跳到主要内容

Tool Use / Function Calling

学完 Prompt Engineering、Context Engineering 和 RAG 之后，下一步非常自然的主题就是 Tool Use / Function Calling。

因为从这一层开始，模型不再只是“会回答”，而是开始具备“会做事”的能力。

比如它可以：

  • 查天气
  • 查数据库
  • 调接口
  • 搜索网页
  • 读取文档
  • 执行代码
  • 调用内部业务函数

这也是很多 AI Agent、自动化助手、企业 AI 应用的基础能力。

1. Tool Use 是什么​

Tool Use 可以理解为：让模型在需要时调用外部工具，而不是只依赖自身参数里的知识直接回答。

这里的“工具”可以很广，比如：

  • 搜索工具
  • 数据库查询工具
  • 计算器
  • 地图服务
  • 邮件发送接口
  • 日历接口
  • 本地代码执行器
  • 企业内部 API

一句话理解：

Tool Use = 模型在回答过程中，能主动借助外部能力完成任务

2. Function Calling 是什么​

Function Calling 是 Tool Use 最常见、最工程化的一种实现方式。

它的核心思路是：

  1. 开发者先定义一组函数
  2. 每个函数有名字、作用、参数结构
  3. 模型根据用户意图判断是否要调用某个函数
  4. 如果要调用，就输出结构化参数
  5. 系统执行该函数
  6. 再把函数结果返回给模型
  7. 模型结合结果给出最终回答

所以：

  • Tool Use 更偏概念
  • Function Calling 更偏实现机制

3. 为什么它重要​

如果没有工具调用，模型通常只能：

  • 靠记忆回答
  • 靠上下文回答
  • 做一些文本层面的推理

但很多真实任务必须访问外部世界，比如：

  • “帮我查今天上海天气”
  • “帮我查这个订单状态”
  • “把这个会议安排到明天下午”
  • “读取这份知识库文档并总结”
  • “帮我运行一段代码看看结果”

这些都不是单靠语言模型参数本身能可靠完成的。

所以 Tool Use 的意义在于：

  • 获取实时信息
  • 获取私有数据
  • 执行真实动作
  • 把模型从“回答器”变成“执行器”

4. 一个最直观的例子​

假设用户问：

帮我查一下今天北京天气，并告诉我是否适合出门跑步。

如果没有 Tool Use，模型只能凭记忆猜。

如果有 Tool Use，流程可能是：

  1. 模型判断：这个问题需要实时天气数据
  2. 调用 get_weather(location="Beijing")
  3. 系统返回天气结果
  4. 模型根据温度、降雨、空气质量给出建议

这时候模型的价值就不是“背出天气”，而是：

  • 知道什么时候该查
  • 知道该查哪个工具
  • 知道怎么用查到的结果组织回答

5. Tool Use 的基本流程​

一个最常见的工具调用流程是：

  1. 用户提出请求
  2. 模型判断是否需要调用工具
  3. 模型选择工具
  4. 模型生成工具参数
  5. 系统执行工具
  6. 系统返回执行结果
  7. 模型结合结果继续回答

如果任务更复杂，这个流程可能会多轮循环：

Thought -> Tool Call -> Tool Result -> Thought -> Tool Call -> Final Answer

这和 ReAct 的思想是非常接近的。

6. Tool Use 和 RAG 的区别​

这两个概念经常放在一起，但它们并不一样。

6.1 RAG 更关注什么​

RAG 更关注：

  • 从知识库里检索相关资料
  • 把资料放进上下文
  • 让模型基于资料回答

它主要解决的是“知识从哪里来”。

6.2 Tool Use 更关注什么​

Tool Use 更关注：

  • 调用外部能力
  • 获取实时信息
  • 执行动作
  • 和系统、服务、数据库交互

它主要解决的是“模型怎么和外部世界互动”。

简单说：

  • RAG：先找资料再回答
  • Tool Use：先调用能力再回答，甚至直接完成动作

7. Function Calling 的核心组成​

