---
title: 'AI Agent 模式解析：从"做完"到"做好"'
author: deletexiumu
pubDatetime: 2026-03-15T17:30:00+08:00
featured: false
draft: false
tags:
  - AI Agent
  - Claude Code
description: "Building Effective Agents 系列第五篇：Evaluator-Optimizer 评估-优化模式。一个 AI 写、另一个 AI 审，循环迭代直到质量达标——从单次输出走向迭代质量保障。含 tech-article-creator 开源案例、Claude Code Review 分析和设计指南。"
---

*Building Effective Agents 模式解析系列（5/6）*

---

## 真实场景引入

你让 AI 写一篇技术文章。初稿读起来"像那么回事"，但仔细一看——数据来源不可追溯、技术术语前后不一致、结构头重脚轻。你给了修改意见，AI 改了，但又引入了新问题。来回三轮，你比自己写还累。

问题出在哪？你同时承担了两个角色：评审者和修改者的协调人。每一轮你都要通读全文、逐字批改、再验收结果。

换一种做法：把"写"和"审"拆给两个 AI。一个专门写，一个专门挑毛病——审完给出具体修改意见（不是笼统的"不太好"，而是"第三段的数据缺出处，建议补上论文链接"），写的那个改完再提交审查，循环直到审查通过。你从"逐字批改"变成了"最终拍板"。

回顾一下系列脉络：Chaining 解决"按什么顺序干"，Routing 解决"谁来干"，Parallelization 解决"怎么同时干"，Orchestrator-Workers 解决"不知道要干啥时怎么办"。前四种模式解决的是**把事做成**，Evaluator-Optimizer 解决的是**把事做好**。

---

## 什么是 Evaluator-Optimizer

Anthropic 在 [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) 中的定义：

> In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.

一个 LLM 生成响应，另一个 LLM 提供评估和反馈，形成循环。

### 核心机制：生成-评估-反馈循环

![E-O 核心循环：输入 → 生成者 → 评估者 → 通过则输出，不通过则反馈回传循环](/blog/ai-agent-evaluator-optimizer/01-eo-core-loop.png)

这个模式有两个角色和一条循环：

- **Generator / Optimizer（生成者/优化者）**：根据任务要求生成输出。首次调用是生成，收到反馈后的调用是优化——同一个角色，两种状态
- **Evaluator（评估者）**：对输出进行评估，输出"通过/不通过 + 具体反馈"
- **循环**：不通过时，反馈回传给 Optimizer，附带修改方向；Optimizer 据此修改后重新提交
- **终止条件**：评估通过 / 达到最大迭代次数 / token 预算耗尽

评估结果可以有不同粒度，从简到繁：

| 形式 | 示例 | 适用场景 |
|------|------|---------|
| **二元型** | PASS / FAIL | 格式检查、语法验证 |
| **三态型** | PASS / NEEDS_IMPROVEMENT / FAIL | Anthropic Cookbook 和 AWS 常用，比二元多了"方向感" |
| **评分型** | 0-100 分 + 阈值 | 灵活但需要明确的 Rubric（评分标准），否则分数无意义 |
| **结构化反馈** | `{dimension, severity, issue, suggestion}` | 信息最丰富，适合复杂任务 |

### 与其他模式的关键区别

三个轴上的差异：

**关注点不同。** O-W 解决"怎么拆任务"（分工），E-O 解决"怎么反复提质"（质量）。O-W 的编排者管分工，E-O 的评估者管质量——两个正交维度。

**反馈深度不同。** Chaining 中的 Gate 是单次检查点——通过或不通过，不带修改方向。E-O 是带具体反馈的闭环：评估者必须说清楚哪里不好、怎么改。

**可以类比 TDD，但不止于 TDD。** 先定义"什么是好的"（评估标准），再迭代达标。但 E-O 比 TDD 更灵活——评估标准可以是语义层面的（"这段读起来像 AI 写的"），不限于测试用例能覆盖的范畴。

### 适用信号

Anthropic 原文给出两个判断条件：

1. LLM 的输出在人类给出反馈后能**明显改善**
2. LLM **本身能够**提供这种反馈

两个都满足，E-O 才有价值。原文举的例子是文学翻译（初稿可能遗漏细微语义，评估者给出修改建议）和复杂搜索（多轮搜索和分析，评估者判断信息是否充分）。

