GPT-6 Astra 切断 Chat Completions 工具调用：接入方在导流前必须完成的迁移

GPT-6 Astra 于 2026 年 9 月 3 日发布，OpenAI 的宣传文案很好读。对接入方来说，更难找到的是：这个模型在 API 层面加了一组硬性约束，会根据工具调用在你的技术栈中所处的位置，静默或显式地破坏现有集成。

有三件事会以接入层可能不会自动捕获的方式出问题。还有一件事——新的失准监控——即使集成本身不报错，也会改变延迟契约。另外两个新错误码（早一天在 9 月 2 日上线）意味着不管你有没有用 Astra，重试逻辑都需要更新。

工具调用不再走 Chat Completions

影响最大的变化：如果你对 gpt-6-astra 通过 v1/chat/completions 传 tools，调用会失败。OpenAI 的 changelog 说得直接——"工具调用需要 Responses API"。这不是能力缺失，是硬性的架构决定。

实际影响取决于你的链路是怎么搭的。如果你用 LiteLLM、LangChain 或任何通过 Chat Completions 路径代理工具调用的网关（大多数都是），这些集成在 Astra 上会失败。如果你用 OpenAI 自己的客户端，在 chat.completions.create 调用里设了 model="gpt-6-astra" 并带 tools= 参数，调用就会报错。

Responses API 已经上线并有完整文档。模型字段变成 model="gpt-6-astra"，tools 数组换成 Responses API 格式，messages 变成 input。但你链路里所有生成请求体的组件，都需要原生支持 Responses API，或者在 Astra 前面放一个适配层。

对于走 Chat Completions 透传模式（"直接转发给 OpenAI"）的接入方，这要求按模型做差异路由：Astra 必须和 GPT-5.x、GPT-4.x 区别对待。如果你的路由层会动态选择 Astra 或把它作为兜底，要么先做好 Responses API 适配器，要么在有适配器之前把 Astra 从带工具调用的路由里排掉。

参数锁定：temperature、top_p 和 logprobs 消失了

GPT-6 Astra 不接受自定义 temperature 或 top_p，也不提供 log probabilities（logprobs）。

对很多接入方来说，这是静默行为变更而不是报错：如果你通过一条不校验参数的路径把 temperature=0.2 发给 Astra，它可能只是被忽略。如果你的应用逻辑依赖 temperature 来控制确定性或多样性——复现可重复的运行，或者混用创意与事实性输出——这个控制手段没了。

实际操作上，如果你的路由层从默认配置里注入 temperature 或 top_p，把 gpt-6-astra 加到这些注入的例外列表。如果你把 temperature 作为用户可配置字段暴露出去，且这个字段会透传到模型，需要做每个模型的覆写机制，或者在 UI 层加防护。模型不会大声报错，测试时很容易漏掉。

logprobs 的消失对做置信度估计、输出校验或从 token 分布做有标定采样的团队来说是更硬的断点。Responses API 里没有能返回 Astra 原始 log probabilities 的等价机制——这个能力对这个模型不存在。

失准监控改变了延迟契约

Astra 是 OpenAI 首个强制运行异步失准监控的模型。该系统在有实质影响的上下文中（涉及敏感数据访问、传输或破坏性操作）异步审查模型的推理和行为，发现问题时可以中止对话。

异步架构意味着大多数调用不受影响——监控并行运行，正常情况下不会加到响应延迟上。但停止行为很重要：如果监控触发，它可能打断一个进行中的 Responses API 对话，不只是打标记。对于使用持久化推理、WebSocket 或 OpenAI compaction 的请求，系统可以阻断后续的对话轮次。

Chat Completions 请求明确不在监控覆盖范围内。这对接入方评估是否将敏感或高风险工作负载路由到 Responses API 有参考价值：监控在那里运行，Chat Completions 不走监控。对某些组织来说这是合规层面的加分项（自动化安全监督）。对另一些来说，这改变了 SLA 模型——被中止的对话就是一次失败的事务。

对于运行长多轮 Astra 会话的网关接入方，处理 misalignment_monitoring webhook 告警现在是运营面的一部分。OpenAI 文档描述了系统无法自动中止时的 webhook 推送方式——这是你的告警系统需要覆盖的新一类带外事件。

异步工具调用：路由层得到了什么

