AI 開發

OpenAI DevDay 2026 API 更新後，開發者如何遷移現有 JSON Tool Calling 工作流？

JSONSort 2026-10-08 發布 2026-10-08 更新閱讀約 16 分鐘

先改寫回，再改模型名。目標若是 gpt-6-astra 或 gpt-6.1-sol，工具呼叫要離開 Chat Completions，改走 Responses API。只做分類或路由的那一跳，可以改到 10 月 6 日公測的 Decisions API。查單仍是 lookup_order。模型只填 JSON，宿主執行。

閱讀前速覽

物件	官方事實	遷移時改什麼
入口	Astra、GPT-6.1 Sol 的工具呼叫走 Responses。Sol、Luna 僅在 reasoning_effort 為 none 時，Chat Completions 能帶函式	改 POST /v1/responses，或明確留下 none
工具物件	Responses 的 name 與 type 同級。省略 strict 會嘗試嚴格模式，不相容則回退並標 strict: false	顯式寫 strict。宿主仍要校驗
回寫	function_call 與 function_call_output 用 call_id。async: true 不把執行交給模型	role:tool 改成 function_call_output
路由	2026-10-06 Decisions 公測，僅 gpt-6-luna。choice 不執行工具	只選列舉的一跳可以搬走

事實截至 2026-10-08 的官方文件：Using GPT-6、Migrate to the Responses API、Decisions、Async tool calling。訂單 A-1042 是虛構的。Decisions 回覆裡的機率是示意數字。

先換寫回形狀，再換模型名

DevDay 之後要遷的是欄位，不是再講一遍 Agent。官方遷移說明集中在四條。第一，目標模型若是 gpt-6-astra 或 gpt-6.1-sol，工具呼叫改走 Responses。這兩款仍可在 Chat Completions 裡發不帶工具的請求。gpt-6-sol 與 gpt-6-luna 只有 reasoning_effort 為 none 時，才能在 Chat Completions 裡做函式呼叫。要帶著推理調工具，同樣走 Responses。第二，工具物件從外層 function 裡的 name，改成與 type 同級。第三，回寫從 tool_calls[].id 改成 call_id。第四，只做分類或路由的那一跳，可以改到 Decisions；它不執行工具。

Astra / GPT-6.1 Sol：工具呼叫離開 /v1/chat/completions。Responses 裡這個欄位叫 reasoning.effort。
定義攤平，strict 寫明。Chat Completions 預設非嚴格。Responses 省略 strict 會嘗試嚴格模式。
路由與查單拆開。choice 只返回列舉。查單仍是 lookup_order。

9 月 29 日發了什麼，見 DevDay 2026 釋出了什麼。Responses 和 Agents 的入口差別，見 Agents API 與 Responses API 的差別。本篇不重寫那兩篇，只寫現有 JSON Tool Calling 怎麼改欄位。

先認出現在讀的是哪一種呼叫

Chat Completions 的模型回覆裡，一次呼叫長這樣。id 在外層，name 在 function 裡。arguments 是字串。虛構訂單，不要貼真實金鑰：

{
  "id": "call_3c91",
  "type": "function",
  "function": {
    "name": "lookup_order",
    "arguments": "{\"order_id\":\"A-1042\"}"
  }
}

Responses 的工具定義把 name 抬到與 type 同級。strict 不要省。省略時，Responses 會嘗試嚴格模式；Schema 不相容就回退，並在返回的工具上給出 strict: false。要保持非嚴格，顯式寫 false。宿主仍要在執行前校驗 arguments：

{
  "type": "function",
  "name": "lookup_order",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "pattern": "^[A-Z]-\\d{4}$" }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

回寫只認 call_id

模型給出的呼叫項是 function_call，不是 tool_calls 陣列。解析器改讀這四項：

{
  "type": "function_call",
  "call_id": "call_3c91",
  "name": "lookup_order",
  "arguments": "{\"order_id\":\"A-1042\"}"
}

宿主解析 arguments，過 Schema，執行 lookup_order，再按同一 call_id 寫回。失敗也是字串裡的物件。手寫歷史時，把上一輪的 reasoning 項和 function_call 一起送回，不要只送結果。更省事的是 previous_response_id：

{
  "type": "function_call_output",
  "call_id": "call_3c91",
  "output": "{\"order_id\":\"A-1042\",\"status\":\"paid\"}"
}

