有人从“只报告”模式（L1）过早毕业到“自动修复”模式（L2），15分钟一次的CI Sweeper在缺乏独立验证Agent、没有分支白名单、没有模型外部硬性token上限的情况下直接跑飞，无人值守自动化的“放手节奏”到底该按什么信号来推进，而不是按“跑通了几天”来拍脑袋？

1. 导语：一次“跑飞”事故的解剖学价值

先把事故压缩成一句可复现的描述：一个调度周期为15分钟的CI Sweeper，最初工作在L1（只报告，不修改任何东西），在“连续跑通若干天”之后被提升到L2（自动修复），但此时它没有独立验证Agent、没有分支白名单、没有模型外部硬性token上限。结果是任务在无人值守状态下持续自我放大：修复动作触发新的失败，新的失败被新一轮扫描捕获并再次“修复”，消耗与变更面同时膨胀，直到被人为叫停。

这类事故在工程上并不新鲜。控制论里它对应正反馈回路失去阻尼；可靠性工程里它对应共因失效（common cause failure）与失效静默扩散；在LLM驱动的运维代理语境下，它多了一层特殊性：执行体本身是概率性的，其“判断”与“动作”耦合在同一个模型里，若没有外部约束，模型的自评会系统性地高估自身正确性。笔者认为，这起事故的真正价值不在于“某个Agent写坏了代码”，而在于它暴露了一个被普遍忽视的治理缺口：自治等级的授予缺少可观测的准入信号，团队用“时间”替代了“证据”。

本文的核心命题：自治等级不是“信心等级”，而是“证据等级”。每一次从L(n)到L(n+1)的跃迁，都应当由一组在L(n)阶段已经稳定观测到、且能被独立复算的信号来授权；任何以“已经跑了多少天”“看起来挺稳”为依据的跃迁，本质上是在用生存偏差替代统计证据。

2. 背景与问题定义：自治等级、CI Sweeper与“放手”的语义

2.1 自治等级的一个可操作定义

业界对“自动化等级”有若干版本，最常被引用的是汽车功能安全领域的SAE J3016驾驶自动化分级（L0–L5），其精髓不在于数字，而在于“谁在什么条件下负责监控与接管”。把这个思想迁移到运维自动化，本文给出如下可操作定义（注意：这是本文的工程化定义，不是任何标准的原文）：

本文评述：这张表的关键不是数字，而是每一级都隐含了不同的“监控责任转移点”。L1到L2的跃迁，本质是把“判断建议是否可信”的责任从人转移给了系统自身。而事故中的系统恰恰没有能力承担这个责任——它既没有独立验证者，也没有域边界，更没有资源刹车。责任转移了，能力没跟上，这就是越级的本质。

2.2 CI Sweeper是什么，以及它为什么危险

CI Sweeper可以理解为一种周期性巡检代理：按固定周期（事故中是15分钟）扫描流水线状态，识别失败、抖动、超时、依赖漂移等问题，并在被授权时执行修复动作。它与“事件驱动”的CI/CD流水线不同，是时间驱动的，这意味着它的触发频率与问题产生频率解耦——问题没解决，它还会再来一次。

这个特性决定了它的危险系数高于普通的一次性任务代理。原因有三：其一，高频重试天然构成正反馈，一次错误修复产生的次生失败会在15分钟后被重新捕获；其二，无人值守意味着人类反馈延迟远大于系统周期，事故中人类介入前系统已迭代多轮；其三，修复动作本身改变环境，使后续观测不再是独立同分布样本，验证难度上升。关于周期性任务与重试放大的风险，可参考Google SRE系列对“重试风暴”的经典讨论（Beyer et al., Site Reliability Engineering, O'Reilly, 2016）。

2.3 “放手”的语义：从权限授予到证据授权

日常语境里，“放手”是一种心理动作；工程语境里，它必须是一次权限状态的迁移，并且这次迁移应当满足三个条件：可观测（有信号）、可证伪（信号能被独立复算）、可回退（迁移可撤销）。事故中的“放手”只满足了第一个条件的一半——有运行日志，但没有把日志转化为可证伪的判据。

