← 学习笔记

Function Calling 时，模型到底被设成了什么

既然模型吐出来的工具参数也是 JSON，那是不是也开了 JSON Mode？
不是。它走的是另一个输出通道。

一、先看完整的一次往返

从提问到拿到答案，中间到底发生了什么？

下面这四步是真实的报文结构。一步一步点，重点看每步是谁在说话。

二、两个不同的输出通道

JSON Mode 和 Function Calling 到底什么关系？

回到你的问题。模型返回的消息体里，有两个互不相干的字段：

{
  "message": {
    "role": "assistant",
    "content": null,              // ← response_format 管这里
    "tool_calls": [ ... ]       // ← function calling 管这里
  }
}

那能同时用吗

可以同时传，但同一轮里只有一个会生效——模型要么调工具（content 为 null），要么直接回答（tool_calls 为空）。response_format 只在它选择「直接回答」那一轮起作用。

三、参数是怎么被约束的

工具参数也是 JSON，它的格式谁来保证？

这里是最容易踩的坑：底层机制和 Structured Outputs 完全一样，但开关是分开的。

不保证

tools=[{
  "type": "function",
  "function": {
    "name": "refund_order",
    // 没写 strict —— Schema 只是「说明书」，模型尽量照做
    "parameters": { "type": "object", "properties": {...} }
  }
}]

引擎保证

tools=[{
  "type": "function",
  "function": {
    "name": "refund_order",
    "strict": True,                    // ← 关键在这一行
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {"type": "string"},
        "amount":   {"type": "number"},
        "reason":   {"type": ["string", "null"]}
      },
      "required": ["order_id", "amount", "reason"],  // 全都要写进来
      "additionalProperties": False
    }
  }
}]

四、谁决定「要不要调工具」

约束解码能保证格式，那「该不该调」谁说了算？

这是两件完全不同的事，很多人混在一起：

你能施加的控制只有一个粗粒度开关 tool_choice：

五、六个坑

上手会踩到什么？

description 比 Schema 更影响准确率

很多人花大力气雕 Schema，却给 description 写一句「查询订单」。

模型选哪个工具、什么时候选，几乎全靠 description。Schema 只在它决定调之后才起作用。

❌ 模型不知道什么时候该用
"description": "查询订单"

✅ 说清什么时候用、什么时候别用
"description": "按订单号查订单详情，含状态、金额、收货信息。
                用户提到具体订单号时用这个；只是泛泛问『我的订单』
                时先用 list_recent_orders。"

六、和另外两个的关系

三者是叠起来的：MCP Server 暴露的工具，最终还是通过 function calling 交给模型；而 function calling 的参数格式，靠的是和 Structured Outputs 同一套约束解码。