长周期 Agent 更需要状态管理

我们已经有了足够多的 memory 层，而且说实话，其中很多都相当好用。Markdown 指令文件有效，模型自行积累的内置 memory 也很有帮助，那些通过 hook 将会话压缩进可搜索数据库的工具，同样是很聪明的工程实践。我每天都在使用其中好几种工具，也并不是来劝你把它们全部扔掉的。

但即便如此，我还是反复遇到同一个问题。我同时运行着几个项目，而且全都通过 Agent 会话推进。一天早上，一个加载了所有 memory 层的全新会话，提议重新讨论一项我在两周前就已经敲定的决定。还是同样的论据，却逐渐推导出了相反的结论。我明明已经把那项决定记录下来了，它就在 memory 里。只是这个会话从未认真读到那条特定记录，因此没有把它当成已经确定的结论。

就在那一刻，我不再相信增加更多 memory 就是答案。

Memory 只有在被读取时才有效

一个负责长期项目的无状态模型，需要从你这里获得两种不同的信息。它需要知道项目是如何走到今天这一步的，也需要知道此时此刻什么才是真实有效的。Memory 是为前者而设计的。它记录说过的话，让过去的信息可以被搜索，而且这件事做得很好。

但出于结构性原因，它无法解决第二个问题：memory 必须经过检索才能被使用。搜索必须被触发，正确的记录必须排在足够靠前的位置，而且 Agent 还必须针对当前这个具体场景，真正仔细地读完它。只要这条链路中的任何一环断裂，过去的错误就会再次出现。你可以记录一切、索引一切，却依然眼睁睁看着同样的错误重复发生，因为一份保存了所有历史言论的档案，并不等于一份关于当前事实的声明。

当前依然成立的事实其实只是一份简短清单：目标、仍然有效的决定、正在推进的工作，以及这些工作被什么阻塞。这份清单需要在每个会话收到第一条 prompt 之前，就直接摆在它面前，不需要任何人检索任何东西。如果必须通过搜索才能获得这些信息，那你其实是在拿搜索结果碰运气。

我不断重建 wiki

早在 Agent 出现之前，人们就已经在管理这类清单了。它们通常存在于 Notion、Jira、Confluence 或团队 wiki 中。任何维护过这类系统的人都知道故事会如何发展：页面逐渐过时，更新它们慢慢变成一件苦差事，负责更新的人越来越疲惫，最终 wiki 不再反映真实情况。

对于小型项目，你确实不需要这些东西。仓库里的 Markdown、几条简单规则，再加上你自己的记忆，就已经够用了。这个组合支撑了我很多年。但随着项目规模增长，它会逐渐失效；而当项目从一个变成两个时，它很快就会彻底崩溃。

所以我采取了显而易见的下一步：让 Agent 来维护这些文档，打造一套由 Agent 整理的项目 wiki。我前后构建过两次这样的系统。两次都是短短几周内就变得陈旧，而我又开始重建一个系统——可这个系统存在的全部意义，明明就是让我不必亲自维护它。

文档会腐烂，因为它是自由形式的

这种失败背后的机制很简单。同一件事可以在文档里用五种不同的方式表达。由于没有规则规定某项事实应该存放在哪里，它便会被写进两个地方，随后两个副本逐渐产生分歧。除非有人专门去查找，否则没人会注意到重复内容。你可以为 Agent 编写风格规则，我也确实这么做了，但这样一来，系统的正确性就取决于每个 Agent 每一次都严格遵守规则。只要有一次没有做到，你就又得回头重写。

任何需要编辑的东西，都需要维护。这句话就是所有死亡 wiki 的完整历史。

摆脱这个困境的方法，是停止编辑。要把 state 当作 state 来管理：

记录事件，而不是更新页面。一项决定已经作出、一项工作已经完成、一项声明获得了 commit 的支持。每件事各写一行，在发生的当下写入，并且只允许追加。不存在需要持续保持最新的“当前 state”文档。

让每一类事实都只有一种固定结构。在我的系统中，记录一项决定只有一种方式，而不是两种。“这应该放在哪里”和“这是不是重复记录”不再需要临场判断，因为结构早已替你作出了决定。

把规则写进工具，而不是写进风格指南。如果一项“done”没有证据，工具就会拒绝记录。修正内容时，新记录会取代旧记录，同时保留完整的演变关系，而不是直接修改历史。一切都不再依赖某个 Agent 今天是否足够认真。

随后，当前 state 会从日志中推导出来，并在每次变更后重新生成。派生出来的投影无需维护，因此也没有任何东西会腐烂。那项杀死了每一个 wiki 的苦差事，就这样彻底消失了。

而且，要实现这一切，你既不需要数据库，也不需要 API。日志只是 git 仓库中的一行行文本。派生出的 state 则是任何 Agent 都能读取的 Markdown。

我把这套系统做成了 superself，其中包含一个名为 self 的 CLI。现在我用它管理自己的项目，包括 superself 本身。每个会话都从一条命令开始，当前事实会被直接推送给它，整个过程不涉及任何检索步骤：

无论在哪里，记录都使用同一套语法。而且写入路径会主动拒绝不合规的操作：如果哪天我声称某项工作已经完成，却拿不出证据，工具也会拒绝我。

当一项决定需要改变时，新决定会取代旧决定，但两者都会保留在日志中。“我们是如何走到这里的”只需要一次查询就能回答；同时，也不会有任何会话把旧决定当成尚未解决的问题，因为 context 只会展示当前仍然有效的内容。

Memory 回答的是：“我们曾经围绕 X 说过什么？”State 回答的是：“现在什么是真的，以及什么不应该被重新讨论？”两者我都需要。但只有后者，真正阻止了我的会话通过不断争论，推翻我自己已经作出的决定。

superself 是一个开源项目，目前仍处于预发布阶段。如果你使用 Agent 同时运行多个项目，而且重建 wiki 的次数已经多到让你不太愿意承认，那么它的入门指南大约只需要五分钟就能看完。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。