话说回来，

从 Hermes Agent 看 Agent 长期记忆：主要不是向量库。而是记忆治理

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

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

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

至于典型问题，Agent 为什么会反复踩同一个坑？

假设有一个旅行规划 Agent。

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

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

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

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

RAG 不等于长期记忆

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

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

RAG 主要覆盖最终一项。

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

四层记忆模型

• Raw Episodic: 使用者输入、助手回复、工具调用结果。
• Consolidated Episodic: 会话摘要和候选经验；例如某次任务失败在哪里、后来如何修正。
• Semantic / Policy: 例如远距离大项目单独占一天；使用者要求附检查结论，长久偏好。
• Working Memory: 当前任务真正需要带入 prompt 的规则和摘要；例如儿童午睡时间等细节，按理说，

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

为什么 Raw 事件不足以支持长期决策？

If you only store raw dialogue and perform simple retrieval,recalled results are usually fragmented.

• You might ask for a new itinerary that references previous failures。but those are still event fragments.
• The real reusable knowledge is distilled from failure,correction,tool feedback,and user preference.

从候选记忆到稳定规则的两步流程

1. 再看抽取候选记忆，模型识别潜在规则，例如「孩子午睡时间」或「避免网红打卡式行程」。 按理说，每条都需附原始事件 ID 做证据链接。
2. 从晋升判断来看，通过跨会话重复出现、有工具失败证据或使用者明确指令等条件。将候选转化为可执行规则，并写入结构化存储以实现可追溯性与回滚功能。
   抽取由模型完成，治理由规则与证据约束保证可靠性。

Semantic 层要克制——避免过度泛化导致误导

• A rule like “stay near Wangfujing” appears only once in Beijing trip—without explicit long‑term instruction it shouldn’t become a permanent preference.
• A rule that gains credibility through repeated failures or explicit user mandates can be promoted safely.
• A stable rule must be limited in scope。high confidence,evidence‑backed and traceable back to original interactions.
  Rule set = 少量、高置信、有证据、可追溯

说到后台心跳整理，让程序在后台自进化而非实时耗时冗余

1. 定时扫描新 Raw 事件；怎么说呢，若发现未处理过的数据则触发摘要抽取流程；步骤二至四按常规执行，步骤五根据新增事件数量心跳间隔，以保持程序轻量高效。
   后台写入需满足来源+证据+晋升理由+scope边界+可回滚等条件。

新任务开始时不要回灌全部历史——聚焦 Working Memory 的目标化上下文建立

• "Working Memory" 包含当前任务描述 + 项目 scope + 相关稳定规则 + 有用会话摘要 + 明确来源 & 证据标识。再看例子，对于上海亲子游。“孩子下午两点到四点需要休息”“行程不能太满”“关键景点尽量安排上午”“迪士尼这类远距离大项目要单独占一天”“输出结果要附路线检查结论”。这样 Agent 能收到整合后的上下文，而不是原始历史碎片。从而减少因过度引用旧信息导致误判或重复错误的问题。

Scope 隔离很关键——防止全局污染

• "Scope" 是所有长期知识必备字段。如 project_id / user_id / session_id / domain / source 等，可确保知识仅在适当范围内被召回与应用。说到举例，报销场景中说 “以后小额交通票直接按新版差旅制度预审”。这条规则应属于报销域，而非旅行规划域。缺乏 scope 的知识容易成为全局污染源，使得本来无关的 Agent 被错误地引导去遵循此规定。不过，

向量库的位置 —— 辅助语义召回。不作事实唯一来源

• "Vector Store" 应用于近义词召回加速，但主事实仍保存在结构化文件/数据库中，以便追溯验证与权限控制。原因包括向量库无法完整表达完整证据链；不过，无法成为权限与 scope 治理唯一基础；话说回来，索引可以重建但原始证据不可丢失；稳定规则需可审计可回滚，合理架构示例这方面，JSONL 或关系型数据库持 Raw/Summary/Rule/Evidence 等字段；Vector Store 存可重建索引并支持检索结果直接追溯到原始数据。

最终验收要看行为差异。而非仅仅是否召回了内容

• "Behavioral Difference Test" — 对比带记忆与无记忆情况下相同任务输出，看是否产生解释性且可验证的改动。例如上海亲子游应体现迪士尼独占一天、留午休窗口、不塞太满等细节，并说明所依据的长期规则。如果程序只是检索了规则却未实际落地，这说明长期记忆并未真正生效。老实说，

​ ​​ ​ ​ ​

​