[!info] related notes

• 关系对比: MCP vs Function Calling
• 相关概念: MCP 协议, AI 聊天与流式 UI, [private note]， 实现一个加法的FunctionCalling

Function Calling

Function calling | OpenAI API

Function Calling 的本质不是“模型真的去执行函数”，而是：

• 你把可用工具的名称、参数结构告诉模型
• 模型判断当前问题是否需要调用工具
• 如果需要，它生成一段结构化的调用请求
• 真正执行工具的是你的后端或宿主程序
• 工具结果再回给模型，模型继续组织最终回答

一句话定义

Function Calling 是让模型按给定的工具描述，输出结构化参数请求，再由外部系统代它执行工具的一种机制。

为什么需要它

模型本身擅长语言理解，但不一定擅长：

• 精确计算
• 查询实时数据
• 调用业务系统
• 执行数据库、搜索、发消息之类的动作

这时就需要把“理解用户意图”和“真正执行动作”拆开。

最简流程

1. 用户提问，同时系统把可用工具定义发给模型
2. 模型判断要不要调用工具
3. 如果要调用，模型返回工具名和参数
4. 你的程序执行工具
5. 工具结果返回给模型
6. 模型基于结果生成最终回答

一个最小例子

比如你提供一个天气工具：

{
  "name": "get_weather",
  "description": "根据城市获取天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}

用户问：

杭州今天什么天气？

模型可能返回：

{
  "tool_name": "get_weather",
  "arguments": {
    "city": "杭州"
  }
}

然后你的服务端去真的调用天气接口。

与 MCP 的关系

Function Calling 关注模型如何产生结构化调用意图；MCP 关注外部工具/资源如何标准化接入 Host。完整关系见 MCP vs Function Calling。

参数校验与兜底机制

模型返回的参数不能直接信任。工程上需要两层校验：

• 模型侧：通过 JSON Schema 约束参数类型、必填项、枚举值
• 运行时侧：用 Zod / Ajv 做结构校验，校验失败进入 repair-and-retry 流程

高风险操作（退款、删除、支付）还需要幂等设计、业务校验、二次确认和审计日志。

详见 Function Calling 参数校验与重试机制。

学习检查

不看正文回答：

1. Function Calling 中模型真正负责什么，宿主系统真正负责什么？
2. 为什么模型返回的 arguments 不能直接无条件执行？
3. JSON Schema、运行时校验、业务权限校验分别解决什么问题？
4. 高风险工具为什么还需要幂等、确认和审计，而不是只有参数类型校验？
5. 工具执行失败后，模型如何进入 repair / retry 闭环？
6. Function Calling 与 MCP 的职责边界是什么？

Related notes

• AI MOC
• Agent MOC
• Coding Agent MOC
• A2A
• Function Calling 参数校验与重试机制