大模型 Function Calling 实战指南：告别答非所问，打造真正的智能体

1. Function Calling 到底是什么为什么说它是大模型落地的拐点大概是从 2023 年年中开始OpenAI 在 API 里放出了 Function Calling 能力随后各大模型厂商跟进国内外的开源模型也陆续支持。到了今天如果你还在让大模型裸奔式地回答问题那真的是浪费了它最值钱的能力。先用大白话解释一下 Function Calling 是什么。过去我们调大模型就是给它一段 prompt它吐一段文本。想要它帮我们查天气、订机票、操作数据库根本没门它只能说得像那么回事但没法真正去执行。于是有了各种取巧方案先让模型输出 JSON再拿正则去解析或者让模型输出一段特定格式的指令再用额外逻辑去匹配。这些方案脆弱到令人崩溃稍微换个表述方式正则就废了。Function Calling 的做法完全不同你在请求 API 时除了正常的 prompt还可以传入一份工具清单清单里描述了这个工具叫什么、参数有哪些、每个参数是什么类型、作用是什么。模型看完用户的话和这份清单会自己判断这件事需要调用工具然后返回一个结构化的调用请求——包括工具名和参数比如{ name: get_weather, arguments: {\city\: \上海\} }你的后端拿到这个请求去真实调用天气 API拿到结果后再把结果回传给模型。模型结合工具返回的真实数据组织出最后的自然语言回答。这一来一回模型就从只会说变成了能干活。我打了这么个比方没有 Function Calling 的大模型像一个只会背书但不会翻书的图书管理员你问它书里写了什么它能凭印象给你编一段。有了 Function Calling它终于学会说等一下我去把书拿来翻一翻然后真的把书翻开找到关键段落再告诉你答案。这个翻书的动作就是调用工具。那为什么说这是落地拐点因为绝大多数真实的业务需求都绕不开数据获取和操作执行。无论你是做智能客服、Copilot、数据分析助手还是自动化流程模型都必须跟外部世界打交道。Function Calling 提供了一种标准化的协议让模型和外部系统之间能够对话。它解决的不只是答非所问的问题而是把大模型从一个文本生成器升级成了智能体Agent的核心大脑。2. 答非所问的根因模型没拿到工具意识现在回到标题的问题你的模型为什么答非所问这个问题我在不同项目里见过太多次了。大家的第一反应往往是模型不行prompt 没写好但实际上绝大多数情况是模型压根没意识到自己手里有工具可以用或者不知道该在什么时候用。先说第一种情况模型没有工具意识。你在接口里明明传了 tools 参数但模型就是不用一本正经地凭自己训练时的知识回答你的问题。比如你部署了一个私有化大模型接入了内部工单系统用户问帮我查一下工单 TICKET-2024-0081 的状态正常流程是模型应该调用 query_ticket 工具去查询但模型可能直接回答工单 TICKET-2024-0081 正在处理中。这明显是胡编的。模型根本没有查询能力它只是根据训练数据的统计规律觉得工单 处理中是一个高频搭配。导致这种问题的原因首批要排查的是这几项。模型本身是否原生支持 Function Calling。不是所有模型都支持尤其是一些开源模型虽然号称支持但实际效果差得远。像 Qwen2.5、GLM-4、DeepSeek 等主流开源模型对 Function Calling 的支持已经很成熟但一些小参数模型在这块的能力非常薄弱。tools 参数的格式必须符合模型的要求。每个模型的 tools 格式有细微差别有的要求用 JSON Schema 描述参数有的支持简化的格式。一旦格式不对模型可能直接忽略这些工具。系统提示词里有没有明确说明工具的用途和适用场景。模型需要知道每个工具是干什么的、什么时候该用它。很多人写系统提示词时只说你是一个智能助手而没有告诉模型它拥有哪些能力、应该在什么条件下使用。再说第二种情况模型有工具意识但用错了时机。举个很常见的例子。用户问今天天气怎么样你给模型提供了两个工具get_weather查天气和 send_email发邮件。如果模型调用了一个跟问题完全无关的工具返回了一个 email 参数列表那就是典型的工具选择失误。这种情况往往是 tools 描述不够清晰导致的。模型不知道 get_weather 是用来满足天气查询需求的或者 tools 列表太长、描述太泛模型在判断时出现了混淆。还有一个非常隐蔽的原因上下文污染。如果历史对话里出现了很多关于发邮件的内容模型可能会被带偏倾向于选择发邮件这个工具。在 Agent 场景里对话历史越长这种偏差越明显。所以当你的模型答非所问时不要急着换模型、调 prompt先系统性地排查上面这几个环节。我把这一整套排查思路整理成了一张检查表下一节直接给到。3. 一次典型的答非所问排查过程从现象到根因我不喜欢空谈理论直接分享一个实际项目里的排查过程。这个项目是一个企业内部的文档问答机器人接入了 Function Calling用来调用企业内部知识库的检索 API。现象是用户问帮我找一下《差旅报销制度》里关于住宿标准的规定机器人经常回答抱歉我暂时无法访问这份文档。但有时候又能正确回答。这种时好时坏的情况比完全不能用还要让人抓狂。第一步我先打开了调试日志看模型返回的原始响应。结果发现模型根本没有发起 Function Call而是直接生成了我暂时无法访问这句回复。这说明模型压根没觉得应该去调用工具。第二步我检查了 prompts 中 tools 的定义。工具定义大致是这样的{ type: function, function: { name: search_documents, description: 搜索企业内部知识库返回匹配的文档片段, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 } }, required: [query] } } }乍一看没问题但仔细一琢磨这段描述太模糊了。模型怎么知道帮我找一下《差旅报销制度》这种需求应该调用这个工具描述里没有提到文档制度查找这些关键词模型在语义匹配时可能不够确信。第三步我调整了工具描述改为当用户需要查询、检索、查找企业内部文档、制度、规范、公告等内容时使用此工具。搜索企业内部知识库返回相关文档片段并附上来源。同时我也在系统提示词里加了一句你是企业知识库助手。用户提问涉及企业文档、制度、规范时你应该先搜索知识库获取准确内容再基于搜索结果回答。不要凭空作答。改完之后大部分问题都能被正确触发了。但还有一种情况模型发起了 Function Call但传的参数是空的或者乱传参数。比如用户问报销住宿标准是多少模型调用 search_documents 时传的 query 是报销住宿标准而不是更精确的差旅报销制度 住宿标准。这虽然有瑕疵但搜索结果还是能兜住。从这次排查里我总结出一个关键认知Function Calling 不是一个纯 API 层面的功能它需要你在 prompt 层面教模型什么时候该用工具。工具描述写得好不好直接决定了模型能不能做出正确判断。还有一个容易被忽略的细节返回结果怎么喂给模型。正确流程是模型发起 Function Call - 你的代码执行真实工具 - 把工具结果作为一条 role 为 tool 的消息回传给模型 - 模型基于这个结果生成最终回答。很多人在这里会犯一个错误把工具结果直接拼接到之前的对话里或者用 system message 回传。这会导致模型无法正确区分哪些是工具返回的数据、哪些是对话历史轻则回答不够准确重则出现角色混乱、格式异常。下面是一个标准的回传格式以 OpenAI 接口为例{ role: tool, tool_call_id: call_abc123, content: 根据搜索结果差旅住宿标准为一线城市不超过500元/晚二线城市不超过350元/晚。 }注意这个tool_call_id它必须和模型发起 Function Call 时返回的 id 一致否则接口会报错。这看起来是个小细节但我在不少项目里见过因为 id 没对上而反复排查的。4. 让模型会调用的 prompt 设计技巧工具描述决定成败如果说 Function Calling 是一辆车prompt 里的工具描述就是方向盘。方向盘没装好车再能跑也白搭。工具描述的核心原则很简单让模型在读到用户问题时能第一时间匹配到正确的工具。怎么做到我总结了几条经过实战检验的规则。第一条描述里写清楚什么场景下用而不是只写这个工具能做什么。比如一个查天气的工具很多人会写获取天气信息。更好的写法是当用户询问当前天气、未来天气预报、气温、降水、风速等天气相关问题时使用此工具获取指定地点的天气数据。这样等于直接给了模型一个触发条件。模型在做意图判断时其实是语义匹配的过程描述越贴近用户的自然表达匹配越准确。第二条每个工具的职责要单一不要一个大而全。我见过一些团队图省事只定义一个工具叫execute_sql描述是执行 SQL 查询数据库。然后让模型自己生成 SQL 去查任何数据。这种设计不是不行但问题很多模型生成的 SQL 不够稳而且模型在判断该不该用这个工具时会犹豫因为查询这个概念太宽泛了。更好的做法是拆成多个细粒度的工具比如query_user_info(uid): 查询用户基本信息query_order_list(uid): 查询用户的订单列表query_order_detail(order_id): 查询单个订单的详细信息每个工具的描述都写清楚用途和参数含义模型的判断准确率会显著提升。第三条参数描述同样重要特别是参数的边界条件。如果你有一个send_email工具参数是recipient和content那么recipient的描述应该写明是收件人的完整邮箱地址格式必须为 xxxexample.comcontent的描述应该写明邮件正文内容纯文本格式。否则模型可能会把一个手机号作为收件人传进来。第四条利用 system prompt 兜底。工具描述写得再好也不如系统提示词里明确说一句你有以下工具可用请根据用户问题选择合适的工具。有些模型对 system prompt 的遵从度很高你甚至可以给出一个简单的决策流程当用户的问题涉及实时数据、操作执行、外部系统时必须调用工具。 调用工具时要确保所有必填参数都有有效值。 如果用户意图不明确可以先追问澄清而不是盲目调用工具。这一层行为指令和工具描述是互补关系。工具回答这个工具是干什么的指令回答你应该怎么选择和使用工具。第五条tools 列表不要过长优先保证质量。如果你一次性给模型塞 30 个工具模型在判断时容易出现混淆特别是工具之间功能相似的场景。我实测下来一次请求里 5 到 10 个工具是比较理想的范围。如果工具确实很多可以考虑先做一轮粗粒度分类用第一个工具来决定走哪个子流程再在子流程里用更精准的 tools 列表。5. 工具调用链路里的常见坑参数幻觉、多轮调用与循环陷阱Function Calling 看起来简单但真正把链路做稳定要处理的坑远比想象中多。我踩过的、帮别人排查过的挑几个典型案例拿出来说。第一个坑参数幻觉。大模型在调用函数时传的参数不是真实存在的而是它编出来的。比如用户说帮我查一下张三的订单模型调用query_order_list时传入的 uid 是zhangsan。但你的系统里 uid 是一串数字根本没有zhangsan这个用户。模型并不知道真实用户 id它只是根据用户提供的名字猜测了一个值。这个问题在 Agent 场景里尤其严重。模型的本质是概率生成你让它从上下文里提取参数它可能提取到错误的实体或者把同义词当作标准值。解法分几个层次。对于关键参数让模型在调用工具前先向用户澄清确认参数值。比如我需要先确认一下您的用户 ID您可以在个人中心页面查看。对于能通过其他方式反查的参数可以让模型先调用查询工具换取标准 ID再传参。比如模型先调用search_user_by_name(张三)拿到标准 uid再查订单。第二个坑多轮工具调用的编排。真实业务中很少是一次工具调用就能搞定的。比如帮我把张三最近一笔订单的发货地址改成新地址。这个流程涉及三步查用户、查订单、改地址。大模型需要连续发起多次工具调用每次拿到结果再决定下一步。好消息是目前主流的 Function Calling 协议支持多轮工具调用的循环模型先返回tool_calls你的程序依次执行把所有结果一次性回传给模型模型综合分析后再决定是继续调用还是给出最终回答。但坏消息是编排逻辑一旦写得不严谨很容易出现死循环。比如一个查询工具返回空结果时模型不知道该怎么处理只好再调用一次同一个工具反复几次后要么超时要么报错。我的建议是在编排层设置一个最大迭代次数一般是 4 到 6 次。超过这个次数直接中断返回一个兜底话术抱歉当前查询太复杂请换个方式描述您的需求。 另外工具返回空结果时你可以在返回内容里带上提示没有找到相关数据请确认查询条件是否正确或者尝试使用其他工具。第三个坑模型把不该调的工具也调了。有些需求明明可以直接回答不需要任何工具但模型仍然发起了一次工具调用。比如用户问1 加 1 等于几模型可能调用了一个计算器工具。这本身不算错误但会导致响应变慢、成本变高。怎么避免在 system prompt 里明确强调对于常识性问题、纯文本生成任务无需调用工具直接回答即可。 这个指令虽然简单但非常有效。第四个坑工具返回的数据太长导致上下文爆炸。企业知识库检索工具经常返回大段文档内容。如果直接把几千字的原文全部塞给模型不仅浪费 token还可能让模型抓不到重点最终的回答反而更差。解法是在工具侧做数据预处理只保留与查询相关的片段做摘要限制返回长度。我一般会控制在 500 到 1000 字以内并把关键结论放在最前面。模型的注意力机制对上下文开头和结尾的内容更敏感所以把答案放在开头是合理的。下面这张表总结了上述坑的触发场景、根因和应对方案坑点触发场景根因应对方案参数幻觉模型传入了不存在的实体 ID模型不知道真实 ID只能根据上下文猜测关键参数先向用户确认或先查询换取标准 ID多轮调用死循环工具返回空结果模型不知道如何处理空结果设置最大迭代次数空结果时返回引导性提示误调工具常识问题也触发工具调用模型没有分清需要工具的边界system prompt 中明确何时不调用工具上下文爆炸工具返回大段原文数据未经预处理工具侧摘要限制返回长度答案放开头6. 不同模型在 Function Calling 上的差异选型参考与实测对比聊了这么多方法论最后必须落到选型上。不同模型对 Function Calling 的支持能力差异很大选错了模型后面所有优化都是事倍功半。我基于自己的实测经验给几个主流模型的 Function Calling 能力做了个横向对比。这个对比不是官方 benchmark是我在真实业务场景里的主观感受但应该很有参考价值。模型Function Calling 稳定性参数提取准确率多轮工具编排能力备注GPT-4o / GPT-4o mini非常优秀很高强不需要额外 prompt 就能理解工具用途Claude 3.5 / 4 系列优秀很高强对复杂指令理解力强擅长多步推理Qwen2.5 72B良好较高中上国产开源里表现突出中文场景友好GLM-4-Plus良好较高中上智谱官方 API 在 Function Calling 上有优化DeepSeek-V3 / R1良好较高中上性价比高R1 是推理模型工具调用链路表现亮眼一些小参数开源模型一般一般弱单工具调用勉强可用多工具场景不建议这里要特别说明两点。第一评测时不要只看官方指标一定要用自己的真实场景去压测。我遇到过某个模型在公开 benchmark 上 Function Calling 得分很高但一上真实业务就频繁误选工具。原因很简单公开测试集里工具描述和用户问题高度对齐而业务里的用户表述五花八门模型的鲁棒性就暴露了。第二如果你用的是私有化部署的开源模型微调是提升 Function Calling 能力最有效的手段。用一批高质量的工具调用样本数据对模型做微调能显著提升参数提取的准确率和工具选择的正确率。这个做法在 Qwen2.5、Llama 3 上都验证过。如果项目阶段不允许微调至少也要选择对 Function Calling 原生支持较好的模型版本。另外补充一点关于推理模型如 DeepSeek-R1、o1 系列的注意点。推理模型在回答前会做大量内部推理所以在工具调用场景里它们的表现与传统指令遵循模型不同。推理模型可能会把调用工具作为一个推理步骤反复思考该不该用导致显式调用出现得比较晚或者参数有些奇怪。如果你在搭建一个低延迟的 Agent这类模型未必是最优解。说到底选模型还是要回归业务本身。你的工具数量、调用频次、对延迟的要求、成本预算都会影响最终选择。Function Calling 只是一个协议真正决定体验的是模型能力、工程质量和 prompt 设计这三者的配合。7. 从 Function Calling 到 Agent下一步该怎么走Function Calling 解决的问题是让模型可以调用工具但如果你真去做一个 Agent光有这个还不够。从我的实践来看下一步至少要补齐三块能力规划、记忆与反馈。规划指的是让模型有能力拆解一个复杂任务把它分成多个子任务并且安排执行的顺序。Function Calling 的每次调用解决的是单点问题但一个真实的用户需求往往是多条工具链的组合。比如帮我对比这几款手机的配置并推荐最适合我的那一款这个需求可能需要先搜索手机参数、再结合用户历史偏好、最后生成推荐理由。每一步都需要模型在拿到中间结果后动态调整计划而不是事先写死。记忆则是让 Agent 在多次交互中记住用户的偏好、历史操作和上下文。没有记忆的 Agent 每次都要重新理解用户效率和体验都会差一大截。你可以把对话历史传给模型实现短期记忆但要长期记忆往往需要引入向量数据库、用户画像这类外部存储再结合工具调用把记忆写入和读取变成两个独立工具。反馈机制是我觉得最容易被忽略的一环。模型调用工具后如果工具执行出错模型能不能理解错误信息、能不能自我纠错并重试比如一个下单工具因为库存不足失败了模型应该把错误消息读进去判断是告知用户缺货还是推荐替代方案。这个理解并处理失败的能力决定了 Agent 在真实场景里的可用度。我目前的工程做法是在每次工具调用失败时把错误信息中提炼出的关键内容传给模型并在 system prompt 里要求模型如果工具返回错误请分析原因如果是参数问题允许修正后重试最多重试一次如果无法解决请如实告知用户。 这层兜底逻辑能救回不少原本会直接崩溃的交互。说到底Function Calling 是骨架规划、记忆、反馈才是血肉。骨架搭好了后续才有机会长成完整的 Agent。如果你现在只是刚接入 Function Calling别急着上太复杂的 Agent 框架先把单工具调用跑稳再把多工具编排做好再逐步叠加规划与记忆。每层都踏实了整体才不会翻车。