---
title: "AI Agent 模式解析：让 AI 自己拆任务（Orchestrator-Workers）"
author: deletexiumu
pubDatetime: 2026-03-15T14:00:00+08:00
featured: false
draft: false
tags:
  - AI Agent
  - Claude Code
  - AI 编程
description: "Anthropic Building Effective Agents 系列第四篇：Orchestrator-Workers 编排者-工人模式。核心区别是子任务由 AI 动态决定而非预定义。通过 Claude Code Agent Teams、Devin Interactive Planning、OpenAI Codex 三个案例解析设计要点。"
---

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

---

## 真实场景引入

你给 Claude Code 一个需求："给这个项目加上用户认证系统"。它需要改多少文件？改哪些？每个文件改什么？你事先不知道，它也不知道——得先分析项目结构、评估影响范围，才能拆出具体任务。

上一篇讲的 Parallelization，子任务是人预先拆好的——前端写 UI、后端写 API、测试写用例，各干各的。但现实中大量任务没法预先拆。你只有一个笼统目标，具体要做几件事、每件事做什么，得"看情况"。

这就是 Orchestrator-Workers 的领地。

回顾一下系列脉络：Chaining 解决"按什么顺序干"，Routing 解决"谁来干"，Parallelization 解决"怎么同时干"，Orchestrator-Workers 解决的是——**不知道要干啥时怎么办**。

---

## 什么是 Orchestrator-Workers

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

> A central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.

一个中心 LLM 动态分解任务、委派给工人 LLM、并综合结果。

核心关键词是**动态**。Orchestrator-Workers 和 Parallelization 在拓扑结构上很像——都是 fan-out → 并行 → 聚合。但关键区别在于子任务从哪来：

![O-W 核心流程：编排者动态分解任务、分配工人、综合结果](/blog/ai-agent-pattern-orchestrator-workers/01-ow-core-flow.png)

- **Parallelization**：子任务**预定义**，写死在代码或配置里，每次执行都一样
- **Orchestrator-Workers**：子任务由编排者**根据输入动态决定**——数量不固定、内容不固定

### 两种形态

实际系统中的 Orchestrator-Workers 不止一种运作方式：

**经典单轮 O-W**：编排者一次性分解 → 工人并行执行 → 编排者综合结果。结构清晰，适合任务边界能在分解阶段就基本确定的场景。

**迭代式 O-W**：编排者分解 → 工人执行 → 编排者根据结果追加或调整子任务 → 新一轮工人执行。适合需要中间反馈的复杂场景——比如先派一个工人调研，根据调研结果再决定后续分工。

基于本文引用的案例来看，大多数生产系统是两者的混合。

### 编排者的三重职责

1. **分析**：理解任务，评估复杂度和所需资源
2. **分解**：将任务拆成可独立执行的子任务（数量和内容视输入而定）
3. **综合**：收集所有工人结果，合并为最终输出

Anthropic 原文给出的适用场景——编码产品（每次需要修改多个文件，哪些文件、改什么内容取决于具体任务）和搜索任务（从多个来源收集和分析信息）——都指向同一个特征：**子任务无法预测**。

### 四种模式对比

![四种模式拓扑对比：Chaining、Routing、Parallelization、O-W](/blog/ai-agent-pattern-orchestrator-workers/02-four-patterns-comparison.png)

| 维度 | Chaining | Routing | Parallelization | O-W |
|------|----------|---------|-----------------|-----|
| 子任务 | 固定步骤 | 固定路径 | 预定义并行 | 动态决定 |
| 决策点 | 无（线性） | 入口分类 | 无（预定义） | 编排者实时决策 |
| 灵活性 | 低 | 中 | 中 | 高 |
| 复杂度 | 低 | 低 | 中 | 高 |
| 典型类比 | 流水线 | 分诊台 | 施工队 | 项目经理 |

---

## 核心案例：Claude Code Agent Teams——编排者模式的混合实现

Agent Teams 不是经典 O-W 的教科书实现，而是一种**混合形态**。它的核心流程体现 O-W——Team Lead 动态分解任务、分配工人、综合结果——同时在通信模型上扩展了经典 O-W。如果你读过这个系列的第 20 篇 Agent Teams 实战，下面的分析会更好理解。

