OpenAI 新旧 API 协议全面对比：Chat Completions vs Responses API

在这里插入图片描述

大家好，我是 JavaPub。

如果你最近在接 OpenAI、Codex、Claude Code 中转平台，或者在做类似 New API、One API、Sub2API 这样的 API 网关，你应该会越来越频繁地看到两个接口：

POST /v1/chat/completions

以及：

POST /v1/responses

很多人习惯把它们称为：

旧协议：Chat Completions
新协议：Responses API

这种理解基本没问题。

目前 OpenAI 官方 API Reference 已经把 Responses API 单独放在核心 API 区域，而 Chat Completions 仍然保留并继续提供。与此同时，旧的 Assistants API 已经明确标记为 deprecated，并推荐迁移到 Responses API。

这篇文章，我们就把两套协议从请求结构、返回结构、流式输出、工具调用、多轮对话以及中转平台适配几个角度一次讲清楚。

一、先看结论

简单理解：

Chat Completions
        ↓
传统“聊天接口”
messages → model → choices

Responses API
        ↓
新一代统一模型接口
input → model/tools/reasoning → output

两者最大的区别，不只是把：

messages

改成：

input

而是 OpenAI 正在把模型调用从：

单纯的聊天生成

升级成：

统一 AI 执行接口

也就是说 Responses API 不只是考虑：

用户问一句
AI 回一句

而是同时考虑：

文本
图片
文件
推理
工具调用
Web Search
Code Interpreter
MCP / Agent
多轮状态
结构化输出

从官方当前 API 结构也能看到，Responses API 已经包含 Responses、Conversations、Input Items、Streaming Events、WebSocket Events 等完整能力。

二、接口地址区别

Chat Completions

旧协议：

POST /v1/chat/completions

典型结构：

Client
   ↓
/v1/chat/completions
   ↓
messages
   ↓
model
   ↓
choices
   ↓
message.content

Responses API

新协议：

POST /v1/responses

典型结构：

Client
   ↓
/v1/responses
   ↓
input
   ↓
model
   ↓
reasoning / tools
   ↓
output

目前 OpenAI API Reference 将 Responses API 作为独立核心 API 提供，包括创建、查询、删除、取消、Compact Response、Conversations 以及输入项管理等接口。

三、最简单的请求对比

假设我们的需求非常简单：

你好，介绍一下 Golang。

四、旧协议 Chat Completions

CURL

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5",
    "messages": [
      {
        "role": "user",
        "content": "你好，介绍一下 Golang"
      }
    ]
  }'

核心就是：

{
  "model": "gpt-5",
  "messages": []
}

这里：

messages

是整个 Chat Completions 协议最核心的数据结构。

五、新协议 Responses API

对应的新协议可以理解为：

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5",
    "input": "你好，介绍一下 Golang"
  }'

你会发现最大的变化就是：

messages

变成了：

input

最简单情况下：

{
  "model": "gpt-5",
  "input": "你好"
}

就可以调用。

这让简单请求明显更简洁。

六、核心参数变化

可以先记住这张表：

Chat Completions Responses API
/v1/chat/completions /v1/responses
messages input
choices output
message.content output 内容项
max_tokens / max_completion_tokens max_output_tokens
tools tools
tool_calls output 中的 tool item
手动传历史消息 可配合 Response / Conversation 管理
面向 Chat 面向统一 AI Execution

最值得注意的就是：

messages → input

choices → output

这两个变化。

七、messages 和 input 到底有什么区别？

Chat Completions 时代，我们通常这样写：

{
  "messages": [
    {
      "role": "system",
      "content": "你是一名 Go 工程师"
    },
    {
      "role": "user",
      "content": "解释一下 goroutine"
    }
  ]
}

这是一种非常明显的：

聊天记录

模型。

Responses API 则更倾向于：

输入项

或者：

Input Items

这个概念。

例如：

{
  "model": "gpt-5",
  "input": [
    {
      "role": "user",
      "content": "解释一下 goroutine"
    }
  ]
}

未来 input 里面并不一定只有：

message

还可能包含不同类型的信息。

所以从设计思想上来看：

messages

强调：

聊天消息

而：

input

强调的是：

模型输入

后者明显更加通用。

八、System Prompt 怎么办？

以前我们习惯：

