适用场景
这篇指南适合：
- 正在做 AI Agent 项目、即将决定是否上线的技术负责人
- 需要对 Agent 做生产准入审查的 FDE 或质量工程师
- 需要向业务方解释"为什么还不能上线"或"可以上线了"的项目经理
核心问题
一个 AI Agent 在测试环境跑得很好，不代表它可以进入生产环境。测试环境和生产环境的差异不在于"功能"，而在于"后果"。
在测试环境中，Agent 输出错误了可以重跑。在生产环境中，Agent 给客户发了错误信息、做了错误的数据修改、或者在关键时刻不可用，后果可能是不可逆的。
四层评测框架
第一层：任务层（Task Readiness）
核心问题：Agent 能可靠地完成它被分配的任务吗？
| 检查项 | PASS | FAIL |
|---|---|---|
| 任务完成率 | 在代表性数据上达到团队预先冻结的准入阈值 | 只在精选数据上测过 |
| 边界输入处理 | 空输入、超长输入、多语言混合有合理处理 | 未测试或直接报错 |
| 幻觉/编造控制 | 有检测机制 + 回退策略 | 完全依赖模型自身 |
| 延迟 | P95 延迟 < 业务可接受阈值 | 未测量或超过用户耐心极限 |
| 确定性 | 关键输出稳定，相同输入结果一致 | 每次运行结果差异过大 |
第二层：系统层（System Readiness）
核心问题：支撑 Agent 运行的系统基础设施是否可靠？
| 检查项 | PASS | FAIL |
|---|---|---|
| 高可用 | 有降级策略；单点故障不导致全部不可用 | 单个 API Key 失效导致整体宕机 |
| 日志与审计 | 每次调用有完整日志；可追溯输入、输出和决策过程 | 只有 console.log；无法事后审查 |
| 权限与认证 | Agent 使用最小权限；敏感操作有人工确认 | Agent 有管理员权限；无操作确认 |
| 成本控制 | 有调用量限制和成本告警 | 无限制，可能因异常循环产生高额账单 |
| 回滚 | 可以快速切回旧版本或人工模式 | 上线后无法回退 |
第三层：业务层（Business Readiness）
核心问题：Agent 上线后业务方准备好了吗？
| 检查项 | PASS | FAIL |
|---|---|---|
| 业务 Owner | 有明确的业务方负责人，对结果负责 | 只有 IT 在推动，业务方旁观 |
| 异常流程 | Agent 出错时有人工兜底流程 | Agent 出错了没人管 |
| 成功指标 | 有明确的基线和目标值 | "用起来就行" |
| 合规审查 | 通过数据安全、隐私和行业合规审查 | 未做合规审查或存在未解决的合规风险 |
第四层：采纳层（Adoption Readiness）
核心问题：目标用户准备好使用 Agent 了吗？
| 检查项 | PASS | FAIL |
|---|---|---|
| 用户培训 | 种子用户完成培训并能独立使用 | 没有人知道怎么用 |
| 反馈通道 | 用户可以方便地报告问题和建议 | 没有反馈入口 |
| 回退选项 | 用户知道如何回到旧方式 | 旧系统已下线，没有退路 |
| 渐进推广 | 按风险分批上线，每一批都设观察窗口和停止条件 | 一次性全面推广 |
执行步骤
- 对照四层清单逐项评估——每层的每个检查项标记 PASS/FAIL/NA
- 按风险裁决——阻断项和普通改进项分开管理，阈值由业务 Owner、安全与技术负责人在测试前冻结
- 四层均满足准入合同才进入 Production——任何阻断项不通过，都需要修复、降级或由有权限的负责人书面接受风险
- 记录豁免项——如果某个 FAIL 被决定接受（风险接受），需要有明确的负责人和风险说明
停止条件
- 任务层存在未解决的阻断项——Agent 本身还没准备好，不应该进入上线讨论
- 第三层的合规审查 FAIL——法律风险，必须先解决
- 没有业务 Owner 愿意为上线结果负责——这是最常见的"软性"停止信号
常见失败模式
- "测试环境都通过了"——测试环境的数据量、并发量和异常情况都不能代表生产环境
- "用户会慢慢学会的"——没有培训和支持，用户只会慢慢放弃
- "先上线再说"——上线后发现权限没控制好或日志不全，修复成本远高于提前准备
- "Demo 效果很好"——Demo 的数据是精选的，用户是配合的，环境是理想的
下一步
如果你需要一份更详细的上线清单，可以使用我们的模板：AI 落地清单。