### 编排者模式的三层体现

**第一层：动态任务分解。** Team Lead 分析需求后，决定需要几个 Teammate、各自做什么。不同需求产生完全不同的任务拆分——"加认证系统"可能需要 4 个 Teammate（数据库、API、前端、测试），"重构数据库层"可能只需要 2 个（重构者 + 审查者）。这种"看了才知道要干什么"的特征，正是 O-W 区别于 Parallelization 的核心。

**第二层：工人专业化。** 每个 Teammate 有独立的上下文窗口和专属工具集。编排者根据任务性质分配角色——reviewer 只需要 Read/Grep，writer 需要 Write/Edit/Bash。可以为不同 Teammate 指定不同模型，实现"聪明编排者 + 经济型工人"的成本优化。

**第三层：结果综合与迭代。** 编排者收到工人结果后，可能触发新一轮任务。第 20 篇实战中的 5 阶段门控就是这种迭代式 O-W 的典型：Phase 1 架构设计完成后，Lead 根据架构文档解锁 Phase 2 的数据和后端开发；Phase 3 审查后发现问题，再让工人返工修复。计划随中间结果动态调整。

### 超越经典 O-W 的地方

经典 O-W 模式中，工人只向编排者汇报——所有信息必须经过编排者中转。Agent Teams 打破了这个约束：Teammate 之间可以通过 SendMessage 直接通信。

举个具体场景：reviewer 发现 writer 的代码有 API 不一致问题。经典 O-W 中，reviewer 要先报告给 Lead，Lead 再转达给 writer。Agent Teams 中，reviewer 直接给 writer 发消息说明问题——省掉了编排者中转这一跳，降低了编排者的上下文瓶颈。

这种"混合"设计说明：现实中的 O-W 实现很少是纯粹的。当工人之间有密切协作需求时，放松"工人不直接通信"的约束往往比严格遵守更实用。

### 与 Parallelization 的关键差异

同一个工具（Agent Teams）既可以用作 Parallelization，也可以用作 O-W，区别在于**谁决定任务拆分**。

第 31 篇的 Superset IDE 场景：用户预先拆好任务（前端 / 后端 / 测试），每个 Agent 各干各的——人决定拆分，这是 Parallelization。

第 20 篇的 Agent Teams 实战：Team Lead 分析需求后自行决定任务拆分，可能先派 Architect 做系统设计，根据设计结果再决定要派哪些开发角色——AI 决定拆分，这是 O-W。

### 实战经验与陷阱

以下基于第 20 篇实战的经验观察：

**编排者的上下文管理**是实际部署中最先遇到的瓶颈。所有工人结果都回到编排者，上下文窗口会迅速膨胀。实践中，让工人返回摘要而非完整输出是必要的——第 20 篇项目 6 个 Worker 产生了 20M+ token 消耗，其中大量 token 花在了 Lead 处理工人的冗长汇报上。

**任务粒度把控**需要实验。拆太粗则工人做不好（一个 Worker 同时负责前后端，质量显著下降），拆太细则协调开销吃掉收益（每个 Worker 只改一个函数，Lead 花更多时间协调依赖）。第 20 篇项目用了 6 人团队、每人 5-6 个任务，这是一次实战样本而非通用建议——Agent Teams 官方推荐 3-5 人作为起步规模。

**错误传播**是 O-W 特有的风险。如果编排者对项目理解有误，任务分解方向就是错的——与 Chaining 不同（Chain 只影响后续步骤），O-W 可能同时把所有工人带到错误方向上。第 20 篇实战中，Lead 一次性启动所有 Agent、跳过架构审查阶段，导致 API 前后端不一致——编排者犯的一个决策错误，级联影响了 3 个 Worker 的产出。

---

## 辅助案例：Devin Interactive Planning + OpenAI Codex

### Devin 2.0 的 Interactive Planning——人机协作的编排

Devin 接到任务后，几秒内完成两步：先用代码库索引快速评估（识别相关文件和初步发现），再构建包含代码引用的详细计划。

