Function Calling 是一种机制： 让大模型“以结构化方式，决定是否调用一个函数，并给出函数所需的参数”。

注意三点关键词：

• 决定是否调用
• 给出参数
• 结构化输出（JSON）

⚠️ 重点：
模型并不会真的执行函数，它只“说我想调用谁、传什么参数”。

二、Function Calling 出现前，模型是怎么“假装会干活”的？

以前（没有 Function Calling）

用户：查一下 AAPL 的财报
模型：我将调用 get_financial_report("AAPL")

问题：

• ❌ 你要自己解析字符串
• ❌ 容易胡编
• ❌ 没法自动化

三、Function Calling 的核心思想（非常重要）

把“自然语言 → 程序行为”的中间层变成“结构化协议”

也就是👇

自然语言
   ↓
模型推理
   ↓
结构化函数调用意图（JSON）
   ↓
程序执行

四、Function Calling 的完整工作流程（一步不跳）

我用一个完整闭环例子给你看👇

Step 1️⃣：你向模型声明“你可以用哪些函数”

[
  {
    "name": "get_stock_price",
    "description": "获取股票当前价格",
    "parameters": {
      "type": "object",
      "properties": {
        "ticker": { "type": "string" }
      },
      "required": ["ticker"]
    }
  }
]

你是在对模型说：

“如果你觉得有必要，可以用这些函数。”

Step 2️⃣：用户提问

现在 AAPL 的股价是多少？

Step 3️⃣：模型进行推理（隐式）

模型内部想的是：

“这个问题我自己不知道，需要查股价 → 有 get_stock_price”

Step 4️⃣：模型返回 函数调用请求（不是普通文本）

{
  "name": "get_stock_price",
  "arguments": {
    "ticker": "AAPL"
  }
}

⚠️ 这一步非常关键：
模型没有回答用户，而是返回了一个“调用意图”

Step 5️⃣：你的程序执行函数

price = get_stock_price("AAPL")

Step 6️⃣：把执行结果再喂回模型

{
  "role": "function",
  "name": "get_stock_price",
  "content": "AAPL 当前价格为 182.35 美元"
}

Step 7️⃣：模型基于真实结果生成最终回答

AAPL 当前股价约为 182.35 美元。

✅ 闭环完成

五、Function Calling 到底解决了什么问题？

没它之前

• 模型胡编
• 你猜模型想干嘛
• 文本解析地狱

有它之后

• 行为可控
• 参数可校验
• 自动化可实现
• Agent 成为可能

六、Function Calling 的本质拆解（工程角度）

七、Function Calling 在 Agent 中的位置

Agent
 ├─ Reasoning（想）
 ├─ Planning（计划）
 ├─ Function Calling（叫人干活）
 └─ Memory / Reflection

👉 Function Calling = Agent 的“手”

八、Function Calling 的 5 个常见坑（血坑）

❌ 1. 让模型“必须调用”

→ 会乱调

❌ 2. 函数描述写太抽象

→ 模型选错

❌ 3. 参数 schema 不严

→ JSON 崩

❌ 4. 执行失败不反馈

→ Agent 卡死

❌ 5. 把业务逻辑塞进 Prompt

→ 不可维护