发布前的爆炸半径清单：你的智能体团队遗漏编写的文档

Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。

这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。

清单中包含什么

爆炸半径清单为每个工具分配一行，每一行的内容都要假设该工具最糟糕的情况已经发生。这些列不是可选的，也不是愿景性的——在注册工具之前，每个单元格都必须填入真实信息，因为每个空单元格都会变成某人在凌晨 2 点提出的问题。

一个可行的初始架构：

• 工具名称及绑定 (Tool name and binding)：注册的工具名称、可以调用它的一个或多个 Agent，以及 planner 看到的函数或 schema。
• 下游系统 (Downstream system)：调用实际命中的外部系统。不是“CRM API”，而是 salesforce-prod.us-east。精确性至关重要，因为这是需要被呼叫 (paged) 的对象。
• 凭证 (Credential)：调用时出示的服务账户、OAuth 范围、API 密钥别名或签名身份。如果凭证与非 Agent 调用者共享，需明确标注。
• 最坏情况影响 (Worst-case effect)：如果提示词注入 (prompt injection) 成功劫持了该调用，它会产生什么后果。不是指正常路径，而是假设被攻陷的路径。“从 CEO 的邮箱向名单发送邮件”比“发送通知”更具体有效。
• 可逆性类别 (Reversibility class)：可逆（60 秒内）、费力可逆（一小时内手动回滚）或不可逆（资金已转移、消息已送达、密钥已轮换、在没有版本控制的系统中文件被覆盖）。
• 审计追踪位置 (Audit trail location)：动作记录存放的位置——SaaS 应用的审计日志、内部数据仓库表、CloudTrail bucket、Agent 自身的结构化事件流——以及保留窗口。
• 下游值班 (Downstream on-call)：当该工具的下游系统崩溃时，无论是否由 Agent 引起，哪个团队会被呼叫。
• 速率限制预算 (Rate-limit budget)：允许 Agent 消耗的下游配额比例，与其它内部调用者消耗的比例分开。
• 组合效应 (Composition effect)：当 planner 将此工具与目录中的另一个工具组合时产生的最坏情况。这是大多数团队会跳过、而大多数事后分析 (postmortems) 最终停留的一列。

组合效应列是将清单从工具列表转变为爆炸半径图的关键。一个 read_email 工具本身风险很低。一个 send_email 工具本身风险也很低。两者若与 fetch_url 工具结合，就构成了 Simon Willison 所说的致命三连——私有数据、不可信指令和外泄通道——Agent 的 planner 可以将这三者组合成其所有者从未同意过的效果。组合效应列迫使团队记录哪些组合已经过考虑，而哪些还没有。

诚实地填写最坏情况列

人们总倾向于写下调用在正常路径下的作用。“更新线索状态”、“向项目频道发布摘要”。这种记录是无用的，因为只有在调用执行了没人想要的操作时，人们才会去阅读这份清单。

正确的框架是假设提示词注入已成功，且 planner 现在处于敌对状态。然后问：凭借该工具持有的凭证、被授予的范围以及被给予的速率限制，在被阻止之前，它能做的最坏的事情是什么？答案很少是该工具设计的初衷。如果提示词被构造为迭代执行，一个拥有广泛写入权限的 update_lead_status 工具可以大规模更改 CRM 中的每一个线索。一个没有固定特定频道 ID 的 post_to_channel 工具可以发布到领导层频道。一个返回完整事件主体的 fetch_calendar 工具可以外泄包含未公开收购目标的会议记录。

2025-Q4 的数据在这一点上是明确的：针对企业 AI 系统的记录在案的提示词注入尝试同比增加了 340%，成功攻击增加了 190%。CVE-2025-53773 的披露显示，在拉取请求 (PR) 描述中的提示词注入通过编码 Agent 实现了远程代码执行，CVSS 评分为 9.6。在这些事故中幸存下来的团队对“最坏情况”问题有预先写好的答案。而没有幸存下来的团队则必须在事故发生现场现编答案。

一个有用的测试：如果工具的“最坏情况”列读起来与工具描述完全一致，那么该列就还没填好。描述告诉你工具应该做什么。最坏情况列则告诉你当工具不该被那样使用时，它能做什么。

将清单设为合并门禁，而非发布产物

