编程Agent每次会话都在重复发现你的代码库

我在实际项目中大量使用编码 Agent。Claude Code、Codex、Cursor。它们在修改代码方面已经做得非常出色。但我总是在新会话开始时注意到同样的事情。Agent 开始探索。它读取 package.json，寻找入口点，遍历目录，检查配置，尝试理解约定，找到重要的文件。然后会话结束。之后开启新会话，令人惊讶的是大量工作又重复了一遍。这让我困扰。不是因为仓库探索没用——Agent 在做重要修改之前确实应该检查源代码。问题在于两者之间有区别：

验证当前源代码 和：从零开始重新发现仓库的基本形态

我想看看第二部分能否变得持久化。于是我构建了 Recall。

Recall 是什么

Recall 是一个本地 CLI，从仓库中导出结构化上下文，并将其存储在仓库本身内部。它不是另一个编码 Agent。它不调用 LLM 来理解你的代码库。它不需要 AI API key，不需要云账户。基本思路是：

仓库 → 确定性扫描 → .recall/ → 持久化仓库上下文 → Claude Code / Codex / Cursor / 任意支持 Markdown 的 Agent

生成的上下文可以描述 Recall 能够从仓库中导出的内容，包括：

• 架构入口点
• 项目约定
• 相关文件
• 风险
• 工作区结构
• 仓库状态

这里的关键词是导出。我刻意不想让 Recall 用另一个模型来发明架构解释。如果 Recall 说了关于仓库的什么，我希望那些信息能够追溯到仓库证据。

为什么不用 CLAUDE.md 或 AGENTS.md？

我也在用这些文件。它们解决的是不同的问题。像 CLAUDE.md 或 AGENTS.md 这样的文件非常适合以下内容：

• 使用 pnpm
• 提交前运行这个命令
• 不要手动修改生成的迁移文件
• 我们的 API 错误遵循这个约定

这些是指令和人类知识。但还有另一类上下文：

• 入口点在哪里？
• 这个 monorepo 是如何组织的？
• 哪个工作区拥有这个功能？
• 哪些文件与这个任务相关？
• 自从生成此上下文以来，仓库是否发生了变化？

其中很多可以从仓库中导出。如果工具能确定性重建，我不想手动维护它。所以我的心智模型变成了：

AGENTS.md / CLAUDE.md → 人类意图 + 指令
Recall → 仓库导出的上下文
源代码 + 测试 → 终极事实来源

Recall 不是要取代源码，而是要提供更好的源码地图。

第一个命令

Recall 作为 npm CLI 发布。当前需要 Node.js 22+。

npx recall-context@latest init

这会为仓库初始化 Recall。你可以用以下命令检查状态：

npx recall-context@latest status

生成任务聚焦的上下文：

npx recall-context@latest context \
  --task "Understand the CLI release and packaging workflow" \
  --max-tokens 1200 \
  --stdout

结果是 Markdown，所以不需要特定厂商的协议。你可以把它交给 Claude Code、Codex、Cursor 或其他能够消费 Markdown 的工具。这种可移植性是有意为之。

任务聚焦的上下文

生成一个巨大的仓库转储并不是特别有趣。更难的问题是：对于我即将执行的任务，仓库的哪些部分可能重要？

Recall 使用确定性信号对相关文件进行排名。今天这包括文件路径、名称、符号、工作区关系和有界的导入图。不涉及 embeddings，没有秘密决定你的应用含义的语义模型。这有一个明显的权衡。排名并不是神奇智能的。但它是可预测的、本地的和可检查的。对于这个版本的项目，我更偏好这个特性。

上下文有一个过期问题

持久化上下文引入了另一个问题：过时的上下文可能比没有上下文更糟。假设 Agent 收到了一份三周前生成的漂亮架构摘要。仓库从那以后已经变了。摘要看起来仍然具有权威性。现在上下文正在积极误导 Agent。

因此 Recall 保留快照，并通过以下命令暴露仓库/上下文状态：

npx recall-context@latest status

目标不是假装生成的上下文永久为真。目标是知道什么时候它不再值得信任，而无需再次检查仓库。这个领域仍然有局限性。当前的实现不是一个完美的语义变更检测器，我不想把它呈现为那样的东西。

这引出了我在这个项目中尝试不同处理的一件事。

Recall 没有证明什么

我可以在 README 上放几个吸引人的声明：节省 token，让编码 Agent 更快。

我一个都没有证明。所以我不声称它们。Recall 当前证明的东西要窄得多：我能够确定性导出可复用的仓库上下文、持久化它、检查它、并把它交给不同的编码 Agent。

这样做是否实质性改善了真实的 Agent 工作流是一个经验问题。而这正是我现在感兴趣的问题。

已经存在其他方法

仓库上下文和 Agent 记忆正在成为一个活跃领域。一些方法使用持久化记忆，一些使用 embeddings 和语义搜索，一些维护模块知识，还有一些拦截文件读取并用结构化摘要替换原始文件。

这些都是有效的方法。Recall 有意更窄。它当前的约束是：

• local
• deterministic
• repository-derived
• inspectable
• agent-agnostic
• no AI provider required

我还不知道这些约束是否足以使其有用。但它们使这个实验对我来说很有意思。

局限性是真实的

Recall 还很早期。当下一些重要的局限性：

• 导入图不是完整的语义程序分析系统
• 任务排名是确定性的而非语义性的
• 当前生态支持主要集中在 JavaScript/TypeScript 和相关的 Node.js 框架
• Token 估算基于每个模型的 tokenizer 是近似的而非精确的
• 没有原生 MCP 集成
• 没有编辑器插件
• 没有云记忆层

而且我刻意还没有构建那些东西。

我要停止功能开发

这可能是我围绕 Recall 做出的最重要的决定。通常这正是我开始添加这些东西的时候：

• MCP
• 编辑器集成
• 更多语言
• Embeddings
• 团队同步
• 一个仪表盘

然后六周后我有了一个大得多的产品，却不知道最初的想法是否重要。

这次我不这样做。Version 0.2.0 已发布。下一阶段是验证。我想测量使用和不使用 Recall 的真实编码任务，并关注：

• 首次正确编辑的时间
• 仓库探索时间
• 首次正确编辑前的工具调用次数
• 上下文/token 使用量
• 正确性
• 是否有人自愿再次使用 Recall

最后那个指标可能最重要。如果有人试用 Recall 一次就再也不用了，不管我把扫描仪做得多复杂都没用。

在真实仓库上试试

如果你在非平凡的 JavaScript 或 TypeScript 仓库上定期使用编码 Agent，那是我最感兴趣测试的环境。从这里开始：

npx recall-context@latest init

然后试试：

npx recall-context@latest context \
  --task "Describe the task you're about to give your coding agent" \
  --stdout

项目是开源的：

GitHub: https://github.com/sabahattink/Recall

我特别感兴趣的是失败。如果生成的上下文指向错误的文件、遗漏了重要的东西、错误地变得过时了，或者根本没有改善你的工作流，这比另一个功能请求对我更有用。

因为问题不是：我能为 Recall 添加多少东西？

而是：持久的、确定性的仓库上下文是否足够有用，让你在下一个编码 Agent 会话中再次想要它？

这正是我要找出的答案。