关键设计：**计划生成后不立即执行**。默认等待 30 秒用户反馈，无响应才自动继续；复杂任务可设置"等待我审批"。审批窗口内，用户可以修改计划、补充上下文、与 Devin 讨论替代方案。

从 O-W 视角看：Devin 是编排者，它动态分解的计划步骤就是子任务，执行层是工人。它的独特之处在于把编排者的"分析→分解"过程**暴露给用户**——让人类校准任务分解，降低编排者犯错的风险。这和第 20 篇 Agent Teams 中 Lead 自行决策形成对比：Agent Teams 的 Lead 是全权编排者，Devin 是"提案型编排者"。

**Fleet 模式**把 O-W 推向规模化：定义迁移 Playbook 后，多个 Devin 实例跨数百仓库并行执行——编排者负责定义任务模板，每个实例作为工人独立执行。同一份年度回顾中，Cognition 披露 Devin 整体 PR 合并率从 34% 提升到 67%（这是平台总体数据，非 Fleet 单项指标）。

背景补充：Cognition 在 2025 年经历了戏剧性的行业整合——OpenAI 收购 Windsurf 未遂后，Google 反向挖走了 Windsurf CEO，Cognition 随后收购了 Windsurf 剩余资产。最终 Cognition 在 2025 年 8-9 月完成 Series C，估值约 $102 亿（Cognition 官方博客），同时拥有 AI 编码 Agent（Devin）和 AI IDE（Windsurf）。

### OpenAI Codex——编排平台化

Codex App 被定位为"Agent 的指挥中心"（command center for agents），其多 Agent 能力让它可以充当编排层。

**Agent Loop** 是其编排核心：推理 → 工具调用 → 观察结果 → 推理。每一轮编排者动态决定下一步行动——是继续当前任务、生成新的子 Agent、还是结束循环。一个会话 turn 可以包含多次模型-工具迭代，直到助手消息标志终止。

**多 Agent 编排**：Codex 作为编排者（orchestrator），处理子 Agent 的生成、指令路由、结果等待和线程关闭。每个子 Agent 可以有不同的模型、指令和沙箱策略。架构支持内置角色分工——worker（实现/修复）、explorer（代码库探索，只读）、monitor（长时间运行的轮询任务）。

```
Root Session (orchestrator)
├── Agent Thread A (explorer, read-only)
├── Agent Thread B (reviewer, read-only)
└── Agent Thread C (worker, workspace-write)
```

**Traces** 提供了 O-W 的可观测性层。Codex 自动记录每个 prompt、工具调用和交接，多 Agent 运行完成后可打开 Traces 仪表板查看执行时间线、每个步骤的输入输出。这对生产级 O-W 至关重要——没有 trace 的编排者是黑盒，出问题时无法区分是编排者分解错误还是工人执行错误。

Codex 还在向事件驱动演进：云端触发式执行（如 GitHub push 后自动跑任务），编排者从交互式向自动化方向发展。

---

## 怎么设计好的编排者

### 任务分解策略

**自顶向下分解**：编排者一次性生成完整计划。Devin 的 Interactive Planning 就是这种风格——分析代码库后输出全部步骤。优点是全局视野好，缺点是初始信息不足时计划可能偏差。

**渐进式分解**：先做一步，根据结果决定下一步。Claude Code 的 Agent 模式——观察→思考→行动→观察循环——天然就是渐进式的。优点是适应性强，缺点是总延迟更高。

**混合模式**：先生成粗粒度计划，执行中根据反馈细化。在第 20 篇实战和 Devin 的 Fleet 模式中，都采用了这种策略。第 20 篇的 Agent Teams 实战就是混合模式：Lead 先制定 5 阶段门控计划，但每个阶段内部的具体任务分配是动态的。

选择原则：任务结构可预测 → 自顶向下；任务高度不确定 → 渐进式；大多数情况 → 混合。

### 编排者的关键设计决策

**上下文管理**。编排者需要保持全局视图，但不需要所有细节——向工人传递必要上下文，收回摘要而非原始输出。上下文窗口是编排者的硬约束，Agent Teams 官方建议团队规模 3-5 人、每人 5-6 个任务，就是基于这个约束的经验值。

