坑一、二：角色堆砌与模型路由
先把角色数量堆到十几个，再让模型自己决定调用顺序，看起来灵活，实际无法测试、无法复现。如何避免？先定三到五个角色，路由用规则写死，等流程稳定之后再逐个放开判断权，而不是一开始就把控制权交出去。
坑三：上下文无限膨胀
把全部历史对话与原始文档塞进每一次调用，成本和延迟一起上涨，关键信息反而被淹没。应按角色只传必要字段与结论摘要，并给上下文设体积上限，超出时先做摘要再传，而不是把整包原文转发过去，这属于设计边界。
坑四：缺少收敛条件
角色之间互相要求补充材料，没有最大轮次与终止条件，任务就会一直循环。应设定最大轮次、超时与失败升级路径，让流程在无法推进时明确停下来并转人工，而不是继续消耗额度，这也是成本控制的边界。
坑五：只看最终答案
评估时只比对最终输出，不检查中间轨迹，就无法判断错误来自哪个角色。应以轨迹为单位抽样复盘：哪一步取了错资料、哪一步合并时丢了信息，这类问题在结果层往往完全看不出来，只能靠轨迹发现，这也是评测的边界。
坑六：成本与延迟没预算
多角色意味着成倍的调用次数，试点阶段量小不觉得，放量后账单与响应时间同时失控。上线前应按任务量估算调用次数与并发，设置限流与降级策略，并明确超额部分由谁承担，否则预算会在中途被叫停，这条边界要在立项时写清。
适用与不适用
适合谁
- 已经跑过单 Agent、准备扩展的团队
- 流程环节多、需要不同工具协作的业务
- 有人力做轨迹复盘与成本核算的组织
不适合谁
- 任务本身只需一次问答就能完成的场景
- 没有日志与评测机制、无法复盘的团队
典型场景
某企业的合同审阅流程一开始设了八个角色，运行两周后发现同一份合同被反复转交，平均要跑十几轮。团队把角色压到四个，路由改成固定顺序，上下文只传条款摘要，并设定最大轮次，耗时与费用同时下降，问题定位也变快了。
可执行步骤
- 先把角色数量压到三到五个，每个角色只负责一件可以独立验收的事
- 先用规则把主干路由写死，第一期完全不做动态分配，避免路径漂移
- 给每次调用的上下文设置体积上限，只传结论摘要与必要的原文片段
- 设定最大轮次、单步超时时间，以及无法推进时转人工的升级路径与责任人
- 按轨迹抽样复盘每一次失败，定位错误究竟发生在哪一步，再定向修改
常见坑
- 为了显得先进而堆角色，评审时没人能说清每个角色的职责与产出，方案无法冻结，只能反复改稿。
- 让模型决定全局路由，流程每次运行路径都不同，出现问题时根本无法复现，也无法向业务解释。
- 上下文不设上限，调用成本随对话轮次线性上升，试点预算很快就被耗尽，团队却还说不清贵在哪里。
- 没有终止条件，两个角色互相等待对方补充材料，任务静默卡死却无人察觉，等到业务投诉才发现。
自检与验收清单
- 角色数量是否控制在五个以内，职责是否互斥
- 主干路由是否已经用规则固定，能否按任务回放
- 上下文是否有明确体积上限，超出时如何摘要
- 是否设了最大轮次、超时与转人工的升级路径
- 是否按轨迹做过抽样复盘，并留下书面复盘结论
常见问题
角色是不是越多越专业？
不是。角色越多，协调开销、调用成本与出错概率同时上升。多数企业场景三到五个角色足够，关键在职责清晰与输出格式统一，而不是数量，更不是名字听起来有多专业、多像一支团队。
动态路由什么时候可以用？
在主干流程稳定、评测集覆盖充分之后，可以只在少数分支上放开，并保留规则兜底。全流程动态路由在多数企业场景里收益有限，风险却明显更高，不建议作为起点，也无法在评审会上说清楚。
MOA 的成本大概高多少？
取决于角色数量、轮次与上下文长度，通常会达到单 Agent 的数倍。具体幅度需按任务量实测，建议在试点期记录每次任务的调用次数与耗时，作为放量前的预算依据与限流阈值参考。