编码智能体如何记住团队决策

给编码 Agent 补上项目记忆，能不能少返工、少花 token？kgai 团队拿一个包含 61 道修复任务的基准做了测试：三轮共 183 次任务执行，146 次首轮通过，最终解决 182 次。报告的单轮运行费用也低于无记忆方案。

但这组结果有明确边界：任务专门考察「代码里没写、团队以前决定过」的约束，测试由工具厂商自己完成。它更适合回答一个具体问题：当修复依赖历史决策时，把决策和理由提前交给 Agent，究竟有没有用。

为什么代码看懂了，修复还是会错

SDE-bench 是开放项目 Agent Memory Benchmark 中面向编码 Agent 的部分，包含同一个 Python 代码库里的 61 道 bug 修复题。

这些题有意设置了一个陷阱：直觉上的修复能解决表面问题，却过不了隐藏测试，因为隐藏测试检查的是团队此前定下的规则。例如：

• 重试范围包括服务端错误，以及客户端错误中的 429 和 408，不能扩展到所有客户端错误。
• 尝试次数上限是 7，因为此前测量的限流窗口支持这个值。
• 折扣计算必须先应用百分比折扣，再应用固定金额折扣。

这些规则只存在于旧开发聊天或提交信息中，代码没有解释原因。Agent 即使读懂当前实现，也未必能推导出正确答案。

每道题的知识语料还混入了 140 段看似相关的开发聊天，以及宿主仓库的 100 条真实提交。记忆系统要先从这些材料中筛出有效约束，再提供给修复任务。

Agent 拿到仓库和 bug 报告后提交修改，测试框架同时检查失败用例和隐藏用例。失败后会反馈并允许重试，每轮重试计为一次干预（intervention）。因此，主要指标是首轮修复成功数，而不是最后有没有修好。

这套基准考的是能否找回历史约束，并把它用进修复。

kgai 如何把聊天压成几条可用的决策

所有方案使用相同的 Agent 和模型：Claude Code 搭配 Claude Sonnet 5，采用测试框架默认配置。

kgai 不直接保存整篇文档，而是记录「决定了什么，以及为什么」。作者先让同一个模型使用 kgai 自带的 skill，逐份阅读历史材料并提取决策。这个阶段没有针对基准追加专门指令，也看不到任务描述和隐藏测试。

提取结果相当稀疏：240 份共享文档留下 21 条决策，66 份任务关联文档留下 84 条决策；有 6 道任务没有提取到任何记录。大量干扰内容被放弃。

开始修复前，测试框架用 bug 报告作为查询，执行一次检索，再通过所有记忆系统都能使用的通用入口，把结果交给 Agent。典型返回量是 1 至 6 条记录，总共几百词。

这条链路的价值在于压缩：Agent 不必重新翻完整段聊天，而是直接看到「最多尝试 7 次」和对应理由。对于检查精确数值的测试，保留具体值尤其关键。

不过，筛选也会漏信息。作者承认，如果某项决定只藏在标题为 fix: … 的提交里，kgai 的 skill 会刻意不记录，这让若干任务丢了分。

费用下降，主要省在少跑几轮

作者自己的三轮测试共执行 183 次任务，最终成功 182 次，首轮成功 146 次。仍有 10 道任务在三轮中都没能首轮通过，其中一道涉及带有六个左右例外的 MIME 类型表。

费用差异与返工次数有关。无记忆方案平均每道题接近多跑一轮，每轮 61 道题的费用约为 27 美元。两种记忆方案都把额外轮次减少了一半以上：Hindsight 每轮约 19 至 22 美元，kgai 每轮约 12.5 至 17.4 美元。

每次重试都要重新处理代码、测试和已有对话。即便各方案最后几乎都能修完，过程中的重复推理也会增加开销。

但这里的费用需要分开看。作者采用 Claude Code 报告的 API 等价费用，kgai 的数字没有包含首次提取记忆的成本：处理全部 306 份文档花了 33 美元，这批记忆由三轮测试复用。作者根据结果文件判断，已发布的对照运行似乎也只统计 Agent 执行费用。

若把这 33 美元一次性计入，kgai 三轮总费用约为 70.5 至 85.2 美元；按无记忆方案每轮约 27 美元估算，三轮约 81 美元。两者已经有重叠。

所以，修复阶段更便宜，不等于包含记忆建设成本后一定更便宜。 历史记忆能被复用多少次，是成本判断的一部分。

我的判断

我认同作者对问题的定义：有些修复失败源于缺少项目决策，继续读代码也补不上。把决定、精确参数和理由一起留下，比只保存聊天全文更便于后续执行。

但这仍是供应商测量。基准、框架及对照运行来自其他人，不代表整场实验是独立评测。它只有一个 Python 代码库，作者只跑了三轮；已发布的 Hindsight 首轮成功数就在 40 至 46 之间波动，不能把一次排名当成稳定差距。

另一个前提是，题目明确依赖历史决策。它能支持这类任务中的收益判断，不能直接证明普通前端或 Node 项目也会得到同样提升。

至于是否必须引入 kgai，原文没有给出与项目规则文件、决策记录文档等做法的对照。记录少、变化慢的团队，可能用一份维护良好的文档就能覆盖需求；记忆工具是否更省事，还要看检索、更新和维护成本，不能由这组数字代替验证。

能拿来做什么

• 给 AI 留约束时，把参数和理由写在一起。例如记录重试哪些状态码、最多尝试几次、依据是什么，避免只写「优化重试逻辑」。
• 如果 Node 项目里存在计费顺序、接口重试或兼容例外，把这些决定整理成可检索记录，并在修复相关问题前提供给 Agent。
• 评估记忆方案时，同时记录首轮成功率、重试次数和总费用，把首次提取及后续维护成本算进去。
• 先用项目里确实依赖历史决定的修复任务做对照，确认现有规则文档能覆盖多少，再判断是否需要专门的记忆系统。