检查一、二：角色卡与路由
角色卡是否写清输入字段、可用工具、输出格式与失败处理；主干路由是否用规则固定并可回放。两项都不过，说明流程还没设计完，此时比较模型或平台没有意义，为什么？因为流程没定，平台选谁都一样。
检查三、四：上下文与终止
上下文是否设了体积上限与摘要策略；是否设了最大轮次、单步超时与失败升级路径。为什么这两项要一起查？因为上下文膨胀与无限重试通常同时出现，最终表现为费用暴涨与任务静默卡死，而且两者常常一起发生。
检查五、六：错误隔离与日志
单个角色失败时能否降级、跳过或转人工，而不必整条链路重跑；轨迹日志是否按任务号串联，能还原每个角色看到什么、返回什么。日志不串联，多角色的排障就只能靠猜，恢复时间会很长，这也是可观测性的边界。
检查七、八：预算与回归
是否按任务量估算调用次数与费用并设限流；是否有固定评测集，每次改动后做回归对比。缺回归机制时，修好一个问题往往会悄悄弄坏另外两个，几轮之后没人敢再动配置，这正是回归机制的价值，也是维护的边界。
适用与不适用
适合谁
- 正在评审 MOA 方案的项目组
- 准备把多角色试点转正式上线的团队
- 需要给管理层一份复核依据的负责人
不适合谁
- 还没有跑通单 Agent 流程的项目
- 没有日志与评测基础、无法回归的组织
典型场景
某银行的流程团队把八项做成上线前复核表。评审时发现方案没有错误隔离，一个角色超时会导致整条链路重跑；也没有固定评测集。团队补上降级路径与回归测试，上线后第一次故障只影响单个环节，当天就完成了恢复，未影响对外业务。
可执行步骤
- 把八项做成一页复核表，每项写明通过标准，以及需要提交的证据文件
- 随机抽查两份角色卡，看输入输出能否直接对接，中间不需要再解释
- 用一条必然失败的测试任务，验证降级、重试与转人工路径是否都能走通
- 检查日志能否按任务号还原全部角色调用，并确认留存期限与访问权限
- 用固定评测集做一次完整回归，记录基线结果与本次改动带来的影响
常见坑
- 角色卡只有职责描述，没有字段与格式约定，联调阶段反复返工，进度一再推迟且难以交代。
- 没有错误隔离，任何单点失败都会导致整条链路重跑，费用与时间双双失控，责任也说不清。
- 日志分散在各个角色，排障时只能逐个翻找，一次故障往往要花几个小时才能定位原因与责任人。
- 上线后直接改提示词而不做回归，旧问题被悄悄带回下一版，团队却毫无察觉，直到投诉出现。
自检与验收清单
- 角色卡是否包含输入字段、可用工具与输出格式
- 主干路由是否已经固定，能否按单个任务回放
- 上下文体积与最大轮次是否都设了明确的上限值
- 单个角色失败时能否隔离，并降级到人工处理
- 日志是否按任务号串联，并按期限完整留存备查
- 是否有固定评测集，并在每次改动后执行回归
常见问题
八项里哪项最容易漏？
错误隔离与日志串联最常被漏。演示阶段很少出现单点失败，团队也就不做降级设计；等上线后某个接口超时，整条链路重跑，才发现没有备用路径，恢复时间被拉得很长，业务中断也随之扩大。
上线后还要继续检查吗？
要。角色卡、路由与评测集都应纳入版本管理，每次改动后跑一次回归。建议每月抽一批失败轨迹复盘，把新出现的失败类型补进评测集，否则覆盖范围会逐渐落后于实际，检查表也就失去意义。
检查表要谁签字？
由业务负责人、编排工程负责人与评测运营三方共同签字。只有技术方签字，业务对角色卡合理性没有背书；只有业务方签字，又容易忽略工程约束，两边都签才算数，也才能在出问题时说得清。