展开本页目录
开始前准备什么
- 列出业务必须支持的聊天、工具、状态和流式能力
- 使用准确模型 ID 与同一份测试输入
- 区分官方功能文档和网关实际开放范围
- 明确任务
- 比较接口形态
- 跑同一测试
- 保留回退
下载双接口与多轮对照脚本
使用同一输入确认接口及输出处理；三次请求不自动重试。
最先影响代码的差异
| 维度 | Chat Completions | Responses |
|---|---|---|
| 请求主体 | messages | input 与 instructions |
| 输出主体 | choices 与 assistant message | 有类型的 output 项与 output_text |
| 多轮 | 应用维护 messages | 手动项续传；特定服务支持状态续接 |
| 工具结果 | role=tool 与 tool_call_id | function_call_output 与 call_id |
| 结构化输出 | response_format | text.format |
| 流式 | delta chunk、结束标记 | 有类型的事件和响应终态 |
- 维度
- 请求主体
- Chat Completions
- messages
- Responses
- input 与 instructions
- 维度
- 输出主体
- Chat Completions
- choices 与 assistant message
- Responses
- 有类型的 output 项与 output_text
- 维度
- 多轮
- Chat Completions
- 应用维护 messages
- Responses
- 手动项续传；特定服务支持状态续接
- 维度
- 工具结果
- Chat Completions
- role=tool 与 tool_call_id
- Responses
- function_call_output 与 call_id
- 维度
- 结构化输出
- Chat Completions
- response_format
- Responses
- text.format
- 维度
- 流式
- Chat Completions
- delta chunk、结束标记
- Responses
- 有类型的事件和响应终态
本站绘制的内容说明图：比较此页两种请求与响应形态；两者能否用于某型号需要核对当前网关，不以品牌推断端点支持。
这些情况，先保留 Chat 更容易验收
现有客服、摘要、翻译已经以 messages 管理历史，且多个厂商都走 Chat 兼容接口时，先优化输出验证、超时恢复和用量记录。单纯换 endpoint 无法保证业务答案更好。
Chat 也可支持工具和结构化输出，但具体支持来自模型与渠道。不要把 Chat 等同于只能文本，也不要仅凭“OpenAI 兼容”假定每个扩展字段都接受。
这些需求，值得单独验证 Responses
Codex 等指定 Responses 协议的客户端，需要匹配这个接口。应用希望将消息、函数调用和其他结果用统一类型处理时，Responses 的输出形态也更合适。
previous_response_id、Conversations、文件搜索、联网搜索等功能需要明确的接口能力与计费支持。能返回一条 Responses 文本，不能证明这些高级功能都可用。
先做同输入的双接口最小实验
下面两次调用可能产生两笔费用。用同一模型和问题，仅比较是否完整、读到的答案与 usage；这不是性能榜单。
python
python
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["tokenba_API_KEY"],
base_url="https://api.apizt.com/v1", max_retries=0, timeout=60)
model = os.environ["tokenba_MODEL"]
prompt = "将这句改得易懂：请求进入队列，预计 30 秒完成。"
chat = client.chat.completions.create(model=model,
messages=[{"role": "user", "content": prompt}])
print(chat.choices[0].finish_reason, chat.choices[0].message.content, chat.usage)
response = client.responses.create(model=model, input=prompt,
store=False, max_output_tokens=1024)
print(response.status, response.output_text, response.usage)保存历史与计费，别由名称推断
手动维护历史时，后续请求通常包含此前的输入与输出，历史长度会继续影响上下文预算与计量。使用服务端状态续接也不等于历史免费，按实际 usage 和账单检查。
把应用的会话数据、上游存储选项和网关日志分别核对。store=False 不代表整条处理链没有任何日志。
失败位置决定修哪里
| 失败 | 优先检查 |
|---|---|
| Chat 通，Responses 404 | /v1/responses 路径及渠道支持 |
| 文本通，工具失败 | 工具定义、回传 ID、模型功能 |
| 首轮通，第二轮失败 | 状态策略与上一轮 output 项 |
| 流式有字但未完成 | 终态、截断、代理中断 |
| 结果对但费用增加 | 所有尝试、历史输入及输出量 |
- 失败
- Chat 通，Responses 404
- 优先检查
- /v1/responses 路径及渠道支持
- 失败
- 文本通，工具失败
- 优先检查
- 工具定义、回传 ID、模型功能
- 失败
- 首轮通，第二轮失败
- 优先检查
- 状态策略与上一轮 output 项
- 失败
- 流式有字但未完成
- 优先检查
- 终态、截断、代理中断
- 失败
- 结果对但费用增加
- 优先检查
- 所有尝试、历史输入及输出量
本站绘制的内容说明图：这些检查覆盖路径、第二轮工具上下文和流结束；首轮生成文本并不证明迁移后的完整任务通过。
迁移顺序：一条流程一次改一层
- 保留旧入口并建立有人工验收的样本。
- 先迁文本与错误处理，再迁多轮、工具、Schema、流式。
- 分开记录协议与模型版本，避免同时换提示词和模型。
- 小流量验证完成率与任务总成本，再扩大。
怎样确认已经完成
- 确认所选渠道支持目标 endpoint
- 文本、多轮、工具、Schema 与流式分别验证
- 失败时有明确错误与回退入口
- 对比所有尝试费用，不只成功一次
常见问题
Responses 会取代所有 Chat 应用吗？
不需要立即重写。按客户端协议与实际业务能力选择，现有稳定路径可以逐流程迁移。
接口不同就代表模型不同吗？
不是。协议、模型 ID 和渠道是不同层面，同一名称仍需分别验收支持。