8.0
热点
AI SCORE
编程提效2026-08-14 07:19
Agent 记忆不应在聊天中，应在项目文件里
dev.to · AI#AI编程#Agent#工作流
Editor brief · 编辑速览
作者提出用项目根目录的特征追踪器替代聊天记录作为 Agent 记忆，避免每次新会话重复解释背景信息。
我并不是为了发明什么框架而坐下来写这些东西的。
我只是想用编程 Agent 做真正的软件开发，结果过了一段时间之后，同样的问题不断出现：工作量比一个会话周期要大得多。
这才是真正的问题。
不是"哪个模型最聪明"。不是"哪个 IDE 的 Agent 最好"。甚至不是"RAG 有没有用"。
问题是连续性。
一个功能会用一个会话开始，在另一个会话里继续，因为限制而中断，在不同的工具里恢复，而在中途我往往不得不重新解释同样的事情：
这种事情很快就会让人筋疲力尽。
而且这不仅仅是让人烦心。它会影响质量。每次重启都会增加噪声。每个新会话都有漂移的风险。每次 Agent 交接都会产生愚蠢错误的余地——那些错误跟智力无关，纯粹是因为丢失了连续性。
在某个时刻，我意识到我过度依赖聊天记录来充当记忆层。
那就是问题所在。
我开始在项目根目录放置功能追踪文件。
不是什么激励人心的文档。不是模糊的笔记。是真正的追踪文件。
当前功能是什么？哪些完成了？哪些待处理？哪些搁置了？哪些已验证？哪些决策已经做过了？
这立刻带来了帮助。
一个新的会话不再需要从代码里猜测活跃的边界在哪里。
然后我遇到了下一个问题：即使功能状态很清楚，Agent 仍然会重复行为上的错误。
所以我开始把这些也外化。
我把重复出现的规则写下来。作用域规则。验证规则。复用规则。代码库边界规则。那些通常只存在于你脑子里、直到被迫重复第五次才会意识到的东西。
后来我对其中部分记忆加了检索，因为不是所有东西都需要放在常驻加载层，但有些内容在工作推进到适当阶段时绝对应该可以恢复。
在这个过程中，整个工作流程的形状发生了变化。
它不再是"聊天记录记住上下文"。
变成了"项目持有连续性"。
这就是核心思想
最简短的版本是这样的：
项目会记忆，Agent 不会。
这就是我开始称之为 ATMAR 的东西：Agentic Tracker Memory And Retrieval（Agent 追踪记忆与检索）。
需要明确的是，我并不是在声称我发明了记忆、追踪器或检索。
那样说就太荒唐了。
我想说的是，在真实的交付压力下，我最终把它们以一种方式组合起来，让中断的多 Agent 工作变得更加可以承受。
核心部分很简单：
每个部分都已经以某种形式存在。
但组合起来的效果比我预想的更重要。
关于编程 Agent 的很多讨论仍然过于以聊天为中心。
这些问题都没问题。我也在用这些工具。
但我认为所有这些下面有一个更基本的软件工程问题：
当工作比会话生命周期更长时，会发生什么？
因为这是正常的。这不是什么边缘情况。真实的软件工作是杂乱的、漫长的、会中断的、跨越时间分散的。
所以如果连续性主要依赖于当前线程保持活跃，那这个工作流程从设计上看就是脆弱的。
这就是我想修复的部分。
我没有声称：
我声称的是：
有人可能会说："这不过是有纪律的工作流程罢了。"
但除非这种纪律没有产生任何效果，否则这不是一种贬低。
真正的问题是：这种纪律是否能为长周期 AI 辅助软件开发创建一个更强的连续性层。
因为没有名字的模式会消失。
如果你不给某个东西命名，人们要么忽略它，要么复制其中的片段而没有任何共同语言来理解它真正有用的部分。
我希望这是可以检验的。
不是被神化。是可检验。
如果它有了名字，人们可以做比模糊认同或模糊否定更有用的事情。他们可以比较它。
这才是我认为应该有的讨论方向。
我有强有力的操作证据和真实的产物证据。我还没有干净的对比证明。
所以我并没有假装论证已经完成。
这就是为什么我把 ATMAR 作为一个案例研究和评估产物发布，而不是某种膨胀的"工程未来"推销。
我宁愿让人测试它然后告诉我它哪里坏了。
用一个功能来试。
不是你整个公司。不是一个六个月的转型计划。就是一个功能。
然后从一个新会话或另一个 Agent 恢复这个功能。
重启变容易了吗？Agent 在范围内表现更好了吗？交接改善了吗？你重复自己的时候少了吗？或者维护开销不值得吗？
这才是我想要的反馈。
https://github.com/revdfdev/ATMAR
如果你测试了，我真心希望得到一个基于真实尝试的尖锐批评，而不是客套的表扬。
那会更有用。
也许最终这会是一个小众但扎实的方法。也许它会成为长周期 Agent 连续性的有用参考点。也许人们复制这个模式然后改进它。
对我来说关键的事情比品牌更简单：
一旦我不再依赖 Agent 作为记忆层，工作就变得不那么脆弱了。