23Multi-Agent 编排

L4P1

多个 agent 平级,协同完成一个任务。常见模式:

Orchestrator-Worker:一个 orchestrator agent 拆任务、派活、聚合结果;多个 worker 各做一部分。Anthropic 的 Computer Use demo 用过这个。

Pipeline:agent A → agent B → agent C,流水线。每个 agent 专精一阶段(planner → coder → reviewer)。

Mesh:agent 之间互相调用,无固定上下级。复杂、难调,生产少见。

通信:消息队列(SQS/Kafka)、共享文档(progress.md)、直接 API(agent-to-agent HTTP)。冲突解决:版本号 / 乐观锁 / 最终一致性。三个 agent 同时改一个文件 → 拆 file 边界或 lock。

注意:multi-agent 增加 token 成本 ~3 倍(每个 agent 都有自己的 system prompt + context)。Anthropic 自己的实测:multi-agent 不是默认选择,只在任务可清晰拆分 + 单 agent context 装不下时用。

速查
"3 个 agent 同时改一个文件怎么办?"——两个方向:(1) 任务拆分让 file 边界互斥,(2) 加 file-level lock + 顺序化执行。绝大多数情况选 (1),(2) 是 fallback。
2026-08 更新 · Multi-Agent 官方产品化

2026 年三家全部把 multi-agent 做成了产品:(1) Claude Code Agent Teams(2026-02 随 Opus 4.6):lead agent + teammates,各自独立 context window,mailbox 点对点通信 + 共享任务列表,可用 tmux 分屏观察;(2) Codex:subagents + 云端 best-of-N(同一任务多副本并行、择优);(3) Cursor:git worktree 隔离的并行 agents + Agents Window 编排界面(IDE 转型为编排平台)。

生产共识:并行研究/评审很稳,并行写代码要谨慎(写冲突);「任务可清晰拆分 + 单 agent context 装不下」才上 multi-agent 的判断依然成立——做错判断 token 成本 10 倍。三种形态的选择:sub-agent(主从委派)/ Agent Teams(平级协作)/ best-of-N(并行竞争),各答不同问题。