OpenAI 两种 API，你选对了吗？Responses API 这6个优势让 Chat Completions 瑟瑟发抖

Fri, 07 Aug 2026 07:30:00 +0800

你还在用 /v1/chat/completions？OpenAI 2025年3月推出的 Responses API 已经整合了 Chat Completions + Assistants API 的全部优势。大多数开发者还在观望要不要切。

先说结论

Responses API 是 OpenAI 的未来。Chat Completions 不会废弃，但新功能全部优先在 Responses API 上线。

两者本质区别：Chat API 是 message-centered（所有东西围绕 messages[]），Responses API 是 item-centered（输入/输出/工具调用/推理拆成 typed items）。

换个说法：Chat API 像一个只有聊天窗口的界面，所有内容都往 messages 数组里塞。Responses API 像一个结构化的工作台，输入、输出、工具调用、推理过程各归其位。

一句话总结：新项目直接用 Responses API，老项目不急着迁移，但别再基于 Chat API 开新功能了。

6大核心差异

一张表说清楚：

维度	Chat Completions API	Responses API
端点	`/v1/chat/completions`	`/v1/responses`
状态管理	无状态，客户端维护完整对话历史	有状态，`previous_response_id` 实现服务端会话
设计哲学	message-centered	item-centered
内置工具	无，需第三方实现	web_search、code_interpreter、file_search、image_generation、MCP
流式输出	SSE 逐 token 推送	语义化事件（text delta、tool_call 等独立事件类型）
推理能力	无原生 reasoning 支持	原生 reasoning tokens，输出结构化推理过程

最关键的一行：状态管理。Chat API 每次请求要把完整对话历史塞进去，token 消耗随对话轮次线性增长。Responses API 一个 previous_response_id 搞定，服务端帮你存。

内置工具对比

这才是 Responses API 真正拉开差距的地方：

工具	Chat Completions	Responses API
自定义函数	functions/tools ✅	FunctionTool ✅
Web搜索	需第三方实现	内置 web_search ✅
代码解释器	需Assistants API	内置 code_interpreter ✅
文件搜索	需Assistants API	内置 file_search ✅
图像生成	需单独调用DALL-E	内置 image_generation ✅
MCP协议	不支持	支持远程MCP服务器 ✅

用 Chat API 想要搜索+代码执行？你得自己接第三方搜索服务，再单独接 Assistants API 的 code_interpreter。

用 Responses API？一行代码搞定：tools=[{"type": "web_search"}, {"type": "code_interpreter"}]。

代码对比：从写法看差异

Chat Completions——你要自己管理一切：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


from openai import OpenAI
client = OpenAI()

# 每次都要传完整历史
response = client.chat.completions.create(
 model="gpt-4o",
 messages=[
 {"role": "system", "content": "You are helpful."},
 {"role": "user", "content": "Hello"},
 {"role": "assistant", "content": "Hi!"},
 {"role": "user", "content": "今天天气怎么样？"}
 ]
)
print(response.choices[0].message.content)

Responses API——服务端帮你管状态：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


from openai import OpenAI
client = OpenAI()

# 第一轮
r1 = client.responses.create(
 model="gpt-4o",
 input="Hello",
 tools=[{"type": "web_search"}]
)
print(r1.output_text)

# 第二轮：只需传上一轮的 ID
r2 = client.responses.create(
 model="gpt-4o",
 input="今天天气怎么样？",
 previous_response_id=r1.id # 服务端自动携带历史
)
print(r2.output_text)

区别一目了然：Chat API 的 messages 数组会越来越长，token 费用线性增长。Responses API 每次只传一个 ID。

流式输出：从"逐字蹦"到"语义推送"

Chat API 的流式输出是原始 SSE，你拿到的是一连串 token delta：

1
2
3


data: {"choices":[{"delta":{"content":"你"}}]}
data: {"choices":[{"delta":{"content":"好"}}]}
data: {"choices":[{"delta":{"content":"！"}}]}

Responses API 是语义化事件，不同类型事件分开推送：

1
2
3
4
5


event: response.output_text.delta
data: {"delta": "你好"}

event: response.tool_call.created
data: {"name": "web_search", "arguments": {"query": "天气"}}

好处：你可以精确区分"模型在输出文字"还是"模型在调用工具"还是"模型在推理"。Chat API 里这些全混在一起，解析起来很痛苦。

推理能力：Chat API 的硬伤

Chat API 对 reasoning（推理过程）完全没有原生支持。你想让模型"想一想再回答"？只能靠 prompt 引导，效果看运气。

