问题#

Tool_Calling_Complete_Link

标准回答#

1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

• 工具的名字
• 一段自然语言描述
• 参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

2. LLM 决策调用#

LLM 收到用户消息和工具列表后，若判断需要调用工具，返回一个特殊的 tool_use 消息（OpenAI 用 tool_calls，Anthropic 用 tool_use），包含工具名和填好的参数 JSON。注意：LLM 只是”说”要调什么工具、传什么参数，它自己不会执行。

3. 系统执行#

系统侧拿到 tool_use 后，解析出工具名，找到本地注册的对应函数，传入参数执行。

4. 结果回传#

执行完拿到结果，包装成 tool_result 消息追加到对话历史，再发回给 LLM。LLM 看到后有两种选择：

• 信息够了 → 直接生成最终回答
• 需要更多信息 → 再发一个 tool_use，形成循环

完整链路：

1
用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

扩展知识#

面试官追问#

关键点#

• Tool Calling（工具调用）完整链路：定义、调用与回传#

Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。

• 打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。
• Tool Calling 就是这个”下命令再拿报告”的标准化流程。

• 1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

• 工具的名字
• 一段自然语言描述
• 参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。

• 示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

LLM 收到用户消息和工具列表后，若判断需要调用工具，返回一个特殊的 tool_use 消息（OpenAI 用 tool_calls，Anthropic 用 tool_use），包含工具名和填好的参数 JSON。

备注#

• 本文已做格式统一与噪声清理，保留原始语义。

• 问题#

Tool_Calling_Complete_Link

Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。

• 打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。

• 1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

• 工具的名字
• 一段自然语言描述
• 参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

LLM 收到用户消息和工具列表后，若判断需要调用工具，返回一个特殊的 tool_use 消息（OpenAI 用 tool_calls，Anthropic 用 tool_use），包含工具名和填好的参数 JSON。注意：LLM 只是”说”要调什么工具、传什么参数，它自己不会执行。

• 3. 系统执行#

系统侧拿到 tool_use 后，解析出工具名，找到本地注册的对应函数，传入参数执行。

• 4. 结果回传#

执行完拿到结果，包装成 tool_result 消息追加到对话历史，再发回给 LLM。LLM 看到后有两种选择：

• 信息够了 → 直接生成最终回答
• 需要更多信息 → 再发一个 tool_use，形成循环

完整链路：

1
用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

• Function Calling（OpenAI 2023.06）：一次只能调一个函数
• Tool Calling（2023.11）：支持 parallel tool calls，LLM 一次返回多个 tool_use，系统并行执行，一轮搞定多查询场景

不同厂商在 Schema 处理上有差异：Gemini 不支持 patternProperties，xAI 不支持 minLength/maxLength，OpenAI 要求参数顶层必须是 type: "object"。工程上需要一层 Schema 归一化来抹平差异。

• 本文已做格式统一与噪声清理，保留原始语义。

• 行 → 结果回传**。

• 打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。

• 1. 工具定义#

• 每个工具本质上是一段 JSON Schema，包含：

• • 工具的名字

• 本文已做格式统一与噪声清理，保留原始语义。