先说结论：Function Calling 是当前把大模型真正接进业务系统时，性价比最高、落地最快的一项能力。它不改变模型的训练方式，也不需要你微调一个专用模型，只需要在请求里多传一份“工具清单”，让模型学会在你设定的规则下输出结构化调用意图，然后由你的代码去执行真实操作。这套机制特别适合做智能助手、客服系统、数据查询机器人、流程自动化这类场景。如果你正在纠结“大模型能帮我干活，但怎么让它安全、可控地操作我的系统”，这篇文章就是为你准备的。
我自己踩过不少坑，从最开始只会让模型“聊天”，到后来让模型直接调接口、查数据库、操作业务系统，中间经历了大量试错。这篇实战指南不绕弯子，直接从原理讲到代码，再讲到工程落地时那些文档里不会写清楚的细节，希望能让你少走几个月的弯路。
1. 为什么需要 Function Calling：从“会聊天”到“能办事”的关键一跃
1.1 大模型本身是个“嘴强王者”
先看一个本质问题：无论是哪种大模型，本质上都是“文字接龙”。你输入一段话，它预测下一段最合理的文字。它知道很多知识，但它的所有知识都停留在训练时见过的文本里。你问它“帮我把订单状态改成已发货”，它能给你写出格式正确的回复句子，但它实际上改不了你数据库里任何一条记录。它没有手，不知道你的订单接口在哪，也不该被直接暴露数据库权限。
这个缺陷在真实业务里非常致命。想象一个客服机器人，用户说“我要退掉昨天买的那个耳机”，如果模型只会聊天，它只能说“好的，已为您记录，我们会尽快处理”，然后什么都没有发生。用户以为退了，实际订单还在那里。这种“假动作”在真实产品里是不可接受的。
那解决方案是什么？早期有两条路：一是用提示词让模型输出固定格式，比如“我要调用退款函数，参数是订单号12345”，然后你写一堆正则去解析它的回复；二是微调模型，让模型学会特定任务。但前者极度脆弱，模型输出的格式稍微漂移你的解析就废了；后者成本高、周期长，业务一变就得重训。
Function Calling 的出现，就是专门来终结这种“靠提示词碰运气”的尴尬状态的。
1.2 Function Calling 到底解决了一个什么问题
用一句话概括：它让模型学会了“求助”——当模型意识到自己无法完成某个操作时，它会输出一个结构化的“调用请求”，就像一位前台接待员写了张便签：“请技术部帮我查一下订单号A10086的状态”。然后你的程序看到这张便签，去执行真实的函数，把执行结果再交还给模型，模型基于真实结果继续组织语言回复用户。
这个设计解决的关键问题有三个：
- 格式稳定性：模型不再输出自由文本让你解析，而是输出严格的 JSON 结构，包含函数名和参数，你的代码可以直接取用。
- 能力边界清晰：模型不直接接触你的数据库或业务系统，它只负责“决定调哪个函数、传什么参数”，真正执行是外部代码，这让权限控制变得非常干净。
- 上下文补全：模型可以把外部函数的返回结果作为新的上下文，继续理解、总结、回答，形成完整的“感知-决策-执行-反馈”闭环。
打个比方：你把 Function Calling 理解为给大模型配了一个“外部工具箱”。模型自己不会修水管，但它知道工具箱里有“扳手”和“生料带”，当用户说“水龙头漏水”，它会准确地从工具箱里挑出扳手和生料带，递给你，由你来完成修理。它负责识别意图和匹配工具，你负责执行和保证安全。
1.3 和普通“提示词引导输出 JSON”的根本差异
很多人会问：我在提示词里写“请以 JSON 格式返回结果”，效果是不是一样？我一开始也这么干过，后来发现差别太大了。
普通提示词引导的方式，模型回复本质上还是“文本生成”。它可能输出：
{"function": "refund", "order_id": "12345"}看起来没问题，但下一次它可能输出：
{"function": "refund", "order_id": "12345", "explanation": "用户申请退款"}或者在你不需要它调用函数的时候，它自作主张地给你调了，又或者它把函数名改了大小写。你的解析器必须像一个整天擦屁股的保姆，永远在适配各种“惊喜”。
Function Calling 则完全不同。它在模型训练阶段就已经强化了“何时调用、如何构造参数、何时不调用”的规范。API 层面也会有结构化的字段返回给开发者，你拿到的是一个已经按照你提供的工具定义校验过的调用意图。你不需要写正则，不需要容忍文本漂移。这就是“约定优于配置”的典范。
2. 核心原理拆解：一次完整的“感知-决策-执行”闭环到底发生了什么
2.1 工具的“招聘广告”：tools 参数里到底该写什么
要理解 Function Calling，必须先理解你传给模型的“工具清单”。从 API 使用者的角度看，你在发起请求时增加一个tools参数，这个参数是一个数组，数组里每个元素描述一个函数。以很多平台通用的格式为例，一个完整的工具定义长这样：
{ "type": "function", "function": { "name": "query_order_status", "description": "查询订单当前状态。当用户询问订单配送进度、发货状态、物流信息时使用。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "用户的订单编号，格式通常为英文字母开头加数字，例如 A10086" } }, "required": ["order_id"] } } }这段定义就是模型判断“要不要调用、怎么调用”的唯一依据。所以这段定义的质量，直接决定了功能的成败。
写description时，不要惜字如金。模型不看你的业务代码，它只看这段描述来判断何时调用。很多新手把描述写成“查询订单”，结果用户问“我的快递到哪了”模型不知道要调用，因为描述里没有“快递”“物流”这些词。我后来把描述写成：“查询订单配送进度。当用户询问物流、快递、发货、揽收、运输中、派送中、签收等状态时调用。需要提供订单编号，若用户未提供，请先向用户索要。”效果立竿见影。
2.2 模型是怎么“决定”该不该调用工具的
这一步是理解 Function Calling 内在机制的关键。在模型生成回复时，它面对的不再是单一的“下一段话”的选择空间，而是多了一个选项：是继续正常的对话文本，还是产生一个“工具调用”的动作。
你可以把模型的推理过程理解为：它在内部会先“思考”当前用户的请求属于什么意图。如果请求的内容是它自己可以直接从对话上下文回答的（比如“你是谁”“帮我写一首诗”），它就直接输出文本；如果请求的内容涉及外部实时信息或操作（比如“我订单到哪了”“帮我改一下收货地址”），它就会在输出中标记“我要调用某个工具”。
模型内部实际上是在所有可能的下一段生成结果中，选择概率最高的那个。当你提供了工具定义，这些工具调用格式就变成了概率空间里的一部分。如果你的描述写得足够精准，模型“觉得应该调用查询函数”的概率就会显著高于“瞎编一个状态”的概率。这也是为什么工具本身就相当于模型的“外挂记忆”——说工具越具体，模型越容易产生正确的调用行为。
这里有一个需要强调的点：模型并没有真正“理解”你的函数逻辑，它只是在做模式匹配和意图识别，只是这个匹配是基于海量训练数据学出来的，显得很“智能”。所以不要指望模型懂得你的函数内部会报什么错，它不知道。所有的错误处理、异常兜底，必须是你的代码来做。
2.3 一次完整的调用过程全解剖
我们把一次真实调用拆成四步，每一步都看得清清楚楚。
第一步：用户发送消息。比如用户说：“我刚买的东西显示已签收，但我没收到，能帮我查一下吗？”你的程序把这条消息发给模型，同时在请求里附上你的tools列表。
第二步：模型返回“工具调用意图”。注意，这时候模型没有直接回复用户，而是返回一个结构化的对象，大概长这样：
{ "role": "assistant", "tool_calls": [ { "id": "call_abc123", "type": "function", "function": { "name": "query_order_status", "arguments": "{\"order_id\": \"A10086\"}" } } ] }这里面最关键的是tool_calls数组。模型明确告诉你“我想调用 query_order_status 这个函数，参数是 A10086”。注意参数是字符串形式的 JSON，你的代码要做一次解析，这一步后面会细说。
第三步：你的程序执行真实函数。你收到这个调用意图之后，在自己的代码里调用真实的查询接口，拿到订单真实状态，比如“包裹显示已签收，签收时间是今天下午3点，签收地点是小区快递柜”。你把这个结果包装成一个“工具消息”返回给模型。
第四步：模型把工具结果组织成自然语言回复。模型看到你返回的真实状态，结合用户最初的问题，组织出一段有温度的回答：“您的订单 A10086 显示今天下午3点已被快递柜签收，一般会有取件码发送到您手机，麻烦留意一下短信。如果确实没有收到，我可以帮您提交异常件查询工单。”
这四步环环相扣。如果你之前没有接触过这个模式，停下来再读一遍上面这一段。这是 Function Calling 的全部核心，其他所有技巧都是围绕这四步做工程加固。
3. 零基础代码实战：用 Python 快速跑通第一个 Function Calling 程序
3.1 准备环境与前置条件
动手写代码前，先明确需要准备的东西。你想调用某个支持 Function Calling 的大模型 API，需要以下几个条件：
- 一个可用的 API Key，开通对应模型的接口权限。
- Python 3.9 以上环境，安装好
openai或对应平台的 SDK（本文以大部分平台通用的接口风格讲解，代码稍作调整即可移植）。 - 一个可访问的网络环境（这里只按正常公网访问 API 场景说明）。
- 实现两个“假函数”：一是模拟查询订单状态，二是模拟提交退款申请。这样你可以在不接入真实业务的情况下，完整跑通整个闭环。
如果你用的是某个具体平台，只需要把base_url和模型名替换成对应的值即可。我建议初学者先不要急着对接真实复杂的业务系统，先用两个模拟函数把流程跑通，理解数据结构，再逐步替换为真实接口。
3.2 定义两个模拟业务函数
先写两个业务函数，这两个函数模拟真实场景。我故意把它们的逻辑写得很简单，因为我们的重点是跑通 Function Calling 的链路，而不是业务本身。
# business_ops.py from datetime import datetime def query_order_status(order_id: str) -> dict: """模拟查询订单状态的真实函数""" # 真实场景这里会调用订单中心接口或者查询数据库 fake_db = { "A10086": { "status": "signed", "recipient": "张三", "signed_time": "2025-01-15 15:32", "signed_address": "幸福小区3栋快递柜", "tracking": "SF1234567890" } } order = fake_db.get(order_id) if not order: return {"error": f"订单 {order_id} 不存在，请核对订单号"} return order def submit_refund(order_id: str, reason: str) -> dict: """模拟提交退款申请的真实函数""" # 真实场景这里会调用售后工单系统创建退款单 return { "refund_ticket_id": "TK" + order_id[-4:], "order_id": order_id, "reason": reason, "status": "submitted", "submitted_at": datetime.now().strftime("%Y-%m-%d %H:%M:%S") }注意这两个函数的返回值都是字典，因为后面我们需要把返回值回传给模型。真实业务中，返回内容不要包含敏感字段，只回传模型组织语言所需的必要信息即可。
3.3 编写工具定义：给每个函数做好“元数据说明”
接下来是关键中的关键：把这两个函数描述成模型能理解的格式。基于前面的讲解，每个工具必须包含name、description、parameters三大部分。parameters要严格遵循 JSON Schema 格式，字段名要准确，必填项要明确。
# tools_def.py tools = [ { "type": "function", "function": { "name": "query_order_status", "description": "查询订单当前状态。当用户询问订单配送进度、发货状态、物流信息、签收情况时调用。若用户没有提供订单号，必须先询问用户获取订单号。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "用户的订单编号，格式通常为字母开头加数字，例如 A10086" } }, "required": ["order_id"] } } }, { "type": "function", "function": { "name": "submit_refund", "description": "为用户提交退款申请。当用户明确表达要退货、退款、不想要了、申请退款等意图时调用。需要订单号和退款原因。若用户没有提供退款原因，请直接询问。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "用户的订单编号，格式通常为字母开头加数字，例如 A10086" }, "reason": { "type": "string", "description": "用户申请的退款原因，例如：商品质量问题、不想要了、七天无理由退货等" } }, "required": ["order_id", "reason"] } } } ]写工具定义时有几个写法学问，我放在后面专门的章节细说，这里先让你跑通。
3.4 主流程：请求-解析-执行-回传
现在写主程序。我会把完整代码贴出来，每一段都有注释，你在自己电脑上改掉 API Key 和模型名，应该就能跑通。
# main.py import json from openai import OpenAI from tools_def import tools from business_ops import query_order_status, submit_refund # 初始化客户端，按你的平台配置 base_url 和 api_key client = OpenAI( api_key="your-api-key", base_url="https://your-endpoint.example.com/v1" ) MODEL_NAME = "your-model-name" def run_conversation(user_input: str): # 1. 构建消息列表 messages = [ {"role": "system", "content": "你是一位电商客服助手。当用户咨询订单问题或申请售后时，使用工具获取真实信息，不要编造。回复时语气亲切、简洁。"}, {"role": "user", "content": user_input} ] # 2. 发起第一次请求，携带 tools response = client.chat.completions.create( model=MODEL_NAME, messages=messages, tools=tools, tool_choice="auto" # auto 表示由模型自行决策是否调用工具 ) # 取第一轮返回结果 assistant_msg = response.choices[0].message # 3. 判断模型是否要求调用工具 if assistant_msg.tool_calls: # 先把助手这条消息加入历史，保留上下文 messages.append(assistant_msg) # 遍历模型请求的所有工具调用（可能一次请求多个） for tool_call in assistant_msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f"[工具调用] 模型请求调用 {fn_name}, 参数为 {fn_args}") # 根据函数名分发到真实函数 if fn_name == "query_order_status": result = query_order_status(**fn_args) elif fn_name == "submit_refund": result = submit_refund(**fn_args) else: result = {"error": f"未知函数: {fn_name}"} # 4. 把工具执行结果作为一条 role=tool 的消息追加进去 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) # 5. 再次请求模型，让它基于工具结果组织最终回答 second_response = client.chat.completions.create( model=MODEL_NAME, messages=messages, tools=tools, tool_choice="auto" ) return second_response.choices[0].message.content else: # 模型没有调用工具，直接返回回答 return assistant_msg.content if __name__ == "__main__": test_input = "你好，我的订单 A10086 显示签收了但我没收到，帮我查一下，然后我想申请退款" final_answer = run_conversation(test_input) print("最终回答:", final_answer)这个脚本跑起来，你会看到控制台先打印出“模型请求调用 query_order_status”，然后继续调用submit_refund，最后模型把两个工具的执行结果整合成一段自然语言回复。这就是一个完整的 Function Calling 应用闭环。
3.5 这段代码里最容易被新手忽略的两个点
第一次跑通这个代码的人，通常会忽略两个细节。第一个是消息历史里必须保留 assistant 的那条 tool_calls 消息。很多人只把最后工具的结果拼到 messages 里，忘记把模型上一轮返回的assistant_msg也追加上去，结果模型不知道“自己刚才要求调用过这些工具”，第二轮的推理就断片了。
第二个是工具调用可能不止一个。模型在识别到用户诉求里同时包含“查状态”和“申请退款”时，理论上可以在一轮回复里同时发起多个tool_calls，代码里要用循环逐个处理，并把每个tool_call_id和结果一一对应。你如果只处理第一个tool_calls[0]，第二个函数就没有结果回传，第二轮模型就会困惑。
4. 让工具定义更聪明：这些细节决定你的 Function Calling 好不好用
4.1 描述即提示词：把“何时调用”写得像说明书
很多人以为description就是随便写一句“查询订单状态”。我负责任地告诉你，这句话的份量约等于一个小型提示词工程。模型完全依赖这段文字进行意图匹配，你写得越具体，模型调用越准确。
我自己的经验是，description需要包含以下内容：这个函数是干什么的；什么时候必须调用；什么时候不要调用；用户没给参数时应该怎么应对。把这三层写清楚，模型才有足够的决策依据。
举一个对比的例子：
- 糟糕的描述：
查询用户订单状态 - 好的描述：
查询订单当前状态。当用户询问订单配送进度、发货状态、物流信息、签收情况时调用。若用户没有提供订单号，必须先询问用户获取订单号。若用户只是想了解退货政策，不要调用此函数。
区别一目了然。后者不仅告诉模型什么时候用，还告诉它什么时候不用，甚至连“用户没给订单号怎么办”这种细节都覆盖了。我在实际项目里发现，加上“不要调用”的边界说明之后，误用率能降低一大截。
4.2 参数的 JSON Schema：既要有约束，也要有引导
parameters这块，很多照着文档抄的开发者都忽略了description的价值。你在参数对象里给每个字段写描述了吗？如果没有，模型只能根据字段名猜参数含义，很容易传错。
比如订单号字段：
"order_id": { "type": "string", "description": "订单编号，格式通常为字母开头加数字，例如 A10086" }这段描述至少告诉模型两件事：这是一个字符串；如果用户说的是“A 一万零八十六”，模型就知道它对应的是 A10086 这个格式的编号。其实模型在理解口语化的数字时，也需要你的格式引导。
还有一个容易踩坑的地方：required数组。很多人写required: ["order_id"]时，没有考虑到用户可能没说订单号。一旦你把这个字段设为必填，模型在被追问“查订单”但没给订单号时，可能会直接编一个订单号出来填充，因为它必须满足格式要求。你说这危不危险？
我的建议是：对于必须业务语义才能执行的参数，如果用户没有提供，合理的做法是不要把它设为 required，而是在描述里写明“若用户未提供订单号，请先询问用户，不要编造订单号”。这样模型会先反问而不是硬编。控制参数时，宁可让模型多问一句，也不要让它凭感觉填空。
4.3 工具数量与调用决策：不是越多越好
当你给模型挂上越来越多的工具时，你会发现一个现象：工具太多，模型反而开始选择困难，甚至选错。这跟人一样，选项超过一定数量，决策质量就会下降。
我做过一组对比实验，在同一个智能助理项目里，工具数量从 5 个增加到 20 个后，工具选择的准确率明显下降。原因不难理解：模型需要在一次生成中同时考虑文本回复的连贯性和工具调用的匹配度，可选项越多，计算复杂度越高，相互干扰也越大。
解决办法是分而治之。不要试图让一个模型处理所有业务，而是按业务域拆分。比如做一个“售前助手”，工具只挂商品查询、库存查询、优惠计算；做一个“售后助手”，工具只挂订单查询、退款申请、物流跟踪。每个模型专注自己的领域，工具数量控制在 10 个以内，准确率会稳定很多。
如果确实工具很多，可以考虑给工具做一层“路由”：先用一个分类模型或关键词规则判断用户属于哪个业务域，再把请求分发到对应的精简单体。这种方式在实际工程中用得很普遍。
5. 深入工程实战：从 Demo 到可用系统的四个关键改造
5.1 给回传内容“减负”：模型只需知道该知道的
当你把自己写的函数接入真实业务系统时，第一件要对抗的事就是“信息过多”。你的订单查询接口可能返回几十个字段，包含内部状态码、运营备注、成本价格、库存信息等。这些字段如果全部回传给模型，会发生什么？一个是模型上下文被无关信息塞满，消耗 token；另一个是更危险的——模型可能把这些敏感字段说出去。
比如你的数据库里订单有个字段is_blacklist（该用户是否被拉黑），如果你把这个字段回传，模型在组织语言时，理论上存在将其泄露给用户的风险。这在真实产品里是大事故。
我的做法是：在工具函数里做一层“输出裁剪”，只把模型组织回答所必需的几个字段返回。比如查询订单状态，模型只需要知道状态、时间、地点，其他的全部丢弃。这一步在真实系统中是刚需，不要偷懒。
def query_order_status_safe(order_id: str) -> dict: """查询订单状态，返回给模型前做字段白名单过滤""" raw = query_order_status(order_id) # 真实接口返回的完整数据 # 只保留安全字段 safe_keys = ["status", "signed_time", "signed_address", "tracking"] return {k: raw[k] for k in safe_keys if k in raw}5.2 模型幻觉的兜底：工具执行错误时不要硬答
真实业务中，工具函数一定会出错。数据库超时、接口返回异常、参数缺失，这些情况在 Demo 里不会有，但生产环境里每天都会遇到。关键在于：工具执行出错时，你返回给模型的内容是什么。
新手最容易犯的错是：工具报错时，程序直接抛出异常，整个对话中断。或者把异常信息原文丢给模型，让模型基于一个报错堆栈去组织用户话术。
正确的做法是：在工具函数里捕获所有异常，并把异常转换成一个模型能理解并妥善应对的结果。比如：
def query_order_status_with_catch(order_id: str) -> dict: try: result = real_query_api(order_id) return {"status": result["status"], "signed_time": result["signed_time"]} except Exception as e: # 记录日志，但返回给模型的内容要干净 return {"error": "订单查询服务暂时不可用，请稍后重试"}这样模型收到{"error": "查询服务暂时不可用"}后，会自然地向用户表达“抱歉，系统开小差了，请稍后再试”，而不是把你在日志里记录的技术细节暴露出去。这是个把“技术错误”翻译成“用户话术”的重要过程。
5.3 延迟与交互体验：模型两次往返是硬成本
Function Calling 的架构决定了，只要触发工具调用，就至少要经历两次模型请求：第一次模型返回调用意图，第二次模型基于工具结果生成回复。这两次请求的延迟会叠加，在真实场景里，用户可感知的等待时间可能从 1 秒变成 3-5 秒。
在工程上，我有几个优化手段。一是并行化工具执行：如果模型一次返回了多个tool_calls，你不必顺序执行，可以用多线程或者异步并发去跑，最大限度压缩工具执行时间。二是流式输出：很多平台支持流式响应，你可以把第一次请求的处理做成流式的，让用户的等待感变轻。三是缓存与预取：对于高频查询类工具（比如查天气、查订单状态），可以在用户输入时就预判需求，提前调用工具，但这种方式要谨慎，避免资源浪费。
还有一个体验层面的技巧：如果你的对话场景是对响应时间非常敏感的（比如实时语音对答），你应该考虑让工具尽量“轻”——把工具的返回结果压缩到最小，因为模型第二次生成回复时读的上下文越短，生成的 token 就越少，速度也就越快。
5.4 权限与安全：工具权限必须收敛，不因模型“聪明”而放松
模型调用工具，本质上是你的程序拿到了一个“指令”，然后去执行。这个指令可能来自真实用户，也可能来自被恶意构造的提示词注入。安全红线一定要在代码层控制，而不是指望模型自觉。
几个硬性原则：
- 模型能触达的工具，必须是已经授予当前对话用户权限的范围。比如用户 A 的订单，模型绝不能调用“查询订单 B 详情”的工具。这类归属校验需要写在工具函数内部，在调用真实接口前完成。
- 涉及资金、退款、修改数据的高危操作，不能只靠模型一个调用意图就执行。要增加人工确认环节或二次授权。哪怕是自动执行，也必须留痕可审计。
- 工具函数的日志必须记录完整的调用链：用户说了什么、模型请求了哪个函数、传了什么参数、函数返回了什么结果。这个链路是事后追查问题的基础。
我见过一个常见事故：某个项目把“发放优惠券”做成工具直接挂给客服机器人，结果用户对机器人说“请给所有用户各发一张千元优惠券”，模型识别意图后真的调用了工具。听起来很蠢，但这类事情确实发生过。因为模型只看描述匹配意图，它不理解“所有用户”这个参数值在你系统里意味着灾难。你需要的是在工具函数里做参数校验：数量、金额、范围，全部设置上限，超限则阻断。
6. 常见问题与排查技巧实录：你一定会遇到的几个坑
6.1 模型就是不调用工具，怎么办
这是最高频的问题。你明明把tools传进去了，用户说的话也完全应该触发工具，但模型就是继续“干聊”，甚至编造一个假的订单状态回答用户。
排查顺序如下：
第一步，确认你的tools是否真的传入了请求。这个坑我踩过：在某平台的 SDK 里，tools参数和另一个functions参数是互斥的，我传错参数名导致工具集根本没生效，模型自然无从调用。
第二步，检查tool_choice的设置。tool_choice="auto"是让模型自己决定，它的决定可能是“不调用”。如果你希望某个场景下模型必须调用某个工具，可以设置tool_choice={"type": "function", "function": {"name": "query_order_status"}}，强制它调用。但这只适用于你已经确定用户意图的场景，平时不建议强行指定。
第三步，最可能的原因：工具描述的引导性不够。回到第 4.1 节，检查你的description是否包含用户的“口语化表达”。模型识别意图依靠的是语义匹配，不是关键词硬匹配，但你的描述如果能覆盖更多同义表达，触发率会明显上升。比如用户说“我的东西到哪了”，你的描述里只有“物流”没有“东西到哪”，模型可能就匹配不上。
6.2 工具参数解析失败或参数缺失，怎么应对
你拿到tool_call.function.arguments后用json.loads解析，结果偶尔会报错。这个问题的发生率不高，但一旦发生就会中断整个对话流程。
原因通常是模型生成的arguments字符串不是严格合法的 JSON，比如包含了一些尾逗号，或者字段名变成了单引号。解决方案是增加一个容错解析函数：
import json def safe_parse_arguments(arguments_str: str) -> dict: try: return json.loads(arguments_str) except json.JSONDecodeError: # 部分场景下模型会给出不严格的JSON，做一次基础清洗 # 例如把单引号替换为双引号（简单方案，按需扩展） cleaned = arguments_str.replace("'", '"') try: return json.loads(cleaned) except Exception: return {"error": "参数解析失败", "raw": arguments_str}另一个更稳妥的做法是：当你的业务对参数要求严格时，在调用真实工具前先做一次参数校验，校验不通过时返回给模型一个提示，让它补全参数。比如模型调用退款函数时漏了reason，你可以返回：“缺少参数 reason，请向用户询问退款原因后再调用。”模型会收敛自己的行为。
6.3 上下文里积攒了太多工具消息，怎么办
每轮工具调用都会往messages列表里追加两条消息（一条 assistant 的 tool_calls 消息，一条 tool 的回传消息）。如果是长对话场景，上下文会快速膨胀，不到十轮就逼近模型的上下文窗口上限。
工程上常用的手段是做记忆裁剪。对较旧的历史消息做压缩或摘要，用一条“概括消息”替代原来的多轮明细。但要注意：正在进行的工具调用相关消息不能裁剪，否则模型会丢失工具执行结果，无法组织最终回答。
我自己的裁剪策略是：当前轮的 messages 完整保留，前一轮的工具调用消息也保留，更早的历史折叠成摘要。如果业务允许，也可以直接限制工具类对话的轮次，超时或超轮后引导用户另起新会话。
6.4 模型把参数“自作主张”补全了，怎么办
前面提过一个风险：当required标记了必填，但用户实际没有提供该参数时，模型有概率自己编造一个值填进去。比如用户只说“帮我退款”，没有说订单号，模型却把订单号自动填成了A00000。
这个问题的本质是模型在“尽力完成格式要求”和“缺少真实信息”之间，选择了前者。应对方案有两条：一是尽量别把这类需要用户提供的信息设置为 required，而是要求模型先询问；二是在工具函数内部加规则校验，比如订单号格式不匹配就直接返回错误，让模型回头追问。
我在自己项目里的做法是双保险：描述里明确写“若用户未提供订单号，必须询问用户”，同时工具函数里加正则校验，格式不对就返回“订单号格式不正确，请重新向用户确认”，逼着模型纠错。
6.5 明明是工具调用，模型却输出了一堆自然语言
有时候你会发现 assistant 的回复内容既有content字段又有tool_calls字段，这种混合输出偶尔会出现。处理逻辑上，只要tool_calls不为空，你就应该优先处理工具调用，而不是把content字段当作最终回答展示给用户。
因为在这种场景下，content字段往往只是模型的“边输出边说”，比如“好的，我来帮您查询一下”这种过渡性话语，真正的动作在tool_calls里。如果你把 content 当成最终回答，一方面工具没执行，另一方面用户会看到一句没下文的“好的我来查”。正确的流程是：检测到 tool_calls 不为空，就忽略 content（或把它作为过渡语缓存），执行完工具、拿到第二次回复后再统一展示最终话术。
7. 进阶玩法思路：Function Calling 还可以这样用
7.1 让模型不再是“嘴替”，而是“编排调度器”
基础用法是模型调单个工具，但实际复杂业务中，一个用户请求往往需要多个工具协同。比如用户问：“找一款 5000 元以内的降噪耳机，和我正在用的手机兼容，推荐一个性价比最高的。”这个任务需要商品查询、库存查询、参数对比三个工具协作。
Function Calling 的多工具返回能力正好可以支撑这种场景。模型第一轮可能先调用商品查询筛选出候选列表，你将结果返回，他再决定是否继续调用参数对比工具。这就是一种简单的“模型自主编排”。
不过要提醒的是，目前的模型编排能力还不能完全信得过，尤其是跨多轮、长链路、相互依赖的任务。工程上建议在提示词里把执行流程写清楚，甚至给模型一个“操作手册”，让它知道先查什么后查什么。也可以引入“决策函数”，让模型在每个步骤只做一个单点决策，你来控制流程走向，这样更稳。
7.2 把 Function Calling 做成“技能注册中心”
当你积累了很多成熟工具后，可以考虑把工具定义转成一份可配置化的“技能清单”。工具的描述、参数约束、权限级别、超时时间都放到配置中心或数据库里，运行时动态组装。
这种方式有几个好处：一是业务变化时，不需要改代码，调整配置即可；二是多个模型应用可以共享同一套工具注册表；三是可以在后台观察每个工具的被调用频率、成功率、误用率，基于数据进行迭代。我最近在做的项目就是这么设计的，后面再单独写一篇详细讲讲。
7.3 Function Calling 与 RAG 的结合点
很多知识库问答场景用的是 RAG（检索增强生成），本质是“先检索资料，再基于资料回答”。RAG 和 Function Calling 并不冲突，反而可以协同：把“检索知识库”本身定义成一个工具，让模型自己判断“这个用户问题是否需要查知识库”。这样比每次都强制检索会更精准，也省 token。
更进一步，你可以在工具里封装不同的检索策略：查商品说明书走一个索引，查售后政策走另一个索引，查维修教程走第三个。模型根据用户问题选择对应的检索工具，这就是一个典型的“意图驱动的知识检索”架构。
8. 收尾：几个我从项目里沉淀下来的体会
这些经验都是我在真实项目里一点一点换来的，写在这里算是个人的一个总结。
第一个体会：工具定义的重要性被大多数人低估了。很多项目把精力花在选模型、调 prompt 上，却对工具描述草草了事。实际上在 Function Calling 场景里，工具的description就是模型决策的那个“prompt”，它的质量直接影响调用准确率，值得你一版一版去迭代。
第二个体会：别怕多问一轮。早期我为了让模型调用一次就成功，把参数校验放得很松，结果经常发生编造订单号这种离谱的事。后来学乖了，宁可让模型与用户多确认一次“您方便提供订单号吗”，也不要冒险用一个未知参数去调用真实接口。在真实业务里，“不执行错误操作”远比“少问一句话”重要得多。
第三个体会：日志是 Function Calling 项目的生命线。模型叫了什么函数、传了什么参数、函数返回了什么、最终回答了用户什么，这整条链路必须完整可查。很多人只在模型回答不好时去调 prompt，却没有数据支撑到底哪里出了问题。把日志系统做扎实，后续的每一次优化才有依据。
第四个体会：从简单场景起步。不要想着一次把所有工具都接入，我建议你先拿一个“查状态”这种风险为零的只读工具完整跑一遍流程，再逐步加入“提交申请”这类有副作用的高危操作。每一步都稳住了，再往前走，整个系统的可靠性就有保障。
Function Calling 是一个值得深耕的能力，它把你手里的大模型从一个“聊天机器人”真正变成了“可指挥的行动者”。希望这篇实战笔记能帮你少踩一些坑，快速做出自己的第一个能“办事”的 AI 助手。