{
  "messages": [
    {
      "role": "system",
      "content": "你是一名专业程序员"
    },
    {
      "role": "user",
      "content": "写一个冒泡排序"
    }
  ]
}

Responses API 更适合把顶层指令独立出来，例如：

{
  "model": "gpt-5",
  "instructions": "你是一名专业程序员，回答时提供完整代码。",
  "input": "使用 Go 写一个冒泡排序"
}

从工程上来说我很喜欢这种设计。

因为以前：

系统 Prompt
业务 Prompt
用户 Prompt
历史消息

全部塞进：

messages[]

久了以后很乱。

现在可以变成：

instructions
    ↓
长期规则

input
    ↓
本次输入

职责更加清楚。

九、返回值变化非常大

这其实是很多中转平台最容易踩坑的地方。

Chat Completions 返回值

传统返回结构大概是：

{
  "id": "chatcmpl_xxx",
  "object": "chat.completion",
  "model": "gpt-5",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Golang 是 Google 开发的一门编程语言..."
      },
      "finish_reason": "stop"
    }
  ]
}

业务代码通常这么取：

const text =
  response.choices[0].message.content;

或者 Python：

text = response["choices"][0]["message"]["content"]

十、Responses API 返回值

Responses API 不再围绕：

choices

设计。

而是：

output

例如概念上：

{
  "id": "resp_xxx",
  "object": "response",
  "status": "completed",
  "model": "gpt-5",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "Golang 是 Google 开发的一门编程语言..."
        }
      ]
    }
  ]
}

也就是说：

旧：

choices
  ↓
message
  ↓
content

变成：

新：

output
  ↓
item
  ↓
content
  ↓
output_text

为什么反而感觉更复杂？

因为 output 以后不仅仅是：

文本

它还可能是：

message
tool_call
reasoning
function_call
image
file
computer action
其他 Item

所以 Responses API 本质是：

输出项目数组

而不是：

候选答案数组

十一、这也是新旧协议最本质的区别

旧接口：

Question

↓ LLM

Answer

Responses：

Input
      ↓
┌───────────────┐
│     Model     │
├───────────────┤
│ Reasoning     │
│ Tools         │
│ Search        │
│ Files         │
│ Code          │
│ Functions     │
└───────────────┘
      ↓
Output Items

所以我认为：

Responses API 更像一个 AI Runtime 协议，而 Chat Completions 更像一个 LLM Chat 协议。

这也是为什么它更加适合 Agent。

十二、Python SDK 对比

旧写法通常是：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY"
)

response = client.chat.completions.create(
    model="gpt-5",
    messages=[
        {
            "role": "user",
            "content": "介绍一下 Golang"
        }
    ]
)

print(response.choices[0].message.content)

新接口：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY"
)

response = client.responses.create(
    model="gpt-5",
    input="介绍一下 Golang"
)

print(response.output_text)

你会发现新 SDK 在最简单的文本生成场景下反而更舒服：

response.output_text

而不是：

response.choices[0].message.content

十三、Node.js 对比

Chat Completions：

import OpenAI from "openai";

const client = new OpenAI({
    apiKey: process.env.OPENAI_API_KEY
});

const response = await client.chat.completions.create({
    model: "gpt-5",
    messages: [
        {
            role: "user",
            content: "介绍一下 Golang"
        }
    ]
});

console.log(
    response.choices[0].message.content
);

Responses：

import OpenAI from "openai";

const client = new OpenAI({
    apiKey: process.env.OPENAI_API_KEY
});

const response = await client.responses.create({
    model: "gpt-5",
    input: "介绍一下 Golang"
});

console.log(response.output_text);

十四、Java 示例

传统 Chat Completions 思路：

Map<String, Object> request = new HashMap<>();

request.put("model", "gpt-5");

List<Map<String, String>> messages = new ArrayList<>();

Map<String, String> message = new HashMap<>();
message.put("role", "user");
message.put("content", "介绍一下 Golang");

messages.add(message);

request.put("messages", messages);

Responses API：

Map<String, Object> request = new HashMap<>();

request.put("model", "gpt-5");
request.put("input", "介绍一下 Golang");

明显简单很多。

十五、Go 示例

使用 HTTP 直接请求最容易看懂。

Chat Completions

package main

import (
	"bytes"
	"fmt"
	"io"
	"net/http"
)

