架構

使用 OpenAI Responses API 建構有狀態代理：實用指南

作者：IdeaBosque最後更新：2026年9月5日

關鍵要點

Responses API 是 OpenAI 推薦的所有新專案的 API 原語，Assistants API 已於 2026 年 8 月 26 日下線 — 遷移窗口已關閉；Chat Completions 仍然受支援，但新的代理能力不會先在這裡落地。
OpenAI 內部評測顯示，通過 Responses API 使用 GPT-6 Astra 等推理模型時，SWE-bench 提升 3%，快取利用率提高 40–80% — 代理迴圈不僅是便利，它可衡量地提升了輸出品質。
遠端 MCP 伺服器是 Responses API 中的一等工具型別 — 你只需用 server_url 和 server_label 連接任意 MCP 伺服器，模型就會在同一請求內發現並呼叫其工具，無需自訂編排。
GPT-6 Astra 的失準監控器在偵測到未授權行為時會直接停止 API 任務 — 沒有恢復路徑；工作流程必須能從持久狀態恢復，這是生產級採用中最重要的架構約束。
有狀態模式比無狀態 Chat Completions 大約慢 2 倍，據多位開發者報告 — previous_response_id 的便利性伴隨著延遲代價，對延遲敏感的面向使用者流程影響顯著。

OpenAI Responses API 是公司推薦用於所有新開發的 API 原語，Assistants API 已於 2026 年 8 月 26 日正式下線。Chat Completions 仍然受支援，但 Responses API 是新代理能力——內建工具、有狀態對話、遠端 MCP、背景模式、中途引導——首先落地的地方。對於在 GPT-6 Astra 上建構生產級代理的團隊，問題不再是是否遷移，而是如何圍繞 API 的狀態模型、其延遲特徵和 Astra 執行時監控器施加的治理約束進行架構設計。本指南梳理了五項關鍵能力、三個決定採用的決策，以及保持你的代理跨供應商可移植的架構模式。

Responses API 改變了什麼

Chat Completions API 是無狀態的：你每次請求都發送完整的對話歷史，API 傳回單一訊息。Responses API 引入了三個結構性變化，影響你建構代理的方式。

用 Item 代替訊息。 Chat Completions 傳回 choices 陣列，每個包含一個 message。Responses API 傳回 output Item 陣列，每個 Item 是一個型別化聯合體——message、function_call、function_call_output、推理摘要或工具呼叫。這不是裝飾性的：這意味著工具呼叫、推理和文字是回應中的一等物件，而非附加在訊息上的欄位。當你用 previous_response_id 連結回應時，API 跨輪次保留所有 Item 型別——包括加密推理——這正是讓多輪代理工作流程無需手動上下文重播即可運作的原因。

一個請求中的代理迴圈。 Responses API 被設計為代理迴圈：模型可以在單次 API 呼叫中呼叫多個工具——web_search、file_search、computer_use、code_interpreter、image_generation、遠端 MCP 伺服器和自訂函式——反覆運算直到達到停止條件。用 Chat Completions 時，你需要自己實作這個迴圈：呼叫模型、解析工具呼叫、執行它、附加結果、再次呼叫。Responses API 在伺服端執行迴圈。OpenAI 內部評測顯示，通過 Responses API 使用推理模型時 SWE-bench 提升 3%，快取利用率提高 40–80%——伺服端迴圈受益於手動迴圈無法複製的快取命中。

通過 previous_response_id 實現有狀態上下文。 你不再每次請求發送完整歷史，而是傳遞前一個回應的 ID 和新的使用者輸入。API 在伺服端重建上下文，包括推理 Item。回應預設儲存 30 天；附加到對話的任何回應持久化其 Item 且無 TTL。你可以用 store: false 停用儲存來實現零資料保留工作流程，但那樣你必須手動重播完整的 Item 歷史——包括加密推理 Item——以跨輪次保留推理上下文。

五項關鍵能力

Responses API 的能力對映到五個架構決策，每個都有具體的權衡：

1. previous_response_id：有狀態鏈式呼叫

最簡單的有狀態模式通過 ID 連結回應：

from openai import OpenAI
client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    store=True,
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="And its population?",
    store=True,
)

