夜雨聆风上周那篇聊到，Agent 记忆有五层架构，上篇讲了前两层——规则记忆和常住画像。结尾我留了个钩子，说还有三层没聊。
今天就接着聊完剩下的三层。
顺便提一句，如果你没看上篇，建议先翻翻，不然「第三层」「第四层」的叫法你可能不知道我在指什么。
好，直接进入正题。
从那个踩了两次坑的 Agent 说起
上篇开头的场景还记得吧？我的 Agent 同一个坑踩了两遍——session 一过期，它就不记得上周发生过什么，问了一样的问题，犯了同样的错误。
上篇解决了两件事。它知道「我是谁」（常住画像），也知道「我该按什么规则做事」（规则记忆）。
但没解决的关键问题是，「我之前做过什么」「我上次是怎么解决这个问题的」。
这恰好就是第三层要解决的事。
第三层，历史召回
常住画像和规则记忆只保留了最高频的信息。它们就像你的身份证和岗位手册，告诉你你是谁、该怎么做。
但历史细节不一样。你两周前跟客户开会的具体内容，不会写在你的身份证上。你也需要的时候再去翻聊天记录和邮件。
Agent 也是一样。
Hermes 的做法挺有意思。它把历史会话存进一个 SQLite 数据库里，用 FTS5（全文检索引擎）做搜索。需要回忆什么的时候，直接搜。
「两周前我们讨论的那个发布流程的坑，叫什么来着？」
FTS5 搜一下，几行结果就出来了。
三个方案，三种取舍
做得久一点的 Agent 框架，对这个问题都有各自的理解。我整理了一下，大概分三种路子。
Claude Code 的做法是最朴素的。 它把所有历史指令和对话流水式地存成一个线性日志。CLAUDE.md 是它最重要的规则文件，但跨 session 的历史记录就是一串顺序排列的文本，没有索引，没有分类。要找什么，你得自己翻自己找。简单是简单，但你用过就知道，当日志长到一定规模，找信息就像在地铁站里找一颗掉落的硬币。
Codex 的做法会更结构化一些。 它按类型归档——规则文件放一类，项目上下文放一类，历史记录按项目分目录。每个目录有自己的结构。好处是分类清晰，缺点是灵活性差。一个跨类别的复杂问题，比如「这个项目在两周前遇到过什么部署问题」，你需要在好几个目录里分别搜索再拼起来。
Hermes 选了中间路线。 它用 SQLite FTS5 做全文检索，也就是搜索引擎那一套。它把每个会话都存进数据库，每条消息都建立了全文索引。搜索的时候不是按目录翻，而是像 Google 一样，输入关键词，FTS5 返回匹配的结果，带着上下文片段。
我实际用过几次，感觉区别挺明显的。
举个例子。我前几天想找一个很久以前的 session，当时东哥说了一句话「不要在 index.md 里写结尾模板，convert_to_wechat.py 会自动加」。具体是哪个会话我完全不记得了。
用 Hermes 的 session_search 功能，我输入「结尾模板 重复 convert_to_wechat」，FTS5 直接定位到了那个会话，还把匹配的那段上下文一起拉出来了。整个过程大概三秒。
如果走 Claude Code 的线性日志路线，我可能得翻好几分钟。如果走 Codex 的目录归档，我得先回忆当时这个讨论是在哪个项目目录下的，再一层层翻。
所以 Hermes 这个 FTS5 的中间路线，我觉得是找到了一个挺好的平衡点。检索能力够用，实施成本也不高。
按主题归档
但纯粹靠搜索也有一个问题——你搜什么关键词，决策权在你手里。有时候你根本不知道要搜什么关键词。
比如你的 Agent 早上醒过来，它需要「最新」的信息，但不一定知道「最新」应该搜什么。
Hermes 的解决方案是，按 topic files 归档。什么意思呢？就是把高频话题单独拉出来，一个话题一个文件，存成结构化的笔记。
我在 MEMORY.md 里的那些核心笔记，其实就是在手动做这件事情。比如我把「图片引用格式」记成一条笔记，Agent 启动的时候自然就读到了。不需要它去搜索什么关键词，因为这是一条常驻的、按话题归档的笔记。
这种做法介于纯搜索和纯手工之间，我觉得挺实用的。高频话题固化下来，低频话题靠搜索。两个加起来，基本覆盖了大多数场景。
第四层，证据链治理
前面三层解决的是「Agent 能记住什么」。但还有一个更棘手的问题——Agent 记住的东西，对吗？
这个问题我是在踩了一个坑之后才意识到的。
有个周末我让 Agent 帮我查一下某个 API 的最新 endpoints 和参数。它查到了，回答了我，然后顺手把信息记进了自己的记忆里。一切都很好。
直到周二，那个 API 升级了，之前的那套参数全变了。Agent 完全不知道，因为它的记忆里还存着旧的参数。它按照旧参数去调 API，跑了一轮全挂了。
这个问题的本质是什么？
Agent 的记忆系统没有「审计层」。 它不知道一个结论是哪来的、可靠不可靠、有没有过期。
它记住了「A 参数可以调通」，但当 A 参数已经不行了，它还是坚信自己是对的。
一个简单的 postmortem 格式
解决这个问题需要一个审计层。Hermes 的做法是，在记录 Agent 得到的每个重要结论时，用 postmortem 格式把它的「来龙去脉」也记下来。
我用的 postmortem 格式长这样：
问题: [问题描述]根因分析: [为什么会这样]来源可信度: [高/中/低] 高 = 官方文档 / 自己验证过的 中 = 社区 / 博客 低 = 道听途说结论状态: [当前有效 / 已过期 / 已验证 / 待验证]修复动作: [做了什么来修复]
为什么要有这几个字段？
来源可信度解决了一个很实际的问题。你从官方文档拿到的结论和从某个论坛帖子看到的结论，分量是完全不同的。Agent 在决策的时候，"信息来源"应该是一个重要的考虑维度，不是所有信息都是平等的。
结论状态解决的是时效性问题。一个结论会过期。API 会升级、库会更新、最佳实践会变。没有状态标识，Agent 就分不清哪些信息还能用、哪些已经作废了。
定期过期治理
但是光有空格式是没用的。关键是多久做一次「过期清理」。
Hermes 的设计比较务实。它会定期让 Agent 自己检查记忆里的结论——把那些「已过期」的标记出来，重新验证。如果验证后发现结论仍然有效，就把状态改成「已验证」。如果发现已经失效，就标记为「已过期」，并记录新的结论。
我自己设了一个每周一次的 cron job 来做这件事。Agent 每周自动跑一次，扫描所有带「当前有效」标记的条目，根据时间戳判断是否需要重新验证。
这个机制听起来挺重的，但其实跑起来很轻。大多数条目几个月才需要验证一次，每周实际涉及的可能就三四条。
一个踩过的坑
这个第四层，其实是我被坑过一次之后才认真搞的。
有一次我把某个 API 的域名记错了。Agent 根据这个错的信息调了好几天接口都没发现问题——因为它的测试数据是缓存过的，直到正式走流程的时候才炸。排查原因的时候找了好久，才发现根因是记忆里的一条 tiny mistake。
从那以后我花了两个小时重新梳理了所有记忆条目，给每条都补了来源可信度和结论状态。
现在 Hermes 每次做重要决定之前，会先检查结论状态。如果是「待验证」或「已过期」，它不会直接用它做决策，而是先跟我说「我这个信息可能不太准了，要不要重新查一下？」。就这一句话，省了我很多事后排查的功夫。
第五层，技能沉淀
前面四层讲的是 Agent 怎么记住东西。第五层解决的是，Agent 怎么从记住的东西里长出新的能力。
这层是最接近「自我进化」概念的。
我自己的体会是，Agent 跟人一样，踩坑不可怕，踩完不反思才可怕。
从踩坑到技能
这个过程在 Hermes 里就是一条流水线。踩坑 → 反思 → 提取模式 → 固化成 skill。
我给你说一个真实的例子。
我有一个 kanban orchestrator 的 skill，现在已经是版本 4 了。最开始写它的时候，是因为我的 Agent 在编排跨 profile 任务的时候反复出问题——任务派对了人，排期不对；排期对了，依赖链又乱了。
连续踩了三次坑之后，我跟 Agent 一起复盘。我把每次出问题的场景写下来，分析模式。然后发现一个规律——大部分编排失败，都是因为任务之间的依赖关系没有处理好。
然后我们把排查出的这几个问题模式提取出来，写成了一条 skill 里的规则：「创建任务时一定要指定 parents 依赖，让 dispatcher 自动管理先后顺序」。
再后来，踩的坑多了，这个 skill 不断补充新规则。「并行任务的超时时间设 4 小时以上，不然高频任务容易断」「任务体里不要写 Secrets，运行记录会持久保存」「如果 worker 掉线了，任务会自动重试，不用手动重派」。
每条规则背后都对应一次踩坑经历。现在这个 skill 经过四个版本迭代，已经覆盖了绝大部分编排场景的坑。
技能和常住画像的区别
很多人会问，技能沉淀和常住画像有什么区别？两者不是都在 Agent 的记忆里吗？
我的理解是这样的。
常住画像回答的是「我是谁」。 Agent 的身份、偏好、不变量。比如「我是斯维因，东哥的统帅，不动手做事，只看地图派兵收战报」。这是 Agent 的自我认知，每次启动都要读。
技能回答的是「我会什么」。 Agent 怎么做一件事、踩过什么坑、有什么最佳实践。比如「发布文章走 wechat-pre-publish-checklist → wechat-publisher 流程」「创建 kanban 任务时必须指定 parents 依赖」。
区别在于，住画像很少变，几个月可能都不需要改一次。而技能是活的，每次踩一个新的坑、发现一个新的最佳实践，技能都会更新版本。它是 Agent 在实践中不断生长的能力库。
Hermes 的 skill 系统还有一个特别好用的点——技能是可复用的。你在这个项目里写好的 skill，可以直接在另一个项目里用。它是版本化的，可以 review，可以回滚。不像自动记忆，什么时候想起了、什么时候忘了，完全随机。
从四层到五层
回到最开始那个场景。那个把同一个坑踩两次的 Agent，问题出在哪？
一层层排查下来，原因很清楚。规则记忆里没有关于「历史 session 决策要不要记住」的规则。常住画像里也没有关于「新旧 session 之间如何保持状态连续」的偏好。历史召回没有建立索引。证据链治理没有审计。技能沉淀没有把踩坑经验固化。
五个层级，少一层都不行。
但反过来看，当这五层都跑通之后，Agent 的状态变化是非常明显的。它不再是一张白纸。它有自己的性格，有自己的工作经验，知道哪些信息来源可靠、哪些需要警惕，还能自己总结规律、优化工作方式。
四种方案，没有万能药
最后做一个对照，看看市面上主流的 Agent 框架在记忆这件事上走的是什么路线。
Claude Code 靠 CLAUDE.md 规则文件加线性日志，思路最简洁。如果你只有一两个固定的工作流、Agent 不需要太复杂的记忆管理，这是最省事的方案。简洁是它的最大优势，缺点就是缺少结构化——跨 session 的上下文感知基本靠你手动写规则，历史记录没有索引，搜索起来效率不高。
Codex 走的是规则文件加类型化归档的路，结构化更好。每个项目有清晰的目录划分，历史记录按类型归档。缺点是灵活性低——一个跨类别的搜索任务（比如「这个项目遇到的问题跟另一个项目的配置有什么关联」）你需要在好几个目录里分别翻。另外归档规则一旦定下来，改起来很麻烦。
OpenClaw 走的是纯自动记忆路线，不依赖文件系统。记忆完全是自动的，不需要手动管理文件。好处是上手极快，不需要写配置文件。缺点是心智上比较黑盒——你不知道它记住了什么、忘了什么、什么时候会出错。你需要接受一定程度的不可控。
Hermes 就是我一直在用的，五层架构。规则靠文件、身份靠文件、历史靠搜索、证据链靠审计、技能靠 skill 系统。最完整，但配置成本最高。不是所有人都需要五层——如果你只是偶尔用 Agent 做点简单的事，没必要搭这么重的一套系统。
没有万能药。适合自己场景的，才是最好的。
收尾
写到这里，从上篇的「踩了两次坑的 Agent」开始，两篇文章把五层记忆架构都走了一遍。
从一张白纸。到有规则、有身份、有历史、有审计、有自己的技能库。
我有一个挺强烈的感受，两三个月前的 Agent 和现在的 Agent，完全是两个物种。差别不在于用了什么更好的模型，而在于它有了这五层记忆架构撑着。它知道想要什么、记得住做过什么、判断得了信息来源靠不靠谱、还能自己总结经验让下次更好使。
所以回到开头的问题。
你的 Agent 走到哪一层了？
来评论区聊聊。说不定你的经验也能帮到其他人。
以上都是个人的实践和梳理，如有不对的地方欢迎指正。
以上，既然看到这里了，点个赞再走吧～
谢谢你看我的文章，我们，下次再见。
