差异一：异常分支
演示只跑通主路径，真实项目大量时间在处理例外，例如字段缺失、接口超时。编排平台把步骤写死，绕行靠分支堆叠；代码框架能写任意控制流，却要求工程能力。怎么试：拿三个月的异常工单看它能否描述清楚。
差异二：工具接入
内置连接器能快速接标准系统，遇到自建系统或老旧接口就要写适配层。怎么估接入量：先数清要调的系统数量、接口形态与鉴权方式，再看能否自定义工具与重试。接入方式决定后期加一个系统是半天还是两周。
差异三：审批中断
业务常需要人在环，例如对外发送、变更承诺、超限处理。平台能否配置中断点、审批回调与超时升级，直接决定它能不能进生产。边界是：没有中断点的平台只能做只读建议，不能执行有副作用的动作。
差异四：部署锁定
SaaS、私有化、混合三种形态决定数据能否出网，也决定迁移难度。怎么降低锁定：问清流程、提示词与工具配置能否导出，版本升级是否破坏兼容。锁定成本常在第二年显现，采购时就要把退出路径写进合同。
适用与不适用
适合谁
- 同时有两三个 Agent 场景准备落地的中大型企业
- 需要在编排平台与代码框架之间取舍的架构团队
不适合谁
- 只有一个简单问答、暂不涉及工具调用的团队
- 希望一套平台覆盖全部业务、不接受组合方案的决策者
典型场景
某集团的客服与合同审查同时立项，用同一套编排平台搭原型：客服顺利，合同审查卡在长文档切分与多级审批。架构师把两个场景的步骤数、分支数、外部系统数并排比对，最终客服用编排平台，合同审查改用代码框架加自建工具层，由业务负责人复核边界。
可执行步骤
- 列出两到三个候选场景，每个场景各取五条真实任务样本并标注验收人，清单留档备查
- 数清每个场景要接的外部系统、接口形态、鉴权方式与调用频率，并估算改造工时
- 在候选平台各搭一条最小链路，用同一批样本跑通并逐条记录失败原因，形成调试记录
- 统计人工接管次数、平均时延与失败原因，标出必须写代码才能实现的环节并折算工时
- 按差异表决定单平台还是组合方案，并在合同附件写明配置导出与迁移路径
常见坑
- 用供应商准备的演示场景评估，主路径很顺，长尾分支没人试，上线后一遇脏数据就停摆，返工成本远高于选型时间。
- 只看编排界面是否直观，不问工具接入方式与导出能力，第二年想换平台，流程和提示词全锁在对方账户里。
- 忽略审批中断点，平台只能给建议、不能执行有副作用的动作，业务部门试用两次就认为没用，项目因此搁置。
自检与验收清单
- 每个候选场景都有真实样本清单和明确验收人，并留档
- 外部系统清单、接口形态与鉴权方式是否已逐项列出
- 人工审批、接管与超时升级是否都能配置并演练，由负责人复核
- 流程、提示词与工具配置能否导出，退出路径是否写入合同
常见问题
可视化平台能不能做复杂业务？
能，但有条件。步骤固定、分支有限、接口标准的流程适合编排；涉及长文档解析、动态规划与复杂重试的任务，编排会越来越难维护，通常要退回代码框架，或用编排去调用自建服务。
多个平台混用会不会更难维护？
会增加运维面，但比强行统一更可控。做法是把模型调用、日志与权限收敛到统一网关，各平台只负责编排；同时约定升级窗口与责任人，避免几套系统各自演进、口径越来越散。
验证需要多长时间？
单场景两到四周足够看清主路径与常见异常。若任务涉及多系统联动，建议延长并加入故障演练；时间不足时优先保证样本真实，而不是增加演示场次，否则结论仍不可用，也很难向管理层解释。