第二次呼叫不會重新發送第一個問題或答案。API 從儲存的回應中重建完整上下文，包括模型執行的任何推理。這是對話代理、研究助手和任何後續取決於前序輪次的工作流程的模式。

權衡是延遲。OpenAI 社群論壇和 Microsoft Q&A 上的多位開發者報告表明，有狀態路徑比無狀態 Chat Completions 大約慢 2 倍——典型情況下 1 秒對 0.5 秒，負載下最多慢 9 倍（2.9 秒對 0.3 秒）。對於執行數分鐘的背景研究代理，這無關緊要。對於必須在 500ms 典回應的面向使用者聊天，延遲代價可能證明繼續使用帶手動上下文管理的 Chat Completions 是合理的。

2. 遠端 MCP 伺服器作為內建工具

Responses API 支援遠端 MCP 伺服器作為一等工具型別。你通過 URL 註冊伺服器，模型在代理迴圈中發現其工具並呼叫：

response = client.responses.create(
    model="gpt-6-astra",
    tools=[{
        "type": "mcp",
        "server_label": "inventory",
        "server_description": "NetSuite inventory and pricing lookups",
        "server_url": "https://your-mcp-server.example.com/mcp",
        "require_approval": "never",
    }],
    input="Check stock levels for SKU A100-23 and suggest a reorder quantity.",
)

require_approval 欄位控制模型在呼叫伺服器工具前是否需要人工審批。對於生產部署，MCP 工具過濾選項——allowed_tools 白名單特定工具名稱，以及按工具的自訂審批策略——是防止模型在未獲明確授權時呼叫破壞性操作的治理層。

這是與 IdeaBosque 整合模式最相關的能力。一個封裝 NetSuite、HubSpot 或 BigCommerce API 的自訂 MCP 模組可以註冊為 Responses API 呼叫中的遠端 MCP 伺服器，模型使用它的方式與使用 web_search 或 code_interpreter 相同。語意層——型別化 schema、稽核日誌、速率限制處理——存在於 MCP 模組中，而非 prompt 中。Responses API 不解決語意層問題；它使 MCP 模組成為自然的整合點。關於該模式的深入探討，參見 MCP Module Code Standard。

3. 背景模式用於長時間執行任務

背景模式將模型呼叫與客戶端連線解耦。API 接受請求，立即傳回回應 ID，非同步執行模型工作。你輪詢狀態或串流接收結果：

resp = client.responses.create(
    model="gpt-6-astra",
    input="Analyze all 200 RFQs from last week and categorize by supplier risk tier.",
    background=True,
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.output_text)

對於長時序代理——研究綜合、批次文件分析、多步採購工作流程——背景模式是能在網路中斷和客戶端逾時中存活的模式。一個耗時六分鐘的背景回應不依賴活躍的 HTTP 連線；如果客戶端斷開，工作繼續，你使用最後的序號通過串流恢復重新連線。

維運上的問題是背景模式不是作業佇列。正如一篇分析所述：API 執行模型呼叫，但你的應用仍然擁有作業狀態——UI 顯示什麼、如何避免重複處理 webhook、何時取消不再需要的工作。對於生產環境，你需要在背景回應周圍有一個持久作業系統，而不僅僅是回應 ID。這與 Long-running Agent Patterns 中描述的模式相同：代理執行時，而非模型 API，才是可靠性層。

4. 加密推理用於零資料保留工作流程

當 store: false 時，API 不持久化回應，但在輸出中傳回加密推理 Item。你在下一個請求的輸入中傳回這些 Item，以跨輪次保留推理上下文，而不會在 OpenAI 的伺服器上儲存任何內容。這是禁止資料保留的受監管環境的模式——EU AI Act 高風險系統、HIPAA 下的醫療工作流程、ITAR 下的國防工作流程。

權衡是你成為了狀態儲存方。你必須在每個輪次序列化、儲存和重播完整的 Item 陣列——包括不透明的加密推理 blob。如果你丟失了加密推理 Item，模型就會失去推理上下文，輸出品質會下降。這與 Chat Completions 相同的狀態管理負擔，但多了一個需要處理的 Item 型別。

5. Astra 任務停止監控器

