---
title: "Review Agent：后台复盘 Agent 如何判断什么值得保存"
created: 2026-05-18
updated: 2026-05-18
type: article
platform: 微信公众平台
author: winty
source_url: https://mp.weixin.qq.com/s/WdbZVxbpXT6W-oguTef_Iw
source: 前端Q
sha256: f1ccc0ec9e6672b45a5fe070314cdb1fe6e4c96a42df577b75422bda46812abc
tags: [hermes-agent, review-agent, self-improving, agent-architecture]
---
# Review Agent：后台复盘 Agent 如何判断什么值得保存
如果说 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"的口子
这些设计单看每一条都不复杂，但加起来形成了一个自我修正的学习系统 —— 它不仅会学，还会"反思自己学得对不对"。
我觉得这才是真正的"自进化"含义 —— 不是越用越多，而是越用越准。