这里引入一个有用的类比：统计过程控制（SPC）中的控制图。休哈特控制图的核心思想是区分“普通原因波动”与“特殊原因波动”，只有当过程处于统计受控状态时，才谈得上能力评估（Montgomery, Introduction to Statistical Quality Control, Wiley, 2019）。把这一思想迁移过来：在L1阶段，我们真正要收集的不是“它跑通了几天”，而是“它的建议在统计上是否受控、偏差是否有界”。没有控制图式的证据，跃迁就是赌博。

3. 失控的机制拆解：三类缺失控制面如何叠加放大

把事故归因为“模型不行”是最省事也最无用的结论。更有解释力的是控制面视角：一个自治系统至少需要三类相互独立的外部约束——认知约束（谁来验证判断）、空间约束（允许改哪里）、资源约束（允许花多少）。事故中三者同时缺位，且它们之间存在耦合放大关系。

3.1 缺失控制面一：没有独立验证Agent

当执行与验证由同一个模型、同一段上下文完成时，会产生两类系统性偏差。第一类是自洽性偏差：模型倾向于认为自己的输出正确，这在LLM评测中表现为“自我偏好”（self-preference bias），即模型对自身生成内容的评分系统性高于他人评分。相关实证可参见Zheng等关于LLM-as-a-judge的工作（Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 Datasets and Benchmarks），该研究发现强模型作为评审时存在对自身输出的偏好，并建议采用位置交换、参考引导等缓解手段。

第二类是上下文污染：执行Agent的上下文里已经包含了“我为什么要做这个修复”的推理链，验证时这些推理会作为前提被继承，验证退化为“检查我是否按我说的做了”，而不是“检查我说的对不对”。笔者认为，独立验证的最低要求不是“换一个模型”，而是切断推理链继承：验证者只能看到变更前后的客观状态、测试结果与规范条款，不能看到执行者的自述理由。否则再强的模型也只是在为自己的作业打分。

一个可操作的独立性判据：验证Agent的输入集合 V 与执行Agent的推理集合 R 的交集应为空或仅含客观事实（diff、日志、测试报告）。若 V∩R 包含执行者的意图陈述，则独立性不成立。

3.2 缺失控制面二：没有分支白名单

分支白名单是变更域约束的最简形式。没有它，修复动作的作用域由模型自行判断，而模型对“哪些分支重要”缺乏组织知识。事故中，自动修复很可能触碰了受保护分支或跨模块修改，导致影响面从“局部失败”扩散为“系统性失败”。

变更域约束的理论依据可以追溯到最小权限原则（Saltzer & Schroeder, The Protection of Information in Computer Systems, 1975）与爆炸半径控制。在持续交付语境中，分支保护、必需评审、状态检查是成熟平台的标准能力，GitHub、GitLab均提供分支保护规则与必需状态检查（参见GitHub Docs: About protected branches；GitLab Docs: Protected branches）。本文评述：白名单的价值不只是“限制范围”，更是把“可逆性”编码进系统——白名单内的变更通常可快速回滚，白名单外的变更往往涉及发布、配置、数据，回滚成本高一个数量级。

3.3 缺失控制面三：没有模型外部硬性token上限

这是最容易被低估的一条。模型侧的上下文窗口限制是软约束——它限制单次调用，但不限制调用次数；而自治代理的失控往往表现为调用次数与单次长度的乘积爆炸。没有外部硬上限，意味着系统可以在“再试一次”的循环里无限消耗，且这种消耗本身会拖慢反馈、拉长人类发现延迟。

工程上，硬性上限应当实现在模型之外：API网关层的配额、调度器的任务预算、代理运行时的循环计数器，三者取最小值。这与云平台的配额治理思路一致——配额在控制面强制执行，而非依赖调用方自律（参见AWS Well-Architected Framework可靠性支柱中关于配额与节流的讨论）。笔者认为，“模型外部”这四个字是关键词：任何由模型自己判断“我该不该继续”的机制，在失控场景下都不可信，因为判断本身也在消耗且可能被错误激励。