最常见的失效模式是将清单视为一次性的发布产物。团队在发布前一周编写它，随后发布，而文档在一个季度内就会变得陈旧。下一次提示词注入事件发生时，响应团队可能会呼叫错误的值班人员，因为清单显示该工具在六周前就已停用。

解决方法是结构性的，而非流程性的。工具注册表（即智能体拥有的工具的代码级定义）和清单必须是同一个真理来源。新工具需要其清单条目才能合并。现有工具的范围变更要求在同一个 PR 中更新其清单条目。合并门禁在 CI 中强制执行，就像模式迁移（schema migrations）或新的公共端点已经实现的那样。该 PR 的审查者包括 AI 团队、安全团队以及工具调用的下游系统的值班团队。如果下游系统的值班团队不愿意签字批准，这表明“最坏情况”列不够准确，或者速率限制预算尚未协商达成。

这是企业级智能体治理中正在出现的“左移”姿态：清单不是某人在想起时才更新的活页夹。它是一个 CI 产物，源自实时工具定义并根据其进行验证，且跨团队审查已内置于 PR 模板中。微软在今年早些时候发布的 Agent Governance Toolkit 也持有同样的立场——唯一能保持正确的清单，是构建流水线在缺少它时拒绝合并的清单。

与结构性部分相伴而生的还有文化部分：清单是给不编写智能体的人看的。安全团队在事件处理期间阅读它。下游系统的值班人员阅读它以了解其依赖服务被要求执行的操作。依赖 SaaS 的容量规划人员阅读它来预测负载。审计人员将其作为哪些自动化效果需要核实的索引。如果清单只对编写它的团队有意义，那么编写它的团队就会因为其他人的困惑而不断被呼叫。

发布后的运营使用

清单在发布后的生命周期是价值复利的地方，但前提是你将其视为一份动态文档。其中有三种运营模式至关重要。

事件处理始于清单。 当智能体做出非预期行为时，第一个动作就是查找执行该操作的工具并阅读对应行。行中的值班人员姓名就是加入故障处理会议（bridge）的人。审计追踪位置是响应者提取取证数据的地方实。可逆性类别告诉会议成员应关注回滚还是损害控制。所有这些都不需要人去记忆哪个仪表盘属于哪个系统，因为清单行中已经写明了。

审计审查将其作为索引。 对智能体驱动行为的季度审查不会尝试从头开始列举——他们会逐项检查清单，确认每一行的审计追踪位置是否仍有保留期，每个凭据是否仍具有文档记录的范围，每个速率限制预算是否仍被遵守。清单的 last verified 列是本季度哪些行已重新验证的真理来源。

弃用审查随着上游系统的演进而检查清单的准确性。 当下游 SaaS 宣布其 API 发生破坏性变更时，清单会告诉你哪些工具依赖于它。当一个下游团队重组其值班轮换时，清单的下游值班（downstream-on-call）列会随之更新。当凭据轮换为更窄的范围时，最坏情况列会根据新范围重新评估。

组合列是从定期重新评估中获益最多的项。目录中每增加一个新工具，都会重新引发一个问题：哪些工具现在可以组合起来，产生任何单行条目都未曾警告过的效果。一个每季度都在增加工具却不重新审视组合列的团队，到第三季度时，其面临的攻击面将是清单中任何一行都无法描述的。

智能体是爆炸半径放大器

这一切背后的架构认知是：智能体将工具组合成任何单一工具所有者都无法预见的效果。工具所有者可以孤立地分析其工具并得出其安全的结论。但他们无法分析自己的工具加上规划器可以按任何顺序调用的另外四个工具，以及来自任意上游源的任意自然语言输入。组合正是爆炸半径所在，而组合是任何单一工具所有者都不负责的部分。

这一责任落在了智能体团队身上，而清单正是智能体团队履行该责任的方式。清单是组织中唯一一份考虑并命名了每种可能组合的最坏情况的文档。不编写清单的团队并没有逃避工作——他们只是将工作外包给了事后复盘。

如果你正在发布一个涉及两个以上外部系统的智能体，并且你还没有一份类似于此清单的文档，那么下一次事故将替你编写它，只是顺序是错的、面临着时间压力、且呼叫了错误的值班人员。这份文档最便宜的版本是在发布前编写的版本。此后的每一个版本都比前一个更加昂贵。