AI应用开发九：从 Hermes Agent 学长期记忆

从 Hermes Agent 看 Agent 长期记忆：核心不是向量库，而是记忆治理

Agent 长期记忆要解决的核心问题是：

一次任务结束后，哪些经验应该留下？这些经验在下一次任务中如何影响行为？

很多长期记忆方案会从 RAG 或向量库开始设计，但向量库主要解决的是"相似内容召回"。一个完整的长期记忆系统，还需要处理写入、修正、遗忘、晋升、证据追踪和任务上下文构建。

因此，长期记忆不只是"历史记录检索"，而是一套围绕经验沉淀、证据管理、规则晋升和上下文构建的治理闭环。

1. 典型问题：Agent 为什么会反复踩同一个坑？

假设有一个旅行规划 Agent。

第一次，用户要求规划北京三日亲子游。Agent 初版把故宫和环球影城排在同一天，路线检查失败，因为这两个地点跨区较远，带 5 岁孩子下午往返并不现实。

随后 Agent 修正方案：同区域景点集中安排，环球影城这类远距离大项目单独占一天。用户还额外交代："以后这种行程，要把路线检查结论也附上。"

一周后，用户要求规划西安两日游。Agent 又把兵马俑和回民街排在同一天。兵马俑距离市区较远，本质上和上次北京案例是同一类规划错误。

这里暴露的问题不是单次推理能力不足，而是上次任务中的失败证据、修正策略和用户偏好没有沉淀为长期记忆。会话结束后，上下文丢失，下一次任务开始时 Agent 没有带回这些经验，自然会重复犯错。

2. RAG 不等于长期记忆

RAG 主要解决 retrieval，也就是召回问题：

给定一批资料，从中找出和当前问题相关的片段。

但长期记忆至少包含四个动作：

动作	解决的问题
写入 ingestion	什么经历应该进入记忆系统
修正 revision	旧记忆如何合并、改写、更新
遗忘 forgetting	什么内容不应该继续影响行为
召回 retrieval	新任务应该取回哪些记忆

RAG 主要覆盖最后一项。

长期记忆的关键难点在前三项：哪些信息值得写入、如何变成稳定经验、什么时候不应该再进入上下文。

可以把两者的边界理解为：

存储和检索解决"能不能读回来"，记忆治理解决"这条记录未来该不该影响行为"。

3. 四层记忆模型

一种较清晰的长期记忆结构，可以拆成四层：

层级	作用	示例
Raw Episodic	原始事件流	用户输入、助手回复、工具调用结果
Consolidated Episodic	会话摘要和候选经验	某次任务失败在哪里、后来如何修正
Semantic / Policy	稳定规则和长期偏好	远距离大项目单独占一天、用户要求附检查结论
Working Memory	当前任务临时上下文	本次任务真正需要带入 prompt 的规则和摘要

各层职责不同：

Raw 层只负责保存原始证据，不做语义加工。
Consolidated 层负责把一次会话压缩成摘要和候选经验。
Semantic / Policy 层只保留少量高置信规则。
Working Memory 在新任务开始时动态生成，不作为永久存储。

这意味着长期记忆不应该简单地把所有历史塞回 prompt，而应先把历史治理成可用经验，再按任务召回。

4. Raw 事件为什么不够？

如果只保存原始对话，再做简单检索，召回结果通常仍然是碎片。

比如新任务是："帮我规划上海两天亲子游，孩子想去迪士尼，最终路线要可执行。"

系统可能召回这些历史片段：

北京路线检查失败：故宫到环球影城太远。
西安路线检查失败：兵马俑离市区太远。
修正后路线检查通过。
用户说以后要附检查结论。

这些片段虽然相关，但仍然是事件流水。真正可复用的经验是：

远距离大项目应该单独占一天，不要和市区景点混排。

这条经验通常并不存在于单条原始事件中，而是从失败、修正、工具通过和用户反馈中抽取出来的。

因此，Raw 事件只是证据来源，不能直接等同于长期记忆。长期记忆需要进一步抽取、压缩和晋升。

5. 从候选记忆到稳定规则

长期记忆可以分两步生成。

第一步，用模型从一次会话中抽取候选记忆，例如：

用户带 5 岁孩子出行，下午两点到四点需要午睡。
用户不喜欢网红打卡式行程，一天不要塞太满。
输出行程时要附路线检查结论。
远距离大项目不能塞进半天。

每条候选记忆都应该带上证据，例如原始事件 ID。没有证据的记忆后续无法核验，也无法回滚。

第二步，不是所有候选都直接变成长期规则，而是要经过晋升判断。

常见晋升条件可以包括：

晋升通道	含义
跨会话重复出现	同类经验在多个任务中被验证
有工具失败证据	比如路线检查返回 failed
用户明确长期指令	用户表达"以后都这样"

这一步适合采用"模型 + 代码"的分工：

模型负责自然语言理解，例如判断两条候选是否同义。
代码负责结构化判断，例如工具状态是否 failed、是否跨会话重复、是否有 durable 标记。