**成本模型**。Stevens Online 提出的"聪明编排者 + 廉价工人"策略——编排者用高能力模型做决策，工人用低成本模型执行窄任务。Claude Code Agent Teams 支持为不同 Teammate 指定不同模型，可以直接实践这个策略。编排者（如 Opus）做全局规划和综合，工人（如 Sonnet 或 Haiku）做具体实现。

**容错与终止**。O-W 优于 Chaining 的核心优势在于错误恢复的灵活性——Chain 中一步失败只能重试或中断，O-W 中编排者可以把失败的子任务重新分配给另一个工人，或者根据失败原因调整分解方案。但灵活性也带来风险：编排者必须有明确的停止条件，否则容易陷入无限循环。三种常见策略：基于规则（所有子任务完成）、基于质量（验证通过）、基于资源（token 预算耗尽）。Hatchworks 的生产失败案例中就出现过没有终止条件的编排者反复重试的反模式。

**可观测性**。生产级 O-W 必须有 trace——当多个工人并行执行时，你需要知道每个子任务的输入、输出、耗时和状态。前面讲的 Codex Traces 就是典型实现：自动记录每个 prompt 和工具调用，出问题时能直接定位是编排者分解错误还是工人执行错误。

### 工人设计原则

每个工人应有明确边界：输入格式、输出格式、可用工具、超时限制。

**经典 O-W vs 协作型 O-W**：经典模式要求工人只与编排者通信，信息流清晰可控；协作型（如 Agent Teams）允许工人之间有限度的直接通信，降低编排者瓶颈但增加协调复杂度。选择取决于场景——如果工人间需要频繁交换细节信息（如 reviewer 和 writer 讨论具体代码行），协作型更高效；如果工人的任务完全独立，经典模式更简单可靠。

工人尽量保持无状态——编排者管理全局状态，工人只执行单次任务。Agent Teams 官方文档强调"Teammates 不继承 Lead 对话历史"，spawn prompt 要包含所有必要信息——这就是无状态工人设计的实践。

### 最小编排者模板

一个展示 O-W 核心循环的伪代码。与第 31 篇的并行模板对比：那个模板的子任务是写死的三个函数，这个模板的子任务由编排者动态生成。

```python
async def orchestrate(task: str, model: str = "YOUR_MODEL_ID") -> str:
    """编排者核心循环：分解 → 分配 → 收集 → 综合"""

    # 第一步：编排者分析任务，动态生成子任务列表
    subtasks = await call_llm(
        f"分析以下任务，拆解为可独立执行的子任务列表（JSON 数组）：\n{task}",
        model=model,
    )

    # 第二步：为每个子任务启动工人，并行执行
    worker_results = await asyncio.gather(
        *[call_llm(st, model="YOUR_WORKER_MODEL_ID") for st in subtasks],
        return_exceptions=True,
    )

    # 第三步：处理失败——重试或跳过
    for i, result in enumerate(worker_results):
        if isinstance(result, Exception):
            worker_results[i] = await call_llm(subtasks[i], model="YOUR_WORKER_MODEL_ID")

    # 第四步：编排者综合所有工人结果
    report = await call_llm(
        f"综合以下子任务结果，生成最终输出：\n{json.dumps(worker_results, ensure_ascii=False)}",
        model=model,
    )
    return report
```

几个要点：编排者和工人可以用不同模型（成本优化）；`subtasks` 的数量和内容完全由编排者根据输入决定——这就是 O-W 与 Parallelization 的本质区别；失败的工人单独重试，不影响其他工人。生产环境还需要加上超时、停止条件和 trace 记录。

---

## 适用场景与模式选择

### 适合 O-W 的场景

- **子任务不可预测**：代码修改（哪些文件、改什么内容取决于具体需求）、研究调研（调研方向取决于课题）、复杂文档生成
- **需要根据中间结果动态调整**：先调研再决定后续方向，先审查再决定是否返工
- **任务涉及多种专业技能的组合**：不同工人有不同能力（Architect 做设计、Data Engineer 做管道、QA 做测试）

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

