Agent 怎么持续优化与上线：Trace、评测、SLO 和灰度交付的证据链

Agent 回答“完成了”，接口返回 200，服务器也没有异常，但任务仍可能失败：来源过期、工具改错对象、报告缺一项，或成本超过预算。可观测性解释发生了什么；评测判断是否做对；交付流程决定哪些变化能进入生产。 三者需要使用同一组任务和版本标识。

本文以截至 2026-10-11 的官方资料为基础。下面的指标口径、发布门槛与流程是可实施的工程建议；示例数字不代表已经测得的服务表现。

公开实践：两家公司把验证放在什么位置

OpenAI Agents SDK tracing^[1]提供模型、工具、handoff 和 guardrails 等运行观察。Harness engineering^[2]描述了让 Agent 访问隔离应用环境、浏览器与观测工具，并用机械检查约束架构的经验；这是特定工程实践，不是所有团队必得的效率倍数。

OpenAI 的 Agent improvement loop 示例^[3]进一步展示了运行记录、人工反馈、评测与下一轮改动如何连接。可借鉴的是反馈形成回归证据的闭环，而不是直接复制示例的业务与数据。

Anthropic 的 长任务 harness 报告^[4]用初始环境、功能清单、进度记录与增量验证帮助跨会话继续工作。Demystifying evals^[5]则区分任务、试验轨迹、最终结果和不同 grader。两者共同提醒：保存进度不等于验证完成，轨迹看起来合理也不等于环境结果正确。

工程推导：贯穿一次任务的 Trace

图 1 · Trace 解释过程，验收判断结果；同一 release_id 连接离线实验与线上观测。

建议一次任务的 trace 覆盖入口接收、排队、检索、重排、上下文构建、每轮模型调用、工具执行、验收与结果交付。跨队列显式传播 trace 上下文，重试创建独立 attempt，暂停后恢复可通过关联关系连接；不要假定本进程自动追踪能贯穿所有外部系统。

记录业务 task_id、attempt_id、operation_id、配置 release_id 与厂商请求 ID，遇到失败能定位同一件事。它们与 tracing ID 的含义不同：一次任务可以跨多个 trace，一次逻辑操作可以在多个 attempt 中对账。

普通日志保存事件类别、结果、耗时和可用的安全关联 ID。必要的详细样本放受控存储，定义授权、脱敏与留存。SDK 可能自动收集提示和工具参数：OpenAI tracing 文档明确 trace_include_sensitive_data 默认开启；上线前按数据约束配置，关闭正文采集后仍要检查自定义 metadata、错误文本和自定义 exporter。

指标：把等待、生成与完成拆开

p50 和 p95 都要看，并注明任务类型和观察窗口。多步 Agent 可以快速吐出一句“开始处理”，但核心工具仍在等；首 token 改善不自动等于完成更快。具体延迟拆解见TTFT 篇。

费用按模型、缓存、工具、环境、存储、审核与失败重试归因。供应商 usage 是核算依据，预估用于准入和预算；缓存命中与写入、压缩调用、隐藏推理费用按各自契约记录。指标标签只用模型、版本、工具类别等有限维度，用户 ID 和自由文本留在受控日志，避免高基数爆炸。OpenTelemetry 语义约定^[6]有助统一命名；具体 GenAI 属性仍应固定所用约定版本。

SLO：用户承诺需要可计算的分子与分母

示例目标：在一个明确窗口内，99.5% 的“已接受、属于支持任务类型、无需等待人工审批”的任务，在 30 秒内通过验收并交付。实现前还要定义：何时算接受、取消怎样计入、依赖故障如何分类、低流量时怎样报告不确定性，以及长任务是否使用另一套目标。

如果窗口内有 10,000 个符合定义的任务，0.5% 对应 50 个允许的失败或超时；这是示例 error budget。不能把失败排除出分母来美化 SLO，也不能把“服务可用”与“答案正确”混成同一个百分比。Google SRE SLO 指南^[7]提供了指标与用户体验连接的原始方法。

告警优先针对用户影响与预算消耗：队列增长、长期没有进展、关键工具失败率、权限门槛异常、费用突增和错误预算快速消耗。只盯 CPU 或统一 5xx 会漏掉大量业务失败。告警必须有责任人、诊断步骤、限制流量或回滚动作，并演练人工通道是否可达。

评测：验证最终环境，不强求同一条路径

工具 Agent 的测试应冻结初始数据、权限、时钟相关条件与可用工具，运行后验证目标对象和副作用。允许合理的不同调用路径；只有顺序本身决定安全或业务规则时，才要求固定顺序。模型裁判负责开放质量，确定性校验负责可计算事实，人工抽检负责校准与争议。

τ-bench 论文^[8]用对话后的数据库状态与目标状态比较，并研究多次运行的一致性。它说明为何“措辞像完成”不足以判断工具任务成功；其旧模型分数不能直接作为当前产品排名。

重放要区分两类：录制工具结果的回放可定位 prompt 或模型差异，但不能证明真实工具仍然可用；隔离环境中的端到端重跑可验证实际交互，却需要控制数据、时间与外部依赖。详见评测闭环。

Docker、K8s 与 CI/CD：发布的是可恢复行为

把应用代码、依赖锁定文件和行为配置构建为可追踪的发布产物。Docker 镜像用 digest 识别，密钥运行时注入，CPU、内存、临时盘与网络权限有界；容器只提供部分隔离，需要结合运行权限和工具策略。

CI 按改动影响检查：代码与类型、schema 和旧客户端契约、权限和幂等、代表性 Agent 评测、费用与延迟趋势。慢或昂贵的完整评测可分层执行，但关键门槛必须在受控流程中真正执行；报告保留逐样本结果与版本，不能只有总分。

Kubernetes probes^[9]区分 startup、readiness 与 liveness。readiness 决定是否继续接收流量，liveness 针对进程需要重启的故障；依赖短暂故障若触发所有实例重启，可能进一步扩大事故。任务 worker 停止领取新任务的机制仍要由应用实现。

滚动升级时停止接收或领取新任务，在宽限期内完成可结束步骤，并把剩余任务交回持久化恢复机制；不能假设长任务总能在关机前结束。Pod 生命周期^[10]描述终止流程，Deployment^[11]描述滚动更新，但它们不自动保存 Agent 内存中的进度。

数据库迁移采用先扩展兼容结构、再切流量、最后清理旧结构的流程。灰度同时观察新旧版本的关键切片，准备回退路由、镜像与行为配置。外部已发生的动作需要对账，数据迁移可能需要单独恢复方案；回滚不能只恢复一个 prompt 字符串。

优化实验：每次改善要能说明因果与代价

先用 trace 区分模型慢、排队慢、检索差或工具失效，再选择改动。可以比较简化工具描述、证据去重、小模型路由、受限并行与缓存；不要一次换模型、prompt、索引和并发，再把全部改善归因给其中一个。

实验记录至少包括：假设、基线、改动、任务分布、模型与配置版本、冷/热条件、运行次数、逐任务成功、p95 和总费用。线上并行实验应控制曝光与资源竞争；新版本抢走旧版本配额可能使比较失真。

发布顺序为离线回归 → 隔离端到端验证 → 受控影子请求 → 小范围灰度 → 扩大观察。失败样本经授权脱敏后回流评测集，严重问题写入 incident 复盘和工程约束。优化只有在质量、安全、成本和用户等待的约束下成立，才具有生产意义。

参考资料