大模型函数调用实战：从工具描述到多轮调用的工程指南

1. 从"能聊"到"能干活"：工具使用到底解决了什么问题

大模型刚火起来那阵子，大家最兴奋的是它能写诗、能编故事、能陪你聊天。但真把它往业务里塞的时候，问题马上就来了：你问它"今天北京天气怎么样"，它要么一本正经地编一个温度，要么告诉你"我的知识截止到某年某月，无法获取实时信息"。你让它帮你订张机票，它只能给你写一段"订票流程说明"，然后就没有然后了。

这个落差的核心，在于大模型本质上是一个封闭的语言模型——它的全部能力来自训练时见过的数据，它没法主动去查、去算、去操作外部世界。而工具使用（Tool Use）和函数调用（Function Calling）要解决的，正是这个"最后一公里"的问题：让模型从"只会说"变成"能动手"。

我打个比方。模型本身像一个知识渊博但被关在房间里的人，他读过很多书，能跟你聊任何话题，但他看不到窗外、打不了电话、也碰不到任何实物。函数调用就是给他开了一扇窗、递了一部电话——他依然靠自己的判断力决定"我现在需要查天气"，但真正去查这个动作，是交给外面的工具完成的。

这一讲的核心，就是讲清楚这套机制怎么运转、为什么这么设计、以及在实际工程里怎么把它用稳。不管你是做智能客服、做数据分析助手、还是做自动化工作流，只要涉及"让模型调用外部能力"，这一讲的内容你都会反复用到。我会尽量把原理讲透，同时把实操中容易踩的坑一并说清楚，让刚接触的读者能上手，也让已经用过的人能补上之前没想明白的地方。

2. 函数调用的完整链路：模型到底"调"了什么

2.1 一个常见的误解：模型并没有真的执行函数

很多人第一次听到"函数调用"这个词，会以为模型内部真的去执行了某个函数。不是的。模型做的事情只有一件：它输出了一段结构化的文本，这段文本描述了"我想调用哪个函数、传什么参数"。真正执行函数的，是你自己的代码。

这个认知非常关键，因为后面所有的工程细节都从这里推导出来。整个链路大致是这样的：

1. 你（开发者）把一组可用工具的描述（函数名、功能说明、参数结构）随对话一起发给模型。
2. 模型读完用户的问题，判断"这个问题需要调用某个工具"，于是不再输出自然语言回答，而是输出一段符合约定格式的调用请求，比如函数名加参数。
3. 你的程序解析这段请求，找到对应的真实函数，执行它，拿到结果。
4. 你把执行结果作为一条新消息，再发回给模型。
5. 模型结合这个结果，生成最终给用户的自然语言回答。

所以模型扮演的是"决策者"和"调度者"，你的代码扮演的是"执行者"。模型负责想"该干什么"，你的程序负责"真的去干"。

2.2 为什么要把工具描述塞进上下文

你可能会问：模型怎么知道有哪些工具可用？答案就是你把工具的描述写进了发给它的上下文里。这带来一个直接后果——工具描述本身会占用 token。

我见过不少项目，一口气注册了三四十个工具，每个工具的描述写得又长又详细，结果光工具定义就吃掉好几千 token，还没开始聊正事，上下文就快满了。更麻烦的是，工具太多、描述太相似时，模型的选择准确率会明显下降，它会在几个长得差不多的工具之间反复犹豫，甚至选错。

这里有个经验：工具数量控制在十个以内，每个工具的描述聚焦"什么时候用它"，而不是"它内部怎么实现"。模型不需要知道你的函数是用什么语言写的、内部调了哪个接口，它只需要知道"遇到什么情况该选我"。描述写得好，选择准确率能差出一大截。

2.3 参数结构为什么必须严格定义

函数调用的参数不是随便传的，它通常遵循一套结构化的模式定义（类似 JSON Schema 的思路）。你要明确告诉模型：这个函数需要哪些参数、每个参数是什么类型、哪些是必填、哪些可选、取值范围是什么。

为什么要这么较真？因为模型输出的是文本，而文本是自由的。如果你不约束，它可能把数字写成字符串，把日期写成"下周三"这种人类能懂但程序没法直接用的表达。结构化定义相当于给模型画了一个框，让它在这个框里填内容，你的程序解析起来才稳。

