站在 IT 或数字化负责人的角度，智能体项目的难点从来不是"做出来"，而是"敢不敢放上线"。
演示会上一切顺利，上线后数据不全、权限不对、写回失败、没人敢担责——这类场景太常见了。
问题出在哪？验证的范围不对。
上线前要验证的不是"能不能跑通"，而是三类用例：正常、异常、越权。
| 差异点 | 演示环境 | 生产环境 |
|---|---|---|
| 数据 | 精心准备的样例 | 有缺失、有脏数据、有历史格式 |
| 权限 | 通常用高权限账号 | 岗位/组织边界复杂 |
| 异常 | 一般不演示 | 超时、重复提交、审批驳回 |
| 责任 | 演示者承担 | 必须事先写明 |
验证清单的本质，就是把这四类差异逐一测掉。
关卡一：准确性与来源（查询类必测）
关卡二：授权与审批（执行类必测）
关卡三：写回与异常处理
写入类步骤单独验证四项：参数校验、权限校验、幂等与重复提交、异常恢复。
这里有个必须反复强调的认知：
不能把"数据库连通"等同于"业务集成完成"。
能连上库只说明网络通，字段映射、校验规则、审批流程、幂等控制这些业务语义层面的事一件都没解决。
关卡四：权限边界（最容易被跳过）
做法很简单——用不同岗位访问同一份数据做交叉验证：
另外，不要用一个统一的高权限系统账号去取数。工程上省事，合规上是重大缺陷——权限校验实际上被绕过了。
关卡五：成本与稳定性
单次任务消耗、长流程耗时、高峰期排队与超时。
关卡六：责任与运维
运行记录是否可追溯（身份、输入及引用来源、模型与配置版本、工具调用、审批、处理结果）；出错后找谁、多久响应、怎么回滚。
| 类型 | 测什么 | 不测的后果 |
|---|---|---|
| 正常用例 | 标准流程能否跑通 | 基本功能不可用 |
| 数据缺失用例 | 缺字段、格式异常时怎么办 | 生产环境大面积报错 |
| 权限不足用例 | 越权能否被正确拦截 | 数据安全事故 |
这三类样例要在 POC 开始前就准备好。
结束时交付：测试结果、问题清单、后续实施建议。不必每次都覆盖所有功能。
不要使用"零错误"这类绝对承诺。
① 迁移的智能体必须重新验证。 提示词、知识文档、工具接口、测试用例可能可复用，但编排方式、记忆机制、权限体系、运行机制往往要调整，迁移后需重新跑效果验证。
② 投入按任务拆分估算，别一口价。 一定有效果调优工作量；涉及企业数据、功能、组织权限、复杂流程、文档质量整理时还需集成与顾问支持。完整计划至少包含：数据/知识准备、接口开发、RAG 建设、智能体配置、测试和调优。
