优先选 OpenAI 兼容
当你的 SDK、编辑器或 CLI Agent 天然就是按 OpenAI 风格工作的。
想从现有 OpenAI 客户端最短迁移。
工具的第三方 Provider 路径明显就是 OpenAI 兼容。
更看重最小改动，而不是 Anthropic 原生字段。
OpenAI 与 Anthropic 接口差异
虽然它们都能通过 LingCoreX 接入，但这两种接口并不等价。真正影响生产行为的，是请求结构、缓存表达能力和错误语义。
最实际的接口差异
下面这些差异，最容易影响工具接入、可观测性和生产行为。
| 主题 | OpenAI 兼容 | Anthropic 原生 |
|---|---|---|
| 主接口 | /v1/chat/completions 或 /v1/responses | /v1/messages |
| 鉴权方式 | Authorization: Bearer | x-api-key |
| 消息结构 | OpenAI 风格 role/content JSON | Anthropic 原生 messages payload |
| 工具行为 | 取决于工具对 OpenAI 格式暴露到什么程度 | 更接近 Anthropic 原生语义 |
| 显式缓存控制 | 请求结构中不暴露 | 上游支持时可保留 Anthropic 原生缓存语义 |
| 错误解释 | 更接近 OpenAI 风格 | 更接近 Anthropic 风格 |
请求结构与语义差异
同一个模型都能打通，并不代表两条链路在边界行为上完全一致。
OpenAI 兼容路径最大的优势，是大多数 SDK、编辑器和 CLI Agent 都已经围绕它构建好了。
Anthropic 原生路径则更适合保留 Anthropic 客户端本身依赖的请求语义，尤其是和缓存控制相关的能力。
所以“请求能成功”不等于“所有原生能力都保留了下来”。客户端请求格式本身，仍然会塑造最终行为。
什么时候选哪种接口
先看调用方，再看模型，而不是反过来。
优先选 Anthropic 原生
当你需要调用方本身保留 Anthropic 原生请求语义。
你在用 Claude Code 或其他 Anthropic 原生客户端。
你希望缓存相关的原生行为被更完整地保留。
你的工作流依赖 Anthropic 原生请求能力，而不是仅仅“能调用到模型”。