反思、验证器与 Evaluator-Optimizer

让模型检查自己的答案，通常会有帮助。但“再想一遍”不是可靠性机制。

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

所以这一讲要分清四件事：反思、批判、评价和验证。

它们都在提供反馈，证据强度却完全不同。

一、Reflexion 做了什么

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

它的重要意义，不是证明模型可以永远自我修正，而是把“失败之后学到什么”放进 Agent Loop。

典型流程是：

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

关键在 Evaluator。没有外部结果，Reflection 只是在评论自己的文本。

二、四类反馈，不要混为一谈

1. Self-reflection

让同一个模型重新审视答案，找遗漏、冲突和改进点。

适合低成本发现明显问题，例如漏字段、结构不清、没有回答某个子问题。它不能独立证明事实正确。

2. Critique

由另一个 Prompt、模型或角色提出反对意见。Critic 可以关注政策、格式、安全或逻辑。

相比自我反思，它增加了视角差异；如果底层模型和证据仍然相同，独立性依旧有限。

3. Evaluator

按照 Rubric、示例或指标给结果评分。Evaluator 可以是规则，也可以是模型裁判。

它适合比较质量、筛选候选和生成反馈，但评分是否可信，取决于 Rubric、数据和裁判偏差。

4. Verifier

用可执行或外部事实检查明确命题，例如运行测试、查询数据库、验证 JSON Schema、重新读取订单状态。

Verifier 的证明力通常最强，因为它不依赖生成者如何描述结果。

四者可以组成一条优先级：

环境终态 / 可执行验证
> 明确规则与可信外部事实
> 独立模型评价
> 同一模型自我反思

这不是说模型评价没有用，而是不能让较弱证据承担较强结论。

三、Evaluator-Optimizer 怎样工作

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

Anthropic Building Effective Agents

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

一个完整循环至少有五个部分：

Generator：产生候选结果；
Criteria：定义什么算好；
Evaluator：判断差距并给具体反馈；
Optimizer：根据反馈修改；
Limits：限制轮次、预算和退化。

如果 Criteria 只有“更好”“更专业”，循环没有稳定方向。更好的标准应尽量拆成可观察项：引用是否存在、SQL 是否可执行、政策是否满足、输出是否包含必要字段。

四、Maker 与 Checker 为什么要分开

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

Maker 负责探索和生成，Checker 负责对照标准检查。分开有三层含义：

Prompt 和角色分开；
上下文与权限分开；
最好连实现机制也分开。

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

如果 Checker 仍然调用 Maker 提供的“测试已通过”摘要，那只是角色名称不同，证据没有独立。

五、模型裁判什么时候有用

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

模型裁判适合这些场景，但要控制四类偏差：

Position Bias

裁判可能偏好列表中靠前或靠后的答案。可以交换顺序重复评估。

Verbosity Bias

更长的回答可能看起来更完整。Rubric 应明确奖励相关性，而不是字数。

Self-preference

模型可能偏好与自己表达风格相似的答案。可以使用不同模型或规则交叉检查。

Evidence Blindness

裁判只看最终文本，无法知道引用是否真实、工具是否执行。需要把可核对证据提供给裁判，或者直接使用外部验证器。

模型裁判是测量工具，不是客观真理。

六、为什么真实环境 Benchmark 更重要

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

τ²-bench GitHub 页面

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

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

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

一个系统是否可靠，不能只看“答得像不像成功”，还要看现实是否成功。

七、反馈怎样写，才真的能修正

无效反馈：

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

有效反馈：

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

有效反馈包含：

失败的具体事实；
预期标准；
差距位置；
下一轮允许修改的范围；
是否需要新证据。

反馈越具体，Optimizer 越不需要重新猜问题。

八、真实实验：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 能否执行；
结果是否符合业务标准；
修正是否只发生在允许范围。

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

九、Evaluator-Optimizer 最常见的失败

1. 无限修改

每轮都能找到新建议，却没有满足标准或停止上限。

2. 同源偏差

Generator 与 Evaluator 使用同一模型和证据，共同相信错误事实。

3. Reward Hacking

Optimizer 学会迎合评分器，而不是改善真实目标。例如堆关键词提高评分，却降低可读性。

4. Verifier Theater

系统展示了一个“检查步骤”，但检查只读取执行者的自述，或测试根本没有覆盖修改。

5. Stale Evidence

测试通过以后源码又变化，旧证据仍被用来声明当前版本成功。

6. Feedback Pollution

错误反思被写入长期记忆，后续任务持续受影响。

解决办法不是增加一个“更严厉的 Critic”，而是让标准、版本、证据和停止规则进入系统。

十、项目应该怎样选

Promptfoo

适合用声明式配置做 Prompt、RAG 和 Agent 回归测试、安全红队，并接入 CI。[4]

Inspect AI

用 Dataset、Solver、Tool、Scorer 和 Log 组织可复现评测，适合研究和安全场景。[5]

DSPy

把 LM 调用写成可优化模块，通过数据和指标搜索更好的指令、示例或程序参数。[6]

OpenAI Evals / OpenEvals

提供评测结构和现成 Evaluator，适合建立数据集与回归基线。[7][8]

项目选择取决于你要评什么：组件、最终文本、完整轨迹，还是环境终态。

十一、一份反馈闭环检查表

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

十二、这一讲的结论

反思可以改善候选答案，验证器才能约束完成声明。

模型适合生成和解释，规则、环境和测试适合证明。两者组合，才形成可靠的 Evaluator-Optimizer。

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

参考资料

[1] Shinn et al., Reflexion. https://arxiv.org/abs/2303.11366

[2] Anthropic, Building Effective Agents. https://www.anthropic.com/engineering/building-effective-agents

[3] Sierra Research, τ²-bench. https://github.com/sierra-research/tau2-bench

[4] Promptfoo. https://github.com/promptfoo/promptfoo

[5] Inspect AI. https://github.com/UKGovernmentBEIS/inspect_ai

[6] DSPy. https://github.com/stanfordnlp/dspy

[7] OpenAI Evals. https://github.com/openai/evals

[8] OpenEvals. https://github.com/langchain-ai/openevals