07. Multi-Agent 什么时候真的有必要？有哪些常见的协作模式？

简单回答

Multi-Agent（多智能体）是用多个 Agent 各司其职来协作完成任务。真正有必要的场景是：任务可以被清晰拆分为多个独立的子领域，每个子领域需要不同的工具集、不同的系统指令、或不同的模型能力。常见协作模式包括主从式（Orchestrator + Workers）、辩论式（多个 Agent 讨论达成共识）、流水线式（按顺序接力处理）。但大多数场景下，一个 Agent 配合好的 Prompt 和工具就够了，不要为了"Multi-Agent"而 Multi-Agent。

详细解释

Multi-Agent 不是银弹

Multi-Agent 近两年被炒得很热——很多框架（CrewAI、AutoGen、MetaGPT）都主打多智能体协作的概念，demo 也确实很酷。但冷静来看，大部分实际项目中单 Agent 就能解决问题，上 Multi-Agent 往往是过度设计。

理解它什么时候有必要，先搞清楚"多个 Agent 相比一个 Agent 到底带来了什么"。

多 Agent 相比单 Agent 的真正优势

职责隔离和专业化。 一个 Agent 如果同时承担太多角色（写代码、测试代码、写文档、做部署），它的 system prompt 会非常长，工具列表也会很庞大。这不仅消耗大量 token，还会让模型"分心"——工具太多选择困难，指令太多容易冲突。把不同职责拆分给不同的 Agent，每个 Agent 的 prompt 和工具集都精简聚焦，效果通常更好。

独立的上下文空间。 每个 Agent 有自己的 context window。如果一个复杂任务的中间信息量非常大，单一 Agent 的 context window 可能装不下。拆成多个 Agent 后，每个 Agent 只需要持有自己领域的信息，上下文更精简。

不同子任务适合不同模型。 比如写代码的子任务用代码能力强的模型，写文档的子任务用通用能力强的模型，简单的工具调用用便宜的小模型。Multi-Agent 架构天然支持这种异构模型配置。

常见协作模式

主从式（Orchestrator + Workers） 是最常用的模式。一个 Orchestrator Agent 作为"管理者"，负责接收用户请求、做任务规划和分发。多个 Worker Agent 各负责一个子领域——比如 Research Agent 负责搜索和信息收集，Code Agent 负责写代码，Review Agent 负责代码审查。Orchestrator 把子任务分配给合适的 Worker，收集结果，综合后给用户。

这种模式的好处是层次清晰、易于管理。坏处是 Orchestrator 成为了单点——如果它的任务分配不合理，整个系统效果都会差。

辩论式（Debate / Discussion） 让多个 Agent 对同一个问题各自给出观点，然后互相讨论、质疑、修正，最终达成共识。适合需要多角度审视的场景——比如代码审查（一个 Agent 写代码，另一个 Agent 找 bug）、方案评审（多个 Agent 从不同维度评估一个方案）。

这种模式的效果取决于 Agent 之间是否能产生真正有意义的"分歧"。如果几个 Agent 用的是同一个模型、同样的 Prompt 模板，它们很可能给出几乎相同的观点——"辩论"就变成了虚假的形式。让 Agent 用不同的 System Prompt（比如一个从成本角度审视、一个从安全角度审视）能增加观点多样性。

流水线式（Pipeline / Sequential） 按顺序处理——Agent A 的输出作为 Agent B 的输入。比如：信息收集 Agent → 数据分析 Agent → 报告撰写 Agent。每个 Agent 只处理一个阶段，上一个的输出是下一个的输入。

这种模式简单清晰，但上游 Agent 的质量直接决定下游 Agent 的效果，错误会级联传播。

投票式（Ensemble / Voting） 让多个 Agent 独立回答同一个问题，然后取"多数意见"或"最佳回答"。用于提高可靠性，适合高风险场景（如医疗诊断建议——多个模型各自给出诊断，取交集或共识）。

什么时候不需要 Multi-Agent

单个任务的步骤虽然多但逻辑线性——用 ReAct 式的单 Agent 循环就够了。任务涉及的工具不多（十个以内）——单 Agent 完全能 handle。Agent 之间的交互主要是简单的"传递信息"而不是真正的"协作"——这时候用 Workflow 更合适。如果做 Multi-Agent 的主要原因是"单 Agent 的 Prompt 太长了"，那更好的解决方案可能是优化 Prompt 或做动态工具筛选，而不是引入多个 Agent 的管理复杂度。

Multi-Agent 的调试和维护成本远高于单 Agent。Agent 之间的通信需要设计消息格式和协议，失败的定位需要追踪跨 Agent 的调用链，Agent 之间的信息传递可能丢失或变形。这些都是实打实的工程开销。

工程上的注意事项

Agent 之间的消息传递格式要标准化。每个 Agent 的输出作为下一个 Agent 的输入，如果格式不一致就会出问题。结构化输出（JSON Schema 约束）在这里非常重要。

需要有全局的超时和 fallback 机制。如果某个 Worker Agent 卡住了（LLM 陷入循环或工具调用失败），不能让整个系统无限等待。

Tracing 要能跨 Agent。需要看到完整的调用链——Orchestrator 分配了什么任务，Worker 做了什么，中间结果是什么，最终怎么合并的。LangSmith、Arize 等 observability 工具在这方面有支持。

面试时可以这样答

Multi-Agent 真正有必要的场景是任务可以被清晰拆分为独立的子领域，而且每个子领域需要不同的工具集、Prompt 或者模型。核心好处是职责隔离——每个 Agent 的 Prompt 和工具集精简聚焦，避免单 Agent 工具太多指令太杂导致效果下降。

常见协作模式有几种。主从式用一个 Orchestrator 做任务分发，多个 Worker 各负责一个子领域。辩论式让多个 Agent 对同一个问题讨论和质疑，适合需要多角度审视的场景。流水线式按顺序接力，上一个 Agent 的输出是下一个的输入。

但我的实际经验是，大多数场景单 Agent 就够了。Multi-Agent 的调试和维护成本很高——Agent 间的消息传递、失败定位、信息丢失或变形，都是实打实的工程问题。如果做 Multi-Agent 的原因只是"单 Agent Prompt 太长"，不如先优化 Prompt 和做动态工具筛选。

常见追问

1. 你有实际做过 Multi-Agent 系统吗？用的什么框架？
2. Orchestrator Agent 的任务分配出了错怎么办？
3. Multi-Agent 系统的延迟怎么控制？