New API 的协议转换能力：为什么它能用 Claude 官方 SDK 直连

问题的起点：三套「方言」

如果你的项目要同时用 OpenAI、Claude、Gemini，你会遇到这样的事：同一个功能，三家接口写三遍。

差异不在参数名字这种表面层，而在三个更深的地方：

一、消息结构

OpenAI：messages 数组，system 是其中一条 role 为 system 的消息。 Anthropic：system 是顶层独立字段，不在 messages 里；messages 只能有 user / assistant。 Gemini：contents 数组，role 是 user / model（注意是 model 不是 assistant），而且不支持交替以外的消息排列。

二、流式响应格式

OpenAI：SSE，每个 chunk 是 data: {...}，以 data: [DONE] 结束。 Anthropic：SSE 但事件类型是分层的（message_start / content_block_delta / message_stop 等），delta 结构也不同。 Gemini：又是另一套。

三、函数调用 / 工具描述

OpenAI：tools + tool_choice，返回 tool_calls。 Anthropic：tools 结构不同，返回的是 content 数组里的 tool_use 块。 Gemini：functionDeclarations。

协议转换在转什么

所谓「协议抹平」，就是把上面三件事双向翻译。以 New API 为例，它提供的是多向转换，而不是单向归一：

• OpenAI 格式 ↔ Claude messages 格式
• OpenAI 格式 → Gemini
• Gemini → OpenAI 格式

关键差别在于「能不能反过来」：

第二、三行是实质价值：你的客户端可以完全不改，只换 base_url。

对 Claude Code 这类只认 Anthropic 协议的客户端尤其重要 —— 它不接受 OpenAI 格式的端点，如果网关只做单向归一，你就必须额外跑一个转换代理。

转换最容易出问题的三个地方

这三点不是理论风险，是实际排查中最常见的三类故障：

1. 流式分块的对齐

不同上游的 SSE 分块粒度不同。有的按 token 流，有的攒一批再发。转换层如果按「一个上游 chunk 对一个输出 chunk」来写，会出现：

• 输出里出现重复 token（增量没算对）
• 输出缺字（多字节字符被切在两个 chunk 之间）

测试方法：让模型输出一段包含中文、emoji、代码块的混合内容，观察是否出现乱码或重复。这是最有效的单点测试。

2. 工具调用的协议漂移

Anthropic 的 tool_use 块和 OpenAI 的 tool_calls 结构差异较大，转换时如果对 input（Claude）与 arguments（OpenAI，是 JSON 字符串）的处理不一致，会出现：

• 工具在测试里成功、在真实会话里静默地把参数写坏
• 多轮工具调用时上下文丢失

行业里讨论 Claude Code 路由器时反复提到的一句经验是：优先选「请求透传、最少改写」的实现。改写越多，协议漂移的风险越高。

3. 参数的静默丢弃

上游不支持某个参数时，有两种处理：报错，或者悄悄忽略。

忽略更危险 —— 你以为设置了 temperature: 0、实际上按默认值跑了；你以为开了 response_format、其实没有约束。这类问题不会报错，只会让结果「时好时坏」。

测试方法：故意传一个非法值（如 temperature: 99），观察返回的是错误还是正常结果。返回正常结果，说明这个参数被忽略了。

对使用者的实际意义

如果你在选站

「支持 Claude 原生协议」是一个值得单独确认的能力项。判断方法很简单：用 Anthropic 官方 SDK，把 base_url 指向它，调一次。能通，说明它做了真转换；报 404 或结构错误，说明它只做单向归一。

如果你在自建

New API 在这个维度上的能力是它相对 One API 最实在的差异。如果你的使用方包括 Claude Code、Cursor、任何原生 Anthropic 协议的客户端，这个能力会直接省掉一层代理。

如果你在排查问题

遇到「同一个 prompt 换一家站结果不同」时，先别怀疑模型。按「流式对齐 → 工具调用 → 参数丢弃」的顺序查一遍，这三类问题的概率远高于模型差异。

本站的《常见报错对照表》与《怎么判断是谁的问题》两篇可以配合本篇使用。