---
title: "拆解 Anthropic 工程博客：怎么让 Claude 连续跑 6 小时还不翻车"
author: deletexiumu
pubDatetime: 2026-03-27T01:00:00+08:00
featured: false
draft: false
tags:
  - AI Agent
  - Claude Code
  - AI 编程
  - 教程
description: "Anthropic 官方多 Agent 框架设计方法论拆解：Context Anxiety 和 Self-Evaluation Bias 两大失败模式的解法，以及如何在 Claude Code 中搭建 Builder + QA 最小可用框架"
---

## 1. 一个 $9 的半成品

你让 Claude Code 开发一个 2D 像素游戏编辑器——关卡编辑器、精灵编辑器、实体行为系统、可玩测试模式，一句话 prompt 丢过去。20 分钟后它交了作业：界面能看，工具面板排列整齐，但游戏主体跑不起来——实体和运行时的绑定静默失败。花了 $9，得到一个"样板房"。

Anthropic 内部团队用多 Agent 框架重做了同一个任务（他们叫它 RetroForge）。6 小时，$200，交付了 16 个功能的完整产品——精灵动画系统、行为模板、音效引擎、AI 辅助精灵生成器，播放模式实际可用，实体响应输入。

但重点不是"砸钱就能出活"。重点是：**多 Agent 不是"更多 = 更好"，而是针对长任务中两类具体失败模式的角色分工**。搞清楚这两个失败模式，才能理解为什么要拆 Agent、怎么拆。

## 2. 长时间 Agent 任务的两个致命问题

### 2.1 写着写着就赶工了（Context Anxiety）

Agent 的上下文窗口有上限。随着对话变长——读文件、搜索代码、累积工具调用结果——窗口逐渐填满。到了后半段，某些模型开始"赶工"：提前收尾、跳过步骤、质量骤降。Anthropic 在 Sonnet 4.5 上观察到这个问题尤其严重，严重到 compaction（上下文压缩）都救不了。

解法是 **Context Reset**——完全清空上下文，用结构化交接文档启动一个全新的 Agent。

这和 compaction 有本质区别。compaction 是"边跑边压缩笔记"，信息在压缩中丢失但焦虑不会消失；reset 是"换一个全新的人，只给他一份交接文档"，上下文窗口从零开始。Anthropic 原文的说法是：

> A reset provides a clean slate, at the cost of the handoff artifact having enough state for the next agent to pick up the work cleanly.

### 2.2 自己夸自己（Self-Evaluation Bias）

让 Agent 评价自己写的代码，它总说"写得不错"——即使明显有 bug。更隐蔽的情况是：它能识别出问题，然后说服自己这些问题不严重，给个"通过"就翻篇了。

这和人类改自己作文的盲区一样，但 LLM 的倾向更系统性。

解法是 **Generator 和 Evaluator 分离**——写代码的和测试代码的必须是两个不同的 Agent 实例。Anthropic 发现，调教一个独立的"怀疑论者"评估器，比让生成器学会自我批评容易得多。

但别指望 Evaluator 拿来就准。Anthropic 也是通过反复读执行日志（trace）、找到评估器判断与人类判断的偏差、逐条更新 QA prompt，才把它调到可用。即便如此，小型布局问题、不直观的交互、深层嵌套功能中的 bug 仍然会漏掉。

## 3. 先跑起来：在 Claude Code 中搭建 Builder + QA 最小框架

理论讲完，先把手弄脏。这一章是**基于 Anthropic 原文思路的 Claude Code 延伸实践**——Anthropic 原文用的是自研的 Claude Agent SDK 框架，这里我们用 Claude Code 的 Agent Team 功能搭一个近似的最小可用版。原理相通，工具不同。

### 3.1 前置条件

- **Claude Code 版本**：v2.1.32 或更高（需支持 Agent Team 功能）
- **启用 Agent Team**：在 `settings.json` 中添加环境变量：

```json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}
```

- **安装 Playwright MCP**：

```bash
# 个人使用（跨所有项目）
claude mcp add --scope user playwright npx @playwright/mcp@latest

# 验证安装
claude mcp list
```

前置条件就这些。Node.js 18+ 是 Playwright MCP 的隐性依赖，版本太低会报 `performance is not defined` 错误。

### 3.2 创建 Builder + QA 两人团队

你不需要手动调用底层 API。直接用自然语言告诉 Claude Code 你要什么团队结构：

