维度一二：编排与可控
编排看多步任务能否表达分支、循环、重试与超时；可控性看有没有审批节点、人工接管与权限边界。怎么判断：让对方用你的一个真实流程现场搭一遍，观察出错时能不能停在安全位置，而不是继续往下执行，这一步最能看出产品成熟度。
维度三四：集成与评测
集成看工具调用方式、连接器数量与私有化能力；评测看能否回放轨迹、统计每一步的成功率。怎么验：要求提供一段失败轨迹的排查演示，能定位到具体步骤与工具返回，才算可运维，否则出问题只能整段重跑，排查成本极高。
维度五六：治理与运维
治理看日志留痕、数据边界与内容标识；运维看版本升级、并发能力与成本结构。怎么约定：升级前通知期、回滚方式与历史轨迹保留期限都要写进合同；否则平台一升级，原有流程可能集体失效，业务中断却找不到原因。
打分表怎么用
六个维度各给一到五分，编排与可控性权重最高，因为这两项决定能不能上生产。设一票否决项，例如没有审批节点、工具权限无法收窄、轨迹不可导出；总分怎么用：只用于排序，最终要落到一个可复现的试点流程上。
适用与不适用
适合谁
- 准备把多步流程交给 Agent 的企业
- 已有工具与系统接口、需要编排的团队
- 对审批与留痕有明确要求的行业客户
不适合谁
- 只需要单轮问答、没有多步流程的场景
- 无法提供工具接口、也不接受改造的系统
典型场景
某物流企业要选 Agent 平台处理异常件。评审组给每家一份真实流程：查运单、判断异常类型、生成处理建议、提交审批；要求现场搭建并演示一次失败分支。技术侧核对轨迹回放与权限收窄能力，合规侧确认日志留存期限，最后按六维打分。
可执行步骤
- 选一个多步流程，写明分支条件、异常场景与审批节点、失败路径与验收人
- 要求各家在评审现场搭建，并演示一次失败与人工接管，并记录接管耗时
- 核对工具权限能否按角色收窄，轨迹能否导出、回放与长期保留以及
- 确认升级通知期、回滚方式与历史轨迹的保留期限，并写进合同附件
常见坑
- 只看演示成功路径，失败分支没有接管机制，生产环境一出错就卡住，只能人工补单，责任也说不清。
- 工具权限给到最大，Agent 可以发起退款或直接改单，风险无法收窄，出事也难以追责。
- 轨迹不能导出，出问题只能整段重跑，无法定位是哪一步出错，排查时间成倍增加，定位全靠猜。
- 平台升级未提前通知，原有流程节点失效，业务中断半天，才有人想起要问版本与升级记录。
自检与验收清单
- 是否用真实的多步流程做过现场搭建与演示环节
- 失败分支是否设置了接管与安全停止机制人工
- 工具权限是否可以按角色收窄到最小，并留记录
- 轨迹是否可导出并支持回放复盘，并支持回放
- 升级通知期与回滚方式是否写入合同附件，并有样例
常见问题
Agent 和工作流引擎有什么区别？
工作流按预设路径执行，Agent 会根据中间结果决定下一步。前者可控、易审计，后者灵活但不确定；多数企业场景适合混合：关键步骤用固定流程，判断与生成交给模型，再由人复核关键结论。
要不要一开始就上多 Agent？
不建议。先用单 Agent 加清晰的工具边界跑通一个流程，确认稳定后再考虑拆分角色；多 Agent 会带来协作开销与调试难度，在流程尚未跑通时引入，通常只会放大问题，也拖慢上线，也要预留调试时间。
私有化部署是必需的吗？
看数据边界。涉及客户信息、图纸或报价的场景，通常需要专有环境或本地部署；通用内部工具可以先用云端并做好脱敏。无论哪种，都要确认日志归属、数据是否用于训练以及导出方式。