ArcRift（Glia-AI）：让 AI Coding 工具真正记住一切的本地记忆层

你有没有过这种崩溃感？昨天和 Claude 讨论了两小时的接口设计，今天打开 Cursor 想继续开发，Claude Code 完全不记得我们聊过——连「为什么用这个字段名」都要重新解释一遍。每换一次对话窗口，就等于清空一次 AI 的记忆。这就是 AI Coding 工具的记忆困境：上下文窗口是有限的，但开发者的需求是连续的。

ArcRift（GitHub 曾用名 Glia-AI）就是来解决这个问题的：它是一个本地优先的持久记忆层，通过浏览器扩展抓取 AI 对话，通过 MCP 服务器向 IDE 注入记忆，让 AI Coding 工具在每次新会话开始时，自动获得过去对话的上下文。你不需要再重复解释项目背景，AI 也不会在关键决策上「失忆」。

一、为什么这个痛点值得专门做一个工具？

在 AI Coding 工具出现之前，开发者主要靠注释、文档和自己的记忆来维持对项目的长期理解。但 AI Coding 工具的出现彻底改变了这个模式——开发者开始把大量关键决策、架构选择和设计理由放进 AI 对话里，而不是代码注释中。这带来了一个隐性风险：对话是临时的，但决策是持久的。

ArcRift 的作者显然也注意到了这个趋势。项目最早发布于 2026 年 4 月，在短短几个月内就积累了 245+ stars.zero open issues，说明项目成熟度非常高，社区认可度也不错。其 GitHub Topics 覆盖了 ai-agents、mcp、rag、sqlite 等关键词，说明这不是一个实验性玩具，而是一个有清晰技术定位的生产级工具。

二、核心技术架构：三段式本地架构

ArcRift 的架构分为三层，每一层各司其职：

第一层：Chrome 浏览器扩展（抓取对话）

ArcRift 提供了 Chrome 扩展，支持 Claude、ChatGPT、DeepSeek、Gemini、Grok、Copilot、Mistral 等主流 AI 对话平台。扩展通过 DOM 抓取用户和 AI 的对话内容，在发送前对隐私信息（如真实姓名、邮箱）进行脱敏处理，通过 FNV-1a 算法做指纹去重，然后以每秒最多 10 条消息的速率向后端推送。扩展在前端做了大量隐私保护工作——敏感信息在浏览器本地就完成了脱敏，不会上传到服务器。

第二层：Node.js 后端（记忆处理引擎）

后端是整个系统的核心推理引擎，使用 TypeScript 开发。它同时运行两个处理管道：

RAG 向量检索管道：将对话切分为 300 词的滑动窗口块（overlap 80 词），使用 Ollama 的 nomic-embed-text 模型生成 768 维向量，存储到 ChromaDB（Docker 模式）或 sqlite-vec（零 Docker 模式）。在每次用户向 AI 工具发送提示词前，后端会对提示词进行 HyDE（Hypothetical Document Embeddings）增强——先让本地 Ollama 模型根据提示生成一个假设性回答，再将真实提示和假设性回答一起 embedding，以提升检索的准确性和召回率。

知识图谱管道：将对话摘要后，用 Ollama llama3.1:8b 或云端 Groq API 提取结构化三元组（实体-关系-实体），存入 Neo4j 图数据库（full 模式）或 SQLite facts 表（lite 模式）。知识图谱使得系统能够理解对话中的实体关系，而不仅仅是匹配关键词。

第三层：MCP 服务器（向 AI 工具暴露记忆）

这是 ArcRift 最具创新性的设计。项目原生支持 Model Context Protocol（MCP），将记忆工具暴露给任何兼容 MCP 的 AI Coding 工具。当前支持 Claude Code、Cursor、Windsurf、Claude Desktop 四种主流 IDE。提供的 MCP 工具包括：recall_context（召回 top-N 记忆块）、store_memory（主动存储记忆）、search_memory（全局混合搜索）、list_projects（列出项目）、get_project_summary（获取项目知识图谱摘要）、identify_active_project（根据当前工作目录自动识别项目）。MCP 服务器以 Node.js STDIO 模式运行，配置非常简单，只需一行 JSON 即可接入。

三、存储后端：灵活的 SQLite → Neo4j 选择

ArcRift 另一个设计亮点是存储后端的灵活性。它支持三种级别：