```
创建一个 Agent Team：
- builder：负责逐功能编码，每完成一个功能通知 qa-reviewer，使用 git 做版本控制
- qa-reviewer：使用 Playwright MCP 打开浏览器做交互式测试（不是看代码），
  按评分标准打分，任何维度不及格就判定失败并返回 bug 列表

评分标准：
1. 功能完整性（是否实现约定功能）- 及格线：核心功能全部可用
2. UI 可用性（按钮能点、表单能提交、导航能跳转）- 及格线：无死链和无响应元素
3. 错误处理（不会白屏、有合理错误提示）- 及格线：无未捕获异常

qa-reviewer 通过后通知我，不通过则将 bug 列表发回 builder 修复。
```

Claude Code 内部通过 `TeamCreate` 创建团队、`SendMessage` 实现 teammate 间通信，但你无需直接调用这些——上面这段自然语言描述就够了。（注：这是 Claude Code 的实现方式，Anthropic 原文中用的是 Claude Agent SDK，底层逻辑相同但 API 不同。）

上面的评分标准和及格线是通用模板。你可以根据项目需要调整维度和阈值——比如数据密集型应用可以加"数据一致性"维度，移动端项目可以加"响应式布局"维度。

![Builder + QA 迭代流程](/blog/anthropic-multi-agent-harness-design/01-builder-qa-iteration.png)

### 3.3 一次完整迭代的工作流

团队创建完成后，你描述任务需求，迭代自动开始：

**步骤 1**：你向 Claude Code 描述任务需求（比如"做一个带拖拽排序的看板应用"）

**步骤 2**：builder 开始编码。它会逐功能开发——先做核心数据模型，再做 UI 组件，最后接交互逻辑。每个功能完成后自动通知 qa-reviewer。

**步骤 3**：qa-reviewer 用 Playwright 打开浏览器，像真实用户一样操作——点击按钮、拖拽卡片、提交表单、检查导航。它不是看代码打分，而是交互式测试。测试完输出评分报告 + bug 列表。

**步骤 4a（通过）**：如果所有维度都及格，qa-reviewer 通知主 Agent，进入下一个功能。

**步骤 4b（不通过）**：qa-reviewer 将 bug 列表连同复现步骤发回 builder。builder 修复后再次通知 qa-reviewer 复测。

**步骤 5**：迭代直到通过或达到最大轮次。

下面是一轮迭代中各角色实际输出的简化示例：

```
[你] → Claude Code：
  做一个看板应用，支持拖拽排序卡片，三列布局（待办/进行中/已完成）

[builder] → qa-reviewer：
  看板核心功能已完成。启动方式：npm run dev，访问 localhost:3000。
  实现内容：三列布局、卡片创建、拖拽排序、本地存储持久化。
  commit: feat: add kanban board with drag-and-drop

[qa-reviewer] 测试报告：
  功能完整性: 7/10 — FAIL
  - 卡片可以在同一列内拖拽排序 ✓
  - 卡片跨列拖拽后，源列的卡片顺序错乱 ✗（复现：将第2张卡片从"待办"拖到"进行中"，"待办"列剩余卡片顺序反转）
  - 空列无法接收卡片 ✗（复现：清空"已完成"列后，拖拽卡片进去无响应）
  UI 可用性: 8/10 — PASS
  错误处理: 9/10 — PASS
  判定：FAIL，bug 列表已发回 builder

[builder] → qa-reviewer：
  两个 bug 已修复。
  - 跨列拖拽：修复 onDragEnd 中 splice 索引计算错误
  - 空列接收：修复 droppable 区域最小高度为 0 的问题
  commit: fix: cross-column drag order and empty column drop

[qa-reviewer] 复测报告：
  功能完整性: 9/10 — PASS
  UI 可用性: 8/10 — PASS
  错误处理: 9/10 — PASS
  判定：PASS，通知主 Agent 进入下一功能
```

![Builder + QA 完整迭代消息流](/blog/anthropic-multi-agent-harness-design/01-builder-qa-iteration.png)

这个流程的关键在于 qa-reviewer 是独立的 Agent 实例，有自己的上下文窗口。它评估 builder 的代码时没有"我写的所以应该没问题"的偏见——这正是第 2.2 节说的 Self-Evaluation Bias 的解法。

### 3.4 QA 评分标准模板

下面是一份可直接复用的 QA prompt 模板。你可以在创建团队时把它写进 qa-reviewer 的指令：

