隨著 GPT-5 正式推出，我們想進一步介紹整合它的最佳方式：Responses API，並說明 Responses 為何是專為推理模型與智慧體的未來量身打造。
每一代 OpenAI API 的設計都圍繞同一個問題： 對開發人員來說，與模型互動最簡單、最強大的方式是什麼？
我們的 API 設計始終以模型本身的運作方式為依據。最初的 /v1/completions 端點很簡單，卻也有侷限：你給模型一段提示詞，它就接續寫完你的想法。透過少樣本提示等技巧，開發人員可以嘗試引導模型輸出 JSON、回答問題等，但這些模型的能力遠不及我們今天習以為常的水準。
接著，RLHF、ChatGPT 與後訓練時代到來。模型突然不再只是接續你寫到一半的文字，而是像對話夥伴一樣 回應 你。為了跟上這個變化，我們打造了 /v1/chat/completions（只用了一個週末就完成，這段故事廣為人知）。透過 system、user、assistant 等角色，我們提供了一套架構，讓開發人員能快速建立帶有自訂指令與上下文的對話介面。
我們的模型持續進步，很快就開始能看、能聽，也能說。2023 年底推出的函式呼叫，成了我們最受歡迎的功能之一。差不多同一時間，我們推出了 Assistants API 測試版，首次嘗試提供完整的智慧體式介面，搭配程式碼解譯器、檔案搜尋等託管工具。有些開發人員很喜歡，但相較於 Chat Completions，它的 API 設計限制較多，也較難上手，因此始終未能獲得廣泛採用。
到了 2024 年底，我們顯然需要一套整合方案：像 Chat Completions 一樣容易上手、像 Assistants 一樣強大，同時專為多模態與推理模型設計。於是，/v1/responses 誕生了。
/v1/responses 是一個智慧體迴圈
Chat Completions 提供簡單的回合式對話介面，而 Responses 提供的是一個用於推理與行動的結構化迴圈。你可以把它想成與偵探合作：你提供證據，偵探展開調查，可能會諮詢專家（工具），最後再向你回報。偵探會在各個步驟之間保留自己的私人筆記（推理狀態），但從不把筆記交給委託人。
這正是推理模型能充分發揮實力的地方：Responses 會在這些回合之間保留模型的 推理狀態 。在 Chat Completions 中，推理不會保留到下次呼叫，就像偵探每次走出房間就忘了線索。Responses 則讓筆記持續保留，逐步思考的過程確實能延續到下一回合。這反映在基準測試成績（TAUBench 提升 5%）、更高的快取利用率，以及更低的延遲上。
Responses 也可以傳回多個輸出項目，不只呈現模型 說了什麼，也呈現它 做了什麼。你會拿到具體紀錄，包括工具呼叫、結構化輸出與中間步驟。這就像同時拿到寫好的文章與草稿紙上的演算過程，有助於除錯、稽核，以及建立更豐富的使用者介面。
{
"message": {
"role": "assistant",
"content": "I'm going to use the get_weather tool to find the weather.",
"tool_calls": [
{
"id": "call_88O3ElkW2RrSdRTNeeP1PZkm",
"type": "function",
"function": {
"name": "get_weather",
"arguments": "{\"location\":\"New York, NY\",\"unit\":\"f\"}"
}
}
],
"refusal": null,
"annotations": []
}
} {
"id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
"type": "reasoning",
"summary": [
{
"type": "summary_text",
"text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."
},
},
{
"id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
"type": "message",
"status": "completed",
"content": [
{
"type": "output_text",
"text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."
}
],
"role": "assistant"
},
{
"id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
"type": "function_call",
"status": "completed",
"arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
"call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
"name": "get_weather"
},透過託管工具提升抽象層級
在函式呼叫推出初期，我們注意到一個重要的使用模式：開發人員不僅用模型呼叫 API，也用它搜尋文件儲存庫，引入外部資料來源，這就是現在所說的 RAG。但對剛起步的開發人員而言，從零建立檢索流程既困難又昂貴。我們在 Assistants 中推出了第一批 託管 工具：file_search 與 code_interpreter，讓模型能執行 RAG 並編寫程式碼，解決你提出的問題。在 Responses 中，我們更進一步，加入網頁搜尋、圖像生成與 MCP。而且，由於工具會透過程式碼解譯器或 MCP 等託管工具在伺服器端執行，你不必讓每次呼叫都繞回自己的後端，因此能降低延遲與往返通訊成本。
安全地保留推理
那麼，為什麼要費這麼多工夫，隱藏模型的原始思路鏈（CoT）？直接公開 CoT，讓用戶端像處理其他模型輸出一樣處理它，不是更簡單嗎？簡單來說，公開原始 CoT 有多項風險，例如幻覺、不會出現在最終回應中的有害內容，對 OpenAI 而言，也會帶來競爭風險。
去年底我們發布 o1-preview 時，首席科學家 Jakub Pachocki 曾在我們的部落格寫道：
我們相信，隱藏的思路鏈為監測模型提供了獨特的機會。只要思路鏈能忠實反映模型的思考，且清晰可讀，隱藏的思路鏈就能讓我們「讀懂模型的心思」，了解它的思考過程。例如，未來我們可能希望監測思路鏈，找出模型試圖操縱使用者的跡象。不過，要做到這一點，模型就必須能自由表達未經修改的想法，因此我們不能透過訓練，讓思路鏈遵循任何政策或使用者偏好。同時，我們也不希望使用者直接看到未經對齊的思路鏈。
Responses 透過以下方式處理這個問題：
- 在內部保留推理，將其加密，且不向用戶端公開。
- 透過
previous_response_id或推理項目安全地延續推理，而不公開原始 CoT。
為何 /v1/responses 是開發的最佳選擇
我們將 Responses 設計成 能保留狀態、支援多模態且高效率的 API。
- 智慧體式工具使用： Responses API 讓你能輕鬆運用檔案搜尋、圖像生成、程式碼解譯器與 MCP 等工具，大幅強化智慧體工作流程。
- 預設保留狀態。 系統會自動追蹤對話與工具狀態，大幅簡化推理與多回合工作流程。透過 Responses 整合的 GPT-5，光是利用保留下來的推理，就能在 TAUBench 上取得比 Chat Completions 高出 5% 的成績。
- 從基礎架構就為多模態而設計。 文字、圖像、音訊、函式呼叫，都享有完整的原生支援。我們沒有在文字 API 上硬加其他模態；就像蓋房子一樣，我們從第一天起就規劃了足夠的房間。
- 成本更低，效能更好。 內部基準測試顯示，相較於 Chat Completions，快取利用率提升了 40–80%。這代表更低的延遲與成本。
- 更好的設計： 我們從 Chat Completions 與 Assistants API 累積了許多經驗，並在 ResponsesAPI 與 SDK 中做了一系列小幅改進，讓開發更順手，包括：
- 具備語意的串流事件。
- 採用內部標記的多型。
- SDK 中的
output_text輔助功能（不再需要使用choices.[0].message.content）。 - 多模態與推理參數的組織方式更完善。
那 Chat Completions 呢？
Chat Completions 不會消失。如果它符合你的需求，請繼續使用。但如果你希望推理能持續保留、多模態互動自然流暢，而且智慧體迴圈不必靠各種權宜做法拼湊，Responses 就是接下來的方向。
展望未來
就像 Chat Completions 取代了 Completions，我們預期 Responses 將成為開發人員運用 OpenAI 模型進行開發的預設選擇。它能在你需要簡單時保持簡單，在你需要強大功能時發揮實力，也有足夠的彈性，因應下一個典範帶來的各種挑戰。
未來幾年，我們都會以這套 API 為基礎持續開發。