在使用大模型的过程中，你肯定发现目前的大语言模型（LLM）在逻辑推理、代码编写和文本生成方面表现优异。但是，它们都有一个共同的局限：无法直接干预外部世界。 如果你要求模型“查询订单状态”或“发送一封邮件”，它通常会回复：“对不起，我无法访问您的数据库。”这是因为模型本质上只是一个预测下一个 Token 的概率模型，并没有直接访问系统资源的权限。
Tool Call（工具调用，也称 Function Calling）的出现，正是为了给模型安装上“手脚”，让它能够通过结构化的方式与外部系统交互。
## 一、 核心概念：决策与执行分离  理解 Tool Call 的关键在于：模型本身并不执行代码，它只负责决策。
我们可以将其理解为“指挥官”与“执行官”的关系：
模型（决策者）：负责判断“当前需要调用哪个工具”、“需要传入什么参数”。 程序（执行者）：负责运行真实的后端逻辑，如数据库查询、发送邮件、鉴权、限流等。 这种“决策与执行分离”的架构，确保了系统的安全性。模型产生的只是一个 JSON 格式的调用指令，真正的执行权限始终掌握在开发者手中，而不是交给模型。
二、 通用工作流 无论是查询数据（读操作）还是执行动作（写操作），在工程上通常遵循以下五个步骤：
定义工具：开发者向模型描述可选工具的功能（建议使用动词命名，如 get_order_status）及其参数规格（使用 JSON Schema）。 发送上下文：将用户问题与工具清单一并发送给模型。 模型决策：模型判断当前问题是否需要工具。如果需要，它会返回一个结构化的响应，包含工具名、参数及唯一标识符 call_id。 本地执行：程序解析参数，调用真实的 API 或数据库，并获取结果。 生成回答：程序将执行结果回传给模型，模型结合结果生成最终的自然语言回复。 三、 Tool Call Schema 详解 Schema 是模型与程序之间的“契约”。定义得越严谨，模型调用的准确率就越高。
1. 结构示例 { "type": "function", "function": { "name": "get_order_status", "description": "根据订单号查询订单状态与物流信息", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，例如 1001" } }, "required": ["order_id"], "additionalProperties": false }, "strict": true } } 2. 字段含义与最佳实践 字段 说明 最佳实践 name 工具的唯一标识符 使用动词式命名，如 get_order_status description 工具的用途说明 越详细越好：说明适用场景、限制条件及返回格式 parameters 参数定义 每个参数都应包含 type 和 description required 必填参数名数组 明确模型必须提供的字段 additionalProperties 额外参数 设为 false，防止模型生成多余参数 strict 严格模式 设为 true，强制模型输出符合 Schema 的 JSON 3. 一个“好”的描述长什么样 差的描述：
...