摘要：运维智能体已在真实企业里上生产——Datadog 的 Bits AI SRE、微软 Azure SRE Agent、ServiceNow 的 AIOps 都已 GA 或宣布可触发修复。于是问题不再是「能不能做」，而是「哪些动作、什么自主级别、什么控制条件」。本文给出一个只用两个客观属性定级的分级器：可逆性与爆炸半径，模型能力不参与定级。
一、问题变了
第一代 AIOps 是个阅读工具：吃进告警、日志和指标，把相关信号归组、抑制重复、指向可能的原因。从「判断哪里出问题」到「敲下那条修复命令」，每一步都留给人。现在闭环被合上了。同一条链路里，智能体开始带凭据去执行：重启进程、扩容、回滚部署、切换主备。这里的变化不是智力，是凭据。
一个能重启服务的智能体，手里就握着一份能重启服务的凭据。治理问题于是从「它的分析准不准」变成了：这个身份被允许做什么，做了之后谁会发现。微软、Datadog、ServiceNow 三家在 2025-12 到 2026-05 之间陆续把这类能力推进到 GA，其中一家的表述是「触发修复」。行业把它当成了产品能力发布，但对使用方来说，它同时是一个授权问题。
二、为什么是运维先被放开
三个属性让运维成为智能体碰生产的第一个领域：
| 属性 | 含义 | 对智能体的意义 |
|---|---|---|
| 规程是写下来的 | 成熟的 runbook 本身接近一份规格说明 | 智能体有可依据的执行规格，不必靠推理补 |
| 工作是重复的 | SRE 对这个有标准定义：手工、重复、可自动化、战术性、无持久价值 | 重复意味着可度量、可回归 |
| 结果是可测的 | 事故时长、重开工单、变更失败率已有基线 | 智能体可以被放进既有考核里对比 |
第三条尤其关键：运维是这个楼里少数几个「智能体的成绩单早就在记了」的地方。你不需要为它新建一套评估体系。
三、定级只用两个属性
要给动作定级，先要选对判断维度。这里用两个客观属性，与模型能力无关：
- 可逆性：这个动作做错了，能不能退回去？
- 爆炸半径：做错了，影响面是单实例、单服务、单机房，还是全局？
之所以把模型能力排除在外：一个更聪明的模型不会让「删库」变得可逆。把模型能力引进定级，会让「性能更好所以可以更放开」变成一个似是而非的推论。下面这个分级器把两个属性编码进去，输出建议等级与必配控制项。
# agent_action_ladder.py LADDER = { 0: ("只读", "可以全自动，错了只是浪费阅读时间"), 1: ("建议", "输出结论给人看，人不点头就不动"), 2: ("批准后执行", "人按一次确认，动作本身由机器做"), 3: ("执行并报告", "事中自主，事后留痕，必须有人能叫停"), } BLAST = {"单实例": 1, "单服务": 2, "单机房": 3, "多机房": 4, "全局": 5} def classify(a): if not a["writes"]: return 0, ["日志留存"] # 只读动作直接进 0 档 level, missing = 3, [] if not a["reversible"]: # 不可逆 -> 天花板 2 档 level = min(level, 2); missing.append("执行前人工确认（不可逆）") if BLAST[a["blast"]] >= 3: # 影响 >= 单机房 -> 天花板 2 档 level = min(level, 2); missing.append("限定变更窗口") if BLAST[a["blast"]] >= 5: # 全局 -> 降到只出方案 level = min(level, 1); missing.append("全局动作仅出方案，不自动执行") if not a["runbook"]: # 无规程 -> 降一档 level = max(1, level - 1); missing.append("无 runbook，须先补规程") if a["credential"]: missing += ["最短生命期凭据", "完整审计轨迹", "已演练的 kill switch"] return level, list(dict.fromkeys(missing))跑出来的结果（12 个常见动作）：
| 动作 | 可逆 | 爆炸半径 | 建议等级 | runbook |
|---|---|---|---|---|
| 告警聚合去重 | — | 全局 | 0 · 只读 | 有 |
| 生成根因假设 | — | 全局 | 0 · 只读 | 有 |
| 工单分派 | 是 | 单服务 | 3 · 执行并报告 | 有 |
| 清理缓存 | 是 | 单服务 | 3 · 执行并报告 | 有 |
| 重启进程 | 是 | 单实例 | 3 · 执行并报告 | 有 |
| 服务扩容 | 是 | 单服务 | 3 · 执行并报告 | 有 |
| 回滚部署 | 是 | 单服务 | 3 · 执行并报告 | 有 |
| 临时授予生产权限 | 是 | 单服务 | 3 · 执行并报告 | 有 |
| 切换主备（failover） | 是 | 单机房 | 2 · 批准后执行 | 有 |
| 改超时/限流参数 | 是 | 单服务 | 2 · 批准后执行 | 无 |
| 改防火墙规则 | 否 | 单机房 | 1 · 建议 | 无 |
| 删除数据 | 否 | 全局 | 1 · 建议 | 无 |
分布：0 档 2 个、1 档 2 个、2 档 2 个、3 档 6 个。读的动作 2 个，写的动作 10 个。
四、从这张表能读出什么
第一，能长期挂在最高档的动作有一个很窄的画像：可逆，且影响不超出单服务。12 个动作里只有 6 个符合，且全是「重启、扩容、回滚、清缓存、派单」这一类——错了再按一次就能回来。
第二，不可逆动作的天花板是「批准后执行」，降到「建议」也合理。注意「删除数据」落在 1 档：机器可以提出「建议删掉这个分区」，但执行的手不该是它。
第三，没有 runbook 的动作先降一档。这一条容易被忽略但很实际：Agent 在没有事先写下的规程时，只能靠推理拼步骤，等于每次现场即兴发挥。换句话说，runbook 是智能体自动化程度的前置条件，而不是配套文档。
第四，「临时授予生产权限」的档位和「重启进程」一样高，但它需要一个别人不太准备的对照。它的可逆性来自凭据会过期，爆炸半径来自权限范围。所以它必须配「最短生命期凭据 + 完整审计轨迹」——这两项在表里对所有需要凭据的动作都出现了，但对这一类是主要控制手段，对重启进程只是辅助。
五、四档的判定顺序与「收益/代价」结构
判断一个动作能不能往上走，问四句就够：
- 它写不写状态？不写 → 0 档，直接全自动。
- 做错了能退回来吗？不能 → 封在 2 档以内。
- 错了影响多大？超过单服务 → 加变更窗口；到全局 → 只能出方案。
- 有写下来的规程吗？没有 → 降一档，先把规程补上。
还有一层不常被提到的性质：这四档的成本结构不一样。
| 档位 | 谁在消耗 | 能否随规模摊薄 |
|---|---|---|
| 0 只读 | 算力 | 能 |
| 1 建议 | 人的阅读时间 | 不能（每条建议都要有人看） |
| 2 批准后执行 | 人的确认动作 | 不能（规模越大越堵） |
| 3 执行并报告 | 事后复核与审计存储 | 部分（留痕可自动，复核要抽样） |
1 档和 2 档的代价是人的注意力，它不随规模摊薄。所以把动作留在「需要人按确认」这一档，控制力最强但扩展性最差；把它推到 3 档，扩展性好但必须把留痕和叫停做扎实——因为这时候人的介入已经从事前挪到了事后。
还有一层容易被忽略的后果：这四档不能「整体升级」。有些团队会把整个智能体的权限一次性从 2 档提到 3 档，理由通常是「试运行阶段表现不错」。但准确的说法应该是：逐个动作、用证据换级别。同一个智能体在「清理缓存」这个动作上跑了一百次没出事，这个证据不能迁移到「切换主备」上——它们需要的凭据强度、变更窗口、回滚路径都不一样。等级是动作的属性，不是智能体的属性。
六、常见误区
误区一：按智能体授权，而不是按动作授权。「这个智能体是可信的，给它管理员权限」——授权单位错了。同一个智能体，读日志和删数据需要的凭据强度差了几个量级。
误区二：把「有人盯着」当成控制。有人看 ≠ 拦得住。控制项要具体到「凭据有效期多长、变更窗口是什么、叫停按钮谁按过、演练记录在哪」。
误区三：用活动量当成绩。工单转派量和「被 AI 处理过的事故数」这类指标会在可靠性下降时同时上升。真正该看的是事故解决时长、重开工单率、变更失败率——这三个已有基线，不需要新建。
误区四（这是我写这个脚本时自己踩的）：分级器的降档逻辑会越过语义边界。我最初把「无 runbook 降一档」写成 max(0, level - 1)。结果「删除数据」这种不可逆 + 全局 + 无规程的动作被连降两档，落到了 0 档「只读」。「删除数据」显示为「只读」——这不是更保守，这是分类错位。一个会改状态的动作，无论被降多少级，都不该落进「只读」这一档。修法是把写动作的地板设在 1 档：max(1, level - 1)。这个 bug 值得单独说，因为它不是编码疏忽，而是规则设计的典型失误：当多条降档规则可以叠加时，必须为每一类动作设一条不可越过的下限，否则「更严格」的规则组合会产生语义上荒谬的结果。分级器如此，权限策略引擎也是如此。
七、结论与适用边界
三条结论：
- 定级依据是两个客观属性，不是模型能力。可逆性决定天花板，爆炸半径决定要不要人按确认，runbook 决定能不能起步；
- 1 档和 2 档的代价是人的注意力，它不随规模摊薄。这是自治等级的真正约束——不是模型能不能做，而是人能不能跟上；
- 推上 3 档的前提是留痕与叫停做扎实。因为此时人的介入已经从事前挪到事后，审计轨迹就是唯一的兜底。
边界：本文的分级器是一个可调整的骨架，BLAST 的档位划分与「降一档」的力度都应按你们自己的变更管理规程校准；表里的 12 个动作也只是常见集，实际要先把自己团队的变更项列全再套。在信创环境的运维治理里，这件事还有一个额外约束：国产化环境对日志留存、操作审计、危险操作拦截这类要求通常写得比通用环境更明确。金蝶天燕 Apusic AI 极光 Aurora 一类面向应用运维与治理场景的智能体，在设计上把「运维操作可控可审计、操作留痕、异常回滚」作为独立特性而不是附加功能，对应的正是 3 档动作真正需要的那套底子——执行动作的不只是模型，还有它身后那条可追溯的记录。
下一篇：《FalkorDB的一组CVE_调试构建里的保护生产没有》——本文说的是「凭据决定边界」，那篇说的是「保护只在开发环境存在」：同一份代码，调试构建里的边界检查在发布版本里被编译掉了。如果明天给你的运维智能体开放一个写权限，你会先开哪一个动作？以及更关键的——你们现在有哪个 kill switch 是真的演练过的？
