OpenAI DevDay 2026 開發者指南：Responses API、Structured Outputs、Tool Calling 與 MCP 可能有哪些新變化？

這篇指南怎麼用：和預測文的分工

預測文回答「舞臺上可能講什麼」。本篇回答「你這周該把哪些 JSON 寫進倉庫」。兩篇共用同一條 2026 軌跡，但讀者動作不同：前者用來對照主題演講；後者用來凍結 schemas/ 目錄。不要爲了預測重寫產品。DevDay 很少從零發明一條 API，更多是把預覽、Beta、企業白名單收成默認產品。

先把「已經是事實」和「可能宣佈」分開。已經是事實的：Responses 是 Agent 能力的主路徑；Structured Outputs 用 text.format.json_schema + strict 鎖最終對象；函數工具與遠程 MCP 可以掛在同一次 responses.create；MCP 默認會先要審批（mcp_approval_request），也可用 require_approval / allowed_tools 收窄。這些不是預測。可能宣佈的，是關停日期、GA 摘牌、自助開關和「兩份 Schema 允許聲明同源」。

有用的讀法不是「會不會出 GPT-5.7」，而是：哪條請求面會被宣佈爲唯一推薦路徑？哪份 JSON Schema 會從模型建議變成平臺強制？哪層會話狀態會從你自己的數據庫，遷到官方 Conversations？對照如下。

Responses API：可能收口的請求面

Assistants 已經死了。Chat Completions 還活着，但 2026 年的新能力幾乎不再往那裏加：遠程 MCP、Tool Search、Computer Use、Skills、hosted shell、WebSocket Responses、phase（commentary / final_answer）都掛在 Responses。可複用 Prompt 從未進入 Chat Completions。這不是口味問題，是平臺在把「能做 Agent 的面」收成一條。對象怎麼從 Assistant / Thread / Run 遷過來，見 Assistants → Responses 遷移。

DevDay 最可能動刀的不是「再多一個 Responses 參數」，而是三件事裏的若干件：給 Chat Completions 一個明確凍結或關停日期；把 Conversations 收成跨文本 Responses 與 Realtime 的統一會話原語；把圖像、轉錄、視頻更多以內置 tool 的形式寫進同一條 output item 時間線。對你意味着：新封裝只認 input / output item、tools[]、text.format、previous_response_id 或 conversation。不要再維護兩套 tools[] 形狀。

請求元數據也會被收口。Fast 已替 Priority，Ultrafast 仍是有限預覽；service_tier、prompt_cache_retention、safety_identifier 現在就該寫成顯式字段，而不是埋在 SDK 默認值裏。主題演講後你要對得上賬單、緩存命中和安全攔截，靠的是這些鍵，不是模型名字。下面這份骨架今天合法，DevDay 後大概率仍合法：函數工具、遠程 MCP 與 Structured Output 走同一條 responses.create。

{
  "model": "gpt-5.6-sol",
  "input": "Extract the paid invoice and call billing tools",
  "tools": [
    {
      "type": "function",
      "name": "searchInvoices",
      "strict": true,
      "parameters": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["draft", "sent", "paid", "void"]
          }
        },
        "required": ["invoiceId", "status"],
        "additionalProperties": false
      }
    },
    {
      "type": "mcp",
      "server_label": "billing",
      "server_url": "https://mcp.example.com",
      "allowed_tools": ["searchInvoices", "createCreditNote"],
      "require_approval": "never"
    }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "invoice_result",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "total": { "type": "number" },
          "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] },
          "status": { "type": "string", "enum": ["paid", "open"] }
        },
        "required": ["invoiceId", "total", "currency", "status"],
        "additionalProperties": false
      }
    }
  },
  "service_tier": "fast",
  "safety_identifier": "billing-user-42"
}

Structured Outputs：形狀、流式與同源 Schema

今天的 Structured Outputs 能鎖最終對象：Responses 裏放在 text.format，規則與 Chat Completions 的 response_format 相同，只是外殼字段名不同。官方賣點是類型安全、可檢測的拒絕、少靠「請一定輸出 JSON」這種提示詞。它不賣的是語義：鎖形狀不等於鎖業務含義。半截流式字符串、$ref 被靜默丟掉、超大 Schema、動態枚舉，仍是 2026 年聯調裏最常見的坑。站內 Structured Output 教程 與 AI 生成 JSON 錯誤指南 寫過同一句話：平臺保證括號匹配，不保證發票總額算對。

DevDay 最「像會講」的開發者痛點，是這三件套：① 流式 Structured Output，增量是合法部分對象或 JSON Patch，而不是殘缺字符串；② Tool Schema 與 Output Schema 允許聲明同源，不再手維護兩份幾乎一樣的文件；③ 更完整的 JSON Schema 子集，oneOf / $ref 少一些 silent drop。概率低於「Completions 收口」，但一旦宣佈，你的流式解析器和 Schema 目錄會立刻被點名。

你現在能做的與舞臺無關：把 schemas/output/ 和 schemas/tools/ 分開；每份輸出 Schema 用 Draft 2020-12，strict + additionalProperties: false，required 寫全；用同一份文件喂平臺和本地校驗器。平臺報錯和本地報錯對不上，先 Diff 兩份 Schema，再懷疑模型。最終給用戶或下游系統的答案，不要和 checkpoint、不要和 MCP arguments 共用一個文件——見 AI Agent State。

Tool Calling：可編程調用與多 Agent

