多 Agent 编排（Agent Orchestration）

一句话定义

多 Agent 编排（Agent Orchestration）：用一个协调层把一个大目标拆成若干子任务，派发给多个 AI Agent 并行执行，再把产出收拢、去冲突、交付的架构模式。

它要解决的不是「模型不够聪明」，而是两个工程问题：

1. 单个 Agent 串行跑太慢——一个跨 12 个文件的迁移，一条会话要跑两个小时；
2. 多个 Agent 并行又太累——你自己开 4 个会话，得手动拆活、分配文件、盯进度、手工缝合，Agentic Coding 里最烦的从来不是写代码，是协调。

编排就是把第 2 件事也交给机器。代价是三样东西会同步上涨：成本、集成复杂度、以及对 CI 的依赖。

为什么 2026 年这件事突然重要

三个前提在同一年同时成熟：

结果就是：并行能力不难，难的是谁来协调。 2026 下半年各家产品集中补的就是这一层——Claude Code 在 2026-09-17 把 Projects 重做成带 coordinator 的编排结构，Cursor 在 9-10 发布 Cursor Projects（协调 agent 派发数千 subagents 在云端并行）。

三种基本拓扑

1. Fan-out / Fan-in（扇出并行）

最常见的形态。协调器把同构任务复制多份，各 Agent 独立跑，最后汇总。

目标：把 checkout p75 延迟降下来
  ├─ Agent A：profile endpoint 1，提优化，开 PR
  ├─ Agent B：profile endpoint 2，提优化，开 PR
  └─ Agent C：profile endpoint 3，提优化，开 PR
        ↓
   协调器：跑测试、判优先级、告诉你哪个先合并

适用：子任务之间几乎不重叠（不同 endpoint、不同文件、不同仓库）。 风险：一旦重叠，冲突全部堆到合并阶段。

2. Pipeline（流水线）

任务有先后依赖，Agent 按阶段接力，每个阶段可能自己再并行。

需求 → 规划 Agent → 编码 Agent → 测试 Agent → 审查 Agent → PR

适用：步骤清晰、每步输入输出明确（如「读 PR → 定位问题 → 给评论」的自动化 代码审查）。 风险：上游一步跑偏，下游全部污染；错误会被放大而不是被纠正。

3. Coordinator-Worker（协调器-工作者）

2026 年产品化的主流形态，也是 Fan-out 的工程化版本：

• coordinator 不直接写代码，只做拆范围、派活、跟踪、审结果、汇总；
• worker 是完整执行单元，各自持有独立的代码副本 / 分支 / 上下文；
• worker 内部还可以再拆出 subagent、loop、workflow —— 并行可以嵌套多层。

Claude Code Projects 重构 用的正是这个结构：一个目标 + 连接的仓库 → coordinator 拆活 → 每个 thread 是一个跑在独立分支与仓库副本上的云端 session → 自动开 PR、跑测试 → 重合部分按普通 merge conflict 处理。

关键设计取舍：coordinator 不提前阻止多个 worker 碰同一处代码，只保证「工作有条理」。这意味着集成负载没有消失，只是被推到了 review 时刻。

五个核心组件

其中共享记忆是 2026 年真正的新增量。Claude Projects 的做法是把它下沉到项目级：某个 worker 学到的「发版挪到周五」「动 billing 前要先找谁」，会沉淀进项目记忆供后续 worker 复用。

但要清醒：共享记忆是项目级的，不是组织级的。 跨项目、跨仓库的规范仍然得靠 AGENTS.md 这类文件承载——记忆解决的是「重复解释」，不解决「规范统一下发」。

成本模型：并行度是第一参数

这是落地前最该算的账。以 Claude Code Projects 的口径为例：每个 thread 都是一个完整的 session，用量随并行线程数线性增长。

单会话：1× 用量
6 条并行 thread ≈ 6× 用量

可行的成本控制旋钮通常只有两个：

1. 并行度 —— 开几条；
2. 模型与 effort 档位 —— coordinator 与 worker 往往可以分别设置（coordinator 用便宜档做调度，worker 用贵档做执行，或反过来）。

实践建议：第一次上并行，压到 2-3 条先看消耗曲线，再决定放量。把并行数当并发连接数来管理，而不是当性能参数。

什么时候不该上编排

编排不是银弹，下面几种情况上了就是负债：

• 没有强 CI / 分支保护。冲突按普通 PR 处理意味着集成风险全部落到 review 阶段；没有自动化测试兜底，并行只会放大混乱。
• 任务本身就小。改 3 个文件的事情，拆活 + 合并的开销大于收益。
• 子任务高度耦合。所有人都要改同一个核心模块的场景，并行等于制造冲突。
• 没有可观测性。跑飞了不知道是哪条线程、哪一步出的问题——先有 trace（如 OpenTelemetry），再谈并行。
• 需要代码不出内网。当前主流编排都跑在厂商云端（Claude Projects 的本地执行官方只说 coming very soon）；有 air-gapped 要求的团队要看 Cursor Self-Hosted Machines 这类把执行留在自有机器的方案。

常见踩坑

• 把并行当性能参数：开 10 条不代表快 10 倍，往往只代表额度烧 10 倍 + 10 个待合并 PR。
• 忽略合并顺序：coordinator 给出的「哪些该先合并」是最有价值的输出之一，但仍然需要人来拍板。
• 共享记忆当规范系统用：它记不住你没让它经历过的事，团队规则仍要写文件。
• 让 coordinator 直接改代码：它一旦开始动手，就失去了「全局视角 + 不引入冲突」这个唯一优势。
• 不看用量页就放量：项目级用量是可查的，第一次用却很少有人先看。

与其它概念的关系

延伸阅读

• 概念：AI Agent / Agentic Coding / Context Engineering / MCP
• 工具：Claude Code / Cursor / Devin / Codex CLI
• 资讯：Claude Code Projects 重构：coordinator + 并行 thread / Anthropic RSI 报告：3 万 Agent 同时在线
• 方案：AGENTS.md 协议：让多个 AI 工具读同一份配置

本页由 AI 之家 编辑部整理。编排形态迭代很快，具体产品行为请以各工具官方公告为准；如发现与最新事实不一致，欢迎通过 反馈邮箱 反馈。