8.5 上线检查单：成本、延迟、降级与回滚

8.5 上线检查单：成本、延迟、降级与回滚

本节摘要：上线评审会上的争论，九成可以靠一张预先谈好的检查单消解。本节把放行前的工程准备收敛为四项——成本预算、延迟目标、降级预案、回滚方案——每项给出可执行的配置要点与一段预算守卫代码，全册的工程纪律在这里完成最后一次集合。

前四章反复出现同一组对偶：智能体的能力是概率性的，生产的要求是确定性的。检查单就是两者之间的翻译层——把"大概没问题"翻译成"参数是多少、超了怎么办、谁来按按钮"。四项检查按"平时看什么、坏了怎么办"两问组织。

图：上线检查单看板——四项检查各自的守卫指标与失守动作

预算守卫：成本检查的落地点

class BudgetGuard:
    """成本守卫：任务级 token 上限 + 用户级日频上限 + 全局熔断。"""

    def __init__(self, per_task_tokens: int = 200_000,
                 per_user_daily_calls: int = 200,
                 global_daily_budget: int = 50_000_000):
        self.per_task = per_task_tokens
        self.per_user = per_user_daily_calls
        self.global_budget = global_daily_budget

    def check(self, task, usage) -> str:          # 返回：run / degrade / halt
        if usage.task_tokens + estimate(task) > self.per_task:
            return "degrade"                       # 降级：换便宜模型或摘要收尾
        if usage.user_calls_today >= self.per_user:
            return "halt"                          # 用户级熔断，防刷防失控
        if usage.global_tokens_today >= self.global_budget:
            return "halt"                          # 全局熔断并告警值班
        return "run"
​

守卫的返回值对应三层动作：run 正常执行；degrade 降级不中断（换轻量模型把任务收尾，而不是半途扔下用户）；halt 熔断并告警。注意"降级优先于中断"的次序——能用便宜方案保住体验，就不要用停摆考验用户的耐心。

四项检查的相互咬合

检查单不是四个孤立的格子，而是一张因果网。成本连着延迟：便宜模型的降级路径同时是延迟兜底路径，配置时要一起调。降级连着回滚：持续降级超过预设时长，应当自动触发回滚评审——降级是止痛药，回滚才是治本。回滚连着评测：7.1 节的评测闸门给出回滚触发的客观依据，否则"要不要回滚"就变成事故现场的情绪决策。最后一切都压在轨迹与监控上：2.3 节留下的黑匣子和 7.1 节的指标体系，是这四项检查共同的观测基础。

案例：一次由检查单拦下的带病上线

背景：客服智能体二期准备上线，新增了多轮追单能力。评审会上团队汇报"功能全部验证通过"。

操作：按检查单逐项核对——成本项，多轮追单使平均任务 token 翻倍，但预算守卫参数未同步调整，高峰期将大量触发 halt 熔断（把用户晾在会话里）；延迟项，p95 从七秒涨到十九秒，超承诺 SLA 一倍；降级项，追单功能的降级路径（跳过多轮直接转人工）有设计但未演练；回滚项，新提示词没有版本化，出了事只能手改。

结果：上线推迟一周。三项整改：预算参数按新成本基线重设并把 halt 改为 degrade；追单超过三步自动出进度摘要压 p95；提示词纳入版本管理并演练了一次回滚（七分钟切回）。复检通过后上线，首月无熔断事故，一次真实故障在八分钟内完成回滚。

解读：这四项里没有一项是"智能体技术"，全是朴素的工程纪律——但正是它们决定智能体项目第二个月还活不活着。检查单的价值不在清单本身，在于把争论从评审会上移到上线前：参数谈不拢可以改设计，带病上线后再谈就只剩事故复盘了。

变式：检查单可以按形态裁剪——副驾驶形态省去部分降级设计（人本来就在环上），但成本与回滚两项任何形态都不可豁免；后台自治形态则要在检查单外加"自治边界"专项（第 5.3 节的缰绳配置核验）。

⚠️ 常见坑：检查单沦为盖章流程。它的每一条都要有对应的配置、监控或演练支撑——没有熔断代码支撑的"成本已管控"就是一句空话。检查单的生命力在于每次上线真的逐项核、真的拦过东西。

本节要点回顾

• 四项备齐才放行：成本预算、延迟目标、降级预案、回滚方案——把"大概没问题"翻译成参数与预案。
• 降级优先于中断：守卫的三层动作是放行、降级、熔断；能用便宜方案收尾就不停摆。
• p95 是用户真实体验：平均值是给报告看的，长尾是给用户过的。
• 回滚要演练、要版本化、要有客观触发：切回能力按分钟计，触发条件写死不看现场情绪。

至此，全册的问题链走完了一圈：从"大模型会什么不会什么"出发，经工具、记忆、规划、协作、检索与生态、评测与护栏，抵达这份上线检查单。回到开篇那句话——聊天和干活之间的鸿沟，不是等模型变强就能填平的，它需要的是这一整套工程。

检查单的运营化：从文档到闸门

一张只活在文档里的检查单，三个月后必然过期——参数会漂，预案会忘，人员会换。让检查单持续有效 做法：参数化——检查单里的每个承诺（p95 目标、预算额度、回滚时长）都对应一个可查的监控项或一次可重放的演练记录，评审会上逐项点开验证而不是逐项口头确认；周期复检——全量检查随大版本走，四项中的守卫参数（熔断线、预算额度）每月随成本与流量基线复核一次，8.3 的大促口径尤其需要季度性重估；失败反哺——每次线上事故复盘的必答问题里有一条："检查单哪一项漏了或失守了？"答案回填成新的检查条目。经过两三个版本的迭代，检查单会从通用的四项清单长成这套系统专属的体检表——那份长出来的部分，恰恰是这个团队用真实代价换来的独有知识。

一份可直接抄走的十行版

收尾给一份最小可用的检查单，每行都是一个可以在评审会上当场验证的条目：一，单任务成本有守卫代码，超限动作已配置且测试过；二，p95 延迟实测值在承诺线内，超限路径（进度提示、降级）可用；三，模型与工具各有一条降级路径，且做过一次真实演练；四，提示词、工具配置、索引全部版本化，回滚演练完成并记录了耗时；五，评测集跑批通过，动作违规率为零；六，三道闸护栏开启，误报率在观察期内低于约定值；七，轨迹留痕开启并可按任务检索；八，值班者知道熔断与回滚的按钮在哪、触发条件是什么。八条全绿才放行——这份清单不保证成功，但能保证失败时你有数据可查、有预案可退、有按钮可按。这就是"敢上产线"的全部含义。