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）来引导你。
你的 RAG 系统在三个月前上线，检索准确度令人印象深刻。如今，它对用户提问中三分之一的内容都给出了“自信的错误”回答——而你的监控系统完全没有察觉到这种变化。没有错误日志，没有延迟激增。语义相似度得分看起来很正常。但检索到的文档已经过时，而模型却充满了信心地回答，因为检索到的上下文看起来非常权威。
这就是 RAG 的新鲜度问题：语义相似度并不关心时间。一个已弃用的 API 参考文档的 Embedding 得分可能与当前最新的文档一样高。上个季度的政策文档可能会排在更新版本之前被检索到。系统不知道，也无法分辨。大多数团队只有在收到用户投诉后，才发现他们的索引已经过时了数周甚至数月——而到那时，用户已经悄然失去了对系统的信任。
在为你的智能体（agent）采用推理模型之前，有一个数字值得你深思：对于一个标准的快速模型，单次查询仅需 7 个 token，但在 Claude extended thinking 中则需要 255 个 token，而在配置激进的推理模型中更是高达 603 个 token。对于孤立的聊天机器人查询来说，这还是可以接受的。但在一个每项任务调用模型 12 次的智能体循环中，你支付的不只是 10 倍的溢价 —— 而是 10 倍溢价乘以 12，并且随着每一轮重新喂入不断增长的上下文窗口，成本还会进一步复现。账单带来的“惊喜”扼杀智能体项目的速度往往比准确性问题还要快。
问题不在于推理模型是否更好。在处理困难任务时，它们显然更出色。问题在于，推理模型是否更适合你的特定工作负载，是否更适合你在智能体循环中的特定位置，以及其提升的幅度是否足以抵消成本。大多数团队在这两个方向上都做出了错误的回答 —— 他们要么统一采用推理模型（在不需要它们的任务上浪费预算），要么完全避开它们（错失了在需要它们的任务上提升准确性的机会）。
你的推理模型在 98% 的情况下能正确识别出数据是敏感的，但它在思维链（chain-of-thought）中泄露该数据的概率却高达 33%。这种差距——即知道某事是隐私与实际保持其私密性之间的脱节——是推理轨迹（reasoning trace）隐私问题的核心，而大多数生产团队尚未为此做好准备。
深度思考（Extended thinking）已成为对准确性要求极高的应用程序的标准工具：客户服务分流、医疗编码辅助、法律文件审查、财务分析。而这些领域恰恰是 Prompt 中数据最敏感的地方。在这些场景中部署推理模型，如果不了解轨迹如何处理这些数据，将面临巨大的暴露风险。
大多数决定自托管 LLM 的工程师都会从同样的计算开始：模型有 70B 参数，FP16 每参数 2 字节，所以是 140 GB。他们检查发现两块 A100-80GB GPU 能容纳 160 GB，感到很满意，于是订购了硬件。然后进入生产环境，却发现还没服务一个真实用户，显存（VRAM）就已经耗尽了。
模型权重只是故事的一部分。让几乎每个团队都感到意外的部分是 KV 缓存（KV cache）—— 理解它会改变你的每一个决定，从量化选择到推理框架，再到你实际需要的 GPU 数量。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
