1.6 Function Calling（函数调用）

Function Calling函数调用更准确的称呼是“工具调用Tool Calling”它是指大语言模型LLM在生成回复时不直接输出纯文本而是输出一个结构化的指令JSON这个指令指明了“该调用哪个外部函数以及传入什么参数”。核心一句话LLM 只负责“决定”要不要调用工具、调用哪个工具、传什么参数但它“绝不执行”这个工具。真正的执行由你的代码Agent来完成。1. 完整的工作流程结合你的 LangGraph 代码这和你之前写的llm.bind_tools(tools)和ToolNode完全对应注册工具你用llm.bind_tools([get_weather, search_web])把工具的定义名称、描述、参数 Schema告诉 LLM。LLM 知道有这些工具存在。用户提问用户说 “北京今天天气怎么样”LLM 决策LLM 推理后决定调用get_weather工具并生成一个 JSON 结构即tool_calls{name:get_weather,args:{city:北京}}Agent 拦截与执行你的 LangGraph 代码ToolNode解析这个 JSON在 Python 中实际执行get_weather(北京)函数拿到结果如 “晴天 25°C”。结果回传ToolNode把结果包装成ToolMessage送回给 LLM。最终回复LLM 看到工具结果后组织语言回复用户“北京今天天气晴朗25°C。”2. 在你代码中的具体体现LangGraph你之前写的这段代码就是 Function Calling 的完整实现# 1. 绑定工具让 LLM 知道这些工具的存在llm_with_toolsllm.bind_tools(tools)# 2. LLM 生成 tool_calls函数调用指令responseawaitllm_with_tools.ainvoke(state[messages])# response.tool_calls 就是那个 JSON 数组# 3. ToolNode 自动解析并执行返回 ToolMessage# 这就是 LangGraph 内置的 ToolNode 帮你做的事情3. Function Calling 的三大价值面试必答结构化输出输出是严谨的 JSON而不是自然语言便于程序解析。确定性调度模型明确告诉你“我要用这个工具”而不是让你去猜测它的意图。解耦模型只需理解工具功能无需关心工具的具体实现比如天气接口是 HTTP 还是 gRPC。4. 面试高频追问“Function Calling 和 MCP 有什么关系”这是对你之前学过的 MCP 知识的极佳串联你可以这样回答“Function Calling 是 LLM 的‘决策协议’规定了大模型如何表达‘我想调用工具’这一意图即tool_calls的格式。而MCPModel Context Protocol是‘工具部署协议’规定了工具如何被注册、发现和通信stdio/SSE。通俗理解Function Calling 是 LLM下达指令的标准填什么单子MCP 是工具上架的标准工具在哪、怎么调用。在 LangChain 中bind_tools处理的是 Function Calling让模型学会填单子MultiServerMCPClient处理的是 MCP帮你去远程货架取工具。两者配合才能让 Agent 既能做出正确决策又能灵活接入跨语言、跨进程的庞大工具生态。”5. 技术细节补充拉开差距的回答如果面试官追问“Function Calling 的实现原理是什么”“在训练阶段模型被微调Fine-tuned来学习识别特殊的tool_call标记或特定的 JSON Schema。在推理时模型通过约束解码Constrained Decoding每一步生成 token 时都受到 JSON Schema 的限制从而保证输出的args一定是有效的 JSON并且参数名和类型与定义完全匹配。这也是为什么tool_choicerequired能强制模型必须调用工具——因为我们在解码层直接屏蔽了输出普通文本的可能性。”