OpenAI Assistants API 週三正式關閉：硬性斷電、無自動遷移工具、對話資料恐將滅失

2026 年 8 月 26 日星期三，OpenAI 同時迎來兩個截止日。搶佔媒體版面的是 o3 從 ChatGPT 模型選單中退場；但真正會讓生產系統掛掉的，是另一個安靜許多的消息：Assistants API 永久關閉。這套自 2023 年 11 月 DevDay 發表以來，支撐了無數企業客服機器人、多輪對話 Agent 與自動化流程的服務端架構，即將畫下句點。週二過後，任何仍呼叫 /v1/assistants、/v1/threads 或 /v1/runs 的應用程式，得到的回應不會是棄用警告，也不會是速率限制——而是直接的硬錯誤。

Assistants API 是什麼

Assistants API 是 OpenAI 第一次嘗試提供「託管式 Agent 基礎設施」，用三層物件把開發 Assistant 最麻煩的部分搬到 OpenAI 的伺服器上：

• Assistants——持續存在的 API 物件，綁定模型選擇、系統指令與工具宣告，全程透過 API 建立與管理。
• Threads——伺服器端的訊息儲存，為每個使用者工作階段保存完整對話歷史，由 OpenAI 持久化，開發者端完全不需要資料庫。
• Runs——針對 Thread 觸發的非同步執行流程，需要輪詢（polling）直到完成。

成千上萬的團隊建立在這種便利性之上：客服平台、內部副駕駛、無程式碼自動化——任何想要「帶狀態的 ChatGPT」卻不想自己管儲存的場景。值得注意的是，這套 API 將近三年從未正式脫離 beta 身分；這個細節在事後看來，比當初感覺的重要得多。

硬性關閉，而且沒有遷移工具

OpenAI 官方遷移指南寫得毫不模糊：在 Responses API 達到功能對等之後，Assistants API 已被棄用，並將於 2026 年 8 月 26 日關閉。沒有寬限期、沒有降級模式、也沒有延期選項——端點就是直接停止正常回應。

更痛的是，OpenAI 已明確表示不會提供把 Threads 自動遷移到新 Conversations API 的工具。手上握有大量 Thread 歷史的團隊——累積數年工單的客服平台、長時間運行的 Agent 工作流、多階段的使用者互動——必須透過 API 逐則讀出每個 Thread 的每條訊息，手動轉換成新的 item 格式，再從結果建立全新的 Conversation。向量儲存（vector stores）與檔案確實會延續到 Responses API 的檔案搜尋工具，但 Assistant 定義與 Thread 歷史不會自動轉移。截止日前沒有匯出的資料，將永遠無法存取。

取代者是什麼——以及真正的改變

替代方案不是改個名字，而是概念上完全不同的模型，由兩個部分組成：

• Responses API——執行層：送進 input items，取回 output items。工具呼叫迴圈改由你的程式碼明確管理。同時解鎖了 Assistants API 從未有過的功能，包括 deep research、MCP 與 computer use。
• Conversations API——持久層：有序的 item 串流（訊息、工具呼叫、工具輸出），供 Responses 以 conversation ID 參照。

依照 OpenAI 指南的對照表：Assistants 變成 Prompts——但有個轉折，prompts 是在控制台中建立與版本化，而不是透過 API。Threads 變成 Conversations，儲存的是廣義的 items 而非僅限訊息。Runs 變成 Responses，把非同步輪詢迴圈收斂成一次同步呼叫。Run steps 則變成廣義 items。

最重大的轉變在於誰擁有狀態。舊 API 把對話狀態放在伺服器端，透明到許多開發者從未把它視為一個前提假設——它就是能動。新架構同樣儲存狀態，但開發者必須明確建立與參照 Conversations、管理其生命週期。輪詢樣板程式碼消失了，架構責任則移進你的程式碼庫。

連帶災情：自動化整合層

衝擊半徑遠超過直接整合 API 的團隊。Zapier 已棄用所有建立在 Assistants API 之上的 ChatGPT 步驟：使用舊版「Conversation With Assistant」動作的 Zap 會被自動遷移到新的 Conversation 動作，但使用 Create Assistant、Upload File、Find Assistant 的 Zap 必須用現行 ChatGPT 動作手動重建。Zoho、Make 等整合平台近幾週也陸續發布自己的棄用公告，都在催促客戶趕在截止日前重建。

2026 年 8 月發布的各份遷移指南一致建議：預算請以「天」計而非「小時」——清點所有 API 呼叫者（包括藏在筆記本、cron 排程與內部工具裡的影子整合）、把狀態處理從 Threads 移植到 Conversations、把 Run 輪詢迴圈重寫成同步的 Responses 呼叫、跑回歸測試。第三方估計，生產級整合的工程量約落在兩到六週——這也正是為什麼拖到最後一刻的團隊，現在面對的是漫長的一週。

一個跑了三年的 beta

這次關閉還有一個少被討論的層面：Assistants API 於 2023 年 11 月明確以 beta 之名推出，並帶著這個標籤一路到死。把它當成穩定生產基礎設施的應用程式，其實是建立在一個 OpenAI 從未承諾過生命週期條款的產品上。而更大的趨勢正在加速——OpenAI 在 2026 年淘汰的模型與 API 數量，超過以往所有年份的總和，ChatGPT 內的模型生命週期已從約 18 個月壓縮到接近 6 個月。

這個教訓是結構性的：AI 模型名稱與 beta API 端點不是穩定的基礎設施識別碼，把它們當成穩定識別碼來依賴，必須承擔實際的營運風險。坐在應用邏輯與供應商 API 之間的框架——Vercel AI SDK、LangChain、LlamaIndex——透過把你的程式與特定端點解耦，吸收了部分這類動盪。跳過抽象層的團隊，就是本週得做兩到六週遷移工程的那批人。

對於把合規敏感流程建立在這類期限上的企業而言，這一週再次提醒：供應商端的生命週期決策，可以在大規模系統上引發未列入計畫的治理事件。o3 的 API 快照對開發者還留到 2026 年 12 月 11 日，Assistants API 則沒有這種緩衝。星期三，它就消失了。