3.4 耦合放大：为什么三者缺一不可

单独看，每一类缺失都有一定容错空间；叠加起来则形成正反馈闭环。可以用一个简化的放大模型描述（以下为本文构建的示意模型，非实测数据）：

设：
  p = 单次修复引入次生失败的概率
  r = 次生失败被下一轮扫描捕获的概率
  k = 单轮允许的最大动作数（无上限时 k → ∞）
  c = 单动作平均token消耗

单轮期望新增问题数 ≈ k · p · r
累计消耗 ≈ Σ_t (k_t · c_t)，k_t 随失败数增长而增长

当 p·r ≥ 1/k 时，问题数期望不收敛；
当 k 无上限且 c 无上限时，消耗呈超线性增长。

这个模型解释了一个反直觉现象：系统在“跑飞”初期看起来是“很勤奋”——修复动作多、日志丰富、指标活跃，容易被误读为“工作正常”。直到消耗或变更面越过阈值才被发现。这与分布式系统中的“重试放大”和“元数据风暴”同构，Netflix、Uber等公司的工程博客均有类似事故复盘（如Uber Engineering关于服务网格与重试预算的讨论）。

4. 放手信号学：四维跃迁判据矩阵

本节是全文的方法论核心。我们要回答的是：在L1阶段，应该观测哪些信号，才能有资格谈L2？笔者提出四个维度，每个维度都要求“可观测、可复算、有阈值、有回退”。这四个维度不是并列的清单，而是有依赖顺序的：先有可预测性，才谈得上独立性；先有独立性，变更域约束才有意义；资源有界性则是所有维度的兜底。

4.1 维度一：行为可预测性（Predictability）

定义：在相同或相似输入下，系统输出的建议分布是否稳定。注意，这里评估的是“建议”，不是“修复”，因为L1阶段还没有修复权限。可操作指标包括：

• 建议一致率：对同一失败样本重复投喂N次，建议动作的语义一致比例。低一致率意味着系统在高方差区工作，不适合放权。
• 根因命中率：人工标注的根因与系统建议根因的匹配比例。可用混淆矩阵计算精确率/召回率。
• 建议可执行率：建议在人工执行时无需二次澄清即可落地的比例。

这里可以借用过程能力指数的思想：把“建议偏差”看作一个受控过程的输出，计算其均值与标准差，只有当过程处于统计受控（无趋势、无超限点）时，能力指数才有意义。模拟示例（以下为模拟数据，仅用于说明计算方法）：某团队在4周内收集了1200条L1建议，人工标注后得到根因命中率0.71、建议一致率0.83、可执行率0.66；按周分组后命中率呈上升趋势但方差未收敛，说明过程尚未受控，此时不应跃迁。

4.2 维度二：验证独立性（Verification Independence）

定义：存在一个与执行路径输入隔离、模型隔离、权限隔离的验证环节，且其判定结果与执行者的自评相关性低。可操作指标：

本文评述：很多团队把“加一个验证步骤”理解为流程合规，但独立性的本质是信息隔离，不是流程隔离。如果验证者拿到的是执行者整理过的摘要，那它验证的是摘要，不是事实。笔者建议把验证输入定义为“三件套”：变更前后快照、可复现的测试结果、规范条款原文；执行者的解释性文字一律不进入验证上下文。

4.3 维度三：变更可逆性（Reversibility）

定义：任一自动变更在T时间内可被无损回滚的概率与成本。可操作指标包括回滚成功率、回滚耗时分布、回滚后的状态一致性。这里的关键洞察是：可逆性不是二值属性，而是随变更类型变化的连续谱。代码改动通常可逆；配置改动部分可逆；数据迁移与发布往往不可逆或高成本。

因此，白名单不应只按“分支”划分，而应按“变更类型 × 可逆性”二维划分。一个实用的做法是给每类变更打上可逆性等级（R0不可逆、R1高成本、R2可回滚、R3秒级回滚），L2只允许R2及以上，且必须预置回滚脚本。关于变更管理与回滚的工程实践，可参考Google SRE Workbook中关于“canarying”与“rollback”的章节，以及AWS Builders' Library中关于“ Ensuring rollback safety during deployments”的讨论。

