跳转到内容
Agent 教程库

反思、验证器与 Evaluator-Optimizer

模型写完一句“退款总额是 320 元”，再让它自己检查一遍，常常能发现漏项。但这不等于结果被证明了。

如果生成者和检查者看到同一份上下文、采用同一种模型，又没有外部标准，它们很可能共享同一个盲点。第一次把退款总额算错，第二次只会把同一个错误解释得更流畅。

所以这讲先把四种常被混称为“复核”的动作拆开：反思、批判、评价和验证。它们都会给反馈，证据强度却完全不同。

反思把失败带回下一轮，但不能自己当证据

Section titled “反思把失败带回下一轮，但不能自己当证据”

Reflexion 提出用语言反馈帮助 Agent 从失败尝试中改进。系统执行任务、接收评分或环境反馈，再生成一段反思，写入后续尝试的情景记忆。[1]

它的意义不是证明模型可以无限自我修正，而是把“失败之后学到什么”带回 Agent Loop，让下一次尝试不必从同一个坑开始。

典型流程是：

Actor 执行
-> Evaluator 给出结果
-> Reflection 总结失败原因
-> 下一次尝试读取反思

关键仍在 Evaluator。没有外部结果，Reflection 只是在评论自己的文本；它可以帮助发现疑点，却不能单独宣布任务完成。

先分清：这是建议，还是证明

Section titled “先分清：这是建议，还是证明”

先把四种反馈强度排个序。环境终态或可执行验证最强，然后是明确规则与可信外部事实，再是独立模型评价，最弱的是同一模型的自我反思。

这不是说模型评价没有用，而是不能让较弱的证据承担较强的结论。让模型打分可以帮助排序；要确认账是否真的退了，仍要读数据库或调用权威服务。

Self-reflection 是让同一个模型重新审视答案，找遗漏、冲突和改进点。它适合低成本发现明显问题，例如漏字段、结构不清、没有回答某个子问题，但不能独立证明事实正确。

Critique 由另一个 Prompt、模型或角色提出反对意见，可以关注政策、格式、安全或逻辑。相比自我反思，它增加了视角差异；如果底层模型和证据仍然相同，独立性依旧有限。

Evaluator 按照 Rubric、示例或指标给结果评分，可以是规则，也可以是模型裁判。它适合比较质量、筛选候选和生成反馈，但评分是否可信，取决于 Rubric、数据和裁判偏差。

Verifier 用可执行或外部事实检查明确命题，例如运行测试、查询数据库、验证 JSON Schema、重新读取订单状态。它的证明力通常最强，因为它不依赖生成者如何描述结果。

一个有用的反馈闭环，至少要有停下来的地方

Section titled “一个有用的反馈闭环，至少要有停下来的地方”

Anthropic 把 evaluator-optimizer 列为一种常见 Workflow：一个模型生成结果，另一个评估并给出反馈，循环到满足标准或达到限制。[2]

Anthropic Building Effective Agents

图 1：Anthropic 将 evaluator-optimizer 作为可组合工作流之一，而不是默认用于所有任务。来源见文末。

一个完整循环至少有五个部分：Generator 产生候选结果，Criteria 定义什么算好，Evaluator 判断差距并给具体反馈，Optimizer 根据反馈修改，Limits 限制轮次、预算和退化。

如果 Criteria 只有“更好”“更专业”，循环没有稳定方向。把标准拆成可观察项，例如引用是否存在、SQL 是否可执行、政策是否满足、输出是否包含必要字段，反馈才知道该往哪里推。

让 Maker 生成，让 Checker 拿事实说话

Section titled “让 Maker 生成，让 Checker 拿事实说话”

旧 Loop Engineering 稿件里有一条原则仍然值得保留：写代码的人不能只靠自己的总结宣布成功。

Maker 负责探索和生成，Checker 负责对照标准检查。分开有三层含义：Prompt 和角色分开，上下文与权限分开，最好连实现机制也分开。

例如 Coding Agent 可以修改代码，但 Verifier 只读取 Diff、运行固定测试、检查退出码。Verifier 不需要相信执行者的解释。

如果 Checker 仍然读取 Maker 提供的“测试已通过”摘要，那只是角色名称不同，证据并没有独立。最小的分工是：Maker 可以改，Checker 只读当前工件、运行固定检查并记录退出码。

模型裁判适合比较，不适合替环境作证

Section titled “模型裁判适合比较，不适合替环境作证”

很多质量无法写成简单规则，例如摘要是否覆盖关键风险、语气是否适合目标读者、两个解释哪个更清楚。

模型裁判适合这些场景，但要注意控制几类偏差。裁判可能偏好列表中靠前或靠后的答案，可以交换顺序重复评估；更长的回答可能看起来更完整，Rubric 应明确奖励相关性，而不是字数；模型可能偏好与自己表达风格相似的答案，可以使用不同模型或规则交叉检查；裁判只看最终文本，无法知道引用是否真实、工具是否执行，需要把可核对证据提供给裁判，或者直接使用外部验证器。

模型裁判是测量工具，不是客观真理。用它前先问清楚：这项质量能否被规则或环境直接验证？能的话，优先用可执行检查；不能时，再把 Rubric、样本和偏差控制写出来。

要看的不是“像不像成功”，而是环境有没有改变

Section titled “要看的不是“像不像成功”，而是环境有没有改变”

τ-bench 和后续 τ²-bench 把 Agent、用户、工具和领域规则放进交互环境，并检查数据库终态与政策遵守，而非只判断最后一句回复。[3]

