先记一句话Tool Calling 不是大模型自己去执行工具而是大模型根据工具定义生成一份结构化的“调用指令”由 Agent Runtime 解析并真正执行。核心链路工具定义 ↓ Tool Schema ↓ 大模型 ↓ 判断是否需要工具 ↓ 生成结构化 Tool Call ↓ Agent Runtime 解析 ↓ 找到对应 Tool ↓ 校验参数 ↓ 执行 Tool ↓ Tool Result ↓ 重新交给 LLM ↓ 继续思考 / 再调用 / 最终回答1. 大模型到底“看到了”什么例如我们给模型一个天气工具{name:get_weather,description:查询指定城市的天气,parameters:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}用户苏州今天的天气怎么样模型实际上同时看到了System Prompt Conversation History User Question Available Tools于是模型需要判断用户的问题 ↓ 我现有知识能不能回答 ↓ 不能 / 需要实时信息 ↓ 有没有合适的 Tool ↓ get_weather ↓ 需要什么参数 ↓ city 苏州2. 模型输出的不是“执行结果”这是最容易理解错的地方。模型不会直接运行get_weather(苏州)而是产生类似这样的结构化输出{tool_calls:[{name:get_weather,arguments:{city:苏州}}]}也就是说LLM 负责决定“调用谁 传什么参数”Runtime 负责“真的调用”。这实际上就是 Agent 的一个重要分工。3. Tool Calling 背后的本质可以把它理解成LLM │ ┌───────┴───────┐ │ │ 普通回答 Tool Call │ │ ↓ ↓ 返回文本 {name, arguments} │ ↓ Agent Runtime │ ┌──────┴──────┐ ↓ ↓ Tool A Tool B │ ↓ 执行结果 │ ↓ LLM所以LLM 决策者Tool 能力Runtime 执行者4. 那么“大模型为什么知道什么时候调用 Tool”这里才是真正值得研究的地方。模型训练阶段会学习大量类似用户需求 ↓ 选择工具 ↓ 生成参数这样的模式。再加上当前请求中提供的 Tool SchemaTool: get_weather 用途 查询天气 参数 city: string模型就可以把自然语言帮我查一下苏州天气映射成Intent: 查询天气 Tool: get_weather Arguments: { city: 苏州 }因此不要简单理解成“模型里面有一个 if-else 判断器。”更准确的是模型通过其训练得到的语言/工具使用能力根据当前上下文预测最合适的结构化 Tool Call。5. Tool Calling 为什么能够“结构化”现代 LLM API 通常不会只把 Tool 当成普通文字 Prompt。工具会以结构化 Schema 的形式提供给模型。例如{type:function,function:{name:search_web,description:搜索互联网信息,parameters:{type:object,properties:{query:{type:string}},required:[query]}}}于是模型的输出空间实际上被约束成类似普通文本 OR Tool Call ├── tool name └── arguments这就是为什么 Tool Calling 比单纯让模型输出我要调用 search_web参数是 xxx可靠得多。6. 真正执行发生在哪里例如模型产生{name:search_web,arguments:{query:LangGraph 最新版本}}这时候LLM只负责“我要调用 search_web”Agent Runtime负责tooltools[search_web]resulttool(queryLangGraph 最新版本)然后把结果重新包装成消息ToolMessage LangGraph 最新版本是……再发送给 LLMUser History Assistant Tool Call Tool Result ↓ LLM7. 这就是 Agent Loop之前研究的Agent Loop实际上可以直接和 Tool Calling 连起来的┌──────────────────────────────┐ │ │ │ LLM 推理 │ │ │ │ “我下一步需要什么” │ │ │ │ │ ┌──────┴──────┐ │ │ ↓ ↓ │ │ Final Tool Call │ │ Answer │ │ │ ↓ │ │ Tool执行 │ │ │ │ │ Tool Result │ │ │ │ │ └──────┘ │ ↑ │ 再次进入LLM └──────────────────────────────┘所以Agent 并不是“LLM自己执行代码”而是 LLM Tool Calling Runtime Loop。8. 放到 LangGraph 中就更清楚了回到 LangGraph 源码这几个概念正好对应起来LangGraph │ ┌────────────┴────────────┐ ↓ ↓ LLM Node Tool Node │ │ │ Tool Call │ └──────────→──────────────┘ │ 执行 Tool │ ↓ State │ ↓ LLM例如START ↓ LLM Node ↓ 是否存在 tool_calls │ ┌┴─────────┐ 否 是 │ │ ↓ ↓ END Tool Node │ ↓ Tool Result │ ↓ LLM Node │ ↓ ...帮助我们理解 LangGraph 为什么需要StateNodeEdgeToolConditional EdgeCheckpointPregel / Superstep因为它实际上是在管理这个 Agent Loop 的状态与执行过程。9. 一个特别重要的认知很多初学者会认为Agent 一个很聪明的大模型。其实更准确的是Agent │ ┌───────────┼───────────┐ ↓ ↓ ↓ LLM Tools Runtime │ │ │ │ │ │ └───────────┴───────────┘ │ Agent Loop │ Memory / State │ Human-in-the-loop其中LLM负责“想”Tool负责“做”Runtime负责“管”State/Memory负责“记”Loop负责“持续行动”记住这句话Tool Calling 是 LLM 与外部世界之间的“控制接口”LLM 负责产生结构化行动意图Agent Runtime 负责把这个意图变成真实行动再把结果反馈给 LLM。这也是从AIGC → Agent的一个关键能力跃迁AIGC LLM → 生成内容 ↓ Tool Calling LLM → 决定调用什么工具 ↓ Agent LLM → Tool Calling → Runtime执行 → 获取结果 → 再推理 → 再行动 → ……这条链路如果真正理解了Function Calling、Tool Calling、Agent Loop、LangGraph Node/Edge、MCP就能串成一个完整的知识体系。