把重要信息塞进系统提示词，期待上下文窗口够长，期待重启之后模型还知道自己做过什么。只要任务持续几天，这套方法就会开始崩。
真正的生产级 Agent，不是因为模型更聪明才可靠，而是因为它有一套可以检查、可以继承、可以同步的记忆架构。
01 第一层：会话内上下文
每次会话开始，Agent 至少应该读取两类文件。
一类是身份文件。它定义这个 Agent 应该怎样工作，优先级是什么，哪些事情未经确认不能做，它和其他 Agent 的关系是什么。
另一类是记忆索引。它不是向量数据库，而是一个纯文本目录，指向那些值得跨会话保留的记忆文件。
这层的关键是可读、可改、可调试。
当 Agent 行为异常时，你应该能打开 Markdown 文件，看见是哪条规则让它偏了。记忆如果不能被人类检查，就很难进入生产。
02 第二层：会话后保留
只靠 Markdown 也不够。
因为很多真正有价值的上下文，是在执行过程中出现的：临时决策、失败模式、用户纠正、项目偏好、某个 Bug 的修复原因。
这些信息如果每次都靠人手写入，迟早会漏。
所以需要一个会话后的事实保留层。每次有意义的任务结束后，Agent 把精选事实写入一个存储库。新会话开始前，再按相关性取回。
注意，这不是保存完整聊天记录。
真正该保留的是事实、决策和偏好，而不是所有噪音。
03 第三层：共享长期状态
当你只有一个 Agent，记忆问题还能忍。
当你有两个 Agent 协同工作，问题会迅速放大。一个认为项目状态是 A，另一个认为是 B。一个昨晚修了问题，另一个早上完全不知道。
解决办法是共享状态文件。
它像一个所有 Agent 都能读写的实时上下文日志，记录当前项目状态、关键决策、进行中的任务、谁做了什么、下一步是什么。
多 Agent 系统最怕的不是能力不足，而是状态漂移。共享状态就是防漂移的锚点。
04 第四层：可搜索知识
最后一层是可搜索知识。
有些内容不应该每次都塞进上下文，但必须在需要时找得到。历史方案、旧 Bug、架构解释、用户偏好、长期原则，都适合放进可搜索知识层。
这层可以是语义搜索，也可以是结构化索引。重点不是技术名词，而是让 Agent 在遇到新任务时能主动检索过去的相关经验。
没有这一层，Agent 只能靠当前窗口工作。
有了这一层，Agent 才开始像一个会积累经验的系统。
05 记忆架构取代了更长提示词
很多人解决 Agent 记忆问题的第一反应，是写更长的系统提示词。
但更长提示词只会把所有问题塞进一个地方。它不利于调试，不利于同步，也不利于长期维护。
真正可持续的方式，是把记忆拆成层：会话上下文、会话后事实、共享状态、可搜索知识。
这套架构的意义在于，它让 Agent 不只是“这次回答得不错”。
而是下次还能接上。