Anthropic 原生协议与 OpenAI 兼容协议有什么区别？中转排错指南

两套协议解决的是同一类需求，但并不相同

Anthropic Messages 与 OpenAI Chat Completions 都能发送对话并接收模型结果，所以许多中转宣称“兼容两种协议”。兼容不代表字段可以随意混用。大量 401、404、流式解析失败和工具调用异常，根源不是 Key 失效，而是请求路径、鉴权头或消息结构用错。

核心差异速查

中转可能允许同一个 Key 使用两套入口，也可能只支持其中一种。先看服务商文档，再用最小请求验证，不要根据域名或 Key 前缀猜协议。

为什么会出现 401

把 Anthropic Key 放进 Bearer 头、或者把 OpenAI 兼容 Key 放进 x-api-key，都可能得到 401。某些网关同时接受两种头，但只把其中一种传给上游；另一些网关会返回自定义中文错误，使问题看起来像余额不足。

排查时固定请求体，只交换鉴权方式；同时保存响应状态、content-type 和错误 JSON。若其中一种稳定成功，就把客户端配置锁定到该协议，不要继续依赖自动猜测。

为什么会出现 404

404 常见于 Base URL 拼接错误。例如配置里已经包含 /v1，SDK 又自动追加 /v1/messages，最终形成重复路径；或者网关只暴露 /v1/chat/completions，却收到 /v1/messages。

将最终请求 URL 打印出来，比反复更换 Key 更有效。还要区分“路径不存在”和“模型不存在”：两者可能都返回 404，但错误体字段通常不同。

流式输出不能只做字符串转发

Anthropic 原生流包含消息、内容块和增量等不同事件，工具输入也可能分多次到达。OpenAI 兼容流则通常在 choices[].delta 中累积内容。简单地把事件名前缀替换掉，会丢失 usage、stop reason、thinking block 或工具参数边界。

验证流式兼容时至少检查：第一块是否能解析、工具参数是否完整拼接、结束事件是否唯一、连接关闭后是否得到最终 usage。前端“看起来一直在打字”不代表协议完整。

工具调用转换是高风险区

两套协议对工具名称、参数 Schema、调用块和工具结果回传的表达不同。若中转转换不完整，常见表现是模型把 {"city":"Shanghai"} 当普通文本输出，或者第一轮能发起工具，第二轮无法识别工具结果。

测试时定义一个确定性工具，明确要求必须调用，并检查完整的两轮链路：模型提出调用、客户端返回结果、模型基于结果完成回答。只看到第一轮工具名还不够。

自动探测应该怎么理解

自动探测一般会分别尝试少量协议请求，根据成功状态和返回结构选择后续路径。它能减少配置门槛，但无法修复一个只实现了部分兼容的网关。如果自动探测选择了 OpenAI 协议，而商家承诺原生 Anthropic，应继续用手工请求核对，而不是把“能返回”当成承诺已兑现。

推荐排查顺序

1. 打印最终 URL，排除 /v1 重复或缺失；
2. 用最小非流式请求确认鉴权和模型名；
3. 打开流式，检查事件和结束标志；
4. 加入确定性工具，跑完整两轮；
5. 再测试结构化输出、长上下文和多模态；
6. 对照一个已知可信接口，比较结构而不是文风。

CheckToken 的自动协议探测与结构检测适合快速完成第 2–5 步。出现错误时展开原始证据，通常可以判断问题属于协议、模型、上游还是能力转换。