一个典型的函数调用机制，通常有下面几部分。

7.1 Tool Definition​

先定义工具或函数，包括：

  • 函数名
  • 函数用途
  • 参数字段
  • 参数类型
  • 必填项
  • 字段说明

比如：

{
  "name": "get_weather",
  "description": "Get current weather by city name",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "City name"
      }
    },
    "required": ["city"]
  }
}

7.2 Tool Selection​

模型要判断：

  • 需不需要调工具
  • 该调哪个工具
  • 是调一个还是多个

7.3 Argument Extraction​

也就是参数提取。

模型要从用户语言里抽出结构化参数，比如：

“帮我查一下明天下午上海的天气”

可能提取成：

{
  "city": "Shanghai",
  "date": "tomorrow",
  "time_period": "afternoon"
}

7.4 Tool Execution​

系统真正去执行函数，比如：

  • 调 API
  • 查数据库
  • 跑脚本
  • 访问文件系统

7.5 Result Injection​

执行结果不能就此结束，还要重新喂回模型，让模型理解结果并生成最终答案。

这个步骤就是：

把工具结果重新注入上下文

它本质上也是 Context Engineering 的一部分。

8. 设计函数时最重要的原则​

很多 Tool Use 效果差，不是模型不会用，而是函数定义本身设计得不好。

8.1 函数职责要单一​

一个函数最好只做一类事，不要同时承担太多责任。

比如优先这样设计：

  • search_docs
  • get_weather
  • query_order_status
  • create_calendar_event

而不是设计一个万能函数：

  • do_everything

8.2 名字要清晰​

函数名最好让模型一看就知道用途。

好的名字通常是：

  • 动词 + 对象

例如：

  • get_order_status
  • search_knowledge_base
  • send_email
  • create_meeting

8.3 参数字段要明确​

参数命名和描述一定要清楚，不然模型容易误用。

比如：

  • location 比 where 更清楚
  • start_time 比 time 更清楚
  • order_id 比 id 更清楚

8.4 参数不要过多​

函数参数太多会显著增加调用错误率。

能拆就拆，能默认就默认。

8.5 描述要写清边界​

函数描述里最好说明：

  • 它做什么
  • 不做什么
  • 适合什么场景调用

这样模型更容易在多个工具里选对。

9. 一个常见的调用例子​

假设系统有两个工具：

  • get_weather
  • create_calendar_event

用户说：

如果明天下午上海不下雨，就帮我安排一个 5 点跑步提醒。

可能的流程是：

  1. 模型先判断要查天气
  2. 调 get_weather(city="Shanghai", date="tomorrow", period="afternoon")
  3. 如果结果显示无雨
  4. 再调 create_calendar_event(title="Run", time="17:00", city="Shanghai")
  5. 最后告诉用户已创建提醒

这类场景就已经不只是单次问答，而是多步工具协作。

10. Tool Result 回注为什么重要​

很多初学者会忽略一个点：

工具调用最关键的，不只是“能调用成功”，而是“结果回到模型之后，模型能不能正确使用它”。

举个例子，工具返回：

{
  "temp": 31,
  "rain": false,
  "aqi": 158
}

模型需要据此进一步判断：

  • 虽然不下雨
  • 但空气质量偏差
  • 所以不太适合跑步

也就是说，工具负责拿数据，模型负责解释数据和决策。

11. 常见设计模式​

11.1 Single Tool Call​

最简单的模式，一次请求只调用一个工具。

适合：

  • 查天气
  • 查订单
  • 查库存
  • 查汇率

11.2 Multi-step Tool Use​

一个请求需要连续调用多个工具。

适合：

  • 先搜索，再读取详情
  • 先查用户，再查订单
  • 先看天气，再创建日历事件

11.3 Tool + RAG​

有些场景会把二者结合起来：

  • 先用搜索工具找到文档
  • 再用 RAG 阅读和生成答案

或者：

  • 先检索知识库
  • 不够再调用其他工具补信息