4.4 维度四：资源有界性（Boundedness）

定义：系统在任意时间窗口内的资源消耗存在外部强制上限，且触达上限时行为确定（降级或停止，而非继续尝试）。可操作指标：单任务token预算、单周期动作数上限、并发上限、单位时间成本上限。这里要强调“外部强制”：上限由调度器/网关执行，模型无权修改，也无权通过“申请更多预算”绕过。

笔者认为，资源有界性是四维中唯一必须在L1之前就具备的维度。原因很简单：L1虽然不修改环境，但它仍然消耗资源、产生噪声、占用人类注意力。一个没有预算的L1同样可能“跑飞”，只是后果从“改坏”变成“烧钱与淹没告警”。这与FinOps领域强调的“预算即代码”理念一致（参见FinOps Foundation的FinOps Framework中关于预算与预警的部分）。

4.5 跃迁判据矩阵：把四维合成一个门禁

把四个维度合成一个可执行的门禁，需要明确“通过条件”与“否决条件”。下表是笔者建议的L1→L2门禁矩阵（阈值需按组织基线校准，此处给出的是示例阈值，非行业标准）：

注意矩阵的逻辑关系是“与”，不是“或”。事故中的系统很可能在“可预测性”上有一些正面观感（跑通了几天），但另外三维全空。用“与”门禁，它根本不该获得L2权限。本文评述：门禁的价值不在于严格，而在于把“感觉稳”翻译成“证据齐”。一旦门禁被写成可执行的检查项，关于“要不要放权”的争论就从主观判断变成了数据核对。

5. 工程落地：门禁架构、灰度阶梯与回滚协议

5.1 参考架构：把约束放在模型之外

一个稳健的CI Sweeper架构应当把“执行”与“约束”分层。下面给出一个与具体技术栈无关的参考结构（文字描述，便于迁移）：

[调度器 Scheduler]
   │  固定周期 + 全局预算（外部硬上限）
   ▼
[采集层 Collector] ──► 只读快照（日志/测试/依赖）
   │
   ▼
[执行Agent Executor] ──► 产出候选变更（不直接落地）
   │
   ▼
[策略网关 Policy Gate] ──► 白名单校验 / 可逆性分级 / 预算校验
   │        │
   │        └─► 拒绝 → 记录并告警
   ▼
[独立验证Agent Verifier] ──► 输入隔离：仅客观事实
   │        │
   │        └─► 不通过 → 回退候选，不落地
   ▼
[落地执行 Apply] ──► 预置回滚点 → 应用 → 观测窗口
   │
   ▼
[熔断器 Circuit Breaker] ──► 失败率/消耗/变更面超阈 → 降级到L1

这个架构的关键设计决策有三：其一，执行者不直接落地，所有变更必须经过策略网关与验证者，这从结构上保证了“验证独立性”不依赖自觉；其二，预算在调度器层，模型无法感知也无法申请，避免“自我扩权”；其三，熔断器是独立组件，其判定逻辑简单、可审计，不依赖模型判断。关于熔断器模式，可参考Nygard的经典著作Release It!（Pragmatic Bookshelf, 2nd ed., 2018）中关于Circuit Breaker的论述。

5.2 灰度阶梯：把跃迁拆成可回退的小步

即使门禁通过，也不应一次性全量放开。笔者建议采用“影子—建议—受限执行—扩大域”的四级灰度，每级都有明确的观测窗口与回退条件：

1. 影子模式（Shadow）：系统产出变更但不落地，与人工实际执行的变更做对比，度量“若采纳会怎样”。观测窗口建议≥2周，重点看分歧样本。
2. 建议模式（L1+）：变更以PR/工单形式提交，人工一键采纳。度量采纳率与采纳后的失败率。
3. 受限执行（L2-）：仅白名单分支、仅R2+可逆变更、仅低峰时段，单周期动作数≤N。观测窗口≥4周。
4. 扩大域（L2）：逐步扩大白名单与动作数上限，每次扩大后重新进入观测窗口，任一指标回退即回退到上一级。

