32 篇博文 含有标签「sre」

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。

这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。

关于编程智能体（coding agents）的讨论总是陷入二元对立：自主还是受监督，YOLO 模式还是手握方向盘，--dangerously-skip-permissions 还是“批准每一次按键”。这种构想框架本身就是一个范畴错误。编程智能体执行的并非“一个动作”，而是一系列动作，其成本跨越了至少七个数量级 —— 从读取文件（免费、可撤销、无副作用）到合并至主分支（不通过 revert PR 则不可逆），再到向集群发布二进制文件（六位数成本级别的事故）。用一个自主性开关来处理如此广泛的范围，就像是为停车场和高速公路设置统一的限速一样。

如果团队在发布“无所不能的智能体”时，没有将每个动作映射到其爆炸半径（blast radius），那么只需一个带有提示词注入风险的 GitHub 评论，就足以引发一场事后复盘 —— 事实上，我们已经有了这种失败模式的公开案例。Anthropic 的 Claude Code 安全审查、Google 的 Gemini CLI Action 以及 GitHub Copilot Agent 在 2026 年都被证实可以通过精心设计的 PR 标题和 issue 正文被劫持，研究人员将这种攻击模式命名为“评论并控制”（Comment and Control）。这些智能体并非在抽象意义上损坏了，而是因为自主性层级悄无声息地将低信任输入抹平为“一视同仁”，从而基于这些输入执行了高阶动作（如推送代码、开启 PR）。

接下来需要建立的规范是：针对每个动作的曲线、随层级扩展的闸门、与爆炸等级匹配的回滚速度，以及一个测试工具组合升级而非单一动作失败的评估程序。

当 Agent 平台第一次崩溃时，事后分析报告（Postmortem）通常包含这样一句话：“周五我们还有八周的冗余容量。到了周一下午，我们已经达到了已配置容量的 140%。”没有人撒谎。容量模型本身是正确的，只是被应用到了一个它从未被设计用来应对的工作负载上。传统的容量规划假设需求沿着一条平滑曲线增长，周季节性是主导信号，最坏的情况是可以提前六个月规划的“黑色星期五”。Agent 工作负载彻底打破了这一假设。

Agent 需求的形态不是曲线，而是悬崖。有三件事造成了这种悬崖效应，并且它们会产生复合影响。一个企业级客户的入驻，就能根据你已经签署的合同通知，在通宵之间将基线移动 10 倍。一个 Agent 循环可以将微小的用户活动增长放大为扇出倍增的浪潮，对推理端的冲击比面向用户的图表显示的要高出 30 倍。单个产品变更——例如启用工具调用、延长上下文、切换到更大的模型——可以在用户数量不变的情况下，将单个任务的 Token 消耗提高一个数量级。

如果你的容量规划以 QPS 为单位，且你的冗余预算是“75% 的利用率是健康的”，那么你不是在规划。你是在赌这三个“悬崖”不会在同一个星期降临。

当你第一次用经典的 SRE 复盘（Postmortem）模板来分析 LLM 事故时，模板赢了，而事故输了。时间线、诱因、缓解措施、预防措施 —— 每个字段都填好了，每个复选框都勾选了，但在文档的最后，没人能回答唯一重要的问题：究竟是哪个变量发生了变动？不是部署事件。不是基础设施故障。不是代码变更。而是 Prompt 的修订、路由选择的模型切片、未触发报警的 Eval 评分所用的 Judge 配置、质量投诉发生时的检索索引状态、规划器（Planner）正在组合的工具 Schema 版本，或者是异常时间段内的流量组合。这些在模板里都没有对应的一行。

SRE 模板并不是为那些“事实来源是观察到的行为而非代码路径”的系统设计的。在 LLM 技术栈中默默变动的变量，正是模板从未需要列举的变量。强行借用模板，只会产生那种被归类为“持续调查中”的“我们不知道发生了什么变化”的复盘报告。

