【免費(fèi)下載鏈接】ai-toolboxPersonal AI Toolbox項(xiàng)目地址https://gitcode.com/gh_mirrors/aitoolbo/ai-toolbox點(diǎn)擊查看免費(fèi)下載AI Toolbox 是一個開源的個人 AI 工具箱其中最硬核的模塊之一就是它的AI 協(xié)議網(wǎng)關(guān)Proxy Gateway。它運(yùn)行在你的本機(jī)負(fù)責(zé)把 Claude Code、Codex、Grok CLI、Kimi CLI、Gemini CLI 這些 AI 編程工具的請求轉(zhuǎn)發(fā)到任意你選擇的模型供應(yīng)商——哪怕兩端說的是不同的語言。這篇深度剖析將帶你從零理解四大 AI 協(xié)議網(wǎng)關(guān)轉(zhuǎn)換架構(gòu)是如何實(shí)現(xiàn)的為什么它的轉(zhuǎn)換方案既優(yōu)雅又穩(wěn)健。先看它在產(chǎn)品里的位置每個 CLI 工具的供應(yīng)商列表里都可以配置不同協(xié)議的 API 端點(diǎn)為什么需要 AI 協(xié)議網(wǎng)關(guān) 一個繞不開的現(xiàn)實(shí)問題不同 AI 工具說不同的協(xié)議?？蛻舳巳胝緟f(xié)議上游可能需要轉(zhuǎn)換的目標(biāo)協(xié)議Claude CodeAnthropic MessagesOpenAI Chat、OpenAI Responses、Gemini NativeCodexOpenAI Responses / ChatAnthropic Messages、OpenAI Chat、Gemini NativeGrok CLIOpenAI ResponsesAnthropic Messages、OpenAI Chat、Gemini NativeKimi CLIOpenAI ChatAnthropic Messages、OpenAI Responses、Gemini NativeGemini CLIGemini NativeAnthropic Messages、OpenAI Chat、OpenAI Responses比如你的 Claude Code 只會說Anthropic Messages但你手里 DeepSeek 的端點(diǎn)是OpenAI Chat格式。直接轉(zhuǎn)發(fā)400 錯誤。這時(shí) AI Toolbox 的協(xié)議網(wǎng)關(guān)就登場了——它把請求翻譯成上游聽得懂的格式再把響應(yīng)翻譯回來。而供應(yīng)商端點(diǎn)的具體協(xié)議在表單里以apiFormat形式選擇兩層架構(gòu)runtime 管編排transformer 管翻譯理解整個網(wǎng)關(guān)的關(guān)鍵是先看清它的分層設(shè)計(jì)。AI Toolbox 把協(xié)議轉(zhuǎn)換拆成兩個互不越權(quán)的層1?? runtime 層runtime/請求編排負(fù)責(zé)流程控制的一切匹配入站路由、讀取供應(yīng)商配置、確定源協(xié)議/目標(biāo)協(xié)議、決定是否轉(zhuǎn)換、拼接上游 URL 與鑒權(quán)頭、執(zhí)行供應(yīng)商方言兼容、記錄日志統(tǒng)計(jì)、處理重試與故障轉(zhuǎn)移。2?? transformer 層transformer/純協(xié)議翻譯負(fù)責(zé)內(nèi)容翻譯的一切把四種聊天協(xié)議的 JSON 請求體、錯誤體和 SSE 流相互轉(zhuǎn)換。它不讀數(shù)據(jù)庫、不拼 URL、不注入 API Key只接收源協(xié)議 → 目標(biāo)協(xié)議的轉(zhuǎn)換路由和原始載荷輸出轉(zhuǎn)換后的載荷。這個邊界劃得非常干凈——協(xié)議結(jié)構(gòu)互轉(zhuǎn)換給 transformer供應(yīng)商方言兼容DeepSeek 的 thinking 門控、Bedrock 的路徑差異、Ollama 的 wire 格式全部留在 runtime。新增一家供應(yīng)商時(shí)永遠(yuǎn)不用改 transformer 一行代碼。四大協(xié)議與 4×4 轉(zhuǎn)換矩陣協(xié)議枚舉定義在 transformer/types.rs協(xié)議代碼字符串典型 wire APIAnthropicMessagesanthropic_messagesAnthropic/v1/messagesOpenAiResponsesopenai_responsesOpenAI/v1/responsesOpenAiChatopenai_chatOpenAI/v1/chat/completionsGeminiNativegemini_nativeGeminigenerateContent/streamGenerateContent四種協(xié)議兩兩互轉(zhuǎn)構(gòu)成12 個非恒等轉(zhuǎn)換方向4×4 去掉 4 個恒等方向JSON 請求、JSON 響應(yīng)、錯誤體和 SSE 流全部走同一套轉(zhuǎn)換路由語義。一個值得注意的優(yōu)化同協(xié)議請求根本不進(jìn)轉(zhuǎn)換器。當(dāng)源協(xié)議與目標(biāo)協(xié)議相同時(shí)走直通鏈路只做模型名改寫、鑒權(quán)注入等 runtime 處理保持字節(jié)保真。轉(zhuǎn)換核心統(tǒng)一中間表示LLM IR如果四種協(xié)議兩兩互寫需要 12 套轉(zhuǎn)換器——這是蜘蛛網(wǎng)式的噩夢。AI Toolbox 用了經(jīng)典而高效的星型架構(gòu)所有協(xié)議都先翻譯成統(tǒng)一中間模型IR再由 IR 翻譯成目標(biāo)協(xié)議。源協(xié)議 JSON ──入站轉(zhuǎn)換器──? LLM IR ──出站轉(zhuǎn)換器──? 目標(biāo)協(xié)議 JSONLLM IR 定義在 llm/model.rs 和 llm/tools.rs它不是對外 API只是轉(zhuǎn)換內(nèi)部的通用語承載消息列表角色、文本/圖片內(nèi)容、工具調(diào)用與工具結(jié)果、推理內(nèi)容reasoning請求參數(shù)model、max_tokens、temperature、top_p、stop、stream 等工具定義tools、tool_choice、parallel_tool_calls響應(yīng)元數(shù)據(jù)choices、usage、finish_reason這樣每種協(xié)議只需要維護(hù)入站 出站兩個轉(zhuǎn)換器雙向共 4 個12 個方向全部由4 個協(xié)議 × 2 個方向的組合覆蓋。轉(zhuǎn)換內(nèi)核入口在 transformer/kernel.rs。一次請求的完整旅程以Claude Code 請求轉(zhuǎn)發(fā)到 DeepSeekOpenAI Chat 端點(diǎn)為例整條鏈路在 runtime/upstream.rs 中編排路由匹配入站前綴/anthropic命中 Claude Code 路由runtime/routes.rs推導(dǎo)出源協(xié)議 AnthropicMessages讀取供應(yīng)商從供應(yīng)商配置解析目標(biāo)協(xié)議 OpenAiChatruntime/providers.rs決策源 ≠ 目標(biāo)創(chuàng)建ConversionRoute請求轉(zhuǎn)換源 JSON → LLM IR → 目標(biāo) JSON供應(yīng)商方言適配最后一跳執(zhí)行 DeepSeek 專屬規(guī)則thinking 字段門控、JSON schema 降級等拼 URL / 鑒權(quán)頭發(fā)出上游請求響應(yīng)回轉(zhuǎn)響應(yīng)按反向路由target → source翻譯回 Anthropic Messages 格式返回客戶端流式響應(yīng)SSE 的邊讀邊轉(zhuǎn)AI 編程工具大量使用流式輸出SSE這給轉(zhuǎn)換帶來了額外挑戰(zhàn)不能把整個流緩沖下來再翻譯必須邊讀邊寫。StreamKerneltransformer/stream.rs的處理模型處理 UTF-8 跨 chunk 邊界解析 SSE 事件塊同時(shí)兼容 LF 和 CRLF 行尾源協(xié)議解析器把各協(xié)議事件解析成統(tǒng)一流事件Start、TextDelta、ReasoningDelta、ToolCall、Finish 等目標(biāo)協(xié)議寫入器把統(tǒng)一事件寫成目標(biāo)協(xié)議的 SSE各協(xié)議流式的方言Chat 的[DONE]、Anthropic 的message_stop、Responses 的終態(tài)事件、Gemini 的 finish chunk都被歸一化且結(jié)束事件冪等處理不會重復(fù)輸出完成信號。跨請求狀態(tài)Side Stores 的巧妙隔離多輪對話里有一些狀態(tài)天然跨越 HTTP 請求。AI Toolbox 把它們統(tǒng)一放在runtime/side_stores/與 transformer 完全隔離CodexHistoryStore記錄上一輪的工具調(diào)用當(dāng) Codex 下一輪只帶previous_response_id時(shí)自動補(bǔ)回缺失的前序工具調(diào)用GeminiShadowStore回放帶thoughtSignature的模型函數(shù)調(diào)用保證 Gemini 多輪工具鏈不斷裂InvalidResponsesCipherStore負(fù)緩存記住上游明確拒絕過的加密內(nèi)容摘要避免反復(fù)撞墻三者都有容量上限和可靠的會話鍵且不落數(shù)據(jù)庫。供應(yīng)商方言兼容runtime 的專屬領(lǐng)域看起來像協(xié)議轉(zhuǎn)換的邏輯其實(shí)大多屬于供應(yīng)商方言——比如 DeepSeek 不接受 OpenAI 的 JSON Schema wrapper、Ollama 的最后一跳是/api/chat而非標(biāo)準(zhǔn) Chat。這些規(guī)則全部收斂在 runtime 的 outbound body pipeline 中按providerType target_protocol識別供應(yīng)商方言DeepSeek、Moonshot、GLM、xAI、Bedrock、Vertex、Copilot、Ollama 等十余種永遠(yuǎn)不下沉到 transformer。判斷依據(jù)是供應(yīng)商配置里顯式聲明的 profile 引用而不是靠模型名或 Base URL 猜供應(yīng)商——這意味著自定義供應(yīng)商不會被誤套官方方言聚合商也不會被當(dāng)成官方渠道。有損轉(zhuǎn)換檢測寧可信其有不是所有字段都能無損翻譯。check_lossy_conversion()transformer/shared/lossy.rs在轉(zhuǎn)換前檢測高風(fēng)險(xiǎn)項(xiàng)——例如 Responses 的 hosted tool、Anthropic 的 server tool、Gemini 專屬的 safetySettings 等目標(biāo)協(xié)議無法表達(dá)的內(nèi)容。它只檢測、不決策是否拒絕由 runtime 策略決定默認(rèn)只把警告寫入響應(yīng)頭X-Transformer-Lossy當(dāng)用戶開啟有損拒絕且請求未帶X-Allow-Lossy頭時(shí)才返回本地 400。寧可透明地告訴你這里可能有損失也不靜默丟字段。關(guān)鍵源碼與文檔索引想繼續(xù)深挖這些入口最值得閱讀模塊路徑職責(zé)協(xié)議枚舉與轉(zhuǎn)換路由transformer/types.rsAiProtocol、ConversionRoute轉(zhuǎn)換內(nèi)核transformer/kernel.rsJSON/錯誤體/SSE 轉(zhuǎn)換入口LLM IRtransformer/llm/model.rs統(tǒng)一中間表示流式轉(zhuǎn)換transformer/stream.rsStreamKernel與統(tǒng)一流事件上游編排runtime/upstream.rs請求/響應(yīng)主編排有損檢測transformer/shared/lossy.rs純檢測函數(shù)完整協(xié)議轉(zhuǎn)換源碼在 transformer/ 模塊架構(gòu)主文檔見 docs/gateway-protocol-conversion.md逐供應(yīng)商兼容細(xì)節(jié)見 docs/gateway-provider-compatibility.md?？偨Y(jié)AI Toolbox 的協(xié)議網(wǎng)關(guān)轉(zhuǎn)換架構(gòu)核心思想可以濃縮成三句話星型架構(gòu)用統(tǒng)一 LLM IR 把 12 個轉(zhuǎn)換方向降維成 4 個協(xié)議的入站/出站轉(zhuǎn)換器嚴(yán)格分層transformer 只管協(xié)議翻譯runtime 管編排與供應(yīng)商方言邊界清晰到新增供應(yīng)商零改動轉(zhuǎn)換器透明可信有損檢測、字節(jié)保真直通、終態(tài)精確判定寧可失敗也不偽造成功。下次當(dāng)你的 Claude Code 在 Codex 格式的供應(yīng)商上流暢對話時(shí)背后正是這套四大 AI 協(xié)議網(wǎng)關(guān)在默默完成無數(shù)次雙向翻譯。贊分享【免費(fèi)下載鏈接】ai-toolboxPersonal AI Toolbox項(xiàng)目地址https://gitcode.com/gh_mirrors/aitoolbo/ai-toolbox點(diǎn)擊查看免費(fèi)下載相關(guān)推薦最穩(wěn)AI架構(gòu)揭秘如何用Portkey實(shí)現(xiàn)99.99%可用性的企業(yè)級LLM網(wǎng)關(guān)最穩(wěn)AI架構(gòu)揭秘如何用Portkey實(shí)現(xiàn)99.99%可用性的企業(yè)級LLM網(wǎng)關(guān) 在當(dāng)今AI驅(qū)動的商業(yè)環(huán)境中企業(yè)對大語言模型LLM服務(wù)的依賴程度日益加深而LLM 網(wǎng)關(guān)API網(wǎng)關(guān)后端負(fù)載均衡人工智能多協(xié)議網(wǎng)關(guān)架構(gòu)Authelia協(xié)議轉(zhuǎn)換與統(tǒng)一認(rèn)證多協(xié)議網(wǎng)關(guān)架構(gòu)Authelia協(xié)議轉(zhuǎn)換與統(tǒng)一認(rèn)證 引言現(xiàn)代應(yīng)用認(rèn)證的挑戰(zhàn) 在當(dāng)今復(fù)雜的微服務(wù)架構(gòu)中應(yīng)用認(rèn)證面臨著前所未有的挑戰(zhàn)。不同服務(wù)可能使用不同的認(rèn)證后端認(rèn)證鑒權(quán)單點(diǎn)登錄身份認(rèn)證應(yīng)用安全FunASR 完全指南從會議轉(zhuǎn)寫到實(shí)時(shí)字幕一套免費(fèi)開源語音識別工具搞定FunASR 完全指南從會議轉(zhuǎn)寫到實(shí)時(shí)字幕一套免費(fèi)開源語音識別工具搞定 一場兩小時(shí)的會議紀(jì)要、幾百段客服錄音、需要實(shí)時(shí)字幕的直播——這些場景背后都是同一個需語音音頻人工智能大模型模型推理服務(wù)本地部署創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考