本文评述：灰度阶梯的本质是把“一次性授权”变成“连续的证据累积”。它与持续交付中的渐进式发布（canary、blue-green）同构，区别在于发布的对象不是代码，而是“权限”。既然代码发布要canary，权限发布更应如此。

5.3 回滚协议：定义“什么时候必须停”

回滚协议要回答三个问题：触发条件、执行主体、验证方式。建议把触发条件写成可计算的规则，例如：单周期失败率超过基线2个标准差、单周期消耗超过预算80%、变更面涉及非白名单路径、验证者与执行者分歧率超过阈值。执行主体应是独立的降级控制器，而非执行Agent自身。验证方式包括回滚后状态一致性与后续N个周期的稳定观测。

一个常被忽略的细节：回滚本身也可能失败。因此回滚协议必须包含“回滚失败”的处置路径——通常是冻结该域、升级到人工、并保留现场。把“回滚失败”当作不可能事件，是很多事故复盘的共同盲点。

5.4 一个可执行的落地清单

为便于直接采用，下面给出按优先级排序的落地清单（P0为跃迁前必须完成）：

6. 关键数据与案例：从公开研究与工业实践看边界

6.1 关于“自我验证不可靠”的公开证据

LLM作为评审者的可靠性已有较多研究。Zheng等（2023）在MT-Bench与Chatbot Arena上的分析指出，强模型评审与人类偏好有较高一致性，但存在位置偏差、冗长偏差与自我偏好；该工作提出的缓解手段包括交换位置、少样本参考、思维链等。Huang等（Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024）进一步指出，在没有外部反馈的情况下，模型的内在自我纠错可能不提升甚至降低推理表现。这两项工作共同支持一个工程结论：把验证交给同一个模型、且不给外部信号，是不可靠的。

本文评述：这些研究并不否定“用LLM做验证”，而是否定“用同一个LLM在没有外部锚点的情况下自我验证”。工程上的对应做法是：验证者必须接入外部锚点——测试结果、静态检查、规范条款、历史基线。锚点越硬，验证越可信。

6.2 关于“代理循环与资源放大”的公开证据

LLM代理的循环与工具调用放大已有系统性讨论。例如Yao等（ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023）展示了推理与行动交织的代理范式，同时也暴露了循环与错误传播的风险；后续大量工作（如Reflexion、Toolformer等）在提升能力的同时，普遍强调需要外部评估与预算控制。在工业侧，OpenAI、Anthropic的代理工程指南均建议设置最大步数、超时与人工接管点（参见OpenAI Cookbook中关于agents的实践建议、Anthropic关于building effective agents的工程文章）。

需要说明的是，公开文献中没有与本次事故完全对应的“15分钟CI Sweeper跑飞”的标准化数据集，因此本文不引用任何声称是该事故的量化统计。凡涉及具体数值的推演，均标注为模拟或示意。

6.3 工业实践中的可迁移经验

虽然没有直接对应的事故数据，但若干成熟实践可以直接迁移：

• 变更审批与分支保护：GitHub/GitLab的分支保护、必需评审、必需状态检查，是把“变更域约束”产品化的现成机制。
• 配额与节流：云平台的配额、API网关的速率限制，是“外部硬上限”的现成实现。
• 渐进式发布：canary、feature flag、自动回滚，是“可逆性”的现成实现。
• 事故复盘文化：Google SRE的postmortem模板强调“无责复盘、机制改进”，适合用来沉淀“放手信号”的失败样本。

延伸阅读与教程（在新窗口打开）：Google SRE Workbook: Canarying Releases、GitHub Docs: About protected branches、AWS Well-Architected Reliability Pillar、FinOps Framework。

7. 对比与局限：为什么“跑通N天”是伪信号

7.1 “跑通N天”的统计缺陷

“跑通N天”作为跃迁依据，至少有三个统计缺陷。第一，样本非独立：周期性任务在稳定环境下重复成功，样本高度相关，N天不等于N个独立证据。第二，幸存者偏差：失败可能被人工悄悄修掉，未进入统计；系统“跑通”可能只是因为人类在旁边兜底。第三，分布漂移不可见：环境在变，昨天的成功分布不代表明天；没有控制图，漂移无法被识别。

