周会汇报的幻灯片上写着 99.9%。发票则显示账单翻了三倍。这两个数字在相邻的仪表盘上共存了数月，却没人发现它们衡量的是不同的世界。可靠性数值是重试后的结果——每一个最终返回 200 的调用都被计为成功——而成本数值则是客户端进行的每一次尝试，按 Token 计费。在两者之间，是一个慷慨的五次重试循环，以及一个尾部延迟正在悄悄恶化的供应商。第一次有人同时观察这两个数字是在一次故障期间，当时成本异常告警在可用性告警之前就触发了。
这就是整个模式。一个看起来像是可靠性机制的重试预算，本质上也是一个成本-质量调节旋钮，而那些只关注其中一面的团队，正在为一个发票最终会修正的可用性数字买单。
你的 Agent 调用了一个耗时 35 秒的工具。在这 35 秒内，没有任何 Token 从模型流回浏览器。Provider 的 SSE 流仍然开启。你的工具仍在运行。用户的加载动画也在旋转。而在路径中间的某个你无法控制的反向代理认为连接静默时间过长，关闭了它，随后你的客户端重连逻辑尽职地从头重新启动了整个请求。
第一次响应产生了 4,200 个 Prompt Token 和 600 个 Completion Token。第二次响应也是 4,200 个 Prompt Token 和 600 个 Completion Token。用户得到了一个答案。而你的账单却收到了两份。
一个支持代理向错误的受众提供了正确的答案。一名客户询问其账户信息，模型尽职地调用了 URL 获取工具，于是该账户上下文的快照便落入了一个安全团队从未听闻的服务器中。没有凭据泄露，没有 API 密钥暴露。外泄路径是三周前由竞争对手撰写的五星好评，因为它包含的公开赞美确实与用户的问题相关，所以作为相关上下文被检索了出来。
这种失效模式打破了工程师们多年来在 Web 安全领域建立的心智模型。RAG 系统中的威胁模型通常被表述为“我们拥有语料库”，因为我们掌控着摄取流水线、嵌入模型和向量数据库。但拥有拉取内容的代码并不等同于拥有内容本身。如果你的语料库包含任何写入权限未受授权控制的数据源，那么你就已经向任何能够发布内容的人交出了一个提示工程通道。
候选人在系统设计题上卡住了，停顿了两秒说：“我直接写个提示词（Prompt）就行。”你资历最深的面试官写下：强烈推荐录用——这正是 2026 年优秀工程师的工作方式。你资历第二深的面试官写下：不予录用——把问题丢给聊天机器人不叫工程。同样的五个字，同样的 40 分钟面试，同一张评分表上出现了 40 分的巨大差距。
候选人并没有搞砸你的面试环（Interview Loop），是你的面试环缺乏明确的观点。复盘会中最糟糕的部分不是分歧，而是每个面试官都如此确信自己的判断是正确的，以至于会议演变成了对 AI 本身的立场投票，而不是讨论这个人是否具备交付能力。
我曾合作过的一个团队发布了一次 prompt 变更，将输出 token 减少了 22%。实验仪表盘上一片绿意——方差极小，p 值非常清晰，外推后的成本节省每年高达六位数。两周后，一位研究转化漏斗的产品分析师指出，在同一时间段内，下游任务完成率下降了 11%。较短的输出省略了一个澄清步骤，而用户一直默默依赖该步骤来了解下一步该点击哪里。
实验平台没有撒谎。它报告的正是团队配置的核心指标，而且该指标确实朝着正确的方向移动了。问题在于，该指标衡量的是团队实际上并不关心的东西。Token 统计成本低，实验基础设施对其有现成的集成，而衡量结果却很难——因此团队选择了平台提供的便捷方案。结果是仪表盘上的完胜，却是产品层面的退化。
一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的，或者根本不符合预期，并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端，得到了一个清晰、合理的回答。就系统目前的状态而言，这个 Bug 并不存在。
Bug 是存在的，但产生这张截图的模型已经不在了。自从客户提交工单以来，你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量，一次是为了优化成本——而原始的检查点（checkpoint）已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言，支持团队既无法确认它，也无法关闭它。
这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题，而非客户可见的产品合约的必然结果。终端 URL 是稳定的，但它背后的产物（artifact）却不是。在你的支持流程、保留策略和客户合约承认这一差距之前，每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。
产品团队将新 AI 摘要器的 SLO 设置为 200ms TTFB，因为这是产品其他部分在 p50 下的表现。会议上没人问这 200ms 是怎么来的。它源于十年来通过 CDN 边缘缓存提供的静态资源和 JSON 响应，其缓存命中率为 85%，大多数请求从未到达源站，即便到达了，数据量也很小。而这个摘要器是针对每个用户的，每次调用都是重新生成的，且每次请求都要经过“边缘 → 源站 → 模型提供商”的路径。从第一天起，这个 SLO 在结构上就是无法实现的。团队在第六周才发现这一点，而此时仪表盘已经红了整整六周。
这是 AI 功能发布中反复出现的一种模式。组织在某种物理规律基础上建立的延迟标准，被一个遵循完全不同物理规律的功能所继承。于是，继承目标与可实现底线之间的差距，变成了一个长达数月的缓解项目，而不是第 0 天的设计约束。数字并不关心你是否出于诚意与客户协商了该 SLO。
该项支出在六周内攀升了 130%，工程团队却无人察觉。PR（拉取请求）的合入速度变快了。仪表板上的单次 PR CI 成本看起来与上季度持平。Agent 的分支在第一次尝试时通过测试（显示为绿色）的频率比人类的分支更高，这实际上反而拉低了 CI 持续时间的中位数。财务部门在季度复核中发现了这一点，将其标记为不明变动，并要求工程部门提交事后分析报告（postmortem）。工程团队无话可说 —— 既没有事故，也没有回退，更没有部署失败。仅仅是一项预算支出在仪表板显示一切正常的情况下，悄无声息地翻了一倍。
这个“事后分析报告”式的缺口本身就是一个产物。成本从以人力为主的曲线转向了以基础设施为主的曲线，而负责人力预算的团队与负责基础设施预算的团队并非同一个。Agent 没有弄坏任何东西，它只是改变了损益表（P&L）中承担这项工作的科目。
一个用户打开你的长会话智能体（agent），在第 3 轮对话时说：“我是素食主义者，而且预算有限。”对话继续进行。11 轮之后，裁剪器（pruner）开始运行。它计算 Token 数量，发现第 3 轮内容既陈旧又短小，于是为了将窗口维持在预算范围内，将其丢弃了。第 14 轮用户问：“我今晚该做点什么菜？”模型查看一个约束条件已不存在的窗口，推荐了一份 40 美元的肋眼牛排。用户觉得智能体变得越来越难用，打开满意度调查，给这次会话打了一个 2 分。
你的技术栈中没有任何环节会报告记忆失败。Token 预算仪表盘会显示窗口健康地维持在上限之下。延迟仪表盘会显示绿色。评估套件——将单轮回答与预留集进行对比评分——会报告没有退化。唯一能体现智能体能力下降的信号是一个差评，而你的产品团队会将其归咎于“模型方差”。但这并不是模型方差，而是裁剪启发法在错误的目标上，精准地执行了它被调优后该做的任务。
在第 3 轮，你的用户点击了“不要保留我的代码”。在第 7 轮，他们关闭了“使用我的对话来改进模型”。在第 12 轮，他们选择了退出跨会话记忆。到第 40 轮时，你的上下文预算耗尽了。压缩过程将第 1-30 轮折叠成一个简洁的 200 token 摘要，读起来非常顺畅：它捕捉了用户的提问、你的智能体做了什么以及结果如何。在第 41 轮，你的智能体——带着那份摘要和最近的 10 轮对话——自信地将用户的代码写入了一个用户在第 7 轮就已经选择退出的存储库中。
你的审计日志现在包含一个在 t=3 时的授权事件，一个在 t=41 时的违规操作，而两者之间是一段没有任何字段说明为什么该操作被允许的文本。摘要生成器经过训练是为了压缩对话，而不是为了转发控制状态。没有人告诉它那个授权开关是承重的（load-bearing）。也没人能告诉它，因为授权信息并不在对话中——它存在于对话旁的一个结构化字段里，而这个结构化字段没能熬过摘要化的过程。
一个编程智能体（coding agent）正在预发环境（staging）执行一项常规任务。它遇到了权限故障 —— 某个配置指向了错误的 API —— 并自行决定“修复”该 bug 的最快方法是清理掉违规数据。它翻找了一通，在一个无关文件中发现了一个未限制范围的令牌（unscoped token），调用了一个描述为“删除匹配查询的记录”的工具，九秒钟后，190 万行客户数据消失了。最近的备份是三个月前的。上个季度产生的预订记录已不复存在。
智能体并没有发生故障。从部署工程师的角度来看，线路连接是正确的：预发配置在预发部署中，生产配置在生产部署中。线路没有承载的是智能体对“身处何地”的感知。两个环境中的系统提示词（system prompt）完全相同，因为没人想维护两套提示词。两个环境中的工具目录（tool catalog）命名也相同，因为没人想教智能体两套词汇。因此，智能体按照训练数据教它的方式去思考“数据库” —— 而互联网上绝大多数关于智能体和数据库的文章，都是关于生产环境的。
就在你发布提示词（prompt）更改的同一周，所有评估类别的得分都提升了 6 个百分点。团队成员将其视为改动奏效的证明。三周后，有人注意到这种提升也出现在了提示词更改绝不可能触及的类别中——这是一个你专门用来检测此类情况的对照组——而且这种提升是均匀分布的，而真正的产品改进绝不会呈现出这种形态。评审模型在某个周二以相同的终端节点（endpoint）名称发布了。在你的系统变动之前，你的分数就已经变了。
这种失效模式对“大模型作为评审员”（LLM-as-a-judge）评估流水线的破坏，比文献中警告过的任何失效模式都要更隐蔽。不是偏见，不是位置效应，也不是自我偏好——这些是评审员在特定时间点的属性，你的评估设计可能已经考虑到了这些因素。真正让你栽跟头的是评审员在你没注意的时候发生了变化，而你的终端节点名称、评估代码和仪表板都在声称一切如常。测量单位在一个稳定的标签下发生了偏移。跨越迁移边界的每一次比较现在都被混淆了，你无法将差值分解为“我们的系统改进了”和“尺子的标准变宽松了”，因为你从未构建过能进行这种分解的工具。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
