วิธีนำ AI Agent ขึ้นใช้งานจริง: คู่มือจากเดโมสู่ระบบที่กู้คืนได้ สังเกตการณ์ได้ และย้อนกลับได้

上线路线图：先定义边界，再逐项验收

AI Agent如何部署到生产环境，关键不是增加模型或编排复杂度，而是让任务失败时可判断、可恢复，变更时可验证、可回退。建议按顺序定义任务和完成条件、选定运行形态、建立运行时与状态存储、落实安全边界、开展代表性任务评测，再进行小流量灰度并安排值班与回滚。

先明确触发条件、输入、允许调用的工具、最终业务结果、超时处理和人工确认节点。固定流程已满足需求时，不必为了“Agent 化”引入多 Agent。工作流与 Agent 的取舍可参考 Anthropic 对 Agent 构建方式的讨论。系统接口接入和工具权限详见 AI Agent 如何对接企业现有系统。

选择部署形态：按约束做取舍

下表用于比较架构约束，不代表性能或价格结论；候选平台的能力、配额与运维责任应按其现行文档核对。

通过模型 API 使用推理时，部署对象通常是应用运行时、受控工具和状态服务；是否自建推理环境另按延迟、数据边界、模型可用性和运维要求评估。Kubernetes Deployment 文档可参考其滚动更新与修订回退机制，但不意味着 Agent 必须部署在 Kubernetes。

最小生产架构：连接请求、执行、状态与观测

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

短任务可等待结果；超过调用方等待窗口或需要跨进程恢复时，可返回任务 ID，由客户端查询状态或接收完成通知。定义任务状态、取消语义、超时边界和结果读取权限。

系统接入不在此重复展开，见前述 AI Agent 如何对接企业现有系统。值班与工程协作职责可参考 FDE 的工程交付职责与协作边界，具体责任需在项目中明确。

发布物准备：让变更可复现

将代码、依赖锁文件、运行镜像、环境配置、提示词模板、模型与工具配置版本纳入变更记录。依赖在构建中校验；开发、测试和生产环境分离；凭据通过受控配置机制注入，不写入代码仓库或普通日志。模型 API 密钥、工具服务凭据和业务身份分别管理。

发布清单至少应确认：

• 运行入口、健康检查、资源限制与关闭信号处理已验证；
• 依赖版本、镜像摘要和配置变更可追溯；
• 提示词、工具契约、模型标识及关键参数有版本记录；
• 回归样本与评测结果能关联到发布版本；
• 回滚目标版本可启动，并能读取当前状态格式或明确拒绝处理。

长任务恢复：检查点不等于业务恰好执行一次

可恢复性涉及任务记录、执行状态和业务副作用三个层面：任务是否排队、运行或等待人工；执行到哪些步骤；外部系统写入是否成功。仅保存对话文本未必足以恢复执行现场，仅有检查点也不能证明外部写操作结果。

以 LangGraph 为例，文档区分按线程保存执行状态的 checkpointer 与跨线程共享数据的 store。进程重启后恢复需要适用的持久化后端，并验证写入、读取、隔离、保留及故障恢复；内存型保存器不能作为跨重启持久化依据。详见 LangGraph Persistence 文档。

重试策略要区分单次尝试超时、可重试错误与重试耗尽后的处理。有副作用的工具应设计幂等键或去重机制，重试前先查询业务结果：调用超时不代表写入没有发生。无法确认时转人工核对或执行补偿流程；检查点、队列和重试本身不构成端到端 exactly-once 保证。参见 LangGraph 故障处理文档。

安全控制：为高风险动作设置阻断条件

发布前至少验证：

• 外部文档、网页和用户输入不能自行扩大工具权限；
• 工具服务逐次校验身份、资源范围和参数，高影响动作需明确人工确认；
• 凭据按环境隔离并可轮换，日志按敏感级别最小化、脱敏并设置保留周期；
• 审批记录关联请求、操作者、拟执行动作与最终业务结果；
• 越权、提示注入、重复提交和敏感数据外泄测试均有预期拒绝结果。

OWASP Agentic AI 威胁与缓解资料可辅助构建威胁清单，但不构成本系统安全或合规的证明。

评测门禁：同时看结果与过程

不要把 Agent 自述“已完成”当作验收。为每类任务定义环境中可核实的成功条件，如目标记录状态、输出格式和禁止动作；保留执行轨迹，以定位规划、工具调用或结果校验中的失败。可参考 Anthropic 的 Agent 评测方法说明。

样本应覆盖正常输入、缺字段、冲突信息、工具超时、权限拒绝、重复请求和外部内容诱导。重要样本可多次运行并记录结果波动。发布门禁可包含任务结果、禁止动作、异常处理、恢复演练和人工接管路径；阈值依据业务风险、既有基线和测试结果确定。

监控：质量、延迟、恢复与成本

为指标定义口径、采集位置、告警条件与责任人：

轨迹用于定位多步执行偏差，业务最终状态用于确认任务完成。日志的脱敏字段、访问范围与保留期限需按项目确定；上线初期观察基线，再按业务风险调整告警阈值。

灰度、回滚与在途任务处置

发布前对代码、提示词、模型配置和工具契约组合做回归；先在受限流量或低风险任务验证，再逐步放量。设置停止条件，例如业务结果异常、越权测试失败，或错误与延迟超过团队定义边界。

故障时暂停接收新任务或关闭高风险工具，盘点运行中、等待中和已完成任务，核实外部副作用，再回退到已验证版本。验证旧版本与现有状态格式是否兼容；无法自动恢复的任务转人工或执行经批准的补偿。Kubernetes Deployment 可作为采用 Kubernetes 时的发布参考；应用回退不会自动撤销已发生的业务写入。

教学演练：用故障注入验证恢复路径

以下是教学演练设计，不是客户案例或实测成绩。设定任务为“生成报告，人工确认后写入结果”，每次记录预期、实际结果与证据：

演练应核对业务状态、执行记录与预期是否一致，并明确异常任务责任人和处置路径。

上线验收清单

• 任务范围、完成定义、禁止动作与人工确认点已书面化。
• 部署形态与任务时长、恢复要求及团队运维能力相匹配。
• 依赖、镜像、提示词、模型配置和工具契约可追溯。
• 任务状态、持久化与业务副作用分别可核验，重试有幂等保护。
• 权限、提示注入、敏感日志与人工审批通过测试。
• 评测覆盖代表性任务、异常样本、结果验证和恢复场景。
• 指标定义、告警责任人、灰度停止条件和值班流程已确认。
• 回滚版本、在途任务、状态兼容与业务补偿路径已演练。

常见部署问题

问：一定要用 Kubernetes 吗？ 答：不一定。团队已有满足任务时长、状态恢复、网络隔离和运维要求的平台时，不必为了 Agent 增加集群复杂度。

问：部署 Agent 是否需要自建模型？ 答：不一定。通过模型 API 使用推理时，通常部署应用运行时、受控工具和状态组件即可；自建推理另行评估数据边界、延迟、可用性与运维要求。

问：服务重启后任务会丢失吗？ 答：取决于任务记录、执行状态持久化和恢复流程验证。仅依赖进程内存不能支撑跨重启恢复，还要核实外部写操作是否成功，避免重复执行。

问：如何防止重试造成重复写入？ 答：为业务操作设计幂等键或去重记录，重试前核对外部系统状态。无法确认时暂停自动重试，转人工核对或走补偿流程。

问：上线成功率阈值该设多少？ 答：没有通用数值。依据任务风险、业务基线和测试结果设定门禁与告警，同时验收禁止动作、人工接管、恢复和业务结果。