跳轉到

Structured Output 與 Tool Use 機制：JSON Schema、Constrained Decoding 與可靠性

整理自論文與廠商文件（見文末），2026-06-20。Agent 能動，靠的是「模型吐出機器可解析的結構（呼叫哪個工具、帶什麼參數）」。本頁拆解這層機制：structured output 怎麼保證格式、tool use 怎麼運作、以及為什麼它和「推理能力」會打架。

實證標記：〔研究〕= 出自論文；〔廠商〕= 出自模型供應商文件；〔實務〕= 業界慣例或本人整理。預設 under-claim。

兩件常被混談的事

Structured Output Tool / Function Calling
解決什麼 讓輸出符合指定格式（JSON schema） 讓模型表達意圖：要呼叫哪個工具、帶什麼參數
保證的層次 語法（syntactic）：格式對 語意（semantic）：選對工具與參數
關係 tool calling 的參數通常就是一個 structured output structured output 是 tool use 的底層磚

〔研究〕一句話：JSON Schema 約束給「語法保證」，tool calling 給「語意意圖」與組裝 agent 的能力。 兩者疊起來，才是 agent 能穩定行動的基礎。

Structured Output 怎麼保證格式：Constrained Decoding

最可靠的做法不是「拜託模型吐 JSON」，而是在解碼時強制它只能產生合法 token：〔研究〕

  • Constrained decoding（約束解碼）：模型參數不變，在推論時依 schema 或正規表達式過濾下一個可生成的 token，從源頭杜絕非法格式。
  • 像 xGrammar 這類文法約束引擎，可用很低的額外開銷強制產出語法合法的 JSON。〔研究〕

對比「自由生成再事後 parse」：後者在生產環境的失敗率常落在 10–20%；用對模式（約束解碼 + 重試）可壓到 sub-1%。〔研究〕

失敗恢復：給模型看它自己的錯

即使有約束，複雜 schema 仍會出錯。一個實用且便宜的模式：〔研究〕

〔研究〕把錯誤明確回灌給模型，它往往第二次就自我修正——因為它能看到「到底哪裡錯了」。所以 tool/structured 流程要內建「parse 失敗 → 把錯誤訊息回給模型 → 重試」的迴路，而不是直接報錯丟出。

複雜 schema 的另一招：〔研究〕 - 分解抽取（decomposed extraction）：schema 欄位多（>8–10 個）或欄位間相依複雜時，拆成多次小抽取，延遲與成本增加，但可靠性大幅提升。

重要取捨：結構化 vs 推理能力

這是最容易被忽略、卻很關鍵的一點：強制結構化輸出，可能壓低模型的推理表現。〔研究〕

〔研究〕有研究觀察到：在推理任務上，要求結構化輸出相較自然語言回答，準確率可能掉超過 27 個百分點；OpenAI 式的約束解碼雖保證可靠格式，但因受限於 JSON Schema 而限制了推理發揮。

〔實務〕實務含義：別讓模型「邊想邊填格式」。常見解法是兩段式——先讓模型用自然語言自由推理（chain-of-thought），再在第二步把結論整理成結構化輸出。把「想」和「填表」分開，兩邊都不犧牲。

Tool Use 的可靠性要點〔實務〕

  1. 工具描述就是 prompt：工具名稱、參數說明寫得含糊，模型就選錯、填錯。描述要精準、給範例。
  2. 參數用 schema 約束：能用 enum/型別限制的就限制，縮小模型出錯空間。
  3. 內建重試迴路：parse/驗證失敗 → 回灌錯誤 → 重試（見上）。
  4. 想與填分離：需要推理的任務，先自由推理再結構化。
  5. 工具輸出當不可信輸入：回傳內容可能含 prompt injection，別直接觸發特權動作（見 AI Agent 安全與權限）。

延伸閱讀（本站）

來源