搞大模型应用有一段时间了，最开始跑通对话、能做内容总结的时候，觉得这玩意儿确实聪明，但真正放到业务里用，总感觉差口气。后来接触到Function Calling，才意识到之前的“差口气”差在哪——大模型只跟你聊，不帮你干活。而Function Calling恰恰是把“聊天”变成“办事”的那道桥。这篇东西我不打算写得太教科书，就按我自己从零到一摸通的路径，把原理、代码、坑，一次讲透。

这篇内容适合正在入门大模型应用开发、想让模型去查数据、调接口、操作外部系统的开发者。哪怕你完全没接触过Function Calling，把代码跑通，也能立刻感受到“模型自己判断该调哪个函数”的神奇之处。

1. 为什么大模型需要Function Calling

1.1 大模型的固有短板

先想一个问题：你跟一个纯对话模型说“帮我把订单表里金额超过一千的客户找出来”，它会怎么回答？大概率是给你一段SQL，或者一段伪代码，告诉你“你拿去数据库里跑一下”。它不会自己连数据库，不会自己执行查询，更不会把结果整理成表格给你。

这不是模型笨，是模型本身的定位决定的。它是个语言模型，不是操作系统，不是一个能直接操纵外部世界的程序。它没有文件句柄，没有数据库连接池，没有HTTP客户端（至少没有能稳定帮你完成事务操作的那种），它只有生成文本的能力。

但问题在于，用户并不关心“你能不能跑SQL”，用户要的是“把超过一千的客户名单给我”。这个诉求天然包含了动作，而不仅仅是文字。如果模型只能说话不能做事，那所有业务场景都得靠人去把模型的输出“翻译”成实际动作，这中间就存在大量的解析、匹配、出错空间。

Function Calling做的事情，本质上是把“模型生成文本”的能力，和“程序执行具体动作”的能力，用一套标准化的协议绑在一起。模型负责任务规划，程序负责动作执行，各干各擅长的部分。

1.2 Function Calling的工作方式

我最初理解Function Calling的时候走了一个弯路，误以为它是“模型学会调用函数了”，其实更准确的说法是“模型学会输出结构化的调用意图了”。

整个流程拆开看是这样的：你把一批函数的名称、描述、参数格式，在请求里显式地告诉模型。模型根据自己的判断，在需要某个函数能力的时候，不是直接输出自然语言答案，而是先输出一个结构化的JSON，里面包含了要调用哪个函数、参数是什么。你的程序解析这个JSON、执行对应函数、拿到结果，再把这结果作为一条消息传回给模型。模型看到执行结果之后，再组织自然语言回复用户。

关键在于：模型没有一个真实存在的函数可以调用，它只是以结构化的方式表达“我想调用什么”。真正执行函数动作的永远是你的代码。这一点理解了，后面所有环节都不会乱。

1.3 为什么说它是“让AI更强大”的关键一步

我个人的看法是，Function Calling是让大模型从“玩具”走向“工具”最关键的机制之一。没有它，模型的输出高度不可控，你不知道它什么时候给文字、什么时候给代码、什么时候“假装”自己执行成功了。有了它，模型知道了“我可以调用能力，但必须以规定的格式表达这个意图”，这让程序解析变得极其稳定。

另一个很重要的价值是节省Token和延迟。你不需要在提示词里花大量篇幅“要求模型必须输出JSON并保证合法性”，也不用为了稳定格式而反复调Prompt。模型在训练阶段就被引导着识别函数调用场景，你只要把函数定义写好，剩下的交给它的意图识别能力，准确率比你写十行Prompt要高得多，也稳得多。

2. 环境准备与一次完整基础调用

2.1 环境与依赖准备

动手之前先把环境弄利索。我用的是Python 3.10，Anaconda建了一个独立的虚拟环境，避免污染其他项目的依赖。

conda create -n fc-demo python=3.10 conda activate fc-demo pip install openai

这里有一点必须提：OpenAI的Python SDK版本迭代非常快，不同版本之间tools参数的兼容性差异很大。我用的是0.28以上的版本，如果你的版本比较老，建议先升级到最新版，否则很多新特性用不了。升级方式很简单：

pip install --upgrade openai

2.2 初始化的正确写法

环境就绪后，第一步是初始化客户端。这块有很多人会踩坑，主要是OPENAI_API_KEY环境变量没配对，或者密钥带了个空格，搞得请求一直报401。我习惯在一开始就把配置写成独立文件，这样后面调试的时候不用到处翻。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1") )

