AI Agent 为什么开始使用 JSON Schema、Function Calling 与 MCP？技术演进全解析

2023 年的 ChatGPT 插件让人第一次看到「模型会调 API」；2024 年 Function Calling 成为各厂商标配；2025 年 Anthropic 发布 MCP，Cursor、Claude Desktop 等 IDE 纷纷接入——同一条演进线上，JSON 从数据交换格式变成了 Agent 的「类型系统」与「握手协议」。

如果你正在搭建 RAG、自动化工作流或 Copilot 类产品，迟早会遇到三个名词：JSON Schema（约束结构）、Function Calling（模型选工具、填参数）、MCP（Model Context Protocol，标准化工具连接）。本文面向后端、平台与 AI 应用开发者，按时间线解释它们为何出现、各自解决什么问题、如何组合使用，并给出可落地的选型建议。

为什么 Agent 需要结构化接口

早期 LLM 应用的核心模式是：用户提问 → 模型生成自然语言 → 人工复制结果去执行。这在聊天场景够用，但无法可靠地驱动数据库写入、发邮件、查库存等可重复、可审计的自动化任务。

纯 Prompt 工程下的 ReAct（Reason + Act）模式让模型在文本里写「Action: search(query=...)」，宿主程序用正则解析——能跑，但脆弱：括号嵌套、引号转义、多语言混写都会导致解析失败。生产环境需要的是机器可读、可校验、可版本化的契约，而不是靠运气解析 Markdown。

JSON 恰好满足三点：LLM 训练数据中大量存在、人类与程序都能读、有成熟的 Schema 校验生态。于是 JSON Schema 成为描述「模型该输出什么形状的数据」的事实标准；Function Calling 则把「调用哪个函数、传什么参数」也纳入同一套 JSON 结构。

技术演进时间线

这条线的本质变化是：把「模型想干什么」从自然语言翻译成带类型的结构化消息，再由宿主程序或 MCP Server 安全执行。

JSON Schema：Agent 的「类型系统」

JSON Schema 最初用于 API 文档与配置校验（OpenAPI、Kubernetes CRD 等）。在 Agent 场景里，它承担两类职责：

• 工具入参：描述 search_products 需要 query（string）和 limit（integer，默认 10）
• 模型输出：例如抽取实体、分类标签、审批结论等，必须返回固定字段供下游消费

典型工具参数 Schema

{
  "type": "object",
  "properties": {
    "city": {
      "type": "string",
      "description": "城市名，如北京、上海"
    },
    "unit": {
      "type": "string",
      "enum": ["celsius", "fahrenheit"],
      "description": "温度单位"
    }
  },
  "required": ["city"]
}

description 字段尤其重要：它进入模型的上下文，帮助模型理解何时调用、各参数语义是什么——Schema 同时服务于校验器与Prompt。

Structured Outputs 与 Schema

仅把 Schema 写进 Prompt，模型仍可能多写字段或类型错误。OpenAI、Google 等提供的 Structured Outputs / JSON mode 会在解码阶段约束 token，使输出严格符合 Schema。这对「发票 OCR → 结构化 JSON → 入账系统」类流水线是刚需。

开发阶段建议：先用 JSON 工具箱等工具本地校验 Schema 语法，再用样例 payload 验证 required、enum 是否按预期拦截非法输入。

Function Calling：模型与工具的握手

Function Calling（各厂商也称 Tool Use、Tools API）定义了模型与宿主之间的一轮握手：

1. 宿主把工具列表（name、description、parameters Schema）随 messages 发给模型
2. 模型不直接执行代码，而是返回 tool_calls：选中的工具名 + JSON 参数字符串
3. 宿主执行真实函数（查 DB、调 HTTP），把结果以 tool 角色消息塞回对话
4. 模型基于结果生成最终用户可见的回答

与 ReAct 文本模式的对比

Function Calling 并没有消灭 Agent 框架（LangChain、AutoGen、Cursor Agent 等），而是成为框架与模型之间的薄协议层——框架负责编排、重试、记忆；模型 API 负责「决策调用哪个工具」。

MCP：可插拔的工具生态

