Responses API 與 Chat Completions 在 Agent 應用上的比較：如何選擇合適的 Contract

對於代理程式（Agent）的工作負載而言，Responses API 是更好的預設選擇：它透過 previous_response_id 提供伺服器端的對話狀態管理、以型別化的輸出項目取代單一訊息區塊，並支援語意串流事件。這些功能減少了您的編排層（orchestration layer）原本需要自行處理的繁瑣事務。當您需要完全控制訊息歷史記錄，或是正在整合圍繞 OpenAI 聊天訊息格式構建的工具時，Chat Completions 仍然是一個有效的選擇；但對於多輪工具呼叫（multi-turn tool-calling）的代理程式來說，Responses 是更直接的契合方案。

這兩個端點皆已記錄在 GPT-5.6 與 GPT-5.5 的當前模型參考頁面中，而 Responses 的共享請求/回應合約則詳列於 Responses create 參考文件。

重點摘要

• Chat Completions 由呼叫端管理：您必須在每次請求時發送完整的 messages 陣列，並自行重建歷史記錄。
• Responses 由伺服器輔助：您發送 input 以及選用的 instructions，並可透過 previous_response_id 串接對話輪次，無需重新發送歷史記錄。
• 工具呼叫的結構不同：Chat Completions 將呼叫巢狀於 choices[0].message.tool_calls 中；Responses 則將其作為型別化項目發送在扁平的 output 陣列中。
• 工具結果的匹配方式：Chat Completions 使用 tool_call_id，而 Responses 則使用 function_call_output 項目上的 call_id。
• 串流處理：Chat Completions 為基於區塊的 delta，而 Responses 為具名的語意事件。
• 託管工具支援（網頁搜尋、程式碼解釋器、檔案搜尋等）：在兩個 API 中皆取決於模型；在假設可用性之前，請先查閱該模型的頁面。

欄位層級比較

關注點	Chat Completions	Responses
端點	POST /v1/chat/completions	POST /v1/responses
主要輸入	messages: []（每次呼叫皆需完整陣列）	input（字串或項目陣列）
系統級指引	messages[0].role = "system"	頂層 instructions 欄位
多輪延續	呼叫端需重新發送完整 messages 歷史	previous_response_id 在伺服器端參照前一輪
輸出格式	choices[0].message（單一訊息物件）	output: []，型別化項目陣列（訊息、function_call 等）
工具呼叫位置	choices[0].message.tool_calls[]	output 中 type: "function_call" 的項目
工具結果提交	帶有 role: "tool", tool_call_id 的新訊息	帶有 type: "function_call_output", call_id 的項目
串流	chunk.choices[0].delta 片段	具名事件（response.output_text.delta, response.completed 等）

previous_response_id：其實際作用

在 Chat Completions 中，對話記憶完全由您負責。每個請求都必須包含完整的訊息歷史，伺服器對前一輪對話毫無概念。相反地，Responses API 會在每個回應物件上回傳一個 id。如果您的應用程式持久化該 id 並在下一次呼叫時將其作為 previous_response_id 傳回，伺服器就會在內部重建先前的對話狀態。您只需發送當前輪次的 input 以及（選用的）新的 instructions。這將狀態管理從您的應用層轉移到了 OpenAI 的基礎設施上，對於進行多次連續工具呼叫的代理程式來說，這非常重要，因為您可以避免在每次跳轉時重新序列化並傳輸不斷增長的歷史記錄。

其權衡之處在於，您的應用程式仍需在輪次之間將 id 持久化到某個地方（例如會話儲存、資料庫列）；API 不會為您提供無限期的保留或對過去回應的搜尋功能，它只是讓您能將緊接的前一個回應作為延續點進行參照。

當前請求範例 (gpt-5.6)

Chat Completions： 您擁有完整的歷史記錄：

{
  "model": "gpt-5.6",
  "messages": [
    { "role": "system", "content": "You are a support agent." },
    { "role": "user", "content": "Check order #4471 status." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_order_status",
        "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
      }
    }
  ]
}

Responses： 帶有 instructions 和 input 的第一輪：

{
  "model": "gpt-5.6",
  "instructions": "You are a support agent.",
  "input": "Check order #4471 status.",
  "tools": [
    {
      "type": "function",
      "name": "get_order_status",
      "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
    }
  ]
}

Responses： 後續輪次，無需重新發送歷史記錄：

{
  "model": "gpt-5.6",
  "previous_response_id": "resp_abc123",
  "input": "What about order #4472?"
}

函式呼叫生命週期

Chat Completions：

1. 模型回傳 choices[0].message.tool_calls，每個呼叫皆包含 id 與函式名稱/參數。
2. 您在本地執行該函式。
3. 您將助理訊息（包含 tool_calls）附加到您的 messages 陣列，然後附加一則新訊息：{ "role": "tool", "tool_call_id": "<id>", "content": "<result>" }。
4. 您重新發送整個更新後的 messages 陣列以繼續。

Responses：