我踩过的一个坑：早期有个工具需要传时间戳，我没在定义里写清楚格式，结果模型有时候传秒级、有时候传毫秒级，程序里判断逻辑直接崩了。后来我在参数描述里明确写了"Unix 时间戳，单位为秒，10 位整数"，问题才消失。参数描述里的每一个字，都是在帮模型减少犯错的空间。

3. 工具描述怎么写，模型才不容易选错

3.1 描述是给模型看的"使用说明书"

工具描述写得好不好，直接决定模型选得对不对。这件事的重要性，怎么强调都不过分。我见过太多项目把工具描述当成注释随便写两句，然后抱怨"模型怎么老是调错工具"——问题往往就出在描述上。

好的工具描述应该回答三个问题：这个工具是干什么的、什么情况下应该用它、什么情况下不该用它。第三个问题最容易被忽略，但恰恰最能减少误用。比如你有一个"查询订单状态"的工具，如果只写"查询订单"，模型可能在用户问"我要退货"的时候也去调它。但如果你补一句"仅用于查询订单当前状态，不处理退换货请求"，误调率会明显下降。

3.2 命名要让人一眼看懂意图

函数名本身也是描述的一部分。get_data这种名字，模型看了完全不知道是查什么数据。get_user_order_status就清楚多了。命名原则很简单：动词加名词，具体到能区分同类工具。

如果你有两个功能相近的工具，命名上一定要拉开差距。比如"查询物流"和"查询订单"，如果都叫query_info，模型基本靠猜。改成query_logistics_tracking和query_order_detail，区分度立刻就出来了。

3.3 用对比表理清工具边界

当工具数量多起来，我习惯做一张边界对照表，把每个工具的"适用场景"和"不适用场景"列清楚。这张表一方面是给自己梳理逻辑，另一方面它的内容可以直接转化成工具描述。

这张表看起来简单，但它逼着你想清楚每个工具的职责边界。边界清晰了，描述自然就清晰，模型的选择也就稳了。

3.4 一个反直觉的经验：工具不是越多越好

新手容易有一种冲动：既然模型能调工具，那我把它可能用到的所有能力都注册进去，不就万能了？实际恰恰相反。工具越多，模型的决策负担越重，选错的概率越高，而且上下文被工具定义挤占，留给真正对话的空间就越少。

我的做法是按场景分组，动态加载。比如一个客服助手，在"售前咨询"阶段只加载商品查询类工具，进入"售后"阶段再切换到订单和退换货工具。这样每一轮模型面对的工具集都很小、很聚焦，选择准确率自然高。这个思路在工程上叫"工具的动态裁剪"，是让复杂系统保持稳定的关键手段之一。

4. 多轮调用与错误处理：真实场景远比 Demo 复杂

4.1 一次调用搞不定的事，怎么串起来

Demo 里最常见的场景是"用户问一句，模型调一个工具，返回答案"，干净利落。但真实业务里，一个需求往往需要多个工具接力。比如用户说"帮我看看我上周买的那本书到哪了"，模型得先调"查询用户最近订单"拿到订单号，再调"查询物流"拿到物流状态，最后组织语言回答。

这就涉及多轮工具调用：模型调完一个工具，拿到结果后，可能发现还需要再调另一个，于是发起第二次调用。你的程序要能支持这种循环——执行、回传、再判断、再执行，直到模型认为信息够了，输出最终回答。

这里有个必须设的保险：最大调用轮数。如果不限制，模型有可能陷入"调了发现不对、再调、还不对"的死循环，既烧钱又拖慢响应。我一般设 5 到 8 轮封顶，超过就强制让它基于已有信息作答，或者直接返回一个兜底提示。

4.2 工具执行失败了，模型该怎么知道

工具调用不可能永远成功。接口超时、参数非法、权限不足、返回空结果，这些都会发生。关键在于：失败信息要以模型能理解的方式回传给它，而不是让你的程序直接抛异常崩掉。

我的做法是把执行结果统一包装成一个结构，里面包含"是否成功""结果数据""错误说明"三个部分。失败时，错误说明要写得让模型能据此决策。比如"订单号格式不正确，应为 12 位数字"，模型看到后可能会去问用户重新提供，而不是干等着。

注意：不要把原始的技术堆栈信息直接丢给模型，它看不懂也没法处理。错误信息要翻译成业务语言，比如把"500 Internal Server Error"转成"订单服务暂时不可用，请稍后重试"。

4.3 参数校验要在执行前做

模型生成的参数不一定合法。它可能漏填必填项、类型填错、或者填一个超出范围的值。在执行真实函数之前，一定要做一层参数校验。校验不通过，就把具体的错误原因回传给模型，让它重新生成。