对人类来说，503 意味着一个“稍后再试”的页面和一段咖啡休息时间。对 Agent 来说，503 只是在七次重试中的第一次尝试前那 250 毫秒的挫折，而且规划器（planner）已经开始询问 LLM 是否有其他工具可以绕过这个失效的依赖项。第一种行为为过载的服务提供了恢复空间。第二种行为则是过载服务的噩梦：数以千计的关联重试，每一次都比人类的操作更廉价、更快速，其中一半还会扩散（fan out）到下一个依赖项，因为规划器认为那是一个富有创意的变通方案。

负载脱落（Load shedding）—— 即通过丢弃低优先级任务来维持高优先级路径可用的准则 —— 是在流量发送主体主要是键盘前的人类，或者是具有手动调优重试策略且行为良好的服务的时代设计的。当 Agent 集群出现时，这两个假设都会瞬间崩塌。Agent 重试速度更快，能同时从更多地方发起重试，绕过故障重新规划，并把你返回的 503 视为负载均衡的暗示，而不是你本意中希望达成的协作式背压（back-pressure）信号。

本文将探讨为什么标准的负载脱落策略在面对 Agent 客户端时会失效，上游服务需要什么样的原语才能真正卸载 Agent 流量，以及 Agent 本身在工具层和规划层必须做些什么，才能不再成为别人事故报告中的恶意流量。

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

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

我在陷入困境的 AI 团队中看到的最显著模式，是他们复杂的模型栈与原始的运营水平之间的差距。一个团队可能在生产环境中运行三个前沿模型，背后是自定义路由逻辑、包含八个检索阶段的 RAG 流水线，以及一个调用二十个工具的智能体。但与此同时，他们没有轮值制度、没有 SLO、没有运行手册，甚至只有一个 #incidents Slack 频道，在那里的提示词是由当时刚好醒着的某个人进行实时热修复。该产品运行在 2026 年的模型基础设施和 2012 年的运维基础设施之上，而这种差距每周都会导致另一次故障。

当问题出现时，本能反应是去拨动模型杠杆。质量下降了？试试新版本。延迟激增了？换个供应商。生产环境中出现幻觉？再加一个护栏提示词。这些都无法解决根本问题，即没有人将系统的可靠性作为一种专业规范来负责。这些团队真正需要的——通常在他们需要另一位应用科学家之前——是他们的第一位 SRE。

你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。

这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。

你的 LLM 功能开始返回胡言乱语。值班工程师呼叫 ML 团队。他们看了看输出，和提示词本应产生的结果对比了一下，不到一小时就关闭了工单："提示词有问题——已调整并重新部署。"事件关闭，事后复盘完成，行动项：改进提示词工程流程。

两周后，同类故障再次发生。不同的提示词，不同的功能——但是同样隐性的根因。

"修提示词"的反射动作，是 AI 工程领域版本的"甩锅给最后一个碰过这个文件的开发者"。它给事后复盘一个干净的结局，却无需任何人真正理解到底是什么出了问题。而与传统软件不同——那里这种反射动作只是懒散——在 AI 系统中，它在结构上是危险的：因为非确定性系统的失败方式，是提示词修改无法解决的。

凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。

这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。

标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。

你的 AI 功能处于 "up" 状态。延迟正常。错误率为 0.2%。仪表盘显示一片绿色。但在过去的两周里，摘要质量在悄然下降 —— 输出在技术上是连贯的，但事实深度变浅了，始终漏掉用户关心的关键细节。没有人提交 Bug。没有触发告警。直到下一次季度审查、留存数据出来时，你才会意识到这一点。

这是传统 SLO 无法察觉的故障模式。可用性和延迟衡量的是你的服务是否在响应 —— 而不是它是否响应得 好。对于确定性系统，这两者几乎是等价的。对于 LLM 功能，它们可能会在数周内无声无息地分道详镳。