AI 学习笔记（三十）：LLM 例外基线收敛与跨团队治理自动化最小实践

发表于 分类于 阅读次数： Changyan： 本文字数： 4.5k 阅读时长 ≈ 4 分钟
runtime drift 检出来以后，真正容易拖垮治理的是各团队各写各的例外单。把字段、审批边界、到期回收和自动阻断收敛到同一套基线，例外才不会越滚越大。

上一篇我们把 runtime drift detection 接进了生产链路。

问题很快会往前再走一步。

漂移被扫出来，不代表团队知道该怎么收。
更麻烦的是，很多团队的例外机制从一开始就不是同一种语言：

  1. A 团队把例外写成 Jira comment
  2. B 团队把例外写成审批单附件
  3. C 团队只在发布群里留一句“今晚先放开，明天再补”

最后常会变成一种很熟的局面：

扫描器越来越多，例外越来越乱，真正能自动处置的却越来越少。

这篇就接着前一篇往下推，聊一个比“再加一条检测规则”更要紧的动作：

先把跨团队的例外基线收敛，再把审批、时效、回收和运行时联动做成自动化。

1. 为什么 drift 检出来了，治理还是收不住

很多团队在这一步卡住，根因通常是“什么叫合法例外”没有统一定义。

常见混乱大概长这样：

  1. 有的团队要求写清补偿控制，有的只写“业务紧急”
  2. 有的团队例外默认 24 小时过期，有的默认一周
  3. 有的团队把模型切换、工具放权、预算放宽放在一张单里，有的拆成三种流程
  4. 有的团队 owner 写个人，有的写群组，有的根本不写

这样一来，运行时看到的往往不是“例外对象”，而是一堆无法稳定解释的文本片段。

结果就是两头都难受：

  1. 平台侧不敢自动回收，怕误伤真实业务窗口
  2. 业务侧觉得治理总在找麻烦，因为每次都要重新解释背景

所以顺序不能反。

别先堆自动化。
先让所有团队对下面几件事用同一套结构说话：

  1. 这次放宽的到底是什么
  2. 风险范围有多大
  3. 打算开多久
  4. 谁来兜底
  5. 到期以后系统该怎么收回来

只有这些信息先收敛，后面的检测、告警、自动回收才有稳定含义。

2. 例外基线先收四类字段，别一上来做大而全

我更建议先把基线压到四类字段。

够用，且容易审。

1) 变更对象

也就是你到底放宽了什么。

最常见的是：

  1. 模型或路由
  2. 工具权限
  3. 预算阈值
  4. 数据外发或联网范围

这个字段必须能直接映射到系统配置，不能只写抽象原因。

2) 风险边界

至少写清：

  1. 影响租户范围
  2. 是否涉及写操作或外发
  3. 是否允许跨环境扩散
  4. 补偿控制是什么

没有边界，后面的审批和自动回收都没法判。

3) 时效约束

这里不要只写过期时间。

还要把三件事写死：

  1. 生效时间
  2. 到期时间
  3. 到期后的默认动作

默认动作很关键。
我建议只允许三种：

  1. 自动恢复基线
  2. 自动冻结高风险路径
  3. 升级人工确认后继续

4) 责任与证据

至少包括：

  1. owner
  2. 批准人
  3. 对应事件或变更单
  4. 评估材料链接
  5. 回收确认人

这些字段听起来很“流程”，但没有它们，例外永远会变成没人收尾的长债。

3. 跨团队收敛，不靠培训，靠一张可执行矩阵

很多组织喜欢先开一次对齐会，再发一篇规范。

这类方法能起一点作用，但撑不住高频变更。
真正有效的，还是把例外矩阵直接做成系统输入。

最小版本我建议长这样：

例外类型 默认上限 额外审批 到期动作 允许自动续期
模型灰度扩容 24 小时 平台 owner 自动恢复基线 否
工具权限放宽 8 小时 安全 + 平台 自动冻结高危工具 否
成本阈值上浮 72 小时 业务 owner 恢复预算上限 是，限一次
外发渠道临时放开 4 小时 安全 owner 自动关闭出口 否

这张表不是摆给人看的，它应该直接驱动：

  1. 表单校验
  2. 审批路由
  3. 运行时策略
  4. 到期回收任务

只要团队提交的例外不在矩阵里，就别让它直接进生产。

这一步看着像流程收紧。
实际是在让系统知道接下来该怎么判。

4. 一个够用的最小数据模型

下面这版模型，已经足够把“提交例外”变成“系统可执行对象”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
type ExceptionType =
  | 'model_route_expand'
  | 'tool_scope_expand'
  | 'cost_cap_raise'
  | 'egress_open';

type ExceptionAction = 'restore_baseline' | 'freeze_high_risk_path' | 'require_manual_reapproval';

interface ExceptionRequest {
  id: string;
  type: ExceptionType;
  env: 'staging' | 'prod';
  scope: 'tenant' | 'workspace' | 'global';
  owner: string;
  approvers: string[];
  reason: string;
  compensatingControls: string[];
  startsAt: string;
  expiresAt: string;
  incidentRef?: string;
  changeRef?: string;
}

