第一步：先判断必要性
只有当任务能拆成若干可独立验证的子任务、且单智能体在上下文或权限上确实受限时，多角色才有意义。拆不出子任务却硬上多智能体，只会增加调用次数与出错面，效果通常不如一个带流程的单智能体。
第二步：角色与契约
每个角色要写清输入、输出、可调用工具与失败时怎么办。契约不写清，角色之间会互相等待或重复劳动。交付物格式最好用结构化字段固定，便于下一环节机器校验，而不是靠自然语言互相揣测对方意图。
第三步：共享状态与仲裁
多角色必须共享同一份任务状态，并规定谁有最终裁决权。没有仲裁时，两个角色意见相左会来回争论，直到轮次耗尽。常见做法是设协调角色或规则引擎，冲突超过一次即升级给人工处理。
第四步：编排与上限
给每次任务设轮次上限、超时与调用次数上限，并规定超限后的降级路径，例如退回单智能体或转人工。没有上限的多智能体在异常输入上会反复重试，成本与等待时间都不可控，用户只能干等。
第五步：评测与灰度
先跑单智能体或人工基线，再用同一批样本比较多角色方案，看成功率、轮次与人工接管率。没有基线的进阶无法判断是否更好。灰度从低风险环节开始，并保留一键回到原流程的开关。
适用与不适用
适合谁
- 跨环节流程长、单智能体上下文吃紧的场景
- 已有单智能体试点、想评估多角色是否值得的团队
不适合谁
- 任务无法拆成可验证子任务的场景
- 没有评测集、也不打算建基线的项目
典型场景
某企业的合同流程涉及条款抽取、风险标注与用印核对。团队先做单智能体基线，发现上下文截断导致漏项；改为三个角色分工，设协调角色裁决冲突，轮次上限六轮。灰度两周后漏项减少但轮次上升，团队据此收窄了适用合同类型。
可执行步骤
- 先用单角色跑一遍基线，记录成功率与耗时，确认它卡在哪
- 把流程拆成可独立验收的子任务，固定每步输入输出与判定人
- 设协调角色或规则引擎，写明裁决顺序与冲突升级的阈值
- 给轮次、超时与调用次数设上限，并定义超限后的降级路径
- 用同一批样本比对基线与多角色方案，通过后再灰度上线
常见坑
- 为多而多，调用次数翻倍但成功率没变，成本上升后又被要求回退，团队白忙一轮。
- 角色职责重叠，两个角色都做抽取又都等对方确认，任务在中间停住，超时才算失败。
- 没有仲裁规则，角色间来回辩论直到轮次耗尽，输出一个看似完整却无人负责的结论。
自检与验收清单
- 是否先有单智能体或人工基线作为对照
- 子任务是否可独立验证并有判定标准
- 是否有仲裁规则与冲突升级到人工的路径
- 轮次与超时上限是否已设并配置告警
常见问题
多智能体一定比单智能体好吗？
不一定。任务可拆、子任务可验证、且单智能体受上下文或权限限制时，多角色才有优势；否则增加的是调用次数与协调成本。判断依据应是基线对比，而不是架构看起来更先进。
轮次上限设多少合适？
按任务复杂度与人工接管成本定，通常个位数轮次即可。上限的意义在于止损：超过上限就降级或转人工，而不是继续重试。上限过高会让异常输入消耗大量时间，结果仍然不可靠。
共享上下文会不会泄露信息？
会，如果所有角色都能读到全部内容。应按角色裁剪可见字段，敏感信息只给必要角色，并在日志中记录谁读了什么。共享不等于全开放，权限设计要在编排阶段就定下来。