AI網(wǎng)關(guān)API和Agent的貨幣化網(wǎng)關(guān)一詞相信大家都不陌生，還記得最早的網(wǎng)關(guān)是什么樣子嗎?沒錯，就是一個簡單的反向代讀到這里你可能會有這樣的疑問：既然都是網(wǎng)關(guān)為什么會有這么網(wǎng)關(guān)演進(jìn)形態(tài)概覽網(wǎng)關(guān)演進(jìn)形態(tài)概覽AI原生架構(gòu)AI網(wǎng)關(guān)云原生架構(gòu)微服務(wù)架構(gòu)單體架構(gòu)垂直架構(gòu)流量網(wǎng)關(guān)作為網(wǎng)絡(luò)架構(gòu)中的關(guān)鍵組件，主要負(fù)責(zé)管理和優(yōu)化數(shù)據(jù)流量，以提升業(yè)務(wù)的可伸縮性和高可用性。Nginx作為流量網(wǎng)關(guān)量網(wǎng)關(guān)的核心目的是解決多業(yè)務(wù)節(jié)點(diǎn)間的流量負(fù)載均衡問題，通過將客戶請求分配到不同的服務(wù)器上，從而均勻分?jǐn)傌?fù)載，避免單點(diǎn)故障，確保服務(wù)的穩(wěn)定性和連續(xù)性。流量網(wǎng)關(guān)在單體架6.1.3微服務(wù)網(wǎng)關(guān)微服務(wù)網(wǎng)關(guān)是微服務(wù)架構(gòu)中的關(guān)鍵核心組件，負(fù)責(zé)集中管理微服務(wù)的路由規(guī)則，增強(qiáng)系統(tǒng)安全6.1.4云原生網(wǎng)關(guān)云原生網(wǎng)關(guān)是伴隨K8s的廣泛應(yīng)用而誕生的一種創(chuàng)新網(wǎng)關(guān)，K8s集群內(nèi)外網(wǎng)絡(luò)天然隔離的特性的配置方式，同時K8s提供了彈性擴(kuò)縮容來幫助用戶解決應(yīng)用容量調(diào)度問題，基于此用戶對網(wǎng)關(guān)產(chǎn)生了新的訴求：期望網(wǎng)關(guān)既能有流量網(wǎng)關(guān)的特性來處理海量請求，又具備微服務(wù)網(wǎng)關(guān)的特性來做服務(wù)發(fā)現(xiàn)與服務(wù)治理，同時要求網(wǎng)關(guān)也具備彈性擴(kuò)縮容能力解決容量調(diào)度問題，能夠讓開發(fā)者能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯的實(shí)現(xiàn)，而無需擔(dān)心底層架構(gòu)的容量、維護(hù)和管理。之前的幾種類型網(wǎng)關(guān)處理的流量基本是以HTTP、RPC為主，多采用長連接提高傳輸性能，長連送數(shù)據(jù)給Client,Websocket更是一種全雙工協(xié)議，主要在如語音類的實(shí)時通訊場景中使用。這種長連接對應(yīng)用帶來的一個巨大的潛在影響是，原來的無狀態(tài)應(yīng)用會變成有狀態(tài)應(yīng)用，應(yīng)用層的配置變更不能中斷長連接的傳輸，AI流量特點(diǎn)簡圖如下：大促特點(diǎn)大促特點(diǎn)在AI場景中，不僅流量有新的特點(diǎn)，而且對于網(wǎng)關(guān)也產(chǎn)生了新的訴求，最典型的是多模型代理訴求，背后的原因有以下4點(diǎn)：企業(yè)需同時處理文本、圖像、音頻、3D等多模態(tài)數(shù)據(jù)。研發(fā)、產(chǎn)品團(tuán)隊(duì)對推理能力強(qiáng)的模型需求多；客服、營銷、平面設(shè)計等團(tuán)隊(duì)對圖片大模型的場景需求多；工業(yè)設(shè)計、影視制作團(tuán)隊(duì)對音視頻大模型的場景需求多。企業(yè)業(yè)務(wù)覆蓋多個垂直領(lǐng)域，需針對不同行業(yè)特性調(diào)用專用模型。尤其是供應(yīng)鏈端的企業(yè)往往服務(wù)多個行業(yè)，可能會涉及多款垂直行業(yè)的大模型需求。復(fù)雜任務(wù)協(xié)同場景，單一任務(wù)需要多個模型分工協(xié)作，以提升效果。多個大模型員工協(xié)同生成內(nèi)容，才能起到最佳效果。安全與效率雙重要求場景，例如醫(yī)療機(jī)構(gòu)的場景，處理患者數(shù)據(jù)使用專屬私有模型分析，其他和患者無關(guān)的需求使用通用模型，避免敏感數(shù)據(jù)和非敏感數(shù)據(jù)在寫入數(shù)據(jù)庫混存。除了多模型代理以外還有很多其他的訴求，例如智能路由、模型增強(qiáng)、安全防護(hù)、流式傳輸、無損變更等，由于篇幅有限這里就不再——展開。目前對網(wǎng)關(guān)有一些更細(xì)粒度的分法，比如直接對接后端模型的稱為ModelGateway,面向終端應(yīng)用的稱為AIGateway,筆者認(rèn)為其本質(zhì)都是屬于AI網(wǎng)關(guān)范疇。垂類模型↓容器物理機(jī)意圖識別AI應(yīng)用AI可觀測Al安全防護(hù)本質(zhì)都屬于讀到這里你可能會問：這些AI網(wǎng)關(guān)的訴求是怎么來的呢?是從真實(shí)的實(shí)踐場景中總結(jié)過來的還是自行YY的呢?所謂實(shí)踐出真知，目前Higress在阿里云內(nèi)部的AI場景中已經(jīng)大規(guī)模生產(chǎn)落地，支持的核心業(yè)務(wù)見下圖。HigressHigress內(nèi)部落地AI場景介紹通義App業(yè)務(wù)Server業(yè)務(wù)Server阿里云百煉業(yè)務(wù)網(wǎng)關(guān)業(yè)務(wù)網(wǎng)關(guān)·支持長連接SSE/WebSocket,熱更新對長連接流量無損Higress網(wǎng)關(guān)不僅在阿里云內(nèi)部大規(guī)模生產(chǎn)落地，有對應(yīng)的云產(chǎn)品，名稱是API網(wǎng)關(guān)，也對外進(jìn)行了開源。如果大家感興趣可以訪問項(xiàng)目地址：https://hiHigress的愿景是成為全球領(lǐng)先的Al網(wǎng)關(guān)，目前Higress已經(jīng)啟動了開源出海項(xiàng)目，也歡迎感興趣的小伙伴一起參與共建。從流量網(wǎng)關(guān)，再到AI網(wǎng)關(guān)，都是API網(wǎng)關(guān)在不同軟件架構(gòu)下的網(wǎng)關(guān)形態(tài)。在流量網(wǎng)關(guān)中，路由本身是一種API,只是沒有定義規(guī)范的請求和響應(yīng)標(biāo)準(zhǔn)，通常被稱為HTTPAPI,他是使用最簡單、應(yīng)用最廣的API。RESTAPI采用OpenAPI格式來規(guī)范請求和響應(yīng)，在微服務(wù)架構(gòu)下中對外提供服務(wù)時，應(yīng)用較廣。gRPC和Dubbo都是高性能的遠(yuǎn)程調(diào)用框架，對于服務(wù)之間的高頻調(diào)用，對帶寬和CPU序列化開銷大的場景，更加適用。WebsocketHTML5標(biāo)準(zhǔn)中的全雙工通信協(xié)議，在即時通訊應(yīng)用的消息同步、游戲場景下的狀態(tài)更新等實(shí)時場景下，更加適用?？梢哉f支持API訪問的都是API網(wǎng)關(guān)，API網(wǎng)關(guān)是貫穿軟件架構(gòu)演進(jìn)的各個階段。因此，唯一不變的是變化，在現(xiàn)代復(fù)雜的商業(yè)環(huán)境中，企業(yè)的業(yè)務(wù)形態(tài)與規(guī)模往往處于不斷變化和擴(kuò)大之中。這種動態(tài)發(fā)展對企業(yè)的信息系統(tǒng)提出了更高的要求，特別是在軟件架構(gòu)方面。為了應(yīng)對不斷變化的市場需求和業(yè)務(wù)擴(kuò)展，軟件架構(gòu)必須進(jìn)行相應(yīng)的演進(jìn)和優(yōu)化。網(wǎng)關(guān)作為互聯(lián)網(wǎng)流量的入口，其形態(tài)也在跟隨軟件架構(gòu)持續(xù)演進(jìn)迭代中。在AI應(yīng)用爆發(fā)的當(dāng)下，AI網(wǎng)關(guān)正扮演著Al應(yīng)用基礎(chǔ)設(shè)施的角色。AI網(wǎng)關(guān)是提供多模型流量調(diào)度，MCP和Agent管理，智能路由和AI治理的下一代網(wǎng)關(guān)。本質(zhì)上，它是一種針對AI應(yīng)用場景進(jìn)行專門優(yōu)化和能力擴(kuò)展的API網(wǎng)關(guān)。AI網(wǎng)關(guān)不僅完整繼承了API網(wǎng)關(guān)的通用能力，如安全認(rèn)證、路由轉(zhuǎn)發(fā)、流量控制等，也演進(jìn)出了大模型Fallback、大模型負(fù)載均衡、Token級別的精細(xì)化流量管控、語義化緩存、內(nèi)容安全、聯(lián)網(wǎng)搜索、MCP協(xié)議轉(zhuǎn)化和管理、工具精選和搜索效果優(yōu)化等面向AI場景的能力。當(dāng)我們嘗試?yán)斫釧I網(wǎng)關(guān)時，不妨先從Al應(yīng)用的流量特征開始，因?yàn)锳I網(wǎng)關(guān)的服務(wù)對象就是Al應(yīng)用，所謂知其然而知其所以然。AI應(yīng)用的流量特征與我們所熟知的傳統(tǒng)Web應(yīng)用截然不同，主要體現(xiàn)在以下四個方面：高延時：模型推理涉及龐大的計算量，導(dǎo)致其響應(yīng)時間遠(yuǎn)高于普通應(yīng)用，從幾十毫秒的量級躍升至數(shù)秒甚至數(shù)十秒。這種長耗時的特性，使得服務(wù)在面對類似慢速連接的惡意攻擊時，變得異常脆弱，攻擊者可以用極低的成本耗盡寶貴的后端計算資源。大帶寬與流式傳輸：為了提升交互的即時感，AI生成的較長內(nèi)容(如文章、代碼)通常不會等待全部生成完畢后再一次性返回，而是采用流式(Streaming)的方式，像打字機(jī)一樣逐字或逐詞地推送給用戶。這對網(wǎng)關(guān)的流式處理能力和內(nèi)存控制提出了極高的要求，傳統(tǒng)的緩存轉(zhuǎn)發(fā)模式很容易導(dǎo)致內(nèi)存溢出。長連接：為了支持上下文連貫的多輪對話，Al應(yīng)用廣泛采用SSE(Server-SentEvents)或WebSocket等長連接協(xié)議。然而，許多傳統(tǒng)網(wǎng)關(guān)在更新配置(如發(fā)布一條新路由)時，需要重啟工作進(jìn)程，這會強(qiáng)制切斷所有已建立的長連接，導(dǎo)致用戶的對話進(jìn)程中斷，仿佛正在交流的機(jī)器人突然失憶，體驗(yàn)極差。API驅(qū)動：未來的Al原生應(yīng)用將由無數(shù)個輕量化的Agent構(gòu)成，它們通過調(diào)用各種原子化的API(即工具)來完成查詢信息、操作軟件等復(fù)雜任務(wù)。這將導(dǎo)致應(yīng)用內(nèi)部和外部的API數(shù)量及調(diào)用量呈爆炸式增長，對API的設(shè)計、發(fā)布、監(jiān)控、安全等全生命周期管理能力提出了前所未有的要求。根據(jù)不同的業(yè)務(wù)需求和部署位置，AI網(wǎng)關(guān)通常出現(xiàn)在以下四種典型的場景中，扮演著各自獨(dú)特的角色：1.模型服務(wù)提供商(MaaS)的接入層對于提供基礎(chǔ)大模型服務(wù)的廠商而言，AI網(wǎng)關(guān)是其商業(yè)化服務(wù)的第一道防線。它部署在所有模型推理集群之前，作為流量的總?cè)肟冢?fù)責(zé)處理來自全球開發(fā)者和企業(yè)的海量請求。在此場景下，網(wǎng)關(guān)的核心職責(zé)是保障服務(wù)的性能、穩(wěn)定和安全。例如，通過高效的負(fù)載均衡策略將請求智能分發(fā)給后端最合適的計算資源，通過精細(xì)化的多維度流量控制來防止服務(wù)被惡意流量或突發(fā)洪峰打垮，并為不同等級的客戶提供差異化的服務(wù)質(zhì)量(QoS)保障。2.AI應(yīng)用的開發(fā)網(wǎng)關(guān)對于廣大的AI應(yīng)用開發(fā)者(尤其是SaaS應(yīng)用開發(fā)者)而言，他們通常不會自建模型，而是靈活地集成多家模型廠商的API,以取長補(bǔ)短。AI網(wǎng)關(guān)此時扮演著多模型智能調(diào)度中心的角色。它可以屏蔽不同廠商API的協(xié)議差異，提供一個統(tǒng)一、簡潔的調(diào)用接口。更重要的是，當(dāng)某個主用模型(如某個經(jīng)過精調(diào)的垂直領(lǐng)域模型)響應(yīng)緩慢或調(diào)用失敗時，網(wǎng)關(guān)可以依據(jù)預(yù)設(shè)策略，自動重試或無縫切換到備用模型(Fallback,如某個通用的基礎(chǔ)大模型),從而在不影響用戶體驗(yàn)的前提下，極大地提升應(yīng)用的穩(wěn)定性和韌性。同時，它還能對所有模型的返回內(nèi)容進(jìn)行統(tǒng)一的安全合規(guī)過濾。3.企業(yè)內(nèi)部的中央AI網(wǎng)關(guān)在大型企業(yè)內(nèi)部，當(dāng)各個業(yè)務(wù)線都開始引入AI能力時，若各自為政，很快就會陷入前面提到的接入混亂、成本失控和安全風(fēng)險的困境。此時，AI網(wǎng)關(guān)就像一個面向AI時代的企業(yè)服務(wù)總線 (ESB),成為所有內(nèi)部系統(tǒng)訪問內(nèi)外部AI服務(wù)的統(tǒng)一、標(biāo)準(zhǔn)化的入口。這種集中化的模式帶來◆成本審計與分?jǐn)偅壕_記錄并分析各業(yè)務(wù)部門、各應(yīng)用的Token消耗量，為成本控制、預(yù)算分配和內(nèi)部結(jié)算提供清晰、可信的數(shù)據(jù)支持。◆數(shù)據(jù)安全與合規(guī)：建立全企業(yè)統(tǒng)一的內(nèi)容安全策略，能夠有效防止企業(yè)內(nèi)部的敏感數(shù)據(jù)(如客戶信息、財務(wù)報表)通過prompt被無意或惡意地發(fā)送給外部模型，構(gòu)筑起一道關(guān)鍵的數(shù)據(jù)防泄露屏障。◆資源復(fù)用與效率提升：通過部署統(tǒng)一的語義化緩存，對全公司范圍內(nèi)的高頻、相似問題直接返回緩存結(jié)果，不僅能有效降低模型調(diào)用成本，更能顯著提升響應(yīng)速度，改善員工和客戶的體驗(yàn)。隨著AIAgent的興起，讓AI能夠調(diào)用外部工具(Tools)來完成查詢訂單、預(yù)訂會議室等實(shí)際任務(wù)變得至關(guān)重要。AI網(wǎng)關(guān)在此場景下，可以作為所有MCP(ModelContextProtocol)工具的統(tǒng)一收口和安全堡壘。所有對外部工具的調(diào)用請求都必須先經(jīng)過AI網(wǎng)關(guān)，由網(wǎng)關(guān)進(jìn)行集中的、標(biāo)準(zhǔn)化的安全管控，包括統(tǒng)一的認(rèn)證鑒權(quán)、精細(xì)的速率限制、全面的審計日志等。這種方式避免了在每一個獨(dú)立的工具服務(wù)上重復(fù)實(shí)現(xiàn)和維護(hù)復(fù)雜的安全邏輯，極大地簡化了MCP工具生態(tài)的安全治理，為企業(yè)構(gòu)建一個安全、可靠、可控的AIAgent體系提供了堅(jiān)實(shí)的基礎(chǔ)。例如Higress構(gòu)建的開源MCP市場就是這樣的一個樣板間。APlasMCP,connectingAIwithrealitaPouwwuocdrdr舉e回eM-@@5.構(gòu)建企業(yè)AI能力貨幣化的統(tǒng)一開放平臺任何企業(yè)的終極目標(biāo)都是營收與利潤，未來AI智能體應(yīng)用會成為大家日常工作生活當(dāng)中不可或缺的存在，在紅杉風(fēng)險投資舉辦的一場創(chuàng)業(yè)企業(yè)分享會中，就對未來AIAgent的前景做了展望，甚至紅杉風(fēng)投將其稱之為Agent經(jīng)濟(jì)，并給了一張暢想圖，從下面的圖中大家可以感受到未來Agent貨幣化的廣闊前景，那么Agent貨幣化的載體就是“AI開放平臺”,而這也是網(wǎng)關(guān)自身承載且擅長的領(lǐng)域。圖片來源：/article/ai-ascent-2025/讀到這里，你可能會產(chǎn)生這樣的困惑，開放平臺不是“API網(wǎng)關(guān)”的職責(zé)嗎?在上一個章節(jié)中簡單說了下“API網(wǎng)關(guān)”,總結(jié)起來，API是一種很泛化的定義。Websocket/gRPC/Dubbo/HTTP都可以被稱之為API,MCP、A2A也可以被稱之為API。當(dāng)前，大語言模型(LLM)正經(jīng)歷一個前所未有的百花齊放時代。從阿里云的Qwen系列、型，整個行業(yè)呈現(xiàn)出群雄逐鹿、蓬勃發(fā)展的多樣性格局。這種多樣性不僅僅是模型的數(shù)量增多，更體現(xiàn)在能力上的分化與專精。有的模型以其強(qiáng)大的邏輯推理和代碼生成能力著稱，有的則在長文本處理和人文創(chuàng)意寫作上表現(xiàn)優(yōu)異，還有一些輕量級模型在特定任務(wù)上具備極高的性價比和響應(yīng)速度。在這樣的背景下，Agent的設(shè)計理念發(fā)生了深刻的演變。早期的Agent或許只依賴單一的強(qiáng)大模型來完成所有任務(wù)，但如今，為了實(shí)現(xiàn)更高效、更經(jīng)濟(jì)、更強(qiáng)大的功能，先進(jìn)的Agent會根據(jù)任務(wù)類型的不同，在后臺智能地調(diào)度和使用多個不同的模型。例如，一個復(fù)雜的報告生成任務(wù)可能會被拆解：用一個模型進(jìn)行數(shù)據(jù)檢索，調(diào)用另一個模型進(jìn)行邏輯分析，最后再使用一個文筆優(yōu)美的模型來潤色文稿。揮著更關(guān)鍵的應(yīng)用基礎(chǔ)設(shè)施作用：企業(yè)MCP開放市場AgentFrameworkA2AAIObservability1.多模型代理：AI網(wǎng)關(guān)是流量的統(tǒng)一入口，用來接收用戶端請求，并負(fù)載均衡到后端模型，還能實(shí)現(xiàn)同一個接口對接多種模型，這個代理層不僅解決了調(diào)用不同模型API的復(fù)雜性，還通過動態(tài)路由實(shí)現(xiàn)了成本與性能的最佳平衡，更是提升了模型服務(wù)的可用性。2.多模型回退/容災(zāi)：依賴單一模型存在單點(diǎn)故障風(fēng)險，API的不穩(wěn)定或性能下降都可能導(dǎo)致服務(wù)中斷。AI網(wǎng)關(guān)能同時對接多個模型，當(dāng)單個模型出現(xiàn)調(diào)用失敗、超時或返回質(zhì)量不佳的結(jié)果時，可以自動Fallover到備選模型多模型，以確保服務(wù)的連續(xù)性和高可用性。3.消費(fèi)者認(rèn)證：當(dāng)一個代理服務(wù)需要為多個用戶或應(yīng)用提供支持時，身份認(rèn)證變得至關(guān)重要。通過AI網(wǎng)關(guān)清晰地識別每一個請求的來源，以便進(jìn)行后續(xù)的計費(fèi)、權(quán)限管理和個性化服務(wù)，確保按權(quán)限分類提供服務(wù)。4.內(nèi)容安全防護(hù)：不同的模型擁有各自的安全策略，標(biāo)準(zhǔn)不一。在一個多模型系統(tǒng)中，必須建立一個統(tǒng)一、前置的內(nèi)容安全防護(hù)層。AI網(wǎng)關(guān)能通過內(nèi)容安全插件，在請求送達(dá)模型之前和模型返回結(jié)果之后，對內(nèi)容進(jìn)行審查，過濾有害信息，確保整個應(yīng)用輸出的內(nèi)容始終符合安全規(guī)范和合規(guī)性。5.Token限流：大模型調(diào)用按Token計費(fèi)，且單位成本遠(yuǎn)高于CPU計費(fèi)，因此有效控制成本是高優(yōu)先級需求。AI網(wǎng)關(guān)提供的Token限流機(jī)制可以從控制單個用戶的調(diào)用頻率和總量，以及對服務(wù)總流量進(jìn)行調(diào)控兩個維度進(jìn)行管理，防止濫用導(dǎo)致費(fèi)用激增，并保障服務(wù)的穩(wěn)定性。6.語義緩存：AI網(wǎng)關(guān)提供了擴(kuò)展點(diǎn)，可接入Redis實(shí)現(xiàn)內(nèi)容緩存。一能提高效率，如果相同的輸入反復(fù)出現(xiàn)，緩存可以避免重復(fù)運(yùn)行模型，從而加快響應(yīng)速度，特別是在處理常見問題時。二是降低成本，大模型API計費(fèi)因是否命中緩存，而有所不同，緩存機(jī)制可以減少模型調(diào)用次數(shù)，以節(jié)省計算資源。三是保持一致性，緩存可以確保相同輸入產(chǎn)生相同輸出，有助于測試和合規(guī)性場景。7.可觀測性：在一個由多個開發(fā)平臺、多個模型、多個組件構(gòu)成的復(fù)雜系統(tǒng)中，統(tǒng)一的可觀測性是運(yùn)維和優(yōu)化的基石。AI網(wǎng)關(guān)能提供包括對每一次調(diào)用的詳細(xì)日志記錄(請求內(nèi)容、選擇的模型、響應(yīng)結(jié)果、耗時)、關(guān)鍵性能指標(biāo)(如延遲、Token消耗、錯誤率)的監(jiān)控，以及端到端的鏈路追蹤。通過可觀測性，企業(yè)可以快速定位問題、分析成本構(gòu)成、洞察用戶行為，并為模型的選擇策略提供數(shù)據(jù)驅(qū)動的優(yōu)化依據(jù)。8.MCP代理：面向MCPServer,提供MCPServer代理、安全認(rèn)證，以及統(tǒng)一觀測、限流等治理能力，同時支持將RESTAPI直接轉(zhuǎn)化成MCPServer,提供協(xié)議卸載能力，將SSE轉(zhuǎn)換為StreamableHTTP,避免無狀態(tài)應(yīng)用也要使用SSE。9.工具的動態(tài)組裝：當(dāng)請求攜帶大量工具通過AI網(wǎng)關(guān)時，通過Query改寫及Rerank模型將大量工具進(jìn)行壓縮，再轉(zhuǎn)發(fā)給LLM,可大幅降低調(diào)用耗時，并在一定程度上增加工具選取的準(zhǔn)確性。10.工具的智能路由：將用戶注冊在AI網(wǎng)關(guān)的大量MCPServer、工具進(jìn)行集合，以MCP或其他形態(tài)提供語義搜索能力，客戶端只需要集成這個工具即可基于用戶Query,動態(tài)搜索出最符合需求的N個工具。綜上所述，不管是構(gòu)建企業(yè)級的SingleAgent亦或是MultiAgent,多模型代理、消費(fèi)者認(rèn)證、多模型Fallover、可觀測等都已經(jīng)成為AI應(yīng)用的通用訴求，根據(jù)以往的軟件演進(jìn)經(jīng)驗(yàn)，這些通用訴求的最佳載體就是網(wǎng)關(guān)，正如微服務(wù)網(wǎng)關(guān)統(tǒng)一解決了微服務(wù)的外部認(rèn)證鑒權(quán)、服務(wù)發(fā)現(xiàn)、微服務(wù)容災(zāi)等，AI網(wǎng)關(guān)也是幫助企業(yè)快速構(gòu)建AI應(yīng)用的最佳實(shí)踐。AI網(wǎng)關(guān)經(jīng)過持續(xù)的技術(shù)演進(jìn)，其原子能力已經(jīng)非常豐富，可以總結(jié)為面向LLM、Agent、MCP和AI開放平臺四大類。通過服務(wù)開源社區(qū)用戶和云上商業(yè)客戶的AI網(wǎng)關(guān)落地，我們總結(jié)了8類常見的實(shí)踐，多模型代理、消費(fèi)者認(rèn)證、內(nèi)容安全防護(hù)、Token限流、語義緩存、多模型容AI網(wǎng)關(guān)經(jīng)過持續(xù)的技術(shù)演進(jìn)，其原子能力已經(jīng)非常豐富，可以總結(jié)為面向LLM、Agent、MCP和AI開放平臺四大類。通過服務(wù)開源社區(qū)用戶和云上商業(yè)客戶的AI網(wǎng)關(guān)落地，我們總結(jié)了8類常見的實(shí)踐，多模型代理、消費(fèi)者認(rèn)證、內(nèi)容安全防護(hù)、Token限流、語義緩存、多模型容災(zāi)、多模型可觀測和AI開放平臺，看看這些實(shí)踐是如何借助AI網(wǎng)關(guān)的能力去滿足實(shí)際的業(yè)務(wù)需需求場景◆多模態(tài)業(yè)務(wù)整合場景，企業(yè)需同時處理文本、圖像、音頻、3D等多模態(tài)數(shù)據(jù)。研發(fā)、產(chǎn)品團(tuán)隊(duì)對推理能力強(qiáng)的模型需求多；客服、營銷、平面設(shè)計等團(tuán)隊(duì)對圖片大模型的場景需求多；工業(yè)設(shè)計、影視制作團(tuán)隊(duì)對音視頻大模型的場景需求多?！羝髽I(yè)業(yè)務(wù)覆蓋多個垂直領(lǐng)域，需針對不同行業(yè)特性調(diào)用專用模型。尤其是供應(yīng)鏈端的企業(yè)往往服務(wù)多個行業(yè)，可能會涉及多款垂直行業(yè)的大模型需求?！魪?fù)雜任務(wù)協(xié)同場景，單一任務(wù)需多個模型分工協(xié)作以提升效果。多個大模型員工協(xié)同生成內(nèi)容才能起到最佳效果?！舭踩c效率雙重要求場景，例如醫(yī)療機(jī)構(gòu)的場景，處理患者數(shù)據(jù)使用專屬私有模型分析，其他和患者無關(guān)的需求使用通用模型，避免敏感數(shù)據(jù)和非敏感數(shù)據(jù)在寫入數(shù)據(jù)庫混存。多模型代理的核心價值業(yè)務(wù)需求適配：根據(jù)業(yè)務(wù)復(fù)雜性或性能要求選擇不同模型?！魯?shù)據(jù)隱私與合規(guī)性：在處理敏感數(shù)據(jù)時，可能需要切換到符合特定法規(guī)的模型，確保數(shù)據(jù)處理的安全性。◆性能優(yōu)化：根據(jù)實(shí)時性能需求，可能會切換到更快的模型以減少延遲?！舫杀九c性能平衡：根據(jù)預(yù)算動態(tài)選擇性價比最優(yōu)的模型◆領(lǐng)域特定需求：針對特定領(lǐng)域(如法律、醫(yī)學(xué)),可能需要切換到在相關(guān)領(lǐng)域微調(diào)過的模型，以提高推理準(zhǔn)確性?！羧轂?zāi)與故障轉(zhuǎn)移：主模型服務(wù)異常時快速切換備用模型。2.消費(fèi)者認(rèn)證需求場景多租戶模型服務(wù)分租場景：企業(yè)為不同部門或團(tuán)隊(duì)提供共享的大模型服務(wù)時，會通過APIKey區(qū)分租戶，確保數(shù)據(jù)隔離和權(quán)限管控。具體要求包括：◆支持租戶自定義模型參數(shù)(如溫度系數(shù)、輸出長度),但需通過網(wǎng)關(guān)校驗(yàn)權(quán)限。◆基于RBAC(基于角色的訪問控制)限制敏感功能(如模型微調(diào)、數(shù)據(jù)導(dǎo)出)。記錄操作日志并關(guān)聯(lián)用戶身份，滿足內(nèi)部審計需求。例如，醫(yī)療健康信息交互：電子病歷生成內(nèi)容，防止泄露患者隱私(如身份證號、診斷記錄),確保AI生成的醫(yī)療建議符合相關(guān)法規(guī)。通過多模態(tài)大模型識別醫(yī)療影像中的敏感信息，并結(jié)息。對AI生成的推薦內(nèi)容(如短視頻標(biāo)題、評論)進(jìn)行合規(guī)性檢查。雖然企業(yè)內(nèi)部使用，不會頻繁存在并發(fā)的需求，但通過設(shè)置限流能力，可以更經(jīng)濟(jì)的配置硬件資源。例如一家10000人的企業(yè)，不需要配置同時支持10000人上線的硬件資源，只需要配置7000人的硬件資源，超出部分進(jìn)行限流，避免資源閑置。其他需求包括：防止惡意使用：通過限制Token數(shù)量來減少垃圾請求或攻擊。5.語義緩存多大模型API服務(wù)定價分為每百萬輸入tokensX元(緩存命中)/Y元(緩存未命中),X遠(yuǎn)低于Y,以通義系列為例，X僅為Y的40%,通過在內(nèi)存數(shù)據(jù)庫中緩存大模型響應(yīng)，并以網(wǎng)關(guān)插◆高頻重復(fù)性查詢場景：客服系統(tǒng)、智能助手等◆固定上下文多次調(diào)用場景：法律文件分析(如合同條款解讀)、教育教材解析(如知識點(diǎn)問◆復(fù)雜計算結(jié)果復(fù)用場景：數(shù)據(jù)分析與生成場景(如財報摘要、科研報告生成),對相同數(shù)據(jù)◆RAG(檢索增強(qiáng)生成)場景中：緩存知識庫檢索結(jié)果(如企業(yè)內(nèi)部FAQ),加速后續(xù)相似查提高效率：如果相同的輸入反復(fù)出現(xiàn)，緩存可以避免重復(fù)運(yùn)行模型，從◆模型自身特性引發(fā)的異常：大模型生成結(jié)果存在概率性波動，導(dǎo)致存在隨機(jī)性輸出不穩(wěn)定的情況；發(fā)布新版本導(dǎo)致的流量有損。用戶使用不規(guī)范導(dǎo)致的異常：使用者請求參數(shù)不符合API規(guī)范，導(dǎo)致連接超時或中斷，或者輸入包含惡意構(gòu)造的提示詞，觸發(fā)模型安全防護(hù)機(jī)制，返回空結(jié)果或錯誤碼。資源與性能限制：請求頻次過高，觸發(fā)限流策略，導(dǎo)致服務(wù)不可用，長請求占用過多內(nèi)導(dǎo)致后續(xù)請求被阻塞，最終導(dǎo)致超時。當(dāng)主LLM服務(wù)因?yàn)楦鞣N原因出現(xiàn)異常，不能提供服務(wù)時，網(wǎng)關(guān)側(cè)可以快速將請求Fallback到配置的其他LLM服務(wù)，雖然可能推理質(zhì)量有所下降，但是保證了業(yè)務(wù)的持續(xù)性，爭取了排查主LLM服務(wù)的時間?！粝蘖髦笜?biāo)：每單位時間內(nèi)有多少次請求因?yàn)橄蘖鞅粩r截，限流消費(fèi)者統(tǒng)計(是哪些消費(fèi)者在被限流)。從0開始構(gòu)建，可能需要：◆開發(fā)一套完整的門戶系統(tǒng)(>3個月):從UI/UX設(shè)計到前后端開發(fā)?！鬉I開放平臺管理后臺(for管理員/運(yùn)營):在這里將底層的模多樣化的AI能力，以API的形式輕松打包成標(biāo)準(zhǔn)化的“AI產(chǎn)品”,并配上完善的文檔、示例，最A(yù)I原生應(yīng)用架構(gòu)白皮書6.4使用AI網(wǎng)關(guān)快速構(gòu)建AI應(yīng)用ChatGPT-Next-Web</ChatGPTNextWeb/ChatGPT-Next-Web>是一個問以及ChatGPT-Next-Web,演示如何逐步搭建一個體系完整的AI應(yīng)用，該應(yīng)用的架構(gòu)如圖可觀測安全可觀測安全al-proxy通義千問立消費(fèi)者認(rèn)證SLMs(小參數(shù)模型)代AI安全護(hù)欄Al內(nèi)容審核阿里云AI安全護(hù)欄第三方SaaS服務(wù)A可觀測GoogleAI插件編輯器插件編程AI助手插件編程WebIDE多模型多模型多模態(tài)模型MCPClient身份認(rèn)證Al開發(fā)插件集多模型協(xié)議多模型適配理插件已AI原生應(yīng)用架構(gòu)白皮書AI代理插件實(shí)現(xiàn)了基于OpenAlAPI契約的AI代理功能。HigressAI代理插件目前支持的模型有：通義千問、DeepSeek、OpenAI、AnthropicClaude、AzureOpenAI譜Al、百川智能、零一萬物、Ollama、Groq。插件的詳細(xì)描述見社區(qū)文檔：/alibaba/higress/blob/main/plugins/wa應(yīng)用架構(gòu)首先，我們先通過網(wǎng)關(guān)快速部署一個可以進(jìn)行對話的聊天應(yīng)用，其架構(gòu)如下圖所示：api規(guī)范clientwebuiai-proxy端口DNS域名已發(fā)布http://*/api/openai/v1/chat/completions/*→qwen已發(fā)布第六章：Al網(wǎng)關(guān)插件配置置路由級插件規(guī)則，選擇在LLM路由下生效，配置如下：123456789插件效果共2條對話AI原生應(yīng)用架構(gòu)白皮書第六章：Al網(wǎng)關(guān)提供AI可觀測基礎(chǔ)能力，包括Metric、Log和Trace,其后需接ai-proxy插件，如果不接ai-proxy插件的話，則需要用戶進(jìn)行相應(yīng)配置才可生效。具體插件的詳細(xì)描述見社區(qū)文檔：/alibaba/higress/blob/main/plu應(yīng)用架構(gòu)現(xiàn)在，我們已經(jīng)有了基礎(chǔ)的對話功能，作為一款網(wǎng)關(guān)產(chǎn)品，我們希望在網(wǎng)關(guān)這個統(tǒng)一的入口處對各個服務(wù)、路由的請求情況進(jìn)行觀測?？紤]到LLM請求主要以Token為觀測目標(biāo)，網(wǎng)關(guān)提供了對Token的觀測機(jī)制，包含路由級、服務(wù)級、模型級的Token用量觀測?，F(xiàn)在，我們改變上文的應(yīng)用架構(gòu)，插入可觀測插件，改造后如下圖所示：插件配置依然是選擇在LLM這條路由上生效，插件配置如下：▽1插件效果513.42:0013:4通過對接阿里云內(nèi)容安全檢測大模型的輸入輸出，保障AI應(yīng)用內(nèi)容合法合規(guī)。插件的詳細(xì)描述/alibaba/higress/blob/main/plugins/wasmgo/e應(yīng)用架構(gòu)大模型通常是通過學(xué)習(xí)互聯(lián)網(wǎng)上廣泛可用的數(shù)據(jù)來訓(xùn)練的，它們有可能在過程中學(xué)習(xí)到并復(fù)現(xiàn)有害內(nèi)容或不良言論，因此，當(dāng)大模型未經(jīng)過適當(dāng)?shù)倪^濾和監(jiān)控就生成回應(yīng)時，它們可能產(chǎn)生包含有害語言、誤導(dǎo)信息、歧視性言論甚至是違反法律法規(guī)的內(nèi)容。正是因?yàn)檫@種潛在的風(fēng)險，大模型中的內(nèi)容安全就顯得異常重要。基于AI內(nèi)容安全插件，通過簡單的配置即可對接阿里云內(nèi)容安全</document_detail/28417.html>,為大模型問答的合規(guī)性保駕護(hù)航。AI原生應(yīng)用架構(gòu)白皮書client-webuiai內(nèi)容安全ai可觀測ai-proxy通義千問 DNS域名YAMLYAML復(fù)制代碼插件效果有什么可以幫你的嗎內(nèi)容安全4親對話2024/7/214;52:39你是誰?我是通義千問，由阿里云開發(fā)的AI助手。我被設(shè)計用來回答各種問題、提供信息和與用戶進(jìn)行對話。有什么介紹一下圣經(jīng)作為AI助手，我不能提供涉及政治、宗教、色情、暴力等相關(guān)信息。如果您還有其他問題需要幫助，可以繼續(xù)提出。Enter發(fā)送，Shift+Enter換行，/觸發(fā)補(bǔ)全，:觸發(fā)命令◎新的聊天發(fā)送登錄阿里云內(nèi)容安全控制臺，可以查看每條請求的審計記錄：OSs迷規(guī)檢測普惠版結(jié)束日期起始日期B請選擇結(jié)束日期起始日期B請選擇詞庫管理結(jié)果重詢插件實(shí)現(xiàn)了基于特定鍵值實(shí)現(xiàn)Token限流，鍵值來源可以是URL參數(shù)、HTTP請求頭、客戶端詳細(xì)描述見社區(qū)文檔：/alibaba/higress/blob/main/plugins/wasm應(yīng)用架構(gòu)查詢是否有token余額檢測結(jié)果限流返回LLM生成內(nèi)容端口服務(wù)來源◎健康固定地址AI原生應(yīng)用架構(gòu)白皮書api規(guī)范token限流ai內(nèi)容安全ai可觀測ai-proxyYAMLYAML復(fù)制代碼3-limit_by_9service13rejected_msg:您的請求頻率過高，請稍后再試。429,響應(yīng)body為“您的請求頻率過高，請稍后習(xí)語言的各種模式和關(guān)聯(lián)。2.參數(shù)學(xué)習(xí)：在訓(xùn)練過程中，模型的每一層都會調(diào)整權(quán)重，以便最小化它對輸入文本與輸出文本匹配度的預(yù)測誤差。這是個深度學(xué)習(xí)過程，利用反向傳播算法迭代優(yōu)化。3.語言理解：當(dāng)你輸入一個問題或者一段文字時，模型會根據(jù)之前學(xué)到的知識，利用自上而下的方式預(yù)測最有可能的接續(xù)詞語或整個句子。4.生成輸出：對于開放性問題，模型可能會生成多段連貫的文字作為回答；對于有明確指令的任務(wù)，則可能直接生成符合要求的答案。5.評估：大語言模型通常使用多種指標(biāo)來評估性能，比如困感度(perplexity)和交叉熵?fù)p失，但主要依賴于人類主觀評價，確保生成內(nèi)容的自然度和相關(guān)性。代表性的大語言模型有GPT、BERT、T5等，這些模型不斷推動著自然語言處理領(lǐng)域的發(fā)展，使得AI在交互性和創(chuàng)造力方面有了很大提升。不過需要注意的是，因?yàn)榇笳Z言模型是基于過往數(shù)據(jù)訓(xùn)練的，所以對于未知領(lǐng)域的信息可能存在一定程度的偏差或誤解。介紹一下大語言模型您的請求頻率過高，請稍后再試。9Enter發(fā)送，Shift+Enter換行，/觸發(fā)補(bǔ)全，融發(fā)命令效端機(jī)器學(xué)習(xí)4澆對語2024/7/216:50:08◎◎新的聊天共6.4.5AI緩存/alibaba/higress/blob/main/plug可觀測限流ai內(nèi)容可觀測限流ai內(nèi)容4timeo共62條對話/alibaba/higress/blob/main/plugins/wasm模型就無法獲取或?qū)W習(xí)新的信息。此外，大型語言模型的訓(xùn)練數(shù)據(jù)雖然浩如煙海，但仍然有可能缺少某些領(lǐng)域的信息，或者對某些主題的覆蓋不夠深入，針對這些細(xì)領(lǐng)域的查詢可能會產(chǎn)生不夠精確或缺乏深度的結(jié)果。檢索增強(qiáng)生成(RAG)技術(shù)能夠利用檢索系統(tǒng)從大規(guī)模的數(shù)據(jù)庫中找到相關(guān)信息，然后將這些信息提供給文本生成模型以幫助生成更精確、更豐富、更符合實(shí)可觀測可觀測通義千問通義千問插件需要配置百煉中DashScopeSDK和向量檢索服務(wù)DashVector的相關(guān)信息：4servicePort:44357apiKey:sk-xxxxxxxxxxxxxxxxxxxxxx10domain:vrs-cn-xxxxxxxxxxxxxx.da新的聊天共2條對話共2條對話四面具88插件新的聊天2條對話20247121923:17發(fā)送發(fā)送Prompt模板允許用戶在網(wǎng)關(guān)定義一系列LLM請求的模板，使用者通過指定模板中的參數(shù)對12123456789專家，你平時使用的編程語言為{{language}}"程序，你的返回結(jié)果里面應(yīng)該只包含python代碼"專家，你平時使用的編程語言為{{language}}"程序，你的返回結(jié)果里面應(yīng)該只包含python代碼"content:"幫我寫一個{{program}}{"program":"冒泡排序",}}1234567Prompt裝飾器允許用戶在網(wǎng)關(guān)定義對Pompt的修改操作，包括在原始請求之前和之后插入message,配置示例如下，請求Body與OpenAI的請求一致。12123456Al請求/響應(yīng)智能轉(zhuǎn)換AI請求響應(yīng)轉(zhuǎn)換插件，可通過LLM對請求/響應(yīng)的Header以及Body進(jìn)行修改。插件詳細(xì)文檔：/alibaba/higress/blob/main/plugins/w請求響應(yīng)轉(zhuǎn)換插件支持對請求/響應(yīng)進(jìn)行智能轉(zhuǎn)換，其工作流程如下圖所示(示例中后端服務(wù)網(wǎng)關(guān)網(wǎng)關(guān)LLM原始請求原始請求修改后的請求修改后的請求原始響應(yīng)原始響應(yīng)修改后的響應(yīng)修改后的響應(yīng)Prompt模板允許用戶在網(wǎng)關(guān)定義一系列LLM請求的模板，使用者通過指定模板中的參數(shù)對LLM進(jìn)行訪問，配置示例如下：插件配置YAMLYAML復(fù)制代碼3prompt:"幫我修改以下HTTP應(yīng)答信息，要求：1.content-type修改為application/json;2.body由xml轉(zhuǎn)化為json;3.移除content-length。"6domain:d7apiKey:sk-xXXXxXXXXxXXXXXXXX此插件可用于修改經(jīng)過網(wǎng)關(guān)的請求/響應(yīng)內(nèi)容，例如將XML格式的響應(yīng)修改為json格式。1<?xmlversion2413<title>Wake{6{{,]}]}}234789AI應(yīng)用正在越過“聊天即產(chǎn)品”的早期階段，進(jìn)入以任務(wù)完成為可解釋性同步提升。在企業(yè)加速數(shù)據(jù)驅(qū)動轉(zhuǎn)型的背景下，生成式AI與AIAgent快速一入口，將開發(fā)、上架、訂閱、計費(fèi)與治理貫通起來，讓Agent能像云服務(wù)與應(yīng)用一樣被標(biāo)準(zhǔn)化消費(fèi)。隊(duì)與廠商的封裝里，參數(shù)規(guī)范、錯誤語義與調(diào)用生命周期各說各話，導(dǎo)致復(fù)用性差、可靠性不再疊加跨云遷移的高成本與治理缺位(權(quán)限、審計、SLA、合規(guī)難一體化),任何嘗試構(gòu)建可持續(xù)的商業(yè)閉環(huán)都會被運(yùn)營摩擦吞噬。破解之道是以AI網(wǎng)關(guān)為中樞，協(xié)議化承載模型、工具、數(shù)據(jù)與工作流，把“能用什么、怎么用、怎么計費(fèi)與如何被治理”一并納入平臺底座。Al網(wǎng)關(guān)負(fù)責(zé)抽象并統(tǒng)一上游推理與下游工具，提供穩(wěn)定的路由、編排與策略面；協(xié)議層對工具與資源進(jìn)行自描述，收斂參數(shù)、錯誤與權(quán)限語義，消弭供應(yīng)商差異；在此基礎(chǔ)上，以API貨幣化為抓手，構(gòu)建可計量、可計費(fèi)、可分治理”的閉環(huán)。Product管理/API管理Document管理多維度API調(diào)用觀測Nacos上圖所示是開源項(xiàng)目HiMarketAl開放平臺的三層架構(gòu)，底座是AI網(wǎng)關(guān)/Nacos基礎(chǔ)設(shè)施，承載ModelAPI/AgentAPI與MCPServer的統(tǒng)一接入、注冊與發(fā)現(xiàn)其上是AI開放平臺后臺，負(fù)責(zé)Portal管理(域名、樣式、審批策略)、API與文檔管理、可見性與策略管理、身份認(rèn)證與RBAC、訂閱與審計，以及多維API調(diào)用觀測，作為企業(yè)級后臺把開發(fā)、運(yùn)營與合規(guī)織成閉環(huán)。HiMarket開源地址：/hig從上圖中我們看到，AI網(wǎng)關(guān)是Al開放平臺的底層基礎(chǔ)設(shè)施。AI網(wǎng)關(guān)在入口實(shí)現(xiàn)身份鑒別、租戶隔離與最小權(quán)限授權(quán)，在數(shù)據(jù)路徑上完成脫敏、駐留與加密，在推理路徑上進(jìn)行模型路由、降級與并行編排，并以統(tǒng)一錯誤模型與重試策略提升魯棒性。對于工具與資源，網(wǎng)關(guān)鼓勵以標(biāo)準(zhǔn)Schema自描述輸入輸出、標(biāo)注冪等與副作用等級，支持流式與異步調(diào)用、長文檔的資源引用與分頁傳輸，從而既降低上下文成本，又提升可復(fù)現(xiàn)性與可調(diào)度性。6.5.3API貨幣化API貨幣化是市場成立的前提。首先讓一切可被度量：請求次數(shù)、輸入輸出token、推理時長、并行度、外部工具直通成本都需被精準(zhǔn)采集與歸因，形成統(tǒng)一賬單與成本畫像，完成AI資產(chǎn)的分賬訴求。隨后基于這些指標(biāo)設(shè)計價格計劃：按量與訂閱并存，支持企業(yè)合約、試用額度與超額計費(fèi)；對復(fù)雜工作流可提供“每次運(yùn)行”或“每任務(wù)完成”的計價模式。對于分成引擎來說，則將平臺費(fèi)、開發(fā)者收益與第三方工具直通費(fèi)透明拆分，實(shí)現(xiàn)可持續(xù)的生態(tài)激勵。6.5.4API開發(fā)者門戶開發(fā)者文檔①需要幫助?開始集成面向開發(fā)者，Agent開放平臺提供自助式上架到變現(xiàn)的全鏈路體驗(yàn)。開發(fā)者在門戶完成能力注冊、參數(shù)與權(quán)限聲明、版本與依賴管理、測試與基準(zhǔn)評測，隨后配置價格與分成策略，提交上線審核。平臺回饋用量、收入與質(zhì)量指標(biāo)，并提供問題排查、回放與A/B路由工具，幫助持續(xù)優(yōu)化可靠性與單次任務(wù)成本。這樣，開發(fā)者的能力沉淀為可交易的“Agent商品”,擺脫一次性交付的天花板。6.5.5Agent市場面向企業(yè)客戶，Agent市場提供統(tǒng)一目錄與受控分發(fā)。企業(yè)可在同一控制臺選擇通用或垂直Agent,綁定自身數(shù)據(jù)源與權(quán)限策略，配置配額、預(yù)算與費(fèi)控閾值，獲得透明的SLA、審計軌跡與合規(guī)模塊。對于有特殊安全訴求的客戶，平臺可支持私有化部署或私域市場形態(tài)，讓采購、集成與運(yùn)維遵循既有的IT治理流程，同時保留跨云與多模型的可移植性。1.治理是Agent市場可持續(xù)的底線工程平臺需要將內(nèi)容安全、越權(quán)與注入檢測、異常用量風(fēng)控與反作弊、數(shù)據(jù)出境與駐留策略、可撤回與刪除權(quán)等內(nèi)化為默認(rèn)能力，以策略即代碼的方式統(tǒng)一配置與審計。通過可觀測性與分布式追蹤，將每一次工具調(diào)用、模型選擇與策略判定記錄為可回放的事實(shí)，為問題定位、成本優(yōu)化與合規(guī)稽核提供依據(jù)。2.跨云與可移植性關(guān)乎長期彈性與議價能力通過協(xié)議化的工具與資源層，以及模型無關(guān)的路由策略，平臺可以在不同模型與云環(huán)境之間進(jìn)行性能與成本基準(zhǔn)，對關(guān)鍵工作負(fù)載實(shí)施多活或按需切換。在同等能力下，選擇更具性價比或更合規(guī)的供應(yīng)商無需重寫上層Agent,只需調(diào)整路由與策略，真正做到“能力一次接入，處處3.隨著供給與需求的雙側(cè)累積，Agent市場會形成正向飛輪更多高質(zhì)量工具與數(shù)據(jù)接入，催生更強(qiáng)的復(fù)合型Agent;更好的體驗(yàn)提升轉(zhuǎn)化與復(fù)購，帶來更高分成與開發(fā)者收入；收益驅(qū)動更多供給入場，市場規(guī)模與品類擴(kuò)展進(jìn)一步增強(qiáng)平臺護(hù)城河。平臺可在此基礎(chǔ)上引入評測榜單、企業(yè)認(rèn)證與行業(yè)模板，降低選擇成本，鼓勵“拿來即用”的場景化組合。API和Agent的貨幣化絕不是“加個計費(fèi)按鈕”,而是一套以AI網(wǎng)關(guān)為中樞、以協(xié)議為通用語言、以市場為分發(fā)載體的系統(tǒng)工程。它把分散在各處的模型、工具與數(shù)據(jù)，重塑為可發(fā)現(xiàn)、可計價、可治理的商品與服務(wù)：平臺方獲得新的營收曲線與網(wǎng)絡(luò)效應(yīng)，開發(fā)者獲得持續(xù)變現(xiàn)通道，企業(yè)獲得統(tǒng)一、安全、可移植的智能入口。隨著生態(tài)成熟與最佳實(shí)踐沉淀，這樣的開放平臺會像城市的主干道，連接起智能供給與業(yè)務(wù)價值的每一處場景。203AINative203AINativeApplicationArchitectureAITools信息技術(shù)的發(fā)展史，是一部計算范式不斷演進(jìn)的歷史。從大型機(jī)時代的集中式計算，到客戶端-服務(wù)器架構(gòu)的分布式計算，再到過去十年由微服務(wù)和容器化技術(shù)定義的云原生時代，每一次范式的躍遷，都旨在解決前一個時代的根本性矛盾，并釋放出新的生產(chǎn)力。如今，我們正站在第四次計算浪潮的黎明AI原生時代。云原生時代的核心是應(yīng)用。我們圍繞應(yīng)用構(gòu)建了以Kubernetes為事實(shí)標(biāo)準(zhǔn)的容器編排系統(tǒng)，以阿里云函數(shù)計算為代表的無服務(wù)器計算(Serverless/FaaS),以及一套完整的CI/CD、可觀測性和服務(wù)治理理論。這些技術(shù)的共同目標(biāo)是：將單體應(yīng)用拆解為更小、更獨(dú)立、更具彈性的微服務(wù)，并高效地在云基礎(chǔ)設(shè)施上進(jìn)行部署、擴(kuò)展和管理。這個范式取得了巨大的成功，但其核心假設(shè)仍然是：計算任務(wù)是由人類預(yù)先編寫的、邏輯確定的代碼驅(qū)動的。的行為不再由確定性的代碼邏輯嚴(yán)格限定，而是由一個宏大的目標(biāo)和一個或多個模型所驅(qū)動。它能夠自主地進(jìn)行規(guī)劃、推理、決策，并調(diào)用外部工具來與數(shù)字世界和物理世界進(jìn)行交互，以達(dá)成指定目標(biāo)。一個AI軟件工程師Agent的工作流，不再是執(zhí)行一段固定的main()函數(shù)，而是一個動態(tài)的、長周期的、充滿不確定性的“思考-行動”循環(huán)。這種根本性的轉(zhuǎn)變，使得我們開始重新審視云原生時代構(gòu)建的基礎(chǔ)設(shè)施。為運(yùn)行持久化應(yīng)用而設(shè)計的虛擬機(jī)和傳統(tǒng)容器，因其沉重的資源占用、緩慢的啟動速度和高昂的閑置成本，無法適應(yīng)Agent所需的極致彈性和成本效益。而為處理確定性、無狀態(tài)、短周期的HTTP請求而設(shè)計的傳統(tǒng)Serverless架構(gòu)，也無法承載一個需要數(shù)小時上下文記憶、擁有完整文件系統(tǒng)、并能與瀏覽器進(jìn)行復(fù)雜交互的Agent。我們需要為AI應(yīng)用而生的原生運(yùn)行時。從為了更清晰地理解Al原生應(yīng)用的需求，我們以云上企業(yè)客戶落地AI業(yè)務(wù)場景為例，并嘗試拆解這些典型應(yīng)用的業(yè)務(wù)行為。場景一：交互式智能內(nèi)容創(chuàng)作助手◆場景描述：市場營銷科技公司的經(jīng)理在一個富文本編輯器中輸入初稿，AI助手可以實(shí)時地進(jìn)行潤色、擴(kuò)寫、總結(jié)。它還能進(jìn)一步執(zhí)行指令，如“幫我配一張科技感的頭圖”、“將這段翻譯成◎多輪對話：整個創(chuàng)作過程是一個持續(xù)的多輪人機(jī)交互會話。上下文記憶：AI必須記住之前的文稿版本、用戶的修改指令和偏好，才能提供連貫的創(chuàng)作風(fēng)格的圖片，可能需要依賴對公司素材進(jìn)行微調(diào)后的垂類模型，并將其托管在如ComfyUI這樣的服務(wù)上。異構(gòu)任務(wù)流：這個過程混合了多種任務(wù)。文本潤色前的內(nèi)容預(yù)處理，然后交給LLM,而配圖則需要調(diào)用文生圖的擴(kuò)散模型。流式響應(yīng)：為了更好的用戶體驗(yàn)，AI的回答，特別是長文本，需要像打字機(jī)一樣逐字流式場景二：個性化AI客服◆場景描述：某電商平臺的“主動式導(dǎo)購Agent”。當(dāng)一個用戶在某個昂貴的商品頁面停留超過3分鐘，并反復(fù)查看評論和規(guī)格時，AIAgent不是被動等待提問，而是主動發(fā)起對話：“您好!我是您的專屬AI導(dǎo)購……”。②事件驅(qū)動：Agent的啟動是由復(fù)雜的業(yè)務(wù)事件(如用戶行為日志、定時器)觸發(fā)的，而不是簡單的API請求。◎企業(yè)數(shù)據(jù)：在發(fā)起對話前，Agent需要瞬間拉取并整合多個數(shù)據(jù)源：用戶的歷史訂單(CRM)、商品知識庫(向量數(shù)據(jù)庫)、實(shí)時庫存(ERP)等。實(shí)時在線：Agent需要全天候在線，隨時準(zhǔn)備響應(yīng)觸發(fā)事件。場景三：通用Agent平臺+病毒式傳播的AIGC創(chuàng)意應(yīng)用◆場景描述：某科技企業(yè)是國內(nèi)一家頭部的基礎(chǔ)大模型服務(wù)公司，利用自己的大模型結(jié)合面向C端的Agent平臺開展全棧開發(fā)，讓平臺用戶可以通過提示詞寫出一個完整的項(xiàng)目工程，并且可以一鍵部署和分享出去?！駻gent智能體：通過和用戶對話，根據(jù)用戶輸入，以休閑益智類游戲?yàn)槔?，通過LLM生成游戲項(xiàng)目代碼?！虼a執(zhí)行驗(yàn)證：Agent智能體通過LLM生成代碼，然后需要一個CodeInterpreterSandbox來執(zhí)行驗(yàn)證。Al原生應(yīng)用架構(gòu)白皮書部署與分享：LLM生成的游戲項(xiàng)目完成驗(yàn)證后，用戶可以快速部署為一個獨(dú)立服務(wù)，然后通過分享對外發(fā)布?！蛎}沖式流量：應(yīng)用可能因?yàn)榫W(wǎng)紅的推薦而流量激增，并發(fā)請求在幾分鐘內(nèi)從10個飆升到10000個。從上述真實(shí)實(shí)踐中，我們可以清晰地勾勒出AI應(yīng)用的共同畫像：它們是會話式的、工具增強(qiáng)的、事件驅(qū)動的、異構(gòu)算力的，并且需要極致彈性與精益成本的。這要求運(yùn)行時基礎(chǔ)設(shè)施具備以下核心能力：異構(gòu)算力會話管理安全隔離(請求/會話/函數(shù))內(nèi)置多語言執(zhí)行引擎輕量化函數(shù)細(xì)粒度資源毫秒級彈性GPU算力解耦&1/N切分CPU算力GPU算力xPU算力第七章：應(yīng)用運(yùn)行時此外，Agent的工作模式并非持續(xù)的高強(qiáng)度計算。在漫長的空閑或等待時間里，傳統(tǒng)基礎(chǔ)設(shè)施的計費(fèi)仍在持續(xù)，導(dǎo)致巨大的資源浪費(fèi)。理想的基礎(chǔ)設(shè)施，必須能夠?qū)⒊杀九cAgent的真實(shí)工作量嚴(yán)格掛鉤。平臺需要通過精細(xì)的運(yùn)行時狀態(tài)監(jiān)控和調(diào)度引擎，精確區(qū)分Agent或工具的付費(fèi)。工具和各種沙箱環(huán)境之間需要標(biāo)準(zhǔn)、安全的連接能力。協(xié)議層需要原生支持以MCP、A2A等標(biāo)準(zhǔn)協(xié)議連接智能載體，原生支持流式請求響應(yīng)，并結(jié)合AI網(wǎng)關(guān)提供靈活、安全的訪問鑒權(quán)能力，方便各種組件的集成。此外，平臺還需具備原生異步化處理能力，自動應(yīng)對大規(guī)模的異步請求，并提供平臺錯誤處理能力，以支持Agent及工具常見的長時任務(wù)處理方式。雖免運(yùn)維卻受限于數(shù)據(jù)合規(guī)與定制化瓶頸；自托管(Self-hosted)方案雖可控卻深陷GPU利用率低下、彈性不足、運(yùn)維復(fù)雜的困局。經(jīng)過大規(guī)模生產(chǎn)實(shí)踐驗(yàn)證，Serverless運(yùn)行時成為模型的最優(yōu)解。案例1:景區(qū)AI生圖的資源浪費(fèi)困局某4A景區(qū)設(shè)計師希望為游客照片生成國風(fēng)特效，使用ComfyUI部署繪圖模型。但景區(qū)流量波動極大：節(jié)假日單日處理10萬張圖，平日僅千張。傳統(tǒng)虛擬機(jī)方案被迫包月預(yù)留峰值GPU資源，導(dǎo)致90+%算力閑置，月成本超5萬元。更致命的是，突發(fā)流量時擴(kuò)容>5分鐘，游客排隊(duì)超時投訴激增。案例2:兒童閱讀App的冷啟動災(zāi)難某兒童閱讀平臺用CosyVoice模型生成故事語音。其2萬+繪本中，熱門內(nèi)容日均調(diào)用10萬次，而長尾繪本月均不足10次。自建容器集群無法為低頻模型保持實(shí)例存活，家長點(diǎn)擊冷門繪本時需等待60+s冷啟動，體驗(yàn)斷裂導(dǎo)致用戶流失。案例3:智能家居企業(yè)的定制化困境某智能家居企業(yè)用Qwen模型分析家庭安防視頻。需適配不同硬件終端(攝像頭/門鎖/電視),每個場景需定制化微調(diào)模型。自建laas平臺每次部署新模型需配置GPU環(huán)境、壓測驗(yàn)證，迭代周期長達(dá)3天，嚴(yán)重拖慢產(chǎn)品創(chuàng)新速度。當(dāng)AI從實(shí)驗(yàn)室走向萬千真實(shí)企業(yè)場景，傳統(tǒng)方案在成本、彈性和效率上的短板被急劇放大，而Serverless模型運(yùn)行時以無服務(wù)器理念重塑AI生產(chǎn)關(guān)系：◆對開發(fā)者：告別“GPU環(huán)境配置-集群管理-模型部署”的非核心工作，專注場景創(chuàng)新；◆對企業(yè)：破解“不用時浪費(fèi)，用時又不足”的算力悖論，使規(guī)?；辉侔殡S成本失控；對產(chǎn)業(yè)：當(dāng)景區(qū)設(shè)計師、兒童產(chǎn)品經(jīng)理、智能家居工程師都能輕松用好領(lǐng)域模型，AI應(yīng)用才會真正繁榮。1、異構(gòu)算力和1/N卡切分使用在算力層，Serverless模型運(yùn)行時通過GPU虛擬化技術(shù)將單張GPU顯卡劃分為N個獨(dú)立計算單元，每個實(shí)例具備隔離的顯存空間與算力資源，不同實(shí)例通過GPU分時復(fù)用技術(shù)實(shí)現(xiàn)并行推理，以16GB顯存的Tesla卡系列為例，Serverless模型運(yùn)行時具備將單張卡切分為16個實(shí)例，每個實(shí)例均擁有1GB顯存和1/16算力，使≤1GB的小參數(shù)模型可運(yùn)行在單個實(shí)例，實(shí)例和實(shí)例間互不影響，實(shí)現(xiàn)資源隔離和數(shù)據(jù)隔離，進(jìn)而大幅簡化開發(fā)范式，減少稀缺GPU資源的碎片化浪費(fèi)。Serverless模型運(yùn)行時通過池化技術(shù)，將CPU/GPU/XPU統(tǒng)一納管到一個資源池，開發(fā)者可根據(jù)模型特性按需配置算力類型-語音識別等輕量任務(wù)分配CPU,圖像生成等算力密集型任務(wù)分配GPU碎片，大語言模型等顯存密集型任務(wù)分配GPU整卡或多卡。某服裝企業(yè)實(shí)測顯示，StableDiffusion服務(wù)采用1/8卡虛擬化后，GPU利用率從18%提升至89%,成本降幅達(dá)83.2%,逼近理論極限值87.2%。這種碎片化供給模式，從根本上重構(gòu)了算力經(jīng)濟(jì)模型。2、負(fù)載感知調(diào)度和毫秒級閑置喚醒在調(diào)度層，Serverless模型運(yùn)行時通過負(fù)載感知調(diào)度系統(tǒng)實(shí)時監(jiān)測請求隊(duì)列深度、GPU顯存占用率、實(shí)例健康狀態(tài)等多維指標(biāo)，基于池化技術(shù)構(gòu)建三級響應(yīng)機(jī)制：請求優(yōu)先分配至活躍實(shí)例；當(dāng)資源吃緊時，毫秒級喚醒閑置實(shí)例；僅在極端流量下觸發(fā)冷啟動。其核心技術(shù)突破在于利用CRIU(用戶空間檢查點(diǎn)/恢復(fù))技術(shù)凍結(jié)顯存狀態(tài)，并將顯存數(shù)據(jù)臨時置換至內(nèi)存，并在新的請求調(diào)度前實(shí)現(xiàn)毫秒級/秒級狀態(tài)恢復(fù)，較傳統(tǒng)虛機(jī)/容器方案提速百倍。某語音類應(yīng)用接入后，長尾模型冷啟動延遲從47秒壓縮至0.8秒，流量高峰期的RT抖動減少80%,配套的成本模型使閑置實(shí)例僅按15%標(biāo)準(zhǔn)計費(fèi)，實(shí)現(xiàn)彈性與經(jīng)濟(jì)的平衡。3、集成加速框架和開發(fā)調(diào)試工具鏈在開發(fā)層，Serverless模型運(yùn)行時預(yù)集成加速框架深度優(yōu)化模型運(yùn)行效率：VLLM框架的PagedAttention技術(shù)通過顯存分頁管理提升3倍吞吐量；SGLang的RadixAttention實(shí)現(xiàn)注意力機(jī)制并行編譯，降低60%推理延遲；TensorRT-LLM的量化融合策略提升2倍能效比。開發(fā)工具鏈提供DevPod交互式環(huán)境，開發(fā)環(huán)節(jié)實(shí)現(xiàn)白屏化操作和實(shí)時反饋，集成在線IDE如VSCode/JupyterLab/SSH終端，開發(fā)者在云端環(huán)境具備比本地環(huán)境更高的生產(chǎn)效率；生產(chǎn)部署環(huán)節(jié)實(shí)現(xiàn)革命性簡化--上傳模型文件后，系統(tǒng)在30秒內(nèi)自動生成Dockerfile、構(gòu)建推理服務(wù)、輸出OpenAPI文檔及SDK。某智能家居企業(yè)模型迭代周期因此從3天縮短至30分鐘。企業(yè)級運(yùn)維能力涵蓋金絲雀發(fā)布(支持5%/10%/20%階梯放量)、動態(tài)彈性擴(kuò)展(實(shí)例數(shù)量根據(jù)定時策略或水位策略在0~N間自適應(yīng)調(diào)整)、全觀測體系(實(shí)時追蹤50+指標(biāo)如GPU顯存利用率、SM利用率)等關(guān)鍵特性。這三層技術(shù)并非孤立存在，而是形成深度協(xié)同的模型運(yùn)行時能力增強(qiáng)：GPU碎片化技術(shù)提供原子級算力單元，為智能調(diào)度奠定資源基礎(chǔ)；負(fù)載感知引擎通過毫秒級實(shí)例彈性，將碎片化算力轉(zhuǎn)化為即時服務(wù)能力；開發(fā)工具鏈則構(gòu)建自動化流水線，使技術(shù)紅利直達(dá)開發(fā)者工作臺。某4A景區(qū)實(shí)踐表明，當(dāng)三項(xiàng)技術(shù)疊加應(yīng)用時，AI生圖服務(wù)峰值吞吐量提升12倍，同時成本降低78%。這種協(xié)同效應(yīng)標(biāo)志著AI模型托管從手工作坊時代邁入工業(yè)自動化時代，將企業(yè)從算力枷鎖中解放，重歸業(yè)務(wù)創(chuàng)新的本質(zhì)。從Serverless到ServerlessAI,本質(zhì)是從資源效率優(yōu)化邁向智能生產(chǎn)力釋放。而Serverless模型運(yùn)行時作為承載AI大腦的核心基座，通過異構(gòu)算力革命、智能調(diào)度進(jìn)化、開發(fā)范式升級三重突破，讓企業(yè)真正實(shí)現(xiàn)：所想即所得的模型服務(wù)，無需擔(dān)憂算力枷鎖，專注智能本身，靈活擴(kuò)展和1、“請求-響應(yīng)”模式：無狀態(tài)的事務(wù)性AI任務(wù)在AI應(yīng)用的早期階段，其交互模式很大程度上繼承了傳統(tǒng)Web服務(wù)和微服務(wù)的“請求-響應(yīng)”模型。其核心是執(zhí)行一個獨(dú)立的、原子性的任務(wù)，具有顯著的無狀態(tài)性。這種模式下，AI更像一個高效、自動化的工具，其無狀態(tài)的特點(diǎn)與ServerlessFaaS架構(gòu)非常契合。因?yàn)橛嬎銓邮菬o狀態(tài)的，平臺可以近乎無限地水平擴(kuò)展，通過并行啟動成百上千個獨(dú)立的、可互換的函數(shù)實(shí)例來應(yīng)對流量洪峰，實(shí)現(xiàn)了極高的彈性和容錯性。2、“對話”模式：有狀態(tài)的協(xié)作式AgenticAI應(yīng)用AI應(yīng)用的關(guān)注點(diǎn)從單純驅(qū)動LLM完成指令，轉(zhuǎn)移到了如何利用外部工具和知識庫構(gòu)建更加智能的交互式智能體(Agent),一個任務(wù)需要經(jīng)歷多輪交互才能最終完成，具有顯著的會話特征。從事務(wù)性到對話式的轉(zhuǎn)變，應(yīng)用的用戶界面發(fā)生了很大的變化，會話上下文貫穿整個交互的生命周期。在Agent應(yīng)用中，會話狀態(tài)的持久化及會話執(zhí)行上下文共享，成為了解決Agent應(yīng)用性能的先決條件，應(yīng)用的架構(gòu)優(yōu)先級發(fā)生了根本性變化，會話及狀態(tài)管理成為了架構(gòu)關(guān)注的第一要素。1、圍繞會話請求和資源調(diào)度模型，維持長時運(yùn)行的狀態(tài)延續(xù)Agent運(yùn)行時的架構(gòu)設(shè)計，以會話(Session)作為不可分割的原子單元，構(gòu)建一個原生支持狀態(tài)持久化的大規(guī)模實(shí)時彈性系統(tǒng)。這個目標(biāo)與云原生時代常見的“請求-響應(yīng)”模型形成了鮮明的對比。后者的彈性，本質(zhì)上是一種無狀態(tài)彈性，通過快速復(fù)制無狀態(tài)的計算實(shí)例來應(yīng)對流量變化。然而，在面對需要記憶和上下文共享的Agent應(yīng)用時存在較大的適配負(fù)擔(dān)，狀態(tài)被迫成為需要被外部化管理的包袱。我們認(rèn)為，會話本身，連同其內(nèi)部狀態(tài)，是實(shí)現(xiàn)下一代彈性的核心。因此平臺設(shè)計的出發(fā)點(diǎn)不再是“如何高效地處理一個瞬時請求”,而是“如何將一個完整的、有狀態(tài)的、長周期的Agent會話作為一個整體，進(jìn)行高效、安全、經(jīng)濟(jì)的生命周期管理”。然后將Agent會話(包含其代碼、內(nèi)存、文件系統(tǒng))封裝成一個可凍結(jié)、可恢復(fù)、可遷移的獨(dú)立單元?；谶@種能力，能夠?qū)挼倪壿嬌芷谂c物理計算資源的分配徹底解耦。這種解耦是實(shí)現(xiàn)大規(guī)模實(shí)時彈性的關(guān)鍵。2、實(shí)現(xiàn)面向Active-ldle資源管理，解決長時運(yùn)行的成本困境Active-Idle資源管理，簡單來說就是基于應(yīng)用“忙-閑”時的資源管理，結(jié)合Agent運(yùn)行特征，我們可以將一個會話所需的資源分解為兩個部分，要突破成本困局，本質(zhì)是要提供一種基于會話生命周期的動態(tài)資源解耦方案?！魻顟B(tài)資源：包括持久化文件系統(tǒng)和凍結(jié)的內(nèi)存快照。這些資源的特點(diǎn)是存儲成本低廉。計算資源：包括活躍的VCPU和內(nèi)存。這些資源是昂貴的，也是傳統(tǒng)模型中造成浪費(fèi)的主要Active-ldle模型的核心，就是根據(jù)Agent的實(shí)時活動，動態(tài)地、透明地為會話“掛載”或“卸載”昂貴的計算資源，同時始終保持其廉價的狀態(tài)資源在線。結(jié)合Agent運(yùn)行時需求，本節(jié)將對目前幾種主流解決有狀態(tài)Serverless架構(gòu)模式進(jìn)行系統(tǒng)性的對比分析。它們在性能、成本、復(fù)雜性和可擴(kuò)展性等方面存在顯著的差異。狀態(tài)范圍會話級，內(nèi)存中(脆弱)實(shí)體級，平臺持久化彈性效率極高(按請求獨(dú)立擴(kuò)展)低(破壞水平擴(kuò)展)高(按實(shí)體獨(dú)立擴(kuò)展)高(函數(shù)本身無狀態(tài))低(實(shí)例故障導(dǎo)致狀態(tài)丟失)高(狀態(tài)由平臺持久化保證)中(受網(wǎng)絡(luò)延遲影響)高(內(nèi)存訪問)中(持久化狀態(tài)訪問有開銷)開發(fā)復(fù)雜度中(需手動管理狀態(tài)讀寫和一致性)高(路由復(fù)雜，狀態(tài)易丟失，調(diào)試?yán)щy)低(狀態(tài)管理由平臺抽象)成本模型置實(shí)例以保證狀態(tài))按操作/狀態(tài)存儲付費(fèi)理想場景遲不敏感的應(yīng)用遷移需要粘性會話的遺留應(yīng)用常常面臨兩個常見的架構(gòu)適配難題而常常被決絕：狀態(tài)解耦編程模型復(fù)雜度高，狀態(tài)外置引入性能和成本問題。◆傳統(tǒng)會話親和：應(yīng)被視為一種過渡性的手段。親和性無法得到保證，屬于盡力親和；同時在會話維度共享實(shí)例，無法提供隔離能力，無論是系統(tǒng)升級，還是業(yè)務(wù)異常，調(diào)度不確定導(dǎo)致應(yīng)用容錯無法保障?！?nèi)置狀態(tài)抽象：架構(gòu)理念先進(jìn)，但需要依賴特定產(chǎn)品能力，同時需要適配狀態(tài)內(nèi)置的編程模型，更適合需要可靠狀態(tài)管理和復(fù)雜工作流編排的場景，并不適合作為編程模型自由度較大的Agent運(yùn)行時。這種架構(gòu)認(rèn)識到，AI應(yīng)用的會話既需要狀態(tài)持久化，又需要高性能的本地計算和會話維度隔離能力。在這種趨勢下，Serverless業(yè)界領(lǐng)導(dǎo)者阿里云和亞馬遜云科技(AWS)不約而同給出了自己的答案：◆阿里云憑借在大規(guī)模、高并發(fā)等極致業(yè)務(wù)場景的實(shí)踐，依托Serverless產(chǎn)品函數(shù)計算突破架構(gòu)邊界，原生提供會話管理能力，支持為每一個用戶會話動態(tài)配置一個專用的、持久化實(shí)例，支持會話維度的動態(tài)掛載實(shí)現(xiàn)存儲隔離，會話綁定的實(shí)例可以持續(xù)存活長達(dá)8小時，未來最長可達(dá)24小時，并能夠保持請求的優(yōu)雅結(jié)束?！鬉WS憑借其先發(fā)優(yōu)勢和對市場的定義能力，發(fā)布了AWSBedrockAgentCore產(chǎn)品作為構(gòu)建AgenticAl應(yīng)用的底層基礎(chǔ)設(shè)施；其核心架構(gòu)創(chuàng)新在于，它為每一個用戶會話動態(tài)配置一個專用的、持久化的實(shí)例，該實(shí)例可以持續(xù)存活長達(dá)8小時。本地文件系統(tǒng)中。這消除了因狀態(tài)與外部系統(tǒng)交互而產(chǎn)生的網(wǎng)絡(luò)延遲，為Agent的多步推理提◆毫秒級的彈性速度：根據(jù)Firecracker官方數(shù)據(jù)，運(yùn)行時底層基于的Mi可以穩(wěn)定在～100毫秒。每個MicroVM的內(nèi)存開銷僅為5MB左右，使得可以在一臺物理服務(wù)器上高密度地運(yùn)行數(shù)千個獨(dú)立的MicroVM實(shí)例，解決會話粒度的實(shí)例彈性問題。這種架構(gòu)可以被稱為Agent原生“會話式”Serverless架構(gòu)，既保留了Serverless的免運(yùn)維、按需擴(kuò)展的優(yōu)勢，又提供了傳統(tǒng)長連接服務(wù)才有的狀態(tài)保持和高性能，在此基礎(chǔ)上同時兼顧了安全性。同時，平臺負(fù)責(zé)解決了Serverless架構(gòu)有狀態(tài)環(huán)境中生命周期管理、業(yè)務(wù)升級會話生命周期管理：計算實(shí)例的生命周期不再是單個請求，而是整個會話。例如，Runtime (刪除)。平臺需要提供API允許開發(fā)者主動管理(如提前終止)這些長生命周期的會話，便所有實(shí)例。平臺需要支持優(yōu)雅升級：新的會話請求被路由到新版本的實(shí)例，而持有舊會話的實(shí)◆匹配運(yùn)行特征的成本模型：通過實(shí)施以會話為中心的Active-ldle資源管理模型，讓開發(fā)者無需關(guān)心底層資源的復(fù)雜管理，就能享受到永遠(yuǎn)在線的會話體驗(yàn)和按真實(shí)計算付費(fèi)的經(jīng)濟(jì)效益，從而解決開發(fā)者和企業(yè)構(gòu)建Agen7.4.1AlAgent與工具：從概念到能力由于AI工具已經(jīng)不再是簡單的API調(diào)用，而是演變?yōu)樾枰獜?fù)雜運(yùn)行時才能管理和安全保障的執(zhí)行環(huán)境。因此，我們先在下表格提煉了Agent常用工具的類型，并進(jìn)一步剖析了它們背后對底(模型上下文協(xié)議)結(jié)構(gòu)化API動態(tài)理解并調(diào)用外部工具。集成。運(yùn)行時具備輕量，彈性(文件搜索/檢索)在預(yù)定義的私有文檔語料庫中高效的向量檢索服務(wù)與運(yùn)行時緊密集成。運(yùn)行時需要具備上(圖像生成)處理的能力，將自然語言描述高性能計算、高效穩(wěn)定的API調(diào)用能力。運(yùn)行時具備異構(gòu)算(代碼解釋器)為模型提供一個有狀態(tài)的、沙箱化的多語言執(zhí)行環(huán)境(Python、Node]s、Go等),用以執(zhí)行復(fù)雜的計算和程序化任務(wù)。這將模型的能力從語言推理擴(kuò)展到邏輯分析領(lǐng)域，使其能夠進(jìn)行量化數(shù)據(jù)分析、算法執(zhí)行和強(qiáng)隔離與安全、持久化會話、(瀏覽器使用)瀏覽器實(shí)例(通常是無頭模式，headlessmode)的能力，以執(zhí)行復(fù)雜的網(wǎng)頁自動化任務(wù)。這超越了簡單的信息搜索，涵網(wǎng)頁元素交互，以及直接從渲染后的網(wǎng)頁內(nèi)容中提取信息。強(qiáng)隔離、會話管理、可觀測性(計算機(jī)使用)(visualagent),直接與計算機(jī)的圖形用戶界面(GUI)進(jìn)行交互。它通過模擬人類的鍵鼠操作用和遺留系統(tǒng)，從而實(shí)現(xiàn)端到端強(qiáng)隔離、具備GUI的完整操作(移動端使用)賦予操作系統(tǒng)更強(qiáng)的語義理解和跨應(yīng)用操作能力，使手機(jī)能夠自主完成復(fù)雜任務(wù)，將手機(jī)轉(zhuǎn)變?yōu)橐粋€能夠真正理解用戶需求的“智能助手”。并需要支持會話管理以保留對話上下文和記憶。云計算基礎(chǔ)設(shè)施正在演進(jìn)，而我們常說的AISandbox,正是一個被嚴(yán)格控制的隔離環(huán)境。它允許Agent在其中安全地執(zhí)行代碼、與應(yīng)用交互和箱技術(shù)在應(yīng)對這種動態(tài)、復(fù)雜且可能具有對傳統(tǒng)無狀態(tài)的FaaS(函數(shù)即服務(wù))設(shè)計產(chǎn)生了根本性沖突。若為每一個潛在的用戶會話都預(yù)置一個成熟的Serverless平臺，特別安全性是AISandbox的基石，其保障始于最底層的物理硬件。例如，阿里云函數(shù)計算采用的安全體系。神龍架構(gòu)通過自研的MOC芯片將虛擬化功能從主CPU卸載，實(shí)現(xiàn)了在共享硬件上其運(yùn)行在擁有獨(dú)立客戶機(jī)內(nèi)核的微型虛擬機(jī)中。這確保了AIAgent生成和執(zhí)行的代碼被完全封型共同構(gòu)建了堅(jiān)固的壁壘。而以函數(shù)計算為代表的AI原生Serverless架構(gòu)通過原生能力解決了這一矛盾。核心能力是強(qiáng)會話親和性(SessionAffinity)、會話物理隔離(SessionIsolation)以及會話管理接口(Session◆強(qiáng)會話親和性：是一個智能路由層，它確保在一次會話的整個生命周期中，所有來自同一客戶端的請求都會被精確地路由到同一個函數(shù)實(shí)例上，從而為每個用戶會話分配了一個固定的函數(shù)實(shí)例，保證了交互的連續(xù)性和上下文的完整性。平臺提供了多種靈活的親和方式，包括專為Agent場景設(shè)計的MCPSSE親和，以及適用于Web場景的HeaderField親和和Cookie親和?！魰捨锢砀綦x：解決了多租戶環(huán)境下的安全問題。在啟用該能力后，平臺會為每一個會話獨(dú)占一個完整的函數(shù)實(shí)