你用智能体替换的内部搜索框刚刚成为了你的 SLO

你停用了公司门户上的搜索栏，因为智能体（Agent）表现得更好。以简单的英语输入问题，获得带引用的回答，通过追问进行优化。试点项目的满意度指标爆表。上线邮件写道：“弃用旧版搜索，两周内全量切换。”两周过去了。旧索引被停用。查询框被聊天输入框取代。

六个月后，在某个周二的早晨，三件事同时发生。由于某人的批处理作业耗尽了共享配额，你的推理服务商对公司账号进行了限流。向量嵌入（Embedding）服务出现了区域性局部故障。一次配置推送清空了 Prompt 缓存。公司里每一位习惯在搜索栏输入“VPN 设置”或“报销政策”的工程师，现在都盯着加载动画转了 40 秒，然后收到一条无法理解其问题的拒绝信息，或者更糟——一条指向不存在的 Wiki 页面的言之凿凿的引用。员工互助的 Slack 频道消息炸了。IT 部门的收件箱里塞满了“搜索是不是坏了？”

你取代的搜索栏在过去 10 年的微小改进中保持了三个九（99.9%）的可用性。取而代之的智能体有着完全不同的故障形态——是变慢而非宕机，是出错而非空白，是昂贵而非缓存——而你的 SRE 文化尚未针对此进行校准。

前任产品的 SLO 随用户一同迁移

当你停用一个功能时，并不会随之停用它所设定的用户预期。一个 10 年来都能在 200 毫秒内返回结果的搜索栏，带来的不仅是速度；它还教会了每一位员工在公司内部“搜索”应该是什么感觉。他们脑海中的模型——输入、看到结果、继续工作——并不会收到一份更新说明。它在全量切换后作为一种默许的预期存活下来，即替代品至少要同样出色。

在那些无人衡量的维度上，替代品并不比原来好。试点项目是根据满意度评分的。在受控的试点中，推理服务商运行良好且向量嵌入缓存充足，满意度看起来非常棒。而旧搜索是根据可用性和延迟评分的，这些十年前制定的 SLO 存在于没人翻阅的运行手册（runbook）中，因为从来没出过错。新智能体还没有对应的运行手册，因为还没有发生过 SRE 认知中的那种“故障”。

这就是继承权问题。用户的预期就是契约，而用户并不关心替代品在技术上是否属于不同的系统。他们在框里输入了一个问题，而框没有回答。这与旧搜索宕机是同一种故障，尽管底层原因是由于第三方 API 的限流，而你的 SRE 团队根本没有权限去修复它。

一个务实的做法是，每当用智能体取代确定性功能时，都要进行显式的 SLO 承接评审。逐行核对前任产品的 SLI/SLO 表，并针对每一项做出决定：智能体是否满足它，能否让智能体满足它，或者我们是否向用户发布不同的承诺？第三种选择是诚实的。而默认选项——在不重新协商的情况下默默继承契约——则是会反噬你的那个。

故障模式在你的运行手册中无处安放

传统搜索的故障分类很简单。索引是在线还是离线。查询时间过长还是结果太少。爬虫漏掉了一个页面。每一行都有对应的告警策略、仪表盘和负责人。

智能体的故障形态无法映射到这些分类。响应可能很慢，因为模型超载了——它没宕机，只是退化到了 40 秒的长尾延迟，超出了用户的耐心。响应可能是错误的，因为检索（Retrieval）找到了正确的文档，但生成器（Generator）把某个条款转述反了。响应可能很昂贵，因为用户提了一个追问，导致上下文激增，在没人察觉的情况下单次查询成本翻了 10 倍，直到月度账单寄到。响应可能被拒绝，因为安全分类器将一个关于劳动法的无害问题打上了标签。响应可能是一个幻觉引用，指向去年已删除且仅存在于团队忘记重新索引的向量数据库中的 Wiki 页面。

在 SRE 团队从搜索工程师那里继承的运行手册中，没有一行能对应这些情况。分类不同，告警不同，缓解措施也不同。旧搜索的 P99 延迟激增意味着索引需要更多副本。智能体的 P99 延迟激增则可能意味着供应商正在对你限流，或者是由于有人增加了系统指令导致 Prompt 变长，又或者是模型滚动到了在长上下文处理上更慢的新版本。适用于旧形态的仪表盘看不见这些新形态。

要做的工作不仅仅是建立一个新的仪表盘。它需要一套新的分类学，而且必须有人来编写它。收集智能体在生产环境前 30 天的实际故障观察，对它们进行聚类、命名，并为每个类别设定默认响应——如果可能的话进行自动缓解，否则制定告警策略。没有这套分类学，你的值班轮换就是在处理类别尚不存在的事件，这与没有值班室并无二致。

迁移计划遗忘的回退方案

替换的正确形式不是“关掉旧系统，开启新系统”，而是“开启新系统，同时将旧系统降级为用户平时看不见、但在需要时可用的回退（fallback）路径”。做得出色的团队会让前代系统保持“热备”的时间比迁移计划要求的更长。他们会将智能体（agent）的置信度、延迟和成本接入路由层，当其中任何一项超过阈值时，该层就会悄无声息地切换到之前的搜索索引。

这种工作大多由三个原语承担：每个身份一个令牌桶，以防止单个用户或后台作业耗尽共享的推理配额；每个故障模式一个断路器，当智能体的错误率或长尾延迟超过预算时跳转到回退路径；以及一个声明式的回退链，按照“主模型 -> 更便宜的模型 -> 语义缓存 -> 遗留索引”的顺序进行路由。这些原语都不稀奇，在任何依赖外部 API 的生产系统中都是标准配置。如果一个团队在交付智能体时不具备这些功能，那么他们的运作方式就好像推理提供商的状态页就是他们的 SRE 一样。

