版本发布：评测门槛、灰度与在途任务回退

更换模型后，平均完成率提升了；同时更新的上下文压缩器却让长资料任务漏掉关键限定条件。如果只记录模型名称，这次发布很难定位，也难以准确回退。

模型、上下文、工具、策略和部署配置应合成一个可追溯的发布对象。上线不是一个分数越过门槛，而是决定哪种组合可以进入哪些真实任务，以及出现问题时怎样退出。

发布单元是一个可还原的组合

下表是一份建议清单，不是某个平台的固定格式：

对象	应保留的版本或引用
模型与网关	模型或部署标识、路由规则、适配器、生成配置
上下文	装配器、压缩策略、Prompt、Skill 和工具定义
执行控制	权限策略、预算、重试和恢复规则
数据与制品	任务输入快照、来源版本、制品格式
运行状态	状态 Schema、事件格式与兼容范围
验收	数据集、评分器、评委配置与发布门槛

有些托管模型只暴露可变化的别名，无法固定底层快照。应如实记录请求日期、实际返回的标识与供应方可提供的信息，降低可复现性的承诺，而不是假装模型名称就是完整版本。

从契约测试走到真实流量

已有评测工程篇提供了任务、试次、证据和回归的骨架。这里讨论运行机制变化后的发布路径。

阶段	回答的问题	必须保留的证据
契约回归	边界是否被破坏	参数、权限、去重、取消与恢复反例
固定任务对照	候选组合改善了哪些任务	同任务、数据快照和预算下的结果
隔离回放或影子评估	面对实际输入能否保持表现	数据范围、隔离措施和分布切片
限定灰度	真实使用下的质量与运营表现	分版本指标、接管记录和资源终态
扩量或退出	风险与成本是否仍可接受	预先定义的门槛与执行记录

门槛应在实验前写清，包括哪些是不可交换的硬条件，哪些允许权衡。平均费用下降不能抵消一次越权；简单任务的提升也不能自动覆盖关键任务切片的退化。

影子任务也可能造成真实副作用

影子运行经常被描述为“只看结果、不影响用户”，但如果候选 Agent 仍有真实写入工具，它可以创建第二条工单、发出通知或污染共享记忆。

可以采用固定响应回放、只读工具或独立测试服务，但必须由执行层限制写入，并隔离缓存、记忆和制品。提示候选 Agent “不要真正执行”不是同等控制。

固定响应回放还存在覆盖边界：候选规划可能选择历史轨迹中没有出现的新工具路径。此时应标记超出回放范围，转入隔离环境验证；不能给所有新请求返回同一份录制结果，再声称任务通过。

灰度需要按任务保持版本一致

一个长任务开始时使用旧版工具 Schema，恢复后突然切到新版适配器，可能遇到历史消息无法映射或审批参数含义改变。因此，发布路由应考虑 Run 级版本绑定，而不是随每个请求随机切换。

对照组与候选组还可能共用下游配额、缓存和数据库，产生相互影响。Google SRE 的灰度指南强调分别观察候选与对照，也讨论了共享资源导致的混淆；比较两组之外，还需要检查绝对服务目标。Canarying Releases

低流量阶段的样本可能不足。未观察到事故只说明当前样本没有捕捉到，不证明风险为零。扩量可以按任务风险、团队范围或负载逐步推进，同时保留快速停止入口。

回滚先处理在途任务与状态兼容

切回旧模型或旧服务镜像，并不会自动撤销已创建的工单。回滚计划至少区分三件事：阻止新任务进入候选版本、处理候选版本的在途 Run、纠正已经产生的外部影响。

在途状态	可考虑的处理
尚未执行	在兼容条件下切回旧版
等待输入或审批	固定原版本继续，或进行明确迁移
已有写入但结果未知	先对账，再决定恢复路径
状态 Schema 已升级	使用兼容读写或有验证的迁移方案

如果旧版不能读取新状态，就不能把“切回旧镜像”当成完整回滚。迁移需要备份、版本检查和失败出口；原有操作键及审批事实应保留，避免回滚成为重复写入的来源。

用消融实验决定何时简化

模型升级后，原来用于补偿能力不足的某些机制可能不再划算。可以在固定任务上逐项移除额外规划、反复自检或过重上下文，比较质量、稳定性和成本。

一次只改一个可解释因素有助于定位，但也要关注机制之间的相互作用。单独关闭两个模块都不退化，不代表同时关闭也安全。硬权限和副作用保护不应因为模型在小样本中表现良好就被删除。

消融实验的输出不是“更少总是更好”，而是某个机制在什么任务条件下有证据值得保留。它可以接续已有的Harness 减负原则与评测系统观。

用变更记录约束扩量

使用设计工作簿，记录本次改变了什么、预期解决哪种失败、哪些任务可能受损、观察到哪些证据，以及何时停止扩量。没有数据时保留“未测”，不要把计划写成结果。

需要决定运行控制与持久化组合时，使用架构选型中的迁移条件；上线后的执行权接管由生产调度负责。