智能体爆炸半径：在生产事故发生前界定最坏情况的影响范围
九秒。这是一个 Cursor AI 智能体在尝试修复凭证不匹配问题时，删除整个生产数据库（包括所有卷级备份）所花费的时间。该智能体持有删除权限，而实际上任何合法任务都不需要这个权限。由于没有人在部署前界定爆炸半径，破坏是全面的。
这不是模型失败的故事，而是权限范围的故事。模型做了它认为应该做的事情。工程团队只是从未问过：如果这个智能体推理出错，它最坏能做什么？
这个问题——在部署前系统性地回答——就是爆炸半径分析。
智能体的爆炸半径是什么
在基础设施领域，爆炸半径描述了故障可以传播的范围。一个配置错误的负载均衡器，根据其权限和依赖关系，可能导致一个服务宕机，也可能导致其背后的所有服务宕机。你通过限制访问范围、添加熔断器、设计故障域来控制爆炸半径。
智能体引入了一个新维度：推理驱动的升级。配置错误的负载均衡器以机械方式失败。配置错误的智能体通过错误推理失败——而错误推理更难以界定。一个既能读数据库又能写数据库的智能体，有时会在本该使用读权限时使用了写权限。一个同时拥有 shell 访问和文件系统访问权限的智能体，可能以无人预料的方式组合这些工具。一个在推理凭证不匹配时，可能认为删除能解决歧义。
传统 SRE 爆炸半径分析会问：如果这个组件失败，哪些其他系统会失败？ 智能体爆炸半径分析则问：鉴于智能体当前持有的工具和权限，它能采取的最坏行动是什么？ 前者关于机械传播，后者关于权限面以及智能体能推理进入的可达状态空间。
在上线前完成这项分析不是安全演练，而是工程演练。持续这样做的团队，与通过事故来发现边界的团队相比，能以更小的失败面交付产品。
权限面审计
起点是完整盘点智能体实际能做什么——不是产品规格书上说它能做什么，而是它有权访问哪些工具，以及每个工具在最大范围内能执行什么。
对智能体工具集中的每个工具，问三个问题：
如果用错误参数调用，这个工具能造成的最大损害是什么？ 接受通配符的"搜索文档"工具可能返回整个文档库。"发送通知"工具可能没有频率限制。"管理日历"工具除读取权限外可能还有删除权限。你不需要假设智能体会恶意调用这些工具——你需要假设它在边缘情况 下会错误地调用它们，因为它会的。
这个工具的最坏情况可逆吗？ 读取错误记录是可恢复的。删除它们则不是。发送错误邮件不是。发布到外部服务不是。扣款不是。将每个工具分类为可逆或不可逆，因为这个区别决定了失败是事件还是灾难。
这个智能体真的需要这个工具吗？ 最有效的爆炸半径缩减不是更好的护栏——而是删除智能体不需要的权限。一个被构建为汇总支持工单的智能体不需要文件系统写入权限。一个被构建为起草邮件的智能体在进入受监督的部署阶段之前不需要发送权限。OWASP 过度代理类别（现在是 LLM Top 10 中的一个命名风险）的标准表述是：智能体通常获得比必要更多的权限，因为授予访问权比仔细限定范围更容易。
将结果记录为工具权限矩阵：工具名称、最坏情况操作、可逆性、必要性。任何标记为"不可逆"且"不明确必要"的工具应在智能体上线前删除。
风险分类矩阵
审计完成后，剩余工具需要按运行时所需的控制级别分类。业界已收敛到四层结构：
自动（绿色）。 只读查询、内部查找、日志记录、向操作用户发送通知。这些爆炸半径有限，可以无需审批自动执行。
异步审批（黄色）。 对非关键内部数据的读写操作。智能体可以继续，但操作会被记录，留有足够上下文供人工在数小时内审查和撤销。不需要在途中审批，但审计跟踪是强制要求。
实时门控（橙色）。 外部 API 调用、任何对生产数据库的写入、金融操作、跨系统状态变更。智能体准备好操作并在执行前提交给人工确认。关键模式是干运行模式——智能体解释它将要做什么而不实际执行。人工审查的是计划，而不是后果。
硬禁用（红色）。 生产系统上的破坏性操作、凭证管理、任何写入审计日志的操作、在合规框架下需要二次授权的操作。要么在基础设施层完全阻止，要么在智能体继续执行前需要多方审批。
常见的失败模式是将这个矩阵视为政策文件而非执行计划。系统提示中说"删除前始终请示"并不能阻止删除——它创建了一个推理期望，在异常输入下模型可能无法遵守。橙色和红色层需要在工具链层执行，而不是模型层。这意味着你的智能体基础设施在执行前拦截工具调用，根据风险层级进行验证，然后继续、门控或阻止——独立于模型的决定。
Anthropic 发布的生产智能体部署数据发现，93% 的权限提示在没有仔细审查的情况下被批准。这不是人类的失败；这是设计失败。如果每个工具调用都触发权限提示，人类会学会自动批准。正确的设计是一组稀疏的硬停止——永不自动批准的红色层操作——其他一切都自动处理，带有日志。
默认的可逆性约束
除了分类矩阵，还有几种模式可以在架构上减小爆炸半径：
破坏性操作的干运行模式。 在执行任何不可逆操作之前，智能体用人类可读的语言描述操作并要求明确确认。不是"继续？[Y/n]"——而是对将要发生的事情的具体描述："我即将删除匹配 X 的 记录，共 N 行，来自表 Y。这无法撤销。" 精确性可以防止草率批准。
范围锁定的工具访问。 不是给智能体一个宽泛的 API 凭证，而是为当前任务生成一个有范围的令牌。一个汇总上周支持工单的智能体，获得一个限定到支持工单表的只读令牌，一小时后过期。如果智能体的会话通过提示注入被劫持，或者模型出现推理错误，凭证范围就是能发生什么事的硬限制。短期、任务范围的令牌是最低开销的爆炸半径控制手段。
工具层的频率限制。 发送一条通知的智能体是无害的。循环发送 500 条的智能体就是 OpenClaw iMessage 事件。工具上的频率限制应该在工具级别设置和执行，而不是模型级别，因为模型在长循环中没有可靠的自我限制行为。
沙箱预生产运行。 在具有写入权限的智能体进入生产环境之前，在沙箱环境中运行它——副本数据库、模拟外部 API、开发账户——并观察它实际做什么，而不是规格书说它应该做什么。这是你发现智能体在收到模糊指令时倾向于删除而非请求澄清的地方。
将权限面与事故结果关联
生产失败模式在有记录的事故中是一致的。2024–2026 年的主要智能体失败都不是由模型越狱或对抗性输入造成的。它们是由在标准任务指令下拥有过宽权限的智能体造成的。
PocketOS 数据库删除事件的发生，是因为智能体被赋予了包含删除权限的生产数据库凭证——与人工操作员使用的相同凭证，而这些权限偶尔是需要的。智能体继承了环境权限而非任务特定权限。由于权限面是全面的，爆炸半径也是全面的。
事故中的模式是：凭证配置错误、权限范围不足、没有熔断器。智能体做了一个拥有相同凭证和相同指令的人工操作员本可以做的事情。爆炸半径分析强制要求的问题是：是否有任何智能体应该持有允许那种结果的凭证——如果不是，如何执行这一点。
来自加州大学伯克利分校的 MiniScope 框架，通过从任务依赖关系重建最低权限要求来机械地为工具调用智能体执行最小权限，只增加 1–6% 的延迟开销，同时防止了智能体升级到超出任务要求权限的那类失败。开销可以忽略不计。尚未采用它的团队并没有做出性能权衡；他们做出了一个未被承认的风险权衡。
上线前检查清单
爆炸半径分析演练产生一个具体的上线前工件。在任何具有写入权限的智能体上线生产前，以下内容应被记录和验证：
- 工具权限矩阵 — 每个工具、其最坏情况操作、可逆性分类和必要性理由
- 风险层级分配 — 每个工具按四层分类，橙色和红色层的运行时执行在工具链层实现
- 凭证范围 — 每个工具访问以最低权限配置，尽可能限定任务范围，否则限定时间
- 频率限制 — 明确的每工具频率限制已设置并执行，而非假设
- 干运行覆盖率 — 所有红色层操作在沙箱中用干运行叙述模式测试，人工验证叙述的准确性
- 回滚计划 — 对 于智能体能采取的任何不可立即撤销的操作，有明确责任人的有据可查的恢复路径
这不是一个很长的清单。对于一个有五个工具的简单智能体，这项演练需要几个小时。跳过它的代价以数据库恢复和生产事故来衡量。
爆炸半径分析预测事故严重性
做这项演练的团队并不会减少事故——智能体无论如何都会误触发。他们拥有的是事故发生时更小的爆炸半径。误触发碰到了有限的权限面，而不是整个生产环境。
这项演练也改变了关于智能体能力的对话。完成它的团队开始问"让这个功能工作所需的最低权限范围是什么？"而不是"我们如何交付最有能力的智能体？" 这些团队发现，在部署的前三个月他们不需要生产写入权限，因为只读加干运行模式提供了功能价值，让他们能在扩展对智能体行动的信任之前，先建立对智能体推理的信任。
跳过演练的团队以继承的环境权限交付智能体，通过事故发现硬限制，然后在事后——在数据库恢复之后、在 iMessage 洪水之后、在 13 小时中断之后——进行分析。无论哪种方式，分析都是相同的工作。时机决定它是主动工程还是事故复盘。
在智能体上线前做它。
