部署
部署智能体 AI 系统所需的实践，远超标准软件部署的范畴。智能体具有非确定性、有状态性，且能够执行真实世界中的操作——这意味着部署失败的影响范围，远比典型服务更大。
概述
GenOps（生成式运营）是 MLOps 面向智能体系统的进化形态。与传统 MLOps 的主要差异如下：
| 维度 | 传统 MLOps | GenOps |
|---|---|---|
| 输出类型 | 确定性预测 | 非确定性的生成式响应 |
| 评测方式 | 准确率、F1、AUC | 相关性、连贯性、安全性、对齐性 |
| 版本管理对象 | 模型权重 + 数据 | 模型 + 提示词 + 上下文 + 工具 |
| 回滚触发条件 | 准确率下降 | 质量退化、安全违规、成本激增 |
| 扩缩容单元 | 推理副本 | 智能体实例 + 工具容量 + 记忆存储 |
最佳实践
| 关键挑战 | 描述 | 经验教训与备选方案 | 采用的解决方案 |
|---|---|---|---|
| 大爆炸式发布 | 将智能体变更一次性发布给所有用户，存在大范围质量退化的风险 | 仅尝试过功能开关；仍有过多用户暴露于损坏的提示词 | 采用金丝雀发布——将 5% 的流量路由至新版本，在全量发布前监控质量指标 |
| 提示词版本管理 | 提示词变更与代码变更同等重要，但往往缺乏追踪 | 将提示词存储在代码注释中，无历史记录，无法回滚 | 将提示词视为源代码管理中的版本化产物，并将提示词版本与部署版本绑定 |
| 环境一致性 | 由于工具配置或模型版本不同，智能体在开发与生产环境中的行为存在差异 | 各环境使用不同模型版本，Bug 只在生产环境中出现 | 按环境固定模型版本和工具配置；使用基础设施即代码（IaC）管理智能体配置 |
| 有状态智能体重启 | 在任务执行中途重启智能体会丢失进行中的状态 | 依赖客户端重试，用户工作成果丢失 | 实现检查点机制（LangGraph checkpointers、通过 Restate 实现持久化执行），使智能体能从上次已知状态恢复 |
| 失控的智能体循环 | 智能体可能陷入无限工具调用循环，耗尽无限制的 Token 和时间 | 仅设置全局超时；智能体在停止前仍会耗尽预算 | 强制执行每次调用的步骤上限和 Token 预算；对工具调用频率实施熔断器 |
| 多智能体协调失败 | 在多智能体系统中，一个智能体的失败会无声地级联传播 | 假设智能体能够自我修正，结果它们却放大了错误 | 在智能体之间定义明确的交接契约；在每个交接边界验证输出 |
| 编排循环 | 编排者反复循环委派任务，导致无限制的成本积累 | 仅设置全局超时；智能体在停止前仍会耗尽预算 | 实现显式步骤计数器、循环检测和强制终止条件；AWS Step Functions 原生支持最大执行时间和步骤数限制——从第一天起就应配置这些限制 |
| 无 Schema 的交接 | 交接边界处使用自由格式的自然语言，导致静默失败和上下文损坏 | 为了灵活性在智能体间传递自然语言摘要，下游智能体对其产生误解 | 要求每个交接节点的输出都经过 JSON Schema 验证；验证失败时向编排者返回结构化错误——绝不在 payload 可能损坏的情况下继续执行 |
| 交接 payload 膨胀 | 在智能体之间转发冗长的 payload 会使上下文窗口膨胀，降低推理质量 | 为保证完整性，在任务对象中转发完整的中间结果 | 仅包含下一个智能体所需的内容；将中间结果存储在 S3 中，并在 DynamoDB 任务状态中通过指针引用 |
| 工具依赖的扩缩容 | 智能体横向扩缩受到下游工具 API 速率限制的制约 | 在不扩展工具容量的情况下扩展智能体副本，立即触发速率限制 | 将工具容量视为一等约束条件；为工具调用实现队列和背压机制 |
| 部署回滚 | 当记忆存储已被修改时，回滚智能体部署会变得复杂 | 回滚了代码但未回滚记忆，导致智能体行为不一致 | 实现记忆版本控制或带回滚标记的仅追加记忆；定期测试回滚流程 |
| 未经验证的自提示循环 | 计划任务或自我馈送循环（自动化、/loop、/goal）在无人审查每个步骤的情况下发布变更 |
将"循环报告已完成"视为正确性的证明；未经审查的回归进入了生产环境 | 为每个自我馈送循环配备独立的验证子智能体或评分模型——循环的"完成"是一个声明，而非证明；参见 Loop Engineering |
规划模式
规划模式是由运行框架（harness）在运行时强制执行的模式，而非提示词中的一段说明。适用于非平凡、模糊、多步骤、高影响或高风险的任务。
规划模式允许：读取、搜索、提出澄清性问题、比较方案、起草计划产物、评估风险。
规划模式阻止：写入、发送、删除、支付、权限变更、部署、外部承诺，以及其他不可逆的副作用。
在以下情况进入规划模式：存在多种有效策略；工作涉及多个系统；副作用难以撤销；工具执行代价高昂；任务将超出单个上下文窗口。
将计划以持久化产物的形式存储在提示词之外。在执行高风险步骤之前，请求包含摘要、具体操作、风险级别、预期结果、回滚路径和范围的审批。如果计划发生重大变更，需再次请求审批。
步骤预算
每个基于循环的智能体都需要在运行框架代码中强制执行明确的预算：
| 预算项 | 描述 |
|---|---|
max_model_turns |
每次运行的最大模型调用次数 |
max_tool_calls |
最大工具调用总次数 |
max_parallel_tool_calls |
并发工具调用上限 |
max_wall_time_seconds |
硬性挂钟超时时间 |
max_input_tokens |
每次调用的上下文预算 |
max_output_tokens |
输出长度上限 |
max_total_cost |
以美元/额度为单位的成本上限 |
max_tool_result_chars |
每次工具调用的结果大小上限 |
max_retries_per_tool_call |
结构化失败前的重试上限 |
当任何预算耗尽时，以结构化状态停止：{ "status": "stopped", "reason": "step_limit_reached", "completed": false, "next_safe_action": "..." }。绝不静默地耗尽预算。
目标式循环
目标是具有可衡量完成条件的持久化目标。当智能体需要跨越多个步骤、工具调用或会话持续推进时，使用目标式循环。
目标状态应持久化存储在提示词之外：
objective: "..."
status: active | paused | completed | blocked | cancelled
scope: "..."
done_condition: "..."
budget:
max_steps: 30
max_cost: "..."
max_wall_time: "..."
checkpoints:
- "..."
validation:
- "..."
forbidden_actions:
- "..."
approval_required_for:
- "..."
progress_log_ref: "..."
好的目标示例："分析最近 200 条支持升级工单，分类出有证据支撑的前五大可重复原因，针对每个原因提出一项运营改进措施，并在报告通过来源核查和 PII 脱敏清单后停止。"
糟糕的目标示例："改善支持运营。"
一个好的目标应包含：单一目标、有界范围、源材料、允许的工具、禁止的操作、预算、检查点、验证方法和停止条件。
MVP 构建顺序
对于新的领域智能体，请按以下顺序推进。每个步骤应通过评测后再进入下一步：
- 构建手动的"模型-工具-观察"循环
- 添加严格的工具 Schema 和本地验证
- 添加运行时权限检查
- 添加结构化工具结果和错误观察
- 添加步骤和成本预算
- 添加链路追踪日志
- 添加感知提示词缓存的上下文排序
- 为高风险任务添加规划模式
- 添加上下文压缩
- 为可复用工作流添加技能（skill）
- 添加具有权限范围限制的 MCP/外部连接器
- 仅在基础智能体通过评测后再添加目标式循环
- 仅在分解能提升可测量结果时添加子智能体
- 添加定期的熵清理工作流
运营成熟度等级
| 等级 | 特征 |
|---|---|
| 1 – 基础级 | 手动部署、基础日志记录、手动扩缩容 |
| 2 – 自动化级 | CI/CD 流水线、全面监控、自动扩缩容 |
| 3 – 智能化级 | 自愈能力、预测性分析、多智能体协调 |
| 4 – 自主化级 | 完全自主的运营决策、自优化生态系统 |
核心基础设施栈
容器编排：Kubernetes 用于智能体部署，Docker 用于容器化，服务网格用于智能体间通信
CI/CD：GitHub Actions / GitLab CI 用于构建流水线，ArgoCD 用于基于 GitOps 的部署，Helm 用于 Kubernetes 管理
持久化执行：Restate 用于重试、容错、定时器和调度——作为反向代理处理智能体工作流的持久化异步执行
云平台：Google Vertex AI、AWS Bedrock / AgentCore、Azure AI Foundry——各平台均提供托管智能体运行时，内置扩缩容和可观测性能力
评测门控部署
这是 Google AgentOps 实践中的核心预生产原则：任何智能体版本在到达用户之前，都必须先通过全面评测，以证明其质量和安全性。这将手动的不确定性转化为自动化的置信度。
两种实现模式：
| 方式 | 适用场景 | 实现机制 |
|---|---|---|
| 手动 PR 前门控 | 处于评测起步阶段的团队 | AI/提示词工程师在提交 PR 前本地运行评测；性能报告附于 PR；审查者评估行为变化和护栏违规情况 |
| CI/CD 流水线内自动门控 | 成熟团队 | 评测运行框架集成至 CI/CD；评测失败自动阻断部署；阈值由 ML 治理团队定义 |
评测运行框架必须评估行为质量，而非仅检查功能正确性。一个智能体可能通过所有单元测试，却因选择了错误的工具或产生幻觉而失败。
三阶段 CI/CD 流水线（Google AgentOps）
健壮的智能体 CI/CD 流水线采用漏斗结构——尽早以低成本捕获错误（"左移"）：
阶段一 — 合并前集成（CI） 在每次拉取请求时触发。运行快速检查：单元测试、代码检查、依赖扫描，以及最关键的——针对黄金数据集的智能体质量评测套件。测试失败将阻断合并。基础设施：Google Cloud Build，配合 PR 检查配置模板。
阶段二 — 合并后在预发布环境中验证（CD） 合并后，CD 流程打包智能体并部署至预发布环境（生产环境的高保真副本）。运行负载测试、针对远程服务的集成测试，以及内部用户测试（"dogfooding"）。预发布环境将智能体作为集成系统在接近生产条件下进行验证。
阶段三 — 门控式生产部署 几乎从不完全自动化。需要产品负责人的审批（人在回路）。将在预发布环境中验证过的精确产物直接晋级——而非重新构建。基础设施：Terraform 用于 IaC，配合相应安全保障的生产部署配置。
基础设施支撑要素： - 基础设施即代码（IaC）：Terraform 以编程方式定义环境——一致、可重复、受版本控制，防止环境漂移。 - 自动化测试框架：基于 Pytest 的框架处理智能体专属产物：对话历史、工具调用日志、动态推理轨迹。 - 密钥管理：API 密钥在运行时通过 Secret Manager 注入——绝不硬编码在代码仓库或提示词中。
GitOps 智能体部署
将 Git 仓库作为部署状态的唯一真实来源： - 每次部署 = 一次 git commit - 每次回滚 = 一次 git revert - 平台：Agent Engine 或 Cloud Run + Cloud Load Balancing，用于跨版本的流量管理
容错与健壮性模式
Arsanjani & Bustos（2026）定义了五级健壮性成熟度谱系。以下模式在现有部署实践基础上延伸，适用于生产级智能体系统：
| 关键挑战 | 描述 | 经验教训与备选方案 | 采用的解决方案 |
|---|---|---|---|
| 智能体停滞/挂起 | 与慢速外部 API 交互的智能体进入无限等待，冻结整个工作流 | 仅设置全局超时；停滞的智能体在终止前耗尽了全部预算 | 看门狗超时监督器：将每次智能体调用包裹在有时限的执行块中（Python asyncio.wait_for）；若智能体在截止时间内未响应，强制取消并触发回退（备用智能体、简化分析或升级上报） |
| LLM 确定性失败循环 | 智能体在相同输入上反复返回格式错误的输出；简单重试会重现相同失败 | 重试时重发相同提示词——每次报错相同，浪费 Token | 带提示词变异的自适应重试：失败时在重试前对提示词进行变异——改写措辞、添加少样本示例、注入思维链指令（"Think step by step"）或收紧格式约束；变异后的提示词往往能在解决失败的同时恢复准确性 |
| 智能体任务中途崩溃 | 智能体进程崩溃，所有进行中的状态丢失，需要完全重启 | 依赖客户端重试从头开始——用户损失数分钟的工作成果 | 自愈智能体复苏：健康监控器检测到崩溃后，从持久化存储中检索最后一个检查点状态，并以该状态还原后重启智能体进程 |
| 长时运行流水线中断 | 多步骤流水线在执行中途中断时丢失所有进度 | 仅将状态存储在内存中；任何基础设施事件都意味着从头开始 | 增量检查点：在每个完成的步骤后将工作流状态持久化到持久存储（如 LangGraph checkpointers、DynamoDB）；重启时从最后一个检查点恢复，而非从头开始 |
| API 速率限制耗尽 | 调用共享外部 API 的智能体耗尽速率限制，导致级联故障 | 未做流量控制；并行智能体的突发请求在整个系统中触发了 429 错误 | 速率限制调用：将所有外部 API 调用包裹在速率限制器中，强制执行每智能体和每 API 的配额；超额请求进入队列或被优雅降级拒绝 |
| 主模型不可用 | 主 LLM 在工作流中途变得不可用或触达成本阈值 | 无回退方案；智能体停止并返回错误 | 回退模型调用：维护一个回退层次结构；在主模型失败或触发成本条件时，路由至更小、更快或更廉价的模型以保持连续性 |
| 人工升级疲劳 | 每次智能体失败都立即升级上报，给运维人员带来告警噪音 | 将每个低置信度结果升级给人工审查员；审查员成为瓶颈 | 延迟升级策略：优先尝试自动化恢复（重试 → 备用智能体 → 缩减范围）；仅在自动化路径耗尽后，携带完整上下文包向人工运维人员升级，以便高效审查 |
| 事件重试时的重复副作用 | 在事件驱动的智能体流水线中，瞬时故障（网络、硬件、软件）触发的重试可能重复执行操作（如重复发送邮件或重复交易） | 盲目重试失败的事件处理；重试偶尔会复现原始副作用 | 幂等处理：将事件触发的智能体操作设计为幂等的（对相同输入多次应用安全）；配合死信队列，将反复处理失败的事件路由至队列供人工审查，而非丢弃或无限重试（Confluent，2025） |
参见
- 可观测性
- 成本管理
- 智能体测试与评测
- A2A 协议 — 多智能体部署的注册中心架构
- 智能体架构模式 — Arsanjani & Bustos — 完整的容错与健壮性模式目录
- 多智能体系统的事件驱动设计模式（Confluent） — 幂等处理、死信队列与基于日志的故障恢复
- 工作流编排 — Temporal — 作为备选故障恢复模型的持久化执行
- Loop Engineering — 由工作树、技能（skill）、连接器和子智能体验证构建的计划任务与自我馈送自动化循环（
/loop、/goal、自动化）
参考资料
- agents-best-practices — DenisSergeevitch (2025) — 规划模式运行时模型、步骤预算、目标式循环结构和 MVP 构建顺序的来源
- Arsanjani, A., & Bustos, J.P. (2026). Agentic Architectural Patterns for Building Multi-Agent Systems. Packt Publishing. ISBN 978-1-80602-957-0. — 健壮性模式来源：看门狗超时、带提示词变异的自适应重试、自愈、增量检查点、速率限制调用、回退模型调用、延迟升级。
- Falconer, S. (2025). A Guide to Event-Driven Design for Agents and Multi-Agent Systems. Confluent, Inc. — 幂等处理和死信队列故障恢复模式的来源。