国内主流云厂商与模型厂商 OpenAI Responses API 兼容性调研报告

信息检索截止日期：2026 年 8 月 6 日

版本：v2.1

证据说明：本报告基于厂商官方 API 文档、开发指南和官方示例。除非特别说明，能力结论属于公开文档证据，尚未使用各厂商有效密钥执行同一套鉴权测试。

截至 2026 年 8 月 6 日，公开官方资料至少可以确认六个面向国内开发者、具有正式 POST /responses 入口的厂商或云平台：

智谱 BigModel 提供 OpenAI SDK 兼容能力，但截至截止日，官方公开接口仍以 POST /api/paas/v4/chat/completions 和 client.chat.completions.create() 为主，未发现正式的 HTTP POST /responses 文档。因此，智谱在本报告的 Responses 协议口径下评为 L1。这个评级只描述协议兼容深度，不代表 GLM 模型能力较弱；其推理、Function Calling、MCP、联网搜索、多模态和 Realtime 能力应单独评价。

各入口不能仅按“是否存在 /responses”排成同一档。更准确的审计单位是：

厂商 × 产品/端点 × 地域 × 模型 ID × 接口模式

同一个平台内，不同模型可能采用平台级 Responses Runtime、无状态 Responses 子集或 Responses-to-Chat 转换层。腾讯 TokenHub 尤其需要按模型和接口模式拆分，不能对整个平台给出一个统一等级。

在尚未完成统一鉴权测试的前提下，本报告不认定任何国内入口达到 L5。公开文档层面，阿里云百炼、火山方舟和百度千帆最接近平台级 Responses Runtime；DeepSeek 是边界清晰的无状态子集；MiniMax 已具备正式 Responses 入口；腾讯 TokenHub 需要按模型分组；智谱原厂 API 仍属于功能丰富的 Chat Completions 兼容实现。

“B 级文档已确认”表示厂商公开承诺了该能力。只有 A 级测试才能进一步证明参数确实生效、事件顺序稳定、状态可可靠恢复，以及失败行为与 OpenAI 一致。

等级只描述 Responses 协议和运行时兼容深度，不评价模型智能、价格、吞吐、上下文长度或企业服务能力。

Chat Completions 兼容不等于 Responses 兼容。两者的核心差异不只是请求路径，而是对象和运行时语义：

因此，以下表述不能单独证明 Responses 兼容：

结论：L4（B 级文档证据）。

百炼为指定 Qwen 模型提供 OpenAI Responses 兼容入口，并使用 client.responses.create() 展示调用。官方文档覆盖 typed output、语义化 SSE、Function Calling、reasoning items、store、previous_response_id、Response 查询，以及 Web Search、Web Extractor、Code Interpreter、File Search、MCP 和图片搜索等平台工具。

主要边界包括：

北京地域当前 Responses 白名单覆盖 Qwen3.8/3.7/3.6/3.5 的若干 Max、Plus、Flash 与开源规格，以及 Qwen Plus/Flash、Qwen3 Coder Plus/Flash、qwen3.5-ocr、qwen-plus-character、qwen-flash-character 等。严格 Structured Outputs、Computer Use，以及不同地域和模型的一致性仍需鉴权测试。

官方资料：通过 OpenAI Responses API 调用通义千问

结论：L4（B 级文档证据）。

方舟提供 https://ark.cn-beijing.volces.com/api/v3/responses。官方资料展示基础 Responses 请求、typed output、语义化流式输出、Function Calling 两轮回传、store、previous_response_id、响应查询/删除，以及 Web Search、Knowledge Search、图片处理和 MCP 等平台工具。

其能力已经超出简单 Chat 字段转换，但仍需保留三项边界：

官方资料：火山方舟 Responses API

结论：L4（B 级文档证据）。

千帆提供 https://qianfan.baidubce.com/v2/responses。当前官方指南列出的 Responses 模型白名单包括：

千帆文档覆盖 typed output、默认存储、store: false、previous_response_id、Response 查询/上下文/删除、Function Calling、json_object、json_schema 严格示例、MCP 和 knowledge_search。

千帆还发布了独立的 Responses 流式文档，列出：

因此，Streaming 可以在文档证据下确认。尚未充分证明的部分包括通用 Web Search、Code Interpreter、Computer Use、background，以及文件、音频和视觉输入的统一白名单。文档示例与顶部模型白名单发生冲突时，应以当前白名单、实际响应和厂商确认为准。