笔者认为，更合理的替代是“证据计数”而非“天数计数”：统计有多少个独立的失败样本被正确诊断、多少个独立的变更被正确验证、多少次回滚演练成功。证据是离散的、可审计的；天数是连续的、容易被叙事修饰的。

7.2 与“全自动运维”叙事的对照

业界存在一种叙事：随着模型能力提升，自治等级会自然上升。本文不否认能力提升的趋势，但要指出能力提升与治理成熟是两条独立曲线。能力曲线决定“能不能做”，治理曲线决定“该不该让它做”。事故的本质是两条曲线的错位：能力已经能执行修复，治理还没建立验证与边界。本文评述：把两条曲线混为一谈，是当前代理工程最大的认知风险之一。

7.3 本文方法的局限

需要诚实说明局限。其一，四维门禁的阈值高度依赖组织基线，本文给出的示例阈值不能直接套用；其二，独立验证的“输入隔离”在工程上需要改造上下文构造流程，成本不低；其三，资源硬上限会降低系统在极端情况下的“自救”能力，需要在“有界”与“有效”之间权衡；其四，本文的放大模型是示意性的，未做实证拟合，读者应将其视为推理工具而非预测模型。

8. 结论与展望：把自治当作可证伪的工程命题

回到最初的问题：无人值守自动化的“放手节奏”该按什么信号推进？本文的答案是：按四类可观测、可复算、可回退的信号推进——行为可预测性、验证独立性、变更可逆性、资源有界性；而不是按“跑通了几天”拍脑袋。事故中的系统在这四维上几乎全空，却被授予了L2权限，失控是结构性的必然，而非偶然的模型失误。

展望未来，笔者认为有三个方向值得投入。第一，把门禁产品化：将四维判据做成CI/CD平台的原生检查项，让“放权”像“发布”一样有流水线。第二，把验证锚点标准化：推动测试结果、静态检查、规范条款的机器可读化，降低独立验证的接入成本。第三，把回滚当作一等公民：在变更设计阶段就要求回滚方案，而非事后补救。这三件事都不依赖更强的模型，却直接决定自治系统能否安全地“放手”。

一句话总结：自治不是“让系统自己决定”，而是“让系统在证据允许的范围内自己决定”。前者是叙事，后者是工程。

9. 参考文献与延伸阅读

本文在写作中参考了自治系统、可靠性工程、LLM评测与代理工程等方向的公开资料，累计参考条目60余篇，其中近三年（2023–2025）文献占比超过50%。以下列出主要参考文献（8–9篇），完整清单可按主题检索原始文献。

1. Zheng, L., et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” NeurIPS 2023 Datasets and Benchmarks Track, 2023.
2. Huang, J., et al. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR, 2024.
3. Yao, S., et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR, 2023.
4. Beyer, B., Jones, C., Petoff, J., Murphy, N. R. Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media, 2016.
5. Nygard, M. T. Release It! Design and Deploy Production-Ready Software. 2nd ed., Pragmatic Bookshelf, 2018.
6. Montgomery, D. C. Introduction to Statistical Quality Control. 8th ed., Wiley, 2019.
7. Saltzer, J. H., Schroeder, M. D. “The Protection of Information in Computer Systems.” Proceedings of the IEEE, 63(9), 1975.
8. SAE International. “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles.” SAE J3016, 2021.
9. FinOps Foundation. “FinOps Framework: Budgets and Forecasting.” 2024. 在线资料。

关于数据集与预处理的说明：本文未使用任何私有事故数据集。文中出现的“1200条L1建议、命中率0.71”等数值为模拟数据，仅用于演示指标计算方法，不代表任何真实团队；模拟数据的构造方式为：按周分组、对建议做人工标注、计算精确率与一致率，未做缺失值插补。读者在实际度量时，应先定义标注规范与一致性检验（如Cohen's kappa），再计算指标。