base_url这个参数建议预留。因为等后面做模型切换、或者走一些兼容网关的时候，不需要改任何业务代码，只需要改这个环境变量，就能把请求转到目标服务上，非常方便。

2.3 云函数平台的关键步骤

云函数平台的部署流程基本是统一的：把代码打包上传、配置触发方式、设置环境变量、部署。我之前部署一个天气查询函数，整个过程大约十五分钟，关键步骤集中在三块：

第一，函数入口文件命名要规范。平台一般要求一个明确的入口函数名，比如main，参数传递约定是事件对象格式。如果你的入口写错了，部署能过，但一触发就报错。

第二，环境变量要一次性配置到位。函数代码里读取的数据库连接信息、外部API密钥，都要在平台的控制台里预先配好。不要想着先空部署再补，因为每次更新环境变量都有可能触发新的冷启动。

第三，日志是排错的生命线。一定不要偷懒省掉日志输出。在代码的关键节点加上日志，记录入参、出参、异常信息，部署到云函数之后，不要等用户在那边反馈“用不了”，直接去平台日志面板看调用链，基本能定位到具体哪一行挂的。

部署完成后，可以在平台自带的测试面板里传一个模拟事件，验证函数是否能正确返回预期的数据结构，确认无误之后再接入上层业务。

2.4 最基础的对话调用

咱们先做一个不包含任何函数调用逻辑的原始对话请求，作为对照基准：

response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": "你是一个智能助手，可以帮助用户查询天气信息。"}, {"role": "user", "content": "北京今天需要带伞吗？"} ] ) print(response.choices[0].message.content)

你让模型自己回答这个问题，它大概率会基于训练数据回答，说“根据我的知识，北京今天的天气情况是……”。但有个问题：它的知识是有截止日期的，当天到底下不下雨，它根本不知道。它只是在“合理编造”一个看起来像样的回答。

这恰恰是纯对话模型在实时信息场景下的致命缺陷。解决这个缺陷的路径，就是Function Calling。

2.5 第一次定义工具并触发调用

下面这段代码是理解Function Calling核心机制的关键，我拆开讲。

tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的实时天气信息，包括温度、天气状况、降水概率等", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京、上海、广州" } }, "required": ["city"] } } } ] response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": "你是一个智能助手，可以通过天气查询工具获取实时天气数据。"}, {"role": "user", "content": "北京今天需要带伞吗？"} ], tools=tools, tool_choice="auto" ) print(response.choices[0].message)

发现没有，这次我没有请求模型直接回答“需不需要带伞”，而是把tools传进去了。模型识别到用户想了解北京的天气，而自己并没有实时数据，它就会“想要”去调用那个get_weather函数。

这时候response.choices[0].message里会多出一个字段tool_calls，里面包含了函数名和参数JSON：

tool_calls=[ { "id": "call_xxxx", "type": "function", "function": { "name": "get_weather", "arguments": "{\"city\": \"北京\"}" } } ]

注意，这时候模型并没有真正执行get_weather，它只是告诉你“我想调用这个函数，并且我提取出了参数”。真正执行这个查询动作的，是你自己的代码。

3. 完整调用闭环：从函数定义到结果回传

3.1 真实执行函数

模型给出了“调用意图”之后，接下来就要靠程序把意图落到实处。这里需要自己写一个真实的get_weather函数，把模型输出的参数解析出来，执行真实逻辑。

import json def get_weather(city: str) -> dict: """模拟一个天气查询接口，实际开发中这里请求的是真实的天气API""" weather_data = { "北京": {"temperature": 26, "condition": "小雨", "rain_probability": 70}, "上海": {"temperature": 30, "condition": "多云", "rain_probability": 10}, "广州": {"temperature": 33, "condition": "晴", "rain_probability": 5} } return weather_data.get(city, {"temperature": None, "condition": "未知", "rain_probability": None})

这个函数的实现很简单，但有两个关键点必须注意：

第一，返回值如果是None、True、False这类布尔值，需要显式处理成字符串，否则模型回传的时候可能会因为JSON序列化问题出现异常。

第二，真实接口场景下，函数内部一定要加异常捕获和超时处理。因为模型并无法判断你调用的下游API当前是否可用，一旦下游超时，整个链路会卡住很长时间。

3.2 把函数结果回传给模型

这是整个流程中最需要理解的一步。函数执行完毕后，你需要把结果作为一条新的tool消息，追加到原有的对话历史里，然后再次调用模型。代码继续：

