多 Agent 协作：什么时候值得，什么时候只是更贵

多一个 Agent，不等于多一份智能

多 Agent 系统常被描述成一个数字团队：主管分派任务，研究员查资料，工程师写代码，审核员检查结果。这个比喻很直观，但软件系统里的“成员”会共享相似模型、重复上下文并产生额外通信。若任务本来可以由一个 Agent 连续完成，拆分后往往只是增加 Token、延迟和故障点。

判断是否值得拆分，先看三个条件：子任务是否能清楚隔离；不同角色是否需要明显不同的工具或上下文；并行执行是否真的缩短关键路径。只满足“听起来像团队”并不够。

三种常见协作拓扑

主管—工人模式由一个主管维护全局目标，将子任务交给多个工人，再汇总结果。适合可以并行的研究、批量代码检查或多数据源分析。主管的风险是成为瓶颈，它必须处理所有通信，也可能错误分解任务。

流水线模式让输出按固定顺序传递，例如研究 Agent 产出证据包，写作 Agent 形成草稿，审核 Agent 检查引用。它的可预测性高，适合交付流程稳定的场景。缺点是上游错误会被下游放大，因此每个阶段都需要明确输入契约。

辩论或评审模式让多个 Agent 独立提出方案，再由裁判比较。它适合高价值、存在多种合理路径的决策，但成本较高。若所有角色使用相同模型和相同证据，它们的错误也可能高度相关，不能把“多数票”自动视为真相。

还可以组合这些结构，但拓扑越复杂，越需要像分布式系统一样处理超时、重复消息、部分失败和状态一致性。

任务切分必须可验收

“研究一下认证问题”不是好的子任务，因为范围与完成条件都不清楚。主管应该发送结构化任务包：

{
  "taskId": "research-auth-errors",
  "objective": "确认版本发布后新增的认证错误类型",
  "inputs": ["release-3.8", "metrics-window-42"],
  "allowedTools": ["query_logs", "read_release_notes"],
  "deliverable": {
    "type": "evidence_bundle",
    "minimumEvidence": 2
  },
  "deadlineSeconds": 120,
  "budget": {"toolCalls": 6}
}

工人返回的也不应是一段随意文字，而应包含结论、证据引用、未解决问题和置信度。主管只汇总通过 Schema 与证据验证的输出。

任务之间最好通过不可变产物传递，例如查询结果快照、补丁文件或证据包，而不是共享一个不断被多人修改的长对话。共享黑板可以保存全局状态，但写入要有版本号，避免两个 Agent 相互覆盖。

通信是最昂贵的部分

每次 Agent 之间交接，都要重新解释背景。把全部历史复制给每个工人会迅速放大成本；只给一句任务又会缺少关键约束。合理做法是为角色构建最小上下文：稳定规则、当前子目标、必要输入、允许工具和输出契约。

主管不需要看到工人每一次内部思考，只需要结构化进度和最终产物。工人也不需要获得所有用户数据。上下文隔离既降低成本，也缩小敏感信息暴露面。

可以给消息加上 runId、taskId、parentTaskId 和 attempt，让系统识别重试与重复提交。没有这些标识，多 Agent 运行很快会变成难以追踪的聊天网络。

冲突不能只靠“再问一个 Agent”

两个工人给出相反结论时，主管应比较证据质量，而不是偏好表达更自信的一方。冲突处理可以遵循确定性规则：优先原始数据、优先更新来源、检查权限与查询范围；若仍无法解决，创建专门的验证任务或请求人工判断。

裁判 Agent 的输入应匿名化方案来源，减少角色权威带来的偏差。评分标准也要提前定义，例如正确性、证据完整度、风险和成本，而不是一句“选最好的”。

部分失败与取消

并行运行时，某个工人超时不应让所有结果丢失。主管需要知道哪些子任务是必需、哪些可以降级。非关键数据源失败时可以带限制完成；关键证据缺失时应将任务标为阻塞。

当用户取消或全局目标改变，系统必须向所有工人传播取消信号。工具执行器还要检查任务是否仍有效，避免已取消的 Agent 在几分钟后继续写入外部系统。

对子任务使用幂等键和检查点，可以防止主管重试时重复创建工单或发送消息。多 Agent 的可靠性问题，本质上与消息队列和分布式作业非常相似。

如何证明拆分值得

评测时要把多 Agent 与强单 Agent 基线比较。至少观察任务成功率、端到端延迟、Token 和工具成本、人工介入率以及结果差异度。若成功率只提升一点，却让成本和延迟翻倍，可能不值得。

多 Agent 真正有价值的场景通常具备明确并行性、专业工具隔离或独立审查需求。否则，先用一个拥有清晰状态和阶段计划的 Agent，往往更简单、更稳定。

小结

多 Agent 不是角色扮演功能，而是一种分布式编排架构。只有任务契约、上下文隔离、消息标识、冲突规则和失败恢复都设计清楚，额外 Agent 才能带来真实吞吐或质量提升，而不是更昂贵的讨论。