更稳妥的原则是：

抽取由模型完成，治理由规则和证据约束。

6. Semantic 层要克制

Semantic / Policy 层是长期记忆中影响范围最大的一层。

这一层中的规则会以较高优先级进入未来任务。如果写入错误或过度泛化，后续任务都会受到影响。

例如"住王府井附近"只出现在某一次北京旅行中，且没有用户明确说明长期有效，就不适合晋升为稳定规则。它可以保留在会话摘要中，但不应作为长期偏好影响未来任务。

更适合晋升的内容包括：

用户明确表示以后输出行程要附路线检查结论。
工具多次证明远距离大项目不适合半天混排。
用户明确表达孩子需要午睡、行程不要太满。

因此，Semantic 层的规则应遵循：

少量、高置信、有证据、可追溯。

7. 心跳整理：让记忆在后台自进化

长期记忆整理不适合放在每轮对话中实时执行。

用户等待回复时，如果每一轮都额外进行总结、抽取、合并，会增加延迟。更合理的方式是后台心跳机制：

定时扫描新 Raw 事件。
找到未处理过的事件。
触发摘要抽取、候选生成、规则晋升。
写入 checkpoint，记录处理进度。
根据新增事件数量调整下次心跳间隔。

这样可以让对话过程保持轻量，把记忆整理放到系统空闲时执行。

8. 心跳的风险：自动整理可能变成自动污染

后台心跳读到的内容不一定都可信。邮件、网页、聊天记录、仓库 issue 等都可能进入事件流。

如果后台记忆写入缺少治理，错误信息、谣言或诱导内容可能被写进长期记忆，并在后续任务中影响行为。

因此，后台写入应满足以下条件：

有来源。
有证据。
有晋升理由。
有 scope 边界。
可回滚。
不绕过治理策略。

没有这些约束，自动整理可能演变为自动污染。

9. 新任务开始时，不要回灌全部历史

当新任务到来时，正确做法不是把所有历史会话都塞回 prompt，而是构建一个当前任务专用的 task brief，也就是 Working Memory。

它通常包含：

当前任务描述。
项目 scope。
相关稳定规则。
相关会话摘要。
证据来源。

例如新任务是上海亲子游，Working Memory 可以带入：

孩子下午两点到四点需要休息。
行程不能太满。
重要景点尽量安排上午。
迪士尼这类远距离大项目要单独占一天。
输出结果要附路线检查结论。

这样 Agent 拿到的是整理过的任务上下文，而不是一堆原始历史流水。

10. Scope 隔离很重要

长期记忆还需要处理不同项目、用户和场景之间的边界。

例如用户在报销场景中说：

以后小额交通票直接按新版差旅制度预审。

这条规则应该属于报销 Agent，不应该被旅行规划 Agent 召回。

因此，每条记忆都应带上 scope，例如：

project_id
user_id
session_id
domain
source

没有 scope 的长期记忆，容易变成全局污染源。

11. 向量库的位置

向量库适合作为近义召回加速组件，但不适合作为唯一事实来源。

更合理的定位是：

向量库负责语义召回，主事实仍然保留在可追溯的结构化文件或数据库中。

原因包括：

向量库不擅长表达完整证据链。
向量库不适合作为权限和 scope 治理的唯一基础。
召回索引可以重建，但原始证据不能丢失。
稳定规则需要可审计、可回滚。

更稳妥的架构是：

JSONL 或数据库保存 Raw、Summary、Rule、Evidence。
向量库保存可重建索引。
召回结果必须能追溯回原始证据。

12. 最终验收要看行为差异

长期记忆是否有效，不能只看"有没有召回到内容"。

真正的验收应该看同一个任务在带记忆和不带记忆时，输出行为是否发生可解释、可验证的变化。

例如同样是上海亲子游任务，带记忆后应该体现：

迪士尼独占一天。
明确留出 14:00-16:00 午休窗口。
行程不要塞太满。
重点安排放上午。
输出中附路线检查结论。
能说明长期规则如何被落实。

如果系统只是召回了规则，但最终输出没有遵守这些规则，那么长期记忆并没有真正生效。

因此，记忆系统的验收重点应该是：

不是召回列表，而是任务结果是否产生了可解释的行为变化。

总结

Agent 长期记忆可以概括为一个治理闭环：

原始对话和工具结果进入 Raw 层。
会话结束后抽取 episode 摘要和候选经验。
候选记忆根据证据晋升为稳定规则。
后台心跳定期触发整理和 checkpoint。
新任务开始时生成 Working Memory。
最终通过行为差异验证记忆是否有效。

核心结论是：

长期记忆的目标不是记住更多，而是只让有证据、可追溯、经过治理的记忆影响未来行为。

这也是类似 Hermes Agent 的长期记忆设计最值得关注的地方：它不是把记忆做成无限增长的历史仓库，而是拆成稳定层、历史层、整理层和召回层，让 Agent 能从过去的失败、修正和用户偏好中持续沉淀经验。