OpenAI Agents API 是什麼？多智能體協作官方規格與中小企業對策
OpenAI 正式發布 Agents API：多智能體協作終於有官方規格，你的土炮架構怎麼辦
OpenAI 把多個 AI agent 怎麼分工，寫成了正式 API 規格，官方文件已掛出完整章節。土炮自建架構的保存期限開始倒數。
本文撰於 2026-09-11。當日 OpenAI 官方開發文件 已掛出完整的 Agents API 章節樹。以下每一項能力敘述，都以官方文件目錄裡實際存在的章節為依據；價格、速率限制、開放區域這些，撰稿時官方未公布，本文一律不寫。
先講白話定義。agent（智能體）指的是「會自己決定下一步、會呼叫工具、會來回跑很多輪」的 AI 程式，跟問一句答一句的聊天機器人是兩種東西。多智能體協作（multi-agent）指讓好幾支這種程式分工：一支接客訴、一支查庫存、一支寫回信，彼此交棒。
OpenAI Agents API 是什麼，跟自己串接 ChatGPT API 做 agent 有什麼不一樣？
Agents API 是 OpenAI 把「agent 怎麼跑、怎麼記狀態、怎麼交棒」定義成官方端點的一套規格。自己串 ChatGPT API 做 agent，等於這些協作邏輯全部由你的工程師自行設計、自行維護。差別在誰擁有那套骨架。
自建路線的典型長相：你用一支 API 拿模型輸出，外面自己寫迴圈、自己存對話狀態、自己判斷什麼時候該叫哪支工具、自己攔錯誤重試。這些程式碼沒有任何外部標準，換人接手就是考古。
官方規格路線則把這些變成文件上的章節名。官方文件目錄 的 Agents API 區塊底下，明列 Architecture（架構）、Configuring Agents（設定 agent）、Sessions（工作階段）、Multi-agent（多智能體）、Observability and usage（可觀測性與用量）等項目——也就是說，協作骨架不再是你家的私有實作，而是雙方共用的公開介面。
官方文件目錄裡，Agents API 實際列出了哪些東西？
依 OpenAI 開發文件 的側欄章節樹，Agents API 至少涵蓋六個面向：會話管理、沙盒環境、檔案與產出物、工具整合、多智能體、可觀測性。以下逐項對照目錄原文。
| 官方章節群 | 目錄中列出的子項 | 對應到你現在自己在寫的東西 |
|---|---|---|
| Sessions | Run and continue sessions、Events and items、Manage sessions、Webhooks | 對話狀態存哪、跑到一半怎麼續、事件怎麼回拋 |
| Environments and sandboxes | OpenAI-hosted sandboxes、Self-hosted sandboxes、Sandbox lifecycle、Sandbox security | agent 執行程式碼的隔離環境與權限控管 |
| Files and artifacts | （單一章節） | agent 產出的檔案往哪放、怎麼取回 |
| Tools and integrations | Web search、Functions、MCP connections、Plugins、Vaults | 自訂工具註冊、外部系統接法、金鑰保管 |
| Multi-agent | （單一章節） | 誰指派誰、交棒規則、失敗回收 |
| Observability and usage | Tracing | 出錯時怎麼追一整條鏈、誰燒了多少 token |
其中 MCP（Model Context Protocol，讓 AI 統一接外部系統的開放協定）以獨立子章節出現，代表官方把「接你家進銷存、客戶資料系統」這件事放進規格內部，而非外掛。
另外，文件把 Agents SDK 列為與 Agents API 並列的獨立章節群，底下有 Orchestration（編排）、Guardrails（護欄）、Running agents、Sandbox agents 等項目；Get started 區則出現「Using GPT-6 Astra」。GPT-6 Astra 的能力細節與定價，官方開發文件撰稿時只見這個章節標題、未見公開摘要，本文不揣測。
自己串 API、Agents API、Agents SDK，我該選哪一個？
三條路線最該比的兩件事：協作邏輯由誰負責、出事時誰有現成答案。下表用六個維度直接比。Agents API 與 Agents SDK 兩欄只填官方文件目錄確實列出的章節，自建欄是我們的判斷。
| 比較維度 | 自己串 ChatGPT API | Agents API（官方端點） | Agents SDK（官方套件） |
|---|---|---|---|
| 協作邏輯誰設計 | 你的工程師從零設計 | 依官方 Multi-agent 章節規格 | 依官方 Orchestration 章節規格 |
| 狀態與續跑 | 自建資料表、自己處理中斷 | Sessions：Run and continue、Manage sessions | 由 SDK 的 Running agents 處理 |
| 執行環境隔離 | 自己架容器、自己管權限 | OpenAI-hosted／Self-hosted sandboxes、Sandbox security | Sandbox agents |
| 外部系統接入 | 每套系統寫一次黏合程式 | Functions、MCP connections、Plugins、Vaults | 目錄未單獨拆出工具／MCP 章節，最接近的是 Integrations and observability（同列於下方出錯追查一欄） |
| 出錯追查 | 自己埋 log、自己拼時序 | Observability and usage：Tracing | Integrations and observability |
| 換手與轉移成本 | 只有原作者看得懂 | 公開文件即交接文件 | 公開文件即交接文件 |
選法很直接：新案子從 Agents API 或 Agents SDK 起手，讓官方文件當你的規格書；已經上線的自建系統先別急著全拆。
為什麼說現在自建的 agent 架構遲早要重做？
因為 OpenAI 已經替兩套 agent 做法各出了一份遷移指南。證據就印在文件目錄上：Agent Builder 與 Assistants API 各自掛著一份 Migration guide（遷移指南）；側欄的 Resources 區塊下依序列出 Changelog、Deprecations（棄用）、Supported countries、OpenAI Crawlers、Terms and policies、Legacy APIs（官方文件未標示階層，此處僅依目錄順序陳述）。
官方替一套做法出遷移指南，通常就是在說下一步往哪走；文件主線放的是 Agents API 與 Agents SDK。規格換位時，跟著官方規格走的人，至少拿得到一份遷移指南；照自己想像寫的人，什麼都拿不到。
所以判斷句是這樣：土炮架構真正的風險是跑得動，但沒人能改、也沒有遷移路徑。至於「多久會被淘汰」，官方沒有給時間表，我們也不編一個機率出來。
這對台灣中小企業意味著什麼？
意味著你外包給工程師的那筆「協作邏輯設計費」，正在快速貶值。以前要付錢請人想清楚 AI 客服怎麼把單子交給 AI 排單，現在這件事有官方章節寫著怎麼做，報價裡的這一項應該被壓下來。
具體到採購動作，分三種情況：
還沒開始做的：直接要求廠商照 Agents API 或 Agents SDK 規格實作，把「不得自行發明協作框架」寫進合約需求。你買到的東西要能被下一個工程師接手。
正在外包開發中的：現在就叫廠商說明，目前的 session 管理、工具註冊、錯誤追查是自己寫的還是照官方章節走。若答案是前者，要求對照上表逐項評估切換成本，趁還沒上線改比較便宜。
已經上線土炮版的：重寫的預算先收回口袋。這一季只動一項工程——把「協作邏輯」從業務程式碼裡抽出來獨立成一層，讓哪支 agent 負責什麼、怎麼交棒的判斷集中在一個檔案。日後要換成官方規格，改的範圍就停在那一層，其餘系統原封不動。
還有一件不屬於技術、但屬於老闆的事：把更多營運流程搬到單一供應商的官方規格上，供應商的帳號設定就成了你的營運風險。撰稿當下 Hacker News 上有一則 433 分、178 則留言的討論串，使用者 jacquesm 回報 OpenAI 的「允許訓練」設定被重複重新開啟，討論串在此。串中有人回報在其他 AI 服務也遇過類似狀況。這件事跟 Agents API 沒有因果關係，但它提醒一個該排進行事曆的動作：定期複查你公司帳號的資料訓練與保存設定，別當成一次性勾選。
採用官方規格前，老闆該自己盯哪三個問題？
規格統一之後，技術選型變簡單，治理問題反而浮上來。以下三題，建議在下一次跟廠商開會時直接問。
第一，沙盒權限開到哪。官方文件把 Sandbox security 列為獨立章節，代表 agent 執行環境的權限是要設定的，不是預設安全。問清楚你的 agent 能碰到哪些檔案、哪些內網服務。
第二，金鑰怎麼保管。目錄裡 Vaults 與 MCP connections 並列在 Tools and integrations 底下。你的進銷存帳密、金流金鑰交給 agent 使用時，存放方式要寫進交付文件。
第三，出事怎麼回溯。Tracing 是官方列出的可觀測性章節。要求廠商示範一次：某張單子被 AI 排錯，你要能在幾分鐘內看到是哪一支 agent、哪一輪、用了什麼輸入做出的決定。答不出來的廠商，交付品質先打折。
我們自己在做 AI 內容與自動化流程時的原則也一樣：涉及錢、合約、對外承諾的動作，一律停在人這關由老闆點頭，其餘讓機器跑完。想看這套「機器全包執行、人只做閘門」怎麼落到實際流程，可以從 mingnow.airun.tw 這邊看起。
所以，新案該照規格接、舊案該怎麼辦？
立場講明白。2026 年 9 月之後才啟動的 AI 多 agent 專案，沒有理由再自行發明協作框架，照 官方 Agents API 文件 的章節結構實作，是成本最低、交接最順的選擇。
已經上線的自建系統，這一季的功課有兩項：協作邏輯抽成獨立一層，並要求廠商補上可觀測性與金鑰保管的交付文件。兩項都結案之後，下一次 OpenAI 再改規格，你付的是改一層的錢，整套重來的帳單可以省下。
至於定價、配額、正式開放範圍，官方撰稿時未公布。在數字出來以前，把架構整理好的公司，會是數字出來當天就能動的那批。
常見問題
OpenAI Agents API 是什麼？
Agents API 是 OpenAI 把「多個 AI agent 怎麼跑、怎麼記狀態、怎麼交棒」定義成官方端點的一套規格。官方開發文件目錄下已列出 Architecture、Sessions、Multi-agent、Observability 等章節，把過去各家自行設計的協作骨架，收斂成公開的共用介面。
跟自己串接 ChatGPT API 做 agent 差在哪？
自己串 API 的話，執行迴圈、對話狀態、工具註冊、錯誤重試全部由你的工程師從零設計，沒有外部標準，換人接手就是考古。走官方規格則是這些骨架都有對應章節，公開文件本身就是交接文件，也才拿得到日後的遷移指南。
已經上線的自建 agent 系統要立刻重寫嗎？
不用。停機重寫是最貴的一種做法。本季把協作邏輯從業務程式碼抽出來、獨立成一層，讓「哪支 agent 負責什麼、怎麼交棒」集中在一處就夠了。之後要換成官方規格時，動到的是那一層，而非整個系統，成本差距很大。
Agents API 和 Agents SDK 是同一個東西嗎？
不是同一個。官方文件把兩者列為並列的獨立章節群：Agents API 走端點，底下有 Sessions、Multi-agent、Sandboxes；Agents SDK 是套件，底下有 Orchestration、Guardrails、Sandbox agents。實作前先確認要走哪一條。
Agents API 怎麼收費、什麼時候全面開放？
截至 2026-09-11 撰稿時，官方開發文件沒有公開定價、速率限制與開放區域的整理資訊，本文不做推測。在數字公布以前，先把架構與交付文件整理好的公司，會是數字出來當天就能動手的那批。
把公司流程搬上官方規格，資料安全要注意什麼？
至少三件事：沙盒權限開到哪（官方把 Sandbox security 列為獨立章節，代表權限要自己設定）、金鑰怎麼保管（Vaults 與 MCP connections 同列在工具整合底下）、出錯怎麼用 Tracing 回溯。另外要定期複查公司帳號的資料訓練與保存設定，別當成一次性勾選。