- 子任务固定且可预定义 → 用 **Parallelization**（更简单、更可控）
- 任务是线性流水线 → 用 **Chaining**（更低开销）
- 只需分流到不同处理器 → 用 **Routing**（更轻量）
- 编排开销大于实际工作量——简单任务用 O-W 是杀鸡用牛刀

### 模式选择决策树

![模式选择决策树](/blog/ai-agent-pattern-orchestrator-workers/03-decision-tree.png)

```
子任务已知且固定？
  ├─ 是 → 需要按顺序执行？
  │         ├─ 是 → Chaining
  │         └─ 否 → Parallelization
  └─ 否 → 需要完全自主、长时间运行？
            ├─ 否 → Orchestrator-Workers（编排者控制全局）
            └─ 是 → Agents（Agent 自主决策，下一篇）
```

### 与其他模式的组合

**O-W + Parallelization**——最常见的组合。编排者动态分解后，独立子任务并行执行。Agent Teams 的 Phase 2（Data Engineer 和 Backend Engineer 并行开发）就是 O-W 框架内的 Parallelization。

**O-W + Routing**：编排者根据子任务类型路由到不同的专业工人集群。Codex 的内置角色体系（worker、explorer、monitor）就是路由到不同类型工人。

**O-W + Chaining**：编排者的整体流程是 Chain（分析→分解→执行→综合），内部每步可能触发新的 O-W 循环。第 20 篇的 5 阶段门控本质上就是这种结构。

核心判断标准：**子任务能否预先定义？** 能 → Parallelization；不能 → O-W。**需要多大自主权？** 有限自主（编排者控制全局）→ O-W；完全自主（Agent 自己决定一切）→ Agents。

---

## 结尾

这是 Building Effective Agents 模式解析系列的第四篇。前三篇的模式——流水线、分诊台、施工队——都假设你事先知道要干什么。Orchestrator-Workers 去掉了这个假设：**让 AI 自己决定要干什么、怎么分工，从预定义走向动态决策。**

下一步可以试试：找一个无法预先拆分的任务，先让 AI 出计划（"请分析这个任务需要做哪些事"），人工审批后再让它执行——这就是最小可行的 O-W 实践。

下一篇：当 AI 不只是分工，还要持续自主决策、做完后自己检查"做得好不好"、自己优化，会怎样？→ **Evaluator-Optimizer（评估者-优化者模式）**。

---

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

*核心案例：[Claude Code Agent Teams 官方文档](https://code.claude.com/docs/en/agent-teams)*

*案例来源：[Devin Interactive Planning](https://docs.devin.ai/work-with-devin/interactive-planning)*

*案例来源：[Devin 2025 年度性能回顾 - Cognition 官方博客](https://cognition.ai/blog/devin-annual-performance-review-2025)*

*案例来源：[OpenAI Codex 多 Agent 架构](https://developers.openai.com/codex/multi-agent/)*

*框架对比：[Arize AI - Orchestrator-Worker Agents 框架对比](https://arize.com/blog/orchestrator-worker-agents-a-practical-comparison-of-common-agent-frameworks/)*

*成本模型：[Stevens Online - Building Self-Healing AI](https://online.stevens.edu/blog/building-self-healing-ai-orchestrator-reflexion-patterns/)*

*背景参考：[Cognition 官方博客 - Devin 2.0](https://cognition.ai/blog/devin-2)*

*反模式参考：[Hatchworks - Multi-Agent Orchestration Patterns](https://www.hatchworks.com/blog/multi-agent-orchestration-patterns/)*

---

## 相关阅读

- [AI Agent 模式解析：让多个 AI 同时开工（Parallelization）](/posts/ai-agent-pattern-parallelization/) — 上一篇，O-W 的"前身"——子任务预定义时怎么并行
- [Claude Code Agent Teams 多代理协作完整实战](/posts/claude-code-agent-teams-practical-guide/) — 本文核心案例的完整实战教程
- [AI Agent 模式解析：Routing 路由分流](/posts/ai-agent-routing/) — 系列第二篇，任务分流到不同处理器