简短结论：AI Agent 不是 demo 能跑通就可以上线。真正的生产就绪，需要同时检查任务适配、数据权限、工具调用、提示注入、评估、可观测性、成本、沙箱、回滚、人工审批和事故响应。
生产环境里的 Agent 同时依赖模型、应用逻辑、工具、数据、用户权限和外部系统。任何一个环节失控，都可能导致错误操作、数据泄露、成本暴涨或不可解释的失败。因此，上线前应该用一套明确的 launch gate，而不是只看一次人工演示。
1. 先确认是否真的需要 Agent
不是所有 AI 功能都需要 Agent。上线前先问清楚：规则、结构化抽取、搜索或普通 RAG 是否已经足够？如果任务不需要多步推理、工具选择或跨系统行动，Agent 可能只是增加风险和成本。
- 任务是否必须跨多个步骤完成？
- 是否需要根据上下文选择不同工具？
- 错误操作是否可恢复？
- 新增成本和风险是否有业务价值支撑？
2. 设定评估门槛
上线前要定义哪些测试必须通过。至少应覆盖任务成功率、失败回归、提示注入、RAG grounding、工具调用正确性、延迟、成本和高风险场景人工复核。
OpenAI Evals 提供了结构化评估模型和应用输出的方法（OpenAI Evals guide）。如果系统会持续迭代 prompt、模型或检索索引，应配套建设 LLM 回归测试集。
3. 审查数据治理
列出 Agent 能看到、存储、检索、导出和写入的所有数据，包括用户输入、检索文档、工具输入输出、日志、trace、memory 和评估数据集。
- 敏感数据是否会进入 prompt 或日志？
- 租户、角色和权限边界是否在检索层生效？
- memory 是否有保存、删除和过期策略？
- 供应商和子处理方是否清楚？
4. 锁定工具和密钥
工具调用是 Agent 的主要风险面。每个工具都应该范围明确、参数可验证、权限可检查、日志可审计，并且高影响操作必须有审批。
- 读工具和写工具分开。
- 服务端注入凭证，不把密钥放进 prompt。
- 按用户、租户和角色做授权检查。
- 危险操作要求人工批准。
5. 加入可观测性和限制
生产 Agent 必须能被追踪。至少要记录 run ID、模型、工具调用、token、延迟、成本、错误、fallback 和审批结果。OpenTelemetry 的 GenAI semantic conventions 可用于统一遥测字段（OpenTelemetry GenAI semantic conventions）。
6. 设计失败隔离和恢复
要假设 Agent 会失败。生产就绪不是保证不出错，而是把错误限制在可控范围内。
- 高风险执行放入沙箱。
- 写操作前保存 checkpoint。
- 重试使用 idempotency key。
- 定义回滚负责人和人工停用开关。
- 把事故案例加入回归测试。
NIST SP 800-61 Rev. 3 提供了准备、检测、响应和改进的事故响应框架（NIST SP 800-61 Rev. 3）。
最小上线清单
- 确认 Agent 是正确工具，而不是过度设计。
- 设定任务成功、安全、延迟和成本门槛。
- 审查数据流、memory、保留和删除策略。
- 锁定工具权限、授权、密钥和审批。
- 加入 trace、指标、预算告警和审计日志。
- 准备沙箱、回滚、停用开关和事故响应。