发布验收、灰度与恢复

发布的是代码、模型、提示、工具、权限和索引共同构成的版本。将前面的检查组织成对应这个版本的证据，再决定灰度、扩大流量或停止。本文负责整合验收流程，具体公式和执行边界回到各专题查阅。

固定候选版本与任务边界

先写清系统完成什么，以及怎样确认完成。查询型助手可以要求答案有可核验来源；执行型助手还需要检查实际业务状态。模型返回结束、HTTP 200 或工具没有抛异常，都不能独自证明任务成功。人工处理也是一个明确的结果分支，应统计其比例和成本，不能静默算作自动成功。

候选版本至少需要能够定位应用代码、模型标识与参数、提示模板、工具 schema 和权限策略。使用检索时还要记录文档快照、分块与嵌入配置、索引版本；使用持久状态时要记录状态格式与迁移规则。不要只给 prompt 一个版本号，却让其余依赖在验证后悄悄变化。对于只能使用浮动模型别名的服务，记录实际可获得的版本信息与验证时间，并承认供应方变化会降低复现能力。

相关解释：Agent 循环、多 Agent 编排。

发布前检查表

每一项记录负责人、候选版本、验证时间、证据位置和结论。未执行与失败分开记录，但两者都不能冒充通过；不适用项写明原因，不能仅删除勾选框。

质量与模型配置

评估的“观察什么”与“谁来评分”是两个维度：业务结果既可由程序检查，也可由人工或模型裁判评估，不能把 outcome 排在程序评分后面当成低级方法。一次成功也不能说明重复执行稳定，应说明每个任务的试验次数与聚合口径。Anthropic：Agent 评估

采样、推理预算和输出上限作用不同。不要把 temperature 机械翻译成 effort，也不要假定所有新模型都取消采样参数。相关原理见 Token 与采样、推理与 thinking、评估与可观测、结构化输出。

上下文、知识与状态

详见 上下文工程、RAG、记忆与状态。模型选型中的权重、KV 与硬件预算见 模型架构。

执行权限、可靠性与观测

已有任务授权应由系统沿操作链传递，需要额外确认的动作再按具体策略处理；逐次人工点击并不能替代资源权限和幂等机制。详见 安全与防护、成本、性能与可靠性。接入协议与工具发现的边界见 MCP 与 Skills。

证据状态与版本匹配

可以使用四种状态：pass（达到约定条件）、fail（未达到）、not_run（未执行）、not_applicable（有理由且经负责流程确认不适用）。报告存在不代表通过，报告通过也不代表属于当前候选。对必要检查，缺失、失败、未执行或版本不匹配都应阻止自动放行。

下面的本地教学例子仅演示这一规则，不会部署任何东西。把多个实际依赖版本的组合抽象成 candidate；真实系统还要验证证据来源、内容、时效和适用范围，不能信任任意调用者自报的 pass。

from copy import deepcopy

REQUIRED = {"quality", "authorization", "recovery"}

def blockers(candidate, evidence):
    problems = []
    for name in sorted(REQUIRED):
        item = evidence.get(name)
        if not isinstance(item, dict):
            problems.append((name, "missing"))
        elif item.get("candidate") != candidate:
            problems.append((name, "stale"))
        elif item.get("status") != "pass":
            problems.append((name, "not_passed"))
        elif not isinstance(item.get("report"), str) or not item["report"].strip():
            problems.append((name, "no_report"))
    return problems

reports = {name: {"candidate": "release-17", "status": "pass",
                  "report": f"reports/{name}-17.json"} for name in REQUIRED}
assert blockers("release-17", reports) == []
assert len(blockers("release-18", reports)) == 3
for state in ["fail", "not_run", "not_applicable"]:
    changed = deepcopy(reports)
    changed["quality"]["status"] = state
    assert blockers("release-17", changed) == [("quality", "not_passed")]
changed = deepcopy(reports)
del changed["authorization"]
assert blockers("release-17", changed) == [("authorization", "missing")]
changed = deepcopy(reports)
changed["recovery"]["report"] = ""
assert blockers("release-17", changed) == [("recovery", "no_report")]
print("匹配版本放行；旧版本、未通过、缺项和缺报告均阻止放行")

这里的必要项不允许用“不适用”跳过。条件项则可以由发布规则在明确场景下判定不适用，例如完全无业务写入的查询服务不需要退款去重检查，但仍需要自身的超时恢复检查。不能让候选版本自行缩减必要项列表。

绿色检查，属于哪个候选版本？

清单的勾选状态需要绑定候选版本、输入集合和检查环境，而不是永久存在的布尔值。这个模型只展开版本维度，让“曾经通过”与“当前可用的验收证据”显式分开。

灰度与恢复

离线验收通过后，用有限范围的真实任务观察新版本，并与可比较的旧版本流量对照。灰度需要预先定义指标、观察条件和停止规则；只把流量比例设为 1% 并不会自动得到足够证据。低流量业务可能很久都遇不到重要失败场景。Google SRE：Canarying Releases

例如，100 个任务中 95 个成功，并不意味着真实成功率已经被证明至少为 95%。在独立、同分布的简化假设下，95/100 的双侧 95% Wilson 区间下界约为 88.8%；真实任务还有分布变化和相关性。是否放量应结合样本量、关键分组与业务容忍度，不能用一个漂亮的点估计代替判断。

回退计划需要回答三个不同问题：新请求怎样回到旧配置，在途任务怎样停止或完成，已经发生的退款/发信等效果怎样核对。恢复旧 prompt 不会撤销退款；强行给进行中的任务换模型或工具版本也可能破坏其状态契约。优先让任务绑定候选版本，并明确升级、排空和恢复策略。

95% 成功率，证据有多强？

发布证据除了版本正确，还要有足够的样本信息。固定观测比例时，增大样本量会收窄区间；但更多重复的相似任务并不自动满足独立性，也不能替代分组覆盖。这里展示不确定性，不把一个置信下界直接当成通用上线标准。 NIST: Wilson interval

$$\frac{\hat{p}+\frac{z^2}{2n}\pm z\sqrt{\frac{\hat{p}(1-\hat{p})}{n}+\frac{z^2}{4n^2}}}{1+\frac{z^2}{n}}$$

发布后的闭环

事故进入回归前，先保存足以解释失败的版本与必要轨迹，并对个人信息和敏感数据做适当处理。将真实数据直接复制到长期评估集可能扩大暴露范围；可以构造保留同一失败条件的合成案例。

一条有用的回归不只是“再次问同一个问题”，还要记录预期结果和失败位置。例如跨租户工单事件可以拆成执行器拒绝测试与端到端注入测试：前者验证权限边界，后者观察模型是否继续正确完成本来任务。修改后跑直接相关测试，再根据依赖影响补充回归，发布前重新确认必要证据属于当前组合。

检查表会随系统变化调整。删除失效、重复的检查并保留理由，新增能覆盖真实缺口的检查；维护目标是让证据更能预测生产行为，而不是让勾选项越来越多。