图 1：Observe 提供窗口证据，Protect 把证据转成继续、降级、暂停或回滚，Improve 再把确认后的事故转成下一版发布门禁。封面动画仅用于表现闭环流动。
1. 为什么生产运营和持续改进应该合在一起
如果只做 Production Ops，团队可能拥有很多监控图，却没有回答：这次失败会不会进入回归任务集？
如果只做 Improvement Loop，团队可能不断改 Prompt、换模型，却没有可信的生产证据说明应该改什么。
一个完整闭环要连续回答三个问题：
它们分别对应不同时间尺度：
关键不是把三层数据堆进同一平台，而是让证据能够向下一层流动，同时保留责任边界。
2. Observe：别让一个成功率统治看板
一个回答正确但耗时 90 秒、调用 40 次工具的 Agent，可能不可运营；一个延迟很低却总把复杂问题转给人工的 Agent，也可能只是把成本藏到了别处。
我会把最小生产记分卡拆成三层。
图 2：三层信号回答不同问题。Trace 负责解释某次失败，窗口指标负责触发运行动作，业务结果负责判断自动化本身是否值得继续。
三层信号的响应速度不同。写入结果未知、安全回归和 Provider 故障可以成为即时硬门禁；用户是否再次追问、人工是否重做等业务结果通常有延迟，更适合周度复盘和任务设计调整。不要因为一个滞后指标刚刚波动，就让发布系统秒级自动回滚。
2.1 运行健康：系统还能稳定执行吗
第一层关注执行面：
这里最危险的不是一个普通错误，而是“写入结果未知”。超时并不等于失败：外部系统可能已经执行成功，只是回执丢失。继续重试可能造成重复付款、重复发信或重复发布，因此它应比成本和延迟拥有更高优先级。
2.2 任务质量：系统仍然做对了吗
第二层来自任务合同和 Eval：
-
核心任务通过率； -
正确拒答率； -
安全回归数； -
证据完整率； -
Grader 分歧与人工抽检； -
不同任务切片的退化情况。
这里要避免只看总体平均数。新版可能让常见问题更好，却让高风险写操作更差；平均分上涨不能抵消安全切片回归。
2.3 业务结果：任务真的被解决了吗
第三层容易被工程看板忽略：
-
用户是否需要再次追问； -
人工是否重做或纠正结果； -
工单是否真的关闭； -
下游是否出现重复写入或错误状态； -
自动化究竟节省了时间，还是只把工作转移给 Reviewer。
这类指标通常需要业务系统和人工反馈，不会自然出现在模型 Trace 里。它也最能提醒团队：一个技术上健康的 Agent，未必完成了值得自动化的任务。
Trace 与监控的分工
OpenAI Agents SDK 可以记录模型生成、工具调用、handoff、guardrail 和自定义事件；OpenTelemetry 也提供跨系统的 Trace、Metric 与 GenAI 属性约定。但“能采集”不等于“已具备可运营性”。生产动作仍应由聚合窗口、任务合同和业务规则决定。工具参数与结果可能含敏感数据，进入观测平台前要做字段白名单和脱敏。
3. Protect：指标必须通向一个明确动作
只设置告警，不设置动作，通常会得到两种结果：值班人员临场猜，或者所有人逐渐忽略告警。
先用一个最小例子区分三个容易混在一起的词：
本文还会使用“单任务成本预算”。它限制一次 Agent 允许花多少调用、Token 或金额，和可靠性 Error Budget 不是同一件事。
更可执行的做法是先写降级矩阵：
稳定版本先降级，是为了保留一部分有用能力；Canary 回滚，是因为候选版本还没有获得扩大影响面的资格。
本文实验采用如下教学阈值：
这些数字只服务于固定夹具。真实阈值必须从任务合同、流量基线、风险等级和团队承诺中推导，并明确窗口长度、最小样本量、Owner 与例外流程。
4. Canary：离线通过只是入场券
Canary 的价值不在于“先发 10%”，而在于建立一组可比较证据：
图 3：实验中的 10% 只是夹具参数，不是生产建议。即使候选离线分数更高，只要在线错误率、安全或成本越界，仍然回滚。
4.1 为什么既看 Control，又看绝对 SLO
只和 Control 比较会漏掉一种情况：候选与旧版同样糟糕。比如两边成功率都是 80%，相对差值为零，但都低于业务承诺。
只看绝对 SLO 也不够。候选可能勉强在阈值内，却比 Control 明显变差。合理门禁应同时检查：
4.2 晋级不是终点
Canary 通过后也不应一步跳到永久全量。更稳妥的做法是逐步扩大流量，每一级保留：
-
当前版本和策略版本； -
观察窗口； -
回滚点； -
触发回滚的证据； -
谁批准了扩大影响面。
Google SRE 对 Canary 的定义同样强调局部、限时部署与对照分析；错误预算耗尽后，普通发布应让位于可靠性恢复。本文不直接照搬某个流量比例，因为 Agent 的风险由任务和副作用决定，而不是由一个通用百分比决定。
4.3 哪些情况先不要做在线 Canary
Canary 不是所有 Agent 的默认发布方式。先用下面四个问题做判断：
这里的 rollback 也只表示停止继续向候选版本分配任务并恢复旧版本。它不会撤回已经发送的消息、退款或数据写入；这些副作用仍要依靠幂等键、回执对账和补偿流程处理。
5. Improve：事故怎样变成 Regression Eval
把所有生产输入自动存进数据集并不叫持续改进。真实 Trace 可能包含隐私、偶发依赖故障、错误人工标签和重复样本。
我只在下面条件满足后，才把事故转成 Eval 候选：
- 已确认
：确实违反任务合同或运行策略，不是正常拒答。 - 已脱敏
：正文、凭据、客户信息和工具载荷不进入评估工件。 - 已去重
：同一故障模式不靠重复样本虚增权重。 - 有预期结果
：说明应该回答什么，或应该采取哪个控制动作。 - 可重复
：测试不依赖已经消失的现场状态。 - 有 Owner
：有人决定它何时修复、何时可以关闭。
图 4：闭环中的自动化可以生成报告、Eval 候选和代码 diff，但默认不自动合并或全量发布。下方数字来自本文固定实验。
Anthropic 的 Agent Eval 方法把评估拆成 Task、Trial、Grader 与 Transcript，并区分探索能力上限的 capability eval 和防止旧问题复发的 regression eval。生产事故更适合进入后者：目标不是证明模型突然更聪明，而是固定一条已经发生过的失败边界。
OpenAI 的 Agent Improvement Loop 示例则把 Trace、反馈、生成 Eval、验证闸门与 Codex handoff 接在一起。一个实际可控的起点是：系统生成候选改动和验证报告，开发者审查 diff 后再合并，而不是让线上失败直接触发自动部署。
关于 OpenAI Evals 的时效说明
截至 2026-08-08，OpenAI 官方文档已经给旧 Evals 平台列出弃用时间表。因此本文使用本地、版本化的通用 Eval 工件，不把闭环绑定到即将关闭的旧平台接口。接入任何托管评估服务前，都应重新核对当前文档。
6. 跟做 Production Loop Lab
本文把前十篇逐步演进的 Agent Reliability Lab 更新到 1.1.1。它不调用真实模型，而是用九个确定性窗口专门验证控制路径。
Lab 只输出 continue、read_only、rollback 等策略决定，不会操作真实流量、部署版本或补偿既有副作用。事故夹具也只包含预先确认、预先脱敏的元数据；代码验证的是这些元数据能否形成稳定 Eval 候选，不实现生产 Trace 的确认、脱敏和去重管道。
6.1 获取实验
可以直接下载本文固定版本：
-
下载 agent-production-loop-lab-1.1.1.zip
SHA-256 校验值：
也可以查看 GitHub 精确提交。
主命令公开接口只有一个：
6.2 应该看到什么
九个窗口分别验证：
实验会生成五类证据：
PASS 只说明九个固定窗口符合声明的控制合同。它不证明真实容量、模型质量、监控覆盖或生产阈值正确。
6.3 两个十分钟故障练习
打开 datasets/operations-cases.jsonl，先不要改预期结果。
练习 A：让健康 Canary 变慢
把 canary-promote 的 p95_latency_ms 从 1900 改为 7000，重新运行命令。CLI 应以非零状态退出，策略决定变成：
这验证候选版本不会沿用稳定版本的 draft_only 降级，而是退出 Canary。
练习 B：模拟工具恢复
不要改写 tool-throttle-degrade。它是以后防止限流降级失效的回归证据。
改动独立的 tool-recovered：把 tool_error_rate 从 0.02 改为 0.18，但保留预期 continue / within_policy。Gate 应以非零状态退出，并显示策略决定变成 read_only / tool_error_budget_exceeded。恢复为 0.02 后，9/9 场景和 10/10 Gate 应再次通过。
这一步体现两个原则：恢复也需要证据；修复新版本时，不要删除已经发生过的失败案例。
7. 一份可直接改写的生产策略模板
下面不是某个框架配置，而是一份设计草稿。可以先用它和产品、SRE、安全及业务 Owner 对齐，再映射到 Prometheus、OpenTelemetry、云监控或自有发布系统。
填写时最重要的不是补齐所有字段，而是找出无人负责的空白：谁能暂停写入？Provider 故障时是否有备用路径？谁判断一次失败可以进入 Eval？什么时候允许恢复？
8. 从 Demo 到可靠系统：系列最后怎样闭环
回看整个系列，十一篇文章并不是十一项独立功能：
它们最终回到同一个判断：
Agent 的可靠性，不是某次回答看起来正确，而是成功有合同、失败有证据、风险有边界、改动能比较、发布可回滚。
9. 收藏清单：第一次把 Agent 放进生产闭环
-
先选一类任务，不要给“所有 Agent”做总看板。 -
写出运行健康、任务质量和业务结果各三个信号。 -
给每个信号补 Owner、阈值、动作和恢复条件。 -
把未知写回执设成独立高优先级状态。 -
固定版本元组，让模型、Prompt、工具、策略和代码可以一起追踪。 -
建立离线 Gate，再让候选进入受控 Canary。 -
同时比较绝对 SLO 和同期 Control，不让平均分覆盖高风险回归。 -
只把确认、脱敏、去重的事故转成 Regression Eval。 -
自动生成候选和报告可以更快，合并与扩大影响面仍保留明确责任人。 -
定期删除无动作、无人负责、长期不使用的告警。
参考资料
OpenAI
-
OpenAI Agents SDK：Tracing -
OpenAI Agents SDK：Configuration -
Build an Agent Improvement Loop with Traces, Evals, and Codex -
Evaluation best practices
Agent Eval、SRE 与观测标准
-
Anthropic：Demystifying evals for AI agents -
Google SRE Workbook：Canarying Releases -
Google SRE Workbook：Error Budget Policy -
OpenTelemetry Semantic Conventions -
OpenTelemetry GenAI Attributes
本文代码与证据
-
Agent Reliability Lab 3102d9b -
Production Loop 核心策略 -
九个生产窗口夹具 -
Operations Review -
预先脱敏的 Incident Eval 候选
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