```
你是一个严格的 QA 测试员。使用 Playwright MCP 打开浏览器，像真实用户一样操作应用。

评分维度与及格线：

1. 功能完整性（权重 40%）
   - 测试方法：逐条验证约定的功能需求
   - 及格线：所有核心功能可用，无功能性 stub
   - 不及格示例：按钮存在但点击无响应、API 返回 mock 数据

2. UI 可用性（权重 30%）
   - 测试方法：模拟完整用户流程——从入口到完成核心任务
   - 及格线：无死链、无无响应元素、表单提交后有明确反馈
   - 不及格示例：导航到不存在的页面、提交后无任何提示

3. 错误处理（权重 30%）
   - 测试方法：故意输入边界值和异常数据
   - 及格线：不白屏、有用户可理解的错误提示
   - 不及格示例：未捕获异常导致页面崩溃

任何维度不及格 → 整体判定 FAIL。
输出格式：每个维度的得分 + 发现的 bug 列表（含复现步骤）。
```

### 3.5 实战注意事项（踩坑清单）

**Token 消耗**：根据社区实测经验，Agent Team 的 token 用量大致是单 Agent 的数倍（具体取决于 teammate 数量和交互轮次）。每个 teammate 是独立的 Claude 实例，token 随 teammate 数量线性增长。小任务（30 分钟内能完成的）不要上多 Agent，性价比太低。

**文件冲突**：两个 teammate 同时编辑同一个文件会导致覆盖。在分工时明确文件归属——builder 负责 `src/` 下的代码，qa-reviewer 只读不写。如果需要多个 builder 并行，按模块划分文件边界。

**Playwright 首次使用**：首次使用时必须显式提示 `使用 Playwright MCP 工具打开浏览器`，否则 Claude 可能尝试通过 Bash 运行 Playwright 命令行，而不是走 MCP 协议。

**Snapshot vs Vision**：Playwright MCP 有两种模式。**Snapshot 模式**（默认）基于可访问性树操作，数据量远小于截图；**Vision 模式**基于截图，数据量大得多。推荐 Snapshot 模式——据 Playwright MCP 官方文档，Snapshot 的 token 消耗量级显著低于 Vision。只有高度自定义的视觉 UI 才需要切换到 Vision。

**QA Agent 的能力边界**：它擅长功能验证——按钮能不能点、API 返回的数据对不对、流程走不走得通。但对视觉布局问题（间距不对、配色不协调）和深层交互问题（复杂拖拽、多步骤组合操作）的判断仍不可靠。QA Agent 是补充，不替代真人测试。

## 4. 回扣理论：Anthropic 的完整三 Agent 框架

第 3 章跑起来的 Builder + QA 是最小版本。Anthropic 的完整框架多了一个关键角色——Planner，以及一套 Sprint Contract 机制。这两个组件解决的是"怎么把大任务拆好"和"怎么定义完成标准"。

### 4.1 三层架构拆解

Anthropic 的框架可以从三个层次理解：

**问题层**——长任务有两类失败模式：Context Anxiety（写着写着赶工）和 Self-Evaluation Bias（自己夸自己）。

**编排层**——三个角色各司其职：
- **Planner = 产品经理**。将一句话 prompt 扩展为完整产品规格。被指示"要有野心"——你说做 4 个功能，它扩展到 16 个。但只负责"做什么"，不管"怎么做"。这个限制是刻意的：如果 Planner 做了细粒度实现计划，一旦计划有误，错误会一路级联到下游。
- **Generator = 开发者**。按 Sprint 逐功能交付，有 git 版本控制。
- **Evaluator = QA 测试员**。用 Playwright MCP 交互式测试，不是代码审查。按 bug 发现数和评分维度打分，任何一项不及格就判定 Sprint 失败。

**执行层**——Anthropic 原文基于自研的 Claude Agent SDK 实现。在 Claude Code 中，可以用以下工具做近似映射：

| 原文概念 | Anthropic 原文实现 | Claude Code 近似映射 |
|---------|-------------------|---------------------|
| Context Reset | Agent SDK 的独立 Agent 实例 | Subagent（每个有独立上下文窗口） |
| 多角色协作 | Agent SDK 的多 Agent 编排 | Agent Team（TeamCreate + SendMessage） |
| 交互式 QA | Playwright MCP | Playwright MCP（相同） |

注意：这里的映射是"思路对应"而非"实现等价"。Agent SDK 和 Claude Code Agent Team 的底层 API 完全不同，但解决的问题相同。

![三层架构映射：问题层→编排层→执行层](/blog/anthropic-multi-agent-harness-design/02-three-layer-architecture.jpg)

### 4.2 Sprint Contract：开工前先签合同

