Chat Completions API vs Responses API：背景、差异与业界支持情况
发布于 2026-06-13 03:03
Chat Completions API vs Responses API：背景、差异与业界支持情况
一、为什么会出现两种 API
OpenAI 的对外接口经历了三个阶段。
Completions API（2020 年）：最早的文本补全接口。传入一段 prompt，模型续写后面的内容。纯文本输入输出，没有对话概念，不支持多轮。
Chat Completions API（2023 年 3 月）：引入 messages 数组，每条消息有 role（system / user / assistant）和 content 字段。支持多轮对话、function calling、system prompt。这个接口迅速成为事实标准，几乎所有大模型厂商都兼容它的格式。你在 DeepSeek、通义千问、智谱 GLM 上调用的 chat/completions 端点，都是这个协议的实现。
Responses API（2025 年 3 月）：专门为 Agent 场景设计。OpenAI 在发布时说得很明确——Chat Completions 适合简单对话，Responses 适合涉及工具调用、代码执行、状态管理的 Agent 工作流。旧的 Assistants API（2023 年 DevDay 发布，长期 beta）将在 2026 年上半年下线，由 Responses API 统一替代。
根本原因是：Chat Completions 在处理复杂 Agent 工作流时有结构性缺陷。每次调用必须手动传入完整历史对话，状态管理完全在客户端，多步骤工具调用需要开发者自己编排循环。当对话轮次变长，token 消耗线性增长，很快就会撞上上下文窗口上限。Responses API 把这些能力搬到了服务端。
二、两种 API 的核心差异
2.1 状态管理
这是两者最根本的差异。
Chat Completions 是无状态的。要维持多轮对话，客户端必须在每次请求中传入完整的 messages 数组。一个 50 轮的对话，第 51 次调用时要把前 50 轮全部重发一遍。开发者需要自己实现上下文压缩、历史摘要等逻辑。
Responses API 引入了 previous_response_id。服务端保存对话状态，客户端只需要传"上一轮的 response id"就能接续上下文。服务端还实现了 compaction（压缩）机制——当对话接近上下文窗口上限时，自动把早期对话总结为摘要，腾出空间继续对话。
实际影响：一个 100 轮的 Agent 对话，用 Chat Completions 每次调用可能消耗 50K+ tokens（全文重发），用 Responses API 只需要传新的一轮输入加上 response id，token 消耗可控。
2.2 数据结构
Chat Completions 的输入是 messages 数组，每条消息是 {role, content} 结构。输出是 choices[].message，也是一个 message 对象。所有信息都塞进 message 这一个概念里。
Responses API 的输入是 items 数组，item 是一个 union 类型，可以是 message、function_call、function_call_result、reasoning、image 等多种类型。输出也是 items[]，每个 item 有自己的 type 字段。message 只是 item 的一种类型，不再是唯一的一等公民。
这个差异让 Responses API 能更精确地表达"模型做了什么"——是输出了文本、调用了工具、还是做了推理。Chat Completions 把所有这些都混在 message.content 里，解析起来更麻烦。
2.3 工具调用
Chat Completions 的 function calling 流程：
- 请求中传入
tools数组（函数定义） - 响应中检查
choices[0].message.tool_calls字段 - 如果有 tool_calls，本地执行函数
- 把执行结果包装为
{role: "tool", content: "...", tool_call_id: "xxx"}追加到 messages - 再次调用 API，传入更新后的 messages
这个流程完全由开发者手动编排。
Responses API 的工具调用：
- 请求中传入
tools数组 - 响应的 items 中直接包含 function_call 和 function_call_result 类型的 item
- 工具调用的输入输出是结构化的，不需要手动解析 tool_calls 字段
Codex CLI 能自动执行工具调用并继续循环，依赖的就是 Responses API 的这个能力。
2.4 内置工具
Chat Completions 只能调用开发者自定义的函数。
Responses API 可以直接使用 OpenAI 提供的内置工具：
code_interpreter：在沙箱中执行 Python 代码file_search：搜索上传的文件web_search：联网搜索
这些工具不需要开发者自己实现，直接写在请求的 tools 数组里就行。
2.5 多模态
Chat Completions 的多模态（图片、音频）需要在 message.content 数组里混合传入不同类型的内容块。
Responses API 的 input/output 天然支持多模态，不同类型的内容作为独立 item 处理，结构更清晰，解析更简单。
2.6 结构化输出
Chat Completions 用 response_format: {type: "json_schema", json_schema: {...}}。
Responses API 用 text.format: {type: "json_schema", schema: {...}}，参数路径不同，功能等价。
2.7 流式输出
Chat Completions 的流式输出是 delta 格式：每个 chunk 包含 choices[0].delta.content。
Responses API 的流式输出是 events 格式：每个事件有自己的 type，如 response.output_text.delta（文本增量）、response.reasoning_summary_text.delta（推理增量）、response.completed（完成）等。事件格式让客户端能区分"模型在思考"和"模型在输出答案"。
2.8 Zero Data Retention
Responses API 的 compaction 机制支持 ZDR 模式：OpenAI 存储的是加密后的摘要密钥，而不是对话原文。对于有数据合规要求的企业，这是 Chat Completions 无法提供的能力。
三、差异对比汇总
| 维度 | Chat Completions | Responses API |
|---|---|---|
| 发布时间 | 2023 年 3 月 | 2025 年 3 月 |
| 状态管理 | 客户端维护完整历史 | 服务端维护，previous_response_id |
| Token 消耗增长 | 线性（每轮重发全文） | 可控（服务端 compaction） |
| 上下文窗口 | 受限于单次请求大小 | compaction 后可远超原生窗口 |
| 工具调用 | 手动解析 tool_calls | 原生支持，结构化 item |
| 内置工具 | 无 | code_interpreter, file_search, web_search |
| 多模态 | content 数组混合 | 独立 item，类型明确 |
| 流式格式 | delta | events（含 reasoning 事件） |
| ZDR 合规 | 不支持 | 支持 |
| SDK 成熟度 | 极高，所有语言完善 | 较新，部分语言仍在更新 |
| 行业兼容性 | 事实标准，所有模型支持 | 仅 OpenAI 原生 + 少数平台兼容 |
四、业界主流模型支持情况
4.1 Chat Completions API 支持
Chat Completions 是事实标准，几乎所有大模型都原生支持或通过代理兼容。
国际厂商：
| 厂商 | 代表模型 | 兼容方式 | 兼容性 |
|---|---|---|---|
| OpenAI | GPT-4o, GPT-4.1, o3, o4-mini | 原生 /chat/completions |
完全 |
| Anthropic | Claude 3.5, 4, 4.1 | 需 LiteLLM 等代理转换 | 代理后完全兼容 |
| Gemini 2.0, 2.5 | 需 LiteLLM 等代理转换 | 代理后完全兼容 | |
| xAI | Grok 3, 4 | 需代理转换 | 代理后兼容 |
国内厂商：
| 厂商 | 代表模型 | 接口地址 | 兼容性 |
|---|---|---|---|
| DeepSeek | V3, R1 | api.deepseek.com/v1 |
原生兼容，高级参数（logprobs 等）可能不支持 |
| 通义千问（百炼） | Qwen3-Max, Qwen3-Plus, Qwen3-Coder | dashscope.aliyuncs.com/compatible-mode/v1 |
原生兼容 |
| 智谱 | GLM-4, GLM-4.5, GLM-4-Flash | open.bigmodel.cn/api/paas/v4 |
原生兼容 |
| 豆包 | Doubao-pro, Doubao-vision | ark.cn-beijing.volces.com/api/v3 |
原生兼容 |
| 月之暗面 | Kimi, Moonshot | api.moonshot.cn/v1 |
原生兼容，长上下文能力突出 |
| MiniMax | MiniMax-Text-01 | api.minimaxi.chat/v1 |
原生兼容 |
| 百度文心 | ERNIE-4.0, ERNIE-3.5 | qianfan.baidubce.com/v2 |
原生兼容 |
| 腾讯混元 | Hunyuan | 官方 API | 原生兼容 |
聚合平台：
| 平台 | 端点 | 覆盖模型 |
|---|---|---|
| OpenRouter | openrouter.ai/api/v1/chat/completions |
400+ 模型，统一 Chat Completions 端点 |
| LiteLLM | 自部署代理 | 100+ 模型，统一 Chat Completions 端点 |
| Ollama | localhost:11434/v1/chat/completions |
本地模型，兼容 Chat Completions |
结论：Chat Completions 的生态覆盖是无死角级别的。无论你用哪个模型、哪个平台，基本都能通过这个接口调通。
4.2 Responses API 支持
Responses API 是 OpenAI 的新一代接口，其他厂商的跟进进度远不如 Chat Completions。
完整支持的厂商：
| 厂商 | 支持模型 | 接口地址 | 功能覆盖 |
|---|---|---|---|
| OpenAI | GPT-4.1, GPT-5, o3, o4-mini | api.openai.com/v1/responses |
完整：compaction、内置工具、ZDR、reasoning、streaming |
| 阿里云百炼（通义千问） | Qwen3-Max, Qwen3-Plus, Qwen3-Flash, Qwen3-Coder 全系列 | dashscope.aliyuncs.com/compatible-mode/v1/responses |
高：previous_response_id（7 天有效）、reasoning.effort、streaming、内置 web_search / code_interpreter / web_extractor、Session 缓存（Header: x-dashscope-session-cache: enable，最小 1024 tokens，有效期 5 分钟） |
通过代理部分兼容的：
| 平台 | 兼容方式 | 限制 |
|---|---|---|
| LiteLLM | 协议转换，将 Responses 请求映射到 Chat Completions | 丢失服务端 compaction、previous_response_id 状态管理；items 多类型会扁平化为 messages；ZDR 不可用。本质上是让 SDK 能跑，但高级特性全部退化 |
| 老张 API | 声称支持 /v1/responses |
第三方聚合服务，功能覆盖不透明，未验证完整功能 |
不支持 Responses API 的主流平台：
- DeepSeek 官方：只提供
/chat/completions，不提供/v1/responses。通过 LiteLLM 代理后可使用部分能力，但服务端 compaction 不可用 - OpenRouter：仅提供
/chat/completions端点，不提供/responses - 智谱 GLM 官方：不支持
- 豆包官方：不支持
- 月之暗面 Kimi 官方：不支持
- MiniMax 官方：不支持
- 百度文心官方：不支持
- 腾讯混元官方：不支持
4.3 国内大模型 Responses API 支持总结
国内大模型厂商中，阿里云百炼（通义千问）是唯一官方支持 Responses API 的平台。
百炼的兼容不是简单的端点映射，而是实现了 Responses API 的核心特性：
previous_response_id跨请求状态关联（ID 有效期 7 天）reasoning.effort推理强度控制（none / minimal / low / medium / high）- 流式 events 输出
- 内置 web_search、code_interpreter、web_extractor 工具
- Session 缓存降低多轮对话成本
其他国内厂商（DeepSeek、智谱、豆包、Kimi、MiniMax、百度、腾讯）都不提供 Responses API 兼容端点。如果你需要通过 Responses API 的协议格式使用这些模型（比如让 OpenAI SDK 的 client.responses.create() 跑起来），只能用 LiteLLM 做协议转换，但会丢失服务端状态管理能力，compaction 和 previous_response_id 都将不可用。
五、对实际项目的影响
5.1 什么时候必须用 Responses API
以下场景必须使用 Responses API + OpenAI 或阿里云百炼：
- 服务端 compaction：对话轮次多（50 轮以上），需要服务端自动压缩历史对话，不消耗客户端 token 预算
- previous_response_id：不想每次调用都重传完整对话历史，需要服务端维护状态
- 内置工具：需要直接使用 code_interpreter、file_search、web_search，不想自己实现
- ZDR 合规：企业数据合规要求对话不能被服务商存储原文，需要零数据留存模式
- Reasoning 事件：需要在流式输出中区分"模型在思考"和"模型在输出答案"
OpenRouter、LiteLLM 无法满足以上任何一条。
5.2 什么时候 Chat Completions 足够
以下场景用 Chat Completions 完全没问题：
- 简单多轮对话：轮次不多，手动传 messages 数组的成本可控
- 自定义工具调用：自己实现 tool call 解析和执行循环，不需要内置工具
- 国产模型优先：使用 DeepSeek、Kimi、GLM 等，这些模型不支持 Responses API
- 聚合平台接入：通过 OpenRouter/LiteLLM 统一管理多模型，这些平台只暴露 Chat Completions
5.3 对 Codex CLI 的影响
Codex CLI 选择 Responses API 不是偏好，是必须。它的三个核心能力绑定在 Responses API 上：
- Auto-compaction：对话达到
auto_compact_limit后自动调用/responses/compact端点，服务端生成加密摘要 - ZDR 模式：支持 Zero Data Retention，适合处理敏感代码
- 内置代码解释器：通过 code_interpreter 工具在沙箱中执行代码，这是它"能运行代码"的基础之一
用 Chat Completions 无法实现同等级别的能力。
5.4 对 Hermes Agent 的影响
Hermes Agent 不受 Responses API 限制。它的 agent loop 在客户端实现，上下文管理、工具调用循环、状态压缩都由本地代码完成，不依赖服务端特性。
Hermes 可以在 Chat Completions 上构建完整的 agent 工作流。Responses API 对它来说是加分项（如果用 OpenAI 模型，可以享受服务端 compaction），不是必需品。
这是 Hermes 的一个重要优势：你可以在 DeepSeek V3 上跑完整的 agent 工作流，不需要等 DeepSeek 支持 Responses API。
六、迁移建议
如果你现在有基于 Chat Completions 的项目，是否需要迁移到 Responses API？
不需要迁移的情况：
- 项目只用国产模型
- 工具调用逻辑不复杂，手动编排可接受
- 已有的 OpenRouter/LiteLLM 聚合方案运行良好
建议迁移的情况：
- 大量使用 OpenAI 模型，且对话轮次多、token 成本高
- 需要服务端 compaction 来控制长对话成本
- 需要 ZDR 数据合规
- 新项目，没有历史包袱，想直接走 OpenAI 主推的技术路线
如果要用 Responses API + 国产模型（比如通过百炼用通义千问），需要注意：百炼的 Responses API 端点路径是 /compatible-mode/v1/responses，不是标准的 /v1/responses。在 SDK 里配置 base_url 时需要指向正确路径。
七、结尾
Chat Completions 和 Responses API 短期内会共存。OpenAI 已明确表示不会废弃 Chat Completions，新功能会优先在 Responses API 落地。
对其他厂商来说，Responses API 跟进的动力不足——大多数开发者的核心需求是"能用"而不是"用最好的接口"，Chat Completions 已经满足了这个需求。国内厂商中，阿里百炼做了兼容，其他厂商暂时没有跟进的信号。
实际选型时，建议根据模型来源决定：用 OpenAI 则优先考虑 Responses API；用国产模型则安心用 Chat Completions，生态支持更完善。
如果你觉得本文有用，请点赞，收藏，转发
你有什么问题，请留言，我来帮你解答。
← 返回博客列表