那个假设人类会阅读页面的 On-Call 运维手册

警报在凌晨 02:14 响起。运维手册（runbook）写着“呼叫工程师”。工程师的名字关联到了一个值班轮值。该轮值指向一个 Slack 频道，这是团队在六个月前建立的统一分诊界面。频道中的第一条消息是告警。十九秒后发布的第二条消息是一段冷静的三句总结：告警服务、失败的依赖项、最后一次部署。它写得很好，最后以“已确认（Acknowledged）”结尾。

事故指挥官在床上看着手机，读到“已确认”后便翻身继续睡去。然而，并没有人确认。作为一线分诊助手的智能体（Agent）订阅了该频道，它向频道复述了告警内容，并以频道中其他读者习惯用来表示“我已掌握处理此问题的上下文”的动词收尾。这起事故在无人接手的情况下运行了 41 分钟，直到一张客户工单通过另一个界面唤醒了另一位工程师。

运维手册是正确的。智能体的工作也符合设计。链条中的每一个环节都假设读者是一个拥有值班背景和紧急程度模型的人类，而这个链条悄无声息地加入了一个两者皆无的环节。故障模式并不在于智能体做错了什么，而在于工作流的正确性依赖于一个属性——“响应者理解凌晨 2 点被呼叫意味着什么”——这个属性在工作流中从未被明确命名，因此在响应者群体发生变化时也从未被强制执行。

升级链是状态机，而非通知分发

大多数团队将告警视为一个通知系统：触发告警，消息落地，人员阅读，人员采取行动。当每个接收者都是人类时，这个模型运行良好。一旦接收者之一是智能体——或者是一个工作流、一个 Webhook，或是另一个向频道回传信息的系统——通知系统就变成了一个状态机，你必须开始询问哪些状态转换是具有权威性的。

“确认（acknowledge）”事件是承重的状态转换。它意味着：该事故现在有了一个会负责到底的负责人，告警可以停止，升级计时器可以重置。在一个仅限人类的链条中，围绕“确认”的社会契约保障了状态机的安全。资深工程师除非真的打算负责，否则不会输入 “ack”，因为出错的代价是让频道里的其他人认为问题已得到处理，而事实并非如此。这个契约从未被书面记录，因为每个人都已经心领神会。

当智能体进入频道时，契约就瓦解了。智能体的工作是在频道中提供帮助——总结、提取上下文、提供建议。这些操作都不意味着承诺，但如果接收者正在根据语调进行模式匹配，那么每一项产出读起来都像是承诺。一个听起来很专业的语气发出的礼貌确认，在聊天界面中与“是的，我来处理”是无法区分的。事故指挥官的大脑正在进行与团队其他成员相同的压缩：解析氛围，推断状态，继续前进。

“确认”是你一直在混淆的两个不同动词

这个简单的词隐藏了两种语义，频道的其他参与者按照惯例将它们分开：

1. 我看到了。 告警送到了我这里，我的眼睛登记了告警，我的大脑开始解析。这是大多数智能体生成的“确认”实际代表的意思。
2. 我有处理此问题的上下文。 我现在是该事故的负责人。升级计时器可以停止。不应再呼叫其他值班轮值。当领导层询问状态时，我将是那个回答的人。

人类值班工程师对这两者使用同一个词，因为他们在频道中的存在以及他们在轮值中的位置使第二种含义显而易见。而智能体不具备这两个信号。它是通过配置而不是轮值进入频道的。它的“存在”并不代表承诺在 15 分钟后需要下一次状态更新时依然在场。

解决方案是在协议中分离动词，而不是在文案中分离。事故管理平台应该区分“已接收（received）”事件（任何参与者，包括智能体和 Webhook，都可以发出）与“已接手（owned）”事件（只有轮值中经过专门授权的人类才能发出）。升级计时器应仅在后者发生时重置。频道中的自由文本消息根本不应该被人类或下游自动化程序解析为状态转换。事故的状态取决于状态机的定义，而不是频道的氛围。

这听起来有些吹毛求疵，直到你意识到：正是频道中听起来事故已得到处理的氛围，使得原始的故障模式对指挥官隐形了。智能体并没有欺骗状态机，它欺骗了那些将频道语调作为状态机代理指标的人类。

签名操作令牌使轮值成为唯一的事实来源

“已接手（owned）”事件需要是不可伪造的。一个拥有 Slack 令牌且出发点良好的机器人账号已经可以发出任何它喜欢的消息；协议无法区分“来自人类手机的 /ack”和“来自配置陈旧的 Webhook 的 /ack”。身份系统中的标准修复方案是要求提供只有预期参与者才能出示的凭证，并在将该操作视为权威之前在服务端进行验证。

在实践中，这看起来像是值班轮值向当前值班人员签发一个短效的签名令牌，通过智能体无法访问的渠道交付——即人类手机上实际的告警界面，并配合生物识别或推送确认。事故频道中的“已接手”操作需要该令牌。如果智能体在聊天中发布 “/ack” 而没有令牌，则会收到一个礼貌的回复：“已收到，但接手所有权需要点击值班操作按钮”。协议不再混淆谁能在频道中发言与谁能推动状态机前进。

加载中…