角色一：编排工程
负责角色调度、状态传递、重试与降级，把流程做成可测试、可回放的骨架。为什么这项工作不能交给业务方？因为它决定失败时系统怎么退，退得不好，业务侧再懂流程也救不回来，也无法在评审时解释清楚。
角色二：领域专家
负责写角色卡与判定标准，明确每个角色的输入、输出与不可逾越的边界。领域专家不参与编码，但必须参与验收：只有他能判断某条结论在业务上是否成立，而不是看起来像那么回事，这一点无法外包。
角色三：评测运营
负责维护样本集、按轨迹复盘失败、统计各角色的错误分布。多角色的错误会互相掩盖，必须有人按环节拆开统计，否则只能看到最终准确率下降，却不知道该改哪个角色。为什么强调这一点？因为改错方向的代价最高。
数据底稿：四类不能缺
角色职责与交接文档、工具清单与权限矩阵、带结果的历史任务、结论冲突时的汇总规则。缺交接文档，角色之间只能靠猜；缺汇总规则，多角色给出的不同结论无人裁决，项目会卡在最后一步，这是数据准备最容易忽略的边界。
适用与不适用
适合谁
- 有平台工程能力、能自建编排层的中大型企业
- 流程复杂、需要多系统协作的业务
- 愿意指定领域专家参与验收的组织
不适合谁
- 没有工程人力、只能采购成品的团队
- 业务流程本身尚未标准化、规则还在频繁变的部门
典型场景
某能源企业的设备故障处理拆成诊断、备件、工单三个角色。领域专家来自检修班组，负责写判定标准；编排工程由信息中心承担，负责状态传递与降级；评测运营每周抽二十条轨迹复盘。三方每月对齐一次角色卡，避免规则随人员变动而失效。
可执行步骤
- 指定编排工程负责人，明确骨架设计与状态传递方式，并约定失败时的降级方案
- 从业务一线选领域专家，负责角色卡与判定标准，并参加每一轮验收评审
- 确定评测运营的固定人选，把轨迹复盘的频率定在每周，结论按月归档
- 整理工具清单与权限矩阵，逐项标注可写、只读与禁用的接口，并由安全复核
- 把结论冲突时的裁决规则写成文档，组织一次跨部门评审，并指定裁决人
常见坑
- 让领域专家直接写代码，角色卡与实现混在一起，后续的交接、维护与审计都会变得困难。
- 没有汇总规则就上线，多角色结论一旦冲突只能全部推翻重来，时间成本极高且难以追责。
- 评测运营只看最终结果，各角色的错误分布始终不清，改来改去没有方向，几轮之后就会停摆。
- 权限矩阵缺失，角色能调用本不该调用的接口，一次误操作就可能带来合规风险与审计问询。
自检与验收清单
- 编排工程是否有明确负责人，并备好降级方案
- 领域专家是否参与角色卡评审并完成验收签字
- 评测运营是否按周复盘轨迹，并把结论完整留档
- 工具权限矩阵是否成文，并逐项核对过可用范围
- 冲突裁决规则是否经过跨部门评审并指定裁决人
常见问题
没有平台团队能做吗？
可以做小范围试点，但要接受排障与迭代速度较慢。建议先用现成编排工具搭骨架，把角色卡与评测做扎实；等流程稳定、调用量上来之后，再考虑自建平台与工具链，避免过早背上维护负担。
领域专家要投入多少时间？
试点期通常每周半天到一天，用于写角色卡、看失败案例与确认判定标准。投入不足会直接体现在角色卡质量上，后续返工的时间往往远超这点投入，返工时还要重新对齐口径。
数据底稿可以后补吗？
交接文档与汇总规则很难后补，因为角色已经按错误假设跑了一段时间，改起来要重跑全部样本。工具清单与历史任务可以边做边补，但要在上线前完成核对与签认，否则仍会返工。