官方资料：千帆 Responses API 指南、Responses 流式事件

结论：L3（B 级文档证据）。

DeepSeek 官方提供 POST https://api.deepseek.com/responses，当前明确支持 deepseek-v4-flash。官方文档展示 typed items、output_text、reasoning、Function Calling、Web Search、语义化 SSE、JSON Schema 和自定义 apply_patch 工具。

DeepSeek 将该接口设计为无状态 Responses 子集：

官方文档支持 json_object 和 json_schema，但尚不足以证明 OpenAI strict 字段及失败语义逐项等价。该入口适合客户端自行管理历史，且主要依赖文本推理、Function Calling、Web Search 或代码补丁工具的应用。

官方资料：Responses API 使用指南、Create a response

结论：需要按模型与接口模式分组评级。

TokenHub 提供 https://tokenhub.tencentmaas.com/v1/responses。官方协议矩阵将模型区分为直接支持与“兼容支持”两类。

当前矩阵中，Responses 列为直接支持的系列包括 Hy3/Hy3 Preview、DeepSeek V4 Flash 若干版本、MiniMax M3/M2.7/M2.5，以及 Qwen3.5 Plus/Flash。带“兼容支持”标记的系列包括 GLM 5.1/5.2、Kimi K3/K2.6/K2.7 Code，以及 DeepSeek V4 Pro。

对于原生只支持 Chat Completions 的模型，TokenHub 会在服务端把 Responses 请求转换为 Chat Completions，再把上游响应重建为 Responses 格式。主要限制包括：

非“兼容支持”模型不应自动继承转换层结论，但官方矩阵本身也不足以证明其状态、工具和错误语义达到 L4。较稳妥的做法是暂列 L3 候选，并对具体模型逐一测试。

混元 Hy3 Preview 已有官方资料展示 Responses Web Search，包括 web_search_call、搜索结果 annotations 和相关流式事件，说明平台至少具备部分工具运行时能力。

官方资料：TokenHub 模型与协议支持矩阵、Responses 兼容模式、混元 Hy3 Responses Web Search

结论：至少 L2，L3 候选（B 级文档证据）。

MiniMax 提供正式 POST https://api.minimaxi.com/v1/responses。官方 API Reference 展示 output、output_text、reasoning items、Function Calling、流式/非流式调用，以及图片、视频输入。

当前仍不宜直接评为 L4：

如果鉴权测试能够证明 typed item、函数参数增量、事件顺序和不支持参数行为稳定，可将其确认为 L3；在状态管理和对象生命周期获得证据前，不宜升为 L4。

官方资料：MiniMax Create response

结论：L1（B 级文档证据）。

截至 2026 年 8 月 6 日，智谱开放平台官方 OpenAI 兼容指南使用：

官方模型 API 目录同样将核心文本接口列为 POST /paas/v4/chat/completions。在可公开复核的官方文档和接口目录中，没有发现 POST /responses、client.responses.create()、previous_response_id 或 Response 对象查询/删除接口。因此，智谱原厂 HTTP API 不能列入正式 Responses 入口。

L1 不代表平台功能简单。智谱的 Chat Completions 接口已经提供较丰富的模型与工具能力：

这些能力说明智谱适合构建复杂应用，但它们当前主要位于 Chat Completions、工具 API、Agent API 或 Realtime API 中，并不自动构成 HTTP Responses API 兼容。

第一，OpenAI SDK 兼容不等于 Responses 兼容。 智谱官方页面所说的 OpenAI API 兼容，实际示例全部使用 Chat Completions 方法。应用如果原本调用 client.responses.create()，不能只替换 API Key 和 Base URL。

第二，Realtime 中的 response.* 事件不等于 HTTP /responses。 GLM-Realtime 使用 WebSocket 会话，包含 response.create、response.output_item.added、response.text.delta、response.done 等事件。这是 Realtime 协议的一部分，不能作为 POST /responses 存在的证据。

此外，腾讯 TokenHub 可以为部分 GLM 模型提供 /responses 兼容外观，但官方已将相应 GLM 型号标为“兼容支持”。该能力属于腾讯云转换层，不能反推智谱原厂 API 已支持 Responses。

如果应用需要直接接入智谱原厂 API，至少需要一层适配：