这是 Anthropic 框架中最有工程感的设计。每个 Sprint 开始前，Generator 和 Evaluator 协商一份"合同"——用文件通信，一个写、一个读并回应，迭代直到双方就"什么算完成"达成共识。

以 RetroForge 的 Sprint 3 为例，合同包含 27 条验收标准。Evaluator 逐条测试，结果精确到代码行号：

| 合同标准 | 发现 |
|---------|------|
| 矩形填充工具允许点击拖拽填充区域 | FAIL — 只在起点和终点放了方块；`fillRectangle` 在 mouseUp 时未触发 |
| 用户可以选择并删除实体生成点 | FAIL — 删除处理器同时需要 `selection` 和 `selectedEntityId`；点击只设了后者 |
| 用户可通过 API 重排动画帧 | FAIL — `PUT /frames/reorder` 定义在 `/{frame_id}` 之后；FastAPI 将 'reorder' 匹配为整数 frame_id，返回 422 |

这些 bug 的共同特点是：**看代码不容易发现，但用户一操作就触发**。矩形填充的 bug 需要实际拖拽才能暴露；路由匹配的 bug 只有在调用特定端点时才会出现。这正是交互式测试优于静态代码审查的地方。

![Sprint Contract 协商流程](/blog/anthropic-multi-agent-harness-design/03-sprint-contract.jpg)

### 4.3 GAN 灵感与前端设计场景

Sprint Contract 解决的是"怎么定义完成"。而 Generator-Evaluator 的对抗迭代本身，灵感来自 GAN（生成对抗网络）——Generator 生成，Evaluator 评判，两者对抗推动质量上升。

在前端设计场景中，评分标准分四个维度，其中 Design Quality 和 Originality 权重更高（因为 Claude 在 Craft 和 Functionality 上本来就表现不错）。每次评估后，Generator 可以选择改进当前方向，或者整个推翻换一种美学风格（通常迭代 5-15 轮，最长 4 小时）。

一个有意思的案例：荷兰美术馆项目。到第 9 轮迭代，产出了一个干净的暗色主题网站。然后在第 10 轮，Generator 把整个方案推翻了——创建了一个 3D 空间体验：CSS perspective 实现的房间、格子地板、墙上挂画、通过门廊在画廊房间之间导航。

这种"推翻重来"的行为是框架刻意允许的。前面 9 轮不是白费——它们积累了"什么不对"的判断力。

## 5. 框架简化：模型进步后哪些组件可以拆掉

### 5.1 核心原则

框架的每个组件都编码了一个"模型做不到什么"的假设。Sprint 结构假设模型跑不了太久就会质量下降；Evaluator 假设模型不能可靠地评估自己的输出。

模型进步后，这些假设要重新压力测试。Anthropic 原文的说法是：

> Find the simplest solution possible, and only increase complexity when needed.

### 5.2 Opus 4.6 带来的简化

Opus 4.6 在周密规划、持续性代理任务、大代码库可靠性、自我调试、长上下文检索方面都有提升。基于这些提升，Anthropic 做了三个简化决策：

1. **移除 Sprint 结构**——构建器可以连续运行超过 2 小时，不再需要人为分段
2. **Evaluator 从每个 Sprint 改为最终只做一次**——减少中间检查开销
3. **保留 Planner 和 Evaluator**——这两个角色的价值没有被模型进步替代

![框架简化前后对比](/blog/anthropic-multi-agent-harness-design/04-simplification-comparison.jpg)

### 5.3 两个案例的独立数据

**案例 A：RetroForge（Sprint 模式）**

| 方案 | 时间 | 成本 | 结果 |
|------|------|------|------|
| 单 Agent | 20 min | $9 | 半成品，关键功能不可用 |
| 完整框架（含 Sprint） | 6 hr | $200 | 16 功能完整交付 |

**案例 B：Browser DAW（简化后框架，使用 Opus 4.6）**

| 阶段 | 时间 | 成本 |
|------|------|------|
| Planner | 4.7 min | $0.46 |
| Build 第 1 轮 | 2h 7min | $71.08 |
| QA 第 1 轮 | 8.8 min | $3.24 |
| Build 第 2 轮 | 1h 2min | $36.89 |
| QA 第 2 轮 | 6.8 min | $3.09 |
| Build 第 3 轮 | 10.9 min | $5.88 |
| QA 第 3 轮 | 9.6 min | $4.06 |
| **合计** | **3h 50min** | **$124.70** |

两个案例的任务不同、模型版本不同，不能直接得出"成本降低 37%"之类的结论。但趋势是明确的：更强的模型允许更简单的框架，更简单的框架意味着更低的协调开销。