Function Calling 解决的是「模型这一侧怎么声明调用」。但当工具数量增长、来源分散（GitHub、Slack、 Postgres、浏览器、文件系统）时，新问题出现：

• 每个 Host（IDE、Chat 客户端、自建 Agent）都要为每种工具写一遍适配
• 权限、凭证、stdio/HTTP 传输方式各自为政
• 用户无法「装一个 MCP Server，处处可用」

Model Context Protocol（MCP） 由 Anthropic 2024 年末开源，定位是 Host 与 Tool Provider 之间的标准协议。类比关系大致是：

MCP 核心概念

• Host：发起连接的应用（如 Cursor IDE）
• Client：Host 内的 MCP 客户端，维护与 Server 的会话
• Server：暴露 tools、resources、prompts 的进程（如 filesystem-mcp、github-mcp）
• Capabilities：工具列表动态发现，而非写死在 Prompt 里

MCP Tool 的 inputSchema 本身就是 JSON Schema。因此 MCP 不是替代 Function Calling，而是把「工具实现」标准化；Host 仍可能把 MCP 工具映射为模型 API 的 Function Calling 格式。

三者如何协同

用一张逻辑分层理解三者关系：

┌─────────────────────────────────────────────┐
│  用户 / 业务系统                              │
└─────────────────────┬───────────────────────┘
                      ▼
┌─────────────────────────────────────────────┐
│  Agent Host（编排、权限、记忆）               │
│  ┌─────────────┐    ┌─────────────────────┐ │
│  │ LLM API     │◄──►│ Function Calling    │ │
│  │ (推理)      │    │ (tool_calls 消息)   │ │
│  └─────────────┘    └─────────────────────┘ │
│           ▲                    │              │
│           │ JSON Schema        ▼              │
│  ┌────────┴────────┐  ┌──────────────────┐  │
│  │ 输出 Schema     │  │ MCP Client       │  │
│  │ (Structured     │  │ ──stdio/SSE──►   │  │
│  │  Outputs)       │  │ MCP Server(s)    │  │
│  └─────────────────┘  └──────────────────┘  │
└─────────────────────────────────────────────┘

• JSON Schema：横切各层——工具参数、MCP inputSchema、模型结构化输出
• Function Calling：模型 ↔ Host 的调用语法
• MCP：Host ↔ 外部世界的工具总线

小型脚本可能只有 Function Calling + 几个本地函数；企业级 Agent 平台则常见 MCP 集群 + 统一 Schema registry + 审计日志。

完整调用链路示例

用户问：「上海今天多少度，顺便查我 GitHub 上 json-schema 相关仓库。」

1. Host 向 MCP 拉取可用工具：get_weather、github_search_repos
2. 转换为模型 API 的 tools 数组，每项带 JSON Schema parameters
3. 模型 返回两个 tool_calls，参数均为合法 JSON
4. Host 经 MCP 调用 weather Server 与 github Server，收集 JSON 结果
5. 结果作为 tool messages 回传；模型合成自然语言答复
6. 若需写入工单系统，再用输出 Schema 约束最终 JSON：{ "summary", "temperature", "repo_count" }

任一步参数不符合 Schema，宿主可在执行前拒绝并请求模型重试——这是文本 ReAct 难以做到的fail-fast。

选型对比与最佳实践

Schema 设计要点

• 字段 description 写清业务语义，比 type alone 更能减少误调用
• required 宁严勿松；可选字段用 default 或明确 nullable
• 大枚举改用 string + description，避免 enum 列表过长占上下文
• Schema 纳入 Git 版本管理，与 API 变更一样做 Code Review

常见问题 FAQ

总结与下一步

AI Agent 从「会聊天」到「能办事」，靠的是一层层把不确定性关进结构化边界：JSON Schema 定义形状，Function Calling 定义模型如何伸手，MCP 定义工具如何接入生态。三者不是互相替代，而是同一条栈上的不同层。

下一步建议：拿一个真实业务工具（查订单、发通知），为其写 JSON Schema → 接入 Function Calling 跑通单轮 → 再评估是否值得封装为 MCP Server 供多个 Host 复用。Schema 与样例数据可在 JSON 工具箱本地校验后再上线。