AgentKit 退場倒數 25 天：從視覺化畫布到程式碼優先的遷移實作課

今日主題：AgentKit 退場遷移實作課

2026-11-05 | 資料來源：OpenAI 官方發佈頁、OpenAI deprecations 頁面、Osher、Forkast

前言：一年前還是 DevDay 的明星，今天只剩 25 天

2025 年 10 月 6 日，OpenAI 在 DevDay 推出 AgentKit，全場掌聲。視覺化畫布 Agent Builder、內嵌聊天介面 ChatKit、集中管理的 Connector Registry、強化的 Evals，再加上為 Agent 而生的強化微調（RFT）——一套「從原型到上線」的完整工具箱。Klarna 用它處理三分之二的客服工單，Ramp 幾小時就做出採購 Agent，Canva 靠 ChatKit 兩週省下一個聊天介面的開發量。

一年後的今天，2026 年 11 月 5 日，距離它關燈只剩 25 天。2026 年 6 月 3 日，OpenAI 在官方發佈頁悄悄加了一段更新：Agent Builder 與 Evals 將於 2026 年 11 月 30 日起停止提供；Evals 已在 10 月 31 日轉為唯讀，只能匯出、不能再編輯。

這篇文章不是悼文，而是一堂遷移實作課：AgentKit 當初承諾了什麼、退場時間表怎麼走、手上的工作流該往哪搬、以及這次退場給所有 Agent 開發者留下的平台風險教訓。

一、AgentKit 當初是什麼：五件套一次看懂

AgentKit 不是單一產品，而是一組疊在 Responses API 與 Agents SDK（2025 年 3 月推出）之上的開發套件，如圖一。

Agent Builder——視覺化畫布。 拖拉節點組成多步驟工作流：Start、Agent、MCP、File search、Guardrails、If/else、While、人工核準、Transform、Set state。支援預覽執行、內嵌評測設定與完整版本控管。OpenAI 執行長 Altman 當時把它比作 Canva：不用寫程式，改排節點就好。

Connector Registry——連接器集中管理。 一個管理後台，統一控管 Agent 能接的資料與工具：Dropbox、Google Drive、SharePoint、Microsoft Teams 等內建連接器，加上第三方 MCP 伺服器。權限、OAuth、憑證輪換集中在登錄處，不再散落各處的環境變數裡。

ChatKit——內嵌聊天介面。 把 Agent 嵌進自家產品的聊天 UI 工具包，處理串流回應、對話串管理、思考過程顯示與品牌客製。Canva 的回饋是：省下兩週開發時間、不到一小時完成整合。

Evals——評測平台。 資料集、軌跡評分（trace grading）、自動提示詞優化、第三方模型支援。Carlyle 宣稱評測平台讓多 Agent 盡職調查框架的開發時間少一半、準確率提升 30%。

Guardrails——開源安全層。 可遮罩或標記個資、偵測越獄攻擊，也能以 Python 或 JavaScript 函式庫獨立使用。

二、退場時間表：三個日期，一個死線

| 日期 | 事件 |

| --- | --- |

| 2025 年 10 月 6 日 | AgentKit 在 DevDay 發佈，Agent Builder 為 Beta |

| 2026 年 6 月 3 日 | OpenAI 宣布 Agent Builder、Evals 與可重用提示詞（v1/prompts API）將退場 |

| 2026 年 8 月 26 日 | 前代產品 Assistants API 關閉（AgentKit 原本要接替它） |

| 2026 年 10 月 31 日 | Evals 轉為唯讀（已過，只能匯出） |

| 2026 年 11 月 30 日 | Agent Builder、Evals、v1/prompts 正式關閉 |

留下的東西： ChatKit、Agents SDK、Responses API、MCP 工具。官方建議很明確：想繼續用程式碼維護工作流，走 Agents SDK；適合自然語言提示詞的場景，走 ChatGPT 裡的 Workspace Agents。

注意一個關鍵細節：Agent Builder 從發佈到退場，始終沒有離開 Beta。一個從未轉正的產品被收掉，技術上不令人意外；真正值得記取的是時間尺度——從高調發佈到宣布退場，只隔了八個月。

三、為什麼退場：三個合理的解讀

OpenAI 沒有公開說明退場原因，以下是對照公開資訊的三個解讀，讀者可自行判斷。

第一，策略轉向程式碼優先。 視覺化畫布適合快速起步，但複雜工作流的除錯、版本控管與程式碼審查，終究回到程式碼。Agents SDK 只有三個小原語——Agent、Handoff、Guardrails——卻能完整表達同樣的邏輯，而且能進 Git、能寫測試、能跑 CI。

第二，託管工作流的責任邊界太重。 幫使用者代管執行環境，意味著 OpenAI 要為每個人的工作流可用性、資料隔離與成本負責。改推 SDK，等於把執行責任還給開發者自己的基礎設施。

第三，產品線收斂。 同一時期 OpenAI 還在推 ChatGPT 內的 Workspace Agents（2026 年 4 月以研究預覽推出，面向 Business、Enterprise 與 Edu 方案）。低程式碼需求由 Workspace Agents 接手，工程需求由 Agents SDK 接手，中間的 Agent Builder 就沒有位置了。

四、遷移實作：兩條官方路線

路線 A：匯出為 Agents SDK 程式碼（工程團隊擁有）

四個步驟：開啟工作流 → 點上方導覽的 Code → 選 Agents SDK → 選 TypeScript 或 Python，複製完整匯出。

但官方遷移指南有一句話必須逐字讀完：

> 「這個流程不會轉換你的工作流圖，也不保證每個行為都原樣轉移。」