这一层校验看起来是额外工作，但它能挡掉大量脏数据，避免你的下游系统被非法参数搞崩。我一般会校验三件事：必填项是否齐全、类型是否匹配、取值是否在允许范围内。这三条覆盖了绝大多数问题。

4.4 超时与重试的边界

外部工具调用是有网络开销的，超时是常态。给每个工具设一个合理的超时时间，超时后不要无限重试。我的经验是：只读类操作可以重试一次，写操作（比如下单、发消息）绝不自动重试，否则可能造成重复下单、重复发送这种严重后果。

这个区分很重要。查询失败了重试一次没副作用，但"发送通知"这种操作，重试一次用户就收到两条，体验直接崩。写操作的重试必须交给上层逻辑判断，或者设计成幂等的。

5. 把工具调用做稳的几个工程习惯

5.1 给模型"思考"的空间，别逼它立刻调

有些实现为了追求速度，逼着模型在第一时间就决定调不调工具。但复杂问题往往需要模型先理一理思路。现在不少模型支持在输出调用请求前先输出一段推理过程，这段推理虽然不直接给用户看，但它能显著提升工具选择的准确率。

我的建议是：在系统提示里明确鼓励模型"先想清楚再动手"。比如告诉它"在决定调用工具前，先判断用户真正想要什么，再选择最合适的工具"。这一句话的改动，往往能带来肉眼可见的效果提升。

5.2 结果回传要精简，别把整个响应塞回去

工具返回的数据经常是一大坨 JSON，里面字段一大堆，但模型真正需要的可能就两三个。如果你把原始响应整个塞回上下文，既浪费 token，又可能干扰模型判断。

我习惯在回传前做一层结果裁剪：只保留模型决策需要的字段，把无关的元数据、调试信息、冗余结构都去掉。比如查询订单返回了二十个字段，但回答"到哪了"只需要物流状态和预计到达时间，那就只回传这两个。上下文干净了，模型的表现也更稳定。

5.3 日志要记全，方便复盘

工具调用出问题时，最怕的就是"不知道当时发生了什么"。所以每一次调用，我都要求记录完整链路：模型为什么决定调这个工具、传了什么参数、工具返回了什么、模型最终怎么回答的。

这些日志在排查问题时价值极高。比如你发现模型老是选错工具，翻日志一看，原来是某两个工具的描述太像了；或者发现某个参数老是被填错，一看日志，原来是描述里没写清楚格式。没有日志，你只能靠猜；有了日志，问题基本都能定位。

5.4 用真实对话反复测试，别只测理想情况

工具调用的测试，不能只测"用户规规矩矩提问"的情况。真实用户会说得含糊、会打错字、会一次问好几件事、会在对话中途改主意。这些情况才是模型最容易翻车的地方。

我的测试习惯是准备一批"刁钻"的对话样本：模糊的、多意图的、前后矛盾的、带错别字的。拿这些去跑，看模型的选择和执行是否还稳。每次调整工具描述或系统提示后，都用这批样本回归一遍，确保没有把之前修好的问题又改回去。

6. 从这一讲能带走的东西

函数调用这套机制，表面上看是"让模型能调外部接口"，但真正吃透之后你会发现，它其实是一套让语言模型与真实世界协作的协议。模型负责理解和决策，工具负责执行和反馈，两者通过结构化的消息来回配合。理解了这条主线，很多具体问题就都有了判断依据。

我自己在做这类系统时，最大的体会是：稳定性不来自模型有多强，而来自你把边界划得有多清楚。工具描述写清楚边界，参数定义写清楚约束，错误处理写清楚兜底，调用轮数设好上限——这些看起来琐碎的工程细节，才是让系统真正能上线的关键。模型再聪明，也架不住你给它一堆含糊不清的工具和没有兜底的流程。

另外一个反复被验证的经验是：先做减法，再做加法。一开始别贪多，两三个核心工具跑通、跑稳，再逐步扩展。每加一个工具，都回头看看它和已有工具的边界是否清晰、描述是否会造成混淆。工具集的质量，永远比数量重要。

如果你正在做涉及工具调用的项目，建议先把这一讲的链路在纸上画一遍：用户输入、模型决策、参数生成、校验、执行、结果回传、最终回答，每一步的输入输出是什么、可能出什么错、怎么兜底。把这张图想清楚了，代码写起来会顺很多，上线后出的问题也会少很多。