先交代下背景。我从 2023 年开始做 LLM 应用去年接了一批 AI 聚合接口平台的项目其中一个叫 OpenMove 的平台让我印象挺深。2026 年这个时间点市面上的聚合接口平台已经多到眼花缭乱但很多人的理解还停留在“把各家模型 API 打包成一个 key”上。实际上聚合平台的生死线不在模型多不多而在协议兼容性你用 OpenAI SDK 写好的代码能不能一行不改切到 Anthropic、Google、甚至其它厂商的模型上这次横评我重点测了 OpenMove 和另外三家同类平台下文用代号 AP、UAG、RelayX围绕 OpenAI、Anthropic、Google Gemini 三大主流请求协议做了五个维度的实测。结果挺有意思能连通的平台不少但能在流式、工具调用、错误码这些细节上做到“无感切换”的真不多。下面把我完整的评测过程、踩坑记录和选型建议都整理出来。不管你是自己搭个内部网关还是准备给团队选型这篇应该都能帮你省掉不少试错时间。1. 聚合接口平台到底在解决什么问题1.1 一个让人抓狂的老问题做 AI 应用的人应该都有这种体验项目一开始只接 OpenAI代码里全是 openai 库的调用习惯messages 数组、tool_calls、temperature、max_tokens 都写得行云流水。结果有一天老板说“换 Claude 试试”你打开 Anthropic 的文档才发现system 要单独提出来消息角色没有 assistant 的 tool 调用结构参数名也完全不一样。等你好不容易改完产品又说 Gemini 有个新模型效果不错你看着满屏的contents、parts、generationConfig只想把电脑摔了。这个问题不是哪一家做得不好而是各家大模型厂商的 API 风格差异实在太大。OpenAI 走的是“一个 messages 数组走天下”的路线Anthropic 把 system 单独拆开Google Gemini 把多模态内容塞进 parts 里参数命名也是各说各话。如果每个模型都要写一套适配层那项目的维护成本会指数级上升。聚合接口平台想解决的就是这件事让上层应用只认一套协议底层模型随便切换。OpenMove 这类平台本质上是个中转网关你按 OpenAI 的格式把请求发过去它负责翻译成 Anthropic 或 Gemini 的格式再把响应翻译回来。理想状态下你的业务代码几乎不用动只需要改一下 base_url 和模型名。1.2 OpenMove 这类平台在生态里的位置如果画一条数据链路大概是这样的你的应用/客户端 │ ▼ SDKopenai / anthropic / google-genai │ ▼ 聚合接口平台OpenMove / AP / UAG / RelayX │ ▼ 各家大模型原生 API注意中间那层 SDK 很关键。聚合平台不是为了替代官方 SDK而是让官方 SDK 变成统一入口。OpenMove 的做法是直接兼容多套协议你可以用 openai 库指向它的 OpenAI 兼容端点也可以把它的 Anthropic 兼容端点配到 claude 的 SDK 里甚至可以直接用 google-genai 库调 Gemini 兼容端点。这和我几年前用的 API 网关不太一样它不是简单的流量代理而是做了完整的协议翻译层。这种架构最大的好处是业务代码和模型供应商解耦了。你今天觉得 Claude 贵想切到便宜的开源模型明天想试试 Gemini 的长上下文只需要在后端配置中心改一个模型路由应用端不用发版。对团队来说这就是一种 AI 基础设施层面的“降本增效”。不过平台多了问题也来了协议兼容不是嘴上说说那么简单真正的兼容性体现在各种边界场景里。这也是我这次横评的出发点。2. 横评对象与评测方法不只看速度更看协议兼容2.1 参与横评的平台清单为了避免广告嫌疑我统一用代号。OpenMove 是这次的主角另外三个是市面上有一定用户量的同类平台。代号核心定位主打卖点备注OpenMove全协议聚合协议翻译层做得细支持多种 SDK 直连重点评测对象AP轻量中转便宜、速度快主打个人开发者适合单模型调用聚合能力一般UAG企业级网关权限、审计、用量报表完善配置复杂度高学习成本高RelayX社区型聚合模型多更新快稳定性波动较大文档较散我选这四家是因为它们基本代表了当前聚合平台的几个流派。OpenMove 属于“协议兼容优先”的一类AP 属于“便宜大碗”的一类UAG 典型的是做企业服务的RelayX 更接近社区玩家。横评不是要分个谁高谁低而是要看出不同类型平台在协议兼容上的取舍。2.2 三大协议具体指哪三个这次说的“3 大协议”是指当下应用接入最频繁的三套大模型 API 规范第一种是OpenAI Chat Completions 协议。核心端点是/v1/chat/completions请求体里主要是messages数组每个 message 有role和content函数调用走tools和tool_calls响应里的流式内容通过 SSE 的data:逐段输出。第二种是Anthropic Messages API。端点是/v1/messages和 OpenAI 最大的区别是system单独作为一个顶层参数消息里的content可以是字符串也可以是内容块数组工具调用用的是tool_use和tool_result块。流式响应的事件类型也完全不同比如content_block_delta、message_delta。第三种是Google Gemini API。端点是/v1beta/models/{model}:generateContent数据结构里没有messages而是contents里面是role和parts数组。参数也不是temperature、max_tokens而是包在generationConfig里叫candidateCount、maxOutputTokens等。这三套协议就像中文、日文、韩文都用了大量汉字但语法和用词规则完全不同。聚合平台要做的就是在它们之间做一套“同声传译”还得保证语气、情绪都别丢。2.3 评测维度与打分方法我这次没有单纯测“响应快不快”而是把协议兼容拆成五个维度基础文本兼容普通多轮对话看请求能否被正确翻译响应能否被正确还原。流式输出兼容SSE 流是否能正常逐字输出结束事件是否正确客户端会不会卡住。工具调用兼容function calling / tool calling 的参数定义、触发方式、结果回传是否完整。扩展参数兼容比如多模态图片输入、JSON 输出、超参映射等。错误码与鉴权兼容模型不存在、鉴权失败、限流、上下文超长时返回的错误信息是否贴近原生协议。每个维度按 10 分制打分总分 50。最后再用真实业务场景做一次冒烟测试验证分数和实际体验是否一致。有人可能会问为什么不测价格和速度价格不是协议兼容的范畴而且各家平台经常调整测了也容易过时速度则和底座链路、目标模型有关单独比聚合层意义不大。我这次只在同一个目标模型上记录了 P95 首字延迟做一个参考性的辅助指标。3. 实测过程三个协议的真实调用记录3.1 测试环境准备我用了 Python 3.11装了官方四个 SDKopenai、anthropic、google-genai以及httpx用来抓原始请求日志。统一用一个简单的企业知识问答 prompt 做文本测试用“查询天气并调用接口”的场景做工具调用测试。四个平台的接入方式大同小异核心都是替换 base_url 和 API key。区别在于 OpenMove 提供了三种不同的兼容端点而其它平台大多只提供 OpenAI 兼容端点。这一点在后续测试里影响非常大。先看一段 OpenMove 的配置示意。用环境变量管理密钥这是最基本的习惯。export OPENMOVE_API_KEYyour_openmove_key export OPENMOVE_OPENAI_BASEhttps://api.open-move.example/v1 export OPENMOVE_ANTHROPIC_BASEhttps://api.open-move.example/anthropic export OPENMOVE_GEMINI_BASEhttps://api.open-move.example/gemini注意看OpenMove 对三个协议分别开了不同的 base path这是它和其它“只兼容 OpenAI 协议”平台最大的不同。后面我会解释这个设计为什么更实用。3.2 场景一用 OpenAI SDK 调用 Anthropic 模型这个场景非常典型你代码里全是 openai 库的写法但现在想看 Claude 的效果。传统做法是改代码、换库在 OpenMove 上可以直接这样写from openai import OpenAI client OpenAI( api_keyos.getenv(OPENMOVE_API_KEY), base_urlos.getenv(OPENMOVE_OPENAI_BASE) ) resp client.chat.completions.create( modelclaude-sonnet-4-2026, # 平台侧映射到的 Anthropic 模型 messages[ {role: system, content: 你是一名企业知识助手。}, {role: user, content: 请用一句话介绍 API 网关的作用。} ], temperature0.3, max_tokens300 ) print(resp.choices[0].message.content)这段代码唯一的“非标”之处就是模型名。不用改消息结构不用管 Anthropic 的 system 参数OpenMove 会把请求翻译过去。我实测了基础回答和工具调用两种请求OpenMove 都能正确把 OpenAI 风格的tools转成 Anthropic 风格的tools响应里的tool_calls也会转换回 OpenAI 格式。相比之下AP 平台虽然也支持modelclaude-...但它实际是在后端调 Claude 的 HTTP API 再自己包一层遇到工具调用的嵌套对象时偶尔会把input_schema里的 JSON Schema 字段丢掉。这个坑我后面细说。3.3 场景二用 Anthropic SDK 调用 OpenAI 模型反向场景同样重要。有些团队本来用的是 Claude现在想让业务跑在 GPT 或开源模型上但又不想推翻整条链路的 SDK 调用习惯。在 OpenMove 下我把 base_url 指到它的 Anthropic 兼容端点import anthropic client anthropic.Anthropic( api_keyos.getenv(OPENMOVE_API_KEY), base_urlos.getenv(OPENMOVE_ANTHROPIC_BASE) ) resp client.messages.create( modelgpt-5.2-2026, # 平台侧映射到的 OpenAI 模型 max_tokens300, system你是一名知识助手。, messages[ {role: user, content: 给出一句关于协议兼容性的比喻。} ] ) print(resp.content[0].text)这里有个细节值得注意。anthropicSDK 会把system单独放进请求的system字段OpenMove 收到后需要把它合并或转成 OpenAI 的 system message再从响应里把 OpenAI 的choices[0].message.content还原成 Anthropic 的content数组格式。我在日志里观察过OpenMove 对这部分的转换是完整的content 数组里的type: text块也保留下来了。而 UAG 在这个场景里反而出了问题。它的 Anthropic 兼容端点文档里写的是“Beta”实测时流式输出的事件名称没有完全对齐 Anthropic 规范导致我本地用官方 SDK 解析时抛了异常。后来查下来是它把message_delta里的stop_reason给漏了客户端收不到“结束”信号一直不 return。这种问题在单次请求里很难暴露一上流式就原形毕露。3.4 场景三用 Gemini SDK 调用聚合平台的统一出口Gemini 的 API 风格和前两者差异最大。以前想在一个项目里同时用 Gemini 和 OpenAI基本得写两套客户端逻辑。OpenMove 的解决方案是提供 Gemini 兼容端点让已有的google-genai代码能直接走聚合层。from google import genai client genai.Client( api_keyos.getenv(OPENMOVE_API_KEY), http_options{base_url: os.getenv(OPENMOVE_GEMINI_BASE)} ) resp client.models.generate_content( modelopenai-gpt-5.2-2026, contents用一句话解释 Protocol Buffers。 ) print(resp.text)这里有个很微妙的点如果目标模型是 OpenAI 系OpenMove 需要在 Gemini 协议的contents格式和 OpenAI 的messages格式之间互转。contents里的 user 角色好办但多轮对话里 assistant 的回复如果带了 function call转换就会复杂很多。我的测试里把 temperature、maxOutputTokens 都传进generationConfigOpenMove 能正确映射到 OpenAI 的对应参数这一点做得比较干净。RelayX 的 Gemini 兼容端点也测了结果却不理想。它的文档里写“支持”实际调用时经常返回 400错误信息是unsupported parameter: safetySettings。也就是说它并没有做完整参数过滤而是把 Gemini 原生请求直接转发给了一个默认模型原生参数一旦落到 OpenAI 模型上就报错。这属于典型的“半兼容”。4. 兼容性实测结果能通只是基础细节全是坑4.1 协议转换的成功率与差异整个测试下来我整理了下面这张汇总表。每一项都是实际跑过的不是看文档得出的结论。测试项OpenMoveAPUAGRelayX普通多轮文本通过通过通过通过流式输出OpenAI SDK通过通过通过通过流式输出Anthropic SDK通过失败失败失败流式输出Gemini SDK通过不支持通过失败工具调用定义与触发通过部分丢字段通过通过工具结果回传后二次请求通过部分丢失通过失败多模态图片输入通过失败通过部分通过JSON 输出格式通过通过通过通过错误码映射规范不规范一般不规范鉴权失败提示通过通过通过通过从这个表能看出来基础文本兼容几乎人人都会但一到流式、工具调用、多模态这些偏门场景差距就拉开了。OpenMove 是唯一一个在三个协议的流式测试里全部通过的平台。其它平台要么是不支持某个协议端点要么是支持但细节没有对齐。4.2 OpenMove 在“细节兼容”上的表现OpenMove 给我留下最深印象的不是“能不能通”而是它对参数映射的细节处理。举个具体的例子OpenAI 的max_tokens到了 Gemini 那边要变成maxOutputTokens如果映射漏了模型会默默用默认值这在小模型上可能没什么感觉但在需要精确控制输出长度的金融、法务场景里直接会导致结果被截断。它另一个做得好的地方是 system prompt 的处理。OpenAI 允许system和developer两种角色Anthropic 只有一个system字段Gemini 甚至通常把 system 指令放在system_instruction里。OpenMove 在转换时会做合并和拆分而不是简单地把 system role 当成普通消息丢掉。我在日志里验证过多轮对话里 system 信息不会被后续 user 消息覆盖。还有一个细节是工具调用。很多平台在把 OpenAI 的tool_calls翻译成 Anthropic 的tool_use块时只翻译了第一层导致嵌套对象的input字段丢失。OpenMove 在这个地方做了递归转换我在测试工具里传了一个带复杂 JSON Schema 的“天气查询工具”返回的 tool 参数结构和原生调用完全一致。4.3 其它平台的槽点前面也提到了不少这里集中说一下。AP 的问题是“半兼容”。它只提供一个 OpenAI 兼容端点Anthropic 和 Gemini 的 SDK 都接不了。如果你只是个人用 OpenAI 体系它足够便宜但想切协议基本就得重写代码。它的工具调用有时会丢字段我连续测了五次有两次input_schema里的enum丢失这个问题在联调时非常难排查因为不是必现而是偶发。UAG 的企业功能很全但协议兼容端点的文档更新滞后。它的 Anthropic 兼容端点标了 Beta实测也确实不稳定流式事件缺失就是很典型的表现。对团队来说这不是说不能用而是需要预留额外的兼容层修复时间。RelayX 更像一个“社区集合”好处是模型种类多、上新快坏处是协议兼容完全靠社区贡献质量参差不齐。Gemini 端点不支持safetySettings只是冰山一角我还遇到过 Gemini 端点在 tool 调用时返回的 finishReason 和原生 API 不一致造成客户端误判。5. 协议兼容性背后的原理一次翻译N端适配5.1 协议转换不是“改个 URL”那么简单很多人以为聚合平台就是一层反向代理把请求 URL 改一下转发出去再把响应原样返回。实际上协议转换要处理的东西远比想象中多。请求侧至少要做三层工作。第一层是端点路由不同协议对应不同路径第二层是参数映射同一个语义的参数在不同协议里叫法不同第三层是消息结构转换把数组、嵌套块、角色定义全部重塑。响应侧也一样要把目标模型返回的数据重新组装成调用方协议的样子同时还不能丢字段。可以把它理解成一个翻译团队不仅要把中文翻译成英文还要把成语、双关语、文化背景都解释清楚。比如 OpenAI 的finish_reason有stop、length、tool_callsAnthropic 的stop_reason有end_turn、max_tokens、tool_use两者不是一一对应翻译时需要有规则映射而不是简单地照抄。5.2 流式兼容的难点流式是最容易暴露协议兼容问题的环节因为它是持续性的不是一次请求一次响应。客户端要和平台之间建立一条 SSE 长连接平台要和目标模型之间再建立一条连接中间还要做逐段翻译。OpenAI 的流式事件一般是choices[0].delta.contentAnthropic 是content_block_delta的delta.textGemini 是candidates[0].content.parts里的text。翻译层需要在每个 chunk 到达时做结构替换还得保持顺序。更麻烦的是结束信号OpenAI 的流式结束靠finish_reasonAnthropic 靠message_delta里的stop_reasonGemini 靠finishReason。如果一个平台只翻译了内容块忘了翻译结束信号客户端的for await循环就会一直等下去看起来就是“卡住不动”。OpenMove 在处理流式时还做了一件事它会透传 usage 信息而不是像有些平台那样偷偷丢掉。这对做 token 计费、用量统计的应用来说非常重要。5.3 参数映射表我把三个协议里最常见的参数映射关系整理了一下聚合平台如果没有按照下面这张表的逻辑去实现基本可以判断为不合格。语义OpenAIAnthropicGeminiOpenMove 映射情况最大生成 Token 数max_tokensmax_tokensmaxOutputTokens有映射温度temperaturetemperaturegenerationConfig.temperature有映射采样概率top_ptop_ptopP有映射系统指令messages 中 rolesystemsystem 字段system_instruction.contents合并/拆分多轮消息messages 数组messages 数组contents 数组有转换工具定义toolstoolstools / functionDeclarations有转换工具调用结果tool 角色消息tool_result 内容块functionResponse part有转换停止符stopstop_sequencesstopSequences有映射从这个表能看出来刚提到的这些参数在语义上基本是共通的只是外衣不一样。一个合格的聚合平台要做的不是“尽量兼容”而是“每一个参数都映射到位”。只要有一项漏了边界场景就会翻车。6. 选型建议与避坑清单6.1 什么场景适合用聚合接口平台经过这轮横评我的结论是不要盲目上聚合平台先看自己的使用场景。如果你是个人开发者或者小团队正在做原型验证模型切换频繁那 OpenMove 这类协议兼容做得好的平台非常合适。你可以在一天内把同一个应用分别接到 GPT、Claude、Gemini 上对比效果这比单独申请各家 API 再写适配层快太多了。如果你的业务已经稳定跑在某个单一模型上而且没有短期内切换模型的计划那直接调官方 API 反而是最稳的选择。多一层转发就多一层风险没必要为了“可能的需求”提前引入复杂架构。但如果你是在做 toB 产品需要同时服务多个客户、多个模型或者你要把模型能力卖给下游开发者那协议兼容聚合平台几乎是必需品。你的客户不可能都用同一套 SDK你需要给不同的客户提供不同的接入协议OpenMove 这种“三协议同时兼容”的方案就有明显优势。6.2 我踩过的坑和排查技巧这轮测试里我也踩了不少坑挑几个典型的分享出来。第一个坑是模型名写错导致 404 而不是 400。有些平台在模型不存在时返回 404但错误信息里没有目标模型名排查起来特别慢。我后来统一在客户端打印model字段至少能确认是聚合层映射问题还是密钥问题。第二个坑是流式环境下的代理干扰。测试 RelayX 时流式中断我一直以为是平台问题后来才发现是我本地抓包工具把 SSE 的 chunk 缓冲了。排查的时候先把抓包工具关掉用最简单的httpx脚本直接读原始响应确认平台侧没问题再上 SDK。第三个坑是工具调用结果的二次请求失败。Anthropic 的工具调用流程里模型返回tool_use后你需要把用户实际执行的工具结果用tool_result内容块传回去。有些聚合平台只做了第一次转换没有把tool_result再转回 OpenAI 的 tool role message导致第二轮请求失败。这个问题在 OpenMove 上没出现但在 RelayX 上必现测试时一定要跑完整的多轮工具调用链路。第四个坑是用量统计对不上。聚合平台上报的 token 用量经常和模型官方返回的不一致这可能是转换过程中自己重新计算了 token也可能是丢了 usage 字段。如果是计费敏感的业务建议以目标模型官方日志为准不要让聚合平台直接参与出账。6.3 选型时可以重点关注的四个能力最后给一个可以直接抄作业的选型清单第一看它是否提供多个协议的 SDK 兼容端点而不只是 OpenAI 兼容端点。这是能不能做到“代码不用大改”的基础。第二用一个小工具函数测三轮完整的工具调用链路而不是只测单轮对话。很多平台死在这一步。第三对比流式输出时的结束事件是否完整。可以写一个三分钟脚本记录从发起请求到流结束的原始事件确认没有漏事件。第四看一下错误码映射。模型限流、上下文超长、鉴权失败这些常见错误返回给客户端时是否符合你所使用 SDK 的异常解析规则。我自己在实际选型时会先把目标模型列表和协议类型列出来再根据这张表打分。OpenMove 这轮的评分是 49 分扣掉的 1 分在于它的控制台自定义模型路由配置首次使用时入口有点隐蔽需要点进“高级设置”才能找到。但对最终要写代码的人来说这不是大问题。这次横评最大的体会就是协议兼容性这东西文档上写着“支持”只代表能连通不等于细节完整。真正决定一个聚合平台能不能省心要看那些平时不会写进宣传页的地方。后面我还会再测一测这些平台的私有化部署方案到时候再来分享。