第一步：拆任务与角色卡
把流程拆成三到五个可独立验收的子任务，每个子任务写清输入字段、可用工具、输出格式与失败处理。角色卡不是人设描述，而是接口约定；写不清的角色后面一定要返工，还会拖慢整条链路，为什么要一开始就写细？因为返工成本最高。
第二步：编排骨架与路由
先用代码或工作流把角色串起来，路由按规则固定，主干路径可测试、可回放。为什么先固定？因为动态路由会让每次运行的路径都不同，出问题时无法判断是角色、资料还是顺序造成的，连排障都无从下手。
第三步：协同评测
评测要同时看结果与轨迹：结果层比对最终输出与人工答案，轨迹层抽样检查每一步的取值与合并。只看结果会漏掉过程错误，只看轨迹又无法判断业务价值，样本还要覆盖不同失败类型，否则怎么评都只是自我确认。
第四步：治理与成本
上线前补齐权限、日志、限流与降级策略，估算每个任务的调用次数与延迟，并约定超额时的处理方式。多角色的成本结构比单 Agent 复杂，治理缺位的项目往往在放量阶段被迫停摆，这时再补边界就来不及了。
适用与不适用
适合谁
- 已有单 Agent 基础、准备处理复杂流程的团队
- 任务环节多、需要多种工具协作的业务部门
- 能安排人力做轨迹复盘与成本核算的组织
不适合谁
- 需求还停留在单次问答层面的项目
- 没有日志与评测基础、无法复盘的团队
典型场景
某物流企业的异常件处理拆成四个角色：查件、判责、方案生成、客户通知。路由按固定顺序执行，判责失败退回查件，最多两轮；评测同时看最终方案与每步取值，发现多数错误来自判责时的规则缺失。补齐规则后，人工接管明显减少。
可执行步骤
- 把流程拆成三到五个可独立验收的子任务，并标注各自的输入与输出
- 为每个角色写清可用工具清单、输出格式、失败处理方式与重试次数
- 先用固定路由把主干串起来，第一期先不做任何动态分配，也不做重排序
- 同时按结果与轨迹两个维度抽样评测，把每处错误定位到具体某一步骤
- 上线前估算每个任务的调用次数与响应延迟，并设定限流与降级策略
常见坑
- 角色卡写成人设描述，没有输入输出约定，联调时只能靠猜，返工几乎不可避免，进度也会被反复拖慢。
- 一上来就做动态路由，路径无法复现，评测结果没有可比性，迭代时也失去方向，只能靠感觉调整。
- 只比对最终输出，过程错误被掩盖，改提示词也解决不了，团队会误判为模型能力不足，转而去换模型。
- 没有估算调用次数，放量后成本与响应时间同时失控，只能临时砍掉功能收场，前期投入的都成了沉没成本。
自检与验收清单
- 每个角色是否都有可验收的输入输出约定与样例
- 主干路由是否已经固定，能否按单个任务完整回放
- 评测是否同时覆盖最终结果与中间的每一步轨迹
- 是否设了限流、降级与超额调用时的处理方式
- 是否写清了退回单 Agent 的判断条件与责任人
常见问题
什么情况下该退回单 Agent？
如果子任务之间高度耦合、拆开后协调开销大于收益，或者调用成本明显超出预算而效果没有提升，就应退回单 Agent 加工具的方案，把复杂判断留给人工，而不是继续加角色，那样只会更慢更贵。
四个角色够用吗？
多数流程三到五个角色已经足够。角色数量取决于子任务是否需要不同的工具与知识，而不是流程看起来有多复杂，建议先按最小可行角色数开工，再按评测结果逐个增补，避免一次铺开。
协同评测要多少样本？
起步阶段每个角色覆盖二十到三十条典型任务，加上失败案例即可形成基线。样本不在多，而在能覆盖不同失败类型，并且每次迭代都用同一批样本做对比，结论才有意义。