分支條件、Guardrail 設定、工具參數都要人工核對。把匯出當作第一份草稿，不是完成的遷移。下面是官方發佈頁客服範例的對等寫法——分類 Agent 收到訊息，判斷是訂單查詢就交棒（handoff）給訂單 Agent，後者呼叫工具查訂單：

from agents import Agent, Runner, function_tool, handoff

@function_tool
def lookup_order(order_id: str) -> str:
    """查詢訂單狀態，回傳物流與金額摘要。"""
    order = db.get_order(order_id)  # 接自己的資料庫或連接器
    return f"訂單 {order_id}：{order.status}，預計 {order.eta} 送達。"

order_agent = Agent(
    name="訂單查詢 Agent",
    instructions="只回答訂單狀態問題，查不到就說查不到，不要猜測。",
    tools=[lookup_order],
)

triage_agent = Agent(
    name="分類 Agent",
    instructions="判斷使用者意圖：訂單問題交給訂單查詢 Agent，其他問題自己回答。",
    handoffs=[handoff(order_agent)],
)

result = await Runner.run(triage_agent, "我的訂單 A1234 到哪了？")
print(result.final_output)

對照原畫布時，逐一核對三件事：If/else 節點的條件是否完整搬進分類 Agent 的 instructions；Guardrail 節點是否改寫為 SDK 的 input/output guardrail；MCP 工具是否改用 SDK 的 MCP 用戶端重新接上。畫布上的 While 迴圈與 Set state 節點最容易漏——SDK 沒有對等節點，要改寫成程式迴圈與外部狀態儲存。

路線 B：重建為 ChatGPT Workspace Agent（非工程師維護）

適合團隊內部使用、由非開發者維護的 Agent。需要 ChatGPT Business、Enterprise 或 Edu 工作區與建立 Workspace Agent 的權限。做法是把匯出的程式碼貼進新的 Workspace Agent 對話，讓內建的建立器轉換，再用真實輸入測試後發佈。

五、遷移驗證清單：11 月 25 日前完成切換

官方死線是 11 月 30 日，但實務上要把切換日定在 11 月 25 日，留五天緩衝。驗證清單如圖二。

1. 先匯出，再談其他。 11 月 30 日之後畫布打不開，匯出功能也跟著消失。今天就把每個工作流的程式碼匯出、放進 Git。

2. 新舊並行跑一到兩週。 讓 SDK 版本與 Agent Builder 版本同時接流量（或影子執行），比對輸出差異，特別是分支條件與 Guardrail 觸發率。

3. 評測資料一起搬家。 Evals 已經唯讀，歷史結果與資料集要匯出；OpenAI 指向的替代品是開源的 Promptfoo，設定檔住在自己的 repo 裡。

4. ChatKit 換後端。 ChatKit 本人留著，但原本指著託管工作流 ID 的設定要改：用 ChatKit Python SDK 接自己的伺服器端 Agent，官方說法是「連接任何 Agent 服務，包括用 Agents SDK 建立的」。

5. 確認工作流 ID 的去留。 截至 11 月初，官方文件沒有明確說明 11 月 30 日後既有的工作流 ID 是否還能透過 ChatKit 執行。不要賭它會留，照「會停」來排程。

六、平台風險的三堂課

第一課：畫布不是資產，程式碼才是。 任何不能匯出為自己能跑的程式碼的建置工具，都只是租來的生產力。選工具前先問：沒有這個平台，我的東西還跑不跑得起來？

第二課：評測資料要住在自己的 repo。 Evals 的教訓最實際：評測集、評分標準與歷史結果一旦只存在平台上，平台一收，連「以前表現多好」的證據都拿不回來。Promptfoo 這類設定檔即程式碼（config-as-code）的工具，至少讓評測資產跟著 Git 走。

第三課：抽象層要選可攜的。 這次退場裡真正全身而退的，是站在開放標準上的東西：MCP 連接器可以原封不動接到 SDK；ChatKit 換個後端就能繼續用；Responses API 還在。被綁住的，永遠是平台專屬的那一層——畫布上的節點圖、託管的工作流 ID、平台內的評測專案。

結論：25 天，夠搬家，不夠猶豫

AgentKit 的故事不是「視覺化開發失敗了」，而是「託管式 Agent 平台的生命週期比想像中短」。八個月前它是 DevDay 的主角，今天它是一份遷移清單。對還在 Agent Builder 上有工作流的團隊，動作只有三個：今天匯出、兩週內並行驗證、11 月 25 日前切換。對還沒選平台的人，教訓更便宜：把工作流寫成程式碼、把評測寫成設定檔、把連接器接在開放標準上——下一個退場公告來臨時，你只需要換一行設定，而不是重寫整個產品。

---

資料來源

- OpenAI，〈Introducing AgentKit, new Evals, and RFT for agents〉（2025 年 10 月 6 日發佈，2026 年 6 月 3 日更新退場公告）：https://openai.com/index/introducing-agentkit/

- OpenAI 官方 deprecations 頁面（Agent Builder、Evals、v1/prompts 於 2026 年 11 月 30 日關閉；ChatKit 與 Agents SDK 留存）

- Osher，〈OpenAI AgentKit: Agent Builder Shuts Down on 30 November 2026〉（2026 年 11 月更新，含遷移步驟整理）：https://osher.com.au/blog/openai-agentkit/

- Forkast，〈OpenAI Agent Builder's Nov. 30 shutdown puts migration on a code-and-validation path〉：https://forkast.news/openai-agent-builders-nov-30-shutdown-puts-migration-on-a-code-and-validation-path/