北京
一個AI應(yīng)用直接調(diào)用大模型，在實驗階段還行。可一旦做成生產(chǎn)級的智能代理，狀況就不一樣了——需要對接多家模型供應(yīng)商、發(fā)現(xiàn)并調(diào)用MCP工具、跨代理通信，還得管認證、限流、重試、超時、成本追蹤和內(nèi)容安全。如果每個應(yīng)用都把這些能力自己實現(xiàn)一遍，用不了多久就會變成一鍋“連接亂燉”，操作難度陡增。
于是，有人主張：傳統(tǒng)API網(wǎng)關(guān)應(yīng)付得來。API網(wǎng)關(guān)本來就能做路由、鑒權(quán)、TLS終結(jié)和速率限制，加上幾次小升級，管起LLM請求也綽綽有余。這種看法在技術(shù)圈并不少見，畢竟“流量管理”聽起來大同小異。
但另一面的聲音也不弱。代理類系統(tǒng)引入的全是“不對勁”的流量：模型服務(wù)不是標準REST，有流式響應(yīng)和令牌級的計量；MCP服務(wù)器的發(fā)現(xiàn)與調(diào)用自帶獨特協(xié)議；代理間通信（A2A）又需要另一套尋址和權(quán)限模型。更麻煩的是，管理員得在同一套體系里落實安全策略，既要看住密鑰存在哪兒、哪些模型能被誰調(diào)用，又要防止一個應(yīng)用燒光全年預(yù)算，還得統(tǒng)一觀察延遲、令牌消耗和故障。把所有這些邏輯嵌入各個代理內(nèi)部，不僅產(chǎn)生重復(fù)代碼，還讓策略執(zhí)行七零八落。
這就是Agentgateway被提出來的背景。它是一個開源、AI優(yōu)先的數(shù)據(jù)平面，專為連接應(yīng)用與代理、MCP工具、LLM供應(yīng)商、推理服務(wù)以及傳統(tǒng)后端而設(shè)計。在Kubernetes環(huán)境中，它還包含一個控制平面，通過觀察Gateway API資源和自定義資源，把配置轉(zhuǎn)成運行態(tài)并分發(fā)給代理網(wǎng)關(guān)代理。它既不是單純把LLM請求轉(zhuǎn)發(fā)出去，也不是要取代現(xiàn)有的API網(wǎng)關(guān)，而是在一個平面上收斂MCP、A2A、HTTP、gRPC等不同協(xié)議，讓代理系統(tǒng)有統(tǒng)一的連接入口和策略層。
我的判斷是：這兩股觀點并不是非此即彼。傳統(tǒng)API網(wǎng)關(guān)在某些路徑上依然好用，比如對外暴露標準HTTP接口；而Agentgateway處理的是代理特有的“多協(xié)議混合”流量和精細化治理。兩者更像是互補，而非競爭。對團隊來說，真正要做的，是把認證、訪問控制、預(yù)算管理、可觀測性這些橫向關(guān)注點，從一個個代理里抽出來，放進一個共享的基礎(chǔ)設(shè)施層，讓架構(gòu)從“每個代理自掃門前雪”變成有規(guī)則、可治理的連接生態(tài)。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
