让 AI 更好理解并调用工具：从“能调”到“调得对”的工程实践

多数团队在接入工具调用（Function Calling）后，很快会遇到一个尴尬的现实：模型确实“会”调工具了，但调得不准、调得太多、或者在不该调的时候乱调。问题的根源往往不在模型本身，而在于工具的定义方式和暴露策略。

让 AI 更好理解并调用工具，核心不是写更长的提示词，而是把工具当成一个面向模型的用户界面来设计。以下从定义、筛选、编排三个层面展开。

一、工具定义：让模型“看得懂”比“写得多”重要

模型决定是否调用一个工具，依据的只有工具的名称、描述和参数结构。这三样东西写得好不好，直接决定调用准确率。

函数名要自带语义。 get_user 和 fetch_customer_profile_by_id 对模型来说是两种清晰度。后者明确告诉模型：这个工具需要一个 ID，返回的是客户档案。OpenAI 官方建议函数名和参数描述必须“清晰且详细”，并明确说明每个参数的含义和格式。一个实用的检验标准是“实习生测试”：如果一个不了解你系统的人类仅凭工具定义就能正确使用它，模型大概率也能。

描述里写清楚“什么时候用”和“什么时候不用”。 很多工具定义只写了功能，没写边界。比如一个 search_documents 工具，如果描述只写“搜索文档”，模型可能在用户问“今天天气”时也去搜一下。更有效的写法是：“当用户询问公司内部政策、产品文档或历史存档时使用。不要用于实时数据查询或外部网页搜索。”微软的文档同样强调，应在系统提示中明确描述每个函数的使用时机和不使用时机。

参数结构要能防错。 如果一个工具同时接受 on: bool 和 off: bool，模型就可能构造出两个都为 true 的非法调用。用枚举和互斥的结构来约束模型，而不是指望它“自觉”。另外，不要把模型已经知道的信息再让它填一遍。如果上一步已经拿到了订单 ID，退款工具就不应该再要求模型传入 order_id，而应该在代码层把 ID 绑定好，让模型只负责触发。

保持工具单一职责。 一个小而专注的函数比一个“万能函数”更容易被模型正确理解和使用。微软的建议很直接：保持工具专注，小型、单一用途的函数更易于控制和测试。

二、工具暴露：别让模型在 50 个工具里做选择题

一个常见的误区是：既然模型支持工具调用，就把所有工具一次性全塞给它。结果是上下文被撑爆，模型的选择困难症也随之而来。

初始暴露的工具数量要克制。 OpenAI 的实践指南建议，在单轮对话开始时暴露的工具数量尽量控制在 20 个以下，尽管这只是一个软性建议。工具越多，模型在相似名称之间混淆的概率就越高，调用延迟也会因为更长的上下文而增加。

用动态发现代替全量硬编码。 当工具生态较大时，更好的方式是让模型按需搜索和加载工具。OpenAI 的 tool_search 机制允许模型先搜索相关工具，再将需要的工具加入上下文。模型上下文协议（MCP）则提供了更系统化的方案：工具集中托管在 MCP 服务器上，AI 代理在运行时动态发现可用工具，而不需要在代理代码中硬编码每一个工具。这意味着新增或更新工具时，不需要重新部署代理，代理始终能拿到最新版本的工具定义。

合并总是连续调用的工具。 如果 query_location 后面永远跟着 mark_location，就把标记逻辑直接并入查询函数里。让模型少做一步决策，就少一个出错的机会。

三、执行与反馈：模型负责决策，代码负责兜底

工具调用的完整链路是：模型发出调用请求 → 应用程序执行 → 结果返回模型 → 模型整合结果生成回答。这条链路里有几个容易被忽视的工程细节。

永远不要盲目信任模型传来的参数。 模型可能生成格式错误的参数、越权的 ID、或者不存在的枚举值。生产系统中必须在代码层对工具输入做校验和清洗。模型只负责“提议调用”，执行权在人手里。

错误信息要写给模型看。 当工具执行失败时，返回的错误信息不应该是给人类看的堆栈跟踪，而应该是模型能理解并据此调整的简短说明。比如返回 {"error": "location parameter must be a city name, not coordinates"}，模型下一轮就可能修正参数。微软将“返回清晰的错误输出，使模型能够推理”列为工具调用的最佳实践之一。

敏感操作需要显式授权。 对于退款、删除、发送通知等高影响操作，不应该让模型直接触发执行。可以在工具定义中标注风险等级，或者在代码层加入二次确认机制。日志记录同样关键：跟踪调用频率、延迟和失败率，既是调试需要，也是治理需要。

注意工具结果的格式和大小。 工具返回给模型的内容应该尽量简洁、结构化。OpenAI 建议将 JSON 对象序列化为字符串返回，同时注意结果大小限制（如 Agents API 中不超过 4 MiB）。一个返回了 10 万字符原始日志的工具，大概率会让模型在后续推理中“迷失”。

工具调用的可靠性，本质上是接口设计的可靠性。模型是一个能力很强但缺乏上下文的新用户，你的工具定义就是它的说明书和操作面板。说明书越清晰，面板越简洁，它调得就越准。当调用仍然出错时，先别急着换模型——回头看看工具的名字、描述和参数结构，答案往往就在那里。