一个日历日期选择器让一个生产环境浏览器 Agent 连续失效三天，无人察觉。设计师在一次小型 UI 改版中，将原生 <input type="date"> 替换为自定义 React 组件。没有 API 变化，没有内容移动，只是新布局中 24px 的单元格——而此前一直可靠点击正确日期的视觉模型，现在偏移了一格，悄悄地把预约订在了错误的日期。
这就是 DOM 脆弱性税：在从未为机器操作而设计的 Web 之上构建自动化 Agent，所持续付出的运营成本。与大多数基础设施税不同，它会复利累积。Web 在变化，反爬虫防御在进化，SPA 越来越动态，而你的 Agent 在悄然退化。
你的部署流水线是绿色的。延迟处于正常水平。错误率：0.02%。新的模型版本已成功发布——或者说你的仪表盘是这么显示的。
与此同时，你面向客户的 AI 正在微妙地以较低的精度总结文档，对以前能直接回答的问题含糊其辞，并不时地压平下游流水线所依赖的结构化输出。没有警报响起。没有触发值班呼叫。你收到的第一个信号是两周后的一张支持工单。
这就是 AI 部署中的隐性回归问题。传统的回滚信号——HTTP 错误、p99 延迟、异常率——是为确定性软件构建的。它们无法察觉行为漂移。随着团队更频繁地升级语言模型，“基础设施健康”与“AI 运行正确”之间的鸿沟成了回归问题的藏身之处。
在 GPS 出现之前，水手们使用推算定位法（dead reckoning）：取你最后一个确认的位置，记录你的速度和航向，然后向前推算。这种方法一直有效，直到累积的误差复合成不可逆转的后果——你没预料到的礁石。
长时间运行的 AI Agent 正面临着完全相同的问题。当一个 Agent 花费两个小时协调 API 调用、编写文档并执行多步骤计划时，运行它的人通常并不比没有仪器的水手拥有更好的能见度。Agent 要么完成了，要么没完成。失败模式并不是崩溃——而是看似在工作却静默循环并烧掉 30 美元 token 的情况，或者是 Agent “成功”完成了错误的任务，因为它的世界模型在执行一小时后发生了偏移。
生产数据让这一点变得具体：据记录，未被发现的循环 Agent 在人工干预前曾重复相同的工具调用 58 次。按照前沿模型的费率，一个失控运行两小时的 Agent 在被察觉之前会耗费 15–40 美元。而最严重的失败并不是报错退出的那些——而是那 12–18% “成功”运行却返回看似合理实则错误答案的情况。
12 要素应用（12-Factor App）准则让开发/生产环境一致性（dev/prod parity）变得家喻户晓：尽可能保持开发、预发布和生产环境的相似。对于传统的 Web 服务，这基本是可以实现的。但对于 LLM 应用，这在结构上是不可能的 —— 且其中的差距远比大多数团队意识到的要大。
问题不在于开发者粗心大意。而是在于 LLM 应用依赖于一类特殊的基础设施（缓存计算、实时模型权重、不断演进的向量索引以及随机性生成），在这些设施中，预发布环境（staging）与生产环境之间的差异不仅是令人不便，而是本质上完全不同。一个看起来正确的预发布环境至少会在七个具体方面对你撒谎。
你的 RAG 系统运行正常。延迟处于常规水平。错误率为零。但一位询问“加州雇佣法”的用户却不断得到关于房地产的搜索结果 —— 而你的日志显示一切正常。
这就是嵌入漂移（embedding drift）在作祟：这是一种不会抛出异常、不会导致错误率飙升，也不会出现在标准可观测性仪表盘上的检索失效模式。当你的向量数据库积累了在不同条件下生成的嵌入时 —— 比如不同的模型版本、不同的分块规则、不同的预处理流水线 —— 向量开始指向不兼容的方向，这种情况就会发生。系统仍在处理请求，但语义坐标已不再对齐，检索质量在数周或数月内悄然恶化。
你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。
问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。
这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。
周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。
这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。
你六个月前部署的模型在日历上已有一个日落日期。你可能没有标注它。你的值班轮换也不知道这件事。积压工作中没有对应的工单。当提供商最终拔掉插头时，你会在最糟糕的时刻收到生产环境中的 404 Model not found 错误，而且没有准备好的回滚方案。
这是大多数使用托管LLM的工程团队的标准故事。模型弃用被归类为供应商问题，而非运营问题——直到它变成一场事故的那一刻。
大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。
多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。
大多数采用多模态AI的团队都会犯同样的错误：他们在精心策划的基准数据集上评估模型，并假设生产性能会与之相符。然而现实并非如此。视觉模型在MMMU基准上取得高分，与同一模型在生产中可靠地从发票中提取结构化数据之间，存在足以葬送产品发布的巨大差距。视觉编码器增加了基准排行榜上无法体现的延迟。空间推理在用户实际发送的图表类型上失效。在干净语音上表现良好的音频模型在真实世界的噪声下土崩瓦解。而多模态真正优于纯文本的任务类别，比供应商所暗示的要窄得多。
本文是关于这一差距的实战指南——它在哪里出现，为什么存在，以及哪些部署模式能在生产负载下保持稳定。
大多数团队决定使用端侧 LLM 推理的方式，就像他们决定重写数据库时一样：冲动行事，仅仅是为了应对原本可以用更廉价方案解决的问题。推介词总是令人心动——无需网络往返、完全隐私、零推理成本——而且初始原型也验证了这一点。然而，在发布六个月后，模型开始悄无声息地输出更差的结果，新的操作系统更新打破了量化兼容性，而那些使用廉价安卓手机的用户正在运行一个你无法推送更新的版本。
本指南旨在让你在看清现实的情况下做出决策。在特定场景下，端侧推理确实是正确的选择，但其成本结构与团队预期的不同，且生产环境中的失效模式与云端 LLM 部署几乎完全不同。
2024 年某个时刻，一个规律开始在 AI 团队的事后复盘中反复出现："我们去掉 LangChain 重写了，上线速度明显加快了。"这些团队在采用框架时并没有犯技术错误——犯的是时机错误。LangChain 是原型阶段的对路工具，却是第七个月的错误工具。
同样的故事发生了足够多次，现在它有了一个名字：编排框架陷阱。你采用了一个确实能加速早期工作的框架，生产力提升掩盖了不断累积的结构性债务。等到债务浮出水面，你已经深陷于那些本不该被触碰的内部实现之中。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