interface ExceptionBaseline {
  maxDurationHours: number;
  requiredApproverRoles: string[];
  allowAutoRenewOnce: boolean;
  expireAction: ExceptionAction;
}

function validateExceptionWindow(
  request: ExceptionRequest,
  baseline: ExceptionBaseline,
): string[] {
  const errors: string[] = [];
  const durationMs = Date.parse(request.expiresAt) - Date.parse(request.startsAt);
  const durationHours = durationMs / (1000 * 60 * 60);

  if (durationHours <= 0) {
    errors.push('invalid exception window');
  }

  if (durationHours > baseline.maxDurationHours) {
    errors.push('exception duration exceeds baseline');
  }

  if (!request.compensatingControls.length) {
    errors.push('missing compensating controls');
  }

  return errors;
}

重点不在字段多不多。
重点在于这份结构已经能支撑三件事：

  1. 提交时校验
  2. 发布前阻断
  3. 到期后自动回收

接下来再补“审批角色是不是够”“范围是不是越权”“是否允许续期”，都能继续往这个模型上接。

5. 真正该自动化的是整条收放链路

很多团队把自动化理解成“单子能不能自动流转”。

这当然有用，但还不够。

例外治理真正该自动化的是下面这条链：

  1. 提交时归一化
    把不同团队的输入映射成统一字段，不接受自由发挥式模板。
  2. 发布前策略校验
    如果例外已过期、审批角色不够、范围超过基线，直接阻断发布。
  3. 运行时绑定
    把例外 ID、owner、过期时间挂进真实配置和审计日志，而不是只留在审批系统。
  4. 周期巡检
    扫描“仍生效但已过期”“已回收但配置未恢复”“重复续期超过阈值”的对象。
  5. 到期回收
    按 expireAction 自动恢复、冻结或升级人工处理。

下面这个示例把“到期动作”接进运行时：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
interface RuntimeControl {
  toolScope: 'tenant' | 'workspace' | 'global';
  costCapUsd: number;
  egressEnabled: boolean;
}

function applyExpireAction(control: RuntimeControl, action: ExceptionAction): RuntimeControl {
  if (action === 'restore_baseline') {
    return {
      toolScope: 'tenant',
      costCapUsd: 500,
      egressEnabled: false,
    };
  }

  if (action === 'freeze_high_risk_path') {
    return {
      ...control,
      toolScope: 'tenant',
      egressEnabled: false,
    };
  }

  return control;
}

这才是例外自动化真正值钱的地方。
重点不在把流程电子化。
重点在于让“放出去的权限”能按约定自己收回来。

6. 盯四个指标，才知道你是在治理还是在堆债

做完自动化之后，很多团队会觉得系统已经稳了。

我不这么看。
如果下面四个指标没人盯，例外债还是会慢慢涨回来。

1) 活跃例外数

按环境、类型、团队拆开看。
只看总量没有意义。

2) 逾期未回收率

这是最直接的健康指标。
只要开始上升，说明自动回收、owner 责任或审批门槛至少有一处在失效。

3) 重复续期率

同一系统、同一原因、连续几次都在申请同类例外，通常说明根因没修。

4) 例外转常态占比

如果某条例外被多个团队长期复用，别再当例外处理。
要么升成正式策略，要么明确禁止。

我更倾向给平台团队设一个简单红线：

任何例外如果连续两次续期，下一步默认就该是“立项修根因”。

这样才能防止治理系统变成“合规包装过的临时方案收容所”。

7. 落地顺序和回退思路

这类能力别一次铺满。

更稳的顺序是：

  1. 先统一字段和例外矩阵
  2. 再把发布前校验接进去
  3. 然后补运行时绑定和到期回收
  4. 最后再做自动续期限制、重复例外告警和跨团队报表

回退思路也要提前准备。

如果自动回收策略第一次上线，我建议保留一周“观察模式”：

  1. 系统先只生成回收计划，不直接执行
  2. 让 owner 和平台团队验证命中是否合理
  3. 命中率稳定后，再切到自动恢复或自动冻结

别一上来就全自动。
例外治理最怕的是误回收把真实事故窗口也一起关掉。

8. 这篇想解决的核心问题

很多团队以为例外治理的难点在审批。

我更愿意把问题说得直接一点：

真正难的是系统能不能稳定知道“为什么批、批到哪、什么时候收、谁负责收”。

如果这些信息不能收敛成同一种结构，例外就永远只能靠人盯。

而一旦还能靠人盯，迟早就会有人不再盯。

所以这一步别再停在发一篇规范。
要把跨团队例外基线收成一套可执行对象，再把发布、运行时、到期回收接成同一条链。

到这里，例外才算从“历史债的缓冲区”，慢慢变成“可控、可回收、可审计的短期机制”。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-exception-baseline-convergence-governance-automation/