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