点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

如果说 Nudge Engine 是 Hermes 的"开关"，那 Review Agent 就是它的"心智"。

我读 Hermes 源码时最佩服的一处设计就是这一块。它没有让"执行任务的那个 Agent"自己复盘自己，而是单独跑了一个专门负责反思的 Agent，在后台默默工作。

这件事看起来很小，但解决的是一个非常根本的工程问题：让一个正在干活的人评判自己刚刚干得好不好，结果总是又长又自夸又没用。

Review Agent 解决的就是这个问题。它换了个角色、换了个 prompt、换了套判断标准，专门干"复盘 + 决定该记什么"这一件事。

这一篇我们就把 Review Agent 拆开看。

为什么需要"独立的"复盘 Agent

很多人做自学习系统时，第一反应是：让执行 Agent 在每次任务结束后，自己写一段总结。

我自己做过这种实验，结果有两类典型问题。

问题 1：自我评价偏正面

让 Agent 自己反思自己刚做的事，它几乎永远会写"任务顺利完成、流程合理、结果符合预期"。

这不是模型偏心，是 prompt 本身的问题 —— 你让它"说说自己干得怎么样"，它的角色是"执行者 + 评价者"，两个角色一冲突，评价就被执行的"我已经尽力了"压住。

写出来的总结基本没法用。

问题 2：上下文挤占严重

执行任务的对话本来就长，再让模型在结尾加一段反思，token 直接翻倍。

而且模型的 attention 在执行任务时聚焦在"下一步要做什么"，复盘要求它从结果反推过程，这两种思维模式在同一个上下文里切换，效果很差。

Hermes 的解法是：把 Review 拆出去单独跑。

执行 Agent 跑完，把整个 trajectory（任务轨迹）丢给 Review Agent。Review Agent 是个全新的对话实例：

▸全新的 system prompt（专门写"你是一个复盘者"）

▸全新的上下文（只有任务轨迹，没有执行时的废话）

▸全新的判断标准（独有 / 高频 / 通用 才记）

这种"双 Agent"设计的关键好处是：评价的人和被评价的人不是同一个，公正性自然就出来了。

我跑过对照实验：让同一个模型分别用"自我反思"和"独立 Review"两种方式复盘 100 次任务，独立 Review 写出来的 Memory / Skill 在后续任务中的命中率高出大概 3 倍。

Review Agent 一次复盘做了什么

Review Agent 不是一个魔法盒子，它的内部流程其实很清晰，就 4 步。

我把每一步拆开说说。

第 1 步：收集这一轮的素材

Review Agent 拿到的是一个完整的"任务轨迹"。具体包括：

▸用户最初的需求是什么

▸Agent 调了哪些工具、参数是什么、返回了什么

▸中间产生了哪些对话

▸用户有没有打断或纠正

▸最终任务成没成、用户的反馈是什么

这些素材在 Hermes 内部叫 session trace，是结构化的事件流，不是纯文本。Review Agent 拿到的是已经规整好的数据，省去了"从混乱对话里提取信息"这一步。

第 2 步：分类信息类型

拿到素材之后，Review Agent 第一件事是分类：这一轮里出现了哪些"可能值得记"的信息？它们分别是什么类型？

Hermes 里的分类大致 4 类：

▸事实型："这个项目的数据库是 PostgreSQL"

▸偏好型："用户喜欢用 yarn 不用 npm"

▸流程型："发布到 npm 的 5 个步骤"

▸教训型："忘了 build 会发空包"

分类不是为了好看，是为了下一步决定写到哪里。事实和偏好通常进 Memory，流程和教训通常进 Skill。

这步很容易被忽视，但其实非常关键。如果跳过分类直接写，会发生"流程被塞进 Memory、事实被塞进 Skill"这种乱套。

第 3 步：判断写入价值

这是 Review Agent 最有"灵魂"的一步。

不是所有分类出来的信息都值得记。Review Agent 会用 3 把尺子去过滤（下一节细讲）。