func main() {

	body := []byte(`{
		"model": "gpt-5",
		"messages": [
			{
				"role": "user",
				"content": "介绍一下 Golang"
			}
		]
	}`)

	req, err := http.NewRequest(
		"POST",
		"https://api.openai.com/v1/chat/completions",
		bytes.NewBuffer(body),
	)

	if err != nil {
		panic(err)
	}

	req.Header.Set(
		"Authorization",
		"Bearer "+YOUR_API_KEY,
	)

	req.Header.Set(
		"Content-Type",
		"application/json",
	)

	client := &http.Client{}

	resp, err := client.Do(req)

	if err != nil {
		panic(err)
	}

	defer resp.Body.Close()

	data, _ := io.ReadAll(resp.Body)

	fmt.Println(string(data))
}

Responses API：

package main

import (
	"bytes"
	"fmt"
	"io"
	"net/http"
)

func main() {

	body := []byte(`{
		"model": "gpt-5",
		"input": "介绍一下 Golang"
	}`)

	req, err := http.NewRequest(
		"POST",
		"https://api.openai.com/v1/responses",
		bytes.NewBuffer(body),
	)

	if err != nil {
		panic(err)
	}

	req.Header.Set(
		"Authorization",
		"Bearer "+YOUR_API_KEY,
	)

	req.Header.Set(
		"Content-Type",
		"application/json",
	)

	client := &http.Client{}

	resp, err := client.Do(req)

	if err != nil {
		panic(err)
	}

	defer resp.Body.Close()

	data, _ := io.ReadAll(resp.Body)

	fmt.Println(string(data))
}

从 HTTP 层面其实非常直观：

/chat/completions
        ↓
messages

/responses
        ↓
input

十六、多轮对话有什么区别？

这是非常重要的一点。

以前 Chat Completions 的多轮对话通常需要你自己保存全部历史：

{
  "messages": [
    {
      "role": "user",
      "content": "我叫 JavaPub"
    },
    {
      "role": "assistant",
      "content": "你好 JavaPub"
    },
    {
      "role": "user",
      "content": "我叫什么？"
    }
  ]
}

本质就是：

数据库
   ↓
读取所有历史消息
   ↓
拼 messages
   ↓
重新发给模型

Responses API 提供了更加原生的 Response / Conversation 体系，官方 API Reference 当前已经提供 Conversations，以及 Conversation Items 的创建、查询、更新、删除和列表接口。

因此未来的应用可以更加自然地设计为：

Conversation
     ↓
Response A
     ↓
Response B
     ↓
Response C

而不是单纯：

messages[0]
messages[1]
messages[2]
messages[3]
...

十七、previous_response_id

Responses API 一个非常实用的思路就是：

previous_response_id

例如第一次：

{
  "model": "gpt-5",
  "input": "我叫 JavaPub"
}

假设返回：

resp_123456

下一轮：

{
  "model": "gpt-5",
  "previous_response_id": "resp_123456",
  "input": "我叫什么？"
}

逻辑就变成：

resp_123456
      ↓
上一轮上下文
      ↓
新 input
      ↓
新 Response

这对于 Agent 系统来说非常舒服。

十八、工具调用变化

以前 Chat Completions 的 Function Calling：

{
  "model": "gpt-5",
  "messages": [
    {
      "role": "user",
      "content": "北京天气怎么样？"
    }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "查询天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string"
            }
          },
          "required": [
            "city"
          ]
        }
      }
    }
  ]
}

模型返回：

choices
  ↓
message
  ↓
tool_calls

例如：

{
  "tool_calls": [
    {
      "id": "call_xxx",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"北京\"}"
      }
    }
  ]
}

Responses API 的思想更统一。

工具调用本身就是：

output item

例如：

output
├── reasoning
├── function_call
├── message
└── ...

因此你解析 Responses API 时，不能默认：

output[0] 就一定是最终文字

正确方式应该判断：

type

例如伪代码：

for _, item := range response.Output {

	switch item.Type {

	case "message":
		// 处理文本

	case "function_call":
		// 执行函数

	case "reasoning":
		// 推理相关数据
	}
}

这种结构明显更加适合 Agent Runtime。

十九、为什么 Agent 更适合 Responses？

传统 Chat Completions：

User
 ↓
LLM
 ↓
Tool Call
 ↓
程序执行
 ↓
重新拼 messages
 ↓
LLM
 ↓
