一、OpenAi的Responses API和Chat Completions API
简单来说,Responses API 是 OpenAI 新一代的统一接口,而 Chat Completions API 是上一代专门用于聊天的接口。对于新项目,通常建议优先使用 Responses API。
下面是详细对比:
| 对比项 | Chat Completions API | Responses API |
|---|---|---|
| 发布时间 | 较早 | 新一代统一 API |
| 主要用途 | 聊天 | 聊天 + Agent + 工具调用 + 多模态 |
| 接口 | /v1/chat/completions | /v1/messages |
| 输入格式 | messages |
input |
| 输出格式 | choices[].message |
output[] |
| 多模态 | 支持,但扩展有限 | 原生支持文本、图片、音频等 |
| 工具调用 | Function Calling | Tool Calling(统一) |
| 推理模型 | 支持 | 更好支持 GPT-5 系列推理模型 |
| 推荐程度 | 兼容旧项目 | 官方推荐新项目使用 |
- Chat Completions
这是大家最熟悉的接口: /v1/chat/completions
python
client.chat.completions.create(
model="gpt-4o",
messages=[
{"role":"system","content":"You are helpful."},
{"role":"user","content":"Hello"}
]
)
返回
python
{
"choices": [
{
"message": {
"role": "assistant",
"content": "Hi!"
}
}
]
}
特点:
使用 messages,适合聊天机器人,Function Calling,流式输出,JSON Mode
- Responses API
新的接口变成:/v1/messages
python
client.responses.create(
model="gpt-5.5",
input="Hello"
)
或者
python
client.responses.create(
model="gpt-5.5",
input=[
{
"role":"user",
"content":[
{
"type":"input_text",
"text":"Hello"
}
]
}
]
)
返回的是
json
{
"output": [
{
"type":"message",
"content":[
{
"type":"output_text",
"text":"Hi!"
}
]
}
]
}
- 为什么要推出 Responses API?
因为 OpenAI 希望把所有能力统一成一个接口。
以前:
python
Chat
↓
Chat Completions
图片
↓
Images API
Function Calling
↓
Chat Completion
Vision
↓
Chat Completion
现在:
python
Responses API
│
├── 文本
├── 图片
├── 音频
├── Tool Calling
├── 推理
├── JSON
├── Streaming
└── Agent
- 多模态更自然
例如图片: Chat Completions:messages: // 里面需要特殊格式。 Responses:
python
input:[
{
"role":"user",
"content":[
{
"type":"input_text",
"text":"Describe"
},
{
"type":"input_image",
"image_url":"..."
}
]
}
]
文本、图片、音频都放在同一个 content 数组里,更统一。
以后很多新能力都会首先(甚至只)支持 Responses API。
- 新项目该选哪个?
一般建议:
新项目:优先使用 Responses API。 它是 OpenAI 当前推荐的统一接口,后续的新能力通常会优先支持它。 已有项目: 如果已经稳定使用 Chat Completions API,没有必要为了迁移而立即重构,可以按需逐步迁移。
如果把它们类比成软件版本:
Chat Completions:成熟稳定的经典接口,适合维护已有项目。 Responses API:统一、面向未来的新接口,集成了文本、多模态、工具调用等能力,是新开发的首选。
二、OpenAi端点和Anthropic端点区别
如果说的是 OpenAI 的 Responses API (/v1/responses) 和 Anthropic 的 Messages API (/v1/messages),它们都是现代 LLM API,但设计理念有不少区别。
| 对比项 | OpenAI Responses API | Anthropic Messages API |
|---|---|---|
| Endpoint | /v1/responses |
/v1/messages |
| 输入字段 | input |
messages |
| System Prompt | system/developer 角色(或开发者指令) |
独立 system 参数,不放在 messages 中 |
| 输出 | 多种 typed output(message、tool、reasoning 等) | 一个 assistant message |
| Tool Calling | 内置工具 + Function Calling | Tool Use |
| 多模态 | 文本、图片、文件等统一输入 | 文本、图片 |
| 会话状态 | 支持 previous_response_id 等状态管理 |
完全无状态,需要客户端维护历史 |
| 推理 | GPT-5 推理模型支持 reasoning | Claude 的 Extended Thinking |
| Prompt Cache | 自动优化 | 开发者可显式控制 Prompt Caching |
- 请求格式
OpenAI
python
{
"model": "gpt-5.5",
"input": "Hello"
}
# 或者
{
"input": [
{
"role": "user",
"content": [
{
"type": "input_text",
"text": "Hello"
}
]
}
]
}
统一使用 input。
Anthropic
python
{
"model": "claude-sonnet",
"messages": [
{
"role": "user",
"content": "Hello"
}
]
}
仍然保持 messages。
- System Prompt
这是两家最大的区别之一。
Anthropic System Prompt 独立:
python
{
"system": "You are a helpful assistant.",
"messages": [...]
}
不能把 system 插到消息中间,也通常只有一个顶层 system。
OpenAI
Responses API 支持不同层级的指令(例如 developer、system、user),统一放在输入消息体系中,便于构建复杂的 Agent 和多轮交互。
- 输出格式
Anthropic: 比较简单。
python
{
"content": [
{
"type": "text",
"text": "Hello"
}
]
}
OpenAI:
python
{
"output": [
{
"type": "message",
...
},
{
"type": "reasoning",
...
},
{
"type": "function_call",
...
}
]
}
返回的是一组 类型化(typed)输出项,不仅可以包含文本,还可以包含工具调用、推理信息等。
鉴权与版本头 OpenAI:通行做法是 Authorization: Bearer 。 Anthropic:常见为 x-api-key,并常配合 anthropic-version(或兼容层要求的等价头字段)。
从接口设计来看:
OpenAI Responses API :更偏向统一的 Agent 接口,使用 input + output,支持服务器端会话状态、内置工具和类型化输出,适合复杂工作流。 Anthropic Messages API:更偏向经典聊天接口,使用 messages + content,结构简洁、无状态,便于客户端自行管理上下文。
OpenAI API 和 Anthropic API 是当前主流的生成式 AI 接口,开发调用差异二者在调用地址、鉴权方式、消息格式等基础开发细节上差异明显,同时计费管理接口也各有特点,具体如下:
| 开发维度 | OpenAI API | Anthropic API |
|---|---|---|
| API 地址 | https://api.openai.com/v1/chat/completions |
https://api.anthropic.com/v1/messages |
| 鉴权方式 | 采用 Authorization: Bearer <api_key> 头部认证 |
需同时配置 x-api-key: <api_key> 和 anthropic-version 头部 |
| 消息格式 | 支持 system/user/assistant 三类角色的消息结构 |
以 user/assistant 角色为主,system 提示单独作为全局参数配置 |
| 计费管理 | 计费接口成熟,可按项目、模型、API密钥等维度筛选使用量和成本数据,能直接对接企业成本仪表盘,适配长期稳定的成本监控需求 | 新增的计费管理 API 功能较全面,可按模型、工作区等维度拆分用量,数据更新延迟约 5 分钟,但优先级服务的成本需单独通过用量接口拼接,适配企业精细化成本核算 |
三个端点怎么选?
| 端点 | 属于哪套生态 | 适合什么场景 | 请求格式特点 |
|---|---|---|---|
/v1/chat/completions |
OpenAI 兼容聊天接口 | 大多数第三方工具、聊天 UI、Cursor 类客户端、LiteLLM、FastGPT、OpenAI SDK 兼容模式 | messages: {role, content} |
/v1/responses |
OpenAI 新版 Responses API | 新版 OpenAI 工具调用、多模态、reasoning、agent 工作流 | input、tools、结构化 response item |
/v1/messages |
Anthropic Claude 原生接口 | Claude 原生 SDK、Anthropic Messages API 工具 | 顶层 system + messages、Anthropic schema |
工具到底是 OpenAI 兼容模式,还是 Anthropic 原生模式 如果工具让你填 OPENAI_BASE_URL,大概率是 OpenAI 兼容模式。 如果工具让你填 Anthropic API Key,或者文档里写 Claude Messages API,大概率是 Anthropic 原生模式。