黑色星期五的流量峰值来了。传统 API 服务的应对方式是启动更多容器。60 秒之内，你的容量就扩充到三倍。自动扩缩容器做了它一贯的事，你安然入睡。
但如果用同一个自动扩缩容器跑 LLM，结果就大相径庭了。新的 GPU 实例要在四分钟的模型权重加载之后才能上线。等那时候，你的请求队列已经塞满，现有 GPU 在半途生成的请求的内存压力下颠簸挣扎，用户盯着转圈圈的加载动画发呆。增加更多算力没有任何帮助——瓶颈根本不在你以为的地方。
AI 推理负载打破了让响应式自动扩缩容在传统服务中奏效的大多数假设。理解其中的原因，是构建能够扛住流量峰值的系统的前提。
你升级到了最新模型，结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高，能处理更难的问题，拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力？退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出，而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感，现在像是在自动驾驶。
这就是能力激发差距：模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环，这个差距系统性地扩大。
AI 生产力研究中有一个几乎无人提及的数字：39 个百分点。一项针对有经验开发者的研究中，参与者预测 AI 工具会让他们快 24%。完成任务后，他们仍然认为自己快了 20%。实际测量结果：他们慢了 19%。感知差距是 39 个百分点——而且每次迭代、每次代码审查、每个交付的功能都在累积。
这就是认知负载倒置。AI 工具擅长卸载廉价的认知工作——编写语法正确的代码、起草模板、建议函数名——同时产生了一类更难的认知工作：对不确定输出的持续评估。你并没有消除认知努力，而是将简单的一半自动化了，然后把困难的一半留给了自己。
在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。
这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。
大多数工程团队对待 LLM 上下文窗口的方式，就像早期 Web 开发者对待全局变量：先塞进去，问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档，以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了，而那时已经很难判断究竟是哪里出了问题。
上下文窗口不是堆内存。它更接近于 CPU 寄存器文件：容量有限、单位成本高昂，且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时，程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时，LLM 会以悄无声息且代价高昂的方式退化。
大多数工程团队把系统提示词当作配置文件对待——需要快速迭代的技术字符串，存储在环境变量中，部署时的仪式感和修改一个超时值差不多。系统提示词有内联注释。错误提示一条也没有。能力披露就是产品经理在上线当天往 Notion 文档里打的那段话。
这正是整整一类 AI 产品故障的根源——这类问题不会出现在你的评估套件里。模型回答了问题，延迟没有问题，JSON 验证通过了。但用户在三次会话之后就停止信任这款产品，周活跃用户曲线再也没能回升。
缺失的那门学科叫对话设计。它影响输出质量的方式，大多数工程监控在架构上是盲目的。
当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。
大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。
当数据变得嘈杂时，你的梯度提升模型会礼貌地退化。准确率下降，精确率下降，监控告警触发，值班工程师知道该去哪里排查。LLM则不会这样。向LLM输入降级、陈旧或格式错误的数据，它产生的输出流畅、自信、听起来权威——但部分甚至完全是错的——而下游消费该输出的系统根本无从分辨。
这就是数据质量税：当劣质数据进入LLM管道时，你付出的复利代价——不是以低置信度分数的形式，而是以披着事实语法的幻觉来呈现。
在 GPS 出现之前，水手们使用推算定位法（dead reckoning）：取你最后一个确认的位置，记录你的速度和航向，然后向前推算。这种方法一直有效，直到累积的误差复合成不可逆转的后果——你没预料到的礁石。
长时间运行的 AI Agent 正面临着完全相同的问题。当一个 Agent 花费两个小时协调 API 调用、编写文档并执行多步骤计划时，运行它的人通常并不比没有仪器的水手拥有更好的能见度。Agent 要么完成了，要么没完成。失败模式并不是崩溃——而是看似在工作却静默循环并烧掉 30 美元 token 的情况，或者是 Agent “成功”完成了错误的任务，因为它的世界模型在执行一小时后发生了偏移。
生产数据让这一点变得具体：据记录，未被发现的循环 Agent 在人工干预前曾重复相同的工具调用 58 次。按照前沿模型的费率，一个失控运行两小时的 Agent 在被察觉之前会耗费 15–40 美元。而最严重的失败并不是报错退出的那些——而是那 12–18% “成功”运行却返回看似合理实则错误答案的情况。
你的生产系统中有一个智能体删除了 10,000 条数据库记录。这次删除符合有效的业务逻辑 —— 这些记录被正确标记了。但三个月后，监管机构提出了一个简单的问题：谁授权了这个操作，智能体是根据什么依据做出决定的？你打开日志，找到了 SQL 语句，找到了时间戳，但什么都找不到了。
这就是决策溯源问题。你可以证明你的智能体采取了行动；但你无法证明它为什么这样做，或者这个行动是否曾经得到了一个真正理解自己在批准什么的人的授权。随着自主智能体开始执行跨越数小时、数十次工具调用、且决策具有真实世界影响的工作流，"我们有日志"与"我们有问责机制"之间的鸿沟已经在运营上变得危险。
大多数团队会在最糟糕的时机发现同一个事实：下线一个 AI 功能与废弃一个 API 完全不同。你在文档中添加了停用日期，发送了常规的三封系列邮件，切换了标志位——然后眼睁睁地看着支持队列激增 80%，而用户则大声解释替代方案“运行方式不一样”。他们的意思是：旧智能体的怪癖、特定的故障模式、以及它独有的错误答案，都已经变成了业务中不可或缺的支撑。他们在那些直到消失才被察觉的行为基础上，构建了整个工作流。
这就是 AI 功能废弃的核心问题。确定性 API 具有明确的契约（contracts）。如果你移除一个端点，每个依赖它的调用者都会收到 404 错误。损坏是可追踪、有限且可预测的。概率性 AI 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。
每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。
对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
