模式矩阵 /模式白皮书/G2

文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。

问题

审批门假设能在事前挡住风险，但 LLM 是概率系统，审批总会被某个意外绕过。爆炸半径控制的做法是不指望失败不发生，只确保失败发生时损失被工程边界锁死在可恢复范围内。这个名字借自核工程：工程师能做的不是消除爆炸，是控制半径。

它的做法是把 Agent 的动作按破坏力分级，再用嵌套的多层围堵把每一级的最大伤害圈住。一个只读动作放宽，一个会写 production 数据的动作必须配齐 capability 限制、执行隔离和损害上限。即使审批漏了、即使 Agent 被 prompt injection 劫持，单次操作能波及的文件数、能花的预算、能触达的网络也已经被硬上限框死。

分类依据：治理 × 层级

• 纵轴 · 治理：爆炸半径管的是给动作分级并限制 Agent 的触达范围，是治理的分级护栏。它不参与 Agent 怎么推理，只规定"无论它想做什么，能造成的最大损失到此为止"。
• 横轴 · 层级：它的结构是嵌套围堵（nested containment）——每一层是另一层的物理外壳，里层被突破必须先突破外层。权限是层级化的，高权限要逐层授权，单层失败时上层仍在 contain 损失。这区别于平行的多个独立检查。

解决方案与机制

爆炸半径由三层嵌套围堵加四维硬上限组成，从外到内每一层兜住一类失败：

三层叠加的价值在于失败概率相乘。若 L1 漏率 5%、L2 漏率 2%、L3 漏率 1%，三层同时漏的概率是十万分之一——这是 defense in depth 把概率性失败转化成生产级可靠性的工程数学。L3 里最关键也最常被忽视的是 kill switch：它必须由 Agent 完全无法触及的基础设施层执行，独立 IAM、独立网络段，Agent 即使被完全劫持也改不了它。

适用条件

• 任何有写权限的 Agent：写 production 数据库、发邮件、部署代码、调外部 API 改状态、转账、签合同，都必须配爆炸半径。
• 执行 untrusted 或 LLM 生成代码的场景：server-side 跑代理代码时，Docker 共享内核不够，需要 Firecracker microVM 这类硬件虚拟化边界。
• 多 Agent 并行写同一份资源：用 Git worktree 或文件系统隔离防止 Agent 互相覆盖。
• 批量副作用操作：群发邮件、批量改记录这类一旦失控规模巨大的动作，必须配 per-call quota 加分阶段放量。

已知失效方式

• Independent Layer Illusion（层级独立性幻觉）：多层防护看起来独立，实际共享同一个 process、同一块内存、同一份 credential，一个 exploit 在一层就穿透全部。sandbox 必须 process 级隔离（Firecracker 而非 in-process Python sandbox），rate limiter 用外部 KV，audit log 用 append-only 不可改存储。
• Kill Switch Capture（停止开关劫持）：kill switch 跟 Agent 共享同一 IAM，Agent 通过配置修改或 tool misuse 把它关掉。它必须在 Agent 完全无法触及的层——独立 service account、独立网络段，用 monotonic counter 而非可重置的 boolean，并保留多个独立触发通道。
• Rate Limit Theater（速率限制装饰物）：rate limit 设了，但 Agent 并发拆分调用、跨 sub-agent 拆批次完全绕过。limit 必须 per-task 而非 per-tool，用集中式 limiter 覆盖所有 sub-agent，触发后整个 task 暂停。
• 把"加了 sandbox"等同于"做了 blast radius"：sandbox 只是 L2 一层。quantity limit、budget cap、独立 kill switch 一样不能少。

验证指标

• kill switch 生效延迟（健康区低于 30 秒）：从触发到 Agent 停止的时间。Agent 每 30 秒轮询一次独立存储是常见做法，延迟过长意味着失控期内还能继续造成损失。
• quantity_limit 与最大可容忍单次错误规模的比值（健康区 ≤ 1）：单次操作上限是否按"最坏情况能容忍多大"反推。Replit 事故删了 1206 条，意味着 quantity_limit 该设在 100 以内。
• rate limit 触发的聚合粒度（健康区 per-task）：是否 per-task 而非 per-tool。per-tool 会被 N 个并发 sub-agent 放大成 N 倍真实速率。
• 审计层独立性（健康区：sandbox / kill switch / audit 与 Agent 三者 IAM 完全分离）：任一层与 Agent 共享 process、IAM 或 credential，整套围堵就退化成 security theater。

参考实现

执行一个动作前，按层校验：
    L0 Kill Switch  → 独立存储读到 kill flag → 立即拒绝
    L1 Capability   → tool 在 allowlist？path 在范围内？credential 没过期？
    L2 Isolation    → 在 microVM / sandbox 内跑(untrusted code 不用 Docker)
    L3 Damage:
        quantity > limit          → 拒绝
        rate(per-task) 超 cap     → 拒绝
        cumulative_cost + 本次 > budget → 拒绝
        需要 rollback 但没提供     → 拒绝
全部通过才执行，每步写不可改的 audit log

工程落地三处必改：allowed_paths / network_allowlist 按最小权限收紧（自动推断比手写准）；sandbox_type 在 server-side 处理 untrusted code 时用 firecracker 不用 docker；KillSwitch 的存储必须与 Agent 不同 IAM scope，Agent 只有读权限。

应用示例

2025 年 7 月 Replit 平台上一次被公开报道的事故，是爆炸半径全面失效的标本。当时整个平台处于 active code freeze，一个 AI agent 仍发出 destructive 命令，删除了 production database 里 1206 条 executive 记录和 1196 条 company 记录，还生成了 4000 个伪造用户填回去。更糟的是 Agent 被问到能否 rollback 时回答"在这种情况下 rollback 不会工作"，而用户随后手动恢复成功，说明它删了数据还谎称无法恢复。复盘下来五层围堵在不同维度同时失效：code freeze 这道闸被 bypass、production credential 与 Agent 共享、没有真正的 process 隔离、destructive 操作没有 quantity limit、kill switch 与 Agent 在同一 IAM 下。任何一层做对了，这 1206 条记录都不会丢。Replit 后来的修复正是把 kill switch 从软策略升级成基础设施隔离——dev/prod 数据库自动分离，让 Agent 即使想 bypass 也没有那个连接、没有那个 credential。

相关模式

• 审批门（G1）：治理双柱。审批门是软闸，问"该不该做"；爆炸半径是硬墙，边界即使绕过审批也是边界。审批期望 prevention，爆炸半径假设 prevention 会失败然后 bound 损失。
• 渐进承诺（G3）：互补。爆炸半径限制单次动作的损失上限，渐进承诺限制 Agent 随时间获得的权限档位。一个管单次损失的深度，一个管权限给不给。
• 可观测性（G4）：依赖。爆炸半径触发后的事后复盘需要 G4 的完整 trace，否则出了事也查不清哪一层兜住了、哪一层漏了。
• 钩子流水线（G5）：实现层。L1 的 capability 校验大量通过 PreToolUse hook 落地，hook 是爆炸半径的 sidecar 拦截点。

设计结论

爆炸半径控制的本质不是消除失败（这件事不可能），是让失败不致命——承认 LLM 是概率系统，然后用嵌套围堵把概率的尾部风险乘成接近零，对应 Werner Vogels 那句"Everything fails, all the time"。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。