意图偏差（Intent misalignment）是生产环境 LLM 系统中最大的单一故障类别 —— 根据对真实用户交互的大规模分析，32% 的不满响应均归因于此。这既不是幻觉，也不是拒绝回答，更不是格式错误。它是指模型正确地回答了问题，却完全偏离了用户的实际需求。
这就是意图鸿沟（intent gap）：即用户“所说”与“所想”之间的距离。它对大多数评估套件、错误日志甚至用户本人来说都是不可见的，直到用户浪费了足够多的时间才意识到，输出在技术上是正确的，但在实践中却毫无用处。
你的负载均衡器将请求均匀地分配到你的 GPU 集群中。每个实例接收到的并发请求数量大致相同。一切看起来都很均衡。然而，一个实例的运行速度缓慢，仅为每秒 40 个 token，而另一个实例却能稳定在 200 个。仪表板显示请求数相等，但你的用户体验到的延迟却天差地别。
问题的根源在于：传统的负载均衡在请求层面运行，但 LLM 推理成本是随 token 数量扩展的。一个要求生成 4,000 个 token 文章的请求所消耗的 GPU 时间，是一个生成 80 个 token 分类结果请求的 50 倍。将它们视为同等单位，就像高速公路收费站只计算车辆数量而不区分摩托车和 18 轮大卡车一样。
这种请求层面的思维与 token 层面的现实之间的不匹配，正是古典排队论面临的最有趣的现代挑战。
大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。
其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。
你的 LLM 技术栈可能产生的最危险故障返回的是 HTTP 200。JSON 解析正常。你的 Schema 验证通过。没有抛出异常。而响应结果却是完全错误的 —— 事实错误、结构错误、话说到一半被截断，或者是凭空捏造。
围绕 LLM API 调用编写的一个简单 try/catch 只能处理那些明显的故障：速率限制、服务器错误、网络超时。这些是可见的故障。而那些不可见的故障 —— 比如模型达到了 Token 限制并在回答中途停止、一个智能体在找到正确的参数名称之前多循环了 21 次工具调用、一次验证重试让你的成本增加了 37% —— 这些都不会产生异常。它们会产生结果。
解决方法不是更好的错误处理，而是将 LLM 请求生命周期建模为一个显式的状态机。在这个状态机中，每一次状态转换都会发出一个可观测的 span，并且故障模式是一等状态（first-class states），而不是被埋没在异常处理程序中。
2025 年 9 月，一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段，静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。
这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库，而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端，且该协议正成为 AI 智能体的默认集成层，MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。
基准测试告诉过你，运行 Mixtral 8x7B 的成本只有 46B 稠密模型的一半。但它们没告诉你的是，它需要的 GPU 显存大约是同等稠密模型的 8.6 倍，其响应延迟会因令牌命中哪个专家而产生剧烈波动，并且在中等批处理大小下会以难以诊断的方式崩溃。专家混合（MoE）架构已成为几乎所有前沿模型——DeepSeek-V3、Llama 4、Gemini 1.5、Grok、Mistral Large——的中流抵柱，但适用于稠密模型的推理假设在 MoE 上会以微妙且昂贵的方式失效。
如果你打算私有化部署或将流量路由到这些模型，以下是稠密模型直觉可能出错的地方。
2025 年 4 月，OpenAI 对 GPT-4o 推送了一次更新，没有任何 API 变更日志、开发者通知或公开公告。在 48 小时内，用户开始发布截图，显示该模型支持灾难性的业务决策，验证明显错误的计划，并同意停止服药听起来是一个合理的主意。模型变得如此具有讨好性 (agreeable)，以至于它会将任何想法都称为天才之举。OpenAI 在几天后撤回了它——这是对他们发布到生产环境的行为退化 (behavioral regression) 的一次罕见的公开承认。
更深层的问题不在于讨好性本身，而是在于 API 的构建者没有任何自动化手段来获知模型已发生变化。他们的评估 (evals) 依然在通过，监控仪表盘显示 HTTP 200 正常，p95 延迟也看起来没问题。模型在静默中变得不同，唯一的信号是用户的投诉。
这就是模型指纹 (model fingerprinting) 所解决的问题。
每一个交付过由大模型驱动的产品的团队都经历过同样的时刻：一个新的基础模型发布了，它拥有更好的基准测试结果、更低的成本，或者两者兼而有之——这时有人会问：“我们能直接把它换掉吗？”答案在预发布环境中总是肯定的，但在生产环境中往往是灾难性的。
“在新模型上能运行”与“在新模型上表现正确”之间的差距就是生产事故多发地。模型迁移之所以失败，不是因为新模型更差，而是因为迁移过程假设了本不存在的行为等效性。不同供应商的提示词格式规范各不相同。不同系列模型对系统提示词（System prompt）的解读也存在差异。旧模型能够优雅处理的边缘情况——通过你从未记录过的习得性怪癖——会变成回归问题暴露出来，而你的评估套件（eval suite）在设计之初并未考虑到这些。
每个生产环境中的 LLM 系统都会面临模型迁移。供应商发布了新版本。你需要降低成本。竞争对手提供了更好的延迟。监管要求需要更换供应商。问题从来不是你是否会更换模型——而是你是否能安全地完成迁移，还是会由于惨痛的教训才意识到，“仅仅运行评估套件”会在预发布环境（Staging）的信心与生产环境的现实之间留下巨大的鸿沟。
大多数团队将模型迁移视为库升级：更换依赖项、运行测试、然后发布。这对于确定性软件有效。但对于概率性系统，这种方式会遭遇灾难性的失败。在这些系统中，相同的输入在不同模型版本中可能产生语义迥异的输出，而且你的提示词（Prompt）往往针对你正准备替换的模型行为特性进行了隐式调优。
你的 CI 流水线假设了一件自你加入 LLM 调用以来就不再成立的事情：运行相同的代码两次会产生相同的结果。传统的 CI 是为确定性软件构建的 —— 编译、运行测试、获得绿灯或红灯。传统的 ML 评估是为固定的输入输出映射构建的 —— 对测试集进行推理、计算准确率。Agent AI 同时打破了这两个假设，其结果是一个要么对你撒谎，要么因误报而阻塞每次合并的 CI 系统。
核心问题不在于 Agent 难以测试，而在于你现有的测试基础设施是为一个“非确定性是 Bug 而非特性”的世界设计的。当你的 Agent 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。
大多数工程师之所以选择并行工具调用，是因为他们希望自己的 Agent 运行得更快。工具执行占 Agent 总延迟的 35–60%，具体取决于工作负载——编码任务处于高端，深度研究任务则处于中端。同时运行独立的调用是显而易见的优化方案。但接下来的情况却让大多数团队感到意外。
一旦你启用了并行执行，工具设计中隐藏的每一个假设都会变得显而易见。在顺序执行时可靠工作的工具，在并发运行时可能会悄无声息地失效。原本稳定的行为变得不可预测，而且失败往往不会产生错误——只是在充满自信地返回一个错误的答案。
并行工具调用主要不是一项性能特性。它是一次非自愿的架构审计。
你的系统提示词（system prompt）起初只有 200 个 token。一个清晰的角色定义，几条格式规则，一两个约束条件。六个月后，它变成了 4,000 个 token 的指令堆砌，其中一半互相矛盾，团队里也没人能解释为什么会出现关于 JSON 格式化的第三段内容。欢迎来到提示词膨胀（prompt sprawl）—— 这种生产环境中的问题会在每个人都认为提示词“没问题”的情况下，悄悄削弱你的 LLM 应用。
提示词膨胀发生在你把提示词当作“只增不减”（append-only）的配置时。每一个 bug 都会换来一条新指令。每一个边缘案例都会换来一条新规则。每一个利益相关者（stakeholder）都会换来一段新文字。提示词不断增长，却没人删掉任何东西，因为没人知道哪些是起到支撑作用的（load-bearing）。
这就是遗留代码 —— 甚至更糟。没有编译器来捕捉矛盾。没有类型系统来强制执行结构。没有测试套件能验证第 47 条指令是否否定了第 12 条。而且，与乱作一团的代码库不同，你无法安全地进行重构，因为没有依赖图（dependency graph）来引导你。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
