多智能体协作：什么时候值得拆成多个 Agent
我第一次认真做多智能体系统时，犯了一个很典型的错误：觉得一个 Agent 做得不够好，就再加两个。
一个负责搜索，一个负责分析，一个负责写报告，外面再套一个总指挥。架构图画出来很有气势，像一个小型公司的组织架构；真正跑起来却像几个实习生在群聊里互相转发任务。总指挥把同一个问题问三遍，搜索 Agent 返回一大段没有来源的文字，分析 Agent 忘了前面说过什么，最后写作 Agent 用更多 Token 把混乱包装成了一份看起来很专业的报告。
那次失败让我记住一件事：多智能体不是“多几个模型调用”，而是把一个任务拆成多个有边界的责任单元。拆分本身会增加通信、状态同步、调度和失败恢复的成本。只有当拆分带来的收益大于这些成本时，多个 Agent 才值得存在。
一、先问一个不太讨喜的问题：单 Agent 真的不够吗
很多任务根本不需要多智能体。一个模型加几个清晰的工具，配上合适的状态和重试，就能完成搜索、总结、分类、生成草稿等工作。此时把流程拆开，通常只会带来三种浪费：
- 上下文被重复传递，同一份资料在多个请求中反复计费。
- 每个 Agent 都有自己的提示词和输出格式，调试时很难知道问题出在哪一层。
- 调度器需要处理更多超时、重试和部分成功，系统复杂度迅速上升。
所以我的判断顺序一直是：先用普通函数解决确定性工作，再用一个 Agent 处理需要推理的环节，最后才考虑多个 Agent。能写成函数的地方，不要交给模型；能由一个 Agent 稳定完成的地方，不要急着拆成团队。
二、什么情况下拆分确实有价值
1. 任务有天然的专业边界
如果任务包含相互独立、需要不同工具和不同判断标准的环节，拆分就比较合理。例如一次企业安全审查，代码扫描、依赖漏洞查询、权限审计和报告撰写的输入输出不同，使用的工具也不同。让一个 Agent 同时扮演四种角色，提示词会越来越长，权限却越来越宽。
拆分的关键不是给每个 Agent 起一个好听的名字，而是让每个角色有明确的“我负责什么”和“我不负责什么”。安全扫描 Agent 只提交发现，不能擅自修改代码；报告 Agent 只整理已验证的证据，不能凭空补全结论。
2. 不同环节需要不同权限
权限边界是非常实在的拆分理由。负责读取生产数据的 Agent，不应该天然拥有发起退款、发布代码或删除资源的能力。把读操作和写操作分成不同的执行单元，再让高风险动作经过审批，往往比在一条超长 Prompt 里反复叮嘱“请谨慎”可靠得多。
3. 某些工作可以并行
当多个子任务互不依赖时，并行 Agent 能缩短总耗时。例如对一份技术方案分别做性能、安全和可维护性检查，三个审查者可以同时工作，最后由汇总者合并结果。这里的前提是输入稳定、结果可独立验证，而且并行带来的时间收益能覆盖额外模型调用成本。
4. 需要相互质疑，而不是只需要多写一遍
在研究、审稿和风险判断任务里，让一个 Agent 生成答案，再让另一个 Agent 专门找证据缺口，有时比让同一个 Agent 自我检查更有效。不过“批评者”必须拿到明确的检查标准和原始证据，否则它只是在生成另一种语气的意见。
三、四种常见协作模式
顺序流水线：一个接一个传递结果
资料收集 → 事实核验 → 方案分析 → 报告生成
这是最容易理解的模式，也最容易落地。每一步只消费上一步的结构化输出，便于重试和缓存。缺点是链路较长，前面一步失败会阻塞后面所有步骤，因此每个阶段都要有清晰的失败状态。
并行专家：多个 Agent 同时给出独立意见
┌→ 性能审查 ┐
输入问题 → 分发器 ─┼→ 安全审查 ─┼→ 汇总 Agent
└→ 产品审查 ┘
并行不是把同一个 Prompt 复制三份。每个专家应有不同的检查表、工具和输出字段，否则你得到的只是三份相似文本。汇总 Agent 也不能简单按字数投票，应该知道每条意见的证据和置信度。
监督者—执行者：负责规划与执行分离
监督者将目标拆成子任务，执行者调用工具完成，监督者检查结果并决定下一步。这种模式适合步骤不固定的长任务，但它很容易出现“规划越来越细、执行越来越慢”的问题。规划应该服务任务，不要为了展示聪明而生成一棵漂亮但无法执行的计划树。
辩论与裁决：不同假设之间互相挑战
它适合高价值、需要反事实检查的场景，例如故障根因分析和复杂方案评审。成本也最高，因为每轮发言都要保存上下文。没有明确裁决标准时，辩论只会把不确定性放大，最后由一个模型用语气决定谁赢。
四、协作的核心不是聊天，而是共享状态
我见过不少多 Agent 设计，把所有消息都放进一个公共对话数组。开始时很方便，后来每个 Agent 都能看到所有内容：搜索结果、内部提示、用户隐私、别的角色的临时猜测全部混在一起。上下文既变长又失去边界，模型自然会抓错重点。
更稳妥的做法，是定义任务状态，而不是依赖聊天记录猜进度：
type TaskState = {
taskId: string
goal: string
status: 'pending' | 'running' | 'blocked' | 'succeeded' | 'failed'
facts: Array<{
claim: string
source: string
confidence: number
}>
artifacts: Array<{
name: string
version: string
uri: string
}>
nextActions: string[]
budget: {
inputTokens: number
outputTokens: number
maxCostCents: number
}
}
Agent 之间传递的应该是经过约束的事件或状态变更，例如“事实核验完成”“报告草稿已生成”“需要用户补充权限”，而不是一段没有结构的长文本。状态可以持久化，事件可以重放，某一个 Agent 失败后也能从最近的检查点继续，而不是全流程重来。
五、消息协议要小，结果要能验证
一个子任务消息至少应包含任务 ID、发送方、接收方、目标、输入引用、截止时间和幂等键：
type AgentMessage = {
messageId: string
taskId: string
from: string
to: string
kind: 'request' | 'result' | 'approval_required' | 'error'
payload: unknown
correlationId?: string
idempotencyKey: string
deadlineAt: string
}
idempotencyKey 看起来是后端老生常谈，但对 Agent 尤其重要。模型可能因为没有及时收到响应而重复调用；如果第二次调用会发送邮件、扣款或发布代码，后果就不是“多算几个 Token”这么简单。
结果也不能只写“任务完成”。执行者应该返回产物、证据、状态和可继续动作。汇总者拿不到证据时，应当把结果标记为待核验，而不是替它补一句确定的话。多智能体系统最危险的时刻，往往不是某个角色明显失败，而是所有角色都用流畅语言掩盖了证据缺失。
六、失败恢复比角色数量更值得设计
至少要把下面几类失败区分开：
- 工具失败：外部 API 超时、权限拒绝或返回格式错误，可以按策略重试。
- Agent 失败：输出不符合 Schema、没有完成任务或陷入循环，需要限制步数并重新规划。
- 业务失败：输入缺少关键信息，应该请求用户补充，不能盲目重试。
- 协调失败：消息丢失、重复消费或汇总超时，需要依靠事件 ID 和检查点恢复。
我通常会给每个 Agent 设置最大步数、最大 Token、最大墙钟时间和最大工具调用次数。预算不是对模型不信任，而是给系统装上刹车。一个能够及时停下并告诉用户“这里需要确认”的 Agent，比一个永远努力、最后花光预算的 Agent 更接近生产级。
七、如何判断拆分没有成功
多智能体项目上线后，不要只看最终答案的准确率，还要记录协作本身的指标：任务成功率、平均 Agent 数量、每个角色的重试率、消息总 Token、串行等待时间、并行节省时间、人工介入率和重复动作率。
如果拆分后准确率没有提升，延迟增加一倍，成本增加三倍，故障定位还更困难，那就应该合并角色。架构不是越细越先进，能够用证据证明拆分带来收益，才是合理的复杂度。
八、我的结论：把 Agent 当成有边界的同事
我现在设计多智能体时，会先写一张很朴素的表：每个角色的输入是什么、输出是什么、能调用哪些工具、拥有哪些权限、失败由谁处理。如果这五个问题答不清楚，我不会急着创建新的 Agent。很多所谓“多智能体需求”，最后只是一个函数、一个队列，或者一个更清楚的 Prompt 就能解决。
值得拆分的系统，通常有三个特征：职责真的不同，权限真的不同，失败真的可以隔离。除此之外，多个 Agent 只是在增加沟通成本。不要因为架构图上出现更多方框，就以为系统获得了更多智能。
好的协作不是让大家同时说话，而是让每个人知道自己为什么发言、依据是什么、下一步交给谁。模型可以负责提出假设，工具可以负责提供事实，编排器可以负责推进状态，人类可以在关键节点承担最终责任。把这些边界守住，多智能体才会从一场热闹的群聊，变成一条能够运行、能够解释、也能够在失败后重新站起来的工程流水线。
