企业官网建设流程全解析

直接说你有没有遇到过这种场景：想让模型去查一下天气、算一笔账、调一个内部接口，结果它一本正经地胡编乱造。以前做大模型应用，最头疼的就是模型活在"语言世界"里，碰不到"现实世界"的数据。Function Calling（函数调用）这个东西出来之后，等于给模型装了一双手，让它能把对话里的意图翻译成程序能执行的指令。这篇文章我会把Function Calling从原理到代码完整拆开，包括底层机制、一次函数是怎么被"编排"起来的、实际联调中最容易翻车的几个细节，以及哪些场景其实不适合硬上Function Calling。整篇内容偏向实战，代码以Python为主，框架层面会兼顾OpenAI SDK和通用的函数协议写法，适合那些已经在做LLM应用但感觉模型输出不够可控的开发者。

1. Function Calling解决的不是"联网"，而是"模型与系统的握手问题"

先说一个最常见的误解：很多人觉得Function Calling是让模型去"联网搜索"，其实完全不是一回事。联网搜索只是函数调用里的一个具体案例，Function Calling真正解决的是模型如何与外部系统安全、准确、可验证地交互。

模型本身是一个概率性的文本生成系统，它没有"真实执行"的能力。你问它"今天北京天气怎么样"，它只能根据训练数据里见过的类似表述去猜测，猜对了是运气，猜错了就是一本正经地胡说八道。Function Calling的核心思路是：让模型根据自己的能力边界，把用户的自然语言请求转化为一个结构化的"函数调用声明"——函数名、参数、必要的说明——然后由我们自己的代码去真正执行这个调用，再把执行结果返回给模型，让模型基于真实结果生成最终回复。

这个设计把"智能"和"求真"拆开了。模型负责理解意图、抽取关键参数、判断调用顺序，我们的代码负责处理真实世界的数据，两者通过一次结构化的中间表示完成握手。正因为中间这一层是结构化数据，不是让模型生成JSON字符串，而是模型直接输出一个可校验的函数调用结构，所以我们才能对模型的行为做约束、校验、容错和审计。

从工程角度看，这其实是把不可控的自由文本输出，压缩到了一个受控的动作空间里。你可以把Function Calling理解成"给模型发了一张只能填固定空白的表格"，而不是让它随便写一篇小作文。模型不能发明函数，只能在开发者预先定义好的函数列表里做选择和组合，这从源头就限制了幻觉风险。

我自己在实际项目里的体会是：Function Calling把"模型能力"和"业务确定性"完成了解耦。业务逻辑该怎么执行，是工程师说了算；模型只负责回答"应该调用哪个、参数是什么"。只要这个分工想清楚了，后面不管接SQL、接HTTP接口，还是接内部流程工具，路都是通的。

2. 一次完整的函数调用，模型的内部决策拆解

要写好Function Calling的代码，第一步是把"一次函数调用生命周期"完整吃透。我见过很多开发者在代码里东抄一行西抄一段，报错就换字段名，最后跑通了也不明白为什么某些参数必须那样传。

2.1 从用户输入到函数选择：模型如何理解工具清单

当我们在API请求里传tools参数时，实际上做了一件很重要的事：我们不是在"告诉"模型怎么做事，而是在"描述"可选的世界行为。

每个tools条目里包含函数名、函数描述、参数Schema。注意，函数名和描述是模型用来做选择判断的关键依据，很多开发者不重视描述字段，随便写一句话，结果模型经常选错函数。我的经验是：函数描述要写清楚"这个函数解决什么问题，在什么情境下应该用，什么情境下不应该用"。

举个例子，如果你同时定义了get_current_weather和get_weather_forecast两个函数，描述里只是简单地写"获取天气"和"获取天气预报"，模型很容易在用户需要"未来五天天气"时调用错。正确写法是：

• get_current_weather：当用户询问当前天气状况时使用，提供城市名、地区或邮编作为参数。
• get_weather_forecast：当用户询问未来若干天的天气预报时使用，提供城市名、天数范围作为参数。

描述越具体，模型的工具选择准确率越高。这不是玄学，而是模型底层机制决定的：模型在生成下一个token时，会对所有候选函数做语义相似度计算，描述文本就是它唯一的判断依据。

