AI 功能退役指南：如何在不破坏用户体验的情况下下线智能体

大多数团队会在最糟糕的时机发现同一个事实：下线一个 AI 功能与废弃一个 API 完全不同。你在文档中添加了停用日期，发送了常规的三封系列邮件，切换了标志位——然后眼睁睁地看着支持队列激增 80%，而用户则大声解释替代方案“运行方式不一样”。他们的意思是：旧智能体的怪癖、特定的故障模式、以及它独有的错误答案，都已经变成了业务中不可或缺的支撑。他们在那些直到消失才被察觉的行为基础上，构建了整个工作流。

这就是 AI 功能废弃的核心问题。确定性 API 具有明确的契约（contracts）。如果你移除一个端点，每个依赖它的调用者都会收到 404 错误。损坏是可追踪、有限且可预测的。概率性 AI 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。

为什么 AI 下线在结构上比 API 废弃更难

当你废弃一个 REST 端点时，用户清楚地知道什么坏了：调用失败。当你废弃一个 AI 功能时，破坏是弥散性的。一个在解析升级意图方面“足够好”的客服智能体，可能被支持代表们默默地补偿了——他们学会了重新表述工单，以引导它得出正确的结果。当你用更准确的东西替换它时，同样的代表突然看到了不同的路由——这并不是因为新模型更差，而是因为他们的适应策略不再适用。

这种动态在你的用户群中大规模上演。每个与你的 AI 功能接触超过几次的用户，无论是有意识还是无意识，都建立了一个关于其行为的心理模型——包括它的怪癖。停用该功能不仅是移除了一项能力，它还使这些心理模型失效。这就是为什么功能下线会产生不成比例的用户流失，远超同等的产品变更，以及为什么在过渡期间支持成本通常会激增 40-120%。

这对工程的启示是：一次成功的 AI 下线需要将行为发现（behavioral discovery）视为头等工程问题，而不是产品沟通问题。

第一步：在动手之前映射行为依赖

在写下任何废弃通知之前，你需要了解用户实际上在依赖什么。这需要你以不同于以往的方式检查日志。

显而易见的信号是使用量和频率——识别该功能的每日活跃用户与偶尔用户。日活用户拥有最高密度的隐式适应；他们已经将 AI 的行为集成到了肌肉记忆中。这些人将产生你 80% 的支持工单，他们值得个性化的迁移支持，而不仅仅是一个变更日志条目。

但使用频率是容易的部分。难点在于理解行为耦合：哪些工作流依赖于这个 AI 功能的特定输出？寻找以下内容：

• 工具调用序列：如果你的智能体调用下游工具（数据库查询、外部 API、文件写入），追踪哪些序列是由智能体的推理触发的，而不是由用户的显式意图触发的。一个说“处理我的订单”的用户，可能隐式地依赖于智能体对他们行业背景下“处理”含义的特定解释。
• 输出下游依赖：在 AI 产生结果后会发生什么？如果用户将该输出复制到另一个系统中、对其进行转换、或将其作为另一个流程的输入，那么即使语义保持不变，更改输出格式或词汇也会破坏他们的集成。
• 故障模式集成：这是一个反直觉的。一些用户已经适应了 AI 特定的故障模式。他们知道“当智能体说 X 时，它实际上是指 Y”。用一个故障方式不同——或者故障更少但在意想不到的地方出错——的智能体替换它，会扰乱这些习得的补偿行为。

具有追踪级粒度的良好可观测性工具使这种分析成为可能。将每个智能体推理步骤与下游影响链接起来的 OpenTelemetry 兼容追踪是基础。如果你现在还没有这种仪表化（instrumentation），那么在安全地下线任何复杂功能之前，你需要先添加它。

第二步：围绕行为迁移而非仅仅时间线来安排下线

业界已经形成了一套由云供应商普及的模型生命周期管理三阶段模型：遗留（Legacy）、废弃（Deprecated）、退役（Retired）。“遗留”阶段宣布意图；“废弃”阶段阻止新部署同时保留现有部署；“退役”阶段关闭所有服务。

这是一个合理的骨架，但它优化的是管理的清晰度而非行为的迁移。对于具有深度用户集成的 AI 功能，你需要在“废弃”和“退役”之间插入一个专门围绕行为设计的迁移支持阶段——而不仅仅是切换到一个新的端点。

影子模式窗口 (The shadow mode window)：在宣布任何时间线之前，让你的替代系统与现有系统并行运行。记录两者的输出，而不将新系统的结果暴露给用户。这会给你带来两个关键的东西：行为偏差的具象测量（这两个系统产生显著不同输出的频率是多少？），以及它们分歧最大的案例清单。这些分歧案例正是用户会遇到破坏的地方——你现在知道该把迁移指导重点放在哪里了。

分段废弃：不要在同一时间线下线所有人。按行为依赖深度进行分段：

加载中…