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

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

_发布 2026-08-15 · 更新 2026-08-15 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 9 分钟阅读_

![Responses API 与 Chat Completions 接入协议决策矩阵](https://keeprouter.com/editorial/blog/responses-api-vs-chat-completions.png)

_按应用实际消费的契约选择；提示词相似不代表响应状态与事件可以互换。_

**先给结论：**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 便捷属性。

## 用三个问题做选择

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

## 安全迁移切片

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

使用 KeepRouter 时，先用公开 [OpenAPI 文档](/api/openapi.json)确认是否存在 Responses 路由，再用[模型目录](/models)确认所选模型的端点兼容性。路由存在与模型有资格是两个独立事实。[OpenAI 兼容 API 页面](/zh/features/openai-compatible-api)提供整体集成背景，[迁移清单](/zh/blog/openai-compatible-api-migration-checklist)则覆盖 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_

1. [OpenAI migrate to Responses](https://developers.openai.com/api/docs/guides/migrate-to-responses)
2. [OpenAI Responses reference](https://developers.openai.com/api/reference/resources/responses)
3. [OpenAI Chat reference](https://developers.openai.com/api/reference/resources/chat)
4. [OpenAI data controls](https://platform.openai.com/docs/models/default-usage-policies-by-endpoint)
5. [KeepRouter OpenAPI](https://keeprouter.com/api/openapi.json)

## 继续阅读

- [OpenAI 兼容 API](https://keeprouter.com/zh/features/openai-compatible-api.md)
- [openai sdk](https://keeprouter.com/use-cases/openai-sdk.md)
- [OpenAI 兼容 API 迁移清单](https://keeprouter.com/zh/blog/openai-compatible-api-migration-checklist.md)
- [models](https://keeprouter.com/models.md)

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)