为什么你的 AI Agent 将大部分上下文窗口浪费在了工具上

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

这种幼稚的方法将工具使用视为已解决的问题。添加工具，编写 Schema，看着智能体调用它们。在小规模下运行良好。但一旦连接真实的业务工具，它就会崩溃：拥有 40 个端点的 CRM 系统，具有模糊重叠功能的内部 API，以及各自携带上百个定义的 MCP 服务器。到那时，你构建的不是一个智能体系统，而是一个非常昂贵的上下文污染机器。

这篇文章将探讨破坏生产工具使用的三个复合瓶颈，以及真正解决这些问题的架构模式。

瓶颈 1：上下文窗口污染

工具定义是散文。包含描述、参数说明、用法注释的 JSON Schema。它们读起来像文档，因为它们 就是 文档——模型需要理解每个工具才能正确使用它。

问题在于这些文档在任何工作开始前就消耗了上下文。一个极简的工具定义可能是 200 个 Token。一个带有参数描述和嵌套 Schema 的详细工具可能是 800 个。乘以 50 个工具，在对话开始前你就已经花费了 10,000–40,000 个 Token。乘以 100 个工具，你会发现早在用户发送第一条消息之前，上下文就已经被填满了。

实际后果不仅是成本——还有质量。随着上下文填满，模型的推理连贯性会下降。对话历史被挤出以腾出空间给定义。智能体再也无法看到三轮之前的对话内容，因为工具 Schema 占据了那个空间。性能会以一种极难调试的方式退化，因为这种退化是逐渐发生的，而不是突然崩盘。

修复方案：延迟工具加载（Lazy Tool Loading）。 不要预先加载所有工具定义。仅加载智能体处理特定任务可能需要的工具，然后根据需要按需发现其他工具。实现模式：将工具标记为延迟加载，并提供一个小的“工具搜索”功能，模型可以调用该功能来检索它认为相关的工具的完整定义。

这里的数字非常可观。将每次请求的工具定义从 50 个减少到 3–5 个，可以降低 85% 的单次请求 Token 消耗，并将可用上下文窗口增加 50%。更重要的是，由于延迟加载的工具不会出现在初始提示词中，它们不会干扰提示词缓存（Prompt Caching）——即使工具可用性扩展，你也能保持系统提示词的缓存命中。

难点在于延迟加载对工具命名和描述质量提出了极高要求。当模型搜索工具时，它会对工具名称和摘要进行语义匹配。query_db 和 fetch_records 看起来像同义词。而 search_customer_orders_by_date_status_and_amount 则是自描述的。你的工具注册表质量直接决定了搜索的准确性。

瓶颈 2：顺序调用带来的推理开销

标准的智能体循环是：推理、调用工具、接收结果、再次推理、调用下一个工具。对于一个需要 20 次工具调用的工作流，这意味着 20 次推理过程。以每 1,000 个输入 Token 0.01 美元和 4,000 Token 的上下文计算，你在每个工作流上要花费 0.80 美元——这还没算上累积在上下文中的中间结果。

更深层的问题是这些中间结果对上下文的影响。一个读取 2,000 条费用明细的预算合规性检查，不需要将所有 2,000 条项目都返回到模型的推理上下文中。它只需要返回：“发现 47 处违规，标记费用 12,400 美元，3 处需要立即上报。”模型并不需要看到每一行明细——它需要的是综合后的结果。

有两种模式可以解决这个问题。

第一种是并行工具调用（Parallel Tool Calling）：同时发出多个独立的工具调用，而不是顺序进行。扇出（Fan-out），然后扇入（Fan-in）。当你的智能体在响应前需要检查账户状态、验证库存并查询价格时，没有理由串行执行这些操作。并行调度这三个任务，汇总结果，然后进行单次推理。这不会减少总的推理次数，但它能显著降低端到端延迟，并防止中间结果在上下文中不必要的累积。

聚合规则在这里至关重要。返回部分、冲突或不完整结果的并行调用需要明确的合并逻辑。如果没有它，你会遇到“谁声音大谁赢”的情况——最冗长的工具结果会主导模型的推理，即使它的相关性较低。在需要调试失败的合并之前，先定义好成功的合并应该是什么样的。

第二种模式是代码编排执行（Code-orchestrated Execution）。模型不是通过智能体循环顺序调用工具，而是编写一段简短的代码块来编排多个工具调用，以编程方式处理结果，并仅返回综合输出。模型看不到中间结果——只能看到最终答案。

对于预算合规性示例：原本需要 20 次推理、上下文中包含 50KB 费用数据，现在只需一个代码块、一次执行和 1KB 的摘要。在实际工作流测试中，这种模式可以在复杂的多步任务中减少 35–40% 的 Token 消耗，并提高需要汇总多源信息的基准测试准确率。

权衡在于：模型需要有足够的能力来编写正确的编排代码，并且你需要一个安全的执行沙箱。这不适用于简单的单一工具调用，也不适用于模型确实需要对中间结果进行推理的情况。它擅长：汇总大型数据集、包含 3 个以上依赖调用的工作流，以及任何原本会导致原始 API 响应填满上下文的场景。

瓶颈 3：参数歧义

JSON schema 可以验证结构，但无法表达意图。

