智能体项目验收，常见场景是供应商演示一遍，业务说“可以”，项目结束。
半年后系统出问题，大家才发现：知识库没人会更新，接口密码不知道在谁手里，验收标准也说不清。
交付不是交一个系统，而是交一套能继续运转的东西。
需求边界
第一份文档，写清楚项目做了什么，没做什么。
包括：支持哪些场景、不支持哪些场景、哪些问题必须转人工、哪些数据不能碰。
这份文档能防止后续扯皮。业务觉得“这个也应该能做”，供应商觉得“合同里没写”，有边界才好谈。
知识和数据清单
第二份文档，列清楚知识从哪里来。
文档名称、存放位置、更新频率、负责人、适用范围，都要写。
数据清单还要说明哪些是敏感数据、哪些需要脱敏、哪些不能给外部模型。
没有这份清单，系统上线后知识很快会过期。
接口和权限说明
第三份文档，写清楚系统接了哪些接口。
包括接口用途、调用方式、账号权限、失败处理、日志位置。
如果项目接了 CRM、OA 或工单系统，要标明读哪些字段、写哪些字段、谁有权确认。
换人接手时，这份文档能省很多时间。
测试集和验收报告
第四份文档，是验收证据。
测试集要来自真实业务，包含常见问题、边界问题和异常问题。验收报告写清楚测试结果、未通过项和处理方式。
不要只留一句“验收通过”。后面系统改版，测试集还要继续用。
运维手册
第五份文档，写清楚日常怎么维护。
知识多久更新一次，日志在哪里看，出现异常找谁，权限怎么回收，版本怎么回滚。
运维手册不用很厚，但要能让一个新同事照着做。
责任人和交接
最后，要明确上线后谁负责。
供应商负责什么，客户内部谁负责什么，出问题多久响应。最好写进合同或交接单。
交付时做一次交接会，让接手的人自己操作一遍，不要只看演示。
边界
不是所有项目都需要很重的文档。
但涉及客户数据、系统写操作和长期使用的项目，文档不能省。没有文档，系统越复杂，后续越依赖原供应商。
智能体公司的交付质量，不只看系统能不能跑，还要看客户能不能自己维护。
交付清单最好写进合同附件。不是不信任供应商，而是让双方对“交付完成”有同一套标准。后面换人、扩容、续约，也都用得上。
文档不要只放在供应商的网盘里，客户要有一套自己的存档。
如果你在选智能体公司，可以看我们的智能体定制服务，也可以从智能体公司报价单里哪些项目最容易漏开始，先问交付清单。