AIREITER距離 OpenAI 在 2026 年 8 月 26 日關閉服務已不遠，最危險的誤判，就是以為這次遷移只是改個 API 名稱。OpenAI 早在 2025 年 8 月 26 日的棄用公告中，提前整整一年宣布 Assistants API sunset；接替者則是 Responses API。從物件名稱看起來，對應關係相當直觀，但底層編排邏輯並非如此。即使照著官方指南實作，仍有開發團隊在正式上線後出現故障。以下拆解哪些功能會消失、表面對應關係隱藏了什麼，以及該如何依你剩下的時間安排遷移。
2026 年 8 月 26 日之後：哪些 API 會失效，哪些資源還在
截止日過後，所有 Assistants 端點系列都會回傳錯誤。受影響範圍包括 /v1/assistants、/v1/threads、thread messages、runs 與 run steps，也包含仍在傳送 OpenAI-Beta: assistants=v2 header 的任何流程。Assistant 設定與 thread 歷史紀錄也將無法再透過 API 存取。
不過，與 Assistants 整合相關的所有東西並不會一併消失：
| 2026 年 8 月 26 日失效 | 仍可使用 |
|---|---|
/v1/assistants CRUD 端點 | Vector stores 與已上傳檔案，可透過 Responses file search 繼續使用 |
/v1/threads、thread messages | Chat Completions API（不在本次關閉範圍內） |
| Runs 與 run steps | Responses API 與 Conversations API |
OpenAI-Beta: assistants=v2 工作流程 | Realtime API |
OpenAI 自家的棄用追蹤頁面，將 Responses 與 Conversations 列為指定替代方案：
四組核心物件對應，但有兩個細節會改變架構
OpenAI 的遷移指南，將四個 Assistants 概念對應到 Responses 時代的替代項目：
| Assistants API | 替代方案 | 實際改變之處 |
|---|---|---|
Assistants | Prompts | 設定移至 Dashboard 建立、可版本化管理的物件 |
Threads | Conversations | 儲存的是通用 items，包括 messages、tool calls 與 tool outputs，而非只有訊息 |
Runs | Responses | 原本 create-run-poll-retrieve 的流程，收斂成一次 responses.create 呼叫 |
Run steps | Items | 涵蓋 messages、function calls 與 results 的 union type |
這種流程收斂可從官方範例看得很清楚：在 gpt-4.1 上完成的 run，回報 34 個 prompt tokens 與 130 個 completion tokens；而在 gpt-5.5 上完成的 response，則回報 17 個 input tokens 與 150 個 output tokens。工作負載型態相近，但欄位名稱已不同。
這正是第一個容易被忽略的差異。若計費儀表板或 payload parser 綁定了舊版 usage 欄位，欄位改名後可能悄悄失效：
| Assistants 欄位 | Responses 欄位 |
|---|---|
usage.prompt_tokens | usage.input_tokens |
usage.completion_tokens | usage.output_tokens |
max_completion_tokens / max_prompt_tokens | max_output_tokens |
truncation_strategy | truncation |
object: "thread.run" | object: "response" |
第二個差異則直接牽涉架構。Prompts 只能在 Dashboard 建立，無法透過 API 建立；因此，凡是會依客戶、workspace 或文件集動態建立一個 Assistant 的系統，都會受到影響。官方指南本身也提醒，若要在長期整合中採用 prompt objects，必須先確認 prompt 的棄用時程，因為可重用的 prompt objects 也有自己的淘汰風險。更耐久的做法，是將 instructions、tool schemas 與 model 選擇保留在自己的 source control 中，並隨每次請求傳送。至於 thread 歷史資料，OpenAI 的立場只有一句話：「We will not provide an automated tool for migrating Threads to Conversations.」
三項內建工具該怎麼搬到 Responses
每一種 Assistants 工具在 Responses 中都有明確落點，但也都意味著更多工作要回到你的應用程式處理：
| Assistants 工具 | 在 Responses 的對應方式 | 現在由應用程式負責的部分 |
|---|---|---|
| File search | Vector stores 會保留；每次請求時在工具定義中提供 vector_store_ids | 在每次呼叫前解析正確的 store IDs |
| Code interpreter | 以 type: "auto" 設定 Container | Container lifecycle |
| Functions | 移除巢狀 function key；name、description、parameters 上移一層 | Tool loop：執行呼叫、以對應的 call_id 回傳結果，並決定是否繼續迴圈 |
對多租戶應用來說，file search 那一列才是最安靜、卻最重要的架構變化。過去，每個 tenant 對應一個 vector store，可以在設定 Assistant 時綁定；現在，收到 session 後，必須先找出該 tenant 對應的正確 store IDs，才能送出請求。
已遷移團隊踩過的幾個坑
OpenAI 的說法是 Responses 已達到功能對等。不過，以下遷移經驗顯示，物件層級的對等，底下其實仍是一輪實質重構。一名多租戶 chatbot SaaS 經營者在 r/aiagents 分享了為期兩週的遷移過程；即使仔細閱讀官方指南，問題仍然出現：
我不得不把每個 optional field 都改成
["type", "null"]，感覺像是在繞過型別系統。— u/aidenclarke_12
嚴格的 tool schemas 要求 optional properties 同時宣告為 nullable，並且仍列在 required 中。因此 schema 會變得更大，而所有原本假設「缺少欄位就代表不存在」的 handler，也都必須重新檢查。同一位開發者還點出了更深層的改變所在：
vector store 的串接方式改變，才是真正的架構轉折。— u/aidenclarke_12
第二個不易察覺的破壞點是串流。Assistants 的 run streaming 不能直接套用到 Responses，必須改寫為處理具型別的 server-sent events，例如 response.created、response.output_text.delta、response.completed，以及 response.function_call_arguments.delta / .done。這些事件有明確的完成事件，也採用了新的 tool-call event 格式；事件名稱可在遷移報導整理中查到。SSE proxy 與 client handler 都得重寫，包含重新連線邏輯。
第三個問題不在 API 本身，而是周邊生態系還沒跟上：
Responses API 推出已經很久了，但還是有不少 framework 和 SDK 不支援它。— u/zhlmmc
若你的技術堆疊建立在仍假設 Threads/Runs 模型的 agent framework 之上，也就是 u/zhlmmc 遇到的情況，除了自己的 glue code 外，還要為這一層預留遷移時間。
多輪對話狀態怎麼留：串接、Conversations 或自行重播
Responses 有三種保留多輪上下文的方法，但它們不能任意互換：
| 策略 | 適合情境 | 注意事項 |
|---|---|---|
previous_response_id | 最簡單的串接方式，改動最少 | 先前上下文仍會計入 billable input |
| Conversations API | 最接近 Threads 的替代方案；在伺服器端保存歷史 | Backfill 得自行實作，沒有 vendor 工具 |
手動重播，store: false | ZDR 與嚴格資料保存要求 | 所有 state 都由你管理；reasoning items 必須一併帶入後續請求 |
若要轉換舊有 thread 歷史，OpenAI 建議的流程如下：
- 依遞增順序列出 thread 的 messages。
- 將每則 user text message 轉為
input_text。 - 將每則 assistant text message 轉為
output_text。 - 將 image URL content 轉為
input_image，保留image_url與detail。 - 使用轉換後的
items建立 Conversation。
角色對應一旦出錯，會出現很具體的問題：模型可能把自己過去的回答當成使用者剛輸入的新指令。Stored responses 預設 TTL 為 30 天，除非傳入 store: false；而根據追蹤此事的遷移報導，截至 2026 年 7 月下旬，conversations 不受 response TTL 限制，且尚未另行公布保存期限。如果你的資料揭露承諾了刪除時間窗，這項細節就很關鍵。
遷移後，token 帳單會怎麼變
有兩項計費事實特別重要。
第一，previous_response_id 提供的是便利性，不是折扣。OpenAI 的Responses 遷移指南明確指出，response chain 中先前輸入的 tokens 仍會以 input tokens 計費。因此，若不做裁剪，長時間進行的對話成本會線性成長。
第二，cached input 比未快取 input 便宜得多。依 2026 年 7 月列出的 GPT-5.x 各級距價格，成本大約是 input rate 的十分之一；此外，根據彙整報導所引用的 OpenAI 內部測試，Responses 的 cache utilization 比 Chat Completions 高 40–80%。在自己的儀表板驗證前，應將這個利用率區間視為供應商提供的數字。真正重要的對等檢查，是切換前後你自己每個 session 的 token 數量。
若你也打算趁這次遷移重新評估 GPT-5.x 工作負載的價格，GPT-5.6 pricing breakdown整理了每 token 的計價方式；而 GPT-5.6 API page 這類 OpenAI-compatible endpoints，則能執行相同的 Responses-style 工作負載，方便直接比較。
依剩餘時間安排的遷移計畫
剩 1–6 天。先備份：以 limit=100 列出 assistants 與 vector stores、拉回檔案，並用 model_dump() 序列化 SDK objects。多篇優先備份的遷移文章都指出一項硬限制：沒有 list-threads endpoint，因此只能匯出你自己的應用程式原本就已保存的 thread IDs。接著用 feature flag 切換：新 session 立即走 Responses，舊 threads 則只在使用者重新開啟時才懶惰式 backfill。
至少還有一週。先挑一條低風險流程做端到端轉換，再處理其他部分。重建 tool loop，確認每個 function result 都帶有對應的 call_id；以依 event type 分支的方式取代舊的 stream handling；接著與 Assistants 基準比較行為、延遲、token 使用量與錯誤率，再逐步擴大流量。
已過截止日。端點會回傳錯誤，assistant configurations 也會從 API 端消失；此時只能根據應用程式資料庫與備份重建。不過，vector stores 與檔案仍可透過 file search 存取。
尚未消失的取捨是：你用伺服器代管的生命週期，包括 polling、truncation 與 tool loop，換來單次呼叫的模型，以及更容易觀察、測試的編排流程。一位同時使用過兩者的開發者如此形容：
Responses API 是很理想的折衷點：它處理了繁重工作，但仍保有足夠彈性，讓你管理自己的功能。— u/landongarrison
OpenAI Assistants API 關閉常見問題
Chat Completions API 也會一起停止服務嗎？
不會。Chat Completions 不在 2026 年 8 月 26 日的關閉範圍內。OpenAI 的建議是按流程逐一遷移至 Responses，而非面對強制遷移截止日。
OpenAI 會自動遷移我既有的 threads 嗎？
不會。官方遷移指南寫得很明白：「We will not provide an automated tool for migrating Threads to Conversations.」Backfill 必須由你撰寫應用程式程式碼，依照上述 item-conversion 流程完成。
2026 年 8 月 26 日後還能繼續使用 Assistants API 嗎？
不能。該日期之後，Assistants、threads、messages、runs 與 run steps 都會回傳錯誤，包括 assistants=v2 工作流程。請在截止日前匯出所有需要保留的資料。
Stored responses 會過期嗎？
會。除非傳入 store: false，stored responses 預設保存 30 天；根據 2026 年 7 月的報導，conversations 不受這項 TTL 限制。
我一定得把 assistant configuration 移到 Prompts 嗎？
不必；若你的 assistants 是動態產生，更不建議這麼做。Prompts 只能在 Dashboard 建立，且官方指南本身也提醒要檢視可重用 prompt objects 的棄用風險。把 instructions 與 tool schemas 放在 source control 中，並在每次請求時傳入，才是更耐久的模式。