Function Call一、Function Call 的本质原理首先要建立一个核心认知LLM 本身并不会“执行”函数。它的本质是 Token 预测机器。所谓 Function Calling流程是你定义工具告诉模型你有哪些函数、参数是什么格式用 JSON Schema 描述模型推理决策模型读完用户意图 工具列表判断“我需要调哪个工具”然后输出一段结构化的 JSON而不是自然语言你的代码接管解析这段 JSON拿到函数名和参数执行你本地/远端的真实逻辑结果回传把函数执行结果塞回对话上下文再次请求模型模型生成最终回答简单类比模型是“指挥官”只下指令你的代码是“士兵”负责干活并把战报回去汇报。更深层一点出于好奇我问的ai嘿嘿Function Calling 的实现本质上是约定 训练 工程封装三者协作的结果而非模型内部有什么特殊的函数调用开关。首先API 提供方如 OpenAI、硅基流动人为定义了统一的 JSON 协议格式——规定请求中如何传递函数定义、返回中用何种字段描述调用意图。其次模型本身并不理解函数这个概念它只是通过海量训练数据学会了在特定上下文格式下输出对应结构的文本当 API 服务器将函数定义和用户提问拼接成 Prompt 送入模型后模型所做的唯一事情就是逐 Token 预测续写而由于在训练阶段它见过大量给定函数描述 → 输出结构化 JSON的样本它会自然地续写出符合协议格式的调用指令例如tool_calls。最后API 服务器在接收到模型输出的文本流后会进行格式检测与包装将其结构化为整齐的 JSON 响应返回给你的代码由你的代码解析并执行真正的业务逻辑。换言之模型只是在模仿格式做文本续写协议是人为约定的标准而真正的函数执行永远发生在你的代码侧——这也是为什么不同模型在同一协议下的表现会有差异它们只是见过多少这种格式的训练数据的区别而非底层机制的不同。二、涉及的协议格式核心重点目前业界主要有两套格式这也是你刚才踩坑的原因旧版格式Legacy / Deprecated请求字段functions数组控制字段function_call返回字段message.function_call回传角色role: functionOpenAI 在 2023 年 6 月首发此格式现在部分老模型仍兼容但新模型和新平台如硅基流动更倾向新版。新版格式Current Standard / Tools API请求字段tools数组元素是{type: function, function: {...}}控制字段tool_choiceauto/none/required返回字段message.tool_calls数组支持并行调用回传角色role: tooltool_call_id关键区别一览表硅基流动SiliconFlow兼容 OpenAI 协议**强推荐用新版 ****tools**格式旧版functions在一些国产模型上可能不触发或行为不一致。三、主流平台/协议体系对比除了 OpenAI 系你以后可能还会遇到这些OpenAI 系我自己目前在用代表OpenAI 官方、硅基流动、DeepSeek、大部分兼容 API 的服务协议新版tools格式为主特点生态最大工程化程度最高Anthropic Claude 系协议toolstool_use/tool_result块格式理念与 OpenAI 新版高度相似但字段命名略有差异tool_usevstool_calls部分 SDK 可互相适配Google Gemini 系协议FunctionDeclaration格式也有自己的tools封装通过 Vertex AI 提供逻辑类似但字段名不同MCPModel Context Protocol—— 新趋势 下一章节给大家带来MCP的介绍和使用由 Anthropic 推动的工具描述标准化协议目标是解耦工具服务端按 MCP 标准暴露能力任何支持 MCP 的模型都能直接接入你目前用不着但未来做 Agent 开发会接触到相当于工具调用的“USB 标准接口”我给出我自己的代码仓库https://github.com/qianshb/cookbooks.git大家可以在终端设置环境变量把API-key设置为自己的然后去改改函数问问AI,看看回复
Function Call
发布时间：2026/6/29 18:29:58
Function Call一、Function Call 的本质原理首先要建立一个核心认知LLM 本身并不会“执行”函数。它的本质是 Token 预测机器。所谓 Function Calling流程是你定义工具告诉模型你有哪些函数、参数是什么格式用 JSON Schema 描述模型推理决策模型读完用户意图 工具列表判断“我需要调哪个工具”然后输出一段结构化的 JSON而不是自然语言你的代码接管解析这段 JSON拿到函数名和参数执行你本地/远端的真实逻辑结果回传把函数执行结果塞回对话上下文再次请求模型模型生成最终回答简单类比模型是“指挥官”只下指令你的代码是“士兵”负责干活并把战报回去汇报。更深层一点出于好奇我问的ai嘿嘿Function Calling 的实现本质上是约定 训练 工程封装三者协作的结果而非模型内部有什么特殊的函数调用开关。首先API 提供方如 OpenAI、硅基流动人为定义了统一的 JSON 协议格式——规定请求中如何传递函数定义、返回中用何种字段描述调用意图。其次模型本身并不理解函数这个概念它只是通过海量训练数据学会了在特定上下文格式下输出对应结构的文本当 API 服务器将函数定义和用户提问拼接成 Prompt 送入模型后模型所做的唯一事情就是逐 Token 预测续写而由于在训练阶段它见过大量给定函数描述 → 输出结构化 JSON的样本它会自然地续写出符合协议格式的调用指令例如tool_calls。最后API 服务器在接收到模型输出的文本流后会进行格式检测与包装将其结构化为整齐的 JSON 响应返回给你的代码由你的代码解析并执行真正的业务逻辑。换言之模型只是在模仿格式做文本续写协议是人为约定的标准而真正的函数执行永远发生在你的代码侧——这也是为什么不同模型在同一协议下的表现会有差异它们只是见过多少这种格式的训练数据的区别而非底层机制的不同。二、涉及的协议格式核心重点目前业界主要有两套格式这也是你刚才踩坑的原因旧版格式Legacy / Deprecated请求字段functions数组控制字段function_call返回字段message.function_call回传角色role: functionOpenAI 在 2023 年 6 月首发此格式现在部分老模型仍兼容但新模型和新平台如硅基流动更倾向新版。新版格式Current Standard / Tools API请求字段tools数组元素是{type: function, function: {...}}控制字段tool_choiceauto/none/required返回字段message.tool_calls数组支持并行调用回传角色role: tooltool_call_id关键区别一览表硅基流动SiliconFlow兼容 OpenAI 协议**强推荐用新版 ****tools**格式旧版functions在一些国产模型上可能不触发或行为不一致。三、主流平台/协议体系对比除了 OpenAI 系你以后可能还会遇到这些OpenAI 系我自己目前在用代表OpenAI 官方、硅基流动、DeepSeek、大部分兼容 API 的服务协议新版tools格式为主特点生态最大工程化程度最高Anthropic Claude 系协议toolstool_use/tool_result块格式理念与 OpenAI 新版高度相似但字段命名略有差异tool_usevstool_calls部分 SDK 可互相适配Google Gemini 系协议FunctionDeclaration格式也有自己的tools封装通过 Vertex AI 提供逻辑类似但字段名不同MCPModel Context Protocol—— 新趋势 下一章节给大家带来MCP的介绍和使用由 Anthropic 推动的工具描述标准化协议目标是解耦工具服务端按 MCP 标准暴露能力任何支持 MCP 的模型都能直接接入你目前用不着但未来做 Agent 开发会接触到相当于工具调用的“USB 标准接口”我给出我自己的代码仓库https://github.com/qianshb/cookbooks.git大家可以在终端设置环境变量把API-key设置为自己的然后去改改函数问问AI,看看回复
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