2.2 工具参数Schema：模型是按你的约束生成结构的

第二个关键点是参数Schema。Function Calling允许模型自由发挥的空间，完全由你定义的参数Schema决定。

比如天气函数的参数location，如果你只定义成"type": "string"，模型会填"北京"也可能填"Beijing"，还可能填"北京市朝阳区"，同一个语义实体出现各种变体，你后端做映射时头都要大。正确的做法是用枚举约束，或者在描述里给出固定的格式要求。

再比如天数参数days，如果你不限定取值范围，模型可能填1也可能填999，你业务上根本不可能支持999天。加上"minimum": 1, "maximum": 14之后，模型输出的参数就会落在合法区间内。

有一点需要特别说明：Schema约束不是强约束。模型在理解上下文不充分的情况下，仍可能输出不符合Schema的参数。你不能把安全性寄托在模型自觉上，后端的参数校验和兜底逻辑必须存在。Scheme的作用是"提高正确率"而不是"保证正确率"。

2.3 工具调用的循环决策与停止条件

Function Calling的完整生命周期不是"用户问一句、模型答一句"那么简单。如果需要调用函数，模型第一轮返回的不是对用户的回复，而是一个tool_calls结构。这时候我们必须：

1. 解析出函数名和参数；
2. 在自己的代码里真正执行函数；
3. 把执行结果以role: "tool"的消息追加回对话历史；
4. 再次把完整对话历史发给模型。

这个循环可能会发生多次。因为某些复杂任务需要先查A再查B，甚至查完B之后模型判断还需要补一个C。所以每次模型返回tool_calls，我们就循环执行，直到模型返回的是普通对话内容为止。

这里有个特别容易被忽视的点：你在第二轮发给模型的时候，之前的对话历史、第一轮的tool_calls、以及第一轮的函数执行结果，都必须完整保留。很多人只把最新结果怼回去，模型完全没有上下文参照，答非所问。

我自己常用的循环终止条件有两个：一是模型响应的finish_reason变为stop，二是tool_calls字段为空。两个条件其实等价，但不同SDK里表现略有差异，稳妥做法是两者都判断。

2.4 为什么函数调用是在"对话体系"里完成的，而不是独立API

有些读者可能会问：既然Function Calling本质上就是"产生结构化指令"，为什么不单独拆一个API让模型输出一段规划，然后再去做执行？这个问题的答案是：独立的函数规划模型和全链路对话模型是两种粒度，前者处理的是单个任务，后者处理的是一段对话里可能出现的多轮工具切换。

在真实业务里，用户常常边说边改需求："查一下上海的天气……哦不对，查杭州下周的天气，然后顺便帮我看看杭州有什么好玩的。"如果拆成独立规划API，这种中途变化很难处理。而放在对话体系里，模型自己会根据用户的新指令重新决策函数调用，甚至推翻上一轮的选择，这才是和真人助手最接近的交互体验。

所以Function Calling设计的核心哲学就是：工具调用不是脱离对话的"附加功能"，而是对话内部展开的"行动计划"。对话历史既是模型的记忆，也是模型组织计划的空间。

3. 从零搭一个Function Calling服务：代码实操与关键参数

理论部分讲清楚了，接下来上代码。我会以Python环境为例，使用OpenAI兼容的SDK写法，因为这个协议目前是事实标准，所有主流国产模型和开源模型都做了适配，后续迁移成本最低。

3.1 环境准备与大模型服务选择

你需要准备一个支持Function Calling的模型接口。常见的选择有：

• OpenAI系列模型
• 国产的各类商用大模型（比如通义千问、文心一言、智谱GLM等）
• 开源的Qwen、DeepSeek等模型，通过vLLM部署后自带OpenAI兼容协议

无论选哪一家，代码层面的差别只在base_url和api_key上。下面我以通用写法做演示，你只需要替换成你自己的接口地址和密钥就能跑通。

pip install openai

这里提醒一句：如果你用的是国产模型，很多SDK版本要求比较绕，建议直接用openai库并设置base_url，比用各家自己的SDK更省心，因为各家SDK的接口签名经常升级，参考文档的代码动不动就废弃，而OpenAI兼容协议反而稳定。

