Google 升級 Gemini API 結構化輸出：原生支援 Pydantic，保留欄位順序

如果你用大模型做過後端開發，多半經歷過這種抓狂時刻：你千叮嚀萬囑咐讓它輸出純 JSON，它偏偏在前後給你包幾句客套話，或者欄位名拼錯、資料型別對不上，直接把下游的解析服務幹崩。

為了徹底解決這個問題，Google 宣佈對 Gemini API 的結構化輸出能力進行了一次重要升級。這次升級不僅擴大了對標準 JSON Schema 的支援，還讓輸出的欄位嚴格遵循 Schema 中定義的順序。

告別膠水程式碼，Pydantic 和 Zod 終於開箱即用

對開發者來說，這次最大的利好是生態對齊。所有處於活躍支援狀態的 Gemini 模型，現在都能直接配合 Python 的 Pydantic 和 JavaScript/TypeScript 的 Zod 使用，省去了中間那層繁瑣的資料轉換膠水程式碼。

Google 還在這個版本里補齊了一批呼聲很高的 JSON Schema 核心關鍵字。比如用來處理條件聯合型別的 anyOf、支援遞迴巢狀模式的 $ref，以及針對數值限制的 minimum 和 maximum。

除此之外，新規範還加上了針對元組式陣列的 prefixItems、額外屬性控制欄位 additionalProperties，以及對 null 型別的顯式宣告。基本上把平時寫嚴謹資料驗證時能踩到的坑，都從協議層面堵上了。

讓鍵值按順序吐出來，連相容介面也管用

另一個看似微小、實際影響巨大的改進是欄位輸出順序。

從 Gemini 2.5 系列模型開始，API 能夠嚴格按照你在 Schema 裡定義的鍵名順序依次返回欄位。這項能力同樣覆蓋了 Google 提供的 OpenAI 相容介面。

這在實際工程裡意義不小。比如在內容稽核場景中，模型可以先按順序返回分類原因，最後再給出結論；開發者在做流式解析時，不需要等整個 JSON 物件吐完，就能按固定順序提前拿到前置欄位進行處理。

根據早期合作伙伴的資料，這種強約束機制能帶來真金白銀的收益。一些團隊在生產環境中徹底消除了因為 JSON 格式殘缺導致的重試，不僅避免了服務報錯，還將特定場景下的 API 呼叫次數減少了最多 6 倍。

為什麼重要

我們認為，Google 這次補丁看起來只是修修補補，實際上踩中了 AI 應用落地最核心的一根軟肋：工程可靠性。

對於做 Multi-Agent 多智慧體協作和複雜資料管道的團隊來說，模型聰明不聰明其實只是一方面，輸出穩不穩定才是決定系統能不能上線的生死線。前一個 Agent 的輸出如果不能百分之百作為後一個 Agent 的安全輸入，系統就得靠一堆重試和清洗邏輯吊著命。

Google 聰明的地方在於，它沒有自己造一套新的資料驗證輪子，而是老老實實向社群標準看齊。直接把 Pydantic 和 Zod 扶正，同時連 OpenAI 相容層都照顧到了，這擺明了是要大幅降低開發者從競品遷移過來的摩擦力。

現在的 Gemini 2.5 已經完全值得拿來重構你的資料提取和結構化業務。雖然對於只把大模型當聊天機器人用的普通人來說感知不強，但只要你打算把大模型插進現有的業務資料庫或後端服務裡，這次更新就是那種能讓你少熬幾個夜的紮實改進。