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 工具箱本機校驗後再上線。