Function Calling

只要模型开始接真实业务，后面几乎一定会碰到一个问题：

当它需要查外部数据、调外部能力时，到底怎么把这个意图稳定表达出来。

这就是 Function Calling 要解决的事情。

1. Function Calling 到底是什么

Function Calling 直接看成：

模型用结构化方式表达“我现在想调用哪个函数或工具，以及参数是什么”。

它最关键的地方，不是执行动作本身，而是把调用意图说清楚。

也就是说：

1. 模型负责表达意图
2. 应用负责决定是否执行
3. 系统负责真正调用工具

所以 Function Calling 不是工具本身，也不是工具执行结果，而是介于两者之间的一层调用表达。

2. 为什么 AI 系统需要它

因为模型自己不能直接进你的数据库、也不能直接调你公司的内部系统。

如果没有结构化调用表达，它最多只能在自然语言里说：

1. “你去查一下订单”
2. “我需要一个天气接口”
3. “也许应该搜一下知识库”

这种说法对人类能看懂，但对系统来说并不稳定。

Function Calling 的价值就在这里：

让模型把“我要调用外部能力”这件事，收成机器可消费的结构。

3. 一个最小调用意图长什么样

例如：

{
  "name": "get_order_summary",
  "arguments": {
    "orderNo": "A001"
  }
}

这段结构里最关键的是两件事：

1. 要调谁
2. 调它时参数是什么

它不代表工具已经执行，只代表模型把调用意图表达出来了。

4. 一条典型链路怎么走

sequenceDiagram
    participant U as 用户
    participant A as 应用
    participant M as 模型
    participant T as Tool

    U->>A: 查询订单 A001
    A->>M: 用户问题 + 工具描述
    M-->>A: 调用 get_order_summary(orderNo=A001)
    A->>T: 执行工具
    T-->>A: 返回结果
    A->>M: 追加工具结果
    M-->>A: 生成最终回答

这条线里要看清一个边界：

模型不是自己去执行工具，它只是把“该调哪个工具、参数是什么”说清楚了。

5. Function Calling 和 Tool 到底差在哪

这两个词最容易混。

可以这样分：

1. Tool 是系统里准备好的能力入口
2. Function Calling 是模型表达“我想调用这个能力”的机制

所以：

1. Tool 更像动作本身
2. Function Calling 更像动作调用意图

一个是“有什么能做”，一个是“现在要做哪个”。

6. 它最适合解决什么问题

Function Calling 最适合这些场景：

1. 问题必须依赖外部实时数据
2. 模型需要调用内部业务能力
3. 想把模型输出稳定接进后续执行链路
4. 不希望应用再从自然语言里硬解析动作

比如：

1. 查订单
2. 查天气
3. 搜知识库
4. 调审批接口
5. 读取某份内部文档

7. 它不解决什么问题

Function Calling 能把调用意图表达清楚，但它不等于：

1. 工具一定会被执行
2. 工具执行一定安全
3. 调用结果一定正确
4. 整条流程一定合理

也就是说，它解决的是“表达问题”，不是“执行安全”和“流程治理”问题。

后面通常还要继续交给：

1. 参数校验
2. 权限控制
3. 风险动作拦截
4. Guardrails
5. Human-in-the-loop

8. 最容易踩的几个坑

8.1 把 Function Calling 当成 Tool 本身

这样后面很容易把能力定义和调用机制混在一起。

8.2 以为模型输出了调用意图，就应该直接执行

真实项目里，很多调用仍然要经过权限、参数和风险校验。

8.3 给模型挂太多工具，却没有清晰边界

工具一多，模型决策会更混乱，调用成本和风险也会上来。

9. 一段更稳的总结

Function Calling 解决的是“模型如何把调用外部能力的意图稳定表达出来”这个问题。它站在模型和工具之间，负责把“我想做什么动作”说清楚，但真正执不执行、能不能执行、是否安全，最后都还是应用系统要继续负责。