## 引言

2023 年，OpenAI 在 Chat Completions API 中引入 Function‑Call 机制，让大模型从"纯文本生成"跨入"可调用的结构化输出"阶段。此后两年，整个行业围绕"模型如何可靠地调用工具"这个问题，衍生出一条清晰的技术演进路线。

但一个普遍的误解是：很多人把 OpenAI 的 Function‑Call JSON Schema 当作行业标准。事实并非如此。本文从原理视角出发，梳理这条技术栈从"尽力而为"到"硬约束"再到"协议标准化"的完整演进路径。

---

## 1. 定位：OpenAI Function‑Call JSON Schema 不是行业通用正式标准

它本质上是 **OpenAI 的 API 私有契约**，不是 ISO/IETF 那样的公开国际标准。

几个关键事实：

- **各家实现互不兼容。** Claude、Gemini 都支持工具调用，但各自的 API 报文结构、字段命名、嵌套方式都不一样。你无法把为 OpenAI 写的工具定义直接搬到另一个模型上运行。

- **JSON‑Schema 只是描述语言，且是子集。** 各家只是借用 JSON‑Schema 的语法来描述工具参数，并非完整实现 JSON‑Schema 规范。OpenAI 的 `strict` 模式甚至刻意禁用了 `oneOf`、`anyOf`、`$ref` 等能力，只保留一个可预测的子集。

- **早期 Function‑Call 是"尽力而为"。** 模型被训练成"尽量输出合法 JSON"，但推理时依然会输出残缺结构、字段名拼错、类型不匹配。业务代码必须做校验、捕获异常、重试——本质上是在用应用层代码兜底模型的不确定性。

> **一句话：JSON‑Schema Function‑Call 是 2023‑2024 的事实工业范式，但它不是终点，后续出现了多层技术演进。**

---

## 2. 第一层演进：Structured Outputs —— 约束解码，模型侧强制 Schema 合规

2024 年 8 月，OpenAI 推出 Structured Outputs，代表工具调用从"尽力生成 JSON"升级为 **Token 生成阶段的硬约束**。

### 核心原理

在模型自回归生成每个 Token 时，推理引擎实时计算当前上下文下"哪些 Token 是合法的"——只有符合给定 JSON‑Schema 的 Token 序列才被允许输出。这叫 **约束解码（Constrained Decoding / Grammar‑Constrained Decoding）**。

开启方式很简单：

```json
{
  "tools": [...],
  "strict": true
}
```

或者用于普通文本输出：

```json
{
  "response_format": {
    "type": "json_schema",
    "json_schema": { "..." : "..." }
  }
}
```

### 效果与局限

**效果：** 语法错误、类型错误、缺失必填字段——这些在 Token 层面就不可能产生。输出 100% 通过 JSON‑Schema 校验。

**局限：**

| 维度 | 说明 |
|------|------|
| 模型覆盖 | 仅 OpenAI 闭源模型原生支持 |
| 开源替代 | 需要借助 GBNF、Outlines、LMQL 等库在推理侧模拟约束解码 |
| 语义盲区 | 只保证语法格式正确，不能保证语义正确（比如把"北京"填到"城市"字段是对的，但业务上用户问的是"上海天气"） |

> **Structured Outputs 解决的是"输出格式可靠性"问题，不是"输出内容正确性"问题。**

---

## 3. 第二层演进：协议层标准化 —— MCP（Model Context Protocol）

Function‑Call 只解决了"模型输出什么 JSON"；MCP 解决的是 **工具如何被发现、传输、执行**。

### 背景

Anthropic 于 2024 年 11 月开源 MCP，随后移交 Linux 基金会 Agentic AI 基金会治理。OpenAI 也在 2025 年的 Responses API 中宣布原生支持 MCP 服务端接入。

### 核心变化

MCP 把工具能力从 API 请求参数里剥离出来，变成独立的通信协议层（基于 JSON‑RPC 2.0）：

| 传统 Function‑Call | MCP |
|---------------------|-----|
| 工具 Schema 塞在每次 API 请求体里 | 模型通过 `list_tools` 协议动态发现可用工具 |
| 工具在业务代码本地执行 | 工具运行在独立 MCP Server 进程，支持本地/远程 |
| 工具与模型紧耦合 | 工具一次编写，GPT / Claude / 开源模型均可复用 |
| 只有函数调用 | 还定义 Resources（文件/数据库读取）、Prompts 模板 |

### 架构示意

```
┌─────────────┐      JSON-RPC 2.0      ┌──────────────────┐
│  LLM / App  │◄──── list_tools ──────►│   MCP Server     │
│  (Client)   │◄──── call_tool ───────►│  (Tools/Res/Prompts)│
└─────────────┘                        └──────────────────┘
      │                                        │
      │  模型内部依然输出                       │  工具实际执行
      │  结构化调用 JSON                        │  在独立进程中
      ▼                                        ▼
  模型推理引擎                           业务系统 / 数据库
```

> **MCP 不是取代 Function‑Call JSON，而是在它之上搭建工具互操作层。** 模型内部依然输出结构化调用，只是工具的交付、执行链路被协议接管。

---

## 4. 第三层演进：API 侧架构升级 —— Responses API

OpenAI 2025 年推出 Responses API，作为面向 Agent 原生设计的新一代接口，逐步替代旧的 Chat Completions。

### 关键变化

