模型退役已經成為日曆上的一個事件。生產棧背後的模型如今按固定節奏來去，每家供應商對你提出的要求都一樣：在關閉日期之前完成遷移。難的部分很少是模型本身，而是當模型 ID 硬編碼散落在原始檔、環境變數、CI 流水線和儀表盤各處時隨之而來的遷移蔓延——沒人說得清還有多少地方仍依賴著這個即將退役的模型。本手冊涵蓋需要弄清的術語、清點工作流、別名層、測試例程、分階段切換，以及一項把下一次模型棄用遷移變成日常雜務的預檢。
為什麼模型退役變成了日常運維
供應商現在釋出模型的速度快過大多數團隊的評估速度，每一代新模型都會把舊模型推向退役。三大平臺都把這件事描述為正常運維，而非緊急事件。OpenAI 的棄用頁面開篇就說，公司“會定期退役較舊的模型”，依賴其模型的軟體“可能需要偶爾更新才能繼續工作”。Anthropic 的模型棄用頁面說法大致相同：隨著更安全、能力更強的模型推出，較舊的模型會被定期退役，應用可能需要偶爾更新。Gemini API 的釋出說明也按類似的釋出與退役節奏推進。
從這三家身上可以看清一點：退役不是供應商或你的團隊的失敗。它是一個附帶日期、按計劃發生的事件，這意味著它可以像其他任何維護工作一樣被規劃、編入預算並自動化。
2026 年 10 月的這批是最新的現成例子：關閉彙總列出了每一個停止工作的快照及其替代方案。
棄用演變成事故的三種方式
大多數棄用帶來的痛苦來自三種模式之一。
1. 影響範圍未知。模型 ID 是有版本的依賴項，它們會積累在出人意料的地方：應用程式碼、環境變數、CI 配置、基礎設施即程式碼、評估指令碼和儀表盤。通知到來時，第一個問題就是該 ID 用在哪裡；如果回答這個問題需要翻箱倒櫃，遷移的成本就已經很高了。
2. 術語被誤讀。“已棄用”並不意味著“已經壞了”。OpenAI 和 Anthropic 都把已棄用的模型描述為在公告發布時仍可正常使用。把“壞了”聽進去的團隊會過度反應；把“不急”聽進去的團隊會一直拖到關閉日期，那時請求開始失敗，切換就變得緊迫。
3. 把替代模型當成可直接替換。更新的模型並不自動是它所替代模型的超集。輸出結構可能漂移，工具呼叫 schema 可能變化，引數可能被移除。Gemini API 2026 年 9 月 17 日的釋出說明就說明了這一點：該條目指出，對於在本地執行工具的團隊，內建工具引數改為 PascalCase，檔案編輯變為行範圍替換。只替換模型 ID 的遷移會讓這些呼叫方出錯。
各家供應商眼中的“已棄用”
每個平臺都發布自己的術語體系，這些詞背後有具體的機制，在動手規劃之前值得先弄清楚。
OpenAI 的棄用頁面記錄其已棄用的模型和端點以及推薦的替代方案。它把棄用定義為“退役模型或端點的過程”。公告發布時，該模型或端點立即變為已棄用，並且始終附帶一個關閉日期；到了該日期它便無法訪問。該頁面把“sunset”和“shut down”當作同義詞使用，並把“legacy”模型和端點標為不再接收更新、預期將來會被棄用的物件。對於確實無法按時遷移的團隊，頁面提到可通過銷售團隊獲得在關閉日期之後繼續訪問的專用容量。
Anthropic 的模型棄用頁面使用四個生命週期術語。Active 表示完全支援並推薦使用。Legacy 表示模型將不再接收更新，之後可能被棄用。Deprecated 表示模型仍可正常使用但不再推薦，附帶已公佈的替代方案和退役日期。Retired 表示模型已不可用，對它的請求將失敗。
每頁上最關鍵的那句話是一樣的：已棄用的模型仍然可用。這正是團隊誤判視窗的原因，也正是應當圍繞這個視窗來設計流程的原因。
模型棄用遷移：按最短的通知視窗來設計
通知視窗因供應商和模型類別而異，所以要按你技術棧中最短的視窗來規劃，而不是最寬裕的那個。
Claude 的退役通知按明確的時鐘走：Anthropic 表示，對於即將退役的模型，它會通知有活躍部署的客戶，“對於公開發布的模型，在模型退役前至少提前 60 天通知”。注意這個框架：通知發給正在活躍使用該模型的賬戶，且該頁面針對的是 Anthropic 運營的平臺。Amazon Bedrock 和 Google Cloud 等合作方運營的平臺有自己的退役時間表，因此模型的狀態和日期在那裡可能不同。
OpenAI 在公告棄用的同時給出關閉日期，其頁面按模型類別說明最低通知期：正式可用模型至少六個月，專用變體至少三個月，而預覽模型可能只提前很短時間退役，例如兩週。頁面還補充說，安全或合規方面的考慮可能縮短其中任何時間線。
Gemini API 的釋出說明節奏更快。根據官方釋出說明，2026 年 9 月 17 日的條目釋出了 antigravity-preview-09-2026，“它取代並棄用 antigravity-preview-05-2026”，較舊的 agent 於 2026 年 10 月 5 日關閉。同一份釋出說明還記錄，現有的 gemini-omni-flash-preview 端點將於 2026 年 9 月 30 日棄用。這類日期會隨計劃變化而變動，所以請把變更日誌當作即時參考，而不是本文。
從這三者中得出的規劃規則：按你能找到的最短通知期來設定遷移流程、人力和告警的規模。如果你的流程能承受兩週的預覽模型退役，那麼六個月的視窗就是白送的。
清點：把每一個硬編碼的模型 ID 找出來
在動程式碼之前，先找出即將退役的模型在哪些地方被引用。把模型 ID 當作有版本的依賴項，像搜尋固定版本的庫那樣去搜索它們：倉庫原始碼、環境與部署變數、CI 配置、基礎設施即程式碼、評估工具、儀表盤，以及任何呼叫該 API 的內部工具。
然後把原始碼層面看到的圖景與供應商自己的視角核對。Anthropic 記錄了確切的路徑：在控制台開啟 Usage 頁面，點選 Export，檢視下載的 CSV，它按 API key 和模型細分用量。這份匯出回答了 grep 無法回答的問題：今天還有哪些 key 在呼叫即將退役的模型。兩者不一致時，以匯出為準。
在控制台裡還有一件運維細節：兩家供應商的通知都只發給正在活躍使用某個模型的賬戶和部署，所以請確認你的賬單和賬戶設定裡的郵箱是一個有人負責、有人盯的別名地址。
用別名層解耦呼叫點
棄用之所以傷人，是因為模型 ID 就住在呼叫點上。修法是結構性的：讓業務程式碼引用邏輯別名，例如 summarize、extract-fields 或 code-review，並在一個地方把每個別名解析為具體的模型 ID——一個小注冊表或配置檔案，由你的服務在啟動時讀取。
下一次通知到來時，遷移就變成改一張對映表，而不是翻遍每個服務。登錄檔還記錄每個對映存在的原因：它通過了哪些測試、何時被評審、它替代了什麼。
這種模式在單個 OpenAI 相容端點上執行得很乾淨，這也是平臺文件在搭建時值得一看的原因。String AI 的文件描述了一個 base URL (https://www.string.ink/v1)，提供與 OpenAI Bearer 相容的介面，另有一個列出 key 可訪問模型的 models 列表介面。如果你要把多個工具整合到一個端點上，我們關於用一個 key 執行 Codex CLI、Claude Code 和 Cursor的指南覆蓋了整合側；別名層是它在程式碼側的對應物，正是它讓未來的切換變得便宜。
先在黃金集上驗證切換
不要憑感覺遷移。用真實流量構建一組固定的代表性輸入作為黃金集，並附上預期輸出斷言，在改變路由之前讓新舊模型並排執行。有三類失敗值得顯式檢查。
- 輸出形態漂移。如果下游程式碼要解析 JSON、抽取段落或對模型輸出做正則匹配，請確認結構仍然成立；人讀起來沒問題的回答，仍可能讓解析器崩掉。
- 工具呼叫與結構化輸出。agent 會依據返回的呼叫採取行動；請驗證工具呼叫的載荷仍然有效，任何結構化輸出模式的行為仍然正常。
- 被移除的引數與能力。替代模型不保證接受舊模型接受過的每一個引數，也不保證支援你 prompt 所假設的每一項能力。要測的不是新模型能不能用，而是你的用法在它上面還能不能用。
把結果記錄在登錄檔條目裡。失敗的檢查要麼修好，要麼帶截止日期延期處理，而不是默默接受。
逐步切換，讓舊路徑觸手可及
路由變更值得按部署級別的紀律來處理：先放一小片流量，保持舊 ID 配置在位且可達，只有在冒煙測試和錯誤預算都保持乾淨之後才刪除它。因為別名層只在一個地方解析，切回去就是改一行，而不是到處重新部署。
切換驗證通過後，趁上下文還新鮮就做清理：從登錄檔移除失效的模型 ID，從文件中移除相應條目，並刪除為過渡臨時加的任何熔斷措施。失效的 ID 和僅供應急的程式碼路徑，正是下一次棄用變得混亂的原因。
讓下一次退役變得無聊
兩個輕量自動化就能消掉剩下的大部分意外。
第一，把“這個模型 ID 還存在嗎？”變成一項檢查，而不是一次發現。在啟動時或 CI 中，把配置裡的每個模型 ID 與端點的 models 列表比對；缺失的 ID 應當快速失敗，而不是作為生產錯誤暴露出來。models 列表介面返回某個 key 可訪問的模型，這讓比對只需幾行程式碼。
第二，按計劃比對這份列表並對變化告警。每週對 models 列表做一次 diff，配合常規監控，可以標出新增和變化，並抓住配置漂移，例如某個環境仍指向舊的 key。
最後，寫一頁執行手冊：通知到來時由誰評估替代方案、哪些別名條目受影響、回滾目標是什麼、切換如何驗證。執行手冊把跨團隊的慌亂變成一張清單。
LLM API 遷移清單
- 閱讀退役通知並記下關閉日期。已棄用還不等於壞掉；日期才是關鍵。
- 拉取供應商側的用量匯出，列出仍在呼叫即將退役模型的每個 key 和服務。
- 在倉庫、CI 配置、基礎設施即程式碼和儀表盤中搜索硬編碼的模型 ID。
- 在每次變更前後，確認該模型 ID 存在於端點的 models 列表中。
- 更新別名登錄檔，而不是呼叫點。
- 在候選替代模型上執行黃金集；檢查輸出形態、工具呼叫和引數。
- 對一小片流量做金絲雀；在冒煙測試通過前保持舊模型可達。
- 用真實任務驗證，然後刪除失效的 ID 和臨時兜底。
- 把決定記錄在登錄檔條目中，並更新團隊執行手冊。
- 為 models 列表 diff 排定計劃，讓下一次通知永遠不是你的第一個警告。
這些都消滅不了退役。它只是讓退役變便宜：改一次對映、跑一次測試，以及一條在關閉日期之前而不是之後到來的告警。
相關閱讀
- 別再讓每個 AI 模型什麼都做：把研究、寫作和評審分配給不同的模型，而不增加協調工作。
- 開發者文章：平臺的安裝指南和整合說明。