当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。
这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。
生产环境中大多数 LLM 推理基础设施的故障并不是模型故障——而是调度故障。团队部署了一个高性能模型，进行了压力测试，却发现用户在等待的同时，昂贵的 GPU 时间仅以 35% 的利用率在消耗。罪魁祸首几乎总是静态批处理（Static batching）：这是从传统深度学习中继承下来的默认设置，但根本不符合语言模型生成文本的方式。
持续批处理（Continuous batching）——也称为迭代级调度（Iteration-level scheduling）或飞行中批处理（In-flight batching）——是解决这一问题的核心机制。它不是一个微调旋钮，而是对推理循环运行方式的架构性改变。在使用相同硬件的情况下，使用该技术的系统与不使用的系统相比，吞吐量可能相差 4–8 倍。
大多数构建智能体（agent）的团队将数据库模式（schema）视为后端关注的问题。这种模式是由工程师为工程师设计的，遵循了数十年关系型数据库的最佳实践：积极规范化、避免冗余、拆分引用表、强制执行外键。这种方法对于联机事务处理（OLTP）系统是正确的，但对于 AI 智能体来说通常是错误的。
当智能体读取你的模式以确定如何回答问题时，它并不是在解析数据结构，而是在构建你业务的心智模型。如果你的模式是为已经理解该领域的应用程序代码构建的，那么智能体将根据为别人绘制的地图进行工作。结果就是幻觉式的联接、错误的聚合，以及原本只需两步却需要八步的工具调用链。
大多数采用知识蒸馏的团队，都在错误的理由和错误的时机下做出了这个决定。他们看到一个70B模型吞噬了推理预算，读到蒸馏可以产出一个"同样出色"的7B学生模型，便立即开干。六周后，他们得到了一个在验证集上表现良好的蒸馏模型，上线后却开始大规模输出自信满满的废话。验证集来自与教师模型合成训练数据相同的分布，而真实流量并非如此。
蒸馏是一种优化工具，而非能力升级手段。只有在特定条件下，经济账才算得过来——而且失败模式足够隐蔽，团队往往要等到用户先发现问题。
一个团队在周二下午将 GPT-4o 换成了一个更新的模型。到周四，支持工单增加了 30%，但没人能说清原因 —— 新模型的回答稍短，拒绝了一些旧模型能处理的边缘情况请求，并且日期格式化的方式不同，导致下游解析器崩溃。团队选择了回滚。两个迭代周期的工作付诸东流。
这种故事不断上演。问题不在于新模型更差 —— 它在大多数方面可能表现得更好。问题在于团队发布的流程与发布 bug 修复程序完全相同：合并、部署、观察。这对代码有效，但对 LLM 则行不通。
大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。
Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。
你的生产系统运行正常。可用性为 99.9%。延迟处于正常水平。错误率告警为零。然后一个用户提交了一个工单：“最近的摘要变得莫名其妙地偏差。”你调取日志，一切看起来都没问题。你检查模型版本 —— 还是三个月前部署的那个。到底发生了什么变化？
是模型提供商变了。而且是悄无声息地变了。
这就是模型升级陷阱：基础模型在你不知情的情况下发生了变化，而标准的观测基础设施对这种行为偏移（behavioral drift）完全视而不见。等到用户注意到时，性能下降已经持续累积数周了。
为 LLM 应用添加视觉能力看起来简单得令人误解。你将文本模型换成多模态模型，在提示词中加入一张图片，演示效果就非常出色。但在推向生产环境后，你会发现有一半的发票金额是错的，PDF 中的表格丢失了结构，而低质量的扫描件会产生言之凿凿的幻觉。调试这种系统的难度超过了你以前面对的任何纯文本系统，因为这些失败是视觉上的，且 LLM 不会告诉你它看不清楚。
本篇文章将介绍当多模态 LLM 输入从原型转向生产环境时，究竟会发生什么问题，以及能够防止这些失败的架构决策。
每个销售 LLM 网关的供应商都会向你展示一张标有“95% 缓存命中率”的幻灯片。那张幻灯片不会告诉你的是小字说明：这个数字是指在找到匹配项时的匹配准确度，而不是找到匹配项的频率。实际的生产系统命中率为 20–45% —— 营销与现实之间的差距正是大多数团队踩坑的地方。
语义缓存（Semantic caching）是一项非常有用的技术。但在不了解其失效模式的情况下部署它，会导致你以极高的置信度向用户返回错误答案，并让你纳闷为什么支持工单翻了一倍。
你使用 GPT-4 生成了 50,000 个合成的指令遵循示例，在这些示例上微调了一个较小的模型并将其部署，结果看起来非常棒。六个月后，你的团队重复了这一过程——只不过这次为了节省成本，你使用微调后的模型来生成示例。第二个模型的评估结果略低，但在噪声范围内。你以同样的方式微调了下一个版本。到第四次迭代时，你的模型输出呈现出一种奇怪的同质化。用户反馈它听起来像机器人。它在处理任何不符合狭窄模板的内容时都显得很吃力。你最强大的微调模型已经变成了最糟糕的一个。
这就是模型崩溃（model collapse）——当大语言模型（LLM）使用其他 LLM 生成的数据进行训练时，会发生渐进式的、自我强化的退化。这并非理论上的风险。它是一种有据可查的故障模式，具有可衡量的机制，并且越来越有可能影响那些在没有仔细思考反馈动态的情况下就将合成数据生成常态化的团队。
大多数构建语音 AI 的团队都会以同样的方式发现延迟问题：在生产环境中，面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时，会觉得它很机械——不是因为声音不好听，而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。
这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。
有一项研究，研究人员要求一个推理模型比较两个数字：0.9 和 0.11。一个模型花了 42 秒才给出答案。数学计算只花了几毫秒。模型在剩下的 41.9 秒里都在进行糟糕的思考。它重新审视自己的答案，怀疑自己，重新考虑，最后得出了它在前三个 token 中就已经得出的正确结论。
这就是过度思考的问题，它并非个案。当你将推理侧计算（inference-time compute）不加区分地应用于不需要它的任务时，就会发生这种情况。
推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