慢工具可以在定義上加 async: true。官方寫明：模型可以繼續推理，或回答不依賴該結果的部分；對應呼叫項會帶 async: true；你稍後用原來的 call_id 提交 function_call_output。宿主仍執行。內建工具和 programmatic tool calling 不能用 async。Multi-agent 裡不要把 async 和並行工具呼叫疊在一起。文件寫的是 GPT-6 Astra 及之後的模型。

五條循環，不要合成一次升級

按現在的寫回形狀分開遷。物件名不同，就不要共用一個解析器：

現在的循環	遷到哪裡
Chat Completions + tools，目標是 Astra 或 GPT-6.1 Sol	改 `POST /v1/responses`。`tool_calls[].id` 改成 `call_id`。name 從 `function` 裡抬出來。
Chat Completions + tools，留在 gpt-6-sol 或 gpt-6-luna	只有 `reasoning_effort` 為 `none` 才能留下。要推理再調工具，改 Responses。
已經是 Responses 的 function_call	循環留下。換模型 ID。Astra 與 GPT-6.1 Sol 不支援 `none`，用 `low`。推理力度不是 none 時，去掉 `temperature`、`top_p`、`top_logprobs`。
工具只返回 lookup / hold / escalate	這一跳改 `POST /v1/decisions`，模型只 `gpt-6-luna`。查單仍是 function_call。
Agents API 的 session	要託管 harness 就留在 Agents。回寫仍是 `turn_id`，不是 `function_call_output`。

路由那一跳用 Decisions 的 choice。請求是 10 月 6 日公測文件的形狀，訂單是虛構的。不要把 9 月 30 日那篇裡自擬的答案合約原樣 POST 到 /v1/decisions：

{
  "model": "gpt-6-luna",
  "input": "Order A-1042 is paid. What should the host do next?",
  "questions": [{
    "type": "choice",
    "name": "next_step",
    "instructions": "Pick the next host action. Do not invent a tool name.",
    "choices": [
      { "value": "lookup", "description": "Read the order. No refund." },
      { "value": "hold", "description": "Stop and wait." },
      { "value": "escalate", "description": "Hand the case to a person." }
    ]
  }]
}

示意回覆的欄位名跟官方 choice 示例一致，機率是虛構的。宿主看到 choice 為 lookup，才發 lookup_order。hold 停止。escalate 交給人。type 為 refusal 時不呼叫工具。閾值由你定。影象必須是內聯 base64 data URL，不能用 https 圖片地址或 file_id：

{
  "answers": [{
    "type": "choice",
    "name": "next_step",
    "choice": "lookup",
    "probabilities": [
      { "value": "lookup", "probability": 0.91 },
      { "value": "hold", "probability": 0.05 },
      { "value": "escalate", "probability": 0.04 }
    ],
    "confidence": 0.88
  }]
}

Ultrafast 是 gpt-6-astra 的 service_tier，值為 ultrafast。它只支援美國資料駐留和全球處理，不支援歐盟及其他區域端點，也不改工具 JSON。GPT-6.1 Sol 的 Ultrafast 在 9 月 29 日的官方回顧裡仍是即將提供，本篇不把它寫成已經。Agents API 在 9 月 29 日加上託管瀏覽器的 Computer Use，站點批准和登入仍由你的應用處理。那不構成把 Responses 的 function_call_output 換成別的形狀的理由。錯位監控可能告警或停下對話；停下時不要把同一個工具呼叫盲目重放。

六步遷完，再切換請求

不要從「先開 Ultrafast」開始。按寫回形狀寫：

標出當前寫回。是 role: tool 加 tool_call_id，是 function_call_output，還是 Agents 的 turn_id。三種不要共用一個解析器。
選定入口。Astra 與 GPT-6.1 Sol 的工具呼叫改 POST /v1/responses。Sol 與 Luna 只有 reasoning_effort 為 none 才能留在 Chat Completions。
攤平工具定義，strict 寫明。Schema 用了嚴格模式不接受的寫法，就設 strict: false，宿主照樣校驗。查單隻收 order_id。
對齊 call_id，去掉取樣引數。arguments 仍是字串。Astra 與 GPT-6.1 Sol 用 low 代替 none。推理力度不是 none 時，去掉 temperature、top_p、top_logprobs。Chat Completions 再去掉 logprobs。Responses 的 include 裡去掉 message.output_text.logprobs。從 GPT-5.5 或更早遷來時，把 prompt_cache_retention 換成 prompt_cache_options.ttl 的 30m。中途改推理力度用 configuration_update，請求級 reasoning.effort 保持不動。
只選列舉的那一跳改 Decisions。模型用 gpt-6-luna。宿主把 lookup 對映到 lookup_order。慢工具再加 async: true，回寫仍用原來的 call_id。
Diff 兩份 JSON，再切換請求。Schema 校驗 arguments 和 answers[].choice。對不上就不要換模型 ID。

