LLM工具调用失败？删掉一半工具比写超长提示词更有效

给AI Agent添加更多工具、写更详细的提示词，是很多团队遇到工具调用不稳定时的第一反应。但一位开发者的实践给出了相反的答案：删掉一半工具，收紧schema定义，Agent立刻变得"聪明"了。这个反直觉的修复揭示了LLM工具调用设计中一个被广泛忽视的问题——工具界面的语义碰撞。

问题根源：重叠工具制造语义碰撞

该开发者的Agent接入了Slack、Notion、HubSpot和几个内部API——一个典型的自动化工作流技术栈。但GPT-5.4频繁调用错误的函数，换成Claude Opus后问题依然存在，只是"姿态稍微好一点"。

他最初的修复方式是经典的错误做法：添加规则、添加例外、添加示例、添加反例、写更多提示词来解释何时使用哪个工具。结果是提示词越来越长，行为却没有改善。这本身就是关键线索：提示词已经不是瓶颈了，工具界面才是。

问题的本质在于语义碰撞。当你给模型提供find_contact_hubspot、get_account_notes_notion、search_customer_records_internal、search_slack_customer_thread这四个功能时，人类能看出它们的差异，但模型看到的是四个部分重叠的"故事"，它必须先对这些工具做语义排序，才能开始解决用户的实际请求。工具调用可靠性正是在这一步开始崩塌的。

据OpenAI的函数调用指南，现在推荐用tool_search延迟加载不常用的工具，而不是把所有工具塞进单次请求中。Anthropic的工具使用文档也明确指出，Claude基于用户请求和工具描述来选择工具，推荐好的描述和input_examples。表面看这是提示词编写问题，实质上主要是边界设计问题。如果两个工具的描述存在重叠，模型就只能猜测你想要哪个。

语义碰撞可以理解为：多个工具的描述在嵌入空间中彼此接近，模型难以仅凭描述稳定地区分它们。LLM 在决定调用哪个工具时，本质上是在给定对话上下文后对候选工具做条件概率排序。当工具描述共享大量词汇（如 customer、account、search），它们的概率分布就会高度重叠，模型只能依赖细微差异或随机性来抉择。这种现象与信息检索中的“查询-文档歧义”类似：查询越模糊、文档越相似，排序越不稳定。工程上的应对策略是主动拉开工具之间的语义距离，而不是期望模型自动学会区分。

工具越多，Agent变笨得越快

一旦工具数量超过某个临界点，模型在开始执行任务之前，就得先做一轮语义排序。这在token消耗上很昂贵，在行为上很脆弱，而且很难用提示词文本来修补。

OpenAI较新的Agents构建模块将这一点更加正式化了，但大多数团队是在生产环境中以"令人恼火的方式"学到这一课的：运行时工具选择优于前端全量加载。现在有用的问题不再是"如何让提示词更聪明"，而是"如何缩小决策面"。

原文对比了三种方案的表现：

方案	实际表现
OpenAI function tools	JSON Schema定义函数，strict: true保证schema遵从，tool_search延迟加载少用工具
Anthropic client tools	name、description、input_schema，可选input_examples、defer_loading和disable_parallel_tool_use
纯提示词消歧	无硬性约束，仅靠指令，随工具数量和重叠度增加而恶化

作者的判断很直接：纯提示词消歧适合演示，不适合真实自动化。如果你的n8n、Make、Zapier或自定义Agent流程在生产环境中触及Slack、HubSpot和Notion，你需要的是契约，不是感觉。

**延迟加载（deferred loading）**指不在首轮请求中暴露全部工具定义，而是先让模型通过一个元工具（如 OpenAI 的 tool_search）检索或声明所需能力，再由运行时动态注入相关工具 schema。这样做有两个好处：一是减少单次请求中的候选工具数量，直接缩小决策面；二是节省 token，因为工具定义本身会占用可观的上下文长度。Anthropic 的 defer_loading 模式思路类似，但通过工具注册和加载策略控制暴露时机。延迟加载并非万能，它把“选工具”问题部分转化为“检索工具”问题，仍要求工具描述具备良好的可检索性。

小schema胜过聪明提示词

文档中那些无聊的天气工具示例其实是很好的范例。它们为什么有效？因为足够窄。一个必填字段，也许一个枚举，意图清晰，几乎没有即兴发挥的空间。

以OpenAI风格的天气工具为例：get_weather只需要一个location参数，描述为"城市和州，例如San Francisco, CA"，加上strict: true。Anthropic风格则在此基础上多一个unit枚举字段（celsius或fahrenheit），可选但边界清晰。