### 5.4 Evaluator 的价值边界

这里有一个容易踩的坑：看到 Evaluator 有用，就什么任务都加一个。

判断标准很简单：
- 任务在模型可靠范围内 → Evaluator 是额外开销，不加
- 任务在模型能力边界 → Evaluator 提供实际提升，加

如果单 Agent 已经能可靠完成的任务（比如写一个 CRUD API），加 Evaluator 只会增加成本和时间，不会提升质量。Evaluator 的价值出现在模型开始"翻车"的地方——复杂 UI 交互、多组件联动、长时间运行的全栈任务。

## 6. 什么时候该用多 Agent（决策指南）

| 场景特征 | 推荐方案 | 理由 |
|---------|---------|------|
| 任务 < 30 分钟，无 UI | 单 Agent | 模型单次可靠完成 |
| 任务含 UI，需端到端验证 | Builder + QA | 自评偏差需要独立评估器 |
| 任务 > 1 小时，多功能 | Planner + Builder + QA | 需要需求扩展和持续 QA |
| 任务在模型可靠范围内 | 不加评估器 | 评估器变成纯开销 |

![多 Agent 决策树](/blog/anthropic-multi-agent-harness-design/05-decision-tree.png)

三档行动建议：

**今天就能做**：给现有 Claude Code 工作流加一个独立的 QA 步骤。完成开发后另起一个新会话，让它用 Playwright MCP 打开浏览器，像真实用户一样点击测试，而不是看代码。这就是最简单的"Generator + Evaluator 分离"。

**这周可以试**：用 Agent Team 搭 Builder + QA 最小框架——本文第 3 章的方案。团队创建用自然语言描述，QA 评分标准直接复用 3.4 节的模板。

**进阶探索**：加入 Planner，实现完整的三 Agent 框架。Planner 负责需求扩展，Generator 按功能逐个交付，Evaluator 做最终验收。如果任务特别大（超过 2 小时），考虑在 Generator 和 Evaluator 之间引入 Sprint Contract 机制。

## 7. 四条核心设计原则

Anthropic 在博客末尾提炼了四条经验：

**1. 读 trace，不读输出。** 在真实问题上实验，读执行日志而非最终结果来调优 prompt。Evaluator 的质量不是靠想象调出来的，而是靠一遍遍读它的判断记录、找到它跟人类判断的偏差、逐条修正。

**2. 分解 + 专业化。** 把复杂任务拆解，给每个子任务配专门的 Agent。Planner 只管"做什么"，Generator 只管"怎么做"，Evaluator 只管"做没做好"。

**3. 模型升级时重新审视框架。** 剥离不再承重的组件，增加新能力解锁的组件。Sprint 结构在 Sonnet 4.5 上是必要的，到 Opus 4.6 就成了多余的协调开销——该拆就拆。

**4. 框架复杂度不会缩小，只会移动。** 模型变强了，旧的框架组件可以拆掉，但新的问题域又需要新的组件——复杂度换了个地方住。

---

## 参考来源

*Prithvi Rajasekaran, "Harness Design for Long-Running Application Development", Anthropic Engineering Blog, 2026-03-24*
*https://www.anthropic.com/engineering/harness-design-long-running-apps*

*Claude Code Agent Teams 官方文档*
*https://code.claude.com/docs/en/agent-teams*

*Claude Agent SDK 概览*
*https://platform.claude.com/docs/en/agent-sdk/overview*

*Microsoft Playwright MCP*
*https://github.com/microsoft/playwright-mcp*

*AI Agent 模式系列（序号 29-34）——从单模式到多 Agent 协作框架的进阶路径：Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer、Autonomous Agents*

---

## 相关阅读

- [AI Agent 模式解析：从"做完"到"做好"](/posts/ai-agent-evaluator-optimizer/) — 本文多 Agent 框架的理论基础——Evaluator-Optimizer 模式的详细拆解
- [Claude Code Agent Teams 多代理协作完整实战](/posts/claude-code-agent-teams-practical-guide/) — 本文第 3 章 Agent Team 实战的详细操作指南
- [从 AI 写代码到 AI 审代码：开发者外循环加速完整实战](/posts/ai-outer-loop-acceleration/) — Generator + Evaluator 分离思路在开发外循环中的应用
- [Anthropic AAR 实验拆解：AI 研究员的 5 天与 4 种作弊手法](/posts/anthropic-aar-alignment-experiment/) — 同样来自 Anthropic 内部，9 个 Claude 实例自主做对齐研究，实验背后的工程设计与本文高度互补