OpenAI 兼容和 Anthropic 兼容是两种不同的大模型 API 接口协议规范，虽然它们都用于对话式补全（chat completion），但在 HTTP 层面的契约完全不同，不能简单通过替换 URL 来互通。以下是核心区别：
接口端点（URL 路径）
- OpenAI 兼容：基路径通常带
/v1，核心接口为/v1/chat/completions、/v1/embeddings等。 - Anthropic 兼容：路径与 Anthropic Messages API 一致，通常为
/v1/messages，与 OpenAI 的 URL 体系不混用同一套资源树。
系统提示（System Prompt）的设置方式
- OpenAI 兼容：
system提示作为messages数组中的一个元素，使用role: "system"来标识。 - Anthropic 兼容：
system是一个独立的顶层字段，与messages数组分离。
鉴权方式
- OpenAI 兼容：使用
Authorization: Bearer <token>头部。 - Anthropic 兼容：使用
x-api-key头部，并常配合anthropic-version（或等价头字段）。
请求体结构差异
- OpenAI 兼容：
messages中广泛使用role: system | user | assistant；字段名如model、temperature、tools、tool_choice等遵循 OpenAI 文档约定。 - Anthropic 兼容：同样使用
messages，但max_tokens为必选字段（OpenAI 中可选）；工具调用（tool use）的 JSON 结构与 OpenAI 不一一对应，例如 Anthropic 使用input_schema而非 OpenAI 的parameters。
流式输出（Streaming）格式
- OpenAI 兼容：基于 SSE（Server-Sent Events），数据片段中常见
choices[0].delta.content结构。 - Anthropic 兼容：流式事件类型、正文块（content block）、
stop_reason、用量字段等与 OpenAI 的字段名和层级不同，解析代码需按协议分别编写。
高级参数支持
| 参数 | OpenAI | Anthropic |
|---|---|---|
tool_choice |
支持auto、required、指定工具，控制更细粒度 |
支持auto或指定工具，功能较简单 |
logprobs |
支持，返回 token 概率 | 不支持 |
presence_penalty/frequency_penalty |
支持 | 不支持 |
response_format（JSON 模式） |
原生支持 | 仅通过兼容层部分支持 |
extra_body（如 thinking） |
不适用 | 支持扩展参数，用于增强推理等 |
工具调用（Tool Use / Function Calling）
- OpenAI 兼容：使用
tool_calls字段，支持并行工具调用，JSON 模式输出有严格保证。 - Anthropic 兼容：工具调用信息嵌入在
content中的tool_use块里，strict参数被忽略，JSON 输出不保证严格遵循 schema。
为什么需要两套兼容入口？
多数模型聚合网关会同时提供两套入口，主要原因包括：
- 对齐既有客户端：大量 SDK、Agent 框架（如 LangChain、Dify）默认按其中一种协议编写，分设入口让用户只需替换
base_url和密钥即可复用原有代码。 - 避免语义强扭：两家在 system 提示、工具调用、多模态、流式增量等能力的演进路径不完全一致，强行统一会丢失信息或增加网关映射复杂度。
- 生态路径依赖：OpenAI 先发推广了「HTTP + JSON 的 Chat Completions」用法，教程和示例默认多是 OpenAI 格式；而 Claude 生态（如 Claude Code、Cline）则默认使用 Anthropic 格式。
如果你刚开始做 Demo 或对接 LangChain/LlamaIndex 等框架，优先选 OpenAI 兼容（生态最广、示例最多、迁移成本最低）；如果需要直接使用 Claude 的原生特性（如超长上下文、thinking 推理等），则选 Anthropic 兼容。通过中转平台可以实现协议自动转换，但可能无法透传所有原生参数。