Schema 怎麼當門，見 Agents API + JSON Schema。為什麼這道門不能只寫在提示裡，見 AI 為什麼需要 JSON Schema。Agents 的回寫形狀，見 Agents API 的工具 JSON。

切換請求前攤開三份 JSON

一次翻車，多半是 id 沒對上、name 還套在 function 裡、或把 choice 當成了已經查完的訂單。

把舊的 tool call 和新的 function_call 格式化，再用 Schema 校驗看 arguments 和 answers[0].choice 是否落在門裡。
用 JSONPath 提取抽出 $.call_id、$.name、$.answers[0].choice。
用 JSON Diff 對比遷移前後的載荷。先補 call_id，再改提示。
核對 call_3c91 在呼叫和 function_call_output 上是不是同一個 id。
訂單、令牌、倉庫路徑不要貼進公共格式化站。JSONSort 在瀏覽器本地跑。

三份物件都能按 Schema 重建，才算遷完。Ultrafast 不代替這一步。

常見誤區

把 Decisions 當成新的 Tool Calling。它返回 choice、probability 或 score。要模型填工具引數，仍用 Responses 的函式呼叫。要一份自定 Schema 的物件，用 Responses 的 Structured Outputs。
工具定義仍套一層 function。Responses 讀不到舊的 function.name。name 與 type 同級。
省略 strict，以為還是非嚴格。Responses 會嘗試嚴格模式，不相容就回退並標 strict: false。要哪種行為，就寫明。宿主校驗照舊。
在 Astra 或 GPT-6.1 Sol 上留下 none 或 temperature。這兩款不支援 none。GPT-6.1 Sol 也不支援 minimal。用 low。推理力度不是 none 時，取樣引數要拿掉。
為了 Computer Use 把 Responses 循環整段搬進 Agents API。9 月 29 日加的是託管瀏覽器，批准仍在你的應用。Agents 的回寫是 turn_id。
把 async: true 理解成模型自己執行。宿主仍跑工具，並負責未完成的呼叫。稍後用原來的 call_id 寫回。

FAQ

Chat Completions 必須關嗎？

帶工具、且模型是 gpt-6-astra 或 gpt-6.1-sol 時，要改走 Responses。這兩款的 Chat Completions 仍可發不帶工具的請求。gpt-6-sol 與 gpt-6-luna 只有 reasoning_effort 為 none 時，才能在 Chat Completions 裡做函式呼叫。要推理再調工具，走 Responses。

Decisions 能發出 function_call 嗎？

不能。它返回帶型別的答案：predicate 的 probability、choice、或 score。宿主把 choice 對映到已有函式。公測端點是 POST /v1/decisions，目前只有 gpt-6-luna。官方稱它比 Responses 大約快 10 倍，那是分類速度，不是查單。

strict 不寫會怎樣？

Chat Completions 預設非嚴格。Responses 省略 strict 會嘗試嚴格模式；Schema 不相容就回退，返回的工具上是 strict: false。要保持非嚴格，顯式寫 false。無論模型側是否嚴格，宿主都要再校驗 arguments。

已有的 Agents session 要不要改回寫？

不要。Agents API 仍是公測。回寫保持 turn_id。Computer Use 是託管瀏覽器上的另一張許可權，站點批准和登入由你的應用處理。要自己控每一步，繼續用 Responses 的 function_call_output。

Ultrafast 會改工具 JSON 嗎？

不會。它是 gpt-6-astra 上的 service_tier: ultrafast，只支援美國資料駐留和全球處理。工具定義、call_id 和 Schema 都不變。GPT-6.1 Sol 的 Ultrafast 不要寫成已經可用。

結論

DevDay 2026 之後的 JSON Tool Calling 遷移，是換寫回形狀。Astra 與 GPT-6.1 Sol 的工具呼叫走 Responses。name 與 type 同級。結果用 call_id 送回。只選列舉的那一跳可以改 Decisions。查單仍由宿主執行。

先寫清 A-1042 是進 lookup_order 的 arguments，還是進 Decisions 的 input。能指到 call_3c91 和 answers[0].choice，再切換請求。