3.2 定义你的第一个工具函数：天气预报场景

我们的目标是实现一个"天气助手"，能理解自然语言请求，调用天气查询函数，再基于查询结果生成回复。为了完全可控，我没有接真实天气API，而是用两个伪造函数模拟真实的数据返回。

import json import random from openai import OpenAI client = OpenAI( base_url="https://your-llm-api.example.com/v1", # 换成你的服务地址 api_key="your-api-key", # 换成你的密钥 ) # 模拟真实天气服务：实际项目中这里应该是HTTP调用或RPC调用 def get_current_weather(location: str, unit: str = "celsius") -> dict: """查询指定地点当前天气的真实状态""" # 这里实际应该调一个天气API，比如 open-meteo、和风天气等，返回结构化数据 # 为了演示，这里直接生成一个随机结果，并构造一条"业务报文" temp_map = { "北京": random.choice([0, 5, 10, 15, 20]), "杭州": random.choice([12, 16, 18, 22, 25]), "广州": random.choice([20, 24, 26, 28, 30]), } return { "location": location, "temperature": temp_map.get(location, 15), "unit": unit, "condition": random.choice(["晴", "多云", "小雨", "阴"]), } def get_weather_forecast(location: str, days: int) -> dict: """查询指定地点未来days天的天气预报""" temp_list = [random.randint(-5, 30) for _ in range(days)] return { "location": location, "forecast_days": temp_list, "unit": "celsius", }

这里有一个工程上的建议：工具函数都写成纯函数或者与业务逻辑解耦的模块，不要在工具函数内部写复杂的业务判断，最好只做"参数校验+调用真实服务+返回结构化数据"，这样后期接真实API时不需要重构整个对话流程。

3.3 将工具和Schema一起发送给模型

接下来把函数定义成tools。这里展示我推荐的Schema写法，直接使用JSON Schema格式：

tools = [ { "type": "function", "function": { "name": "get_current_weather", "description": "当用户询问某个地点当前的天气状况时使用，参数location必须是城市名，unit设定温度单位", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名，例如：北京、杭州、广州" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位，默认摄氏" } }, "required": ["location"] } } }, { "type": "function", "function": { "name": "get_weather_forecast", "description": "当用户询问未来某几天的天气预报时使用，例如'下周天气'或'未来三天天气'", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名，例如：北京、杭州、广州" }, "days": { "type": "integer", "minimum": 1, "maximum": 14, "description": "要查询的天数" } }, "required": ["location", "days"] } } } ]

我特别想强调一下description字段的重要性。模型没有"试运行"的能力，它判断什么时候调用哪个函数，唯一依据就是这段描述文本。描述里不仅要说"该函数做什么"，还要写清"什么时候调用、什么时候不要调用"。比如对get_current_weather，如果用户说"北京今天适合出去玩吗"，模型应该调当前天气；如果用户说"北京这两天天气怎么样"，这应该调用预报函数。这些语义边界写进描述后，工具选择的准确率会有非常明显的提升。

3.4 主循环：请求、解析、执行、回填、再生成

下面是核心对话循环。这也是整个Function Calling的骨架逻辑，值得反复琢磨。

def run_conversation(user_query): messages = [{"role": "user", "content": user_query}] # 第一轮请求：让模型决定是否调用工具 response = client.chat.completions.create( model="your-model-name", # 替换成实际模型名，例如 qwen-plus 或 gpt-4o messages=messages, tools=tools, tool_choice="auto", ) assistant_message = response.choices[0].message # 关键判断：如果模型返回了tool_calls，就说明它想调用函数 if assistant_message.tool_calls: messages.append(assistant_message) # 逐一处理模型想要调用的函数 for tool_call in assistant_message.tool_calls: function_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) print(f"[执行] 调用函数: {function_name}, 参数: {arguments}") # 这里用字典分发函数，避免大段if-else function_map = { "get_current_weather": get_current_weather, "get_weather_forecast": get_weather_forecast, } result = function_map[function_name](**arguments) # 把工具执行结果追加到对话历史中，role必须是tool messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False), }) # 携带完整对话历史再次请求，让模型基于真实结果生成回复 second_response = client.chat.completions.create( model="your-model-name", messages=messages, tools=tools, ) return second_response.choices[0].message.content return assistant_message.content print(run_conversation("北京今天天气怎么样？适合出门吗？")) print(run_conversation("未来三天杭州的天气怎么样？"))

这段代码的可复用性在于function_map分发机制。后续要加新函数，只需要在tools里加一条定义，同时在function_map里注册对应的可调用对象，主循环逻辑完全不用动。比起写十几个if function_name == "xxx"，这种分发方式维护起来舒服得多。

3.5 多工具连续调用的正确处理方式

上面的示例假设模型一次最多调用一个工具。但真实场景里模型可能同时发起多个工具调用，比如用户问"比一比北京和广州今天气温"，模型有可能同时发起两个get_current_weather调用。这时代码里的for tool_call in assistant_message.tool_calls就会起到作用，它会依次执行两个调用、依次追加结果。

这里有个实践经验：并发调用比顺序调用好，但要注意服务限流。如果你的后端弱，或者外部API有限频，顺序执行反而更安全。大多数SDK允许一次返回多个tool_calls，但真实外部服务未必能扛住并发压力，稳妥起见建议设置一个MAX_PARALLEL_TOOL_CALLS参数控制并发量。

还应当考虑多轮调用的情形：第一轮执行完两个天气查询后，模型还可能觉得需要"再查一下空气质量"，然后继续发起新调用。所以不要只做"两次请求"，而是把它做成一个while循环，直到模型不再返回tool_calls为止。

3.6 一个健壮版的多轮循环框架

下面我给出一个能处理任意轮次工具调用的完整框架，这套骨架在多次生产项目中稳定运行，建议收藏。

def run_multi_tool_conversation(user_query, max_iterations=5): messages = [{"role": "user", "content": user_query}] iterations = 0 while iterations < max_iterations: iterations += 1 response = client.chat.completions.create( model="your-model-name", messages=messages, tools=tools, tool_choice="auto", ) assistant_message = response.choices[0].message # 没有tool_calls时，说明模型已准备好最终回复 if not assistant_message.tool_calls: return assistant_message.content messages.append(assistant_message) for tool_call in assistant_message.tool_calls: function_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) # 越界保护：参数解析失败时绝不能中断整个对话 try: result = function_map[function_name](**arguments) except Exception as e: result = {"error": str(e), "message": f"函数{function_name}执行失败"} messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False), }) return "已达到最大工具调用轮次，终止对话。"

max_iterations这个参数很关键，它能防止模型进入"工具调用死循环"——比如A函数的结果喂回去后，模型又调A，来回不停。实际项目里常见的问题是模型对某个工具"上瘾"，每次对话都触发调用，这时候轮次上限就是最后的兜底保障。

4. 参数细节与真实项目中的微调心得

代码跑通只是开始。从"能跑"到"在复杂业务里稳定产出"，中间隔着一堆细节。下面挑几个最影响结果的部分展开说。

4.1tool_choice参数：auto、none与forced的使用边界

默认情况下我们传tool_choice="auto"，让模型自己判断"是否需要调用函数、调用哪个函数"。这适用于大多数场景。但某些业务场景下你需要强制行为。

• tool_choice="none"：强制模型不得调用任何工具，只能基于对话内容直接回复。适合纯闲聊阶段、或者在开场白阶段不期望模型去拉任何数据时使用。
• tool_choice="required"或者直接指定函数名（如{"type": "function", "function": {"name": "get_current_weather"}}）：强制模型必须调用某个函数。适合"用户请求必须落库"的流程，比如必须先查询再回答的场景。

我在实际项目里遇到一个比较隐晦的问题：当对话进入多轮、上下文变长之后，auto模式下模型偶尔会"忘掉"该调用工具，直接凭记忆作答。这时在关键业务节点上强制tool_choice能稳定输出。这算是一个小技巧：业务里如果需要"先查后答"，就主动在对应节点传递tool_choice指定函数，不要依赖模型自觉。

4.2 工具参数里的枚举、默认值与required字段

写JSON Schema时，最容易犯的错误是过度约束。以为约束越多模型越准确，结果模型频繁返回"参数不完整"或者触发校验失败，最后还得自己写一堆修正逻辑。

我的建议是：

• 凡是模型很难判断或经常乱填的字段，都设置required；
• 凡是可选字段，尽量给默认值。
• 枚举字段一定要给足可选项，不要留"其他"。模型遇到不在枚举里的值时会自动选一个最接近的，如果你enum里给的是["celsius", "fahrenheit"]，用户说"用华氏"，模型能正确映射；如果你给的是["摄氏", "华氏"]，模型也会尝试映射，但准确性会下降。

参数命名最好贴近常见语言习惯。比如用英文名称location而不要用拼音缩写loc，模型对标准英文参数名的理解远好于自定义缩写。

4.3 函数执行出错时，错误信息该如何喂回模型

这一点值得单独拎出来说。工具执行阶段经常会发生外部API超时、参数不合法、权限校验失败等问题。这时候最忌讳的做法是：直接抛异常让整个对话崩掉，或者把一段晦涩的堆栈文本丢回给模型。

正确做法是把错误包装成"工具返回数据"，用结构化的错误说明发给模型，让它自己决定下一步是修正参数重试，还是用自然语言向用户解释失败原因。举个例子：

result = { "status": "error", "error_code": "RATE_LIMITED", "message": "天气服务暂时不可用，请稍后重试或改用其他城市查询" }

模型收到这种结果后，通常会生成一段"抱歉，天气服务暂时不可用，建议你稍后再试"的回复——体验上远好于抛出异常让用户面对一个错误页面。这个设计思路，本质上是把"系统异常"也变成了模型上下文的一部分，让模型充当解释器和缓冲器。

4.4 上下文长度：函数定义会占用大量tokens

每次请求都要把tools完整传进上下文，也就是说函数定义占用的是每一轮请求的token成本。如果你的函数列表特别多，一次请求可能会消耗上千甚至几千token。

几个优化策略：

• 只传当前场景可能用到的函数，不要把所有函数都塞进去。比如用户明确问天气，就别传电商相关的函数。你需要做一层分类路由，根据第一轮意图筛选工具子集。
• 精简函数描述。描述写得精炼但信息密度高，不要堆砌无关的营销文案。
• 复用一个长期对话时，可以考虑把不常调用的工具定义移出后续轮次，只保留当前上下文需要的核心函数。

实测下来，工具筛选策略处理得好不好，直接影响响应速度和账号消耗。一个大列表每次都传到服务端，不仅仅是钱的问题，模型在大量候选函数里做选择也更容易出错。

5. 排查链路：Function Calling联合调试地图

任何功能上了生产环境，就一定会有排查需求的。我这里把实际排障中总结出的一个"三段式"排查链路写出来，按这个顺序基本能覆盖绝大多数问题。

5.1 第一段排查：模型到底有没有正确识别函数

当模型没有返回预期的工具调用时，第一件事不是改代码，而是去查看模型的完整响应。把response.choices[0].message整个打出来，看看tool_calls字段到底是什么：

• 如果tool_calls为空，说明模型判断不需要调用任何自定义工具，这时候问题出在tools定义或description上。常见原因：函数描述和用户问题语义差距太大；参数Schema不完整导致模型认为信息不足无法调用；或者tool_choice="none"被错误设置。
• 如果tool_calls存在但函数名不对，说明多个函数的描述文本区分度不够。比如两个函数描述都提到了"天气"，模型就分不清该用哪个。
• 如果函数名对但参数内容不对，通常是Schema约束太宽松或者类型定义错误。比如你把天数days定义成字符串，模型就很可能填"三天"而不是3。

这个阶段的核心要领就是：不要凭感觉改代码，要把模型的"意图层"打印出来看。模型想不想调、想调哪个、想怎么调，在这个字段里一目了然。

5.2 第二段排查：工具执行链路是否稳定

确认模型调用正确之后，下一个排查点是工具本身的执行链路。我见过不少项目在本地联调时一切正常，一上生产环境外部API就开始超时或返回异常数据结构。

这里有几个必查项：

• 工具函数有没有做超时控制。外部HTTP调用没有超时设置会直接拖垮整个对话响应时间，建议统一给工具函数包一层timeout。
• 工具返回的数据类型是否和你Schema里定义的一致。比如模型预期return是{"temperature": 20}，你后端返回了字符串"20°C"，模型在做最终总结时容易产生错误理解。
• 工具内是否有重试机制。在大模型场景里，单次工具调用失败率其实不低，如果函数内部能做一次重试，对话成功率会明显提升。

我的建议是：给每个工具函数都设计统一的返回结构，比如{"status": "success" | "error", "data": ..., "message": ...}，这样模型更容易理解，排查时也更好抓日志。

5.3 第三段排查：生成阶段为什么还在幻觉

最后一段问题跟模型无关，跟Prompt写法有关。模型收到工具返回的真实数据后，在生成最终回复时仍然可能"润色"过头——比如天气服务明明返回25度，模型却说成"接近30度，注意防晒"。这是因为模型在tokens生成阶段会根据语言习惯对数字做近似的口语化表达。

解决方法是在系统提示词里加一条硬性规定："你必须严格依据函数返回的数据作答，不得修改具体数值，不得推测函数未提供的信息。"实测这个提示词能显著降低数值型数据的失真率。如果还不行，就在最终消息生成前做一次校验，用规则检查敏感数值是否与工具返回一致，不一致就强制用模板化回复兜底。

5.4 常见错误对照表：遇到问题先查这张表

这张表我每次培训新同事时都直接贴出来，很多问题看一遍就能定位到具体原因。

6. 进阶经验：把Function Calling做成一套可复用的能力模块

上面讲的是单点功能，到真实项目里你要面对的往往是几十个函数、多个场景、多种模型切换。下面分享几个关于架构设计的经验，帮你把Function Calling从"一个demo"变成"一个能力平台"。

6.1 函数注册中心的自动发现机制

当函数数量多起来之后，手工维护tools列表和function_map会越来越痛苦。我建议用装饰器做一个函数注册中心，这样每写一个新的工具函数，它就会被自动收集到定义列表和调用映射里。

TOOL_REGISTRY = {} def register_tool(description: str, schema: dict): def decorator(func): func_name = func.__name__ TOOL_REGISTRY[func_name] = { "function": func, "description": description, "parameters": schema, } return func return decorator @register_tool( description="查询指定地点当前天气状况", schema={ "type": "object", "properties": { "location": {"type": "string", "description": "城市名"} }, "required": ["location"] } ) def get_current_weather(location: str): # 实际查询逻辑 pass

然后生成tools列表时，只需要遍历TOOL_REGISTRY自动把定义拼出来，调用分发时也从注册中心取函数。新增一个工具函数，代码层面只加一个函数和装饰器，主循环零改动。这个模式是我在维护十几个工具函数时总结出来的，强烈推荐。

6.2 场景化工具编排：同一个函数不同场景给不同描述

有时候同一个后端函数在不同场景下，想让它触发的方式完全不同。比如同一个"查用户信息"的接口，在客服场景里希望模型在用户咨询订单问题时调用，在风控场景里希望模型在用户身份核验时调用。你不需要写两个函数，只要在场景A和场景B分别维护不同的tools描述文本，指向同一个注册函数。

实现上就是为每个场景维护一个SCENARIO_TOOLS配置，里面按需筛选注册中心里的函数，并允许覆盖description。这样"函数实现"和"触发策略"完全解耦，不同业务线之间可以共享底层能力，同时各配各的触发规则。

6.3 加入验证层：工具的参数不合法时主动修复

Schema校验之外，我强烈建议再做一层"业务校验"。比如查询天气的城市名"北京市朝阳区望京SOHO"这种经过模型推断但可能过拟合的输入，虽然格式合法但实际城市服务不认识。这层校验要做两件事：

• 用正则或字典把模型输出映射为你知道能处理的格式
• 校验不通过时，不直接失败，而是生成一条"参数错误信息"返回给模型，引导模型重新给出正确参数

典型做法是把修正后的错误信息与合法格式示例一起包装返回，模型读了之后大概率自己能纠正过来。这个"工具返回错误再纠正"的链路，比一味加正则去堵漏洞要优雅得多。

6.4 日志与审计：不要忽视Function Calling的观测性

Function Calling本质上把模型带入了业务系统的"执行层"，这意味着你必须有完整的日志记录。我的做法是：每一次工具调用都记录用户请求、模型判断、工具参数、工具返回、最终回复、耗时、模型消耗的token数。

有了这些日志之后，至少能回答这五个问题：

1. 用户最后到底得到了什么答案？
2. 模型有没有调用它不该调用的函数？
3. 工具调用失败是哪一环导致的？
4. 每次对话平均消耗多少token？
5. 哪个函数被调用的最多，哪个定义最容易被误解？

尤其是第五个问题，它能反向指导你优化函数描述。如果某函数被"误调用"的频率很高，多半是描述和参数Schema写得有歧义。

7. 哪些场景不适合硬上Function Calling

最后必须泼一盆冷水：Function Calling不是万灵药，有些场景硬上反而会让系统更复杂、更脆弱。

7.1 高频低延迟查询场景

如果用户请求大部分时候只查一个固定列表，比如查一下自己的订单状态，这种方式通过一个函数调用绕了好大一圈：模型解析参数、工具执行、再让模型总结，链路慢且token开销大。如果你的场景可以用规则直接命中，就没必要让模型参与决策。比如订单查询，直接用ICD12"你的订单编号是xxx"去查数据库更简单。模型应该在用户用自然语言表达模糊需求时介入，而不是对每个请求都做一次"工具调用编排"。

7.2 必须保证100%确定性的场景

Function Calling本身是概率性的。哪怕模型已经训练得很稳，它仍可能在某些极端上下文里选错函数、填错参数。如果你的场景涉及支付操作、权限变更、删除数据这类"不可回退"动作，不能单纯依赖模型的函数选择判断。

这类高风险动作的正解是把Function Calling的决策结果作为"建议动作"，在代码里增加二次确认或者人为审批环节，绝不能把最终执行权完全交给一个概率模型。我之前处理过一个案例：某团队让模型自动调用"删除用户"的接口，结果用户说了一句反话，模型当真就去调删了，幸好后面加了审批流才没出事。

7.3 上下文已经超长的长对话

Function Calling需要把工具定义和完整历史一起传给模型，这会让上下文长度压力雪上加霜。当对话已经有几十轮时，再叠加几十个工具定义，很容易触发上下文窗口上限。这时候需要考虑分段记忆方案，把早前的对话摘要化，只保留当前轮次所需的工具列表。

7.4 工具数量过多（超过20个）时的退化现象

实测下来，当一次请求里塞进来的工具超过15到20个之后，模型的函数选择准确率会明显下降。这个现象在多个模型上都存在，原理上是模型在超长工具列表里的注意力开始分散。

解决思路一个是通过意图路由先缩小工具候选范围，另一个是把工具粒度变粗——将多个近似的功能合并成一个工具，用内部action字段区分。后者看似把单个函数变复杂了，但整体准确率往往更高。

8. 从Function Calling到Agent：下一步该往哪走

Function Calling是Agent体系的基石之一，但它只是一个"原子能力"，离真正的智能Agent还差一段。前面我们讲了"模型决定调用什么函数、我们负责执行"这一层，接下来的演进方向是让模型具备更强的规划和多步决策能力。

我最近在做的一个模拟项目X里，已经把Function Calling升级为了一套轻量的任务编排协议：模型第一次只决定"第一步该做什么"，执行完结果返回后，它再根据当前状态决定第二步。每走一步都重新审视上下文，而不是在开始时一次性列出完整计划。这种"边做边想"的循环加上缓存机制，比一次性Plan的鲁棒性高很多，推荐有兴趣的朋友在Function Calling基础稳定之后往这个方向探索。

另外一件事值得持续关注：越来越多的模型API开始原生支持"并行工具调用"和"结构化输出"能力。对工程师来说，这意味着可以少写很多解析和兜底代码，把精力放在真正的业务逻辑上。不过任何新特性上线前，都要先在小流量灰度环境里验证，不要拿生产环境的稳定性去赌模型行为。这一点我从做Function Calling的第一天到现在都一直坚持，也是最有价值的工程底线。

Function Calling适合当跳板，不能当终点。先把"模型能稳定调函数"这一步做扎实，后面的Agent能力、多步规划、记忆管理都会顺理成章地长出来。