1. 从能聊天到能干活工具使用与函数调用到底在解决什么问题大模型刚火起来那阵子大家最直观的体验就是能聊。你问它答写诗写文案写代码样样都行。但真把它扔进一个实际业务里问题马上就来了它知道今天天气吗它能帮你查数据库里那条订单的状态吗它能替你发一封邮件、下一笔单、调一次接口吗答案是不能。因为模型本身只是一个语言函数输入文本、输出文本它的知识截止在训练数据的那一天它没有手也没有脚碰不到外部世界。工具使用Tool Use与函数调用Function Calling这一整套机制就是给模型装上手和脚的关键。它的核心思想非常朴素模型不直接执行任何外部操作它只负责决定该调用哪个工具、传什么参数真正的执行交给外部程序。模型输出一段结构化的调用意图外部系统解析后去执行再把结果喂回给模型模型基于结果继续推理或生成最终回答。这个模型决策 外部执行 结果回灌的闭环就是整个智能体Agent体系的地基。我为什么特别看重这一讲的内容因为在我自己做过的好几个项目里从纯对话机器人升级到能真正完成任务的助手卡点几乎都在这。很多人以为接个 API 就完事了实际上工具描述怎么写、参数 schema 怎么设计、多轮调用怎么串、错误怎么兜底、模型幻觉调用怎么防每一步都有坑。这一讲要解决的就是把这些工程细节讲透让你不只是知道有函数调用这回事而是能真正落地一套稳定的工具调用系统。这篇文章适合三类人看一是正在做 AI 应用、想把大模型接入自己业务系统的开发者二是对 Agent 架构感兴趣、想搞清楚底层机制的技术爱好者三是已经用过函数调用但总踩坑、想系统梳理一遍的实践者。我会从设计思路、核心机制、实操落地到问题排查一层层拆开讲尽量做到你看完就能照着搭一个能跑的东西出来。2. 整体设计思路为什么是模型决策 外部执行这套架构2.1 为什么不让模型直接执行先想一个最直接的问题既然模型能生成代码为什么不干脆让它生成一段 Python 然后直接跑这样不就什么都能干了这个思路听起来很美但工程上基本不可行原因有三。第一是安全。模型生成的代码你无法完全预测它可能删库、可能发起恶意请求、可能陷入死循环烧光你的资源。你不可能把生产环境的执行权限交给一个概率模型。第二是可控性。生成代码是开放式的你没法在中间做权限校验、参数校验、审计日志。而函数调用是封闭式的模型只能从你预先注册的工具列表里选参数必须符合你定义的 schema这就把自由度关进了一个可控的笼子里。第三是稳定性。让模型每次生成一段能正确运行的代码成功率远低于让它填一个结构化参数。所以这套架构的本质是一次职责分离模型负责理解意图和决策外部程序负责执行和兜底。模型永远不碰真实世界它只输出一个我想调用 get_weather参数是 city北京这样的结构化意图。这个设计把不可控的概率模型约束成了一个可控的决策组件。2.2 工具描述模型能不能选对工具全看这段文字很多人第一次写函数调用最容易被忽略的就是工具描述tool description。他们觉得这就是个注释随便写写。但实际上模型选不选得对工具、传不传得对参数几乎完全取决于这段描述的质量。模型在做工具选择时看到的只有你提供的工具名称、描述和参数 schema。它没有你的代码不知道这个函数内部干了什么。所以描述必须回答三个问题这个工具是干什么的、什么时候该用它、每个参数是什么意思。我见过太多失败案例工具名叫func1、func2描述写处理数据模型根本不知道该在什么场景下调用它结果要么不调用要么乱调用。一个实用的经验是把工具描述当成写给一个刚入职、完全不了解你系统的同事看的说明书。你要告诉他这个工具解决什么问题、输入输出是什么、有什么边界条件。描述里最好包含一两个使用场景的例子比如当用户询问某地天气时使用此工具。这样模型在意图匹配时命中率会高很多。2.3 参数 schema结构化输出的契约参数 schema 通常用 JSON Schema 来描述它定义了每个参数的名字、类型、是否必填、取值范围、描述。这是模型和外部程序之间的契约。模型按这个契约生成参数外部程序按这个契约校验参数。这里有个关键点schema 越严格模型出错的空间越小。比如一个参数只能是摄氏度或华氏度你就用 enum 把它限定死而不是让模型自由发挥。再比如日期格式你明确写YYYY-MM-DD比让它自己猜格式要稳得多。我个人的习惯是凡是能用枚举限定的绝不用自由字符串凡是能加格式说明的一定写清楚。这看起来是小事但能显著降低参数解析失败率。2.4 多轮调用一次不够就再来一次真实任务往往不是一次调用能搞定的。用户问帮我看看北京和上海今天哪个更热这就需要调用两次天气工具然后比较结果。用户问帮我订一张明天从北京到上海、时间最早的票可能需要先查车次、再筛选、再下单是一串调用。这套架构天然支持多轮模型第一次输出调用意图外部执行后把结果作为一条新消息追加到对话历史里模型看到结果后决定是继续调用下一个工具还是给出最终回答。这个循环会一直持续到模型不再请求调用工具为止。理解这个循环是理解 Agent 的关键后面我会详细拆解每一轮发生了什么。3. 核心机制拆解一次函数调用到底经历了什么3.1 完整调用链的六个阶段我把一次完整的函数调用拆成六个阶段这样你在排查问题时能快速定位是哪一环出了岔子。第一阶段是工具注册。你在发起请求时把可用的工具列表名称、描述、参数 schema一并传给模型。这个列表就是模型的工具箱它只能从这里选。第二阶段是意图识别与工具选择。模型读完用户输入和对话历史判断是否需要调用工具、调用哪个。如果不需要它直接生成文本回答流程结束。第三阶段是参数生成。模型根据选中的工具的 schema生成符合格式的参数。这一步输出的是结构化的 JSON不是自然语言。第四阶段是外部执行。你的程序解析模型返回的调用请求校验参数然后真正去执行——查数据库、调 API、读文件随便什么。执行结果通常也格式化成 JSON。第五阶段是结果回灌。你把执行结果作为一条特殊角色的消息通常是 tool 角色追加到对话历史再次发给模型。第六阶段是继续推理或收尾。模型看到工具返回的结果判断任务是否完成。没完成就继续下一轮调用完成了就生成面向用户的最终回答。这六个阶段里模型只负责第二、三、六阶段其余都是你的程序在干。搞清楚这个分工你就知道哪些问题该找模型比如选错工具哪些问题该找自己比如参数校验失败、执行报错。3.2 模型是怎么决定调用工具的这里要破除一个常见误解模型并不是真的在运行你的函数它只是在生成一段符合特定格式的文本。这段文本恰好描述了我要调用某个工具、参数是什么。所谓函数调用能力本质上是模型被训练成能稳定输出这种结构化格式。理解这一点很重要因为它解释了为什么模型会幻觉调用——它可能生成一个你根本没注册的工具名或者生成不符合 schema 的参数。它不是故意的它只是在按概率生成文本偶尔会跑偏。所以外部程序必须做严格的校验不能盲信模型的输出。那模型是怎么学会选工具的训练时模型见过大量用户请求 工具列表 正确调用的样本它学会了把用户意图和工具描述做语义匹配。所以工具描述写得越贴近真实使用场景匹配就越准。这也是为什么我一直强调描述质量——它直接决定了模型的决策质量。3.3 并行调用与串行调用有些场景下多个工具调用之间没有依赖关系可以并行。比如前面说的比较北京和上海天气两次查询互不依赖模型可以一次性输出两个调用请求你的程序并行执行再一起回灌。这能显著降低延迟。而有些场景必须串行。比如先查用户 ID再用 ID 查订单第二步依赖第一步的结果只能一轮一轮来。模型会根据任务结构自己决定是并行还是串行但你在设计工具时要有意识尽量让工具之间解耦能并行的就别设计成强依赖这样整体效率更高。我踩过的一个坑是早期设计工具时我把查用户信息和查用户订单合并成了一个大工具结果模型每次都要一次性拿全部信息既慢又浪费。后来拆成两个独立工具模型按需调用灵活多了。工具粒度设计是个平衡活太粗不灵活太细调用轮次多一般建议按单一职责来拆。3.4 结果回灌的格式设计工具执行完的结果怎么回灌也是有讲究的。最省事的做法是把结果原样 JSON 塞回去但这样模型可能读不懂或者抓不住重点。更好的做法是对结果做一次轻量整理只保留模型决策需要的关键字段并且用清晰的键名。举个例子你查天气 API 返回了一大坨数据包含气压、湿度、紫外线、能见度等等。如果用户只问温度你把整坨塞回去模型可能被干扰。你可以只回灌{city: 北京, temperature: 25, unit: 摄氏度}干净利落。当然如果任务本身需要多字段那就都保留。原则是回灌给模型的信息要服务于它下一步的决策。另外工具执行失败时不要直接抛异常中断流程而是把错误信息也作为一种结果回灌给模型比如{error: 城市名无法识别请确认城市名称}。模型看到错误后往往能自己纠正比如换个城市名重试或者向用户澄清。这比直接报错给用户体验好得多。4. 实操落地从零搭一个能用的工具调用系统4.1 环境与依赖准备我以一个通用的 Python 环境为例讲一套最小可运行的实现。你需要的东西不多一个能调用大模型 API 的 SDK、一个 HTTP 库用来做外部请求、再加一个 JSON 处理。核心依赖大致是这些pip install openai requests pydantic这里openai只是举例任何支持函数调用的模型 SDK 都行接口形态大同小异。pydantic用来做参数校验比手写 if-else 靠谱得多。requests用来在工具内部发起真实请求。环境准备好之后整个系统的骨架其实就三块工具定义、模型调用循环、工具执行器。下面我一块块拆。4.2 定义你的第一个工具工具定义包含两部分给模型看的 schema和真正执行的函数。我习惯把两者放在一起管理避免描述和实现脱节。# 给模型看的工具描述 weather_tool_schema { type: function, function: { name: get_weather, description: 查询指定城市的当前天气。当用户询问某地天气、温度、是否下雨时使用此工具。, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认摄氏度 } }, required: [city] } } }注意几个细节。description里我明确写了当用户询问某地天气时使用这是给模型的触发提示。unit用 enum 限定避免模型自由发挥。required只列了city因为单位可以默认。对应的执行函数def get_weather(city: str, unit: str celsius) - dict: # 真实场景这里调用天气 API这里用模拟数据演示 mock_data { 北京: {temp_c: 25, condition: 晴}, 上海: {temp_c: 28, condition: 多云}, } if city not in mock_data: return {error: f未找到城市 {city} 的天气数据} data mock_data[city] temp data[temp_c] if unit celsius else data[temp_c] * 9 / 5 32 return {city: city, temperature: round(temp, 1), unit: unit, condition: data[condition]}执行函数返回的永远是结构化字典成功有成功的结构失败有失败的结构绝不抛异常出去。这是保证循环不中断的关键。4.3 核心调用循环的实现这是整个系统的心脏。我用伪代码把逻辑讲清楚你换成自己用的 SDK 就能跑。def run_agent(user_input, tools_schema, tool_map, max_turns5): messages [{role: user, content: user_input}] for turn in range(max_turns): response call_model(messages, toolstools_schema) msg response.choices[0].message # 模型没有请求调用工具直接返回文本 if not msg.tool_calls: return msg.content # 把模型的调用意图加入历史 messages.append(msg) # 逐个执行工具 for call in msg.tool_calls: name call.function.name args json.loads(call.function.arguments) if name not in tool_map: result {error: f未知工具 {name}} else: try: result tool_map[name](**args) except Exception as e: result {error: str(e)} messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result, ensure_asciiFalse) }) return 任务轮次超限请简化你的请求这段代码有几个关键设计。max_turns是防死循环的保险丝防止模型陷入无限调用。工具执行用 try-except 包住任何异常都转成错误结果回灌而不是让程序崩溃。未知工具名也做了兜底因为模型确实可能幻觉出一个不存在的工具。tool_call_id必须原样带回这是模型用来对应哪个结果属于哪次调用的标识漏了会出问题。4.4 参数校验别盲信模型的输出模型生成的参数不一定符合你的 schema尤其是类型和格式。我强烈建议在执行前做一次校验。用 pydantic 可以写得很干净from pydantic import BaseModel, ValidationError class WeatherArgs(BaseModel): city: str unit: str celsius def safe_get_weather(raw_args: dict) - dict: try: args WeatherArgs(**raw_args) except ValidationError as e: return {error: f参数校验失败{e}} return get_weather(args.city, args.unit)这样即使模型传了个数字当城市名或者漏了必填参数你也能优雅地返回错误让模型重试而不是让程序炸掉。我实测下来加了这层校验之后因为参数问题导致的失败率能降一大截。4.5 一个完整的对话示例把上面的东西串起来跑一个真实场景。用户输入北京和上海今天哪个更热第一轮模型看到工具列表判断需要调用天气工具而且两个城市互不依赖于是并行输出两个调用请求get_weather(city北京)和get_weather(city上海)。你的程序并行执行拿到{temperature: 25}和{temperature: 28}回灌给模型。第二轮模型看到两个结果比较后生成最终回答上海今天更热28 摄氏度北京是 25 摄氏度。 任务完成循环结束。整个过程模型调用了两次工具你的程序执行了两次回灌了一次最终输出一次。这就是一个最小但完整的 Agent 工作流。你可以把工具换成查数据库、发邮件、下单逻辑完全一样。5. 常见问题与排查技巧实录5.1 模型不调用工具怎么办这是最高频的问题。用户明明问的是天气模型却自己编了个答案压根没调工具。原因通常有三个。第一工具描述没写清楚触发场景。如果描述只写查询天气模型可能觉得它自己也知道天气就不调了。改成当用户询问实时天气、温度、是否下雨时使用此工具不要凭记忆回答命中率会明显提升。第二系统提示词没强调要用工具。你可以在 system message 里加一句涉及实时数据、外部信息时必须调用工具获取不要凭训练数据回答。这句话对模型的行为约束很强。第三模型本身能力不足。有些小模型对函数调用的支持很弱这时候要么换模型要么用提示词工程硬凑比如让模型输出特定格式的 JSON你自己解析。我一般优先换支持函数调用的模型省事。5.2 参数传错或格式不对模型把日期写成明天而不是2024-06-01或者把数字写成字符串这类问题很常见。解决办法前面提过schema 里写清楚格式执行前做校验。另外在参数描述里给例子也很有效比如description: 日期格式 YYYY-MM-DD例如 2024-06-01。模型看到例子模仿的准确率会高很多。如果某个参数经常出错可以考虑在工具内部做容错解析。比如日期参数你写个函数把明天下周一这种相对表达转成绝对日期。这比指望模型每次都输出标准格式要稳。5.3 工具执行超时或报错外部 API 挂了、数据库连不上、网络抖动这些都会导致工具执行失败。核心原则是任何失败都要转成结构化错误回灌给模型绝不中断循环。模型看到错误后可能会重试、换个参数、或者告诉用户暂时查不到。但要注意如果同一个工具连续失败多次别让模型无限重试。你可以在回灌的错误信息里加上已重试多次仍失败请告知用户稍后再试引导模型收尾。或者在循环层面加个计数器同一工具失败超过 N 次就强制结束。5.4 模型陷入无限调用偶尔模型会陷入调用-看到结果-再调用-再看到结果的死循环尤其是任务描述模糊的时候。max_turns是必须的保险丝一般设 5 到 10 轮足够。超过就强制返回一个兜底回答。另外检查你的工具描述是不是有歧义导致模型反复确认。我遇到过一次工具描述里写了如果不确定可以再次调用确认结果模型真的反复调用删掉那句话就好了。5.5 常见问题速查表问题现象可能原因排查方向模型不调用工具描述不清、提示词没约束、模型能力弱补触发场景、加系统提示、换模型参数格式错误schema 不严、缺示例加 enum、加格式示例、执行前校验工具执行报错外部依赖问题错误结构化回灌、加重试上限无限调用任务模糊、描述有歧义设 max_turns、清理描述结果模型读不懂回灌数据太杂精简字段、清晰键名调用错工具工具之间描述太像差异化描述、明确各自场景5.6 几条踩坑心得第一条工具宁少勿滥。一开始别注册一大堆工具模型选择困难错误率反而高。先把核心的几个做扎实按需扩展。第二条描述里写不要做什么和写要做什么一样重要。比如此工具仅查询天气不处理订票能防止模型误用。第三条日志一定要打全。每次调用的工具名、参数、返回结果、耗时都记下来。出问题时这些日志是你唯一的线索。我习惯把每轮对话的完整 messages 也存下来复盘时特别有用。第四条先在沙箱里测。工具涉及写操作下单、发邮件、改数据时一定要有测试环境别拿生产数据练手。模型偶尔会做出你意想不到的调用沙箱能救命。6. 工具调用的边界与进阶方向6.1 什么任务适合交给工具调用不是所有任务都适合。工具调用擅长的是需要外部实时数据、需要执行具体操作、需要精确计算的场景。比如查实时信息、操作数据库、调用第三方服务、做复杂数学运算。而纯文本生成、创意写作、逻辑推理这类模型自己就能干硬套工具反而累赘。判断标准很简单这个任务需要模型知道它训练时不可能知道的东西或者需要它做它物理上做不到的事吗是就用工具否就别用。6.2 安全边界必须守住工具调用给了模型动手的能力也就带来了风险。几条底线必须守写操作要有确认机制尤其是涉及资金、删除、发送的操作最好让用户二次确认权限要最小化工具能访问的数据范围要严格限定敏感操作要审计谁在什么时候调了什么工具、传了什么参数都要留痕。我见过一个反面案例某系统把删除用户做成了工具模型在一次对话里误判意图直接把用户删了。后来加了二次确认才解决。这类教训很贵别自己再交一遍学费。6.3 从单工具到多工具编排当你有了十几个工具之后新的挑战来了模型怎么在这么多工具里选对这时候可以考虑工具分组按业务域把工具分到不同类别先让模型选类别再选具体工具。或者用路由层先用一个轻量模型判断意图属于哪个域再把对应域的工具列表给主模型。这些是进阶技巧等你的工具数量上来了再考虑。再往上是多智能体协作每个智能体负责一组工具互相调用。这就进入更复杂的 Agent 架构了但底层还是本文讲的这套决策-执行-回灌循环只是套了几层。把单工具调用吃透往上走就是水到渠成的事。6.4 我个人的一点体会做工具调用这段时间我最大的感受是这套系统的上限取决于你对业务的理解深度而不是模型有多强。工具怎么拆、描述怎么写、错误怎么兜底这些全是业务和工程的活。模型只是个决策组件你把它的输入输出设计好了它就稳设计得含糊再强的模型也救不了。另一个体会是别追求一步到位。先搭一个能跑的最小闭环哪怕只有一个工具跑通了再慢慢加。我见过太多人一上来就想搞个全能 Agent结果卡在工具描述和参数校验上连第一个工具都没跑通就放弃了。小步快跑边跑边调才是正道。最后分享一个我常用的小技巧给每个工具写一个反例就是明确告诉模型什么情况下不要用这个工具。这招在工具之间功能相近时特别管用能显著降低误调用率。你可以试试效果比想象中好。