只有同时满足"独有 + 重复 + 通用"的信息，才有资格进入下一步写入。

我在源码里看到，这一步用的 prompt 非常严格，会反复强调"宁可错过，不要乱记"。这是 Hermes 设计哲学的一个体现 —— 错过的信息以后还能补，错记的信息会污染整个 Memory / Skill 库。

第 4 步：选择目标和写入方式

通过筛选的信息，最后一步是决定：

▸写到 Memory 还是 Skill？

▸写到全局（~/.hermes/）还是项目级（.hermes/）？

▸是新建一条，还是 patch 已有的？

新建 vs patch 是个隐藏的设计要点。如果已经有相关 Memory / Skill，Review Agent 会优先 patch 而不是新增。这避免了"同一个事实被记 5 遍、版本互相矛盾"的烂局面。

整个 4 步走完，Review Agent 退出，等下一次被 Nudge 唤醒。

金句：不是"记下一切"，而是"只记值得的"。

3 把尺子：什么样的信息才"值得记"

Review Agent 的核心难点不在流程，在判断标准。

我看 Hermes 的 prompt 时，发现它把"是否值得记"这件事拆成了 3 个维度，每个维度都是一道独立的过滤。

尺子 1：独特性 Uniqueness

这条信息原本不在模型的"常识"范围内吗？

✅ 应记："这个项目的部署机器在 ap-east-1"

这种是项目特定信息，模型自己绝对不知道，记下来才有价值。

❌ 不记："JavaScript 是动态语言"

这是基础知识，每个 LLM 训练时都已经学过，再记一遍是噪音。

很多人初做 Review 系统时容易踩这个坑 —— 把模型本来就懂的常识也写进 Memory，结果库越来越膨胀。

尺子 2：重复性 Repeatability

以后还会反复出现吗？

✅ 应记："每次发包都要 bump version"

这是高频出现、跨任务都会用到的事实，记下来收益持续。

❌ 不记："今天网络偶发抖了一下"

一次性事件，下次几乎用不到。

判断重复性最简单的办法：这个信息在未来 10 次相似任务里，至少会被用到 3 次以上吗？ 如果不能，就别写。

尺子 3：通用性 Generality

是这一类任务的通法，还是只有这次有效？

✅ 应记："npm publish 前必须 build"

这是"所有 npm 发布"的通用规则，不限于今天发的这个版本。

❌ 不记："今天只发了 1.0.3 这个特定版本"

这是单次执行的细节，没有跨任务复用价值。

通用性这一关最难判断，因为很多信息看起来"挺通用"，但其实只在某个特定子场景下成立。Hermes 在 prompt 里专门要求 Review Agent 在写入时，必须说明这条信息适用的边界。

只有同时通过 3 把尺子的信息，才会真正进入 Memory / Skill 文件。

Review Agent 也会学歪：3 类典型失误

把 Review Agent 写得这么聪明，是不是它就不会犯错？

并不是。我跑了一段时间后总结过，Review Agent 至少有 3 类典型"学歪"模式。

失误 1：过度抽象，丢了上下文

错误示例：把一次完整的发布流程，抽象成 Skill 后变成"部署服务 → 验证 → 完成"这种全是 placeholder 的高级描述。

听起来很通用，实际上下次执行时模型完全不知道每一步具体要敲什么命令。

修复方式：限制 Skill 必须包含至少 3 行可执行命令。Hermes 在 prompt 里有一条硬约束，叫 "steps must be reproducible without further inference"。

失误 2：抽得太细，等于流水账

错误示例：Memory 里写"2026-04-30 14:23 用户运行了 ls 命令"。

这种信息没有跨次复用价值，纯粹是日志，不是 Memory。

修复方式：明确告诉 Review Agent，只记跨任务复用的事实，不记一次性事件。

我自己在调 prompt 时加了一句话："如果这条信息只在今天这一次任务里有用，不要写入 Memory。"加完之后，流水账类条目少了一半。