### 五种模式对比

| 维度 | Chaining | Routing | Parallelization | O-W | E-O |
|------|----------|---------|-----------------|-----|-----|
| 核心问题 | 按什么顺序 | 谁来干 | 怎么同时干 | 怎么拆任务 | 怎么做好 |
| 反馈机制 | 无（线性） | 无（分流） | 无（预定义） | 单次汇总（非迭代） | 评估者闭环迭代 |
| 迭代性 | 无 | 无 | 无 | 可选 | 核心特征 |
| 典型类比 | 流水线 | 分诊台 | 施工队 | 项目经理 | 质检循环 |

---

## 核心案例：技术文章创作管线——Evaluator-Optimizer 的生产实现

选这个案例不是因为它最酷，而是因为它最"可感知"——你正在读的这篇文章本身就经历了这个循环。这是一个基于 Claude Code 的 [Skill 机制](https://code.claude.com/docs/en/skills)构建的多 Agent 写作管线（[源码已开源](https://github.com/deletexiumu/AgentSkills-Hub/tree/main/skills/public/tech-article-creator)），下面的数据基于实际运行日志。管线的写作+内部评审阶段，是一个完整的 Evaluator-Optimizer 实现。

![技术文章创作管线 E-O 架构：Writer 写手 → 技术评审 + 内容评审并行 → 反馈循环 → 外部模型评审 → 终稿](/blog/ai-agent-evaluator-optimizer/03-article-pipeline.png)

### E-O 的三层体现

**第一层：角色分离。** Writer（Optimizer）和 Reviewer（Evaluator）是不同的 Agent，有不同的 prompt 和关注点。Writer 按大纲和素材写作；Reviewer 按评审维度打分——事实准确性、AI 痕迹、可读性、版本差异化。关键在于：写的人不审自己写的东西。

**第二层：结构化反馈。** Reviewer 不是给个"不行"就完了，而是输出问题列表 + 严重度分级（高/中/低）+ 具体修改建议。比如不是"数据有问题"，而是"第三段引用了 CCR 论文的 F1 数据，但原文是 28.6% 而非 29%，建议核实后修正"。这就是 E-O 与简单 Gate 的区别——反馈必须可执行。

**第三层：明确的终止条件。** 所有 Reviewer 都认为"无高/中严重度问题"时通过。不是"差不多了"这种模糊判断，而是有具体的通过标准（无高/中严重度问题）。明确的退出标准防止无限循环。

### 为什么不能自己审自己

直觉上觉得"让 AI 再看一遍"就行了。数据说的不是这回事。

Cross-Context Review（CCR，跨上下文审查）论文做了一个严格的实验：30 个产物、150 个注入错误、360 次审查。结果：

| 审查方式 | F1 | 说明 |
|---------|-----|------|
| 跨上下文审查（CCR） | **28.6%** | 全新会话，只看最终产物 |
| 同会话自审（SR） | 24.6% | 带完整历史 |
| 同会话审两遍（SR2） | 21.7% | 看两遍反而更差 |

跨上下文审查（CCR）的 F1 显著高于同会话自审（SR），而审两遍（SR2）反而更差——重复审查不仅没有发现更多问题，反而引入了更多误报。多看几遍不管用，管用的是**换一个干净的上下文**。

这就是为什么要分离评估者和生成者：不同角色（甚至不同模型）有不同的盲区，分开才能互补。

### 多评估者并行：E-O + Parallelization 组合

这条管线用了两个评估者并行审查同一篇文章：

```yaml
reviewers:
  - role: "tech-reviewer"
    focus: "事实准确性、代码可执行性、数据口径一致、脱敏彻底"
  - role: "content-reviewer"
    focus: "AI痕迹检测、可读性、版本差异化、读者行动路径"
```

tech-reviewer 聚焦事实和代码，content-reviewer 聚焦可读性和 AI 痕迹。两个评估者独立给出意见——一个评估者的盲区可能被另一个覆盖。这比单一评估者更鲁棒，和学术论文的多审稿人制度是同一个道理。

### 外部评审层：评估者的评估者

内部 Agent Team 评审通过后，还有一层外部模型评审——将终稿发给不同的 LLM（如 Codex、Gemini），用相同的评审维度再审一遍。修改后附"已修改项"清单再发评审，方便 Reviewer 聚焦变更点，降低评审成本。

这种"评估者的评估者"结构在高质量要求场景下很常见。评估者本身也有偏见，用不同模型交叉评审能捕获单模型的系统性盲区。

### 实战观察

基于这条管线的经验数据（非严格实验，标注为实践观察）：

- **典型迭代次数**：2-3 轮。首轮通过率低，第二轮通过率显著提升。超过 3 轮通常说明初始 prompt 或素材有问题，不是迭代能解决的
- **最常见的评审发现**：AI 痕迹（排比对称、"值得注意的是"这类套话）、数据来源不可追溯、版本间差异化不足
- **成本结构**：写作占 token 大头，评审相对便宜——评估者不需要生成长文，只需判断和反馈

---

## 辅助案例

### Claude Code Review——Evaluator-heavy 的人机协作变体

Anthropic 2026 年 3 月发布的 Code Review（目前处于研究预览阶段），是一个多 Agent 并行审查 PR 的系统。但要先明确定位：这不是纯自动闭环 E-O。评审器（Evaluator）是自动的，优化器（Optimizer）通常是开发者或另一个 coding agent——E-O 的两端可以独立演进。

架构分三阶段：多个 Agent 并行扫描 diff → 验证过滤误报 → 严重性排序后以行级评论发布。默认只审正确性（逻辑错误、安全漏洞、边界用例、回归），不审风格和测试覆盖率。

实测数据（Anthropic 官方）：

| 指标 | 数据 |
|------|------|
| 大 PR（>1,000行）至少发现一个问题 | **84%**（平均 7.5 个） |
| 误报率 | **<1%** |
| 实质性评论占比提升 | 16% → **54%** |
| 平均成本 | $15-25/次 |

两个真实案例说明了 LLM 评估器的语义理解能力：一个一行代码的改动被标记为"关键问题"——它会破坏该服务的认证机制；TrueNAS 的 ZFS 加密重构中发现了一个类型不匹配问题，会在每次同步时静默擦除加密密钥缓存。这些都是传统 Linter（静态代码检查工具）基于固定规则的模式匹配无法捕获的。

从 E-O 视角看：评估器端（LLM reviewer）已经非常成熟，优化器端（人类/agent 修改）仍需人机配合。这说明 E-O 模式的两端不必同步成熟——先把评估做好，优化可以逐步自动化。

### 程序化评估——"写代码 → 跑测试 → 看报错 → 改代码"

最朴素的 Evaluator-Optimizer：LLM 写代码，测试框架当评估者，测试结果当反馈。评估者不一定是 LLM——程序化评估（测试通过/失败 + 错误信息）更快、更便宜、更确定。

一个基于 ClickHouse 的 SQL 自纠正实现是典型案例。它的评估器是数据库本身，分层验证：

| 检查 | 方法 | 成本 |
|------|------|------|
| 语法验证 | `EXPLAIN AST` | ~10ms，无数据扫描 |
| 执行验证 | `SELECT ... LIMIT 1` | ~50ms，最小成本 |
| 错误分类 | 错误码匹配 | 识别具体问题类型 |

关键设计：**定向修复优于整段重生成**。评估器告诉优化器"错在哪、怎么修、什么是对的"，优化器只改有问题的部分。"Fixing syntax is cheaper than regenerating entire queries。"

Claude Code 的日常工作循环本质上就是这个模式：写 → 跑 → 看结果 → 改。任何"做了之后验证"的流程都是 E-O 的雏形。这说明 E-O 可能是最自然的 Agent 模式之一——你甚至可能已经在用了，只是没叫这个名字。

---

## 怎么设计好的 Evaluator-Optimizer

### 评估者设计

**评估标准（Rubric）是核心。** 没有明确标准的评估是随机打分。Rubric 应包含三个要素：维度（评什么）、等级（好/中/差的定义）、权重（哪些维度更重要）。Anthropic 在 Demystifying Evals 中建议："从 20-50 个真实失败案例中提取评估标准"——比凭空设计 Rubric 更接地气。

**反馈必须可执行。** 不能只说"不好"，要说"哪里不好、怎么改"。结构化输出是关键：`{dimension, severity, issue, suggestion}`。前面核心案例中 Reviewer 的输出就是这个结构——维度、严重度、具体问题、修改建议，缺一不可。

**评估者与生成者用不同模型。** 避免"自己审自己"的盲区。多项 LLM-as-Judge 研究发现了显著的自我偏好偏差——当 LLM 充当评委时，它倾向于给自己生成的文本打更高分。更深层的原因是模型对自身风格的文本"更熟悉"，会系统性地高估其质量。实践建议：生成用一个模型，评估用另一个——跨模型评估能捕获单模型的系统性偏见。

**多评估者策略。** 不同评估者关注不同维度，独立评估后汇总。Panel of LLMs（多模型组合评审）可有效缓解单一评估者的偏见——用 2-3 个不同的评委，取多数票或平均分。

### 评估器的三种类型

从 Anthropic 的 Demystifying Evals 延伸，评估器不是只有一种：

| 类型 | 优势 | 劣势 | 成本 |
|------|------|------|------|
| **程序化评估器** | 快速、确定、可复现（如前面 ClickHouse 案例） | 脆弱、缺乏语义理解 | 最低 |
| **模型评估器** | 灵活、能处理开放任务 | 非确定性、有偏见 | 中等 |
| **人工评估器** | 金标准质量 | 昂贵且慢 | 最高 |

选择原则：**能程序化就程序化，需要语义判断用模型，高风险才动用人工。**

### 迭代控制

**最大迭代次数必须设硬上限。** 通常 3-5 轮。超过上限说明问题不在迭代，而在初始 prompt 或任务定义——继续迭代只会浪费 token。

**收敛检测。** 如果连续两轮评分没有提升，提前终止。继续迭代不仅浪费成本，可能越改越差——过拟合评估者的偏好。

**每轮聚焦变更。** 评估者在后续轮次应重点检查"上次反馈是否被正确采纳"，而非全文重新评估。发送"已修改项"清单给评估者，降低评估成本，也让反馈更聚焦。

### 成本控制三板斧

**程序化评估优先。** 能用代码检查的不要用 LLM。ClickHouse SQL 自纠正的语法检查 ~10ms、测试执行 ~50ms，比 LLM 评估便宜几个数量级。低成本评估器的替代路线也在成熟——据 Galileo 宣称，其 Luna-2 专用评估模型相比 GPT-4 as judge 成本降低 97%（二手博客数据，仅供参考量级）。

**分层验证。** 先过便宜的程序化检查（格式、语法、长度），通过后再用 LLM 做语义评估。Claude Code Review 的成本在 $15-25/次（含多 agent 并行评审），如果不做前置过滤，纯 LLM 评估的成本会更高。

**定向修复优于整段重生成。** 评估者的反馈应指向具体位置和修改方向，生成者只改有问题的部分。这个原则在所有 E-O 实现中都适用——不管是改代码、改文章还是改 SQL。

**只在质量改善可测量时使用 E-O。** 这是 Anthropic 原文的建议。如果无法量化"好了多少"，就不知道该不该继续迭代，E-O 循环也就失去了意义。

### 常见反模式

- **无限循环**：评估者标准模糊，每轮都能挑出新问题，永远无法通过
- **评估者太宽松**：总是通过，E-O 退化为单次生成，失去迭代价值
- **反馈不可执行**：评估者说"整体质量不够好"但没有具体修改方向——生成者只能盲猜
- **过度迭代**：质量在第 2 轮已经够好，但强制跑满 5 轮——浪费 token，可能越改越差

---

## 适用场景与模式选择

### 适合 E-O 的场景

- 输出质量是首要约束（内容创作、翻译、代码生成）
- 有明确的评估标准（测试套件、评分 Rubric、合规检查）
- LLM 输出在反馈后能显著改善（Anthropic 的两个适用信号）

### 不适合 E-O 的场景

- 无法定义"什么是好的" → 评估者没有标准，循环无意义
- 首次生成已足够好 → 单次调用更划算
- 延迟敏感场景 → 每轮迭代增加延迟，实时系统慎用
- 评估本身比生成更难 → 评估者不可靠，循环不收敛

### 模式选择决策树（更新版，含全部 5 个模式）

![五模式选择决策树：需要迭代改进质量则选 E-O，子任务固定选 Chaining 或 Parallelization，动态分解选 O-W，分流选 Routing](/blog/ai-agent-evaluator-optimizer/02-decision-tree.png)

```
任务需要迭代改进质量？
  ├─ 是 → 有明确评估标准？
  │         ├─ 是 → Evaluator-Optimizer
  │         └─ 否 → 先定义标准，再决定
  └─ 否 → 子任务已知且固定？
            ├─ 是 → 需要按顺序执行？
            │         ├─ 是 → Chaining
            │         └─ 否 → Parallelization
            └─ 否 → 需要动态分解？
                      ├─ 是 → Orchestrator-Workers
                      └─ 否 → Routing
```

### 与其他模式的组合

**E-O + Parallelization**——最常见的组合。多个评估者并行审查同一输出，各自独立给出意见。前面核心案例中 tech-reviewer + content-reviewer 的并行评审就是这个组合。

**E-O + O-W**——编排者动态分解任务，每个工人内部用 E-O 迭代提质。Agent Teams 中 writer-reviewer 的循环就是 O-W 框架内嵌套的 E-O。

**E-O + Chaining**——Chain 的某个步骤内嵌 E-O 循环。比如在多阶段工作流中，plan-checker 反复验证计划质量，通过后再进入下一阶段。

核心判断标准：**输出质量是否是首要约束？** 是 → 加 E-O 层。**能否测量质量改善？** 能 → 值得迭代；不能 → 不要迭代。

---

## 结尾

这是 Building Effective Agents 模式解析系列的第五篇。

前四篇的模式各有分工：Chaining 是流水线，Routing 是分诊台，Parallelization 是施工队，Orchestrator-Workers 是项目经理。它们解决的是"怎么把事做成"。Evaluator-Optimizer 加了一层：**做完之后自己检查、自己改进——从单次输出走向迭代质量保障。**

E-O 的本质是一个简单的信念：第一次做对很难，但如果有明确的标准和具体的反馈，第二次一定比第一次好。

下一步可以试试：找一个你对 AI 输出质量不满意的场景（写邮件、翻译、生成代码），把"写"和"审"拆成两步——先让 AI 生成，再新开一个对话让另一个 AI（或同一个 AI 的全新会话）按你定义的 3-5 条标准逐项打分，把具体问题和修改建议喂回去改。两轮下来，你会直观感受到 E-O 循环的效果。

下一篇是系列收官：Autonomous Agents（自主代理）。

---

*原文参考：[Anthropic - Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)*

*核心案例：[tech-article-creator skill 开源仓库](https://github.com/deletexiumu/AgentSkills-Hub/tree/main/skills/public/tech-article-creator)*

*学术数据：[Cross-Context Review: Improving LLM Output Quality by Separating Production and Review Sessions (arXiv 2603.12123)](https://arxiv.org/abs/2603.12123)*

*LLM-as-Judge 偏差研究：[Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge](https://llm-judge-bias.github.io/)*

*案例来源：[Claude Code Review 官方博客](https://claude.com/blog/code-review)*

*案例来源：[ClickHouse SQL 自纠正系统 - DEV Community](https://dev.to/clayroach/building-self-correcting-llm-systems-the-evaluator-optimizer-pattern-169p)*

*评估方法论：[Anthropic - Demystifying Evals for AI Agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)*

*Anthropic Cookbook 参考实现：[Evaluator-Optimizer Pattern](https://platform.claude.com/cookbook/patterns-agents-evaluator-optimizer)*

---

## 相关阅读

- [AI Agent 模式解析：Orchestrator-Workers 编排者-工人模式](/posts/ai-agent-pattern-orchestrator-workers/) — 系列上一篇，E-O 经常与 O-W 嵌套组合使用
- [AI Agent 模式解析：Parallelization 并行化](/posts/ai-agent-pattern-parallelization/) — E-O 最常见的组合模式，多评估者并行审查
- [AI Agent 模式解析：Prompt Chaining 提示链](/posts/prompt-chaining-agent-pattern/) — 系列第一篇，Chain 的 Gate 与 E-O 的反馈循环是关键区别