先交代下背景。我從 2023 年開始做 LLM 應(yīng)用去年接了一批 AI 聚合接口平臺的項(xiàng)目其中一個叫 OpenMove 的平臺讓我印象挺深。2026 年這個時間點(diǎn)市面上的聚合接口平臺已經(jīng)多到眼花繚亂但很多人的理解還停留在“把各家模型 API 打包成一個 key”上。實(shí)際上聚合平臺的生死線不在模型多不多而在協(xié)議兼容性你用 OpenAI SDK 寫好的代碼能不能一行不改切到 Anthropic、Google、甚至其它廠商的模型上這次橫評我重點(diǎn)測了 OpenMove 和另外三家同類平臺下文用代號 AP、UAG、RelayX圍繞 OpenAI、Anthropic、Google Gemini 三大主流請求協(xié)議做了五個維度的實(shí)測。結(jié)果挺有意思能連通的平臺不少但能在流式、工具調(diào)用、錯誤碼這些細(xì)節(jié)上做到“無感切換”的真不多。下面把我完整的評測過程、踩坑記錄和選型建議都整理出來。不管你是自己搭個內(nèi)部網(wǎng)關(guān)還是準(zhǔn)備給團(tuán)隊(duì)選型這篇應(yīng)該都能幫你省掉不少試錯時間。1. 聚合接口平臺到底在解決什么問題1.1 一個讓人抓狂的老問題做 AI 應(yīng)用的人應(yīng)該都有這種體驗(yàn)項(xiàng)目一開始只接 OpenAI代碼里全是 openai 庫的調(diào)用習(xí)慣messages 數(shù)組、tool_calls、temperature、max_tokens 都寫得行云流水。結(jié)果有一天老板說“換 Claude 試試”你打開 Anthropic 的文檔才發(fā)現(xiàn)system 要單獨(dú)提出來消息角色沒有 assistant 的 tool 調(diào)用結(jié)構(gòu)參數(shù)名也完全不一樣。等你好不容易改完產(chǎn)品又說 Gemini 有個新模型效果不錯你看著滿屏的contents、parts、generationConfig只想把電腦摔了。這個問題不是哪一家做得不好而是各家大模型廠商的 API 風(fēng)格差異實(shí)在太大。OpenAI 走的是“一個 messages 數(shù)組走天下”的路線Anthropic 把 system 單獨(dú)拆開Google Gemini 把多模態(tài)內(nèi)容塞進(jìn) parts 里參數(shù)命名也是各說各話。如果每個模型都要寫一套適配層那項(xiàng)目的維護(hù)成本會指數(shù)級上升。聚合接口平臺想解決的就是這件事讓上層應(yīng)用只認(rèn)一套協(xié)議底層模型隨便切換。OpenMove 這類平臺本質(zhì)上是個中轉(zhuǎn)網(wǎng)關(guān)你按 OpenAI 的格式把請求發(fā)過去它負(fù)責(zé)翻譯成 Anthropic 或 Gemini 的格式再把響應(yīng)翻譯回來。理想狀態(tài)下你的業(yè)務(wù)代碼幾乎不用動只需要改一下 base_url 和模型名。1.2 OpenMove 這類平臺在生態(tài)里的位置如果畫一條數(shù)據(jù)鏈路大概是這樣的你的應(yīng)用/客戶端 │ ▼ SDKopenai / anthropic / google-genai │ ▼ 聚合接口平臺OpenMove / AP / UAG / RelayX │ ▼ 各家大模型原生 API注意中間那層 SDK 很關(guān)鍵。聚合平臺不是為了替代官方 SDK而是讓官方 SDK 變成統(tǒng)一入口。OpenMove 的做法是直接兼容多套協(xié)議你可以用 openai 庫指向它的 OpenAI 兼容端點(diǎn)也可以把它的 Anthropic 兼容端點(diǎn)配到 claude 的 SDK 里甚至可以直接用 google-genai 庫調(diào) Gemini 兼容端點(diǎn)。這和我?guī)啄昵坝玫?API 網(wǎng)關(guān)不太一樣它不是簡單的流量代理而是做了完整的協(xié)議翻譯層。這種架構(gòu)最大的好處是業(yè)務(wù)代碼和模型供應(yīng)商解耦了。你今天覺得 Claude 貴想切到便宜的開源模型明天想試試 Gemini 的長上下文只需要在后端配置中心改一個模型路由應(yīng)用端不用發(fā)版。對團(tuán)隊(duì)來說這就是一種 AI 基礎(chǔ)設(shè)施層面的“降本增效”。不過平臺多了問題也來了協(xié)議兼容不是嘴上說說那么簡單真正的兼容性體現(xiàn)在各種邊界場景里。這也是我這次橫評的出發(fā)點(diǎn)。2. 橫評對象與評測方法不只看速度更看協(xié)議兼容2.1 參與橫評的平臺清單為了避免廣告嫌疑我統(tǒng)一用代號。OpenMove 是這次的主角另外三個是市面上有一定用戶量的同類平臺。代號核心定位主打賣點(diǎn)備注OpenMove全協(xié)議聚合協(xié)議翻譯層做得細(xì)支持多種 SDK 直連重點(diǎn)評測對象AP輕量中轉(zhuǎn)便宜、速度快主打個人開發(fā)者適合單模型調(diào)用聚合能力一般UAG企業(yè)級網(wǎng)關(guān)權(quán)限、審計(jì)、用量報表完善配置復(fù)雜度高學(xué)習(xí)成本高RelayX社區(qū)型聚合模型多更新快穩(wěn)定性波動較大文檔較散我選這四家是因?yàn)樗鼈兓敬砹水?dāng)前聚合平臺的幾個流派。OpenMove 屬于“協(xié)議兼容優(yōu)先”的一類AP 屬于“便宜大碗”的一類UAG 典型的是做企業(yè)服務(wù)的RelayX 更接近社區(qū)玩家。橫評不是要分個誰高誰低而是要看出不同類型平臺在協(xié)議兼容上的取舍。2.2 三大協(xié)議具體指哪三個這次說的“3 大協(xié)議”是指當(dāng)下應(yīng)用接入最頻繁的三套大模型 API 規(guī)范第一種是OpenAI Chat Completions 協(xié)議。核心端點(diǎn)是/v1/chat/completions請求體里主要是messages數(shù)組每個 message 有role和content函數(shù)調(diào)用走tools和tool_calls響應(yīng)里的流式內(nèi)容通過 SSE 的data:逐段輸出。第二種是Anthropic Messages API。端點(diǎn)是/v1/messages和 OpenAI 最大的區(qū)別是system單獨(dú)作為一個頂層參數(shù)消息里的content可以是字符串也可以是內(nèi)容塊數(shù)組工具調(diào)用用的是tool_use和tool_result塊。流式響應(yīng)的事件類型也完全不同比如content_block_delta、message_delta。第三種是Google Gemini API。端點(diǎn)是/v1beta/models/{model}:generateContent數(shù)據(jù)結(jié)構(gòu)里沒有messages而是contents里面是role和parts數(shù)組。參數(shù)也不是temperature、max_tokens而是包在generationConfig里叫candidateCount、maxOutputTokens等。這三套協(xié)議就像中文、日文、韓文都用了大量漢字但語法和用詞規(guī)則完全不同。聚合平臺要做的就是在它們之間做一套“同聲傳譯”還得保證語氣、情緒都別丟。2.3 評測維度與打分方法我這次沒有單純測“響應(yīng)快不快”而是把協(xié)議兼容拆成五個維度基礎(chǔ)文本兼容普通多輪對話看請求能否被正確翻譯響應(yīng)能否被正確還原。流式輸出兼容SSE 流是否能正常逐字輸出結(jié)束事件是否正確客戶端會不會卡住。工具調(diào)用兼容function calling / tool calling 的參數(shù)定義、觸發(fā)方式、結(jié)果回傳是否完整。擴(kuò)展參數(shù)兼容比如多模態(tài)圖片輸入、JSON 輸出、超參映射等。錯誤碼與鑒權(quán)兼容模型不存在、鑒權(quán)失敗、限流、上下文超長時返回的錯誤信息是否貼近原生協(xié)議。每個維度按 10 分制打分總分 50。最后再用真實(shí)業(yè)務(wù)場景做一次冒煙測試驗(yàn)證分?jǐn)?shù)和實(shí)際體驗(yàn)是否一致。有人可能會問為什么不測價格和速度價格不是協(xié)議兼容的范疇而且各家平臺經(jīng)常調(diào)整測了也容易過時速度則和底座鏈路、目標(biāo)模型有關(guān)單獨(dú)比聚合層意義不大。我這次只在同一個目標(biāo)模型上記錄了 P95 首字延遲做一個參考性的輔助指標(biāo)。3. 實(shí)測過程三個協(xié)議的真實(shí)調(diào)用記錄3.1 測試環(huán)境準(zhǔn)備我用了 Python 3.11裝了官方四個 SDKopenai、anthropic、google-genai以及httpx用來抓原始請求日志。統(tǒng)一用一個簡單的企業(yè)知識問答 prompt 做文本測試用“查詢天氣并調(diào)用接口”的場景做工具調(diào)用測試。四個平臺的接入方式大同小異核心都是替換 base_url 和 API key。區(qū)別在于 OpenMove 提供了三種不同的兼容端點(diǎn)而其它平臺大多只提供 OpenAI 兼容端點(diǎn)。這一點(diǎn)在后續(xù)測試?yán)镉绊懛浅４蟆Ｏ瓤匆欢?OpenMove 的配置示意。用環(huán)境變量管理密鑰這是最基本的習(xí)慣。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 對三個協(xié)議分別開了不同的 base path這是它和其它“只兼容 OpenAI 協(xié)議”平臺最大的不同。后面我會解釋這個設(shè)計(jì)為什么更實(shí)用。3.2 場景一用 OpenAI SDK 調(diào)用 Anthropic 模型這個場景非常典型你代碼里全是 openai 庫的寫法但現(xiàn)在想看 Claude 的效果。傳統(tǒng)做法是改代碼、換庫在 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, # 平臺側(cè)映射到的 Anthropic 模型 messages[ {role: system, content: 你是一名企業(yè)知識助手。}, {role: user, content: 請用一句話介紹 API 網(wǎng)關(guān)的作用。} ], temperature0.3, max_tokens300 ) print(resp.choices[0].message.content)這段代碼唯一的“非標(biāo)”之處就是模型名。不用改消息結(jié)構(gòu)不用管 Anthropic 的 system 參數(shù)OpenMove 會把請求翻譯過去。我實(shí)測了基礎(chǔ)回答和工具調(diào)用兩種請求OpenMove 都能正確把 OpenAI 風(fēng)格的tools轉(zhuǎn)成 Anthropic 風(fēng)格的tools響應(yīng)里的tool_calls也會轉(zhuǎn)換回 OpenAI 格式。相比之下AP 平臺雖然也支持modelclaude-...但它實(shí)際是在后端調(diào) Claude 的 HTTP API 再自己包一層遇到工具調(diào)用的嵌套對象時偶爾會把input_schema里的 JSON Schema 字段丟掉。這個坑我后面細(xì)說。3.3 場景二用 Anthropic SDK 調(diào)用 OpenAI 模型反向場景同樣重要。有些團(tuán)隊(duì)本來用的是 Claude現(xiàn)在想讓業(yè)務(wù)跑在 GPT 或開源模型上但又不想推翻整條鏈路的 SDK 調(diào)用習(xí)慣。在 OpenMove 下我把 base_url 指到它的 Anthropic 兼容端點(diǎn)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, # 平臺側(cè)映射到的 OpenAI 模型 max_tokens300, system你是一名知識助手。, messages[ {role: user, content: 給出一句關(guān)于協(xié)議兼容性的比喻。} ] ) print(resp.content[0].text)這里有個細(xì)節(jié)值得注意。anthropicSDK 會把system單獨(dú)放進(jìn)請求的system字段OpenMove 收到后需要把它合并或轉(zhuǎn)成 OpenAI 的 system message再從響應(yīng)里把 OpenAI 的choices[0].message.content還原成 Anthropic 的content數(shù)組格式。我在日志里觀察過OpenMove 對這部分的轉(zhuǎn)換是完整的content 數(shù)組里的type: text塊也保留下來了。而 UAG 在這個場景里反而出了問題。它的 Anthropic 兼容端點(diǎn)文檔里寫的是“Beta”實(shí)測時流式輸出的事件名稱沒有完全對齊 Anthropic 規(guī)范導(dǎo)致我本地用官方 SDK 解析時拋了異常。后來查下來是它把message_delta里的stop_reason給漏了客戶端收不到“結(jié)束”信號一直不 return。這種問題在單次請求里很難暴露一上流式就原形畢露。3.4 場景三用 Gemini SDK 調(diào)用聚合平臺的統(tǒng)一出口Gemini 的 API 風(fēng)格和前兩者差異最大。以前想在一個項(xiàng)目里同時用 Gemini 和 OpenAI基本得寫兩套客戶端邏輯。OpenMove 的解決方案是提供 Gemini 兼容端點(diǎn)讓已有的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)這里有個很微妙的點(diǎn)如果目標(biāo)模型是 OpenAI 系OpenMove 需要在 Gemini 協(xié)議的contents格式和 OpenAI 的messages格式之間互轉(zhuǎn)。contents里的 user 角色好辦但多輪對話里 assistant 的回復(fù)如果帶了 function call轉(zhuǎn)換就會復(fù)雜很多。我的測試?yán)锇?temperature、maxOutputTokens 都傳進(jìn)generationConfigOpenMove 能正確映射到 OpenAI 的對應(yīng)參數(shù)這一點(diǎn)做得比較干凈。RelayX 的 Gemini 兼容端點(diǎn)也測了結(jié)果卻不理想。它的文檔里寫“支持”實(shí)際調(diào)用時經(jīng)常返回 400錯誤信息是unsupported parameter: safetySettings。也就是說它并沒有做完整參數(shù)過濾而是把 Gemini 原生請求直接轉(zhuǎn)發(fā)給了一個默認(rèn)模型原生參數(shù)一旦落到 OpenAI 模型上就報錯。這屬于典型的“半兼容”。4. 兼容性實(shí)測結(jié)果能通只是基礎(chǔ)細(xì)節(jié)全是坑4.1 協(xié)議轉(zhuǎn)換的成功率與差異整個測試下來我整理了下面這張匯總表。每一項(xiàng)都是實(shí)際跑過的不是看文檔得出的結(jié)論。測試項(xiàng)OpenMoveAPUAGRelayX普通多輪文本通過通過通過通過流式輸出OpenAI SDK通過通過通過通過流式輸出Anthropic SDK通過失敗失敗失敗流式輸出Gemini SDK通過不支持通過失敗工具調(diào)用定義與觸發(fā)通過部分丟字段通過通過工具結(jié)果回傳后二次請求通過部分丟失通過失敗多模態(tài)圖片輸入通過失敗通過部分通過JSON 輸出格式通過通過通過通過錯誤碼映射規(guī)范不規(guī)范一般不規(guī)范鑒權(quán)失敗提示通過通過通過通過從這個表能看出來基礎(chǔ)文本兼容幾乎人人都會但一到流式、工具調(diào)用、多模態(tài)這些偏門場景差距就拉開了。OpenMove 是唯一一個在三個協(xié)議的流式測試?yán)锶客ㄟ^的平臺。其它平臺要么是不支持某個協(xié)議端點(diǎn)要么是支持但細(xì)節(jié)沒有對齊。4.2 OpenMove 在“細(xì)節(jié)兼容”上的表現(xiàn)OpenMove 給我留下最深印象的不是“能不能通”而是它對參數(shù)映射的細(xì)節(jié)處理。舉個具體的例子OpenAI 的max_tokens到了 Gemini 那邊要變成maxOutputTokens如果映射漏了模型會默默用默認(rèn)值這在小模型上可能沒什么感覺但在需要精確控制輸出長度的金融、法務(wù)場景里直接會導(dǎo)致結(jié)果被截斷。它另一個做得好的地方是 system prompt 的處理。OpenAI 允許system和developer兩種角色Anthropic 只有一個system字段Gemini 甚至通常把 system 指令放在system_instruction里。OpenMove 在轉(zhuǎn)換時會做合并和拆分而不是簡單地把 system role 當(dāng)成普通消息丟掉。我在日志里驗(yàn)證過多輪對話里 system 信息不會被后續(xù) user 消息覆蓋。還有一個細(xì)節(jié)是工具調(diào)用。很多平臺在把 OpenAI 的tool_calls翻譯成 Anthropic 的tool_use塊時只翻譯了第一層導(dǎo)致嵌套對象的input字段丟失。OpenMove 在這個地方做了遞歸轉(zhuǎn)換我在測試工具里傳了一個帶復(fù)雜 JSON Schema 的“天氣查詢工具”返回的 tool 參數(shù)結(jié)構(gòu)和原生調(diào)用完全一致。4.3 其它平臺的槽點(diǎn)前面也提到了不少這里集中說一下。AP 的問題是“半兼容”。它只提供一個 OpenAI 兼容端點(diǎn)Anthropic 和 Gemini 的 SDK 都接不了。如果你只是個人用 OpenAI 體系它足夠便宜但想切協(xié)議基本就得重寫代碼。它的工具調(diào)用有時會丟字段我連續(xù)測了五次有兩次input_schema里的enum丟失這個問題在聯(lián)調(diào)時非常難排查因?yàn)椴皇潜噩F(xiàn)而是偶發(fā)。UAG 的企業(yè)功能很全但協(xié)議兼容端點(diǎn)的文檔更新滯后。它的 Anthropic 兼容端點(diǎn)標(biāo)了 Beta實(shí)測也確實(shí)不穩(wěn)定流式事件缺失就是很典型的表現(xiàn)。對團(tuán)隊(duì)來說這不是說不能用而是需要預(yù)留額外的兼容層修復(fù)時間。RelayX 更像一個“社區(qū)集合”好處是模型種類多、上新快壞處是協(xié)議兼容完全靠社區(qū)貢獻(xiàn)質(zhì)量參差不齊。Gemini 端點(diǎn)不支持safetySettings只是冰山一角我還遇到過 Gemini 端點(diǎn)在 tool 調(diào)用時返回的 finishReason 和原生 API 不一致造成客戶端誤判。5. 協(xié)議兼容性背后的原理一次翻譯N端適配5.1 協(xié)議轉(zhuǎn)換不是“改個 URL”那么簡單很多人以為聚合平臺就是一層反向代理把請求 URL 改一下轉(zhuǎn)發(fā)出去再把響應(yīng)原樣返回。實(shí)際上協(xié)議轉(zhuǎn)換要處理的東西遠(yuǎn)比想象中多。請求側(cè)至少要做三層工作。第一層是端點(diǎn)路由不同協(xié)議對應(yīng)不同路徑第二層是參數(shù)映射同一個語義的參數(shù)在不同協(xié)議里叫法不同第三層是消息結(jié)構(gòu)轉(zhuǎn)換把數(shù)組、嵌套塊、角色定義全部重塑。響應(yīng)側(cè)也一樣要把目標(biāo)模型返回的數(shù)據(jù)重新組裝成調(diào)用方協(xié)議的樣子同時還不能丟字段?？梢园阉斫獬梢粋€翻譯團(tuán)隊(duì)不僅要把中文翻譯成英文還要把成語、雙關(guān)語、文化背景都解釋清楚。比如 OpenAI 的finish_reason有stop、length、tool_callsAnthropic 的stop_reason有end_turn、max_tokens、tool_use兩者不是一一對應(yīng)翻譯時需要有規(guī)則映射而不是簡單地照抄。5.2 流式兼容的難點(diǎn)流式是最容易暴露協(xié)議兼容問題的環(huán)節(jié)因?yàn)樗浅掷m(xù)性的不是一次請求一次響應(yīng)?？蛻舳艘推脚_之間建立一條 SSE 長連接平臺要和目標(biāo)模型之間再建立一條連接中間還要做逐段翻譯。OpenAI 的流式事件一般是choices[0].delta.contentAnthropic 是content_block_delta的delta.textGemini 是candidates[0].content.parts里的text。翻譯層需要在每個 chunk 到達(dá)時做結(jié)構(gòu)替換還得保持順序。更麻煩的是結(jié)束信號OpenAI 的流式結(jié)束靠finish_reasonAnthropic 靠message_delta里的stop_reasonGemini 靠finishReason。如果一個平臺只翻譯了內(nèi)容塊忘了翻譯結(jié)束信號客戶端的for await循環(huán)就會一直等下去看起來就是“卡住不動”。OpenMove 在處理流式時還做了一件事它會透傳 usage 信息而不是像有些平臺那樣偷偷丟掉。這對做 token 計(jì)費(fèi)、用量統(tǒng)計(jì)的應(yīng)用來說非常重要。5.3 參數(shù)映射表我把三個協(xié)議里最常見的參數(shù)映射關(guān)系整理了一下聚合平臺如果沒有按照下面這張表的邏輯去實(shí)現(xiàn)基本可以判斷為不合格。語義OpenAIAnthropicGeminiOpenMove 映射情況最大生成 Token 數(shù)max_tokensmax_tokensmaxOutputTokens有映射溫度temperaturetemperaturegenerationConfig.temperature有映射采樣概率top_ptop_ptopP有映射系統(tǒng)指令messages 中 rolesystemsystem 字段system_instruction.contents合并/拆分多輪消息messages 數(shù)組messages 數(shù)組contents 數(shù)組有轉(zhuǎn)換工具定義toolstoolstools / functionDeclarations有轉(zhuǎn)換工具調(diào)用結(jié)果tool 角色消息tool_result 內(nèi)容塊functionResponse part有轉(zhuǎn)換停止符stopstop_sequencesstopSequences有映射從這個表能看出來剛提到的這些參數(shù)在語義上基本是共通的只是外衣不一樣。一個合格的聚合平臺要做的不是“盡量兼容”而是“每一個參數(shù)都映射到位”。只要有一項(xiàng)漏了邊界場景就會翻車。6. 選型建議與避坑清單6.1 什么場景適合用聚合接口平臺經(jīng)過這輪橫評我的結(jié)論是不要盲目上聚合平臺先看自己的使用場景。如果你是個人開發(fā)者或者小團(tuán)隊(duì)正在做原型驗(yàn)證模型切換頻繁那 OpenMove 這類協(xié)議兼容做得好的平臺非常合適。你可以在一天內(nèi)把同一個應(yīng)用分別接到 GPT、Claude、Gemini 上對比效果這比單獨(dú)申請各家 API 再寫適配層快太多了。如果你的業(yè)務(wù)已經(jīng)穩(wěn)定跑在某個單一模型上而且沒有短期內(nèi)切換模型的計(jì)劃那直接調(diào)官方 API 反而是最穩(wěn)的選擇。多一層轉(zhuǎn)發(fā)就多一層風(fēng)險沒必要為了“可能的需求”提前引入復(fù)雜架構(gòu)。但如果你是在做 toB 產(chǎn)品需要同時服務(wù)多個客戶、多個模型或者你要把模型能力賣給下游開發(fā)者那協(xié)議兼容聚合平臺幾乎是必需品。你的客戶不可能都用同一套 SDK你需要給不同的客戶提供不同的接入?yún)f(xié)議OpenMove 這種“三協(xié)議同時兼容”的方案就有明顯優(yōu)勢。6.2 我踩過的坑和排查技巧這輪測試?yán)镂乙膊攘瞬簧倏犹魩讉€典型的分享出來。第一個坑是模型名寫錯導(dǎo)致 404 而不是 400。有些平臺在模型不存在時返回 404但錯誤信息里沒有目標(biāo)模型名排查起來特別慢。我后來統(tǒng)一在客戶端打印model字段至少能確認(rèn)是聚合層映射問題還是密鑰問題。第二個坑是流式環(huán)境下的代理干擾。測試 RelayX 時流式中斷我一直以為是平臺問題后來才發(fā)現(xiàn)是我本地抓包工具把 SSE 的 chunk 緩沖了。排查的時候先把抓包工具關(guān)掉用最簡單的httpx腳本直接讀原始響應(yīng)確認(rèn)平臺側(cè)沒問題再上 SDK。第三個坑是工具調(diào)用結(jié)果的二次請求失敗。Anthropic 的工具調(diào)用流程里模型返回tool_use后你需要把用戶實(shí)際執(zhí)行的工具結(jié)果用tool_result內(nèi)容塊傳回去。有些聚合平臺只做了第一次轉(zhuǎn)換沒有把tool_result再轉(zhuǎn)回 OpenAI 的 tool role message導(dǎo)致第二輪請求失敗。這個問題在 OpenMove 上沒出現(xiàn)但在 RelayX 上必現(xiàn)測試時一定要跑完整的多輪工具調(diào)用鏈路。第四個坑是用量統(tǒng)計(jì)對不上。聚合平臺上報的 token 用量經(jīng)常和模型官方返回的不一致這可能是轉(zhuǎn)換過程中自己重新計(jì)算了 token也可能是丟了 usage 字段。如果是計(jì)費(fèi)敏感的業(yè)務(wù)建議以目標(biāo)模型官方日志為準(zhǔn)不要讓聚合平臺直接參與出賬。6.3 選型時可以重點(diǎn)關(guān)注的四個能力最后給一個可以直接抄作業(yè)的選型清單第一看它是否提供多個協(xié)議的 SDK 兼容端點(diǎn)而不只是 OpenAI 兼容端點(diǎn)。這是能不能做到“代碼不用大改”的基礎(chǔ)。第二用一個小工具函數(shù)測三輪完整的工具調(diào)用鏈路而不是只測單輪對話。很多平臺死在這一步。第三對比流式輸出時的結(jié)束事件是否完整。可以寫一個三分鐘腳本記錄從發(fā)起請求到流結(jié)束的原始事件確認(rèn)沒有漏事件。第四看一下錯誤碼映射。模型限流、上下文超長、鑒權(quán)失敗這些常見錯誤返回給客戶端時是否符合你所使用 SDK 的異常解析規(guī)則。我自己在實(shí)際選型時會先把目標(biāo)模型列表和協(xié)議類型列出來再根據(jù)這張表打分。OpenMove 這輪的評分是 49 分扣掉的 1 分在于它的控制臺自定義模型路由配置首次使用時入口有點(diǎn)隱蔽需要點(diǎn)進(jìn)“高級設(shè)置”才能找到。但對最終要寫代碼的人來說這不是大問題。這次橫評最大的體會就是協(xié)議兼容性這東西文檔上寫著“支持”只代表能連通不等于細(xì)節(jié)完整。真正決定一個聚合平臺能不能省心要看那些平時不會寫進(jìn)宣傳頁的地方。后面我還會再測一測這些平臺的私有化部署方案到時候再來分享。