4.4. 记忆检索让历史信息从默认参与者变为条件参与者

记忆检索让历史信息从默认参与者变为条件参与者

2026 年 2 月，Nous Research 发布了 Hermes Agent 的首个公开版本。在随后数月的迭代中，一个微小却关键的设计决策开始浮出水面：记忆不是无限注入的上下文，而是在特定条件下出现的“贵宾”。到 2026 年 6 月（本文撰写时），官方文档明确将记忆系统定义为“有界、精心筛选且跨会话持久化”，并强调其核心目标之一是“保持上下文精简的同时提升前缀缓存命中率”。这意味着，历史信息必须从全员出席的默认参与者，变成只在被明确邀请时才上场的条件参与者。

如果你已经阅读了上一章关于 memory_tool 精细化冲突处理的内容，应该已经理解写入操作如何通过精确匹配保证记忆文件的整洁。但写入只是前半段——如果所有已写入的记忆都在每一次推理中全量参与，那么 3,600 字符的萃取就失去了意义。Hermes 的答案是：通过“会话级冻结快照”+“异步写入-下次生效”的工程机制，将历史记忆从全量上下文常驻者，转变为仅在新会话起点被动参与一次、且受严格容量约束的静态背景。这不是一个算法创新，而是一个架构选择，但这个选择对推理密度、成本和干扰控制产生了根本性影响。

结论先行
与常见的“每轮动态检索记忆并注入提示”模式相比，Hermes 的按需检索实际表现为 “不检索”：记忆只在会话开始那一刻被整体嵌入系统提示，整个会话过程中不再改变，写入操作甚至不会在当前会话中生效——历史信息的角色被压缩为一个不可修改的背景板。这一设计将记忆带来的指令干扰从“每轮都可能出现”降为“每会话一次”，同时大幅提高前缀缓存的命中率，使得记忆系统成为成本控制的盟友而非敌人。

（注：以上对比基于 Hermes 官方 memory.md 文档中描述的机制，以及社区对前缀缓存打标的讨论推断。具体缓存命中率提升幅度因模型和会话结构而异，但定性收益是确定的。）

检索触发时机：从“每轮搜索”到“会话起点加载”

在传统记忆增强 Agent 中，检索通常表现为一个主动动作：当用户提出新消息时，Agent 调用检索引擎，从记忆库中找出与当前上下文最相关的若干片段，再拼接进提示。这种模式下，记忆是实时参与者，每一轮都可能被新的检索结果替换或补充。对推理流程而言，这意味着持续的不确定性——Agent 无法依赖稳定的上下文，提示前缀经常变动，缓存命中率被压低。

Hermes 的选择截然相反：检索动作被从对话循环中摘除，转移到了会话的启动阶段。根据官方文档描述，Agent 的记忆由两个 Markdown 文件组成——MEMORY.md（Agent 自身环境与约定，上限 2,200 字符）和 USER.md（用户偏好，上限 1,375 字符）。在每个新会话初始化时，系统读取这两个文件的当前内容，生成一份“冻结快照”，嵌入系统提示。一旦会话开始，这份快照就不再做任何读取或更新，即使 Agent 在对话中通过 memory 工具修改了文件，更改也只持久化到磁盘，当前会话的系统提示中看到的依然是上一刻的快照。

换句话说，“检索”在这里退化为“会话首部的文件加载”。触发时机只有一条规则：用户开始一次新会话。这一决策背后的逻辑是：如果记忆管理的目标是让 Agent 记住长期偏好和环境，那么在一次连续对话中，这些偏好和环境理应保持不变——动态检索反而会破坏这种稳定性。

对比表格能更清晰地呈现两种范式的差异：

这种“懒加载”并非功能缺失，而是一种刻意的工程约束。它让记忆在推理过程中彻底安静下来，Agent 的思考链条不再被忽隐忽现的历史片段打断。

检索算法与排名：当“搜索”被“自治筛选”取代

既然会话开始时不涉及任何矢量相似度或关键词排名，那么 Agent 如何决定哪些记忆应该进入那宝贵的 3,575 字符（2,200 + 1,375）？答案藏在另一个过程中：Agent 在执行记忆写入时已完成了筛选和排名。

在上一章我们详细拆解了 add、replace、remove 三个操作的精确匹配机制。但从检索的角度看，这些操作其实承担了双重职责：它们不仅是写入工具，更是 Agent 自主执行的信息优先级判断。当 Agent 想要记下某事时，它必须自行决定这是否值得挤占有限容量；如果容量已满，工具直接返回错误（而非静默丢弃），倒逼 Agent 当场进行整合或淘汰。这一设计将“检索应该取出什么”的问题，转化为了“写入时应该保留什么”的问题。记忆的“排名”由 Agent 在写入那一刻完成，而不是在读取时由算法计算。

例如，Agent 已经记住了你的 5 条代码规范，每条占 200 字符，总计 1,000 字符。当你提出第 6 条时，如果超出 MEMORY.md 的 2,200 字符上限，memory_add 会返回错误。Agent 必须立刻判断：是合并旧条文腾出空间，还是删除某条不再使用的规范。这种强迫性的实时优先级决策，形成了内在的“记忆排名”——被删除的是低优先级，被保留和整合的是高优先级。最终加载到系统提示中的，就是这样一个经过反复筛选的快照，无需额外检索算法。

