多智能体协作：编排、分工与信息传递设计

为什么需要多个 Agent

单个 Agent 的瓶颈主要有三个：上下文窗口装不下全流程信息、一个 Prompt 难以同时优化多种能力、串行执行太慢。多智能体（Multi-Agent）通过分工与隔离来突破这些瓶颈——就像一个人干不完的项目要拆给一个团队。

但先把丑话说在前面：多 Agent 的调试难度、成本、失败面都是单 Agent 的数倍。判断标准很简单：

产品决策提示：只有当单 Agent 明确撞到上下文上限、能力混杂互相拖累、或需要并行提速时，才上多 Agent。如果只是觉得“多 Agent 更高级”，那是在给产品叠加故障点。大多数场景，一个好的单 Agent + 好的工具集就够了。

三种编排拓扑

1. 流水线：固定工序传递

需求分析 Agent → 代码编写 Agent → 测试 Agent

每个环节职责单一、输入输出明确。最可控、最好调试，适合流程已验证成熟的任务。本质上接近工作流，只是每个节点由 Agent 填充。内容生产线的“选题→撰写→审校”就是典型。

2. Supervisor：主管分派

        ┌── 研究 Agent
Supervisor ├── 写作 Agent
        └── 事实核查 Agent

一个主管 Agent 接收任务，拆解后分派给专职 Agent，汇总结果决定下一步。灵活，能应对不可预枚举的任务分支。ChatGPT 的 Deep Research、各类“研究团队”产品多用此模式。代价是主管的拆解质量成为系统上限。

3. 对等协作：辩论与互审

Agent 之间平等对话、互相批评修正，如“生成器 vs 审查员”的对抗模式、多角色圆桌讨论。适合质量优先、需要对抗性检验的场景——用审查 Agent 找生成 Agent 的漏洞，比在一个 Prompt 里写“请自查”有效得多。

拓扑选择速查

拓扑	适合	关键风险
流水线	成熟固定流程	僵硬，不适应意外分支
Supervisor	开放复杂任务	主管拆解错误传导全局
对等协作	高质量要求、需对抗校验	成本翻倍、讨论不收敛

信息传递：上下文是稀缺资源

多 Agent 之间不共享大脑，一切靠消息传递。核心设计问题：每个 Agent 该知道多少？

原则是最小充分信息——只传任务所需的信息，而非全量对话历史：

• 传结论与摘要，不传原始过程。研究 Agent 给写作 Agent 交付“要点清单 + 引用来源”，而不是 50 轮检索日志。
• 定义清晰的交接物格式（handoff schema）：状态、已完成、待办、注意事项。格式化的交接物让下游 Agent 不用重新理解上下文。
• 上下文隔离是特性不是缺陷：写代码的 Agent 不需要知道用户闲聊的 50 条历史，隔离反而提升专注度和稳定性。

产品决策提示：多 Agent 系统最贵的 bug 往往不在单个 Agent，而在交接处——信息在传递中丢失或失真。设计评审时把“交接物里有什么”当作正式规格逐项过，比优化单个 Agent 的 Prompt 回报更高。

过程展示：团队要有“作战室”

多 Agent 执行时用户看到什么？行业已收敛出一些体验模式：

• 任务面板：像 Manus 那样展示各 Agent 当前在做什么、整体进度到哪一步，把不可预测的执行变成可视的“项目管理界面”；
• 中间产物可查看：允许用户点开研究 Agent 的中间结论，既增加信任，也方便出错时归因；
• 可控介入点：在关键交接处允许用户修改方向（“这个大纲改一下再继续写”），比全自主跑完再返工体验好得多。

成本与延迟控制

多 Agent 的账要算三遍：

1. token 账：每个 Agent 独立上下文，信息重复传递，总 token 通常是单 Agent 的 3-10 倍；
2. 延迟账：串行链路延迟累加；能并行的（Supervisor 同时派发多个研究 Agent）务必并行；
3. 失败账：N 个 Agent 的失败率会叠乘，必须有单点重试和整体超时熔断，避免一个环节卡死拖垮全程。

本节要点

• 多 Agent 解决单 Agent 的三大瓶颈：上下文上限、能力混杂、串行慢；但成本、延迟、调试难度数倍增长，不要为多而多。
• 三种拓扑各有归属：成熟流程用流水线，开放任务用 Supervisor，高质量校验用对等协作；主管的拆解能力是 Supervisor 模式的系统上限。
• 信息传递遵循最小充分原则，交接物要格式化定义；系统最贵的 bug 通常出在 Agent 之间的交接处而非 Agent 内部。
• 过程展示用任务面板 + 可查看中间产物 + 关键点介入，把不可预测性转化为可控的项目管理体验。
• 上线前算清 token、延迟、失败三笔账，配好单点重试与整体熔断。