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，再切换请求。