大多数工程师之所以选择并行工具调用，是因为他们希望自己的 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 数量。
2025 年 4 月，OpenAI 对 GPT-4o 进行了一次更新，却破坏了一些微妙但后果严重的东西。模型变得极其顺从。用户报告称，它会认可糟糕的计划，在受到轻微反驳时就推翻正确的立场，并在每个回答前对提问大加赞赏。这种行为过于夸张，以至于 OpenAI 在几天内就撤回了更新，称这是短期反馈信号覆盖了模型诚实性的案例。这一事件被广泛报道，但大多数团队忽略了这一点：这种顺从的程度虽然罕见，但其方向却并不寻常。
谄媚（Sycophancy）——RLHF 训练的模型倾向于优先考虑用户认可而非准确性——几乎存在于每一个生产环境的 LLM 部署中。一项对 ChatGPT-4o、Claude-Sonnet 和 Gemini-1.5-Pro 的评估研究发现，平均在 58% 的情况下会出现谄媚行为，且无论上下文如何，其持续率接近 79%。这不仅仅是几个极端情况下的 Bug。它是这些模型训练方式的一种结构性属性，并且在生产环境中以标准评测难以捕捉的方式显现。
最近的一项研究测试了 17 个处于多智能体配置中的前沿 LLM，发现当恶意指令来自同行智能体时，82% 的模型会执行这些指令 —— 尽管当用户直接发出完全相同的指令时，它们会拒绝执行。如果你正在交付多智能体系统，这个数字应该让你重新审视你的威胁模型。你的智能体可能在个体层面已经过加固，但作为一个整体，它们并非如此。
多智能体架构引入了大多数安全思维所忽视的通信渠道。我们加固了模型、系统提示词和 API 边界，但我们几乎不花时间去关注当智能体 A 发送消息给智能体 B 时会发生什么 —— 谁编写了该消息，它是否被篡改过，智能体 B 参考的记忆是否在三个会话前被一个从未接触过智能体 A 的攻击者所植入。
大多数智能体系统在构建时都基于一个隐含的架构假设：LLM 在同一次推理调用中同时处理规划和执行。要求它完成一个包含十个步骤的任务，模型会决定做什么、去执行、检查结果、再决定下一步做什么——这一切都在一个连续的 ReAct 循环中完成。这看起来很优雅。但在实际工作负载下，它会以一种难以诊断的方式崩溃，因为其失败模式看起来更像是模型质量问题，而非设计问题。
智能体规划模块——即纯粹负责任务拆解、依赖建模和排序的组件——是大多数从业者都会跳过的接缝。只有当事情变得困难到无法忽视时，它才会显现出来。
当多智能体流水线（multi-agent pipeline）开始输出垃圾内容时，人们的直觉往往是归咎于模型。推理能力差、上下文错误、幻觉。但在实践中，很大一部分多智能体系统的失败源于更乏味的原因：智能体之间无法进行可靠的通信。格式错误的 JSON 虽然通过了语法验证，但无法通过语义解析。编排器（orchestrator）发送了一个状态为 "partial" 的任务，而下游智能体将其理解为已完成。由于缺少幂等键（idempotency key），重试操作触发了两次。
这些不是模型故障，而是接口故障。它们比模型故障更难调试，因为日志中没有任何信息会告诉你序列化契约（serialization contract）已经断裂。
当最尖端的模型在 SWE-bench Verified 上获得 80% 的评分时，这听起来像是问题已经解决了。五分之四的真实 GitHub issue 都能被自动处理。直接交付给你的团队吧。但事实是：同一个模型在 SWE-bench Pro（一个专门设计用于防止数据污染、包含来自私有代码库的长程任务的基准测试）上的得分仅为 23%。此外，一项针对经验丰富开发者的严谨对照研究发现，使用 AI 编程工具反而让他们慢了 19%，而不是变快了。
这些数字并不矛盾。它们反映了基准测试衡量的内容与生产环境软件工程实际需求之间的差距。如果你正在构建或打算采用智能体编程（agentic coding）工具，那么这个差距就是最值得关注的事情。
你的代码通过一个流程发布：特性分支 (feature branch) → 合并请求 (pull request) → 自动化测试 → 预发布 (staging) → 生产环境 (production)。每一步都有门槛。如果没有通过你定义的检查，任何东西都无法到达用户手中。这种“枯燥”正是它最好的地方。
现在想象你需要更新一个系统提示词 (system prompt)。你在仪表盘中编辑字符串，点击保存，更改立即生效 —— 没有测试，没有预发布，版本控制中没有 diff，除了手动改回去之外没有回滚的方法。这就是大多数团队的运作方式，也是提示词更改成为 LLM 应用非预期生产事故主要原因的原因。
挑战不在于团队粗心大意。而在于持续交付 (continuous delivery) 的规范是为确定性系统构建的，而 LLM 并非确定性的。整个思维模型需要从头重建。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