Responses API 原生支持 reasoning tokens：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


response = client.responses.create(
 model="o1",
 input="分析这段代码的性能瓶颈",
 reasoning={"effort": "high"} # 控制推理深度
)
# 推理过程和最终答案分离输出
for item in response.output:
 if item.type == "reasoning":
 print("推理过程:", item.content)
 elif item.type == "message":
 print("最终答案:", item.content)

推理过程和最终答案结构化分离，这对需要展示思维链的应用（比如教育、代码审查）价值巨大。

MCP 协议：Responses API 的隐藏大招

2025年5月，Responses API 新增了对 MCP（Model Context Protocol） 的原生支持。这不是小功能——它意味着模型可以直接连接外部工具服务器，不需要你在客户端做中间代理。

1
2
3
4
5
6
7
8
9


response = client.responses.create(
 model="gpt-4o",
 input="帮我查一下今天的 GitHub Trending",
 tools=[{
 "type": "mcp",
 "server_label": "github",
 "server_url": "https://mcp.github.com/sse"
 }]
)

Chat Completions API 完全不支持 MCP。你想在 Chat API 里用 MCP 工具？只能自己在客户端做协议转换，写一堆胶水代码。

为什么 MCP 重要？它是一个开放标准，Anthropic、Google、各大工具厂商都在跟进。Responses API 原生支持 MCP，意味着你的应用可以直接接入整个 MCP 生态，不用为每个工具写适配器。

Background Mode：长任务不再阻塞

Responses API 还有一个 Chat API 完全没有的能力——后台执行模式。

有些任务需要几分钟甚至几十分钟才能完成（比如大规模代码分析、复杂的多步骤推理）。用 Chat API，你只能傻等，连接超时了还得自己做重试逻辑。

Responses API 的 background mode：请求提交后立即返回一个 response_id，任务在服务端异步执行，你随时可以查询状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 提交后台任务
response = client.responses.create(
 model="o1",
 input="分析这个代码库的架构问题",
 background=True
)
# 立刻拿到 response_id，去做别的事

# 随后查询结果
result = client.responses.retrieve(response.id)
if result.status == "completed":
 print(result.output_text)

对生产环境来说，这个能力太重要了。你不需要额外搭建任务队列，OpenAI 帮你做了。

国内替代方案

Responses API 是 OpenAI 的标准，但国内厂商也在跟进：

能力	海外（OpenAI）	国内替代
Responses API	OpenAI 原生	火山引擎（字节）已支持迁移
Web搜索	内置 web_search	通义千问内置搜索、Kimi 内置搜索
代码执行	内置 code_interpreter	智谱 GLM 内置代码沙箱
文件搜索	内置 file_search	百度文心一言文件对话
MCP协议	原生支持	各家陆续跟进中

火山引擎是目前国内最积极跟进 Responses API 的平台，字节的 Coze 平台已经支持。

该不该迁移？

直接上结论：

场景	建议
新项目	直接用 Responses API，没商量
已有 Chat API 项目	不急，Chat API 不会废弃，但别加新功能了
需要内置工具	必须迁移，这是 Responses API 的杀手锏
需要推理能力	必须迁移，Chat API 不支持
只做简单对话	可以不迁，但建议年底前完成

迁移成本其实不高。OpenAI 的 Python SDK 同时支持两个接口，迁移主要就是把 client.chat.completions.create 改成 client.responses.create，参数结构调一下。

最大的收益是状态管理。10轮对话用 Chat API，每次请求要把全部历史（21条消息）塞进去，token消耗随对话轮次线性增长。用 Responses API 的 previous_response_id，每次请求只传最新输入，token消耗大幅降低。

对高频调用的应用来说，光这一个改进就能省不少钱。

我的判断：Chat Completions API 就像当年的 IE6，不会突然消失，但你不想2027年还在用它。

关键事实

Responses API 于 2025年3月 推出，是 OpenAI 的战略性产品
OpenAI 官方明确表态：新集成应直接使用 Responses API
Chat Completions API 不会废弃，维护模式，新功能不再优先
Responses API 整合了 Chat Completions + Assistants API 的优势，Assistants API 未来可能被完全替代
火山引擎（字节）已支持 Responses API 迁移，是国内最积极的跟进者
2025年5月大更新：远程MCP服务器、Image Generation、Code Interpreter、升级版File Search、background mode、encrypted content
Python SDK 同时支持两个接口，迁移成本可控

AI开发 on Kalend's Blog