大多数团队最初都使用单一的 LLM 提供商 API 密钥，并在所有业务中共享。这在起初行得通，直到某天它突然失效。也许在某个下午，数据管道中的一个批量任务耗尽了全部速率限制，导致面向用户的聊天功能陷入沉寂。或者财务部门要求你按团队细分 4 万美元的 LLM 账单，而你意识到自己根本无法回答这个问题。
在 LLM 提供商前部署生产级 API 网关可以解决这两个问题 —— 但它也会引入一类复杂性，大多数团队在遇到麻烦之前往往会低估这种复杂性。
为 LLM 应用添加视觉能力看起来简单得令人误解。你将文本模型换成多模态模型，在提示词中加入一张图片，演示效果就非常出色。但在推向生产环境后，你会发现有一半的发票金额是错的，PDF 中的表格丢失了结构，而低质量的扫描件会产生言之凿凿的幻觉。调试这种系统的难度超过了你以前面对的任何纯文本系统，因为这些失败是视觉上的，且 LLM 不会告诉你它看不清楚。
本篇文章将介绍当多模态 LLM 输入从原型转向生产环境时，究竟会发生什么问题，以及能够防止这些失败的架构决策。
你在凌晨 2 点收到了报警。用户报告输出内容全是一堆垃圾。你通过 SSH 登录，检查日志，盯着追踪信息 —— 结构上看起来一切正常。模型有响应，延迟也正常。但答案就是不对劲。接着，事故频道里出现了一个问题：“现在到底运行的是哪个版本的 Prompt？”
如果你不能在 30 秒内回答这个问题，说明你正面临 Prompt 版本管理问题。
在大多数早期 LLM 项目中，Prompt 被当作配置来对待。产品经理修改 .env 文件中的字符串，开发者将更新后的指令粘贴到硬编码的常量中，还有人在 staging 的 Slack 频道中粘贴了一个略有不同的版本。最终，版本产生了偏差，没有人知道哪里运行的是什么。这种在实验阶段助你快速上线的随意性，在你拥有真实用户的那一刻就会变成一种负债。
每个销售 LLM 网关的供应商都会向你展示一张标有“95% 缓存命中率”的幻灯片。那张幻灯片不会告诉你的是小字说明：这个数字是指在找到匹配项时的匹配准确度，而不是找到匹配项的频率。实际的生产系统命中率为 20–45% —— 营销与现实之间的差距正是大多数团队踩坑的地方。
语义缓存（Semantic caching）是一项非常有用的技术。但在不了解其失效模式的情况下部署它，会导致你以极高的置信度向用户返回错误答案，并让你纳闷为什么支持工单翻了一倍。
当开发者第一次接入 JSON 模式时，响应结果感觉就像解决了一个大问题。LLM 不再返回 Markdown 围栏、文字道歉或靠近花括号的乱码。输出可以解析了，测试通过了，生产环境上线了。
然而，三周后，一个后台作业悄无声息地失败了，因为模型在 Schema 要求 {"status": "completed"} 时返回了 {"status": "complete"}。由于一个必填字段返回了 null 而不是被省略，数据流水线崩溃了。智能体工具调用循环（agent tool-call loop）提前终止，因为模型在字符串值中嵌入了一个异常换行符，导致下游解析器卡死。
JSON 模式保证了语法上有效的 JSON。它并不保证该 JSON 的含义与你的预期一致，不保证它包含你的应用程序所期望的字段，也不保证在多次请求之间保持语义一致性。这些是不同的问题，需要不同的解决方案。
大多数 Agent 演示仅使用 5 个工具，而生产系统通常拥有 50 个。这两个数字之间的差距，正是大多数 Agent 架构分崩离析的地方。
当你给一个 LLM 4 个工具和一个明确的任务时，它通常能选对。但当你给它 50 个工具时，更有趣的事情发生了：准确率大幅下降，Token 成本激增，且失败模式通常表现为模型幻觉出一个工具调用，而不是承认它不知道该用哪一个。来自 Berkeley Function Calling Leaderboard 的研究发现，在跨多个领域的日历调度任务中，当工具数量从 4 个扩展到 51 个时，准确率从 43% 骤降至仅 2%。这绝不是一个平滑的性能退化曲线。
有一项研究，研究人员要求一个推理模型比较两个数字：0.9 和 0.11。一个模型花了 42 秒才给出答案。数学计算只花了几毫秒。模型在剩下的 41.9 秒里都在进行糟糕的思考。它重新审视自己的答案，怀疑自己，重新考虑，最后得出了它在前三个 token 中就已经得出的正确结论。
这就是过度思考的问题，它并非个案。当你将推理侧计算（inference-time compute）不加区分地应用于不需要它的任务时，就会发生这种情况。
推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。
大多数 AI agent 都会以同样的方式失败：它们在演示中表现完美，但在经历十次真实对话后就会分崩离析。那个上周二还帮用户配置账单集成的 agent，今天已经完全不记得那个用户是谁了。它再次询问对方的公司名称，然后是套餐层级，接着重新解释用户已经掌握的概念。体验从“有用的助手”降级为“健忘的聊天机器人”。
直觉反应是给问题增加更多上下文 —— 将对话历史塞进 prompt 并认为问题已解决。这种做法在达到一定规模前确实有效。在大规模场景下，全上下文方案的成本高得惊人，而且更麻烦的是，随着输入量的增长，性能会下降。研究表明，即使在模型宣称的限制范围内，LLM 的准确率也会随着上下文长度的增加而明显下降。100 万 token 的上下文窗口并不是一个记忆系统。
在生产环境中运行良好的 agent 将记忆视为头等架构关注点，而不是事后才考虑的事情。而那些做对的 agent 能够区分三种根本不同的持久化信息类型 —— 每种类型都有不同的存储模式、检索策略和衰减特性。
Model Context Protocol (MCP) 将自己定位为 AI 的 USB-C 接口 —— 将任何工具接入任何模型，然后看着它们自如交流。在实践中，第一天确实感觉如此。第二天你会遇到扩展性漏洞。到了第三天，你就在阅读关于那些你甚至都不知道存在的工具投毒攻击（tool poisoning attacks）的 CVE 了。
MCP 是一个非常有用的标准。它于 2024 年底推出，并迅速被整个行业采用，它解决了大语言模型（LLM）与外部系统之间真实的集成摩擦。但在“完成演示原型”与“在真实用户负载下可靠运行”之间，存在着比大多数团队预想的更大的鸿沟。以下是这个鸿沟的真实样貌。
你部署了一个从支持工单中提取客户意图的流水线。你已经对其进行了广泛测试。它运行良好。发布三天后，一个警报被触发：下游服务因 KeyError: 'category' 而崩溃。模型开始返回 ticket_category 而不是 category —— 提示词（prompt）没有改动，只是你的提供商悄悄推行了一次模型更新。
这就是结构化输出问题。而 JSON 模式并不能解决它。
你的 Datadog 仪表板显示 99.4% 的在线率，低于 500ms 的 P95 延迟，以及 0.1% 的错误率。一切都是绿色的。与此同时，你的支持队列却充满了抱怨 AI 给出了完全错误答案的用户。你毫无头绪，因为每个请求都返回了 HTTP 200。
这是传统可观测性与你在 LLM 系统中真正需要的可观测性之间的本质区别。语言模型可能会以标准 APM 工具无法留下痕迹的方式发生故障：幻觉事实、从错误的产品版本中检索文档、在代码更改修改了系统提示词后将其忽略，或者在模型更新后对特定查询类型静默降级。在你的延迟图表上，这些看起来都一切正常。
大多数生产环境中的 AI 系统在成本管理上都会犯同样的错误：它们上线时仅使用单一的最强模型 (frontier model) 来处理每个请求，眼睁睁看着 API 账单随流量线性增长，然后才手忙脚乱地添加缓存或缩减上下文窗口来补救。真正的解决方法——根据每个查询的实际需求将其路由到不同的模型——事后看来显而易见，但很少能被很好地实现。
数据能够清楚地说明问题。当前的最强模型 (frontier model)，如 Claude Opus，每百万输入 token 的成本约为 5 美元，每百万输出 token 为 25 美元。同系列的高效模型成本分别为 1 美元和 5 美元——比例达 5 倍。使用 RouteLLM 的研究表明，通过合理的路由，你可以在将 85% 的查询路由到更便宜的模型的同时，保持 95% 的最强模型质量，从而根据工作负载实现 45–85% 的成本降低。这不仅仅是边际改进；它改变了大规模部署 AI 的单位经济效益。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