τ²-bench GitHub 页面

图 2：τ²-bench 代表从文本评分走向 Tool-Agent-User 环境终态的评测路线。来源见文末。

假设客服 Agent 说：“已经为您办理退款。”

文本裁判可能认为语气清楚。环境检查却可能发现：订单仍然是 paid，或者 Agent 违反政策给不可退款订单动了账。

一个系统是否可靠，不能只看“答得像不像成功”，还要看现实是否成功。这也是环境型 Benchmark 有价值的地方：它把最终文本放回工具、用户和状态约束中检验。

让下一轮能动手：反馈要指出哪一处事实错了

Section titled “让下一轮能动手：反馈要指出哪一处事实错了”

无效反馈是：

答案不够好，请继续改进。

有效反馈要说清楚：

SQL 可以执行，但结果为 400；验收值是 320。
查询包含 status='refunded' 的订单。
下一次只允许修改 WHERE 条件，不改变数据表。

有效反馈包含失败的具体事实、预期标准、差距位置、下一轮允许修改的范围，以及是否需要新证据。

反馈越具体，Optimizer 越不需要重新猜问题。反过来，含糊的“再优化一下”会诱导它扩大改动范围，甚至把本来正确的部分一起改坏。

动手：运行一段能执行、但不该通过的 SQL

Section titled “动手：运行一段能执行、但不该通过的 SQL”

运行 verifier_loop.py。脚本会在内存 SQLite 中建立三笔订单：两笔已支付，一笔已退款。

第一次生成的 SQL 是：

select sum(amount) from orders;

它语法正确，可以执行，却把已退款的 80 元也算进去，结果是 400。独立 Verifier 知道业务验收值应为 320，因此拒绝通过。

第二次查询增加状态条件：

select sum(amount) from orders where status = 'paid';

执行结果为 320，验证通过。完整轨迹见 experiment-result.json。

别只看第二条 SQL 最终通过。这个实验给出了一条可复用的判断顺序：SQL 能否执行、结果是否符合业务标准、修正是否只发生在允许范围。

可以继续做一个小改动：把验收值或允许修改范围改错，再运行一次。若系统仍把结果宣布为成功，说明你的 Verifier 只是在走流程；若它明确拒绝，并能指出哪项证据不匹配，才算真的参与了决策。

“语法正确”与“任务正确”之间，正是 Verifier 的位置。

几种让反馈闭环越改越偏的情况

Section titled “几种让反馈闭环越改越偏的情况”

每轮都能找到新建议，却没有满足标准或停止上限，这叫无限修改。Generator 与 Evaluator 使用同一模型和证据，共同相信错误事实，这叫同源偏差。Optimizer 学会迎合评分器，而不是改善真实目标–例如堆关键词提高评分，却降低可读性–这叫 Reward Hacking。

系统展示了一个“检查步骤”，但检查只读取执行者的自述，或测试根本没有覆盖修改，这叫 Verifier Theater。测试通过以后源码又变化，旧证据仍被用来声明当前版本成功，这叫 Stale Evidence。错误反思被写入长期记忆，后续任务持续受影响，这叫 Feedback Pollution。

遇到这些情况，通常不是加一个“更严厉的 Critic”就能解决。把标准、版本、证据和停止规则写进系统，远比多一段批评提示词可靠。

选工具前，先说清你要验证哪一层

Section titled “选工具前，先说清你要验证哪一层”

Promptfoo 适合用声明式配置做 Prompt、RAG 和 Agent 回归测试、安全红队，并接入 CI。[4] Inspect AI 用 Dataset、Solver、Tool、Scorer 和 Log 组织可复现评测，适合研究和安全场景。[5] DSPy 把 LM 调用写成可优化模块，通过数据和指标搜索更好的指令、示例或程序参数。[6] OpenAI Evals 和 OpenEvals 提供评测结构和现成 Evaluator，适合建立数据集与回归基线。[7][8]

项目选择取决于你要评什么：组件、最终文本、完整轨迹，还是环境终态。别因为工具能打分，就把它当成所有任务的验收器。

提交一次 Agent 改动前，过一遍这几个问题

Section titled “提交一次 Agent 改动前，过一遍这几个问题”

成功标准能否被具体描述？是否优先使用可执行验证？模型裁判有没有 Rubric 和校准样本？Generator 与 Checker 是否共享偏差？反馈是否指出事实差距？每轮修改是否有范围？证据是否绑定当前版本？是否有最大修订次数？失败是否能转交人工？

收尾：反思负责修，验证负责放行

Section titled “收尾：反思负责修，验证负责放行”

反思可以改善候选答案，验证器才能约束完成声明。模型适合生成和解释，规则、环境和测试更适合证明；两者组合，才构成可靠的 Evaluator-Optimizer。

这里也有边界：没有稳定的成功标准、没有独立事实来源时，反馈循环只能提升表面质量，不能承诺真实正确。对高风险动作，应该把“未能验证”当成一个明确结果，交给人工或后续流程，而不是无限修改。

下一讲进入 Context Engineering。很多 Agent 看似推理失败，实际是输入里缺了当前事实、混入旧政策，或者同时暴露了太多无关工具。

资料与延伸阅读

Section titled “资料与延伸阅读”

本书关联阅读

继续沿着这本书往下读

返回本书目录
[[Agent 规划]][[Context Engineering]][[结构化输出与工具调用]][[Agent Memory]]

打开教材源码与可运行实验