回退到前代系统是一个不寻常的举动。它需要持续的维护成本——旧索引必须保持更新，路由层必须经过测试，仪表盘必须展示两条路径。但这一举动也意味着，供应商的宕机对大多数用户来说是无感的，而不是变成一场全公司范围的 IT 事故。账很好算：让前代系统保持一年待命状态的成本，远低于一次半天宕机导致的损失，毕竟那时 CEO 会发邮件质问为什么大家什么都查不到。

如果让前代系统保持热备确实不可行——比如旧基础设施已退役、合同到期、了解操作的团队已离职——那至少也要构建一个存根（stub）回退。在相同的语料库上建立一个扁平的关键词索引，通过静态端点提供服务，返回十个结果并显示一个横幅，写着“高级搜索暂时不可用”。衡量标准应该是“用户在推理系统宕机期间仍能找到 VPN 设置页面”，而不是“降级模式下的功能平替”。

容量规划有了新的乘数

旧的搜索系统每天为每位员工提供服务，单位成本低于一美分，因为索引是自有的，且计算成本在十年的优化中已经摊销。而智能体为同样的用户提供服务，每条查询的单位成本从几美分到几美元不等，且面对的是一个供应商，其配额是为你的试点项目（pilot）而设定的，而非全量上线。

如果迁移提案中没有包含数学计算——即前代系统的每秒查询量（QPS）乘以智能体的每条查询成本，再乘以对话式界面带来的后续轮次乘数——那么团队就是在让领导层接受一份随着采用率增长而不断膨胀的账单。这通常在财务会议上首次浮出水面，有人会问为什么 AI 支出项环比增长了 8x，而得到的回答是“全量上线完成了”。

诚实的容量规划始于前代系统的流量画像，而非试点项目。抽样一周的旧搜索日志。预估对话扩展（用户在有机会时会问后续问题——预计每个任务的轮次至少会有 2x 的放大）。乘以当前供应商价格下的每轮成本。加上缓存失效、重试以及随着产品迭代而不可避免的系统提示词（system prompt）增长所带来的缓冲区。得出的数字就是你需要与推理提供商签订的合同——不是试点配额，也不是友好的初始套餐，而是一个承诺吞吐量协议，以保证在周二早上平台上有其他人也在疯狂消耗配额时，你的系统依然稳健。

同样的数学逻辑也驱动着回退决策。如果智能体与遗留索引之间的单次查询成本差异达到两个数量级，路由层就应该倾向于从更便宜的路径提供简短、常见的查询服务。“vpn setup”不需要生成式回答，用户只想要那个页面。智能体是长尾问题的正确答案，而非头部高频查询的答案。

组织鸿沟是真正的故障面

产品团队负责迁移指标。SRE 团队负责 SLO。两者之间的鸿沟就是智能体的故障画像，而这两个团队都没有为此做预算。

情况往往是这样恶化的：产品团队运行试点项目，衡量满意度，宣布成功，推动切换。SRE 没有参与试点评估，因为试点项目没有触发过告警（page）。当第一起事故发生时，SRE 被叫去处理一个他们从未见过依赖图谱、故障模式不在其值班培训中、且供应商关系由他们几乎不认识的采购团队维护的服务。事故后的复盘将“提高智能体可靠性”列为一个没有负责人且耗时六个月的行动项。

解决方法是流程性的，而非技术性的。在退役旧功能并将面向用户的可靠性移交给新系统之前，负责新系统的团队必须签署一个“弃用对等里程碑（deprecation parity milestone）”——预先以书面形式达成一致——即在旧系统撤除前的指定窗口期内，替代方案在可用性、延迟、拒绝率和单位成本方面必须达到或超过前代系统的水平。SRE 签字，产品签字，财务签字。这些签名是一个强制函数，将迁移从一个满意度项目转化为一个可靠性项目。

窗口期很重要。在平稳发布期间进行的为期两周的对等检查，无法捕捉到供应商的每月维护窗口、季度索引漂移或季节性流量高峰。对于依赖项不受你控制的任何系统，九十天是底线。六个月更好。让前代系统并行运行两个额外季度的成本，与公司会记住数年的糟糕切换成本相比，微不足道。

Agent 并不只是增加功能——它们是在替换系统

这种架构层面的认知既简单又令人不安：一个替换了确定性功能的 Agent 并不是一个强加在公司技术栈上的新功能。它是一个继任系统，而无论团队是否重新谈判，继任系统都会继承原有的契约（Contract）。

这重塑了许多决策的维度。试点项目（Pilot）并不是尽职调查的终点，而是起点。成功的衡量标准不是满意度，而是原系统所承担的所有评估指标的并集。运维手册（Runbook）不再是旧的那本，而是必须针对 Agent 实际的失效模式（Failure Modes）从零开始编写。与供应商的关系不再仅仅是采购细节，它是决定你面向用户的可用性（Availability）的核心因素。降级方案（Fallback Path）不是未来的优化点，而是上线的先决条件。

内化了这些理念的团队所交付的 Agent，能够挺过第一个故障频发的“黑色星期二”。而没能做到这些的团队，他们交付的 Agent 只会换来一份事故报告（Postmortem）、一场财务审计会议，以及一位再也不敢完全信任下一次 AI 部署的高管。两者之间的差距并不在于模型质量，而在于是否有人在旧系统退役之前，写下了新系统必须履行的契约——并真正确保新系统履行了它。