JSON Schema 會成為 AI Agent 的標準 Contract 嗎？

如果你讀過本系列前幾篇——JSON Schema、Function Calling 與 MCP 的技術演進、Structured Output 落地指南、Agent 呼叫鏈上的 JSON 資料流——會發現一個共同點：無論模型廠商、無論協議層，描述「該傳什麼形狀的資料」時，幾乎都在用 JSON Schema（或其子集）。

於是一個自然的問題浮出水面：JSON Schema 會不會成為 AI Agent 的「標準 Contract」——就像 OpenAPI 之於 REST、Protobuf 之於 gRPC 那樣，成為跨團隊、跨 IDE、跨雲廠商的預設握手語言？

本文從「Contract 到底指什麼」出發，梳理 2026 年生態裡的採納現狀、仍存在的裂縫，以及工程上該如何選型。結論先行：JSON Schema 已是 Agent I/O 邊界的事實標準，但不會是唯一一層契約——傳輸、鑑權、編排仍由 MCP、OpenAPI、各 Agent SDK 承擔。

Agent 裡的「Contract」指什麼

在軟體工程裡，Contract（契約）約定雙方交換資料的形狀、語義與錯誤處理方式。AI Agent 比普通 API 更復雜，因為「呼叫方」裡多了一個非確定性的大模型——它可能漏欄位、編引數、或在自然語言與結構化輸出之間搖擺。

因此 Agent 棧裡其實有多層契約，JSON Schema 主要落在payload 形狀這一層：

說「JSON Schema 成為標準 Contract」，在實踐裡通常指：凡是模型與程式之間、程式與工具之間要交換結構化 JSON 的地方，預設用 JSON Schema 描述。傳輸怎麼連、誰有許可權調——那是上一層協議的事。

JSON Schema 已佔據的三條戰線

1. Tool / Function Calling 引數

OpenAI、Google Gemini、Anthropic Claude 的 Tools API 均用 JSON Schema 描述 parameters（或等價欄位）。模型讀 description 理解語義，宿主用同一 Schema 校驗 arguments 再執行——這與我們在資料流一文裡拆解的鏈路一致。

{
  "name": "create_ticket",
  "description": "在工單系統建立一條記錄",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "description": "工單標題" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] }
    },
    "required": ["title"],
    "additionalProperties": false
  }
}

2. Structured Output（模型最終回覆）

當業務不要自然語言、只要 JSON 時，各廠商的 Structured Output / JSON Schema 模式在解碼階段約束 token，使輸出符合 Schema。詳見Structured Output 指南；Gemini 側可參考Gemini 結構化 JSON 教程。

3. MCP Tool 的 inputSchema

MCP 規範明確要求每個 Tool 提供 inputSchema，型別即 JSON Schema。Cursor、Claude Desktop 等 Host 把 MCP 工具對映為模型 API 的 Function Calling 格式時，Schema 往往原樣透傳或做輕微子集裁剪——這是「寫一次 Schema，IDE 與雲端模型共用」的基礎。

三條戰線覆蓋 Agent 生命週期裡幾乎所有結構化 JSON 邊界，這也是「標準 Contract」論點的核心證據。

競品與替代方案

關鍵洞察：沒有一種格式能同時最優地服務「模型可讀」與「高效能 RPC」。JSON Schema 贏的是「模型 ↔ 程式」這一環；OpenAPI 與 Protobuf 繼續在各自領地存活，並透過轉換層與 Agent 對接。

為何 JSON Schema 在贏

1. 與 LLM 訓練分佈對齊：JSON 在預訓練語料中海量存在，Schema 的 type、enum、description 可被模型當作「軟型別提示」。
2. 人類與機器雙可讀：產品、後端、Prompt 工程師能同讀一份 Schema，比二進位制 Protobuf 更適合協作與 Code Review。
3. 校驗生態現成：ajv、jsonschema（Python）、各雲 API 內建校驗——Structured Output 之後仍建議二次校驗語義與業務規則。
4. 廠商收斂：2023 各家用自定義 tool 格式；2024–2026 主流 API 檔案均以 JSON Schema 子集為 parameters / response 的規範表述。
5. MCP 與 OpenAPI 的「向下相容」：MCP 選用 JSON Schema 而非發明新 DSL，降低工具作者學習成本；OpenAPI 3 的 Schema 元件可直接複用。

尚未統一的部分

「事實標準」不等於「完全統一」。生產 Agent 仍需處理以下裂縫：

