一个人干不了所有活
单个智能体再强，也有能力边界。它不可能同时是代码专家、财务分析师、法律顾问和设计师。于是多 Agent 协作成为自然选择——让不同专长的 Agent 各司其职，协同完成复杂任务。
听起来很美好，实战中却是一地鸡毛。
Medium 上有一篇被广泛引用的文章，标题就很直白：《Multi-Agent AI 的黑暗心理学：30 种能摧毁你整个系统的失败模式》。30 种可能是夸张了，但核心观点不虚——多 Agent 系统的复杂度不是线性增长，而是指数增长。2 个 Agent 的协调问题比 1 个 Agent 多不止一倍。
三种协作架构
先理清多 Agent 协作有哪几种模式，再分析各自的问题。
模式一：Orchestrator-Worker（中心调度）
一个"主管" Agent 负责理解任务、分解子任务、分派给专业 Worker Agent，最后汇总结果。
[Orchestrator] → 分派 → [代码 Agent]
→ 分派 → [财务 Agent]
→ 分派 → [设计 Agent]
← 汇总 ← 各 Agent 结果
优点：逻辑清晰、责任划分明确 缺点：Orchestrator 成为单点瓶颈——它既要理解全局，又要管理分发，还要处理冲突
模式二：Pipeline（流水线）
Agent 按照固定顺序串联执行，前一个的输出是后一个的输入。
[需求分析 Agent] → [设计 Agent] → [编码 Agent] → [测试 Agent] → [部署 Agent]
优点：简单、可预测 缺点：无反馈回路——如果测试 Agent 发现问题需要返回设计阶段，流水线很难回溯
模式三：Peer-to-Peer（对等协作）
Agent 之间通过消息传递自由协作，没有固定的"领导"。
[Agent A] ←→ [Agent B]
↕ ↕
[Agent C] ←→ [Agent D]
优点：灵活、适应性最强 缺点：最难控制——可能出现循环依赖、死锁、信息不一致
四大协调问题
问题一：信息孤岛
每个 Agent 只看到自己收到的任务和返回的结果，看不到其他 Agent 的推理过程和中间结论。
典型场景
代码 Agent：根据需求写了一个 API 端点，返回 JSON 格式
→ 它不知道设计 Agent 已经决定用 XML 格式
→ 两个 Agent 各自按自己的理解干活
→ 最终拼不到一块
根因
- 上下文不共享：每个 Agent 有独立的对话上下文，天然隔离
- Orchestrator 信息压缩：转发任务时只传了摘要，丢失了细节
- 缺少共享状态：没有一个所有 Agent 都能读写的公共信息空间
问题二：级联失败
一个 Agent 的错误顺着依赖链传播，污染整条管线。
传播路径
需求分析 Agent（幻觉了一个需求细节）
→ 设计 Agent 基于幻觉需求做设计
→ 编码 Agent 按幻觉设计写代码
→ 测试 Agent 测幻觉代码
→ 全线基于错误前提，但每步内部都"自洽"
单 Agent 模式下幻觉只能影响当前任务。多 Agent 模式下，幻觉从一个 Agent 流向全部下游——传播效率和破坏力远超单 Agent。
更严重的情况：错误"确认"
如果两个 Agent 独立犯相同类型的错误（比如都幻觉了某个不存在的 API），它们可能相互"确认"——A 说"XX API 存在"，B 也说"我用过 XX API"，互相强化错误信念。这在人类团队中也有类似现象（群体思维），但在 Agent 团队中更危险，因为没有人类的经验直觉来刹车。
问题三：责任归属不清
任务失败了，是哪个 Agent 的错？
用户：为什么生成的报告有问题？
Ochestrator：我按照标准流程分派了任务
代码 Agent：我按照需求规格开发的
数据 Agent：我提供的是数据库里的原始数据
设计 Agent：我做的 UI 不是内容逻辑
人人有责 = 无人负责。在调试时你不知道该查看哪个 Agent 的日志、优化哪个 Agent 的 prompt。
根因
- 没有端到端追踪：每个 Agent 的执行日志是独立的
- 跨 Agent 上下文丢失：Orchestrator 转发时压缩了信息，失败时回溯不到根因
- 没有版本化的分派记录：不知道哪个版本的任务描述导致了错误
问题四：协调开销
Token 消耗爆炸
每增加一个 Agent，协调通信的开销不是加 1 倍，而是加 N 倍。每个 Agent 都需要：
- 接收完整的任务上下文（大量 token）
- 接收其他相关 Agent 的输出（更多 token）
- 自己处理并返回结果
- Orchestrator 汇总所有结果（又是 token）
在 4 个 Agent 的系统中，协调通信的 token 消耗可能超过实际工作的 token 消耗。
延迟叠加
顺序执行的流水线中，延迟是加性的：
分析 10s + 设计 15s + 编码 30s + 测试 20s = 75s 总延迟
即便可以并行，Orchestrator 的汇总和决策也需要时间。实际加速比往往远低于理论值。
对策
对策一：共享状态空间
所有 Agent 读写同一个结构化状态空间：
shared_state = {
"requirements": [...], # 需求分析 Agent 写入
"api_format": "JSON", # 设计 Agent 写入，代码 Agent 读取
"code_modules": [...], # 代码 Agent 写入
"test_results": [...], # 测试 Agent 写入
"decisions_log": [...] # 所有关键决策的审计日志
}
每个 Agent 写入自己的输出，读取其他 Agent 的输出。格式约定在先，避免"代码用 JSON，设计要 XML"的冲突。
对策二：交叉验证网
不要让任何一个 Agent 的输出不经校验就传递给下游：
代码 Agent 输出 → 设计 Agent 交叉审查（是否符合设计？）
→ 测试 Agent 独立验证（功能是否正确？）
多一对眼睛，就多一个发现错误的机会。代价是增加延迟和 token 消耗，但对高风险任务值得。
对策三：端到端追踪
每条分派指令和返回结果都有唯一 ID 和上下游关联：
task_trace = {
"task_id": "T-001",
"parent_task": None,
"subtasks": [
{"subtask_id": "T-001-A", "assigned_to": "code_agent",
"input_snapshot": "...", "output_snapshot": "..."},
{"subtask_id": "T-001-B", "assigned_to": "design_agent",
"input_snapshot": "...", "output_snapshot": "..."}
]
}
失败时顺藤摸瓜：哪个 Agent 的输出有误？它的输入是什么？是由谁的输出衍生的？一路回溯到根因。
对策四：谨慎选择并发度
经验法则：
- 2-3 个 Agent：适合大多数场景，协调开销可控
- 4-5 个 Agent：需要完善的共享状态和追踪机制
- 6+ 个 Agent：除非有非常成熟的 Orchestrator，否则不如拆成多个独立小系统
多不一定是好。一个 2 Agent 系统（分析+执行）往往比 5 Agent 全家桶更稳定、更快。
对策五：减少协调需求
好的架构减少 Agent 间依赖，而非增加通信：
- 合并相近专长：不需要单独的"查询 Agent"和"筛选 Agent"，合并为一个"数据 Agent"
- 独立子任务并行：不互相依赖的子任务才值得拆分
- 预定义接口契约：先约定输入输出格式，再分配任务，减少运行时协商
小结
多 Agent 协调的核心矛盾是：分工带来的专长增益 vs 协调带来的复杂度成本。
2 个 Agent 的系统不是比 1 个 Agent 强 2 倍，而是在专长增益和协调成本之间找到新的平衡点。超过 5 个 Agent 的系统，如果协调机制不够成熟，大概率比 2 个 Agent 更差。
好的多 Agent 系统设计：少即是多——2-3 个专长互补的 Agent + 清晰的共享状态 + 端到端追踪 + 交叉验证，比 10 个 Agent 的大乱斗有效得多。
下一篇我们讨论"谁来负责"的问题：治理与问责。