AI智能体的任务成功率，不能用一次演示是否顺利来衡量。企业应先定义任务边界：什么结果算成功，哪些步骤允许人工介入，出现何种情况必须判定失败。只有将目标、输入、输出和责任节点固定下来，成功率才具有比较价值。
从“完成任务”而不是“生成内容”开始评估
评测单位应是完整任务，而非某一步调用是否正确。例如，智能体即使成功识别请求，却未能正确调用业务系统、遗漏审批或输出无法使用的结果，仍不能算任务成功。企业可以按任务类型建立评估集，记录成功、部分完成、失败和主动转交人工等结果，并同步记录响应时间、调用成本和人工复核情况。
更重要的是，成功率必须附带测试条件。评估记录至少应说明：
- 任务输入和预期输出；
- 使用的模型或智能体版本；
- 可访问的工具、系统和数据范围；
- 人工介入节点及介入频率；
- 失败样本、异常原因和不可适用场景。
如果只披露平均成功率，却不说明任务类型和失败边界，这个数字就不足以支持采购决策。高风险任务尤其不能被低风险场景的平均结果掩盖。
把回滚设计成可执行的控制机制
回滚不是简单的“恢复旧版本”，而是错误发生后迅速限制影响、撤销操作并恢复业务状态的完整机制。企业应分别验证三类能力：能否立即暂停智能体执行，能否撤销或恢复已经写入的数据和业务动作，能否恢复到可审计的模型、流程或权限版本。
评估时应主动设置异常情形，而不是等生产事故发生后再检查。例如，工具返回错误、输出缺少关键字段、权限被扩大、任务陷入重复执行时，系统是否自动停止，是否保留操作日志，是否能由指定人员确认后恢复。对于付款、合同、生产配置、客户权益和敏感数据等操作，回滚路径必须在上线前完成演练，并明确人工接管和退出条件。
最终，企业应把“成功率”和“可回滚性”放在同一张评估表中：前者回答智能体能否稳定完成任务，后者回答失败后能否控制损失。只有任务结果可复核、权限边界可管理、异常状态可恢复，自动化才具备进入生产环境的基础。