OpenAI 兼容接口和 Anthropic API 有什么区别？
简答：一句话结论：OpenAI 兼容接口主要复用 OpenAI SDK 或请求格式，Anthropic API 则使用原生 Messages 协议；前者适合快速接入已有 OpenAI 代码，后者更适合需要 Claude 原生工具调用、结构化输出、思考或提示缓存能力的场景。最短路径是先确认 Base URL、模型 ID和认证头，再发送一次最小文本请求；如果后续要用工具调用或流式输出，还必须单独验收消息结构、事件类型和结果回传。本文面向直接调用 AI API 的开发者，不讨论网页或移动端产品功能。
定义：OpenAI 兼容接口是按 OpenAI 风格暴露的请求与响应层，Anthropic API 是以 Messages 为核心的原生 Claude API；二者可以调用相似模型能力，但不代表参数、事件和工具协议完全相同。
先看结论：两种接口到底差在哪里
如果你的程序已经使用 OpenAI SDK，并且只需要普通文本对话，OpenAI 兼容接口通常能减少改动：主要调整 API Key、Base URL 和模型 ID。Anthropic 官方也提供 OpenAI SDK 兼容层，但明确说明它用于测试 Claude API 的兼容接入，并列出若干与原生 Claude API 不同的能力边界。Anthropic OpenAI SDK 兼容性文档
如果应用依赖 Claude 原生 Messages 语义、严格结构化输出、提示缓存、音频以外的特定输入能力、思考内容或更完整的工具循环，建议直接使用 Anthropic SDK 或原生 HTTP API。这里的“建议”是工程选型，不表示所有 Claude 模型或所有兼容网关都具备相同能力，最终仍应以当前模型和服务文档为准。
| 维度 | OpenAI 兼容接口 | Anthropic 原生 API |
|---|---|---|
| 典型端点 | /v1/chat/completions；部分服务也提供 /v1/responses | /v1/messages |
| 主要请求结构 | Chat Completions 使用 messages；Responses 使用 input、instructions 等 | 使用 messages，内容可由文本、图片和工具相关 content blocks 组成 |
| 文本响应读取 | Chat Completions 常见为 choices[0].message.content；Responses 常读 output_text 或解析 output | 遍历 content 中的 text block |
| 工具调用 | Chat Completions 返回 tool_calls；Responses 返回 typed output items，例如 function call | 返回 tool_use block，应用执行后以 tool_result block 回传 |
| 流式事件 | Chat Completions 常见为带 delta 的 SSE；Responses 使用带 type 的事件 | Messages 使用 Anthropic 自己的消息流事件，不能直接按 OpenAI chunk 解析 |
| 兼容风险 | 第三方平台可能只实现 Chat Completions，未必支持 Responses、完整工具调用或 usage | 原生语义更完整，但需要按 Anthropic 的认证、版本、消息和事件格式接入 |
OpenAI 官方将 Responses、Chat Completions 和其他 API 表面分开维护；Responses 的输入、输出和流式事件模型也不同于 Chat Completions。OpenAI API Reference 概览 OpenAI Responses 迁移指南
第一步：先统一 Base URL、认证头和请求路径
本文示例约定：BASE_URL 表示“服务根地址”，不包含资源路径；如果服务文档给出的 Base URL 已经带有 /v1，就不要再拼接一次。也就是说，以下两种写法只能选一种：
- 根地址写法：
BASE_URL=https://api.example.com，请求路径写成/v1/chat/completions、/v1/responses或/v1/messages。 - 版本地址写法：
BASE_URL=https://api.example.com/v1，请求路径只拼接/chat/completions、/responses或/messages。
OpenAI API 请求通常使用 Authorization: Bearer，并通过 /v1 下的资源路径调用接口。OpenAI 认证与 API 概览
Anthropic 当前文档将 API Key 作为 Bearer 凭证放入 Authorization: Bearer <key>；旧式 x-api-key 仍被官方文档列为兼容写法。不要把静态 API Key、OAuth 或其他短期凭证混为同一种凭证：不同凭证的获取方式和适用入口不同。原生请求还需要 anthropic-version，某些未限定工作区的 Key 还需要 anthropic-workspace-id。Anthropic 认证文档 Anthropic API 概览
OpenAI Chat Completions：最小 curl
curl "$BASE_URL/v1/chat/completions" -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"YOUR_MODEL_ID","messages":[{"role":"user","content":"只回复：ok"}]}'
Anthropic Messages：最小 curl
curl "$BASE_URL/v1/messages" -H "Authorization: Bearer $ANTHROPIC_API_KEY" -H "anthropic-version: 2026-10-21" -H "Content-Type: application/json" -d '{"model":"YOUR_CLAUDE_MODEL_ID","max_tokens":64,"messages":[{"role":"user","content":"只回复：ok"}]}'
示例中的 BASE_URL、模型 ID、Key 和 Anthropic API 版本只是变量位置示范；实际值必须从当前服务文档或控制台确认。成功判定不要只看 HTTP 200，还要检查响应是否包含预期文本字段；如果返回 HTML、网关错误页或非 JSON 内容，应先记录状态码、响应头和脱敏后的响应片段。
第二步：理解 messages、system、developer 与 content blocks
OpenAI Chat Completions 把对话放在 messages 数组中，角色可以包含 developer、system、user、assistant 和 tool。工具调用通常由 assistant 消息中的 tool_calls 表示，工具结果再以 tool 消息回传。OpenAI Chat Completions 参考
OpenAI Responses 将模型输入放在 input 中，也可以把指导内容放到顶层 instructions；响应则是带类型的 output items，工具调用不再只是 Chat Completions 中的一个消息字段。OpenAI 官方迁移说明明确把 Chat Completions 的 message、tool call 与 Responses 的 input、output item、function call 做了对应说明。OpenAI Responses 迁移指南
Anthropic Messages 的顶层请求包含 system 和 messages，消息内容可以是字符串，也可以是 content blocks。工具调用时，响应中会出现 tool_use block；应用执行工具后，要把原 assistant 响应和包含 tool_result 的 user 消息继续发回。Anthropic 工具调用流程
| OpenAI 侧概念 | Anthropic 原生侧概念 | 迁移时要改什么 |
|---|---|---|
system 或 developer message | 顶层 system | 不能只改角色名；要确认多段指令的顺序和作用域 |
assistant tool_calls | assistant 内容中的 tool_use block | 响应解析从 message 字段改为 content block 遍历 |
| tool message | user 消息中的 tool_result block | 保存对应的工具 ID，并按原协议回传结果 |
| 文本或图像 content part | 文本或图像 content block | 检查字段名、媒体类型、URL 或 Base64 形式是否被当前接口接受 |
特别要注意 Anthropic 的 OpenAI SDK 兼容层：官方文档说明，system/developer 消息会被提取、拼接后放入顶层 system；因此它不等价于原生 API 中可以出现在对话中间的系统消息。兼容层还可能静默忽略部分不支持字段，不能仅凭请求成功判断能力完整。
第三步：工具调用、结构化输出和思考能力不要混用判断
工具调用：OpenAI Chat Completions 的流式工具调用通常出现在 chunk 的 delta.tool_calls，结束原因可能是 tool_calls；Responses 则使用类型化事件和 output items。Anthropic 原生 Messages 使用 tool_use 与 tool_result，应用必须驱动“请求—执行工具—回传结果—继续请求”的循环。OpenAI Chat 流式事件参考 Anthropic 工具调用流程
严格结构化输出：不要把 OpenAI 兼容层中的 strict 当作 Anthropic 原生能力的等价物。Anthropic 官方兼容层文档明确写出，兼容层会忽略 function calling 的 strict，不能保证工具 JSON 一定符合给定 schema；需要保证 schema 时，应使用原生 Claude API 的结构化输出能力，并按当前文档测试。
思考与 reasoning：OpenAI Responses 和 Anthropic Messages 的字段、事件和返回内容不是同一套协议。Anthropic 官方说明，使用 OpenAI SDK 兼容层时不会返回 Claude 的 thinking 内容；需要完整思考相关能力时应使用原生 Claude API。思考配置还具有模型依赖，不能把某个模型的参数直接复制到其他模型。Anthropic OpenAI SDK 兼容层限制 Anthropic thinking 文档
提示缓存与音频：Anthropic 官方兼容层文档当前明确列出提示缓存不支持、音频输入不支持或会被忽略；这些限制只说明该兼容层的行为，不能泛化为所有 OpenAI 兼容服务，也不能反推 Anthropic 原生 API 的全部能力。
第四步：流式响应为什么最容易迁移失败
非流式请求通常只需改请求体和响应读取；流式请求则必须重写事件解析。OpenAI Chat Completions 的常见事件是带 choices[0].delta 的 SSE chunk；Responses 流式接口使用带 type 的 typed server-sent events，例如文本增量、完成和错误事件。OpenAI 流式响应指南 OpenAI Responses 迁移指南
Anthropic Messages 流式接口也有自己的消息流事件，应用不能假设每一行都含有 OpenAI 风格的 choices 或 delta.content。要兼容不同接口，建议把“网络读取”和“业务事件”分成两层：底层分别解析 Chat chunk、Responses event 或 Anthropic event；上层统一转换成自己的事件，例如 text_delta、tool_call_started、tool_arguments_delta、completed 和 error。Anthropic Messages 流式文档
- 最小验收：普通文本能完整拼接，结束事件能触发收尾。
- 工具验收：能识别工具名、调用 ID 和分片参数，并在参数拼接后做 JSON 校验。
- 异常验收：连接中断、事件流内错误、代理缓冲和超时都能区分记录。
- 日志要求：不要打印完整 API Key、Authorization、工具参数中的敏感数据或完整用户提示。
按场景怎么选：不是越原生就一定越好
| 场景 | 优先考虑 | 理由与注意事项 |
|---|---|---|
| 已有 OpenAI SDK 的普通文本对话 | 先试 OpenAI 兼容接口 | 通常只需调整 Base URL、Key 和模型 ID，但先做一次最小请求并确认响应字段 |
| Claude Code 或已有 Agent 工作流 | 按工具或平台文档选择兼容层或原生 API | 重点核对工具调用、流式事件、模型 ID、重试和上下文状态，不能只看能否返回文本 |
| 强依赖工具调用、结构化输出或思考 | 优先评估 Anthropic 原生 Messages | 兼容层可能忽略 strict、thinking、缓存等字段；原生接入需要重写请求和响应适配 |
| 多模型网关或路由服务 | 以网关实际声明为准 | 同一个网关可能只支持 Chat Completions，或对 Responses、SSE、usage 和工具字段做了裁剪 |
“OpenAI 兼容”只说明某一层请求接口相似，不等于支持全部 OpenAI 能力，更不等于能无修改地承载 Anthropic 原生语义。选择前应让服务方明确列出端点、模型 ID、工具调用、结构化输出、流式事件、错误格式和 usage 返回范围；没有明确说明的能力，按“未核实”处理。
迁移前自查清单：先做最小闭环，再扩大能力
- 确认身份：确认使用的是 OpenAI API、Anthropic 原生 API，还是某个兼容网关；不要把兼容层文档当成原生 API 文档。
- 确认地址：记录 Base URL 是否已经包含
/v1，最终只生成一个版本路径。 - 确认认证：检查 Key 类型、Authorization 或
x-api-key、Anthropic 版本头及可能需要的工作区头。 - 确认模型：从当前服务文档或模型列表得到真实模型 ID，不要把一个平台的模型别名直接复制到另一个平台。
- 发最小请求：先只发送一条文本消息，不同时开启工具、流式、结构化输出和思考。
- 确认响应：分别写出 Chat Completions、Responses 和 Messages 的文本提取逻辑，不要复用错误的字段路径。
- 再测流式：确认事件类型、结束标记、usage、连接超时和事件流内错误。
- 最后测工具：验证工具 schema、调用 ID、参数拼接、JSON 校验、工具结果回传和多轮循环。
如果返回 401，先查 Key、认证头和过期状态；如果返回 400，优先查请求体、版本头、模型参数或 workspace；如果返回 404，查 Base URL、路径和模型 ID；如果文本成功但工具或流式失败，通常是能力边界或事件解析问题，而不是“接口完全不兼容”。Anthropic 官方也按 400、401、402 等类别说明了错误响应和排查方向。Anthropic API 错误文档
常见问题
OpenAI 兼容接口能直接调用 Anthropic 模型吗？
有些平台或 Anthropic 官方兼容层可以通过 OpenAI SDK 风格调用 Claude，但是否能用工具、结构化输出、思考、缓存和流式能力，要看当前兼容层文档。只把 Base URL 换掉并不能证明全部功能兼容。
Anthropic API 和 OpenAI API 的认证方式一样吗？
两者都可以在 HTTP 请求中使用 Bearer 形式，但请求头、版本头、工作区选择和凭证来源仍可能不同。Anthropic 当前文档说明 API Key 可放在 Authorization，旧式 x-api-key 仍支持；OAuth 或其他短期凭证不能简单等同于静态 API Key。
为什么普通聊天成功，工具调用却失败？
普通文本只验证了认证、路径、模型和基础响应；工具调用还涉及 schema、调用 ID、参数 JSON、工具结果回传和多轮状态机。应分别测试 Chat Completions、Responses 或 Messages 的工具结构，不要只复用文本响应解析器。
OpenAI Chat Completions、Responses 和 Anthropic Messages 可以用同一套解析代码吗？
不建议直接共用。Chat Completions 常见字段是 choices 和 delta，Responses 使用 input、output items 及 typed events，Anthropic Messages 使用 content blocks 和 tool_use/tool_result。可以在适配层之后统一成自己的内部事件模型。
什么时候应该优先使用 Anthropic 原生 API？
当应用依赖 Claude 原生 Messages 语义、工具调用循环、结构化输出、思考或提示缓存等能力时，应优先评估原生 API；如果只是快速验证已有 OpenAI 代码能否调用 Claude，可先试兼容层。
相关阅读
- Codex 自定义 API 端点与 Base URL 配置
- Cursor 自定义 OpenAI 接口配置
- Dify 添加自定义模型 API
- API 返回 403 或 404 的路径与权限排查
- API 401 认证错误排查
参考资料
- Anthropic：OpenAI SDK 兼容性（platform.claude.com）
- Anthropic：认证方式与 API Key（platform.claude.com）
- Anthropic：API 概览（platform.claude.com）
- Anthropic：工具调用流程（platform.claude.com）
- Anthropic：消息流式响应（platform.claude.com）
- Anthropic：Thinking 能力（platform.claude.com）
- Anthropic：API 错误（platform.claude.com）
- OpenAI：API Reference 概览
- OpenAI：迁移到 Responses API
- OpenAI：Chat Completions 参考
- OpenAI：Chat 流式事件
- OpenAI：流式响应指南