2026 年的工具調用已經不是「模型選一個函數、你跑一次、把字符串塞回去」。7 月 9 日 GPT-5.6 把 Programmatic Tool Calling、顯式 Prompt Cache、persisted reasoning，以及 Multi-agent orchestration（Beta）寫進 Responses。意思是：模型可以按程序結構連續調工具，也可以把子 Agent 當一等對象。Beta 的典型命運是 DevDay 摘免責聲明、補 SLA 與限額。

若轉 GA，你的編排器要重新劃邊界：哪些 hop 交給平臺 orchestration，哪些仍留在自建循環。JSON 會多出一類——子 Agent 的中間 artifact。不要把它和最終 Structured Output、MCP arguments 塞進同一個 schema 文件。每條工具日誌現在就該打 correlationId / runId / callId，GA 之後纔好對賬。函數工具的 arguments 仍常是 JSON 字符串：執行前必須 JSON.parse + Schema，與 MCP tools/call 是同一類問題。

Tool Search、Skills、hosted shell 已經只掛在 Responses。DevDay 若把「先搜工具再調用」收成默認，你會後悔把 80 個函數一次性塞進 tools[]。先按領域拆工具包，allowed_tools 式白名單在函數工具側也先用起來。參數 Schema 保持小、枚舉短、禁止 additionalProperties。細節對照 MCP 與 JSON Schema。

MCP：遠程工具、審批與 Connector

GPT-5.5 起 Responses 就能掛遠程 MCP：模型先 mcp_list_tools，再決定調哪一個。控制檯有 OpenAI 維護的 Connector；5 月 19 日的 Secure MCP Tunnel 讓 ChatGPT、Codex、Responses、AgentKit 經客戶側 tunnel-client 打到內網，但目前偏企業開通。默認行爲值得記：平臺會在數據交給遠端之前要你審批，輸出裏出現 mcp_approval_request；信任之後可把 require_approval 設成部分工具或 never。工具太多時用 allowed_tools，否則光是 list 就會燒上下文。

缺口很清楚：普通項目仍難「一鍵掛私有 MCP」，Connector 目錄也不夠覆蓋自建工具。預測文把「Hosted MCP / Connector 自助化、Tunnel 下沉到項目開關」標成高概率。本指南只要求你做一件與概率無關的事：MCP Tool.inputSchema 與模型 tools[].parameters 同源。外殼字段名可以不同，屬性、必填、枚舉必須同一份源文件生成。平臺不會替 Server 做執行期校驗。校驗鏈仍然是 parse → Schema → 業務規則。遠程 MCP 本身是無狀態 JSON-RPC，業務機位不在 Server 上——見 Stateless MCP。

和 A2A 不要混。MCP 是模型調工具；A2A 是 Agent 橫向委託，任務有自己的生命週期和 artifacts。OpenAI 已經在模型層喫 MCP，橫向委託仍是空檔。DevDay 若點一句 AAIF / A2A，也只是互操作，不是讓你把 Agent Card 和 inputSchema 寫成一個對象。對照 A2A vs MCP。私有工具的 arguments 與 MCP params.arguments 對不上時，用 Diff 看的是生成鏈路，不是模型「抽風」。

提前凍結的 6 份 JSON Schema

不要做一個巨大 json 走天下。按消費者拆文件：模型看輸出形狀，運行時看工具入參，MCP Server 看 inputSchema，編排器看會話 item 和子 Agent 產物，賬本看用量。六份就夠覆蓋 DevDay 最可能碰的面。源文件用 Draft 2020-12；生成 OpenAI 外殼（text.format / parameters）時只加包裝，不改屬性。

建議在倉庫裏放一份索引，聲明哪兩份同源、哪一份只做包裝。索引本身也是普通 JSON，方便評審和 Diff：

{
  "schemaVersion": "1.0",
  "pack": "devday-2026-prep",
  "files": [
    {
      "id": "so.invoice_result",
      "path": "schemas/output/invoice_result.json"
    },
    {
      "id": "fn.searchInvoices.parameters",
      "path": "schemas/tools/searchInvoices.json"
    },
    {
      "id": "mcp.searchInvoices.inputSchema",
      "path": "schemas/mcp/searchInvoices.json",
      "sameOriginAs": "fn.searchInvoices.parameters"
    },
    {
      "id": "conv.item",
      "path": "schemas/session/conversation-item.json"
    },
    {
      "id": "agent.artifact",
      "path": "schemas/agent/child-artifact.json"
    },
    {
      "id": "obs.usage",
      "path": "schemas/obs/usage-record.json"
    }
  ]
}

聯調順序固定三步，和模型是否在 DevDay 上「更聰明」無關：parse → Schema → 業務規則。半截 JSON、Schema 報錯、MCP arguments 漂移，各留一條真實失敗樣本。演講當天用來對照新行爲，而不是對着社交媒體摘要猜字段。

瀏覽器裏即可完成：JSON 格式化看 parse；JSON Schema 校驗對 output 與 tools；JSON Diff對比模型 arguments 和 MCP params.arguments。數據不離開本機。

延伸閱讀：DevDay 10 條預測、Assistants → Responses 遷移、Structured Output、MCP 與 JSON Schema、Stateless MCP、A2A vs MCP。

常見問題 FAQ

總結與下一步

DevDay 2026 對開發者真正重要的，不是再記一個模型名字，而是平臺會不會把 Responses、Structured Outputs、Tool Calling、MCP 收成默認棧。四條線指向同一件事：少幾條平行 API，多一份必須遵守的 JSON 契約。

9 月 29 日前，把 Completions 新代碼停掉，把六份 Schema 拆開，把失敗樣本留好。演講當天對照 changelog，而不是對照摘要帖。需要覈對應答形狀時，打開 JSONVue 即可。