用 Git 状态摘要减少编程智能体重复读库

编码 Agent 每次开工都要重新摸清仓库，浪费的不只是 token：如果它读到过期任务，还可能认真地做错事。独自维护约 16 个仓库的作者，为此做了 Go CLI 工具 Relai，把当前状态压缩成会话启动时自动加载的交接信息。

这套方案有价值的地方，是从 Git 和任务文件即时生成上下文，并用 hook 保证它被读到。作者报告了明显的 token 节省，也坦承实验规模有限、小项目可能更贵。对同时维护多个项目的人，这比又一套提示词技巧更值得看。

Agent 缺的不是更多文档，而是可信的开工状态

作者遇到两种开销：每次新会话，Agent 都要读大量文件才能确定项目进度；按他的描述，一次 Claude Code 调用在读取项目代码前，就已有约 29k tokens 的成本。不过，原文没有拆解这笔成本的来源，不能直接当成所有用户的固定开销。

更麻烦的是信息过期。他的一个 TODO 文件有数百个未勾选项，其中一些早已完成，Agent 却继续处理。早期评估还出现过这样的失败：基于陈旧任务列表生成的精简交接，让模型在一轮内自信地答错。

压缩上下文本身并不保证正确。压缩错了，反而更容易让模型相信那份摘要。

Relai 的核心命令 relai handoff 会用几百 tokens 输出分支、近期提交、Beads 中的未完成任务、OpenSpec 变更中下一个未勾选步骤，以及人工记录的决策和踩坑信息。

这些内容从文件生成，不由 LLM 撰写。读取任务跟踪器失败时，它会明确报错，而不是显示「0 个任务」。这个区别很实用：无法确认有没有任务，不能等同于确认没有任务。

把交接放进 hook，才不依赖 Agent 的记性

relai workspace 把同样的思路扩展到项目目录。作者的 16 个仓库，总览约占 400 tokens，适合先判断该进入哪个项目，再查看具体交接。

其他命令负责补齐维护动作：

• relai discover --links 查找仓库间的相互提及，提出关联供用户确认。
• relai tidy 只有在默认分支的提交中发现 Closes 标记时，才关闭对应任务。原文没有展示完整引用格式。

作者更看重自动加载。relai init 会为 Claude Code 添加一个小 hook，在每次会话开始时载入交接。仅在 AGENTS.md 写「先运行 relai handoff」，Agent 仍可能跳过。

在作者尝试的新克隆仓库中，没有额外项目说明时，带 hook 的会话用一轮回答了「项目进展到哪了」，不带 hook 则需要两轮。这是有限样本中的观察。

后续还有两个 Git hooks：一个在提交时更新仓库内的任务导出，另一个在合并后关闭已完成任务并删除已合并分支。作者仍需手写决策和踩坑笔记。

自动生成可以减少摘要过期，却不能替源文件保证真实性。

如果任务状态没更新，或者关键决策没写下来，交接仍可能遗漏事实。它消除的是额外维护一份摘要的负担。

节省约 100k tokens，证据有多强

作者在自己的 16 个真实仓库上，用 Claude Haiku 比较了两条路径：先读总览和交接，或者直接探索仓库。前者每项任务节省 tokens 的中位数约为 100k。

这个数字值得关注，但实验边界也很明确：每个案例只跑了一次，有一个案例用了 Relai 反而更贵；两个小项目直接读 README 成本更低。目前也只试过 Claude。

作者自建的脚本测试样例中，交接方案以更少 tokens 达到了与读文档相同的正确性。不过，这些样例专门用来暴露过期文档问题，对 Relai 有利。另一个约有 15 条 CI/CD pipelines 的 portal 仓库，只是使用体验，没有测量数据。

团队能力也还在验证中。可选的自托管看板 RELAI-TEAM 读取 Beads、OpenSpec 和 TODO.md 清单，支持任务认领、租约、MCP adapter、token 轮换和限流。租约用于让崩溃 Agent 占用的任务重新释放，但作者一直独自使用，尚未验证多人协作收益。

其中一个工程教训反而非常具体：早期服务定时轮询仓库，每次 bd 调用即使只读，也会重写约 3 MiB 数据库。空闲时写入约 9.5 MB/s，一天约 790 GiB，NVMe 温度达到 80 °C。作者后来用少量 stat 调用计算仓库指纹，只读取发生变化的内容。

调用外部命令时，「读取」操作也可能产生大量写入。

我的判断

我认可「确定性生成状态，再通过 hook 注入」这个方向。比起再维护一份自然语言进度文档，它少了一处需要人工同步的信息源；相比只靠 AGENTS.md 提醒，hook 也更容易保证启动动作发生。

但约 100k tokens 的收益还不能推广到一般团队。仓库规模、任务类型、原有文档质量都会影响结果，单次运行也难以排除模型波动。原文没有给出足够的重复实验，这仍是有价值的初步证据。

小仓库直接读 README，可能更划算。只使用普通任务系统、没有 Beads 或 OpenSpec 的团队，也需要先评估接入和维护成本。

作者还公开了交接格式规范，目前为草案 v0.5，包含版本规则和变更记录；Relai 自身也通过 OpenSpec 开发。但 relai.yaml 尚无正式 schema，也没有第二个实现。现在更适合把它视为工具格式，而非成熟标准。

能拿来做什么

• 同时维护多个前端或 Node 仓库时，可以先尝试生成简短的项目总览，再按需读取单仓库状态，减少每次会话重新找入口的成本。
• 给日常 AI 编程接入启动 hook 前，先明确交接需要哪些可靠字段，并让读取失败显式暴露，避免把未知状态写成「没有任务」。
• 用自己的真实任务比较交接方案与直接读 README 的成本和正确性，重复运行后再决定是否接入，小项目尤其值得先测。
• 编写轮询仓库或调用任务 CLI 的 Node 脚本时，同时检查磁盘写入；可以借鉴文件指纹方案，只在状态变化后读取详细内容。