智能体在凌晨 3 点呼叫我：触达人类工具的爆炸半径策略

当一个智能体因为循环处理一个格式错误的告警信号，在一小时内给你的值班人员发了四次传呼时，领导层终于意识到安全团队早已知晓的一件事：“工具访问权限”与“创造人工任务的能力”其实是同一种权限，而你在没有进行安全审查或产品归属权审查的情况下就授予了它。没有人关注“谁被允许在凌晨 3 点打扰人类”这个问题，因为根本没人把它当作一个问题。它被描述为一个 Slack 集成。

2026 年的智能体技术栈让这种故障模式的发生门槛变得极低。Anthropic 的 MCP 服务器、OpenAI 的 Agents SDK，以及各种厂商提供的操作工具，极大地缩短了“模型决定做某事”与“人类被吵醒”之间的距离。大多数团队部署这些集成的方式与部署数据库客户端如出一辙：定义一个 Token 作用域，引入 SDK，写一段系统提示词，然后发布。数据库客户端的爆炸半径是受影响的行数。PagerDuty 客户端的爆炸半径则是一个人的睡眠。

无人审计的权限

看看一个面向人类的工具实际上是如何安装的。工程师接入了 PagerDuty MCP 服务器，给智能体一个具有 incidents:create 权限的服务 Token，并在预发环境的故障上进行了测试。测试成功。发布。

审查的内容包括：OAuth 范围、API 契约，或许还有 PagerDuty 端的限流设置。未被审查的内容包括：在什么条件下智能体应该决定调用该工具，调用后的后果由谁承担，允许调用的频率，以及什么样的情况属于“智能体永远不该自主执行的操作”。集成清单上没有这些问题，因为它们不适合放在清单里。它们是披着基础设施配置外衣的产品归属权问题。

如今大多数智能体框架对工具只有两种模式：可用或不可用。在“模型拥有完全自主调用权限”与“模型完全看不见”之间没有中间地带。这种二元论对于 SQL 只读从库来说没问题。但对于下游影响对象是人类的工具来说，这完全搞错了方向。

当你按人为代价列出权限授予时，这种不对称性就显而易见了。读取 S3 存储桶：零代价。写入数据库行：代价低，且可逆。在 #general 频道发帖：消耗数百人/秒的注意力。传呼值班人员：一个人醒了。在 JIRA 提交任务：某人的积压工作增加了。给客户发邮件：客户关系发生了变动。集成 Token 将它们视为等同。但组织架构图并不这么认为。

当“爆炸”影响到人时，什么是“爆炸半径”

基础设施人员思考爆炸半径已经十年了——衡量单位是“我的系统坏了多少”。账户隔离、区域分区、熔断开关、百分比滚动发布。这个概念可以清晰地映射到计算和存储上，因为受影响的对象是可替代且可重建的。

面向人类的工具打破了这个模型。单位不再是容器或数据行，而是人的注意力。人是不可替代的。凌晨 3 点的传呼对值班人员造成的代价远高于下午 2 点的 Slack 消息，而一次误报对告警系统信任度的侵蚀，需要数周才能重建。“我们把你吵醒了，结果没事”这种事是没有回滚操作的。

因此，对于触达人类的工具，你需要追踪的维度与基础设施完全不同：

• 触达范围 (Reach)：多少人，以及哪些人（是一个值班人员还是拥有 400 人的 #general 频道）
• 打扰等级 (Interruption tier)：被动（频道发布）、主动（私信）、紧急（传呼）
• 可逆性 (Reversibility)：副作用能否撤销，或者人类是否已经切换了上下文
• 累积压力 (Cumulative pressure)：本次操作加上智能体之前对同一个人采取的最近六次操作
• 信任代价 (Trust cost)：这类智能体操作的误报率，而非智能体的整体误报率

累积压力是团队最容易忽视的一点。单个智能体操作孤立来看似乎是合理的。但针对同一个人、在同一个小时内连续执行三次智能体操作，看起来就像是骚扰——即使每一次操作在个体层面都是正确的。策略层必须将接收者视为一个有状态的资源进行追踪，而不是将操作视为无状态的事件。

递归传呼机：三个值得点名的故障模式

过去一年的复盘显示了三种重复出现的故障模式。它们都与模型质量无关，而是因为在“模型生成工具调用”与“联系人类”之间缺乏控制平面。

放大的误报。 一个上游告警因为某个不稳定的集成而触发。智能体被设置为调查、总结并通知。它的总结以 P1 级别的 Slack 消息形式发送到故障频道。订阅该频道的三个下游智能体都将该总结视为真实信号，并各自通知了自己的负责人。一个告警变成了十七个，噪音掩盖了真正的问题。

递归传呼。 智能体因为某个工具性能下降而传呼值班人员。值班人员的响应（或未响应）本身就是智能体观察的一个指标。在“未确认”五分钟后，智能体再次传呼——只不过这次它顺便传呼了值班人员的经理。二十分钟后，它传呼了一小截组织架构图，而这些人中没有一个能修复最初那个下游 API 的瞬时波动。

错误频道的爆炸。 智能体的 slack_post 工具权限范围被设定为“机器人所在的所有频道”，因为这是最简单的默认设置。一个格式化 Bug 导致它将调试追踪信息发到了 #all-engineering 而不是预想的开发频道。帖子加粗显示了三次“ERROR”。四百名工程师在它被删除前看到了它。对智能体输出的信任度打击是永久性的，这种损失是单次安静的 Bug 修复无法弥补的。

它们的共同点是：在每种情况下，智能体都执行了技术上允许它做的事情，但结果还是错了，因为策略没有模拟人为代价。

位于工具边界的策略层

修复方案不是“让模型更聪明地判断何时进行呼叫”。模型并不是执行配额的合适场所，“模型应该懂事”这种说法在事后回顾中并不能作为可用性理由。修复方案是在智能体与任何触达人类的工具之间建立一个策略层，由运行时而非提示词强制执行。

加载中…