同一份任务脚本
把三到五个多步任务写成脚本，含正常、异常与越权三类场景，发给每家按同一接口实现。怎么保证可比：工具接口统一用同一套模拟服务，避免因对接差异影响结果；脚本与预期结果提前封存，评完再公开。
比较完成率与步数
完成率看能不能跑完，步数看效率与成本。怎么解读：完成率高但步数明显偏多的方案，长期调用成本更高；完成率低但失败集中在越权场景的，可能只是权限设计保守，要分开看，不能只用一个数字排序。
人工介入与可诊断
统计每个任务需要人工介入的次数，以及失败时能否定位到具体步骤。怎么判断：让对方现场排查一条失败轨迹，若只能重跑或翻日志猜，说明可运维性不足，上线后每次异常都要找厂商，响应速度无法保证。
导出与迁移
比较流程定义、轨迹与提示词能否导出，迁移到其他平台需要多少改造。怎么约定：在合同里写明导出格式与协助义务；忽略这条，试点成功后想换平台，等于把已经投入的流程重做一遍，议价空间也会被锁死。
适用与不适用
适合谁
- 手上有两家以上 Agent 平台在比较的企业
- 准备用试点验证多步流程的团队负责人
- 希望保留后续迁移空间的架构负责人
不适合谁
- 只需要单轮问答、没有流程编排需求的项目
- 无法提供工具接口或模拟服务的系统
典型场景
某银行比较三家 Agent 平台做贷后回访准备。项目组提供五个任务脚本与一套模拟客户接口，要求各家在一周内跑通；记录完成率、平均步数与人工介入次数，并让每家现场排查一条失败轨迹，最后按清单打分，选定一家进入试点。
可执行步骤
- 写五到十个多步任务脚本，覆盖正常、异常与越权三类场景，并写明预期结果
- 为各家提供同一套模拟工具接口，避免因对接差异影响最终的比较结果
- 记录每家的完成率、平均步数与人工介入次数，做成一张横向对比表
- 要求对方现场排查一条失败轨迹，据此评估平台的可诊断性与响应速度
常见坑
- 各家用自己的演示环境，任务与接口都不同，结果无法比较，评标变成看谁讲得好，决策没有依据。
- 只看完成率不看步数，长期调用成本高出数倍，预算在半年后被迅速消耗，再想调整已经晚了。
- 失败排查只能整段重跑，问题反复出现，运维逐渐依赖厂商，响应时间被对方掌握，议价能力随之下降。
- 没有约定导出格式，试点成功后想换平台，已投入的流程只能重做，只能被动接受报价。与排期。
自检与验收清单
- 任务脚本是否覆盖正常、异常与越权场景三类
- 工具接口是否统一为同一套模拟服务与账号，避免差异
- 是否记录完成率、步数与人工介入次数，并纳入评分
- 是否要求对方现场演示失败轨迹的排查与恢复
- 导出格式与迁移协助的义务是否写入合同条款
常见问题
试点要跑多久？
两到四周比较合适，覆盖一个完整流程与至少一次异常处理。时间太短看不到稳定性，太长则成本高；关键是预先约定观察指标与停止条件，避免试点变成无限期的免费开发工作。
步数越少越好吗？
通常如此，但要结合完成率看。步数少可能是因为跳过了校验步骤，短期看起来高效，长期出错率更高。建议把步数与失败类型放在一起分析，找出既稳又省的配置，再决定是否推广。
能不能只看价格选？
不建议。Agent 平台的价格与调用量、并发、私有化程度相关，低价方案往往在权限、审计或导出上有限制；把这些限制换算成后续改造与运维成本，再与报价一起比较，才是完整的判断。