多智能体什么时候值得拆？先算协作成本，再谈角色数量

做企业 Agent 方案时，常有人先问“要不要上多智能体”。这个问题通常问早了。更实际的判断是：任务里有没有几块工作可以独立推进？它们交接时能否用稳定的输入输出描述？并行省下的时间和扩大后的协调成本，是否值得？如果这些问题还没有答案，先把角色拆多，只会让系统多出几处需要排查的地方。

固定任务先让工作流承担

当业务步骤基本确定，例如读取申请、检查必填项、匹配制度，再生成待审结果，代码编排通常更容易控制和复现。模型可以负责理解模糊表达或处理自然语言，步骤顺序、权限检查、超时退出和审批节点仍由明确的流程决定。Anthropic 对 Agent 与工作流的区分也提醒开发者：流程越明确，越应先考虑简单的组合模式，再按实际需要增加自主决策。

多 Agent 更适合开放度高、工作方向相对独立、需要同时探索多个来源的任务。比如市场研究可以按地区或竞争维度并行搜集证据，再由协调者统一去重和写结论；跨部门分析也可能需要不同角色查看不同资料范围，最后汇总为一份可核对的结果。这里的拆分依据是工作边界，而不是给每个步骤都冠上“专家 Agent”的名字。

按交付物拆分，比按人设拆分可靠

每个子任务都应该有可验收的交付物。研究角色返回结论时，需带来源、时间和未解决的问题；数据角色返回计算结果时，需注明口径与数据范围；复核角色说明发现了哪些不一致，并指出依据。协调者拿到的不是一段笼统的“我看过了”，而是能继续处理或退回补充的结构化成果。

交接契约还要说清楚哪些工作禁止重复、哪些数据不能传出权限范围、交付不完整时如何处理。若协调者无法判断子任务是否完成，或者两个 Agent 对同一信息使用了不同口径，就应把问题放回业务规则和结果格式解决，而不是继续叠加一个“仲裁 Agent”。

并行有收益，也会带来新的等待

并行能够缩短彼此独立任务的总用时，却不适合每一步都依赖上一步的链路。下游需要上游的完整结果时，启动多个子 Agent 可能只是把串行等待换成调度、状态管理和合并等待。工作开始前，可以先画出任务依赖关系：独立的分支并行，强依赖的步骤按序执行，验证和审批保留为明确关口。

运行时还要处理部分失败、重复交付、超时、用户取消和结果冲突。协调者应有限制地创建任务并等待结果；没有必要的递归委派要及时停止；一个分支失败时，需要决定是使用其余结果、请求重试还是转交人工。把这些边界写进状态流转，比单纯增加更长的系统提示词更重要。

评估时把协作开销也算进去

比较方案时，不只看最终答案，还要看完成任务的时间、调用和模型成本、子任务重复率、结果合并错误、人工接管次数与失败后的恢复能力。每个指标都要用同一类任务和同一版本的数据比较。某个多 Agent 方案即使在少数复杂任务上提高了覆盖度，如果日常任务因此变慢或费用过高，也未必适合作为默认路径。

Anthropic 分享的多 Agent 研究系统展示了并行研究和协调者模式，也明确提到协调、评测、可靠性和成本会随之成为新问题。这类经验可以帮助团队提出架构假设，但具体收益仍须在自己的业务样本上验证；外部案例中的提升比例不能直接当成本项目的预期结果。

因此，合理的起点不是先规定 Agent 数量，而是选一类任务分别做单 Agent、显式工作流和必要的并行协作版本。只有当任务边界、交接格式和业务收益都能被说明，才把多智能体作为正式架构。宜天信达可在企业 Agent 方案设计阶段，结合流程依赖、组织权限和验收样本评估拆分范围，让系统复杂度跟着真实任务走。

延伸阅读

Anthropic：How we built our multi-agent research system；Anthropic：Building effective agents。