Answer

大量状态都是：

开发者自己维护

Responses 的设计更像：

             ┌──────────────┐
             │   Response   │
             └──────┬───────┘
                    ↓
          ┌──────────────────┐
          │      Model       │
          └──────────────────┘
                    ↓
     ┌──────────────┼─────────────┐
     ↓              ↓             ↓
 Reasoning       Tool Call      Message
     ↓              ↓
     └──────→ Tool Result
                    ↓
                 Model
                    ↓
                  Output

它不是单纯解决：

聊天

而是解决：

AI Task Execution

二十、流式输出区别

Chat Completions 流式请求：

{
  "model": "gpt-5",
  "messages": [
    {
      "role": "user",
      "content": "你好"
    }
  ],
  "stream": true
}

传统 SSE 大概是：

data: {...}

data: {...}

data: {...}

data: [DONE]

核心增量数据经常在：

choices[0].delta.content

所以很多中转系统代码里都会出现：

chunk.choices[0].delta.content

Responses API 的 streaming 更偏：

事件驱动

官方 API Reference 也已经为 Responses API 单独定义了 Streaming Events 和 WebSocket Events。

它的思路是：

event A
event B
event C
event D

例如可能经历：

response.created

response.output_item.added

response.output_text.delta

response.output_text.done

response.completed

因此：

Chat Completion Stream

更像：

不断追加 token

而：

Responses Stream

更像：

不断触发状态事件

二十一、中转平台为什么特别需要注意 Streaming？

如果你正在写：

OpenAI API Proxy

最容易犯的错误就是直接：

上游 SSE
   ↓
原封不动转发

Chat Completions 可能还能工作。

但是 Responses API 以后事件类型会越来越多。

例如你应该设计：

type StreamEvent struct {
	Type string `json:"type"`
}

然后：

switch event.Type {

case "response.output_text.delta":
	handleTextDelta()

case "response.function_call_arguments.delta":
	handleToolDelta()

case "response.completed":
	handleCompleted()

case "response.failed":
	handleFailed()
}

而不是永远写死：

choices[0].delta.content

二十二、一个优秀的 API 网关应该怎么设计？

如果你的平台同时支持：

OpenAI
Claude
Gemini
DeepSeek
Grok

我不建议内部数据结构直接使用：

ChatCompletionRequest

因为这样你的整个系统都会被：

OpenAI Chat Completions

绑死。

更加推荐：

type AIRequest struct {

	Model string

	Input []InputItem

	Tools []Tool

	Stream bool

	MaxOutputTokens int
}

例如：

type InputItem struct {

	Role string

	Type string

	Text string
}

然后：

                 Internal AI Protocol
                         │
       ┌─────────────────┼──────────────────┐
       ↓                 ↓                  ↓
OpenAI Responses   Chat Completions      Claude
       ↓                 ↓                  ↓
 /v1/responses    /chat/completions    /v1/messages

这才是比较长期的设计。

二十三、建议增加 Adapter 层

比如：

internal/
└── protocol/
    ├── request.go
    ├── response.go
    └── stream.go

provider/
├── openai/
│   ├── responses.go
│   └── chat.go
│
├── claude/
│   └── messages.go
│
├── gemini/
│   └── generate.go
│
└── deepseek/
    └── chat.go

统一：

type Provider interface {

	CreateResponse(
		ctx context.Context,
		req *AIRequest,
	) (*AIResponse, error)

	StreamResponse(
		ctx context.Context,
		req *AIRequest,
	) (<-chan AIEvent, error)
}

这样未来即使协议继续变化：

Responses V2
Claude Messages V2
Gemini API V2

你都不用改核心业务。

只需要改 Adapter。

二十四、Responses 对多模态更加自然

Chat Completions 后来其实也加入了多模态，例如：

{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "这是什么？"
    },
    {
      "type": "image_url",
      "image_url": {
        "url": "https://example.com/a.png"
      }
    }
  ]
}

但是你会发现：

messages

这个概念其实越来越勉强。

因为以后可能有：

text
image
audio
file
tool
computer
reasoning

所以 Responses API 把核心抽象升级成：

Input Item

就更加合理。

二十五、旧协议是不是马上不能用了？

不是。

目前 OpenAI 官方 API Reference 仍然保留完整的 Chat Completions API，包括 Create、Retrieve、Update、Delete、List 和 Streaming Events。