若现有系统本身就是 Chat Completions 架构，智谱的迁移成本较低；若系统深度依赖 Responses 的 typed items、服务端状态和平台工具对象，迁移成本为中高。

官方资料：OpenAI API 兼容指南、对话补全 API、GLM-Realtime

符号：✅ 官方文档明确支持；🟡 部分支持、按模型或需实测；❌ 明确不支持；❓ 公开证据不足；🔁 转换层重建；— 不适用。

表中的 JSON Schema 支持首先属于文档能力。要证明 strict 行为，还应测试额外字段、必填字段缺失、枚举越界、嵌套对象和流式 JSON 拼接等失败条件。

除智谱外，Kimi 独立开放平台、华为云 MaaS、硅基流动、蚂蚁百灵等公开资料仍主要指向 /chat/completions 或 Chat SDK。在本报告的证据范围内，这些平台不列入已确认的正式 /responses 入口。

该结论表示“截至截止日未取得足够官方证据”，不代表厂商不存在私有、灰度或后续发布的接口。同一模型经阿里、百度、腾讯等云平台托管时，也可能通过云平台 Runtime 或转换层获得 /responses，但不能反推模型原厂 API 具备相同能力。

第三方转换或透传网关也应与厂商原厂 API 分开统计。网关可以降低客户端改造成本，但兼容性由网关、上游模型和状态实现共同决定；在没有原始请求、响应和错误行为证据时，不应给出完整兼容结论。

阿里云百炼、火山方舟和百度千帆具有较完整的平台级特征：除了请求格式，还提供服务端状态、响应对象生命周期或平台工具。它们更接近 OpenAI Responses 的运行时设计，但仍受模型白名单、地域、状态有效期和工具差异限制。

DeepSeek 提供 typed items、语义化流式事件、函数调用和部分内置工具，但明确不保留响应状态。这种设计可以兼容客户端结构，却不能替代依赖 previous_response_id 的服务端会话架构。

腾讯 TokenHub 的兼容支持组会在服务端转换请求和流式事件。它适合减少 SDK 层改造，但状态和工具语义可能无法完整保留。客户端必须明确处理被忽略或不生效的字段。

智谱原厂 API 属于这一类。其模型和工具能力可以很强，但应用需要自行管理消息历史，并适配 Chat messages、choices 和 [DONE] 流。协议等级不能与模型能力混为一谈。

优先在阿里云百炼、火山方舟、百度千帆中进行 PoC：

如果应用已经保存完整历史，不依赖 previous_response_id，DeepSeek 官方的 L3 子集可能足够。MiniMax 可以作为多模态 Responses 候选，但需要先验证流式事件和函数调用闭环。

腾讯 TokenHub 的转换兼容组适合快速获得统一 /responses 外观，但应用架构仍应按无状态 Chat 后端设计。直接支持组必须按具体模型重新测试，不能复用转换组结论。

建议在业务代码内建立最小能力抽象：

要把文档审计升级为实际兼容性结论，至少需要对每个“平台 × 模型 × 地域 × 模式”执行以下测试：

测试通过标准不应是“请求返回 200”，而应是：预期支持的能力能够重复生效，预期不支持的能力以可识别方式失败，关键字段不会被无声丢弃。

截至 2026 年 8 月 6 日，国内可公开复核的正式 OpenAI Responses 入口至少有六个。市场已经从单一 Chat Completions 兼容发展为平台级 Runtime、无状态 Responses 子集、协议转换层和 Chat-only 原厂接口并存，但尚无公开证据证明任何国内入口在完整状态、工具、多模态和错误语义上达到经统一实测验证的 L5。

智谱 BigModel 的专项结论是：原厂 API 的模型和工具能力较完整，OpenAI SDK 兼容也较成熟，但当前官方 HTTP 接口仍是 Chat Completions，不能作为正式 /responses 入口。GLM 模型通过腾讯 TokenHub 或百度千帆获得 Responses 外观时，应将能力归属于相应云平台的 Runtime 或转换层，并按具体模型重新验证。

实际选型应始终按厂商、端点、地域、模型和接口模式进行。平台支持 /responses 不代表全模型支持；返回 response 对象不代表状态和工具真实生效；出现 response.* 事件也不一定代表 HTTP Responses API。只有统一的原始请求、响应、SSE 和错误行为测试，才能把文档兼容升级为生产可用结论。