智能体在凌晨 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 修复无法弥补的。

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

位于工具边界的策略层

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

该层需要实现的五件事：

• 针对每个渠道的频率限制，在边界处强制执行。 智能体每小时在每个服务中获得 N 次呼叫，每天给每个接收者发送 M 条 Slack 私信，每周在每个项目中创建 K 个 JIRA 工单。这些是针对 工具 的配额，而不是针对模型的。当配额耗尽时，工具调用应返回结构化错误，智能体必须转向人类批准的升级路径或等待。智能体应该在上下文中看到频率限制的响应，以便据此制定计划，而不是无休止地重试。
• 针对任何产生通知的工具提供试运行（Dry-run）模式。 这是一个一类标识，允许智能体“起草”一个呼叫或 Slack 帖子并提交给人类审批，而不是直接发送。试运行也是智能体自身反思步骤的正确模式：它可以在提交之前检查渲染后的副作用。
• 对首例升级进行人机协同。 凡是智能体从未对该接收者执行过、或从未在这种严重级别下执行过的操作，都需要人类批准首个实例。系统通过少量的批准学习模式；在信任建立期间，人类参与其中，一旦模式变得枯燥重复，人类便可退出。
• 针对每个租户的影响范围配额。 智能体代表租户可以采取的人机交互动作的 总数 日上限——无论使用的是哪种工具。这是熔断机制，即使没有触及单个工具的渠道限制，也能捕捉到失控的循环。
• 将接收者视为有状态资源。 控制平面跟踪“智能体在过去 24 小时内对该人类执行的操作”，并将其作为下一个决策的输入。策略随后可以规定：在同一事件中，如果没有人类批准，不得向同一值班人员发送两次呼叫；或者不得给过去一周内屏蔽了机器人的接收者发送 Slack 私信。

窍门在于，所有这些都属于运行时，而非提示词。提示词是证据，而非强制手段。任何你要求模型“记住不要做”的事情，在上下文窗口变得有趣的那一刻，都会被遗忘。

谁来批准赋予智能体打扰人类的能力

这是没人想谈论的话题，因为答案改变了由谁买单。目前，赋予智能体 PagerDuty 权限往往是一个基础设施决策，是在 SRE 式的预算下做出的，由拥有 API 密钥的人批准集成。

但后果却由另一个团队承担。被呼叫的值班人员在产品团队。收到渠道错误邮件的客户是 GTM 团队维护的关系。JIRA 待办事项增加的工程师负责他们自己的路线图。在确定集成范围时，这些人都不在场。

将打扰人类的权利视为一种产品权限，而非基础设施权限。这意味着：

• 面对人类渠道的所有者（值班表、Slack 工作区、客户邮件域名）必须签署同意哪些智能体可以访问、频率和严重程度如何。
• 审批是基于层级的：被动 vs. 主动 vs. 紧急，每个层级有独立的预算。
• 存在文档化的权限撤销路径。当智能体的判断比预期的差时，所有者可以撤销权限，而不需要基础设施团队更新令牌。控制平面必须在几秒钟内支持这种撤销，而不是在每周一次的部署中。
• 审计追踪是人类可读的。“智能体 X 在 Z 时间呼叫了值班人员 Y，因为工具 Q 返回了 R”应该是受影响的人类可以查询的，而不是埋在只有平台团队才知道如何阅读的结构化日志仪表板中。

如果你不会在第一天就给一个新实习生 PagerDuty 的升级策略——你确实不会——那么在没有同样脚手架的情况下给智能体相同的权限，是一个更糟糕的决定。实习生至少还有一个能感知成本的主管。

设计离场机制

每个触达人类的工具从第一天起就需要内置离场机制。离场机制是当情况跨越策略阈值时，智能体用来替代联系人类的操作。常见形式：

• 一个待处理动作队列，人类可以在自己的时间进行分流，而不是同步呼叫。
• 一个“软”渠道——一个低关注度的场所，智能体可以在这里自由写入；以及一个需要独立预算的“硬”渠道。智能体学会默认使用软渠道。
• 渲染到 UI 中供人类发送的草稿消息，而不是直接发送。
• 延迟窗口。智能体的通知在 10 分钟内不会发出；如果智能体的后续操作能让该通知变得多余，则抑制原始通知。

离场机制使频率限制变得可恢复。没有它，达到配额意味着智能体静默地未能传达人类可能真正需要知道的信息。有了它，配额只是改变了渠道——从紧急到非紧急，从同步到异步，从“把你叫醒”到“出现在早上的队列中”。

在连接下一个工具之前要问的问题

在安装下一个 MCP 服务、集成或让你的智能体能够联系到人类的 webhook 之前，请审视以下五个问题。在你得到每个问题的答案之前，不要发布产品：

1. 这个工具可以联系哪些人？谁负责管理这些人的注意力预算？
2. 智能体可能发送的最糟糕的单条消息是什么？其爆炸半径有多大？
3. 智能体可能产生的最糟糕的一小时重复操作是什么？在什么情况下运行时环境（runtime）会在没有智能体配合的情况下介入？
4. 当智能体出错时，谁能在 60 秒内撤回权限？
5. 当政策规定不能执行此操作时，智能体会转而采取什么行动？

如果其中任何一个问题的答案是“到时候再看”，那么这种集成还没有准备好。原因并非源于理论风险，而是因为你将要编写的事后分析（postmortem）已经初具雏形，而且它将被呈交给一个并未主动选择出现在智能体分发列表中的人。

2026 年最重要的转变不是智能体变得更加强大，而是它们获得了触达能力（reach）。缺乏触达控制平面的能力，将是你的产品即将交付的下一类事故隐患。好消息是，控制平面大多是平凡的基础设施：速率限制（rate limits）、配额（quotas）、审批、审计追踪（audit trails）和退出机制（off-ramps）。难点在于承认“唤醒人类的权利”是一种权限，并指定专人负责授予这种权限。