所以：

Chat Completions ≠ 已废弃

不要看到 Responses API 就马上把所有：

/v1/chat/completions

删掉。

特别是兼容第三方模型的平台：

DeepSeek
Qwen
Moonshot
GLM
OpenRouter
各种 OpenAI Compatible API

目前：

/v1/chat/completions

依然具有非常重要的生态价值。

二十六、真正逐渐退出历史舞台的是谁？

这里需要区分三个东西：

Completions API

Chat Completions API

Assistants API

其中传统：

/v1/completions

属于更早一代接口。

而当前 OpenAI 官方已经明确将 Assistants API 标记为 deprecated，并推荐向 Responses API 演进。

因此整个演进路线可以粗略理解成：

Completions
      ↓
Chat Completions
      ↓
Assistants / Tools
      ↓
Responses API

不过：

Chat Completions

目前依然存在，并不是说已经不能用了。

二十七、为什么 OpenAI 要设计 Responses API？

我认为主要有五个原因。

1. Chat 已经无法覆盖 AI 的全部能力

以前：

AI = 聊天机器人

现在：

AI =
Chat
+
Reasoning
+
Search
+
Code
+
Files
+
Tools
+
Agent
+
Computer Use

如果所有东西继续往：

messages

里面塞，会越来越复杂。

2. Output 不再只是文字

以前：

choices[].message.content

基本就是最终答案。

现在：

output

可能包含很多类型的 Item。

因此：

output[]

比：

choices[]

更加合理。

3. Agent 需要状态

Agent 经常运行：

10 秒
30 秒
2 分钟
甚至更长

过程可能是：

Reasoning
↓
Search
↓
Read File
↓
Function Call
↓
Code
↓
再次 Reasoning
↓
Answer

所以需要一个：

Response Object

来表示：

整个执行任务

而不是只表示：

一次文本生成

4. Tool 成为一等公民

过去：

Function Calling

更像是：

Chat 的附属能力

现在：

Tool

已经成为 AI Runtime 的核心组成部分。

5. 多模态统一

以后输入：

input

输出：

output

这个抽象天然适合：

文字
图片
语音
视频
文件
工具调用

二十八、如果你现在开发项目应该选哪个？

我的建议非常简单。

普通聊天系统

例如：

AI 客服
ChatGPT 镜像
简单 ChatBot
OpenAI Compatible 服务

继续支持：

/v1/chat/completions

完全没有问题。

而且生态兼容性往往更好。

新项目

如果是直接围绕 OpenAI 新模型开发：

优先 Responses API

尤其是：

Agent
Codex
工具调用
Web Search
Computer Use
复杂工作流
长期任务

Responses 会更加合适。

二十九、中转 API 平台怎么办？

如果你做的是：

New API
One API
OpenRouter
Sub2API
API Gateway

这一类产品，我认为最正确的答案不是：

二选一

而是：

两个都支持。

例如：

POST /v1/chat/completions

POST /v1/responses

然后内部：

                   Client
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
 /chat/completions         /responses
          ↓                     ↓
   Chat Adapter        Responses Adapter
          └──────────┬──────────┘
                     ↓
             Unified Request
                     ↓
                  Router
                     ↓
      ┌──────────────┼──────────────┐
      ↓              ↓              ↓
    OpenAI        DeepSeek        Claude

这套架构会比较稳。

三十、甚至可以做协议互转

例如客户端发送：

/v1/chat/completions

网关可以转换：

messages
↓
input
↓
OpenAI Responses

然后返回的时候：

Responses output
↓
转换
↓
choices[].message

于是：

老客户端

依然可以使用：

新 Responses 上游

这种能力对于 API 中转平台非常重要。

三十一、一个简单的转换器

例如：

type ChatMessage struct {
	Role    string `json:"role"`
	Content string `json:"content"`
}

type ChatRequest struct {
	Model    string        `json:"model"`
	Messages []ChatMessage `json:"messages"`
}

Responses：

type ResponseInput struct {
	Role    string `json:"role"`
	Content string `json:"content"`
}

type ResponsesRequest struct {
	Model string          `json:"model"`
	Input []ResponseInput `json:"input"`
}

转换：