零 Docker SQLite 模式：仅依赖一个 ArcRift.db 文件，数据库内置 sqlite-vec 扩展提供向量检索，facts 表存储三元组。适合没有 Docker 环境或内存小于 8GB 的用户。一个命令 npx arcrift-setup 即可完成安装。

Docker Lite 模式：MongoDB + ChromaDB，适合 8GB 以下 RAM、希望有持久化向量数据库但不需要图数据库的用户。

Docker Full 模式：MongoDB + ChromaDB + Neo4j，8GB+ RAM 用户可获得完整的知识图谱体验，支持 Cypher 查询和图可视化。

install.sh 脚本会在安装时自动检测系统硬件，根据可用内存推荐合适的模式，无需用户手动选择。

四、上手体验：一条命令即可

安装体验是 ArcRift 做得非常好的地方。官方推荐的方式是：

npx arcrift-setup

这个命令会自动检测环境（Node.js、Docker、Ollama），安装 Chrome 扩展（通过 .xpi 文件），配置 MCP 服务器，并在后台启动服务。如果使用 Docker 模式，它会拉取 MongoDB、ChromaDB 和 Neo4j 镜像，然后启动后端服务。全程无需手动配置。

Dashboard 是一个基于 Tauri 的原生桌面应用，使用 React + Vite 构建，提供知识图谱可视化、会话历史管理和项目概览。由于是 Tauri 打包的本地应用，启动速度比 Electron 快很多。

五、代码质量与测试

ArcRift 在代码质量保障上投入了大量工程努力。项目内置了完整的基准测试套件，包括：RAG 召回率审计（在 1000 个干扰块中测试检索精度）、图谱渲染压力测试（1200+ 节点的物理引擎稳定性验证）、MCP 上下文压缩基准测试（评估 MCP 提示词的压缩率和延迟）、MCP 项目隔离安全测试（验证多租户场景下数据不会跨项目泄露）。

后端使用 TypeScript 编写，tsconfig.json 配置了严格的类型检查。后端 package.json 包含 jest.config.json，说明有单元测试覆盖。不过，由于项目的核心创新在于数据处理管道而非复杂算法，测试主要覆盖 RAG 检索和 MCP 工具调用的正确性。

六、局限性与挑战

对 Ollama 的强依赖是 ArcRift 最大的技术约束。没有 Ollama 时，向量 embedding 管道无法工作，知识图谱三元组提取也无法进行。虽然项目支持 Groq 作为云端备选，但 Groq 是付费 API，且仅用于图谱提取，不支持 embedding 生成。这意味着纯离线场景下必须安装 Ollama——这对没有 GPU 的用户来说，CPU 推理速度可能较慢。

浏览器扩展的局限性也值得关注。ArcRift 通过 DOM 抓取对话内容，这意味着它依赖 AI 对话平台的页面结构。如果平台改版导致 DOM 结构变化，扩展可能需要同步更新。目前项目 zero open issues，说明作者维护得相当及时，但这也意味着单一维护者的项目存在长期维护风险。

RAG 的本质局限是 ArcRift 无法绕过的：基于向量相似度的检索本质上是模糊匹配，对于高度结构化的需求（如「上次讨论中我们决定用 PostgreSQL 而不是 MySQL 的原因」）可能检索到相关但不够精确的内容。知识图谱在一定程度上弥补了这个问题，但对于没有明确实体关系的隐含上下文，仍然存在盲区。

七、行业意义与趋势

ArcRift 代表了一个正在快速发展的细分方向：AI Coding 工具的记忆基础设施。随着 Claude Code、Cursor、Windsurf 等工具的普及，如何让 AI 在跨会话中保持连贯性，正在从「nice to have」变成「must have」。

类似的开源项目还有 Engram（另一个 MCP 记忆服务器），但 ArcRift 的独特之处在于它同时覆盖了浏览器端和 IDE 端，真正实现了对话记忆和编码上下文的双向同步。2026 年 AI Coding 工具爆发式增长，ArcRift 作为基础设施类项目，正好卡在了一个需求明确但竞争还不激烈的市场空白点上。

从增长数据看，项目在入库后的 3 个月内从 244 增长到 245 stars，增长曲线较为平稳，说明这不是一个流量驱动的爆款项目，而是一个靠口碑传播的生产力工具。对于需要长期维护复杂项目的开发者群体，ArcRift 的价值会随着使用时间推移而持续积累。