import json messages = [ {"role": "system", "content": "你是一个智能助手，可以通过天气查询工具获取实时天气数据。"}, {"role": "user", "content": "北京今天需要带伞吗？"} ] # 第一轮调用：模型返回工具调用意图 response = client.chat.completions.create( model="gpt-4o", messages=messages, tools=tools, tool_choice="auto" ) assistant_message = response.choices[0].message messages.append(assistant_message) # 解析并执行函数 if assistant_message.tool_calls: for tool_call in assistant_message.tool_calls: args = json.loads(tool_call.function.arguments) result = get_weather(city=args["city"]) # 把函数执行结果作为 tool 消息追加 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result) }) # 第二轮调用：模型基于函数结果生成最终回答 final_response = client.chat.completions.create( model="gpt-4o", messages=messages, tools=tools ) print(final_response.choices[0].message.content)

第二次调用的输出，才是用户最终看到的内容。因为模型看到了真实的get_weather执行结果：北京温度26度，小雨，降水概率70%。它就能非常确定地告诉你：“北京今天有小雨，降水概率较高，建议带伞”。

这里有个细节值得品一品：tool_call_id一定要对应上。这是把执行结果和调用请求关联起来的关键字段，如果你随便写或者省略，模型无法判断这个结果属于哪一次调用，会导致上下文错乱。

3.3 多轮与多函数调用的状态维护

真实业务里不太可能只在一个函数上打转。比如用户问“北京和上海哪个更适合带伞？”模型可能会同时发起两次get_weather调用，返回的tool_calls列表里就会有两条记录，每个记录都有自己的id、function.name、function.arguments。

处理多函数调用时，有个容易被忽视的细节：assistant_message整体要一次性append进消息历史，然后再逐条处理函数调用，逐个把tool消息追加进去。顺序千万不能乱，否则第二轮调用时模型对前文的理解会出现偏差。

在实际应用中，我发现一个特别管用的经验：messages必须要完整保存全流程的对话历史，从高到低逐轮追加，不能只发最后一条。因为模型在做意图识别的时候，会参考之前的上下文，来判断“用户的当前问题是否要基于上一次工具结果继续提问”。比如用户说“那上海呢？”，模型需要结合对话历史才明白，原来是在问上海天气，而不是一个独立的无关问题。

4. 从单一函数到多函数业务场景

4.1 场景设计：旅行助手应用

单函数跑通之后，你会忍不住想把Function Calling用在一个更完整的业务场景里。我自己的实践是从一个“旅行助手”开始。这个助手同时具备天气查询、景点推荐、酒店推荐三个函数，根据用户的提问目标，自动选择调用不同的工具。

这就引出了多函数场景下的核心问题：第一，模型如何决定该调用哪个函数；第二，当用户问的问题语义模糊时，模型会不会选错；第三，多个函数都定义了相似参数时，模型怎么保证参数的一致性和正确性。

回答第一个问题：模型是根据每个函数描述与实际用户意图的语义相似度来决策的，也就是说，函数描述写得越清楚，模型选择函数越有把握。很多新手不在意描述文字，随便写两句，结果模型频繁选错函数，然后抱怨模型“不智能”。其实源头就在描述太烂。

4.2 函数定义精细化，直接影响调用准确率

我深入对比过函数描述的好坏对调用准确率的影响，差异可以达到两成以上。举个例子：

• 差描述：获取酒店信息
• 好描述：根据城市、入住日期和预算，查询符合条件的酒店列表。当用户提到住宿、入住、酒店时优先使用此函数。

差别很明显吧。模型对函数意图的理解，完全依赖description。你描述得越清晰，模型越能准确判断“这个用户需求是否属于这个函数的能力范围”。

同样的思路也适用于参数定义。参数里每个字段的description也要写上，尤其是枚举值。比如sort_type参数的可选值有price_asc（价格升序）和score_desc（评分降序），你光告诉模型这是个字符串，它不知道该传什么，但你把选项含义写清楚，模型提取参数的准确率立刻提升。

这里给出一个我实践过效果不错的景点推荐函数定义：

