智能体采购的过程验收，核心不是确认“最终答案是否正确”，而是验证系统能否在真实业务中稳定完成“理解任务—制定计划—调用工具—执行反馈—风险控制”的完整闭环。一个结果看似正确的智能体，如果绕过审批、读取无权访问的数据，或在异常后持续执行，仍不能视为验收通过。
先把验收对象从模型改成任务
采购方应以真实业务任务作为最小评测单元，而不是只测试单轮问答。任务描述中要明确目标、约束条件、可调用工具、权限边界、人工接管条件和预期结果，同时准备缺字段、信息冲突、数据过期、权限不足、工具超时等异常样本。
过程验收至少应检查四类能力：
- 任务理解：能否识别目标、优先级和不可执行部分，必要时主动澄清。
- 任务规划：能否拆解步骤，识别前置条件，并在执行失败后调整计划。
- 工具使用：能否选择正确工具、生成合规参数、理解返回结果，并避免重复或越权操作。
- 执行治理：能否记录关键过程，在不确定、异常或权限不足时暂停并转交人工。
最终结果、过程质量和治理质量应分别评价。结果质量关注任务是否完成；过程质量关注规划、工具调用和信息引用是否正确；治理质量则关注权限、日志、人工接管、数据处理和回滚能力。三者不能互相替代。
把验收设计成分阶段放行
更稳妥的做法是先在边界清晰、数据可控、结果可衡量的场景试点，再逐步扩大权限和覆盖范围。验收可以按照以下顺序推进：
- 只读验证：检查知识检索、分类、摘要等任务的准确性，以及数据范围是否符合授权。
- 受限执行：接入少量可回滚工具，验证参数生成、异常处理和状态同步。
- 人工协同：测试审批、二次确认和人工接管，确认系统不会把不确定判断伪装成确定结论。
- 持续运营验收：检查日志完整性、版本变更记录、回归测试和降级机制。
采购合同不应只写“支持多工具调用”或“具备长期记忆”，而应写成可验证条款：什么情况下必须停止、哪些操作必须审批、失败后如何保留现场、谁负责处理错误，以及何种指标达标后才允许扩大部署。对智能体而言，能在失败时安全停下，往往比偶尔生成更漂亮的答案更具交付价值。