- **原生多态输出：** 文本、工具调用、代码解释器、MCP 调用、搜索调用统一作为 `output` 数组中的不同项，不再嵌套在 message 结构里。

- **内置 MCP 对接：** 可以直接在 API 调用中声明 MCP 服务端地址，模型自动发现并调用远程工具。

- **Agent 基础设施下沉：** 多步工具循环、handoff（Agent 间交接）、缓存优化等能力下沉到 API 层，业务侧减少大量消息拼接和状态管理代码。

- **有状态设计：** 与 Chat Completions 的无状态请求‑响应不同，Responses API 支持在服务端维护对话和工具调用状态，减少网络往返。

---

## 5. 开源侧配套技术

闭源模型在往前走的同时，开源社区也在多个维度补齐能力：

### 5.1 约束解码库

| 项目 | 机制 | 特点 |
|------|------|------|
| **GBNF** | 上下文无关文法 | llama.cpp 内置，轻量 |
| **Outlines** | 有限状态机编译 JSON‑Schema | 支持 vLLM、TGI 等推理框架 |
| **LMQL** | 声明式查询语言 | 在生成过程中混合约束与逻辑 |
| **guidance** | 程序化约束模板 | 微软出品，灵活度高 |

这些工具让开源模型也能做到"输出 100% 合法 JSON 工具调用"，弥补了开源模型仅靠微调依然会输出坏 JSON 的缺陷。

### 5.2 并行工具调用

单轮推理同时输出多个工具调用请求，不再串行一轮一轮跑。例如模型一次性决定"查天气"和"查汇率"两个工具并行执行，将 Agent 的多步延迟从 O(n) 降到接近 O(1)。

### 5.3 工具调用的 RL 微调

从纯监督微调（SFT）演进到用 GRPO 等强化学习算法优化工具调用行为：

- 奖励信号覆盖：工具选择是否正确、参数填写是否准确、错误恢复是否合理
- 解决"格式对但语义错"的问题——这是约束解码无法覆盖的盲区

---

## 6. 当前完整技术栈层级（由内向外）

```
Layer 6 ── 业务应用层：重试、鉴权、业务校验、Agent 编排
Layer 5 ── 工具互操作协议层：MCP（工具发现、传输、执行）
Layer 4 ── API 接口层：Chat Completions / Responses API
Layer 3 ── 约束解码层：Structured Outputs / GBNF（保证输出语法合规）
Layer 2 ── 模型微调层：学会输出工具调用 JSON（ToolLLaMA 等）
Layer 1 ── LLM 底座：生成 Token 流
```

每一层解决不同层面的问题：

- **Layer 1‑2** 解决"模型有没有能力输出工具调用"
- **Layer 3** 解决"输出是否格式可靠"
- **Layer 4‑5** 解决"工具如何交付和执行"
- **Layer 6** 解决"业务如何落地"

---

## 7. 总结

1. **OpenAI Function‑Call JSON Schema 只是事实范式，不是正式行业标准。** 各家实现互不兼容，JSON‑Schema 只是被借用的描述语言子集。

2. **技术演进路线清晰：** 尽力而为 JSON 输出 → Structured Outputs 约束解码保障格式 → MCP 协议标准化工具互操作层 → Responses API 面向 Agent 原生接口。

3. **JSON Function‑Call 和 MCP 是互补关系，不是替代关系。** Function‑Call 解决"模型输出什么"，MCP 解决"工具怎么交付怎么跑"。模型内部依然输出结构化 JSON，只是工具的生命周期管理被协议接管。

4. **格式可靠 ≠ 语义正确。** 约束解码解决了语法问题，语义正确性需要靠更好的模型训练（RL 微调）、更好的工具描述（Prompt 工程）和业务层校验来共同保障。


2023 年，OpenAI 在 Chat Completions API 中引入 Function‑Call 机制，让大模型从"纯文本生成"跨入"可调用的结构化输出"阶段。此后两年，整个行业围绕"模型如何可靠地调用工具"这个问题，衍生出一条清晰的技术演进路线。

# Function‑Call JSON 是最新标准吗？后续发展了哪些技术

OpenAI 的 Function‑Call JSON Schema相关技术盘点

人工智能

编程语言

架构设计

OpenAI Function-Call JSON Schema并非行业标准，而是私有契约，各家工具调用互不兼容。技术演进分为三层：Structured Outputs通过约束解码强制输出合法JSON；MCP协议标准化工具发现与执行链路；Responses API面向Agent原生设计。开源侧以GBNF、Outlines等实现约束解码，并借助RL微调提升语义正确性。各层解决不同问题：模型能力、格式可靠、工具交付与业务落地。

强化学习

代码解释

数据库

解释器

Linux

Agent

JSON

腾讯云大数据特惠0.2折起


oceanus

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OpenAI Function-Call JSON Schema并非行业标准，而是私有契约，各家工具调用互不兼容。技术演进分为三层：Structured Outputs通过约束解码强制输出合法JSON；MCP协议标准化工具发现与执行链路；Responses API面向Agent原生设计。开源侧以GBNF、Outline...

# Function‑Call JSON 是最新标准吗？后续发展了哪些技术-腾讯云开发者社区-腾讯云

# Function‑Call JSON 是最新标准吗？后续发展了哪些技术

# Function‑Call JSON 是最新标准吗？后续发展了哪些技术

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