Review Agent 机制深度解析（winty）¶

Ch04.077 Review Agent 机制深度解析（winty）¶

📊 Level ⭐⭐ | 17.9KB | entities/review-agent-deep-dive-winty.md

Review Agent 机制深度解析¶

来源：前端Q/winty（2026-05-18），评分 56；同系列有 Hermes Self-Improving Loop 详解（2026-05-12）覆盖四组件全貌

核心定位¶

Review Agent = Hermes 的"心智"。独立于执行 Agent 之外，专门负责复盘和判断什么值得沉淀为长期记忆。与执行 Agent 的本质区别：执行 Agent 有"已完成任务"的执念，Review Agent 没有。它只看快照，不看情绪。

为什么复盘必须独立（独立 Agent 设计）¶

两个根本问题¶

问题 1：自我评价偏正面 让 Agent 自己反思自己刚做的事，它几乎永远写"任务顺利完成、流程合理、结果符合预期"。这不是模型偏心，是 prompt 角色冲突——"执行者 + 评价者"两个角色一冲突，评价就被"我已经尽力了"压住。 问题 2：上下文挤占严重 执行任务的对话本来就长，再让模型在结尾加一段反思，token 直接翻倍。执行时 attention 聚焦"下一步做什么"，复盘要求从结果反推过程，两种思维模式在同一上下文切换，效果很差。

独立 Agent 的三新¶

执行 Agent 跑完，把整个 trajectory（任务轨迹）丢给 Review Agent。Review Agent 拿到的是全新的对话实例： ▸ 全新的 system prompt（专门写"你是一个复盘者"） ▸ 全新的上下文（只有任务轨迹，没有执行时的废话） ▸ 全新的判断标准（独有 / 高频 / 通用才记）对照实验结果：让同一个模型分别用"自我反思"和"独立 Review"两种方式复盘 100 次任务，独立 Review 写出来的 Memory/Skill 在后续任务中的命中率高出大概 3 倍。

Review Agent 一次复盘的 4 步流程¶

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

Review Agent 拿到的是一个完整的"任务轨迹"： ▸ 用户最初的需求是什么 ▸ Agent 调了哪些工具、参数是什么、返回了什么 ▸ 中间产生了哪些对话 ▸ 用户有没有打断或纠正 ▸ 最终任务成没成、用户的反馈是什么 Hermes 内部叫 session trace，是结构化的事件流，不是纯文本。Review Agent 拿到的是已经规整好的数据，省去了"从混乱对话里提取信息"这一步。

第 2 步：分类信息类型¶

拿到素材之后，Review Agent 第一件事是分类。这一轮里出现了哪些"可能值得记"的信息？是什么类型？ 4 类分类： ▸ 事实型：如"这个项目的数据库是 PostgreSQL" ▸ 偏好型：如"用户喜欢用 yarn 不用 npm" ▸ 流程型：如"发布到 npm 的 5 个步骤" ▸ 教训型：如"忘了 build 会发空包" 分类决定写到哪里——事实和偏好通常进 Memory，流程和教训通常进 Skill。如果跳过分类直接写，会发生"流程被塞进 Memory、事实被塞进 Skill"这种乱套。

第 3 步：判断写入价值（3 把尺子）¶

这是 Review Agent 最有"灵魂"的一步。不是所有分类出来的信息都值得记。 Review Agent 用 3 把尺子过滤： 尺子 1：独特性 Uniqueness 这条信息原本不在模型的"常识"范围内吗？ ✅ 应记："这个项目的部署机器在 ap-east-1"——项目特定信息，模型自己绝对不知道 ❌ 不记："JavaScript 是动态语言"——基础知识，每个 LLM 训练时都已经学过 尺子 2：重复性 Repeatability 以后还会反复出现吗？ ✅ 应记："每次发包都要 bump version"——高频出现、跨任务都用 ❌ 不记："今天网络偶发抖了一下"——一次性事件判断标准：这个信息在未来 10 次相似任务里，至少会被用到 3 次以上吗？ 尺子 3：通用性 Generality 是这一类任务的通法，还是只有这次有效？ ✅ 应记："npm publish 前必须 build"——所有 npm 发布的通用规则 ❌ 不记："今天只发了 1.0.3 这个特定版本"——单次执行细节，没有跨任务复用价值 只有同时通过 3 把尺子的信息，才会真正进入 Memory/Skill 文件。 源码里的 prompt 非常严格，反复强调"宁可错过，不要乱记"。这是 Hermes 设计哲学的体现——错过的信息以后还能补，错记的信息会污染整个 Memory/Skill 库。

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

通过筛选的信息，最后一步是决定： ▸ 写到 Memory 还是 Skill？ ▸ 写到全局（~/.hermes/）还是项目级（.hermes/）？ ▸ 是新建一条，还是 patch 已有的？ 关键设计点：优先 patch 而非新建。 如果已经有相关 Memory/Skill，Review Agent 会优先 patch 而不是新增。这避免了"同一个事实被记 5 遍、版本互相矛盾"的烂局面。整个 4 步走完，Review Agent 退出，等下一次被 Nudge 唤醒。

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

3 类典型失误（Review Agent 也会学歪）¶

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

错误示例：把一次完整的发布流程，抽象成 Skill 后变成"部署服务 → 验证 → 完成"这种全是 placeholder 的高级描述。听起来很通用，实际上下次执行时模型完全不知道每一步具体要敲什么命令。 修复方式： 限制 Skill 必须包含至少 3 行可执行命令。Hermes 在 prompt 里有一条硬约束叫 "steps must be reproducible without further inference"。

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

