Evaluator-Optimizer（评估器-优化器）

Evaluator-Optimizer（评估器-优化器） 是 Agentic System Patterns（智能体设计模式）中的一种工作流模式。核心结构是：一个 LLM（生成者）产出内容，另一个 LLM（评估器）提供评估和反馈，两者在循环中迭代，直到内容达到质量标准或迭代次数上限。

工作机制

flowchart LR
    In((输入)) --> Gen[LLM Generator]
    Gen -->|Solution| Eval[LLM Evaluator]
    Eval -->|"Rejected + Feedback"| Gen
    Eval -->|Accepted| Out((输出))

关键在于评估器和生成者是两个独立的 LLM 调用，而非同一模型的自我审查。这使评估器可以用不同的 prompt、不同的关注点，甚至不同的模型来审查生成内容。

何时适用

Anthropic 给出了两个判断标志：

LLM 的响应在人给出明确反馈后能被明显改进（说明改进空间存在）
LLM 本身能提供这样的反馈（说明评估器角色是可行的）

两者同时成立，这个模式才值得引入。如果人工反馈无法提升输出（任务本身已最优），或 LLM 无法有效评估（缺乏评估依据），循环只是在浪费 token。

典型用例（Anthropic 原文给出的示例）：

文学翻译：翻译者 LLM 可能未捕捉到的文化细节或语气微差，由评估器 LLM 逐条指出，翻译者再修订
复杂搜索：每轮搜索结束后，评估器 LLM 判断信息是否已够全面，或需要继续搜索哪些维度

与 Reflexion 的区别

Reflexion（反思）也有反馈循环，但机制不同：

维度	Evaluator-Optimizer	Reflexion
评估来源	独立的评估器 LLM	同一模型自我反思
记忆方式	反馈直接传入下轮 prompt	反思写入语言记忆层（情节记忆）
角色分工	生成者和评估器明确分离	单一 Agent 担任两个角色
偏差风险	评估器有独立视角，偏差较小	自我评估容易产生系统性偏见
失败处理	依赖程序退出条件	内置失败信号引导自我校正

Evaluator-Optimizer 更适合有清晰外部标准（翻译准确性、信息完整度）的场景；Reflexion 更适合试错密集型任务（代码调试、推理证明）。

造检分离：为什么需要两个 Agent

Addy Osmani 的表述最为简洁：“写代码的模型给自己的作业打分时太仁慈（way too nice grading its own homework）。” 它太了解自己的意图，容易把说服自己接受的错误带进验收。第二个 Agent——使用不同的系统 prompt，有时是不同的模型——能抓住第一个 Agent 说服自己接受的那些缺陷。

这一原则在 Loop Engineering（循环工程）中尤为重要：循环在你不在场时运行，一个你真正信任的 Verifier 是你敢走开的唯一理由。 生成者可以自称完成；独立 Verifier 不会放过它。

Evaluator-Optimizer 模式在 Anthropic 2024 年 12 月的工程博客《Building Effective Agents》中已有系统记录；2026 年它以"造检分离"等说法在 AI 工程圈大规模流行——术语是新的，模式早已存在。

工具实现

工具	实现方式
Codex	`.codex/agents/` 目录下的 TOML 文件，字段：`name`、`description`、`instructions`，可选 `model` 与 `reasoning_effort`；按需调用，多个子 Agent 并行，结果折叠回主回答
Claude Code	`.claude/agents/` 目录下的子 Agent 定义，支持 agent teams 在 Agent 之间传递工作

典型配置：安全审查者用强模型 + 高推理努力（reasoning_effort = high），探索者用快速只读的小模型。Sub-agents 消耗更多 token，应优先把"第二意见"预算花在真正影响质量的验收节点上。

与 Evals 的关系

Evaluator-Optimizer 是在线评估（运行时评估器参与任务执行本身）；Evals（评估）通常是离线评估（批量测试模型或系统的整体性能）。两者目的不同——Evaluator-Optimizer 是生产流程的一部分，Evals 是研发过程中的质量测量工具。

注意事项

退出条件必须明确：需要设置最大迭代次数或明确的"达标"判定逻辑，否则可能无限循环
评估器 prompt 决定质量上限：评估器能发现什么问题，决定了整个循环能改进到什么程度
成本翻倍：每次迭代包含生成 + 评估两次 LLM 调用；多轮迭代成本快速上升
改进可能收敛：同一个评估器 LLM 给同一类内容的反馈可能趋于重复，需要判断何时停止