Schema 规定 date 是一个字符串，但它没说这个字符串应该是 2025-01-15、January 15, 2025、15/01/2025 还是 1705276800（Unix 时间戳）。Schema 规定 filter 是一个可选对象，但它没说你在查询大型数据集时应始终包含它以避免超时。Schema 规定 currency 有一个有效的枚举值列表 ["USD", "EUR", "GBP"]，但它没说即使在默认使用 USD 的情况下，跨境交易也需要显式指定货币。

这是生产环境工具调用中典型的隐性失败模式。调用在结构上是有效的，通过了 schema 验证。但 API 返回了错误，或者更糟糕的是，返回了模型视为正确但实际并不符合预期的结果。

标准的建议——“写好描述”——是正确的，但并不完整。描述解释了参数的作用，而示例则展示了它在上下文中的使用方式。

具体的示例在效果上远好于单纯的描述。 这种模式是：对于每个具有非显而易见参数的工具，包含 3–5 个使用示例，展示最小化的有效调用、带有特定可选参数的部分规范，以及复杂情况下的完整规范。使用真实的数据——真实的城市名称、合理的价格、看起来真实的 ID。模型能从示例中进行归纳，而这是它无法从抽象文档中做到的。

提升效果非常显著：在需要复杂参数处理的任务中，添加具体的示例能将准确率从 70% 左右提升到 85–90% 的区间。通过花费一小时编写文档，就能获得 15–20 个百分点的提升。

这种努力是前期投入。编写一次示例，将它们包含在你的工具注册中心（Tool Registry）里，每一次调用都将受益。相比之下，在生产环境中调试参数错误既昂贵又缺乏系统性。

为生产环境设计工具接口

除了上述三个瓶颈，一套接口设计原则可以将运行可靠的工具与产生歧义的工具区分开来：

返回精简且合成后的输出。 大多数工具返回的信息超出了模型的实际需求。如果模型只需要 1–2 个相关片段，而搜索工具却返回 10 个完整的文档，这会让上下文充满噪音。在相关时包含 reason_code（原因代码）或 confidence（置信度）字段。通常，一个结构良好的精简响应可以完全消除后续的追问调用。

要求在调用前进行显式推理。 提示模型在每次工具调用前陈述一行理由，并在每次结果后进行简要观察，这能提高可追溯性并减少推理循环。这会迫使模型阐明它 为什么 要调用某个工具，从而捕获那些它出于习惯而非必要而使用工具的情况。

构建拒绝网关。 每次工具调用在执行前都应通过验证。尽早拒绝格式错误的调用并提供显式的错误消息，而不是静默失败。模型可以从清晰的错误中恢复，但它无法从一个虽然成功但什么也没做的 API 调用中恢复。

将提示词注入视为工具调用中的 SQL 注入。 如果你的工具接受会在下游执行的自然语言参数，你就面临注入攻击的风险。实施黑名单清洗，在执行前针对预期模式验证参数，并将非预期的输入结构视为潜在攻击而非边缘情况。

并行工具调用的实践

并行工具的使用改变了架构，其影响超出了“同时调用多个工具”的范畴。

规划模型（Planning model）和执行模型（Executing model）可以是不同规模的。大模型擅长确定如何并行工作——将任务分解为独立的子任务，识别哪些操作可以在没有状态冲突的情况下并发运行。而较小的模型可以处理每个特定调用的实际执行。规划器 + 执行器的拆分让你能高效地利用计算资源：在战略推理关键的地方使用昂贵的推理，在常规执行中使用廉价的推理。

设置分支预算以防止成本失控。 在并行工作流中，每个分支都可以独立积累上下文并进行额外的调用。如果没有明确的预算——最大 token 数、最大调用次数、最大延迟——一个昂贵的分支可能会耗尽你整个会话的预算，而其他分支可能只需极低成本即可完成。为每个并行分支设置硬性限制并强制执行。

证据溯源防止聚合问题。 当来自并行分支的结果被合并时，要求每个贡献的结果都包含出处标记：哪个工具、哪次调用、哪些参数。这使得后期调试变得可行，并防止合并后的总结丢失其来源。

未来趋势

推测执行（Speculative execution）方法——即根据历史模式，在模型显式请求之前预先启动预测的工具调用——在研究环境中已证明能减少 48% 的任务完成时间。这个想法类似于 CPU 的分支预测：你会为错误的预测付出代价，但会在正确的预测上大获全胜。虽然目前尚未在生产环境中广泛部署，但随着工作流的标准化，这一模式将变得至关重要。

MCP（Model Context Protocol）生态系统作为一种标准正在走向成熟（现在已得到各大主流厂商的支持），这意味着工具定义将越来越能在不同的 Agent、组织和工作流之间复用。这将工具设计从局部工程问题转变为更接近 API 设计的工作——即他人所依赖的接口，具有版本控制、迁移路径和稳定性保证。

更深层次的转变在于，工具调用的质量正在成为衡量 Agent 优劣的主要标准——即区分“真正能用的 Agent”与“看起来能用的 Agent”。模型能力的差异正在缩小，上下文窗口的限制正在扩大。剩下的是那些并不起眼的工作：工具定义质量、懒加载架构、示例覆盖率、验证网关。这才是生产环境可靠性的基石。

连接到一切的 50 工具 Agent 并不是 Agent 设计的成熟版本，它只是草案。成熟的版本是每项任务加载 5 个工具，生成合成输出，并在失败时发出足够响亮的警报，以便让你能够修复它。