工具调用与函数调用概览

一句话定义

工具调用（Tool/Function Calling）让模型在对话中输出结构化的「调用请求」（工具名 + JSON 参数），由外部系统执行后把结果回填对话，形成「模型决策、代码执行」的闭环——它是 Agent 应用的最小构件。

为什么重要

LLM 天生不会查数据库、算精确数学、访问私有系统；工具调用把这些能力「外挂」进来，直接缓解幻觉与时效性两大痛点。当代 Agent、RAG、自动化工作流全部构建在这个原语上，属于现代 LLM 工程的分水岭概念。

前置知识

• kp-026（API 的 messages 形状）

核心概念

• 工具声明（Tool Schema）：以 JSON Schema 描述工具名、用途、参数类型，随请求发给模型。
• 调用请求：模型输出结构化调用（工具名 + 参数对象），而非自然语言描述。
• 执行回路：应用层执行工具 → 结果作为 tool 消息回填 → 模型继续生成最终回答。
• ReAct 模式：推理（Thought）与行动（Action）交替的智能体范式。
• 并行与多步调用：一次响应请求多个工具、或多轮工具链。
• 与多智能体的边界：本节是「单模型 + 工具」；多智能体编排属于独立专题站。

原理与机制

机制上，工具声明被序列化进系统/用户消息（条件信息），模型经 SFT/RLHF 学会「需要外部信息或动作时输出调用格式」——本质是一种被训练出的「格式化行为」，与 kp-028 的结构化输出共享约束解码基础。可靠性取决于三件事：schema 描述质量（模型按描述选工具）、参数合法性校验（应用层必须验证）、错误回传设计（执行失败应回填可读错误让模型自我修正）。安全上，工具执行是代码在真实世界产生副作用，最小权限、白名单与人工确认是底线。

公式或模型

一次工具回合的消息扩展（概览视角）：

图示

用户: "北京现在几度？"
模型: → 调用 get_weather(city="北京")     ← 结构化请求，不是瞎编温度
应用: 执行 API → 返回 {temp: 21}
模型: → "北京当前 21°C，建议……"          ← 基于工具结果作答

直观类比

像给「只会动嘴的顾问」配一部电话：他不再凭记忆猜数字，而是当场打给相关部门（工具）要准确数据，听完汇报（结果回填）再给你结论。电话号码簿写不清（schema 模糊），他就可能打错部门。

实例或案例

Toolformer（2023）证明模型可自学习在何处插入 API 调用；ReAct（2023）确立了「思考-行动-观察」循环，成为 Agent 框架的标准心跳；当代各模型 API 均原生支持工具调用，典型应用是「模型选工具 → 系统执行 → 模型总结」的查询类助手。多步任务（查日历→订会议室→发邮件）即多轮工具链，属于 Agent 专题站的深入范围。

常见误区

• 「模型真的执行了工具」：模型只输出调用请求，执行永远在应用层——这是安全边界的根本。
• 「工具越多越好」：工具过多增加选择错误率，按场景裁剪并写清描述更重要。
• 「参数无需校验」：模型可能生成类型错误或越界参数，应用层校验是必需而非可选。

与其他知识点的关系

• kp-028 提供结构化输出的约束机制（工具调用的格式保障）；kp-029 是最常用的「内置工具」形态；多智能体编排的展开见独立专题站。

自测题

1. 描述一次完整工具调用的消息流。
   答案要点：声明 schema → 模型输出 tool_call → 应用执行 → 结果以 tool 消息回填 → 模型生成回答。
2. 工具调用如何缓解幻觉？
   答案要点：事实类问题改为取实时/权威数据源，模型只做理解与总结。
3. 应用层必须做哪些安全设计？
   答案要点：schema 校验、最小权限、白名单、危险操作人工确认。

延伸阅读

• Toolformer（Schick 等，2023）
• ReAct（Yao 等，2023）