错误示例：Memory 里写"2026-04-30 14:23 用户运行了 ls 命令"。这种信息没有跨次复用价值，纯粹是日志，不是 Memory。 修复方式： 只记跨任务复用的事实，不记一次性事件。在 prompt 里加："如果这条信息只在今天这一次任务里有用，不要写入 Memory。"加完之后，流水账类条目少了一半。

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

错误示例：USER.md 里出现"用户喜欢周二下午写代码"。这是 Review Agent 把用户某次偶然的对话当成了稳定偏好。 修复方式： 偏好类信息必须有 2 次以上佐证才能写入。Hermes 里这叫 "two-strike rule"，单次事件不能升级成偏好。这 3 类失误的本质都是同一个问题：学习不等于记下一切，更不是猜测。 Review Agent 的 prompt 设计里有大量"反猜测"的提示词，比如"不要从单次行为推断长期偏好""不要把用户的礼貌用语当成需求"。这些都是踩过坑之后的工程沉淀。

实践观察¶

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

跑了一周的统计：Review Agent 被触发了 200 多次，最终真正写入 Memory 或 Skill 的不到 30 次。写入率大约 15%。很多人觉得这个比例太低，应该让 Review Agent 多记点。恰恰相反——写入率越低越说明它在认真过尺子。 写入率上 50%，库就会膨胀；上 80%，整个 Memory/Skill 就成了噪音库。

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

失败任务里包含的信息密度，往往是成功任务的 3 倍以上。成功了你只学到"这样能跑通"。失败了你学到"这样会出错、根本原因是什么、怎么排查、下次怎么避"。专门给失败信号设更高的优先级，让 Review Agent 优先复盘失败案例。

观察 3：Patch 比新建多得多¶

跑久了之后你会发现，Review Agent 大部分时候不是在新建 Memory/Skill，而是在 patch 已有的。这其实是好事——说明库里的核心条目越来越稳定，主要的进化是在现有条目上增量补充，而不是无限新增。

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

每两周扫一次 .hermes/memory/ 和 .hermes/skills/，看看 Review Agent 写的东西有没有跑偏。如果发现有"流水账类""过度抽象类""拟人化类"的条目，手动删掉，并在 prompt 里加针对性的负面例子。 .hermes/review-feedback.md 文件可以直接放人工反馈，下一次 Review 会读到。 这是让 Review Agent 越来越准的关键循环。

核心哲学¶

自学习 Agent 真正的工程门槛，不是模型多大、上下文多长，而是"判断写入价值"的那套标准能不能立得住。把所有信息都记下来 ≠ 学习。把没价值的信息记下来 = 给未来的自己埋污染。 Hermes 在这一层做了大量看似简单、但实际反直觉的设计： ▸ 复盘要单独跑一个 Agent，不能让执行 Agent 自己评价自己 ▸ 写入率要低不要高，宁可错过不要乱记 ▸ 偏好要有 2 次以上佐证才能写 ▸ Patch 优先于新建 ▸ 留出"人工反馈给 Review Agent"的口子这些设计单看每一条都不复杂，但加起来形成了一个自我修正的学习系统——它不仅会学，还会"反思自己学得对不对"。 真正的"自进化"含义——不是越用越多，而是越用越准。 → 原文存档

深度分析¶

独立 Agent 设计解决角色冲突问题 执行 Agent 和评价 Agent 的角色冲突导致自我评价偏正面。独立 Review Agent 通过全新的 system prompt、上下文和判断标准，实现了公正评价。对照实验证明独立 Review 的命中率高出 3 倍。
四步流程的结构化设计 Review Agent 的 4 步流程（收集→分类→判断价值→选择目标）形成了完整的信息处理流水线。session trace 结构化输入省去了从混乱对话提取信息的步骤。
3 把尺子作为核心过滤机制 独特性、重复性、通用性三重过滤是判断写入价值的关键。只有同时通过 3 把尺子的信息才进入 Memory/Skill，避免污染知识库。Prompt 反复强调"宁可错过，不要乱记"。
Patch 优先于新建的设计决策 Review Agent 优先 patch 已有的 Memory/Skill，避免了"同一个事实被记 5 遍、版本互相矛盾"的烂局面。这是避免知识库膨胀的关键机制。
三类失误揭示"反猜测"工程沉淀 过度抽象、流水账、拟人化三类失误说明"学习不等于记下一切，更不是猜测"。Prompt 中的"反猜测"设计（不要从单次行为推断长期偏好、不要把礼貌用语当成需求）是踩坑后的工程沉淀。

实践启示¶

分离执行与复盘: 不要让执行 Agent 自己复盘，启动独立的 Review Agent，用全新的上下文和 system prompt，确保评价公正性。
建立严格的写入标准: 应用 3 把尺子（独特性、重复性、通用性）评估信息价值，设定低写入率目标（15% 以下）来维持知识库质量。
优先 patch 而非新建: 处理已有条目时优先 patch，避免信息重复和版本矛盾，让核心条目越来越稳定。
优先复盘失败任务: 失败任务的信息密度是成功任务的 3 倍，给失败案例分配更高优先级，专门设更高的 Review 权重。
定期人工审查 Review Agent 输出: 每两周扫一次 .hermes/memory/ 和 .hermes/skills/，用 .hermes/review-feedback.md 反馈针对性问题，逐步优化复盘质量。