自研编排的边界
自研适合角色数量少、协议稳定、团队能承担可观测性建设的场景。真正的成本在调试与回归：多角色的失败往往跨节点，没有链路追踪就只能靠日志猜。团队缺这块能力时，自研会变成长期负担。
平台采购的取舍
平台在编排、追踪与权限上成熟，适合快速起步。限制是角色与字段契约要迁就平台模型，特殊业务逻辑得绕开。采购前应要求用真实任务跑通一条链路，并确认配置能否导出，避免被格式锁死。
外部交付的条件
外部交付适合缺经验但任务明确的团队。合同要写清角色配置、协议文档、评测集与失败案例库的归属，并约定交接后的联合运行期。只交一个能跑的流程，换模型或改规则时仍要找原厂。
别先买平台再找场景
多智能体的价值高度依赖任务结构，平台能力再全也无法替代对流程的理解。先买平台容易把不适合拆分的任务硬拆，最后留下一个昂贵却没人用的编排层。顺序应是先定任务与基线，再选工具。
适用与不适用
适合谁
- 正在比较多智能体技术路线的负责人
- 已有单角色应用、想评估编排方案的团队
不适合谁
- 任务尚未确定就要求平台选型的场景
- 没有工程团队、也不打算建设的组织
典型场景
某企业在自研与平台间比较。评估发现任务只涉及三个角色、协议稳定，但团队缺少链路追踪能力。最终选择平台承载编排与追踪，自研补齐字段契约与仲裁规则，合同约定配置可导出，避免后续被格式锁定。
可执行步骤
- 先定任务结构与角色数量，然后讨论选用什么工具与平台
- 评估团队在链路追踪、回归测试与日常运维上的现有能力
- 要求候选方案用真实任务跑通一条完整链路，然后再比较
- 核对配置、协议与评测集的归属，并确认这些内容能否导出
- 把联合运行期与退出迁移的具体方式写进合同正文与附件
常见坑
- 先买平台再找场景，把不适合拆分的任务硬拆，最后留下一个没人使用的编排层。
- 配置无法导出，换方案时要重建全部角色与协议，迁移成本高于当初的采购价。
- 忽略链路追踪能力，多角色失败跨越多个节点，排查只能靠猜，平均修复时间很长。
自检与验收清单
- 任务结构与角色数量是否已经确定
- 团队在追踪与回归上的能力是否评估
- 是否用真实任务跑通过一条完整链路
- 配置与评测集能否完整导出并迁移
常见问题
平台能不能直接用现成角色？
可以参考，但不要直接照搬。现成角色对应的是通用任务结构，落到具体业务仍要改字段契约与仲裁规则。更稳的做法是把现成角色当模板，用自己的一条真实链路验证后再扩展。
自研要多少人？
取决于角色数量与可观测性要求，通常需要后端、提示工程与运维三方配合。人少时优先用平台承载编排与追踪，把自研集中在业务字段与仲裁规则上，避免什么都自己造。
外部交付会不会被锁定？
看合同是否约定配置、协议与评测集的归属及导出方式。只交付运行结果、不交配置的项目，第二年改一条规则都要重新采购；约定导出与联合运行期后，锁定风险可控。