企业采购AI Agent：验收测试、日志与回滚清单

企业采购AI Agent别只看演示：先写验收测试、日志边界与回滚条件

AI Agent演示往往能在几分钟内完成一个看起来完整的任务，但企业采购需要回答更难的问题：在真实数据、权限限制、异常输入和依赖故障下，它能否稳定完成工作？发生错误时能否发现、停止、回滚并追溯？如果只根据演示视频或一次成功案例做采购决定，团队很容易把“能跑通”误认为“可以上线”。

一、把采购需求写成任务清单

明确Agent要处理的输入、输出、使用的系统、允许调用的工具、禁止操作和成功条件。不要只写“自动处理客服”“提升办公效率”，而要拆成可验证任务，例如读取指定范围的工单、按规则分类、生成建议回复、把不确定项交给人工确认。任务越具体，供应商越难用模糊演示掩盖能力边界。

列出正常场景、边界场景和失败场景。包括缺失字段、冲突指令、超时、权限不足、第三方API不可用以及重复提交。验收测试应在采购前确定，而不是在供应商演示后临时挑选容易通过的案例。

二、区分建议型Agent和执行型Agent

只生成建议的Agent与能修改客户资料、发送邮件、创建订单或调用付款接口的Agent，风险不同。对建议型系统，可以重点检查事实依据、错误率和人工复核成本；对执行型系统，还必须检查授权、操作范围、二次确认、幂等性和撤销能力。

采购合同应明确哪些动作可以自动完成，哪些必须经过人类审批。供应商声称“有安全护栏”并不足够，要现场测试越权请求、重复操作和异常工具返回时的行为。

三、把日志要求写进验收标准

企业需要知道一次操作由哪个模型版本、哪些工具、什么权限和哪些输入证据触发。日志应记录任务ID、工具调用、决策结果、错误类型、时间和配置版本，但不应默认保存全部客户对话、密码或敏感业务数据。日志字段和保留期限应在采购阶段明确。

要求供应商演示如何追踪一次失败任务：能否找到对应事件、区分模型错误与工具错误、查看是否发生外部副作用，以及确认重试有没有造成重复操作。若只能看到最终答案而无法解释执行路径，生产排障会非常困难。

四、评估总成本而非只看单次调用价

总成本包括模型调用、工具和第三方API、数据准备、集成、监控、人工复核、失败重试、培训和持续维护。一个单次调用很便宜的Agent，如果经常需要人工修正或重复执行，最终成本可能更高。建立一组代表性任务，记录成功完成的成本、平均人工介入时间和失败后的恢复成本。

不要把供应商提供的最佳演示速度当作生产SLA。测试高峰负载、长任务、外部依赖变慢和模型切换后的表现，并明确哪些成本由采购方承担。

五、要求明确的人工接管与回滚路径

系统应该能够在低置信度、权限冲突或外部工具异常时暂停并交给人类，而不是继续猜测。对于有副作用的操作，要求有预览、确认、撤销或补偿机制。回滚不一定能撤销已经发送的邮件或外部付款，因此要区分真正可逆的动作与只能补救的动作。

验收时测试断网、超时、重复回调、错误数据和权限撤销。确认人工接管后，操作者能够看懂Agent已经做了什么、还没有做什么，以及哪些结果需要复核。

六、用风险框架组织持续评估

NIST AI风险管理框架将工作组织为治理、映射、测量和管理等环节。企业可以将其转成采购流程：先定义责任人和用途，再识别风险，建立基准测试，最后监控上线后的偏差与事件。它不是一张自动通过的合规证书，而是一套帮助团队组织评估的框架。

把验收结果写入合同附件：任务集、成功标准、日志字段、数据边界、人工接管、故障通知、版本变更和退出方式。这样，采购决策不再依赖“看起来很聪明”，而是依赖能重复验证的生产能力。

七、用小规模试点验证供应商承诺

不要一开始就把Agent接入所有生产系统。先选一个范围明确、可回滚、失败成本可控的流程，建立基线数据，再运行一段时间。试点期间记录成功完成率、人工接管率、错误恢复时间、单任务总成本和权限异常。对供应商宣称的功能逐项留证，未在试点中验证的能力应标记为待验证，而不是写进上线结论。试点结束后，由业务、技术、安全和采购共同决定扩大、整改或停止。这样的阶段门可以避免一次演示就触发大规模采购，也能让合同条款与真实运行表现相互对应。