AI Agent 项目的验收对象不是一个“会聊天的页面”，而是一条受权限约束、可追踪的业务执行链。演示时答对，不代表面对数据缺失、接口超时或敏感操作时仍然可靠。
验收前先固定测试条件
验收用例应写明测试角色、数据范围、触发条件、预期动作和预期结果。同一个问题至少要覆盖正常数据、缺失数据和无权访问三种状态；涉及发消息、建待办、改字段等动作时，还要明确哪些步骤允许自动执行，哪些必须由人确认。
测试数据与正式数据要能区分。若 Agent 连接 CRM、ERP、钉钉或知识库，应记录所用数据源、更新时间和账号权限，避免把“碰巧答对”当成稳定能力。
正式验收也不要只在页面里点几下。应选一笔完整业务，从数据读取开始，连续经过审批、流转、提醒、报表和导出，逐个核对相关角色能否完成自己的动作；再用超期、驳回、重复提交、权限不足和数据缺失等异常用例复跑。这样才能验证 Agent 在正常链路和异常链路中的表现，而不是只验证演示脚本。
7 个检查点逐项验
- 正常问答：答案应引用约定的数据源，口径与业务系统一致，不用模型猜测补齐缺失字段。
- 权限拦截：无权查看的客户、合同、薪酬或财务信息不能出现在回答、摘要和日志明文中。
- 数据缺失：查不到数据时要明确告知缺什么，而不是生成一个看似完整的结果。
- 异常升级：遇到超期、冲突或无法判断的情况，能够转给约定岗位并附带上下文。
- 人工确认：付款、发消息、修改关键状态等高风险动作，应在执行前展示对象、内容和影响范围。
- 日志追踪：能查到请求、数据读取、工具调用、失败原因、人工介入和最终结果。
- 结果复盘：待办是否完成、异常是否关闭、处理结果是否回写，都能在原业务链路中核对。
数据正确性不能只看最终一句话
验收人员应把回答拆回字段：客户名称来自哪里，订单状态以哪个系统为准，时间范围如何计算，汇总是否排除了作废记录。若一个答案跨越多个系统，还要检查关联键和更新时间，避免旧数据与新数据混用。
对知识库问答，重点核对版本、引用来源和失效内容；对经营数据问答，重点核对筛选条件、统计口径和权限范围。两类场景不能共用一套模糊的“回答准确”标准。
工具调用要覆盖成功、拒绝和失败
Agent 能创建待办或更新 CRM，并不等于执行链已经可靠。验收时应分别测试参数完整、参数缺失、对象不存在、重复提交、接口超时和权限不足。系统需要给出可理解的状态，不能静默失败，也不能在重试时重复创建业务记录。
涉及不可逆动作时，确认页面应展示即将执行的内容；取消后不得留下半成品数据。执行成功后，业务系统中的记录、通知对象和 Agent 返回结果要相互一致。
日志和交接决定问题能否定位
交付物应说明提示词或规则配置位置、知识库来源、已接工具、账号权限、日志入口、常见错误和人工接管方式。验收发现问题时，要能区分是数据源、权限、流程规则、模型输出还是接口调用造成的，不能统一归为“效果不好”。
最终签字应对应具体用例和测试证据。仍未通过的用例、临时绕行方案及责任人单独列出，避免把演示通过等同于业务闭环完成。
