生产化部署

生产化部署：把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚，以架构、轨迹与故障重放完成工程验收。

学习目标

  • 能解释“生产化部署”如何把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚
  • 能区分异步队列、幂等键、降级、灰度发布、补偿，并标出控制权、状态和副作用边界
  • 能冻结输入与版本，沿以下证据定位首个分叉：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志
  • 能注入“模型超时后网关无幂等键地重试写操作，造成重复下单并在全量发布中扩大”，完成阻断、恢复、复位和同输入重放

来源、课程身份与适用边界

“生产化部署”以Anthropic 公开全文《Building effective agents》建立工程总纲，并用Anthropic Managed Agents 工程文章核对本章机制。

这不是一本名为《AI Agent 开发实战》的官方出版物，也不存在官方十四章目录。平台把公开工程文章、官方开发文档和原始论文重组为 14 个工程单元；下列 112 个节点是站内课程地图。正文、代码、图表、实验与练习均为独立教学重写，模型、API、协议或安全边界变化时必须重新验证。

本单元的八个工程坐标

  • 生产化部署：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 1 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 小特要从一个人，变成一支正规军：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 2 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 生产架构：上线不是一个脚本，是一套架构：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 3 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 并发与异步：海量请求同时来，一个个串着处理必死：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 4 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 超时·降级·重试：生产里，调用一定会失败：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 5 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 灰度发布与回滚：新版本别一上来就全量：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 6 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 动手玩：先当一回兜底工程师，再当一回发布负责人：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 7 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。
  • 动手一：主模型超时了，一个做了降级的 Agent 会直接报错吗：这是“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的第 8 个工程坐标；必须进入机制解释、运行轨迹或故障证据，不能只停在目录。

术语与运行合同

、、、、。

本页不变量是：每个请求都有稳定身份、资源预算和可恢复状态，重试不会重复副作用，版本可安全回退。任何“成功”结论都要保存request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志；模型自评、最终措辞和单次 demo 都不能替代环境事实。

工程机制与反证实验

脑与手保持稳定接口

模型和 harness 会迭代，执行、状态和权限接口应能独立扩缩与升级。

动手验证：替换模型版本，确认执行协议和历史任务仍兼容。

重试前先判断幂等

查询可安全重试，扣款和发送需要幂等键或补偿，不能一套策略覆盖所有工具。

动手验证：制造响应丢失，确认同一请求只执行一次。

超时与背压保护下游

无限等待和无限并发会把局部慢调用放大成系统雪崩。

动手验证：降低下游容量，检查队列上限、拒绝和恢复。

回滚不仅是代码版本

新版本已产生的订单、消息和文件不会随镜像回退，需要补偿与审计。

动手验证：灰度中制造错误写入，演练版本回滚和状态补偿。

从架构到故障重放

分步1 / 3

1. 架构复杂度实验

在“生产化部署”中切换简单基线、受控工作流和自主循环，先判断“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”是否真的需要更高自主性，再比较延迟、成本、可观测性与风险。

Architecture decision laboratory

生产化部署

把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚

复杂度档位

不变量：每个请求都有稳定身份、资源预算和可恢复状态，重试不会重复副作用，版本可安全回退

受控工作流：只激活能够由收益证明的阶段1接入排队2限并发执行3超时降级4灰度观测5回滚补偿蓝色表示当前方案承担的责任；虚线阶段仍留在系统边界外。关键证据：request_i…
自主性46
延迟52
成本48
可观测78

最小可运行切片

async function handle(job: Job) {
  return idempotency.run(job.key, async () =>
    timeout(
      concurrencyLimit.run(() => agentService.execute(job)),
      30_000,
      () => safeFallback(job),
    ),
  );
}
 
await rollout.canary(newVersion, {
  steps: [0.05, 0.25, 0.5, 1],
  rollbackOn: regressionPolicy,
});

切片只表达“把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚”的核心合同。生产实现还要补齐持久化、超时、密钥隔离、结构化日志、幂等和批量评测；如果不能重新取得request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志，代码跑通也不能证明机制正确。

练习与答案

练习

问题 1：最小证明。 怎样用正常、边界和单故障三类样本证明“每个请求都有稳定身份、资源预算和可恢复状态，重试不会重复副作用，版本可安全回退”？

问题 2：节点覆盖。 生产化部署、小特要从一个人，变成一支正规军、生产架构：上线不是一个脚本，是一套架构、并发与异步：海量请求同时来，一个个串着处理必死、超时·降级·重试：生产里，调用一定会失败、灰度发布与回滚：新版本别一上来就全量、动手玩：先当一回兜底工程师，再当一回发布负责人、动手一：主模型超时了，一个做了降级的 Agent 会直接报错吗如何从目录词变成工程证据？

问题 3：恢复验收。 怎样证明“模型超时后网关无幂等键地重试写操作，造成重复下单并在全量发布中扩大”已经修复？

本章回顾

  • “生产化部署”解决的是把模型决策与执行基础设施解耦，补齐队列、并发、超时、幂等、降级、灰度和回滚。
  • 核心不变量是每个请求都有稳定身份、资源预算和可恢复状态，重试不会重复副作用，版本可安全回退。
  • 首要反例是模型超时后网关无幂等键地重试写操作，造成重复下单并在全量发布中扩大。
  • 最小证据包包含request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

名词解释

本章出现的专业名词，用大白话再讲一遍。

异步队列

把请求接收与长耗时执行解耦的缓冲层。在“生产化部署”中必须能按以下证据重新定位：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

幂等键

让重复请求只产生一次业务副作用的稳定标识。在“生产化部署”中必须能按以下证据重新定位：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

降级

主依赖不可用时转向能力较低但安全的处理路径。在“生产化部署”中必须能按以下证据重新定位：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

灰度发布

逐步扩大新版本流量并观察指标的发布策略。在“生产化部署”中必须能按以下证据重新定位：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

补偿

撤销或抵消已发生外部副作用的业务操作。在“生产化部署”中必须能按以下证据重新定位：request_id、idempotency_key、队列事件、超时、重试、模型版本、灰度指标、回滚与补偿日志。

阅读导航

← 安全护栏与成本控制 · 本课程终点 →

讨论

评论区加载中…