智能体项目的验收，不能只看“能不能聊天”，而应验证它是否在明确边界内稳定完成任务。尤其是接入企业知识库、订单、会员、客服或管理系统的项目，验收对象不是一个对话页面，而是由模型、知识检索、业务接口、权限体系和异常处理共同组成的业务系统。若合同只写“实现 AI 问答”，后续很容易出现演示效果良好、实际无法使用的争议。
先把验收范围写成可执行场景
验收标准应按真实任务拆分，而不是按“功能已开发”判断。至少要明确：
- 智能体能回答哪些问题，哪些问题必须拒答或转人工；
- 企业资料是否支持上传、更新、删除、分类和版本管理；
- 回答是否需要展示引用来源，用户权限是否影响检索结果；
- 查询订单、创建工单、预约服务等动作需要哪些身份信息；
- 业务接口失败、超时或返回异常时，是否给出明确提示，而不是编造结果；
- 用户输入错别字、问题模糊或超出资料范围时，系统如何处理。
每个场景都应配套测试问题、预期行为和验收结果。不能只准备标准提问，也要加入资料中没有答案的问题，以及故意缺少必要信息的任务。
把“回答正确”拆成多项指标
知识库验收重点不只是“能搜到文件”，还要检查资料清洗、内容切分、权限控制和引用是否符合需求。资料过期、重复或互相矛盾时，系统应能暴露不确定性，不能将推测包装成确定答案。
业务执行类智能体则应重点检查权限、参数校验和状态一致性。例如，用户没有足够身份信息时不得直接查询；接口执行失败时不能声称操作成功；涉及价格、优惠、售后等内容时，必须遵循约定口径。后台的 Prompt、知识文档、会话、调用量和错误日志，也应纳入验收范围。
单独验收非正常场景
上线前应进行兼容性、压力和安全检查，并验证流式输出、会话记录、文件上传、转人工、敏感内容拦截等交互。对于面向公众的项目，还要明确并发量和响应要求；对于内部使用，则应重点确认权限隔离和资料范围。
最终验收文件应同时写清功能边界、模型调用费用、知识库范围、业务接口清单、异常处理方式和后续运维责任。只有把“什么情况下算完成”写成可复现的测试条件，智能体项目才不会停留在一次成功演示上。
