Responses API 与 Chat Completions：按契约选择，而不是追新

当 Responses 的 Item 输出、工具循环与状态模型解决真实需求时选择它；若现有消息契约已满足需求且迁移没有实测收益，就继续使用 Chat Completions。

发布 2026-08-15 · 更新 2026-08-15 · KeepRouter Editorial · 9 分钟阅读

Responses API 与 Chat Completions 接入协议决策矩阵 — 按应用实际消费的契约选择；提示词相似不代表响应状态与事件可以互换。

先给结论：Responses 是不同的应用契约，不是 Chat Completions 改了名字。OpenAI 将 Chat Completions 描述为消息输入、返回包含消息的 choices；Responses 则接受灵活输入并返回有类型的 output Items。当 Item 模型、内置工具或状态处理能解决真实需求时选择 Responses；如果现有“消息进、消息出”已经满足需求，且迁移没有可测收益，就继续使用 Chat Completions。

会影响代码的契约差异

关注点	Chat Completions	Responses	迁移问题
主要输入	消息数组	字符串或有类型的 input Items	提示词构造器能否生成新输入形态？
主要输出	包含消息的 choices	有类型的 output Items；SDK 可能提供聚合文本助手	解析器会不会丢失非文本 Item？
工具	Chat 形态中的函数/工具调用字段	函数调用和内置工具都表示为 Items	循环能否处理每一种返回 Item？
对话状态	通常由客户端重发消息维持	可串联 response 或使用 conversation state	谁负责保留、删除与重放？
流式	Chat completion chunk 事件	有类型的响应生命周期与 Item 事件	UI/事件消费者是否区分端点？
多个生成结果	支持 Chat 特有的 choices 模式	Responses 迁移指南记录为单个生成结果	是否有调用方依赖多 choices？
结构化输出	Chat 专用 response format	不同的 text-format 形态	Schema 与拒绝处理是否重新测试？

OpenAI 迁移指南把迁移概括为三项变化：请求发往 Responses 端点、读取有类型的 output 数组、决定轮次间如何携带状态。这是有用的最小集合。生产代码还应测试工具、流式、存储设置、错误映射、用量计量、取消，以及任何会隐藏原始响应的 SDK 便捷属性。

用三个问题做选择

是否需要 Responses 专属工作流？ 内置工具、Item 化 Agent 循环或 response 串联可能足以支持采用，但要核验具体模型与账户能力，不能假设普遍可用。
应用当前读取了什么？ 如果代码只读一段文本，迁移可能很小；若依赖 choices、工具增量、定制流式拼装或已存 Chat 历史，就应逐项盘点。
谁拥有状态与数据策略？ 服务端延续状态能减少载荷拼装，但会改变保留与删除责任。应阅读当前数据控制文档，并在支持时显式设置存储行为。

安全迁移切片

[ ] 冻结一组代表性 Chat 请求及其结构断言。
[ ] 单独创建 Responses 适配器，不要让一个解析器猜测两套事件家族。
[ ] 断言有类型的 output Items，而不只检查 SDK 聚合文本属性。
[ ] 覆盖每个工具定义与工具结果的完整往返。
[ ] 按数据策略分别测试关闭和开启存储。
[ ] 比较两条链路的 usage 记录与请求标识。
[ ] 只灰度一个有边界的工作流，并保留路由级回滚开关。

使用 KeepRouter 时，先用公开 OpenAPI 文档确认是否存在 Responses 路由，再用模型目录确认所选模型的端点兼容性。路由存在与模型有资格是两个独立事实。OpenAI 兼容 API 页面提供整体集成背景，迁移清单则覆盖 SDK、错误与灰度证据。

边界：上游说明不能证明 Gateway 完全等价

OpenAI 文档只对 OpenAI 自身端点具有权威性。OpenAI 兼容 Gateway 可能实现 Chat Completions、Responses、两者，或只实现部分字段与模型。Chat Completions 请求成功不能证明 Responses 也受支持。先检查 Gateway 当前 OpenAPI 与模型级兼容性，再用应用真实需要的字段发起有范围的验证请求。

常见问题

Responses API 是 Chat Completions 的直接替换吗？

不是。端点、输入、输出、工具、流式事件与状态处理都有差异。简单文本可能只需薄适配层，但生产迁移仍需契约测试。

支持 Chat Completions 的 Gateway 也一定支持 Responses 吗？

不一定。应分别在当前 OpenAPI 中核对路由，并在模型目录中核对所选模型的端点资格。

参考的一手资料

本文最近复核 2026-08-15