• Schema 方言：OpenAI strict: true 對 additionalProperties、required 全量覆蓋要求嚴；Gemini、Anthropic 支援的組合型別、$ref 深度各異。複雜 Schema 需按目標 API 做相容性測試。
• Draft 版本：生態仍混用 draft-07、2019-09、2020-12；$defs vs definitions 等差異會導致生成工具踩坑。
• 語義 vs 語法：Schema 保證「有 priority 欄位且為 string」，不保證「priority=high 是否符合 SLA 政策」——業務規則仍需程式碼或 JSON Logic 等擴充套件。
• 非 JSON 載荷：圖片、音訊、檔案 URI 等多模態 Tool 結果，Schema 只描述後設資料包裝，不替代 Blob 儲存契約。
• 編排與狀態：多步 Agent、Human-in-the-loop、子 Agent 委派——JSON Schema 不描述狀態機，LangGraph、Temporal 等另有一套 DSL。

這些限制說明：期待「一份 Schema 統治 Agent 全棧」不現實；期待「所有結構化 JSON 邊界預設 Schema 化」則已基本成立。

2026 生態訊號

若你正在評估技術債：現在投資 JSON Schema 技能與工具鏈，比在私有 JSON 格式上繼續堆 Prompt 更安全——即便未來出現「Agent Schema 2027」之類的 profile，也大機率是 JSON Schema 的超集或子集 profile，而非全新語言。

會成為「唯一」標準嗎？

分兩層回答：

會（高置信）——作為 Agent結構化 I/O的預設 Contract：Tool 引數、Structured Output、MCP inputSchema、OpenAPI 元件中的 request/response body。新工具、新模型 API 若不提供 JSON Schema 描述，反而顯得「不完整」。

不會（同樣重要）——作為 Agent全棧唯一契約：傳輸（stdio/SSE/HTTP）、鑑權、工具發現、多 Agent 編排、SLA 與配額，仍由 MCP、OpenAPI、各平臺策略覆蓋。JSON Schema 是棧中的「型別層」，不是「網路層」或「治理層」。

┌──────────────────────────────────────────────────┐
│  治理 / 鑑權 / 審計（OAuth, RBAC, 日誌）           │
├──────────────────────────────────────────────────┤
│  編排 / 狀態（Agent 框架, 工作流引擎）             │
├──────────────────────────────────────────────────┤
│  連線 / 發現（MCP, OpenAPI, gRPC 閘道器）            │
├──────────────────────────────────────────────────┤
│  ★ JSON Schema：工具引數 · 結構化輸出 · 訊息體 ★  │
├──────────────────────────────────────────────────┤
│  執行體（HTTP, DB, 檔案, 瀏覽器自動化…）            │
└──────────────────────────────────────────────────┘

落地建議

• 單一 Schema 源：用 Pydantic / Zod 定義領域模型，生成 JSON Schema 供 OpenAI、MCP、檔案共用，避免三份定義漂移。
• 按目標 API 做子集：為 OpenAI strict、Gemini 各維護一份「相容 Schema」或透過 CI 自動檢測不支援的關鍵字。
• description 當 Prompt 寫：description 直接影響模型是否誤呼叫；與欄位命名一樣值得 Review。
• Structured Output + 服務端二次校驗：解碼約束降低語法錯誤，業務規則仍用同一 Schema + 自定義 validator。
• 版本化與變更日誌：Schema 變更 = API 破壞性變更；Agent 客戶端應 pin Schema 版本或做向後相容。
• 本機先驗：上線前用 JSON 工具箱校驗 Schema 語法與樣例 payload，減少聯調輪次。

常見問題 FAQ

總結與下一步

JSON Schema 正在成為 AI Agent 結構化 I/O 的標準 Contract——不是理論預測，而是 OpenAI、Google、Anthropic、MCP 與主流 Agent SDK 共同鋪就的事實軌道。它不會取代 OpenAPI 或 Protobuf 的全部職能，但在「模型與程式握手」這一環，替代方案的空間已急劇縮小。

下一步：選一條真實業務鏈路（例如「使用者意圖 → 結構化抽取 → 調工單 API」），用一份 JSON Schema 同時驅動 Structured Output 與 Tool parameters，並在 JSON 工具箱本機驗通後再接入 MCP。系列閱讀建議按演進順序：技術演進總覽 → Structured Output → 資料流 → 本文（Contract 判斷）。