你的 AI 产品在需要另一个模型之前，更需要一名 SRE

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

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

“交付更好的提示词”循环是对生产环境的信任盲跳

AI 产品团队往往围绕生成表层进行组织：提示词、评估、检索质量、工具架构。这些工作是合理的，但这些工作也让每一次生产事故都显得像是头一遭。上周四的一个提示词更改，突然变成了周一延迟退化的首要解释。没有人确定，因为没有人记录。没有人记录，是因为修改提示词的团队不是负责事故响应的团队，甚至根本没有事故响应团队。

在大规模 LLMOps 调查中，最一致的发现之一是：提示词漂移（即未受监控的小微编辑累积）是生产退化最常见的单一来源，其影响甚至超过了模型故障和基础设施问题。这纯粹是一个运营上的失败。提示词本身不是问题。问题在于提示词被当作代码对待，却没有遵守代码的纪律：没有评审、没有回滚、没有变更日志、没有与遥测系统挂钩。传统的软件团队会认为这是一个明显的系统缺失。而 AI 团队通常将其视为一种特性：“我们可以快速迭代”。

他们可以快速迭代，直到出事为止。当第一个客户投诉一个没人能复现的行为时，团队会发现他们无法将提示词编辑、部署和面向用户的退化关联起来。每一次事故都变成了一场长达数小时的考古挖掘。

SRE 究竟能带来哪些模型无法提供的东西

SRE 并不是换了个头衔的 DevOps 工程师。这个角色的存在专门是为了将可靠性视为一种产品属性，而不是个体工程师勤勉工作的副作用。随之而来的实践——SLO、错误预算、无责复盘、运行手册规范、警报卫生——是一套 AI 团队几乎永远不会自发发明出来的工具箱，因为在周二早晨，交付新功能的冲动总是能赢得争论。

考虑一下当一名 SRE 进入 AI 组织后会发生什么变化：

• 可靠性变得可衡量。 “智能体感觉挂了”变成了“补全接口的 p99 延迟在 14:02 突破了 8 秒的 SLO，且检索服务的错误率有所上升”。第二句话是可操作的。第一句话只能开启一场集体诉苦会。
• 事故留下痕迹。 包含复盘的真实事故时间线记录了发生了什么变化、谁注意到的、耗时多久以及故障类别。在发生十二次此类事故后，会出现任何个体工程师都无法察觉的模式。
• 警报有了意义。 最近的一项行业研究发现，去年 44% 的组织发生的停机故障与警报被抑制或忽略直接相关。在 AI 团队中，这一比例几乎肯定更高，因为非确定性系统的基准信噪比本来就很差。SRE 到岗的前三个月通常是一场针对警报噪音的静默战争。
• 运行手册真正存在。 不是那些自第二季度以来就没人读过的、贴着“运行手册”标签的 Wiki 页面。而是真正的运行手册：提示词更改回滚流程、回退模型激活路径、检索索引重建脚本，并记录了负责人和预期结果。

这都不需要机器学习方面的专业知识。它需要的是一个以可靠性为职能的人，而不是一个职能是开发功能、而可靠性只是偶尔被记起的人。

你已经跨越“小团队可以靠即兴发挥”界线的领先指标

在每个初创公司都有这样一个阶段，五人团队可以把整个系统记在脑子里，即兴处理事故响应也没问题。有趣的问题是，这个阶段什么时候结束。对于 AI 产品来说，结束的时间比大多数团队意识到的要早，因为非确定性导致的故障面扩张速度超过了团队的增长速度。

注意这些信号：

• 事故量在上升，但检测时间（time-to-detect）没有改善。 如果你的响应速度变快了，但事故发生的频率却更高了，说明你只是更擅长“灭火”，而不是更擅长“防火”。SRE 会将精力从前者转移到后者。
• 不相关的事故中重复出现相同的复盘主题。 “由于没人盯着那个仪表盘，我们四十分钟都没发现。”“回滚花了两个小时，因为部署流水线不支持部分撤销。”“没人知道那是谁的警报。”当三个不同的复盘中出现相同的根本原因时，它们就是系统级的缺口，而不是个人的失误。
• 值班是非正式的，且集中在一两个“英雄”身上。 你有一个 Slack 频道，出事时大家在里面发帖，然后两个资深工程师承担了 80% 的工作，因为他们刚好最了解系统。这既是可靠性风险，也是人才流失风险。英雄会倦怠，然后你就彻底没人值班了。
• 工程师通过私信协商提示词编辑。 当核心提示词的变更管理流程只是“私聊 Sarah，看她是否有时间看一眼”时，你根本没有变更管理流程。
• 客户比你的遥测系统更早告诉你发生了退化。 这是最明确的信号。用户可观察到的故障与内部检测之间的差距，正是 SRE 存在的意义，即缩小这一差距。

