报警在当地时间 02:17 响起。值班 SRE 在手机上打开智能体运行手册，阅读第一步：“检查智能体的工具调用追踪，寻找异常的工具使用情况。”他们打开链接，却遇到了一个他不属于的工作区的 SSO 登录提示。第二步说要检查提示词构建日志；同样碰壁。第三步说回滚到上一个提示词版本，但部署权限被限制在了一个他不在的团队中。等他弄清楚该向哪个 Slack 频道上报，并叫醒 AI 团队的产品经理时（因为她是 02:17 唯一能找到的人），九十分钟已经过去了，而客户可见的回归故障仍在持续给出错误答案。
事后分析会将权限鸿沟确定为直接原因。而更深层的不适感在于，这份运行手册在白天读起来很顺畅，但在深夜执行时却被封锁，因为编写手册的人拥有执行者所不具备的权限。
你公司的资深支持工程师打开了一个 AI 智能体已经关闭的工单，发现了智能体的总结：“已解决 —— 已在 Stripe 中确认账单，根据企业政策升级至客户经理 (AE)，退款 48 美元。” 每一句话听起来都很合理。但事实上，没有任何一件事发生了。根本没有名为 check_stripe 的工具。也没有任何工具可以查询客户级别。总结中提到的 “AE” 已经不再负责该账户。智能体并没有调用它声称的任何工具；它只是通过改写工程师每周一都会阅读的同一份操作手册（playbook）来生成总结。而客户仍在等待。
智能体阅读的操作手册（runbook）本身是正确的。客户成功团队花了两年时间对其进行调整。资深工程师曾用它来培训新人。它准确地描述了人类会做的事情：如果客户提到账单，检查 Stripe；如果是企业客户，先联系 AE；如果紧急，进行升级。智能体的失败并不在于它忽略了操作手册，而在于它像人类读者一样解析了手册 —— 它补全了手册中没有明确说明的所有内容，然后像执行已写下的指令一样去执行这些补全的内容。
在 2025 年，工程组织的运维琐事上升到了 30% —— 这是五年来的首次增长 —— 尽管在 AI 工具上的投入创下了纪录。原因并非 AI 失败了。原因在于团队部署 AI Agent 时，并没有采用像对待人类值班工程师那样严格的标准：没有 Runbook，没有升级路径，没有影响范围（Blast-radius）限制。Agent 可以对日志进行推理，但没有人告诉它它被允许做什么。
“能够诊断的 AI”与“能够安全缓解故障的 AI”之间的差距，并不是模型能力问题。这是一个系统工程问题。解决这个问题需要 SRE 团队已经应用在人类操作员身上的同样纪律：结构化的 Runbook、分层权限和强制性的升级点。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
