企业智能体项目最容易失控的地方，不是模型回答得不够流畅，而是“交付完成”缺少可判定标准。一次现场演示只能证明系统能够完成某次操作，不能证明它已经嵌入真实流程、能够持续运行，更不能证明业务价值已经成立。可验收的交付标准，应把智能体从“能力展示”转化为“任务闭环、结果证据和责任边界”。
先定义可验收的业务任务
“建设企业智能体”不是合格的验收目标。目标应改写为具体任务，例如处理某类工单、完成知识查询、辅助生成内容，或减少重复录入。每项任务都要明确输入、处理过程、输出结果、责任人和例外情况。
其中，输出不能只包括一段文本，还应说明是否完成了系统调用、业务流转或人工转交。涉及生产控制、安全判断、对外发布等高风险环节时，必须明确哪些动作由智能体执行，哪些动作必须经过人工确认。
用业务指标替代主观评价
验收指标应围绕真实任务设置，而不是只评价回答是否自然。可根据场景选择处理时长、一次通过率、人工介入率、错误率、结果可追溯性和异常升级效率等指标，并与上线前的基线水平进行比较。
不同场景不能套用同一标准。工业场景更关注稳定性、权限和安全隔离；餐饮场景需要核对门店差异、库存数据和执行情况；内容与品牌场景则应增加事实核验、版权审查、品牌一致性和最终发布责任。指标必须对应业务风险，否则“效果提升”可能只是表达质量提升，并未带来经营结果。
把测试证据写进方案
验收方案至少应说明测试样本来自哪里、数据是否真实、测试过程是否包含人工校正、异常如何处理，以及结果由谁测量。对于展示案例，还要追问系统是否在真实环境中持续运行，是否有明确的业务指标，人工参与处于什么范围。
数据和系统条件同样属于交付内容。数据来源、更新频率、访问权限、接口能力和知识有效期如果没有确认，模型表现再好，也可能无法进入生产流程。验收不能只测模型，还要测数据链路、权限控制、日志留痕和人工升级机制。
明确上线后的责任边界
智能体交付不是项目结束，而是运营责任的开始。模型供应商、平台方、实施方和业务部门，应分别明确数据责任、流程责任、模型变更、故障响应、审计留痕和退出机制。还应约定知识更新、工作流调整和异常复盘的处理方式。
真正可验收的企业智能体，最终应回答五个问题：完成了什么任务，结果如何衡量，异常由谁处理，证据是否能够复核，系统变化后谁负责维护。只有这五个问题都能在方案和运行记录中找到答案，智能体才算从“能回答”进入了“可交付”。