Agent 编排是指将多个 AI Agent（每个专注于不同子任务）按照特定协作模式组织起来，共同完成单个 Agent 无法高效处理的复杂任务。如果把单 Agent 比作一个全栈工程师，多 Agent 编排就是一个分工明确的团队——有人调研、有人编码、有人审查，效率和可靠性都大幅提升。
单 Agent 面临三个硬瓶颈：
| 瓶颈 | 具体表现 | 多 Agent 如何解决 |
|---|---|---|
| 上下文窗口 | 处理 500 页文档或大型代码库时，单次对话装不下所有信息 | 将文档拆给多个 Worker 并行处理，各自只关注自己的部分 |
| 串行执行 | 10 个独立子任务只能逐个完成，总耗时累加 | Fan-Out 模式将子任务并行分发，总耗时取最长而非累加 |
| 泛化 vs 专业化 | 一个通用 prompt 什么都会但什么都不精；安全审查 Agent 一定比通用 Agent 的审查质量高 | 每个 Agent 有自己专属的 System Prompt 和工具集，术业有专攻 |
此外还有可靠性——单 Agent 出错没有第二意见。多 Agent 系统可以让一个 Agent 审查另一个的输出，在高风险任务中将错误率降低一个数量级。
最基础、最常用的模式。一个 Orchestrator（编排器）负责接收总任务、拆解为子任务、分发给多个 Worker，最后汇总结果。
总任务 → Orchestrator 拆解 → Worker A（研究）+ Worker B（写作）+ Worker C（审查）
↓
Orchestrator 汇总 → 最终输出
适合场景：子任务可清晰拆分且分解逻辑已知。例如”研究某技术 → 写报告 → 审核事实性”天然拆成三个子任务。
每个 Worker 有自己专属的 System Prompt 和工具集。比如 Researcher 有搜索工具，Writer 有文档模板，Reviewer 有事实核查规则。
每个 Agent 的输出是下一个 Agent 的输入，像 Unix 管道一样串联。
Agent 1（调研）→ Agent 2（初稿）→ Agent 3（审校）→ Agent 4（发布）
适合场景：内容生产、数据清洗、多阶段验证等”转换链”。关键约束是每个环节的输出必须结构化，下一环节才能可靠消费。建议中间 Agent 使用 JSON Schema 约束输出格式。
典型代码结构：
def run_pipeline(input_text, stages):
current = input_text
for stage in stages:
response = client.messages.create(
model=stage["model"],
system=stage["system"],
messages=[{"role": "user", "content": current}]
)
current = response.content[0].text
return current
同一任务同时发给 N 个 Agent 并行执行，然后通过投票、合并或择优来汇总。
┌→ Agent 1（方案 A）
总任务 ────┼→ Agent 2（方案 B）──→ Judge Agent 评选最优 → 最终输出
└→ Agent 3（方案 C）
两种汇总策略：
适合场景：需要多样性或容错的任务——头脑风暴、代码生成（多个方案择优）、多源信息聚合。通过给不同 Worker 设置不同的 temperature 参数，可以产出风格各异的候选方案。
Agent A 产出，Agent B 批评，Agent A 修订，如此循环。这种对抗式协作能捕捉单 Agent 会遗漏的错误。
Agent A 产出 → Agent B 批评 → Agent A 修订 → Agent B 再审查 → 收敛输出
适合场景：高风险任务——法律文书审查、安全漏洞分析、事实核查。研究显示，辩论模式在数学推理和事实准确性任务上比单 Agent 的准确率提升 15-25%。
核心机制是让两个 Agent 持有不同的”角色立场”：一个负责生成（generator），一个负责批判（critic）。Critic 的 System Prompt 会明确要求它”找出所有可能的错误、遗漏和逻辑漏洞”。
一个 Router Agent 分析输入任务，根据任务类型将其路由到最合适的专家 Agent。
┌→ 安全专家（检测到安全类任务）
用户输入 → Router ┼→ 代码专家（检测到编程类任务）
└→ 通用 Agent（未匹配到专家）
适合场景：平台级应用，需要处理多种异构请求。如客服系统——退款问题路由到退款专家，技术问题路由到技术支持。
Router 本质上是一个轻量级分类器，可以用简单的关键词匹配实现，也可以用 LLM 做语义分类。关键设计原则：给 Router 一个 fallback 选项，无法分类的请求交给通用 Agent 处理，避免”查无此人”。
| 模式 | 并行度 | 延迟 | 可靠性 | 典型场景 |
|---|---|---|---|---|
| Orchestrator/Worker | 中（子任务间可并行） | 中 | 中 | 调研报告、项目规划 |
| Pipeline | 低（串行） | 高 | 低（单点失败全链中断） | 内容生产、数据清洗 |
| Fan-Out/Fan-In | 高 | 低（取最长子任务） | 高（多结果冗余） | 代码生成择优、多源聚合 |
| Peer Debate | 低（交替执行） | 高 | 最高 | 法律审查、安全审计 |
| Specialist Routing | 高（独立路由） | 低 | 中 | 客服系统、多领域平台 |
多 Agent 编排不是银弹——它引入了通信开销、更高的 token 成本和更复杂的调试难度。但如果你的任务确实触碰了单 Agent 的硬天花板（上下文不够、需要并行、需要多专业协作），这 5 种模式提供了经过验证的工程方案：
实际项目中，这些模式可以组合使用。例如，一个代码审查系统可以先用 Specialist Routing 分发到不同语言专家，每个专家内部用 Fan-Out 生成多个审查意见，最后用 Peer Debate 收敛到最终结论。
延伸阅读：