func ChatToResponses(
	req ChatRequest,
) ResponsesRequest {

	input := make([]ResponseInput, 0)

	for _, message := range req.Messages {

		input = append(
			input,
			ResponseInput{
				Role:    message.Role,
				Content: message.Content,
			},
		)
	}

	return ResponsesRequest{
		Model: req.Model,
		Input: input,
	}
}

实际生产环境当然还需要处理：

system
developer
image
audio
tool_call
tool_result
reasoning
stream
usage
finish_reason

这些结构。

三十二、返回值也要转换

Responses：

output_text

可以转换成：

{
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello"
      },
      "finish_reason": "stop"
    }
  ]
}

这样旧 SDK 完全不知道上游其实使用的是：

Responses API

三十三、但协议转换并不是 100% 无损

这是必须注意的。

因为：

Responses API

能力集合大于传统：

Chat Completions

所以：

Responses → Chat

有时候会发生：

信息丢失

例如：

reasoning item
computer action
复杂 tool event
多阶段 output
Response 状态
Conversation 状态

Chat Completions 并没有完全对应的数据结构。

因此：

Chat → Responses

通常相对容易。

但是：

Responses → Chat

需要做降级。

三十四、建议中转平台建立统一事件模型

例如：

type EventType string

const (
	EventTextDelta EventType = "text_delta"

	EventReasoningDelta EventType = "reasoning_delta"

	EventToolCall EventType = "tool_call"

	EventToolResult EventType = "tool_result"

	EventCompleted EventType = "completed"

	EventError EventType = "error"
)

结构：

type AIEvent struct {

	Type EventType

	Text string

	Tool *ToolCall

	Usage *Usage

	Error error
}

然后：

OpenAI Responses SSE
        ↓
Responses Decoder
        ↓
AIEvent
        ↓
        ├── Responses Encoder
        ├── Chat Encoder
        ├── Claude Encoder
        └── Internal Consumer

这样才方便后期维护。

三十五、新旧协议总结

最后再通过一张表快速总结。

能力 Chat Completions Responses API
Endpoint /v1/chat/completions /v1/responses
核心输入 messages input
核心输出 choices output
定位 Chat AI Runtime
简单文本 很成熟 很方便
多模态 支持 更原生
Tool Calling 支持 更统一
Agent 可以自己实现 更适合
多轮状态 通常自己管理 Response / Conversation
流式 token/delta 风格 event 风格
SDK 取文本 choices[0].message.content output_text
第三方兼容 极高 正在快速普及
新项目 可以 推荐重点支持
API 网关 必须支持 建议必须支持

三十六、开发者应该怎么理解这次变化？

不要简单理解成：

OpenAI 换了一个 API 地址。

真正的变化是：

Chat API

正在变成：

AI Execution API

过去 API 的核心对象是：

Message

现在核心对象逐渐变成：

Input
Response
Output Item
Tool
Conversation
Event

这几个抽象非常关键。

三十七、一句话解释 OpenAI 新旧协议

如果让我只用一句话解释：

Chat Completions 是“让模型聊天”的协议，而 Responses API 正在成为“让模型完成任务”的统一协议。

如果只是：

用户：你好

AI：你好，有什么可以帮助你？

Chat Completions 足够。

但如果以后你的 AI 要：

读取文件
↓
搜索互联网
↓
分析数据
↓
执行代码
↓
调用 API
↓
继续推理
↓
生成最终答案

那 Responses API 的设计明显更加符合未来的 Agent 架构。

最后

对于普通开发者：

不用急着抛弃 Chat Completions。

对于正在开发新 AI 项目的开发者：

建议开始学习 Responses API。

而对于 API 中转平台、模型网关和 AI 基础设施开发者：

/v1/chat/completions

+

/v1/responses

最好全部支持。

更进一步，不要把自己的核心系统设计成：

OpenAI Chat Completions 的复制品

而应该建立一套：

统一 Input
统一 Output
统一 Tool
统一 Event
统一 Usage

的内部协议。

这样未来无论接入：

OpenAI
Claude
Gemini
DeepSeek
Grok
Qwen

还是新的 Agent API，都只需要增加 Adapter。

这可能才是 OpenAI 从 Chat Completions 转向 Responses API，对我们这些做 AI 应用和 AI 基础设施的人最值得关注的地方。

我是王仕宇

在这里插入图片描述

posted @ 2026-08-15 22:21  JavaPub  阅读(46)  评论(0)    收藏  举报