对比同样意图的记忆增强系统（如基于向量数据库的 RAG），它们往往在写入时不做质量筛选，大量原始信息涌入向量库，然后在每次检索时依赖 embedding 相似度来提取 Top-K。但相似度并不等同于价值高低——高相似度片段可能是冗余的甚至是过时的。Hermes 的方法避开了这个陷阱：筛选权交给了最了解任务上下文的 Agent 自身，发生在记忆形成的时刻，而不是调用时刻。

检索结果注入与上下文裁剪：冻结快照的插入逻辑

记忆如何注入系统提示，同样经过了精确裁剪。Hermes 要求两条记忆文件的总容量被严格控制在约 3,575 字符以内（约 1,300–1,500 个 token，因模型分词器而异），且以 § 分节符组织条目。嵌入系统提示时，记忆中只会出现核心内容，同时附加当前的使用率信息（例如“Memory usage: 85%, 1,870/2,200 characters”），让 Agent 在会话中获得“自我感知”能力——它知道自己还剩下多少记忆容量空间。

这种注入方式意味着，裁剪不是在检索后发生，而是在写入时就已完成。Agent 无法在会话中期望通过“读记忆”动作获取更丰富的内容，因为它根本没有读取的入口（memory 工具只有 add、replace、remove，没有 read）。系统提示中的快照就是那一次会话的全部印记。如果 Agent 忘记了一件本该记住的事，唯一的补救途径是在未来写入或修改该条记忆，然后等待下一次会话加载。

这一点在实际使用中会产生一个容易被忽视的行为：当 Agent 犯错后，用户若在当前会话中纠正它并要求它“记住这个教训”，Agent 使用 memory_add 写入，但几轮之后继续讨论同话题时，Agent 可能依然会重复犯错，因为新写入的记忆还没有被加载到当前会话的提示中。这不是 bug，而是刻意设计的“写—下一次会话读”异步模式。其目的仍然是保持当前会话的前缀稳定，避免破坏缓存，同时让 Agent 的下一次会话从更好的基础上下文开始。

从上下文裁剪的工程角度看，冻结快照像一页贴在笔记本封面上的便利贴——每次打开笔记本（新会话）都能看到，一旦合上再打开，便利贴可能被替换或新增，但在打开的期间，你看到的永远是最初的那一页。这种设计对开发者提出了一个新的要求：需要教会 Agent 在合适的时间点向用户说明“我已记下，下次会话时会生效”，从而管理用户期望。

按场景推荐：何时让记忆“静默”，何时让它“敲门”

基于以上分析，我们可以为不同 Agent 使用场景提供可操作的使用指南：

1. 长周期项目开发或陪伴型助手
记忆应该以用户偏好和项目环境为主，如代码规范、部署路径、常用工具配置。建议利用 USER.md 存储稳定的用户习惯（比如“使用 spaces 而非 tabs”），用 MEMORY.md 存储项目约定。每次新会话开始时，这些信息作为背景静默参与，无需 Agent 在对话中反复检索。这种模式下，信息作为条件参与者完美隐身，减少了每次对话开头的确认冗余。

2. 需要记住对话中临时决策的单次长会话
冻结快照的缺点暴露：如果会话中途确认了一项重要决策，Agent 写入记忆后无法立即在新的回答中受益。此时应该调整架构预期——不要依赖记忆系统来做工作记忆，而应使用消息历史或工作空间文件夹存储临时决策（如全局 context.md），并在需要时通过读文件工具显式获取。记忆系统只负责跨会话的长期保留。

3. 多 Agent 协作或短期并行任务
每个 Agent 独立维护两文件可能导致数据冲突。从当前调研资料看，Hermes 的官方方案尚未充分暴露多 Agent 共享记忆的成熟机制，但 Reddit 社区中已经有开发者将记忆外接到独立的 MCP/REST 服务，使得多个 Agent 可以异步读写，但依然保留了“每 Agent 自身加载快照”的模式。推荐此类场景先行评估是否真的需要共享记忆，大多数协作任务通过结果文件交换比记忆共享更可靠。

从条件参与到技能抽象

Hermes 通过冻结快照、写入自筛选和异步生效这三个设计，完成了一个关键转变：记忆不再是每轮推理的默认语境，而是会话起点上一次性的条件输入。它用近乎极简的工程手段，解决了长历史记忆带来的干扰和成本膨胀问题——历史信息从“全员开会”变成了“只提交一份书面报告”。

但记忆只是第一步。如果 Agent 在一次会话中成功处理了某个任务，仅仅把结果记到 MEMORY.md 里，下一次遇到类似任务时仍然需要重新推理。真正让自进化成为可能的，是将重复的成功模式从记忆升华为可复用的技能。下一章《从记忆到技能的跃迁是自进化 Agent 的关键路径》，我们将探讨如何把那些被成功筛选进记忆的经验，进一步抽象为可调用的 Skill，让 Agent 从一开始就能带着“肌肉记忆”上场。