tools = [ { "type": "function", "function": { "name": "recommend_attractions", "description": "根据城市、偏好主题和游玩天数，推荐适合的景点列表。当用户询问去哪里玩、有什么景点时使用此函数。", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，如北京"}, "preference": { "type": "string", "enum": ["history", "nature", "food", "shopping"], "description": "游玩偏好：history表示历史古迹，nature表示自然风光，food表示美食体验，shopping表示购物" }, "days": {"type": "integer", "description": "游玩天数"} }, "required": ["city"] } } } ]

注意这里我把preference定义成了枚举，并且把每个值对应的中文语义解释得很明确。模型从用户那句“我想吃吃喝喝逛逛”里，就能很自然地提取出{"preference": "food"}，这就是描述清晰的功劳。

4.3 多函数场景下的决策链

在旅行助手场景里，用户说：“帮我规划一个北京三天的行程，我想看历史古迹，另外也帮忙看看这几天天气适合不适合出行。”那么模型第一步会判断：用户需要景点推荐，也需要天气信息。它会如何决策？

如果几个函数之间没有依赖关系，模型会在一次响应里输出多个tool_calls，同时触发recommend_attractions和get_weather。你的程序处理完所有函数结果，再统一把结果回传。这是并行调用方式。

但有些场景是函数之间存在依赖的。比如用户说：“根据景点推荐结果，帮我查一下去这些景点要怎么坐车。”这时模型必须先调用景点推荐函数，拿到景点列表后，才能把具体景点名称作为参数，再次调用交通查询函数。这属于串行调用，需要两轮以上的函数调用循环。

从工程实现的角度来说，你的代码需要支持循环调用逻辑，不能只处理一次tool_calls就退出。我通常在代码里加一个最大循环轮次限制，比如最多处理三轮工具调用，超出后直接退出，并返回一条兜底文案。这个限制很有必要，防止极端场景下模型陷入无限循环。前面提到过那个同学遇到的“陷入循环直到额度耗尽”的问题，加了这个限制之后基本就不会再出现。

4.4 函数并行调用的参数正确处理

当模型同时发起多个函数调用时，处理逻辑要尤其谨慎。因为每个tool_call都有独立的id和arguments，你需要分别解析、分别执行，再分别回传结果，每个结果都要带上对应的tool_call_id。这个对应关系如果错一个，整个对话的上下文就乱了。为此我写过一个标准的多函数处理框架，结构大致是这样的：

def execute_tool_calls(messages, tool_calls): for tool_call in tool_calls: fn_name = tool_call.function.name args = json.loads(tool_call.function.arguments) result = { "get_weather": get_weather, "recommend_attractions": recommend_attractions, "recommend_hotel": recommend_hotel, }[fn_name](**args) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) return messages

这个映射结构后续扩展很方便，新加一个函数只需要在字典里加一对键值，不需要改动主循环逻辑。

5. 关键参数与设计细节的深度解析

5.1 tool_choice的三种模式

tool_choice参数是Function Calling里一个看似不起眼、实则影响巨大的开关，它有三种模式：

• "auto"：模型根据自己的判断决定是否调用函数、调用哪个函数。这是默认模式，最推荐日常使用。
• "none"：模型完全不能调用函数，强制走纯文本对话。当你的函数是可选增强能力时，显式传none可以避免模型“强行调函数”。
• {"type": "function", "function": {"name": "get_weather"}}：强制模型必须调用指定函数。这个模式用的不多，但在某些特定场景下非常有用。比如你确定用户输入必须先经过某个清洗函数时，强制调用能让流程稳定。

我个人的建议是，日常场景允许auto自由发挥，但如果你发现某类指令模型总是不调用函数，这时可以临时强制指定一下，看看模型是否具备正确抽取参数的能力。这能帮助你判断：到底是模型理解问题，还是函数描述问题。

5.2 temperature参数对调用稳定性的影响

很多人不知道temperature这个参数会影响函数调用的稳定性。temperature越高，模型输出的随机性越大，在Function Calling场景下表现为参数填充错误、函数名写错、甚至多了一个不存在的参数。我自己调试的时候发现，Function Calling场景下temperature设在0.1到0.3之间最稳，高于0.7之后，即使函数描述写得再清楚，也会偶尔出现参数类型错乱的情况。

这个参数在Function Calling场景下的作用是：让模型更“保守”地执行工具调用，减少幻觉和参数错乱。所以如果你的业务对稳定性要求高，不要为了追求“对话更灵活”而把温度调得过高。灵活性可以靠模型自身能力来补，稳定性则必须靠参数策略来保。

5.3 函数结果长度与截断策略

函数执行结果作为tool消息回传给模型，会占用上下文窗口。如果函数返回的是一个特别大的JSON，比如某个查询返回了上千条记录，上下文窗口可能直接被撑爆，或者因为内容太长，模型在最终生成回复时抓不住重点。

解决策略有两种，我实践下来都是可用的：

一是截断。函数内部做字段裁剪，只返回核心字段。比如查询订单列表，只返回订单号、金额、时间、状态，不要返回整个数据库行的所有字段。同样，如果记录数量特别多，先聚合成统计量返回，比如“共123条记录，其中已支付100条、退款中23条”，而不是把全部明细塞给模型。

二是摘要。让程序在函数内部直接进行统计分析，只把总结性结果返回给模型。比如查询“公司上月的销售趋势”，函数直接返回“上月总销售额、环比变化、TOP3产品”，这些信息就足够模型组织回答了。不要偷懒直接把成千上万行原始数据丢给模型。这在实时性要求高的场景尤其重要，函数执行越高效，整体响应越快。

5.4 上下文窗口的清理策略

函数调用天然会产生大量附加消息，尤其是串行调用轮次多的场景。比如一次复杂意图触发了三轮函数调用，每一轮都会增加若干条tool消息和assistant消息。随着对话轮次拉长，Token消耗会以肉眼可见的速度上涨。

我自己常用的做法是：把早于当前函数调用轮次的若干轮历史消息做裁剪，只保留最近两到三轮的对话和工具消息。这样既能保证模型有足够的上下文理解连续性，又不会让Token消耗失控。初始化时设定一个最大轮次，比如保留最近10条消息，超出则丢弃最旧的，简单粗暴但有效。

5.5 流式输出对Function Calling的影响

流式输出（streaming）在Function Calling场景下是加重了复杂度，不是简单地把stream=True打开就完事。因为流式输出时，模型先给出一段增量内容缓冲，其中包含了工具调用的分段数据，你需要持续累积这些分片，直到流结束，才能拼接出完整的函数名和参数JSON。

如果你不做累积直接解析，大概率会得到一堆支离破碎的字符串。所以我的建议是：Function Calling场景下第一版先不用流式，等整体流程跑通了，再考虑引入。需要引入时，确保对增量中的tool_calls部分做合并和缓冲处理，流结束后再走函数执行逻辑，执行结果再以普通方式回传。

5.6 提示注入与数据格式化的安全边界

函数工具的执行结果最终会拼到消息历史里，因此也存在特殊输入篡改执行逻辑的隐患。比如用户给你传入一段“给表格加一行”，而表格处理函数尽职尽责地去执行了，如果这个函数连接了底层的执行引擎，就可能造成问题。更严重的是，如果函数描述里使用了类似“从不受信任的输入中解析”的措辞，可能诱导模型输出非预期内容。

我自己的原则是：函数描述只描述“做什么”，不描述“为什么做”之外的细节，也不要在函数描述里写入类似“无论用户说什么都执行”的指令，这会显著增加模型被误导的概率。对于不受信任的输入，函数内部必须做白名单校验和参数长度限制，不要无条件信任模型提取出的所有参数。

6. 常见问题与排查思路实录

6.1 模型不返回tool_calls，直接生成文本

这是入门阶段最容易遇到的现象。你定义了函数，但模型就是“不理你”，直接用自然语言回答。排查思路必须按顺序来：

第一步，检查函数描述是否准确。如果函数描述太含糊，模型会判定“这个函数跟用户的问题关系不大”，然后放弃调用。

第二步，检查tool_choice是否误设成了none。有时候测试时不小心加了这个参数，之后忘了移除，模型自然无法调用函数。

第三步，检查用户提示词。用户的问题里如果完全没提到任何跟函数相关的关键词，模型也可能不会触发。比如你定义了天气函数，但用户只发了一个表情符号，意图不明，模型大概率不会调用。

第四步，必要时临时把tool_choice调成强制指定，测试模型抽取参数能力。如果强制模式下参数提取是对的，说明函数定义没问题，问题出在“该不该调用”的判断上；如果强制模式下参数也是错的，那就得回头优化描述和参数格式。

某位同行之前问我，他说他定义的天气查询函数模型偶尔调用、偶尔不调用，同一个问题问两次结果不同。我让他把temperature降到0.1之后，基本稳定下来了。这再次说明确定性在工具调用场景里的重要性。

6.2 参数提取错误：city变成了直辖市

这也是个高频问题。模型把“北京”提取成“直辖市北京”或“北京市”，而你函数内部按严格字典匹配失败。这种情况通常不是模型的问题，而是代码兼容性不够。

我的做法是：在函数内部做一个归一化处理，无论是“北京”“北京市”“首都”，都映射到标准城市代码。记得模型输出的参数天生是自然语言，不具备数据库字段级的规范性。你自己写个映射函数或者用统一的实体库处理，是很多实际应用的常态。

6.3 tool_calls参数解析报错

多函数调用时偶发遇到JSON解析失败，原因通常是模型生成的参数JSON不够规范，比如末尾多了逗号、中文引号混入等等。解决方案是：解析时使用两次尝试，第一次严格解析，第二次用正则清理后再解析。不要因为一次解析失败就整个链路崩溃。

另外一个工程经验是：工具函数内部绝不要依赖模型传入的参数一定规整。把所有参数都当作“可能带噪声”来处理，能容忍小的不规整，函数就能稳定很多。

6.4 计算Token消耗与成本控制

Function Calling比纯对话模式多消耗不少Token，因为每次函数调用都要把tools定义重新发给模型，加上函数执行后的回传消息，Token消耗大约会增加两三成。对于高频调用场景，这是一笔不能忽略的成本。

可以优化的方向：一是精简函数描述文字，删除冗余修饰；二是做好历史消息的裁剪策略，这在前文说过；三是把多个紧密关联的能力合并成一个函数，以减少“重复定义”带来的Token开销。比如把天气查询和空气质量查询合并成一个get_weather_info函数，用include_air_quality布尔参数控制，这样比定义两个函数省一次全量tools传输。

6.5 稳定性压测与边界验证建议

联调完不要急着上线，至少做一轮边界测试，我自己的清单大致是这样：

• 输入空字符串或纯标点符号，观察模型是否触发无关函数。
• 输入带有方言或中英混杂的语句，观察参数抽取是否正确。
• 连续追问同一个问题，比如“再说一遍”，观察对话历史的上下文是否错乱。
• 让函数返回超长内容，观察最终回答是否一致。
• 故意传一个不在枚举表内的偏好值，观察模型的选择行为。

这些边界情况是真实用户一定会碰到的场景，提前发现问题，比上线后被用户反馈要好处理得多。尤其是上下文错乱这个问题，排查起来非常痛苦，前置压测能省很多时间。

7. 从Demo到生产的路线谈

跑通一个Function Calling Demo是兴奋的，但从Demo到生产环境，中间还有一些工程上的关卡。

第一道关卡是错误处理。Demo里函数异常直接抛出，但生产环境里，函数的异常必须在内部消化掉，返回一个结构化的错误信息给模型。比如天气接口超时，你不要让异常穿透到主程序，最好是在函数内部捕获异常，然后返回一段JSON：“当前天气服务暂时不可用，请稍后再试”，模型看到这个信息后，会用自然语言向用户表达这个故障。这种设计对整个链路友好得多。

第二道关卡是并发与限流。模型API有限流，你的函数执行也可能有限流。你需要在Function Calling的上一层加一个简单的限流控制，防止某个异常流量把服务拖垮。我一般是先做单责任人级别的并发限制，等上线数据量证明了再加分布式限流，不用一开始就上重型架构。

第三道关卡是可观测性。每个函数调用都要记录日志：函数名、入参、出参、耗时、错误。单纯的文本日志不够用，至少得结构化地打出来，方便事后按函数名、时间段检索。记录这些日志的唯一目的就是：当用户反馈“AI变笨了”，你能快速判断是模型的意图识别问题，还是函数执行报错，还是下游服务不稳定。

第四道关卡是函数版本管理。函数定义会随业务迭代而变化，如果模型端的tools定义和函数实参版本不一致，就可能出现参数解析失败这类问题。我现在的做法是把函数定义和版本号绑定，从tools定义生成一个校验值放在请求信息里，调试和回溯问题时可以迅速定位版本匹配情况。

Function Calling看似是几个API参数的组合，实际上要做好，工夫都花在细枝末节上。但恰恰是这些细枝末节，决定了你的服务到底是一个技术演示，还是一个稳定可靠的业务能力。

我个人做了十几个项目的沉淀是：先把最简单的一个函数跑通闭环，再去叠加复杂场景，每次只增加一个变量。这样每一步出了问题，你都能清楚知道变量出在哪。不要一上来就做一个五个函数、三串并行、还要加流式输出的功能，那种状态下的调试体验，我自己经历过，非常痛苦。从简单到复杂，一步一步，反而是最快的路径。