失误 3：拟人化，把用户随口的话当偏好

错误示例：USER.md 里出现"用户喜欢周二下午写代码"。

这是 Review Agent 把用户某次偶然的对话当成了稳定偏好。

修复方式：偏好类信息必须有 2 次以上佐证才能写入。Hermes 里这叫 "two-strike rule"，单次事件不能升级成偏好。

这 3 类失误的本质都是同一个问题 —— 学习不等于记下一切，更不是猜测。

Review Agent 的 prompt 设计里有大量"反猜测"的提示词，比如"不要从单次行为推断长期偏好""不要把用户的礼貌用语当成需求"。这些都是踩过坑之后的工程沉淀。

我自己用下来的几个观察

跑了 Hermes 一段时间，我对 Review Agent 这层有几个挺深的体感。

观察 1：Review Agent 的写入率应该很低，才是健康信号

我看过自己跑了一周的统计，Review Agent 被触发了大概 200 多次，最终真正写入 Memory 或 Skill 的不到 30 次。

写入率大约 15%。

很多人觉得这个比例太低，应该让 Review Agent 多记点。我现在的看法恰好相反 ——写入率越低越说明它在认真过尺子。

写入率上 50%，库就会膨胀；上 80%，整个 Memory / Skill 就成了噪音库。

观察 2：失败任务比成功任务更值得 Review

失败任务里包含的信息密度，往往是成功任务的 3 倍以上。

成功了你只学到"这样能跑通"。失败了你学到"这样会出错、根本原因是什么、怎么排查、下次怎么避"。

我现在跑 Hermes 时，会专门给失败信号设更高的优先级，让 Review Agent 优先复盘失败案例。

观察 3：Patch 比新建多得多

跑久了之后你会发现，Review Agent 大部分时候不是在新建 Memory / Skill，而是在 patch 已有的。

这其实是好事 —— 说明库里的核心条目越来越稳定，主要的进化是"在现有条目上增量补充"，而不是"无限新增"。

观察 4：偶尔人工 review 一下 Review Agent 的输出

我每两周会扫一次 .hermes/memory/ 和 .hermes/skills/，看看 Review Agent 写的东西有没有跑偏。

如果发现有"流水账类""过度抽象类""拟人化类"的条目，我会手动删掉，并在 prompt 里加针对性的负面例子。

这种"人工反馈给 Review Agent"的循环，是让它越来越准的关键。Hermes 设计上其实留了这个口子 ——.hermes/review-feedback.md 文件可以直接放人工反馈，下一次 Review 会读到。

我的看法

研究完 Review Agent，我最大的感受是 ——自学习 Agent 真正的工程门槛，不是模型多大、上下文多长，而是"判断写入价值"的那套标准能不能立得住。

Memory / Skill 系统的容量越大、写入越频繁，这条门槛就越关键。

把所有信息都记下来 ≠ 学习。把没价值的信息记下来 = 给未来的自己埋污染。

Hermes 在这一层做了大量看似简单、但实际反直觉的设计：

▸复盘要单独跑一个 Agent，不能让执行 Agent 自己评价自己

▸写入率要低不要高，宁可错过不要乱记

▸偏好要有 2 次以上佐证才能写

▸Patch 优先于新建

▸留出"人工反馈给 Review Agent"的口子

这些设计单看每一条都不复杂，但加起来形成了一个自我修正的学习系统 —— 它不仅会学，还会"反思自己学得对不对"。

我觉得这才是真正的"自进化"含义 —— 不是越用越多，而是越用越准。

下一篇我们把这一章收个尾，把 Memory、Skill、Nudge、Review Agent 串起来，看看从一次任务到一次进化的完整链路是什么样子。

往期推荐

Multi-Agent Teams：让多个专家 Agent 像团队一样协作

AI Agent 是怎么"想一步做一步"的？拆解 ReAct 模式

从零开始：用 LangChain.js 构建你的第一个 Tool-Calling Agent

最后

点个在看支持我吧