用户在解决问题过程中顺手说了一句偏好，主 Agent 正忙着读代码、跑测试，没有调用 memory 工具。任务完成了，值得保存的信息也一起消失。
Hermes 的 Background Review 让另一个 Agent 在后台回看对话，把执行时遗漏的知识补写进记忆或技能。
这篇只回答一个问题：Agent 忙于完成任务时常常忘记保存经验，怎样补上这一步又不阻塞用户？
Hermes 给出的答案是：在对话后按双计数器触发后台审视，把 messages 快照交给独立 Agent，允许其操作共享记忆和技能工具，并让整个过程失败可忽略、不可递归。
执行与复盘是两种注意力任务
主 Agent 的目标是解决当前问题。要求它在每一步同时判断哪些信息值得长期保存，会增加提示负担，也容易在复杂工具链中遗漏。
Hermes 把复盘放到对话后，由独立 Agent 读取快照。学习过程不阻塞用户下一轮，也不会修改主对话本身。
双计数器区分事实与方法
记忆更可能随对话轮次出现，技能更可能来自多次工具调用后的试错。Hermes 分别统计 turns 与 iterations，用不同频率触发审视。
如果主 Agent 已经主动写入记忆或技能，对应计数器会重置，避免后台再次保存同一内容。触发机制因此同时考虑机会和去重。
共享存储，但不共享可变消息
审视 Agent 需要写同一个 MemoryStore 和技能目录，才能让结果在未来会话生效；它读取的 messages 却必须是快照。
若把可变列表引用交给后台线程，主 Agent 新一轮追加消息时，审视看到的输入会在运行中改变。共享什么、复制什么，是隔离设计的核心。
学习失败不能拖垮主任务
Hermes 把审视放在 daemon thread，限制最大迭代，吞掉异常并关闭多余输出。失败的后果只是这次没有保存经验，而不是用户对话失败。
审视 Agent 还必须关闭自己的 nudge，否则它会触发新的审视 Agent，形成无限级联。best-effort 不是随意忽略错误，而是明确核心链与增强链的优先级。
Hermes“越来越聪明”的完整链路
主 Agent 每完成一轮对话或一批工具调用，记忆与技能计数器都会更新。达到阈值且本轮没有主动保存时，系统复制一份 messages 快照，在后台线程创建审视 Agent。
审视 Agent 读取的对话不会继续变化，但它使用的 MemoryStore 和技能目录与主 Agent 相同。它检查用户偏好、项目事实和非平凡做法：值得保存就直接调用 memory 或 skill_manage，没有内容则明确返回 Nothing to save。
这项工作限制迭代次数、吞掉异常，并关闭自身 nudge，避免审视再触发审视。即使本次失败，用户刚完成的任务和下一轮对话也不受影响。
所以 Hermes 的“聪明”不是模型在后台自动升级，而是把容易遗漏的经验转换成 未来会话可读取的记忆和技能。它改变的是上下文资产，不是模型参数；后者属于轨迹训练和强化学习的范围。
三个容易走偏的地方
- 审视 Agent 保留 nudge，后台线程不断递归创建新审视。
- 把 messages 引用而非快照传入后台，输入在运行中被污染。
- 审视提示过于宽泛，没有 Nothing to save 的止步条件。
产品经理可以怎样评审
评审这项能力，可以先检查三条：
- 自动学习应在主任务成功之外独立计状态，失败不能反向破坏交付。
- 触发频率要与有效经验产生信号绑定，而不是每轮固定执行。
- 审视输出必须允许“无内容可保存”，否则自动化会制造噪声记忆。
本文基于原材料解释后台审视机制，不把静默吞错视为所有后台任务都适用的错误策略。