模型 API 正在分歧：2026 Q3 企業 AI 閘道的相容性清單

多模型閘道的前提，是同一個 OpenAI 格式的請求可以送到不同的模型。這個前提在 2026 年第三季受到明顯挑戰：三家主要供應商各自調整了工具呼叫、取樣參數與推理控制的規則，而且多半以「回 400」而不是「默默忽略」的方式生效。對依賴 OpenAI-compatible 介面串接多家模型的企業，這份清單值得逐條檢查。

Anthropic 方面，依 Claude 的 release notes，Opus 5.5 的 thinking 無法關閉，請求裡不論帶 thinking disabled 或 enabled 都會回 400，推理深度改由 effort 控制；強制工具呼叫的 tool_choice any 與 tool 也會回 400，官方建議改用 auto 搭配 strict tool use。Sonnet 5.5 同樣拒絕強制工具呼叫，要關掉預先 thinking 時需送 thinking type between_tools，而且只能在 high 以下的 effort 使用。

Google 方面，Gemini API 的 changelog 在 7 月 21 日宣布 temperature、top_p、top_k 三個取樣參數進入棄用。依賴這些參數控制輸出風格或可重現性的應用，需要重新驗證。OpenAI 方面，GPT-6.1 Sol 的文件說明它在 Chat Completions 不支援工具呼叫，工具必須走 Responses API；GPT-6 Luna 只有在 reasoning_effort 設為 none 時，才在 Chat Completions 支援 function calling。平台層面，Assistants API 已於 8 月 26 日關閉，v1/prompts、Evals 與 Agent Builder 排定 11 月 30 日下線。

這些變化對閘道的意義是：「OpenAI-compatible」只保證請求格式，不保證每個參數在每個模型上都有相同的語意。最危險的是靜默轉換，例如把 OpenAI 的 tool_choice required 自動改寫成 Anthropic 的 any，在 Claude 5.5 上就會直接失敗；更糟的是靜默丟掉參數，讓呼叫端以為設定生效了。閘道應該明確回報錯誤，或在文件中清楚說明每個模型的轉換規則。

實務上，閘道團隊可以做五件事：為每個模型維護一張能力表，列出哪些參數會被拒絕、哪些會被忽略、工具呼叫走哪個端點；建立回歸測試集，涵蓋工具呼叫、取樣參數、thinking 與串流，每次新增或升級模型都跑一遍；對不支援的參數回傳清楚的錯誤，而不是靜默丟棄；把供應商公告的棄用與下線日期放進團隊行事曆；以及在模型目錄中標示每個模型的生命週期狀態，讓使用者事先知道哪些模型即將退役。

接下來要觀察的是這股分歧會不會持續擴大。供應商把新能力優先放進自家的新端點（例如 OpenAI 的 Responses API 與 Agents API），而 Chat Completions 這個共同格式逐漸只承載基本功能。如果趨勢延續，企業閘道的價值會從「轉發請求」轉向「吸收差異」：維護能力表、做明確的轉換、並把變動及早告訴使用者。