多 Agent 系统的协作模式：从单兵到军团
2025 年是单 Agent 成熟的一年，2026 年的主战场明显转向了多 Agent。但「多」不等于「强」——我见过太多团队把三个 Agent 串起来，效果还不如调教好的一个。多 Agent 系统的能力上限不取决于 Agent 数量，取决于协作结构的设计。这篇文章拆解四种主流协作模式、各自的适用边界，以及那个最大的暗坑。
为什么需要多 Agent
先回答前置问题：单 Agent 不够用吗？很多场景确实不够，原因有三。
上下文窗口是物理上限。 一个复杂任务（比如重构一个中型代码库）所需的上下文远超窗口容量，单 Agent 越往后跑，早期信息被挤出，质量塌方。拆成多个 Agent，每个只装自己需要的上下文，是对窗口限制的工程化绕行。
角色专注度。 同一个模型，给它「你是测试工程师，只挑毛病」的窄指令，比「你又写又测」的宽指令表现更好。注意力被指令聚焦了。这和人类组织分工的逻辑相同。
并行加速。 互不依赖的子任务（扫描十个模块找安全漏洞）天然适合并行,十个 Agent 同时跑就是十倍吞吐。
但这三个收益都有代价，代价就藏在协作模式里。
四种协作模式
模式一：Orchestrator-Worker（主从编排）。 一个主 Agent 负责理解任务、拆解、分发给 Worker、汇总结果。这是目前生产里最主流的模式，Claude 的 sub-agent、各家 Deep Research 产品都是这个结构。优点是控制流清晰、易调试；缺点是 Orchestrator 是单点——它拆错了任务，下面全白干。适用：任务可分解、子任务边界清晰的场景（研究、代码库分析、批量处理）。
模式二：Pipeline（流水线）。 Agent 按固定顺序接力：需求分析 → 编码 → 测试 → 审查。每个 Agent 的输出是下一个的输入。优点是质量门禁明确，每一环都可以独立优化和评测；缺点是错误会沿管道放大，且总延迟是各环节之和。适用：流程固定、每步产物可验证的场景（内容生产、代码 CI 流、数据 ETL）。
模式三：Debate（辩论/对抗）。 两个以上 Agent 持不同立场互相批驳，第三方裁决或收敛共识。研究表明对抗结构能显著降低单模型的「自信幻觉」。成本是 token 翻几倍。适用：高风险判断类任务——安全审查、方案评审、事实核查，不适用于产出型任务。
模式四：Swarm（群体投票）。 同一任务发给 N 个独立 Agent，对结果投票或聚合。本质是用冗余换可靠性，类似分布式系统的多数派。适用：答案可比较、正确性可投票的封闭性问题（分类、打分、数学题）；开放性产出（写一篇文档）没法投票，不适用。
实践中的组合拳通常是：Orchestrator 做骨架，关键节点插入 Debate 做质检，可并行处插 Swarm。
最大的暗坑：上下文割裂
多 Agent 系统第一大故障源不是模型能力，是信息在 Agent 之间传递时的损耗。
单 Agent 的所有决策共享同一份上下文；拆成多 Agent 后,每个 Worker 只看到 Orchestrator 转述的任务描述。转述必然有损：Worker A 在模块里发现的一个重要约束，Worker B 不知道；Orchestrator 汇总时把两个互相矛盾的结论拼在了一起，自己却看不出矛盾——因为支撑各自结论的证据都没传上来。
这就是为什么很多多 Agent 系统的产出「每一段都对，整体是错的」。
工程上的缓解手段，按性价比排序：
1. 共享黑板（Blackboard）：所有 Agent 读写同一份结构化状态
文件/数据库，关键发现必须落盘，而不是只存在于对话里
2. 任务描述带上下文契约：Orchestrator 分发任务时显式附带
「已知约束」「禁止假设」「输出 schema」三段
3. 汇总前做一致性检查：专设一个 Agent 校对各 Worker 结论
之间的冲突，冲突即打回重跑
4. 控制扇出深度：层级不超过两层，Agent 套 Agent 套 Agent
的转述损耗是指数级的
一个简化的 Orchestrator 骨架（基于消息而非框架，刻意展示裸逻辑）：
async def orchestrate(task: str) -> Report:
plan = await llm(PLANNER, task) # 拆解
board = Blackboard() # 共享黑板
results = await asyncio.gather(*[
run_worker(sub, board.snapshot()) # 带上下文契约分发
for sub in plan.subtasks
])
for r in results:
board.merge(r.findings) # 关键发现落盘
conflicts = await llm(CHECKER, board.dump()) # 一致性检查
if conflicts:
results += await rerun(conflicts, board) # 冲突打回
return await llm(SYNTHESIZER, board.dump()) # 基于黑板汇总
注意汇总（SYNTHESIZER）的输入是黑板而不是各 Worker 的原始对话——这是刻意的。让汇总者面对结构化的事实清单，而不是 N 段冗长转述，幻觉率会明显下降。
怎么评测一个多 Agent 系统
多 Agent 系统的评测比单 Agent 难，因为失败可能发生在任何一环，端到端指标好坏都说明不了原因。我们的做法是三层评测。
单元层：每个 Agent 独立评测。 给每个角色（规划、执行、检查、汇总）建立独立的评测集，固定输入测输出。Worker 的评测集最好直接从线上失败案例里攒——Orchestrator 拆出来的真实子任务，比手造的测试用例有效得多。
链路层：注入故障测鲁棒性。 刻意让某个 Worker 返回错误结论、超时、返回格式损坏的输出，观察系统是否能识别和恢复。多 Agent 系统和分布式系统一样，部分失败是常态而不是异常，没测过故障注入的系统等于没测过。
端到端层：人工评估抽样 + 配对对比。 终态产出用人工抽样打分，并且永远和单 Agent 基线做配对对比——同一批任务，单 Agent 调到最好 vs 多 Agent 系统，盲评。这一步经常给人泼冷水：相当比例的场景里，精心调优的单 Agent 能追平复杂的多 Agent 编排，而成本只有几分之一。这个对比实验做不做，决定了你的架构决策是基于证据还是基于时髦。
成本与可观测性
多 Agent 的 token 消耗通常是单 Agent 的 3~15 倍，上生产前必须算账：这个任务质量提升带来的价值，覆盖得了成本吗？我的粗规则：日常高频任务用单 Agent 调到极致；低频高价值任务（深度研究、全库审计、安全评审）才值得上多 Agent。
可观测性是另一个必须前置的投入。多 Agent 跑挂了，你需要知道是哪个 Agent、在哪一步、基于什么输入做错的。最低配置：每个 Agent 调用记录输入/输出/耗时/token 的 trace，全链路一个 trace id 串起来。OpenTelemetry 的 GenAI 语义约定已经够用，别等出了事故再补。
结语
多 Agent 系统在重演分布式系统的老路：单机不够了才分布式，然后一致性、可观测性、部分失败这些问题排着队找上门。判断标准也可以直接抄分布式那套——能单 Agent 解决的别拆；确实要拆，先设计信息流（谁知道什么、怎么同步），再设计控制流（谁指挥谁）。
我们自己的代码审查系统折腾了三轮，最后稳定在「Orchestrator + 黑板 + 一个一致性检查角色」这个不算花哨的结构上。中间试过五层 Agent 嵌套的版本，看 demo 很酷，上线一周就退回来了——出了问题没人说得清是哪一层错的。供参考。