GPT-6 Astra 在每個使用工具的請求上都配備了失準監控。當監控器標記潛在未授權行為時，模型的回應包含停止訊號。在 ChatGPT 和 Codex 中，使用者看到暫停的任務以供審查。在 API 中，任務直接停止——沒有恢復路徑。

對於在 Responses API 上建構的生產代理，這是最重要的架構約束。一個通過 previous_response_id 鏈或背景模式執行數小時的任務可能被分類器中途終止。你的工作流程必須能從持久狀態恢復——每次工具呼叫、每個中間結果、每個部分輸出必須在下一次 API 呼叫前持久化到你自己的儲存中。如果監控器在第 47 步（共 50 步）停止任務，你需要能從第 47 步恢復，而非從零重啟。

OpenAI 首席科學家 Jakub Pachocki 在 An Alien Mind（2026 年 9 月 6 日）中透露，公司依賴思維鏈監控的能力正在「逐步減弱」——模型更擅長推理和操縱自己的推理過程，改進的預訓練使模型即使沒有言語化推理也更聰明。停止你任務的監控器是現有最好的執行時執行層，但其供應商已表示它依賴的訊號正在退化。關於不讀取模型推理的執行層的深入探討，參見 GPT-6 Astra Ships the Runtime Kill Switch。

三個採用決策

決策 1：有狀態還是無狀態？

當你的工作流程是對話式、多輪次且延遲容忍時，使用 store: true 配合 previous_response_id。當你的工作流程要求零資料保留或你需要完全控制上下文管理時，使用 store: false 配合手動 Item 重播。延遲差異大約 2 倍——對背景代理可接受，對面向使用者的聊天可能不可接受。

決策 2：內建工具還是自訂函式？

內建工具（web_search、file_search、code_interpreter、computer_use、image_generation、遠端 MCP）在伺服端執行並受益於代理迴圈的快取最佳化。自訂函式需要你自己實作工具呼叫迴圈。實踐規則：對於 OpenAI 提供得比你更好的能力（網路搜尋、程式碼執行）使用內建工具，對於你自己的系統整合（NetSuite、HubSpot、BigCommerce）使用遠端 MCP 伺服器。僅對無法暴露為 MCP 伺服器的能力使用自訂函式。

決策 3：僅 OpenAI 還是模型靈活？

Responses API 是 OpenAI 的原語。如果你完全基於 previous_response_id 和內建工具建構代理，你就被鎖定在 OpenAI 的狀態儲存和工具生態中。如果你的生產需求包括模型靈活性——將敏感成本的任務路由到 Qwen3.8-27B 等開放權重模型，或路由到 Claude 的特定能力——你需要一個抽象層，在 Responses API 的 Item 模型和其他供應商使用的 Chat Completions 訊息格式之間轉換。

這是決定 Responses API 是你整個代理執行時還是多個後端之一的架構決策。模型靈活的建構將代理迴圈保留在你自己的執行時中，在 Responses API 的能力值得其延遲和鎖定代價時使用它，在不值得時回退到 Chat Completions 或開放權重推理。推理經濟學很明確：29% 的生產 token 用量已經在開放權重模型上執行，支出不到 4%。路由紀律是生產現實，而非未來計畫。

遷移清單

OpenAI 的遷移指南提供了完整清單。影響架構而非僅程式碼的決策：

確定你的狀態模型。 previous_response_id、手動 Item 重播或 Conversations API。這決定了你的延遲特徵和資料保留姿態。
稽核你的函式定義。 自訂函式原樣遷移，但函式呼叫輸出必須包含正確的 call_id。在手動傳遞上下文時丟棄推理或函式呼叫 Item 是最常見的遷移錯誤。
將 Structured Outputs schema 從 response_format 移至 text.format — 欄位名已更改。
為任何執行超過幾秒的工作流程新增持久狀態持久化。 Astra 任務停止監控器可以在沒有恢復路徑的情況下終止長任務；你的狀態儲存是恢復機制。
在路由生產流量之前比較延遲、token 使用量和錯誤率。 3% SWE-bench 提升和 40–80% 快取改善是平均值；你的工作負載可能不同。
保留 Chat Completions 回退，如果模型靈活性很重要。Responses API 僅限 OpenAI；其他供應商使用 Chat Completions。