问题一：任务能拆吗
把流程写成步骤清单，看每一步到底需要前面多少信息。若多数步骤只依赖一小段材料，拆分的收益就大；若每一步都要看全文，拆开只会让每个角色都缺信息，反而不如单 Agent 稳，这就是判断能否拆分的边界。
问题二：子任务需要不同工具吗
如果所有子任务用的是同一套检索与同一个知识库，多角色的价值就有限。只有当子任务需要不同系统、不同权限或不同专业知识时，角色分工才真正降低复杂度，也才值得增加一层编排与日志，这是选型的边界。
问题三：并行能省下时间吗
多角色常被期待用来提速，但汇总环节仍然是串行的。要算清关键路径：拆开之后最慢的那条链是否比原来短。若总时长由汇总决定，并行收益会被抵消，只是界面上看起来更快，怎么算收益要按总时长来。
问题四：汇总规则明确吗
多个角色给出不同结论时，谁说了算？是按规则取交集、按置信度排序，还是交人裁决。没有明确规则，角色越多争议越多，最后还是要靠人从头看一遍，投入等于白花，这条边界必须在开发之前就定下来。
问题五：成本与排障扛得住吗
按任务量估算调用次数与费用，再算排障需要多少人手。多角色的日志量与失败类型都成倍增加，没有人负责轨迹复盘，系统会在几周内变成黑箱，最后只能整体停用，到那时如何收场都会非常被动。
适用与不适用
适合谁
- 流程环节多、材料量大的业务部门
- 已跑通单 Agent、想提升覆盖面的团队
- 有平台工程能力与评测人力的组织
不适合谁
- 只需要一句话就能答完的简单问答场景
- 没有日志基础、也无法做轨迹复盘的团队
典型场景
某集团评估三个 MOA 提案：投标文件合规检查、员工政策问答、售后方案生成。按五问打分后发现，政策问答所有子任务共用同一知识库，拆分收益有限；售后方案生成的汇总规则最难统一，暂缓；投标文件检查因章节独立、工具不同，最先启动。
可执行步骤
- 把候选流程写成步骤清单，标注每一步依赖的材料范围，以及由谁负责
- 逐项核对每个子任务是否真的需要不同的系统、权限或专业知识支撑
- 画出拆分前后的关键路径，逐段确认并行处理是否真的能缩短总时长
- 写清多角色结论冲突时的裁决规则，并指定具体岗位作为最终裁决人
- 按真实任务量估算调用次数、费用与排障人力，再决定是否值得立项
常见坑
- 只看演示效果，不核算调用次数与费用，放量之后账单远超预期，项目往往被迫缩减范围。
- 汇总规则留到开发阶段才定，各角色输出格式无法对齐，联调时间被无限拉长，进度失控。
- 把并行当成必然提速，忽略汇总环节的串行瓶颈，整体时延几乎没有改善，成本却先付了。
- 没有指定轨迹复盘的人，故障处理全靠供应商远程支持，响应时间以天计算，业务无法接受。
自检与验收清单
- 每个子任务是否都只依赖有限范围的材料与工具
- 子任务之间是否真的使用不同工具或不同知识
- 关键路径是否算过，并与原流程做过同口径对比
- 结论冲突时的裁决规则是否已经书面化并指定裁决人
- 调用费用与排障所需人力是否都已经估算过并留出余量
常见问题
五问都通过才做吗？
不必。前三问决定能不能拆，后两问决定能不能撑住。若汇总规则或排障人力缺失，即使拆分条件很好，也应先把规则与人手补齐，否则系统会在第一次结论冲突时停摆，返工代价很大。
拆分后效果一定更好吗？
不一定。拆分减少的是单次上下文的干扰，增加的是信息传递与协调成本。需要用同一批任务做对照测试，比较准确率、时延与费用三项，再决定是否保留多角色结构，还是退回单 Agent。
可以先做两个角色试试吗？
可以，而且推荐。两个角色足以验证传递、汇总与排障三条链路是否成立，成本也可控。等这三条链路都稳定，再考虑增加角色，避免一次性铺开之后难以定位问题，也难向业务解释。