Agents 不需要记忆，他们需要文档
AI 工程师正在重新思考软件 agent 应该如何“记住”过去的工作。他们认为，黑盒记忆存储和向量数据库往往会产生陈旧、无结构的杂乱内容，而显式、带版本的文档、ADR 以及仓库本地 markdown 可以给 agent 提供更清晰、可审计的指导。许多人倾向于把 agent 当作初级开发者来管理：用 AGENTS.md、lint 规则、测试和结构良好的文件夹来约束它们，然后让 agent 自己帮助保持文档与代码同步。也有人反驳说文档同样会腐化，因此实用系统大概需要一种结合：精选文档、轻量记忆、强上下文管理以及确定性反馈，而不是某种单一的魔法记忆层。
“记忆”与文档的角色
- 许多人认同，天真的记忆插件（只追加的片段、黑盒存储）很快就会过时、噪音变多，而且难以整理。
- 也有人认为，结构良好的文档（AGENTS.md、ADR、规范、决策记录）才是更好的“记忆”层：可查询、可审计、可更新。
- 另一些人反驳说，文档同样会腐化，也可能碎片化，而且除非有人（通常是 agent）被明确要求保持同步，否则它们很少反映现实。
- 还有人认为这一区分主要只是语义上的：文档不过是一个结构化的、外化的记忆系统。
具体实践与仓库结构
- 常见设置包括：
- 一个最小化的 AGENTS.md，指向更聚焦的文档。
- 基于功能/问题的 markdown 文件夹；
decisions/、plans/、knowledge/、workbench/等树状结构。 - 目录/索引文件，用来描述每份文档以及何时阅读它们（“read_if” 规则）。
- 提到的工具和模式包括：仓库中的 markdown“brains”、用于管理文档的 CLI 工具、基于 S3 或 git 的文档存储、内部技能市场，以及自定义的 memory MCPs。
Agent 行为、控制与漂移
- 反复出现的抱怨是：随着时间推移，agent 会忽略复杂的记忆/ADR/原则系统，转而依赖 grep + 快速写的 Python 脚本。
- 很多人强烈希望通过 hooks、带有指令性的 lint 规则以及确定性的运行时监控来施加强制规则（例如“用 jq，不要临时写 Python”）。
- 有些人使用类似面试的工具或在注释中加入原则/版本 token 来引导 agent，并在原则变化时触发重新评估。
测试、验证与反馈
- 对 agent 的 TDD 循环有不同体验：测试能够确保回归保护并传达意图，但也可能退化为走形式。
- 替代方案是：针对项目特有的代码异味和架构原则，定制“verify”技能和基于 lint 的反馈。
- 确定性的反馈（类似 RL 风格的评分）被认为很强大，但难以落地。
上下文管理与评估
- 强烈关注显式上下文管理：动态裁剪、按文件夹划分会话、结构清晰的 monorepo。
- 对庞大的 AI 生成文档堆持怀疑态度；担心它们会变成难以阅读的“AI slop”，而且并没有可衡量的帮助。
- 有人呼吁对“重文档”与“极简”设置做真正的 A/B 评估；就目前线程中的证据而言，大多只是轶事。
安全性与多 Agent 担忧
- 有些人让许多 agent 24/7 运行并相互通信，且反馈不错；另一些人则担心这种系统很容易被大规模部署、产生错配，以及带来金融系统风险。
- 总体来看，参与者一致认为，agent 系统更需要透明、可检查的状态，而不是黑盒式的长期“记忆”。