1. output 陣列包含一個 type: "function_call" 的項目，其中包含 call_id、name 與 arguments。
2. 您在本地執行該函式。
3. 您發送一個新請求，將 previous_response_id 設為前一個回應的 id，並將 input 設為包含一個 type: "function_call_output" 的項目，匹配 call_id 以及執行結果。
4. 伺服器已保留函式呼叫上下文，因此您無需重新發送先前的輪次。

扁平的型別化輸出項目與帶有巢狀陣列的單一訊息之間的結構差異，往往能簡化 Responses 中的解析邏輯，因為您可以迭代 output 並根據 type 進行切換，而不必深入挖掘訊息的選用欄位。

決策檢查清單

• 正在構建帶有工具呼叫的多輪代理程式嗎？ 預設使用 Responses；previous_response_id 可省去歷史記錄的簿記工作。
• 需要精確控制歷史記錄內容嗎（如編輯、自訂摘要、非標準訊息注入）？Chat Completions 讓您能明確控制，因為您可以自行組裝 messages。
• 正在遷移現有的 Chat Completions 整合嗎？ 權衡重構成本與狀態管理節省的效益；對於短暫、單輪的呼叫，其效益較小。
• 依賴託管工具嗎（搜尋、程式碼解釋器、檔案工具）？在投入開發前，請先在該模型的頁面上驗證支援情況，因為可用性會隨模型與端點而異。
• 需要具備細粒度事件語意的串流嗎（例如，無需檢查 delta 形狀即可區分文字 delta 與工具呼叫 delta）？Responses 的具名事件比 Chat Completions 的通用 delta 區塊更明確。
• 在圍繞聊天訊息構建的現有框架或 SDK 中工作嗎？ 在專案中途切換合約前，請確認其對 Responses 的支援成熟度。

多供應商代理程式與合約轉換

代理程式很少長期停留在單一供應商上。編碼代理程式可能會路由至 Claude Sonnet 5 或 Kimi K2.7 Code 進行實作工作，退回到 DeepSeek V4 Flash 或 Gemini 3.5 Flash 進行低成本草稿生成，偶爾呼叫 GLM-5.2 或 Qwen3.7 Plus 進行開源權重成本控制。這些供應商不一定原生公開 OpenAI 的 Chat Completions 或 Responses 合約。

這正是路由層發揮價值的地方。TokenLab 在 docs.tokenlab.sh 的文件描述了一個單一 API 介面與金鑰，可用於存取多個模型供應商，這消除了為每個供應商合約手寫獨立客戶端整合的需求。我們關於 合約相容性標頭別名 的相關文章介紹了如何映射請求標頭，以便針對一種合約形狀編寫的程式碼可以存取不原生支援該合約的模型。如果您正在構建一個需要呼叫多個模型系列的聊天機器人或代理程式，我們關於 使用單一 API 金鑰構建 AI 聊天機器人 的指南提供了更具體的設定步驟。

如需透過 TokenLab 存取的完整當前模型列表（包括上述提到的前沿模型、編碼模型與低成本路由選項），請參閱 我們的模型頁面。在最終確定您的架構之前，請先確認當前的可用性與任何合約特定的注意事項，因為模型陣容的變更頻率高於 API 合約的變更頻率。

限制

本文並未重述 OpenAI 針對任一合約的精確欄位層級 API 參考，因為這些細節會隨版本更新而變動。請勿將上述的請求形狀範例視為生產環境就緒的程式碼。我們也未在此深入涵蓋每家供應商的原生合約；Claude、Gemini、DeepSeek 與 GLM 各自發布其 API 參考，且它們沒有義務匹配 OpenAI 的 Chat Completions 或 Responses 格式。如果您的代理程式對工具呼叫順序、串流事件格式或批次處理行為有保證需求，請根據該供應商的當前文件進行驗證，而非根據本文。

常見問題 (FAQ)

Responses API 是 Chat Completions 的替代品嗎？ OpenAI 的快速入門文件將 Responses API 定位為新開發（包括代理程式使用案例）的當前路徑，而 Chat Completions 仍然是其記錄的 API 介面的一部分。Chat Completions 在任何特定時間點是否被棄用、停止維護或僅僅是舊版，您應直接在 OpenAI 的當前文件中確認，因為支援狀態可能會改變。

Claude、Gemini 或 DeepSeek 等其他供應商使用相同的合約嗎？ 並非原生使用。每家供應商都定義了自己的請求與回應格式。如果您需要在 OpenAI 模型以及 Claude Sonnet 5 或 DeepSeek V4 Pro 等供應商之間執行代理程式，請規劃一個轉換層，而不是假設存在共享合約。

切換合約會改變模型輸出品質嗎？ 不會。合約是請求與回應的傳輸與結構，而非模型本身。輸出品質取決於您呼叫的模型（例如 GPT-5.5 與 Claude Sonnet 5），而非您使用 Chat Completions 還是 Responses API 來呼叫它。

如果您正在評估哪種合約與哪些模型適合您的代理程式，請從針對 TokenLab 記錄的端點進行小型測試建置開始，並直接比較編排開銷。請前往 docs.tokenlab.sh 開始針對您的工作負載進行比較。