11.4 Tool + Planning​

复杂任务里，模型可能先做计划，再按计划调用多个工具。

这就是很多 Agent 系统的常见模式。

12. 实战里最常见的问题​

12.1 选错工具​

表现：

  • 明明该查数据库，却去搜索网页
  • 明明只要查一个字段，却调用了复杂流程

原因通常包括：

  • 工具描述不清
  • 多个工具边界重叠
  • 函数名不直观

12.2 参数提取错误​

表现：

  • 城市提错
  • 日期理解错
  • 用户 ID 或订单 ID 提取错

解决方向包括：

  • 参数定义更清晰
  • 对关键字段加校验
  • 必要时先追问用户

12.3 工具结果太乱​

表现：

  • 返回字段太多
  • 数据结构太深
  • 模型很难读懂重点

所以工具返回最好：

  • 字段化
  • 精简
  • 稳定
  • 可解释

12.4 调用了工具，但最终回答没用好结果​

比如工具已经返回“库存为 0”，模型却仍然说“可能有库存”。

这通常说明：

  • 结果回注不清晰
  • 上下文里存在冲突信息
  • 没有强约束模型优先依据工具结果

12.5 多步调用中间状态丢失​

复杂流程里，如果没有状态管理，模型可能忘了：

  • 已经调用过什么
  • 上一步查到了什么
  • 下一步该做什么

这时就需要：

  • 状态摘要
  • 工作记忆
  • 明确的多步流程控制

13. Tool Use 的安全与边界​

Tool Use 一旦涉及真实动作，就必须考虑安全问题。

比如：

  • 发邮件
  • 下单
  • 删除数据
  • 修改日历
  • 写数据库

这类工具最好增加额外控制，比如：

  • 权限检查
  • 参数校验
  • 高风险动作二次确认
  • 日志记录
  • 可回滚机制

否则模型“会做事”也可能带来更大风险。

14. 一个典型 Prompt 模式​

在支持工具调用的系统里，常见的指令思路是：

你是一个智能助手。

当用户的问题需要实时信息、外部数据或执行动作时，请优先调用合适的工具。
如果工具结果已经足够回答，请基于工具结果生成最终答案。
如果信息仍不足，再明确说明缺少什么。

如果系统支持函数 schema，真正的关键通常不在这句提示本身，而在：

  • 工具列表设计得好不好
  • 参数结构清不清楚
  • 工具结果是否容易被模型消费

15. 学习 Tool Use 最值得先掌握的 8 个点​

建议优先掌握下面这 8 个：

  1. 区分 Tool Use 和普通问答
  2. 理解 Function Calling 的完整流程
  3. 学会设计清晰的函数 schema
  4. 学会做参数提取和参数校验
  5. 学会把工具结果重新注入上下文
  6. 学会处理多步工具调用
  7. 学会设置高风险动作边界
  8. 学会把 Tool Use 和 RAG、Planning 结合起来

16. 一个实用的学习顺序​

如果你要系统学这个主题，我建议按这个顺序来：

  1. 先理解 Tool Use 的基本概念
  2. 再理解 Function Calling 的调用流程
  3. 学函数 schema 设计
  4. 学参数提取和结果回注
  5. 学多步调用
  6. 学和 RAG、ReAct、Agent 的结合
  7. 最后再学权限、安全和评估

17. 它和 Agent 的关系​

可以把 Tool Use 看成 Agent 的核心积木之一。

因为一个 Agent 通常需要：

  • 理解任务
  • 决定下一步
  • 调用工具
  • 读取结果
  • 更新状态
  • 再继续执行

如果没有 Tool Use，很多 Agent 只能停留在“会说”，而不能真正“会做”。

18. 一句话总结​

Tool Use / Function Calling 的本质，是让模型不只靠语言和记忆回答问题，而是能在需要时调用外部能力、读取真实数据、执行实际动作，并把结果重新纳入推理过程。

从这里开始，模型才真正从“问答系统”向“可执行系统”迈进。