尧图网页设计 
彻底搞懂大模型 Function Calling核心原理与消息流转Function Calling 的本质是一个多轮对话流程让模型、代码和外部工具如 API协同工作。其核心工作流如下1定义工具首先在代码中以特定格式通常是 JSON Schema定义好可用的工具包括工具的名称、功能描述、以及需要的参数。2用户提问用户发起一个需要调用工具才能回答的请求。3模型决策模型接收到请求后分析用户的意图并匹配最合适的工具。它不会直接回答而是返回一个包含 tool_calls 的特殊响应。这个响应相当于一个指令“请调用某某工具并使用这些参数”。4代码执行应用接收到这个指令解析出工具名称和参数然后在代码层面实际执行这个工具例如调用一个真实的天气 API。5结果反馈将工具的执行结果例如从 API 获取的真实天气数据包装成一个 role 为 tool 的消息再次发送给模型。6最终生成模型接收到工具的执行结果后结合原始问题和工具返回的信息生成最终的、自然的语言回答。1. 核心认知Function Calling 的本质是大模型负责决策本地程序负责执行。大模型不会直接执行代码、不会联网、不会查数据库。它只输出结构化调用计划真正执行工具的是你的本地程序。完整闭环LLM 下发调用指令 → 本地执行工具 → 结果回填上下文 → LLM 整合输出答案2. 四大核心消息类型Function Calling 的消息流转主要由四种消息组成。SystemMessage作用是给大模型设定规则包括角色设定可用工具工具调用场景回答约束它是大模型决策的依据。HumanMessage用户的原始问题是触发工具调用的业务输入。AIMessageAIMessage 有两种形态。普通问答形态没有工具调用直接返回自然语言答案。AIMessage(content北京今天天气晴朗。)工具调用形态模型不直接回答而是返回tool_calls要求本地程序执行工具。AIMessage( content, tool_calls[ { id: call_001, name: get_weather, args: {city: 北京} } ] )其中id本次调用的唯一标识name工具名称args工具参数ToolMessage工具执行完成后结果会被封装成 ToolMessage回填到消息上下文中。ToolMessage( content北京今日晴25℃, tool_call_idcall_001 )重点ToolMessage 必须绑定正确的tool_call_id。否则大模型无法判断这个结果对应哪一次工具调用。3. 单轮 Function Calling 完整流程以“今天北京天气怎么样”为例。第一步组装初始消息[ SystemMessage(工具规则), HumanMessage(今天北京天气怎么样) ]第二步大模型返回工具调用指令大模型判断需要查询天气返回带tool_calls的 AIMessage。AIMessage( content, tool_calls[ { id: call_001, name: get_weather, args: {city: 北京} } ] )第三步本地程序执行工具本地代码负责解析工具名解析参数调用真实函数或接口获取返回结果大模型在这一步并没有执行代码。第四步回填 ToolMessage工具结果被封装成 ToolMessage并绑定调用 ID。ToolMessage( content北京今日晴25℃, tool_call_idcall_001 )此时完整消息结构为SystemMessage HumanMessage(用户提问) AIMessage(工具调用指令) ToolMessage(工具执行结果)第五步大模型生成最终答案大模型读取工具结果后不再返回tool_calls而是输出自然语言答案。AIMessage(content北京今天天气晴朗气温25摄氏度。)4. 多轮工具调用消息结构有些问题需要连续调用多个工具。例如对比北京和上海的天气。消息结构会变成SystemMessage HumanMessage(对比北京上海天气) AIMessage(调用 get_weather(北京)) ToolMessage(北京天气结果) AIMessage(调用 get_weather(上海)) ToolMessage(上海天气结果) AIMessage(对比总结答案)规则很简单多轮调用 多组 AIMessage ToolMessage 顺序叠加5. 工具无限循环的三大原因模型重复调用同一个工具常见原因只有三个。1. tool_call_id 不匹配ToolMessage 的tool_call_id与 AIMessage 中的id不一致。模型会认为工具没有正确执行从而再次调用。2. 工具返回异常工具结果为空、报错、格式混乱模型无法识别有效信息。3. 系统提示约束不足没有明确告诉模型拿到工具结果后直接回答不要重复调用。6. 核心本质Function Calling 不是大模型直接执行代码而是一套消息交互协议。它的核心逻辑是LLM 下发结构化任务 → 本地程序执行 → 结果回填上下文 → LLM 整合回答7. 最简伪代码messages [SystemMessage(工具规则), HumanMessage(用户输入)] while True: ai_msg llm.invoke(messages) messages.append(ai_msg) if not ai_msg.tool_calls: break for call in ai_msg.tool_calls: res run_tool(call.name, call.args) tool_msg ToolMessage(contentres, tool_call_idcall.id) messages.append(tool_msg) print(messages[-1].content)结语掌握 Function Calling关键不是记住某个框架 API而是理解消息如何变化。核心重点大模型只负责决策本地程序负责执行AIMessage 下发工具调用ToolMessage 回填结果tool_call_id必须一一对应每一次工具调用都由一组AIMessage(tool_call) ToolMessage组成 彻底搞懂大模型 Function Calling：核心原理与消息流转
彻底搞懂大模型 Function Calling核心原理与消息流转Function Calling 的本质是一个多轮对话流程让模型、代码和外部工具如 API协同工作。其核心工作流如下1定义工具首先在代码中以特定格式通常是 JSON Schema定义好可用的工具包括工具的名称、功能描述、以及需要的参数。2用户提问用户发起一个需要调用工具才能回答的请求。3模型决策模型接收到请求后分析用户的意图并匹配最合适的工具。它不会直接回答而是返回一个包含 tool_calls 的特殊响应。这个响应相当于一个指令“请调用某某工具并使用这些参数”。4代码执行应用接收到这个指令解析出工具名称和参数然后在代码层面实际执行这个工具例如调用一个真实的天气 API。5结果反馈将工具的执行结果例如从 API 获取的真实天气数据包装成一个 role 为 tool 的消息再次发送给模型。6最终生成模型接收到工具的执行结果后结合原始问题和工具返回的信息生成最终的、自然的语言回答。1. 核心认知Function Calling 的本质是大模型负责决策本地程序负责执行。大模型不会直接执行代码、不会联网、不会查数据库。它只输出结构化调用计划真正执行工具的是你的本地程序。完整闭环LLM 下发调用指令 → 本地执行工具 → 结果回填上下文 → LLM 整合输出答案2. 四大核心消息类型Function Calling 的消息流转主要由四种消息组成。SystemMessage作用是给大模型设定规则包括角色设定可用工具工具调用场景回答约束它是大模型决策的依据。HumanMessage用户的原始问题是触发工具调用的业务输入。AIMessageAIMessage 有两种形态。普通问答形态没有工具调用直接返回自然语言答案。AIMessage(content北京今天天气晴朗。)工具调用形态模型不直接回答而是返回tool_calls要求本地程序执行工具。AIMessage( content, tool_calls[ { id: call_001, name: get_weather, args: {city: 北京} } ] )其中id本次调用的唯一标识name工具名称args工具参数ToolMessage工具执行完成后结果会被封装成 ToolMessage回填到消息上下文中。ToolMessage( content北京今日晴25℃, tool_call_idcall_001 )重点ToolMessage 必须绑定正确的tool_call_id。否则大模型无法判断这个结果对应哪一次工具调用。3. 单轮 Function Calling 完整流程以“今天北京天气怎么样”为例。第一步组装初始消息[ SystemMessage(工具规则), HumanMessage(今天北京天气怎么样) ]第二步大模型返回工具调用指令大模型判断需要查询天气返回带tool_calls的 AIMessage。AIMessage( content, tool_calls[ { id: call_001, name: get_weather, args: {city: 北京} } ] )第三步本地程序执行工具本地代码负责解析工具名解析参数调用真实函数或接口获取返回结果大模型在这一步并没有执行代码。第四步回填 ToolMessage工具结果被封装成 ToolMessage并绑定调用 ID。ToolMessage( content北京今日晴25℃, tool_call_idcall_001 )此时完整消息结构为SystemMessage HumanMessage(用户提问) AIMessage(工具调用指令) ToolMessage(工具执行结果)第五步大模型生成最终答案大模型读取工具结果后不再返回tool_calls而是输出自然语言答案。AIMessage(content北京今天天气晴朗气温25摄氏度。)4. 多轮工具调用消息结构有些问题需要连续调用多个工具。例如对比北京和上海的天气。消息结构会变成SystemMessage HumanMessage(对比北京上海天气) AIMessage(调用 get_weather(北京)) ToolMessage(北京天气结果) AIMessage(调用 get_weather(上海)) ToolMessage(上海天气结果) AIMessage(对比总结答案)规则很简单多轮调用 多组 AIMessage ToolMessage 顺序叠加5. 工具无限循环的三大原因模型重复调用同一个工具常见原因只有三个。1. tool_call_id 不匹配ToolMessage 的tool_call_id与 AIMessage 中的id不一致。模型会认为工具没有正确执行从而再次调用。2. 工具返回异常工具结果为空、报错、格式混乱模型无法识别有效信息。3. 系统提示约束不足没有明确告诉模型拿到工具结果后直接回答不要重复调用。6. 核心本质Function Calling 不是大模型直接执行代码而是一套消息交互协议。它的核心逻辑是LLM 下发结构化任务 → 本地程序执行 → 结果回填上下文 → LLM 整合回答7. 最简伪代码messages [SystemMessage(工具规则), HumanMessage(用户输入)] while True: ai_msg llm.invoke(messages) messages.append(ai_msg) if not ai_msg.tool_calls: break for call in ai_msg.tool_calls: res run_tool(call.name, call.args) tool_msg ToolMessage(contentres, tool_call_idcall.id) messages.append(tool_msg) print(messages[-1].content)结语掌握 Function Calling关键不是记住某个框架 API而是理解消息如何变化。核心重点大模型只负责决策本地程序负责执行AIMessage 下发工具调用ToolMessage 回填结果tool_call_id必须一一对应每一次工具调用都由一组AIMessage(tool_call) ToolMessage组成