这就是整个技巧的缩影：窄工具更容易选择，也更难被误用。

实际修复的五步操作

作者给出了一个可复用的修复顺序，按优先级排列：

1. 从同一轮次中移除重叠工具

如果多个工具能回答基本相同的请求，不要同时暴露它们。先做路由，再只暴露相关子集。用OpenAI的tool_search或等效的运行时加载模式；用Anthropic则依靠defer_loading模式和更严格的工具注册。

2. 重命名工具，让它们听起来互斥

工具名称不是装饰，它是接口的一部分。customer_lookup_v2、record_search、account_tool这样的命名毫无区分度。更好的做法是get_customer_billing_status、read_customer_support_notes、find_recent_slack_thread_for_customer——这些名称创造了分离感。

3. 通过增加对比度来缩短描述

长描述只有在定义边界时才有用。"检索客户信息、账户历史、支持上下文、消息、记录和相关更新"这种描述是在制造混淆。更好的写法是："仅用于从HubSpot获取账单状态。不要用于支持备注、Slack历史或内部CRM记录。"后者给模型一个更干净的决策。

4. 严格约束参数

使用枚举，谨慎使用必填字段，避免巨大的自由格式对象。customer、options、mode三个自由对象字段的schema是灾难；customer_id加上source枚举（hubspot或internal_crm）的schema才是正解。

5. 副作用场景关闭并行工具调用

如果一个工作流能发Slack消息、更新HubSpot、写入Notion，并行工具调用不总是特性，有时只是更快地制造清理工作。Anthropic风格的控制方式是设置disable_parallel_tool_use: true。作者认为这个设置被低估了——一个干净的动作永远胜过三个半对的动作。

并行工具调用允许模型在单轮回复中同时发起多个函数调用，从而降低往返延迟。但在有副作用的场景中，并行会引入竞态与一致性问题：例如同时更新 HubSpot 和写入 Notion，若其中一个失败，系统就处于部分完成状态，需要补偿逻辑。更隐蔽的风险是模型基于不完整信息同时决策，导致动作之间相互冲突。禁用并行调用相当于强制串行化，让每一步的结果成为下一步的输入，牺牲吞吐换取可预测性。对于可并行的只读查询，仍可保留并行以优化延迟。

一个隐蔽的失败模式：更好的描述反而让选择更糟

这一点让很多团队栽跟头。你改进了每个工具的描述，添加了更多细节和上下文，感觉不错。然后工具选择依然很烂。

原因在于：你让每个描述在同一种词汇体系里变得更丰富了。现在五个工具都提到customer、account、support、history、messages、updates。描述写得更好，但语义也变得更相似，这反而让选择更难而非更容易。

修复的关键是对比度。一个好的工具描述应该说明四件事：这个工具做什么、什么时候用、什么时候不用、应该用哪个邻近工具代替。最后一点比大多数人意识到的更重要。

提示词仍然重要，只是不负责这件事

这不是反对提示词，而是反对用提示词来弥补草率的工具设计。作者现在的分工是：提示词负责策略——比如"未经经理批准不得退款"、"晚上9点后不得联系客户"、"删除Notion页面前需确认"；schema和工具边界负责行为——比如枚举值、必填字段、互斥工具、高风险操作每轮只允许一个工具。

如果混淆这两者，你就会写一份900词的提示词去解决一个9行schema就能解决的问题。

生产环境中的代价

三个工具的小演示可以靠感觉存活，真实工作流不行。当工作流触及Slack、Notion、HubSpot、Discord、内部API和客户数据时，工具歧义会变成运营问题。而且如果按token付费，模型在五个重叠函数之间做决策所消耗的周期会很快变得昂贵。

原文作者提到，对于持续迭代Agent行为、测试工具schema和运行自动化的场景，Standard Compute的固定费率API访问模式比每次调试都担心token消耗要轻松得多。如果技术栈已经兼容OpenAI API，切换成本不高。

核心结论

当LLM工具调用开始失败时，大多数人的反应是增加：更多提示词、更多示例、更多回退逻辑、更多工具。但杠杆率最高的修复往往是减法：更少的活跃工具、更少的重叠描述、更少的可选字段、更少的并行副作用机会。

如果你发现Agent总是选错工具，在写下另外500个token的提示词之前，先试着删掉一半工具箱。你可能在解决的是模型的界面问题，而不是智能问题。