其中任何一个信号都是可以生存的。但三个或更多信号同时出现，意味着非正式的运营模式已经走到了尽头，并且正在悄无声息地给业务带来比任何人的追踪还要高的代价。

为什么再招一名应用科学家通常是最常见的错误举动

当告警在凌晨 3 点响起时，AI 团队的直觉几乎从不是“我们需要一名 SRE”。而是“我们需要改进模型，这样就不会出错了”。于是，下一名新员工又是另一位应用科学家。

这通常是错误的举动，原因有三。

首先，应用科学家的成本很高，而他们投入在可靠性维度的工作比例却很低。他们接受的训练是提高评估分数，而不是设计值班流程。你最终会为一个根据训练和偏好将大部分时间花在无法减少生产环境痛苦的事情上的人，支付前沿模型级别的薪酬。

其次，在一个运维基础薄弱的团队中增加建模能力，会导致更多功能运行在同样破碎的基础设施上。故障率不降反升，因为增加了更多的故障暴露面。六个月后，团队仍处于原地，且背负了更多债务。

第三——这也是创始人最难听进去的一点——“我们需要模型专业知识”这种说法往往是逃避不那么光鲜的真相的一种方式：团队面临可靠性问题并不是因为模型不够好，而是因为没有人的职责是负责可靠性。模型成了组织缺口的替罪羊。

反对意见通常是“我们没有预算聘请全职 SRE”。这很公平，但实际的问题是：你目前在故障响应、客户信任和工程士气上支付了多少代价？边际资金是花在第五个应用科学家身上更好，还是花在第一个 SRE 身上更好？对于大多数已经度过原型阶段的团队来说，SRE 是更好的投资。

转型框架：嵌入式 SRE vs. 运维方向的机器学习工程师培养

一旦团队决定认真对待可靠性，有两条合理的路径，而正确的选择取决于团队规模和增长轨迹。

早期嵌入 SRE（8–20 人的团队）。 雇佣一名全职 SRE 并将他们嵌入 AI 工程团队，而不是放在一个独立的可靠性部门。他们头 90 天的任务是：为三个最受用户关注的指标建立 SLO；通过工具化手段缩短从提示词（prompt）修改到部署之间的间隙；用真正的故障管理工具取代“#incidents”频道；并与负责相关系统的工程师一起编写前三份 runbook。到第 180 天时，他们会按计划主持事后复盘（postmortem），团队的值班轮换也有了正式的交接流程。

培养机器学习工程师的运维规范（3–8 人的团队）。 在这个规模下，聘请专职 SRE 很难证明其合理性。相反，指定一名机器学习工程师作为该季度的运维负责人——不是永久性的，但要足够长，以建立上述实践的最小可行版本。如果可以从公司的其他部门借调时间，让他们去与具有 SRE 文化的团队共事。将产出——SLO、runbook、故障处理流程——视为他们的正式交付成果，而非副业。

这两种情况的失败模式是一样的：将运维视为志愿服务。SRE 实践需要数年的积累。如果一个团队中没有人的绩效评估提到这些，这些实践就无法存续。

模型不再是瓶颈

几年前，底层模型的质量是大多数 AI 产品的核心约束。但现在往往不是了。对于度过原型阶段的团队来说，核心约束在于他们能否在生产负载下运行非确定性系统，而不至于让整个组织每周都焦头烂额。这是一个已解决的问题，但解决方案并不在模型目录中。它存在于一套比当前 AI 浪潮早二十年的实践中，而懂得如何建立这些实践的人正坐在传统基础设施部门里，眼睁睁看着 AI 团队在凌晨 2 点互相传呼。

真正改变轨迹的举动不是下一次模型升级。而是那个将你的生产系统视为它本该是的生产系统的雇员。