GPT-6 接入先测什么：Responses API 兼容性与流式排错

新模型接入时，最容易被忽略的一点是：请求能返回文本，只能说明链路通了第一步。企业真正依赖的，往往是流式事件、工具调用、结构化输出、错误码和日志字段能否一起稳定工作。

本文不假设 GPT-6 的具体 API 规格已经发布，而是提供一套接入新模型时可以直接复用的 Responses API 兼容性检查方法。

一、先做最小非流式请求

最小请求只保留模型、输入和必要参数：

{
  "model": "待官方确认的模型 ID",
  "input": "返回一句测试文本"
}

先确认身份、状态码和响应结构，再逐个增加工具、流式和复杂输入。

二、记录接口四元组

每次测试都记录：

Base URL。
API 路径。
模型 ID。
客户端或 SDK 版本。

只记录“请求成功”不够。兼容网关可能把不同路径路由到不同上游。

三、响应结构要保存原文

SDK 往往会把事件转换成自己的对象。

排错时同时保存：

HTTP 状态码。
响应头中的 request ID。
原始 JSON。
SDK 解析结果。

如果字段在原始响应中存在、在 SDK 对象中消失，问题属于客户端兼容层。

四、流式测试要覆盖空增量

流式输出可能出现：

仅有角色事件。
空文本增量。
工具调用增量。
结束事件。
错误事件。

客户端不能假设每个事件都有可显示文本。

建议先把所有事件类型打印到脱敏日志，再决定如何渲染。

五、工具调用要验证完整生命周期

一次工具调用至少包含：

模型提出调用。
客户端解析工具名和参数。
执行器运行工具。
客户端回传工具结果。
模型生成下一步或最终回答。

任何一步缺少关联 ID，都可能导致多轮调用串线。

六、400 错误的排查顺序

缩减到最小请求。
确认 model 和 input 字段。
删除所有可选参数。
关闭流式和工具。
逐个恢复参数。
记录第一个触发错误的字段。

不要在一次 400 后同时修改模型名、路径和请求体，否则无法定位原因。

七、404 和 405 的区别

404 通常表示路径或模型资源不存在。

405 表示服务器找到了路径，但不接受当前 HTTP 方法。

如果网关把路径重写，405 也可能来自错误的上游路由。

排查时要同时看客户端请求方法、网关日志和上游响应。

八、流式中断怎么判断

先关闭流式重试同一输入：

非流式成功、流式失败：优先检查事件解析和连接保持。
两者都失败：优先检查模型、权限、参数和上游状态。

不要把网络断开直接归因于模型质量。

九、结构化输出的兼容性

如果业务依赖 JSON，至少验证：

Schema 是否被接受。
字段是否完整。
枚举值是否有效。
错误时是否返回可解析结果。
流式拼接后是否仍是合法 JSON。

最终验收应由解析器完成，而不是人工阅读。

十、网关接入记录

通过兼容网关时，建议记录：

如果网关不能提供这些字段，应在上线评估中记录可观测性缺口。

十一、兼容性验收矩阵

十二、结论

新模型接入的关键不是“能不能返回一句话”，而是 API 协议、流式事件、工具调用、结构化输出和日志能否一起工作。

在 GPT-6 的官方接口尚未完成核验前，不应按猜测的字段直接改生产客户端。先用最小请求确认模型身份，再逐层恢复能力，并为每个兼容性问题保存原始请求和响应。