新的异步工具调用模式（在函数或自定义工具定义上设 async: true）让 Astra 在你的应用执行工具时继续推理和处理，工具完成后通过原始 call_id 返回结果，模型不等待。

这改变了路由代理需要理解的请求-响应循环。普通工具调用是同步阻塞：模型暂停，你的应用跑工具，模型继续。异步工具调用意味着模型在工具派发和结果返回之间继续产生输出——也就是说，当你的数据库查询或外部 API 调用还在飞的时候，你会收到 Astra 流出的内容。

对于建立带有慢速工具依赖（搜索索引、外部 API、数据库查询）的 Agentic 工作流的接入方，这是实实在在的延迟收益：模型可以在等待慢工具的同时推理请求中独立的部分，而不是阻塞等待。对于缓冲或转换流式输出的网关接入方，需要理解工具调用输出和模型持续输出现在可能在流里交织出现。

中途引导（通过 WebSocket，走 Responses API）让你在 Astra 工作时注入修正或更新的指令。结合按请求改变推理力度（configuration_update 输入项），这些为接入方提供了对长 Astra 任务更多的运行时控制——但这一切都在 Responses API 里，进一步强化了 Chat Completions 不是 Astra 驱动工作流的路径这一事实。

影响所有 OpenAI 模型的新错误码，不只是 Astra

9 月 2 日，Astra 发布前一天，OpenAI 把 429 过载错误拆成了两类。这适用于所有模型：

• 429 带 slow_down 码：你的流量增长太快，需要放缓并更缓慢地爬坡。
• 503 带 server_is_overloaded 码：模型临时过载，等待后重试。

两者都可能包含 Retry-After 头。有这个头时照执行；没有时用指数退避。以前这两种情况都作为无差别的 429 返回——你的重试逻辑可能已经一视同仁地处理它们。现在你可以区分"放慢流量增长"和"等待再试"，并采取不同行动：对 slow_down 在入口侧做激进的限速，对 server_is_overloaded 做普通的指数退避。

对于管理多租户或突发流量模式（负载尖峰、批量运行）的接入方，slow_down 信号在运营上很有用。它告诉你限流在流量形态上，而不是模型容量上——也就是说，把同样的负载分散到更长的时间窗口上可能就能解决，而不是等待服务器容量恢复。

Responses API 迁移在实践中长什么样

一个之前用 Chat Completions 带工具的请求：

# 之前 — Chat Completions（带 tools 时对 gpt-6-astra 无效）
response = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[{"role": "user", "content": "搜索 X 的最新新闻"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "搜索网络",
            "parameters": {...}
        }
    }],
    temperature=0.2  # 也被丢弃——被忽略或报错
)

# 之后 — Responses API（gpt-6-astra 工具调用的必选路径）
response = client.responses.create(
    model="gpt-6-astra",
    input="搜索 X 的最新新闻",
    tools=[{
        "type": "function",
        "name": "web_search",
        "description": "搜索网络",
        "parameters": {...}
    }]
    # 无 temperature——该参数不被接受
)

结构上的差异：messages 变成 input（或输入项列表），chat.completions.create 变成 responses.create，工具定义迁移到 Responses API 格式。工具调用返回的 call_id 是你提交工具结果时要回传的。

多轮对话时，Responses API 用 store: true 和前一个响应 ID，而不是消息历史。这是有实质意义的架构差异——会话状态在服务器端，而不是客户端管理。

OpenAI 的 Codex 可以通过 OpenAI docs skill 自动应用迁移：$openai-docs migrate this project to GPT-6 Astra。对于在第三方网关或 LiteLLM 上的团队，在路由带工具的 Astra 流量之前，先确认你的服务商的 Responses API 适配器是否生产就绪。

需要了解的推理力度层级

Astra 支持 low、medium、high、xhigh 和 max 五档推理力度。none 明确不支持。如果你的路由层传 reasoning_effort: "none" 来跳过推理以降低延迟（一些团队在简单子任务上这样做），对 Astra 会报错。把 none 力度的请求路由到 GPT-5.x 模型，或者调整默认值。

对于需要在对话中提升推理力度（处理更难的子任务）再降低（后续跟进）的请求，configuration_update 输入项可以处理这种切换，同时不会让已缓存的提示词前缀失效——对长 Astra 会话来说是有意义的成本控制手段。