作者：極客有約

前言：

隨着 AI 原生浪潮的到來，智能體（Agent）正成為企業創新的新引擎。然而，在生產環境中大規模落地 Agent，卻面臨開發複雜、運維困難、成本高等挑戰。這些問題應該如何解決？企業內部大規模部署和運維 Agent 是否有捷徑可走？針對這些問題，InfoQ 近日對話了阿里云云原生應用平台 Serverless 計算負責人楊皓然（花名：不瞋），圍繞大規模 Agent 部署和運維的最佳實踐等主題展開討論。

AI 原生時代的 Serverless AI 等於 Serverless 加 AI 嗎？

在 AI 原生時代，Serverless AI 絕不只是把“Serverless + AI”機械相加。AI 原生應用（Agent）具備非確定性推理、長期上下文與工具調用等特性，直接導致基礎設施從無狀態走向有狀態、從同構調度轉向異構編排，並把安全隔離從容器提升到 MicroVM 級別的沙箱。也因此，面向高併發、高稀疏、強隔離的負載形態，Serverless 的價值從“錦上添花”變為“剛需”：以毫秒級喚醒支撐稀疏會話、以精細計量降低長時空閒成本、以平台化能力統籌網關、可觀測與記憶。但這並不意味着“一切皆無服務器”——例如大模型推理更適合 P/D 分離與常駐 GPU 的彈性邊界管理。換言之，Serverless AI 的答案，是以 Serverless 的方式精準擁抱 AI 負載的關鍵環節，用體系化工程完成落地。

InfoQ：很多人都在提 AI 原生，比如 AI 原生應用、AI 原生組織等。您如何理解 AI 原生這個概念？在 AI 原生時代，基礎設施的核心變化是什麼？

楊皓然： 談 AI 原生，首先可能需要定義一下 AI 原生的應用與傳統應用本質上有哪些不同，這些不同決定了運行應用配套的基礎設施所需要的演進。

與傳統應用相比，AI 原生應用（或稱 Agent 應用）確實存在顯著差異。傳統應用的開發方式是由程序員編寫確定性的代碼，程序執行過程和結果都是可預測的。而 AI 原生應用則不同，它內部包含了大量非確定性的指令推理過程。這類應用需要具備主動感知、規劃能力，並能夠調用各種工具來完成模糊的任務目標，而不再像以往那樣，只依賴程序員或應用開發者預先編寫的、固定且精確的執行邏輯。

因此，這催生了基礎設施層面的三大重要變化：

第一，基礎設施所需要支持的主流應用形態，可能正在從過去的“無狀態應用”轉向“有狀態應用”。 在微服務時代，無狀態應用的典型做法是將狀態數據存儲在數據庫或共享存儲中，這樣各微服務實例就可以無狀態的方式啓動和運行；當需要讀取或寫入數據時，再與數據庫或鍵值緩存（KV cache）進行交互。然而，Agent 類應用的情況則不同。它們通常需要在較長時間內維持稀疏但連續的對話，並在此過程中保持上下文信息、連續執行一系列動作。這意味着，底層基礎設施必須能夠以極低的成本、可靠且高效地維持海量的有狀態會話。

第二，任務的調度與編排模式已經從“同構任務”轉變為“異構任務”。 所謂“同構”，指的是傳統微服務體系中，雖然應用或業務邏輯會被拆分為多個微服務並相互調用，但各服務的運行狀態和特徵基本一致，通常都是長期運行的容器實例。然而，在 Agent 應用的模式下，系統的負載特徵呈現出高度的動態性。例如，某一時刻可能處於推理階段，屬於計算密集型任務；下一刻可能需要調用外部 API；再下一刻又可能執行由大模型生成的代碼。這種動態、異構的任務形態與傳統的資源調度方式存在本質差異。後者主要是為長期運行的常駐實例，或為偏離線的一次性執行任務而設計的，這兩類模式在以往的系統中往往是分離的。而在 Agent 場景中，這些任務類型卻需要緊密且無縫地融合在一起。因此，Agent 應用的調度模式必然與傳統體系存在顯著差異。從未來發展來看，若能以“工作流”的視角重新審視整個資源調度體系，並針對這一新模式進行優化，將可能成為重要的發展方向，並帶來顯著收益。

第三，新的 Agent 應用對基礎設施的安全性和隔離性的要求發生了重大轉變。 以往的系統中，使用 Docker 或容器來執行代碼已能滿足需求，因為這些應用通常是可信的，其核心要求只是實現資源和性能層面的隔離即可。但在 Agent 時代，情況明顯不同。由於 Agent 所執行的代碼往往是由大模型自動生成的，其中可能包含潛在的惡意或不可信成分，因此必須在高度隔離的沙箱環境中運行，以確保系統安全。這種變化進一步延伸至更廣泛的層面——從運行時的安全隔離，到數據安全機制的強化，再到整個執行過程中的數據管理與可信性保障。可以説，Agent 應用對基礎設施提出了全新的安全體系要求，這是與傳統應用相比的又一重大區別。

InfoQ：今年 9 月底的雲棲大會上提到的 Serverless AI 到底是什麼意思？它的核心概念是什麼？

楊皓然： 在討論“Serverless AI”這一概念時，我們的團隊內部其實進行了充分的討論，而且這個詞本身也存在一定的爭議。我們最擔心的是，外界會誤以為我們因為從事 Serverless 相關工作，就試圖從這一視角去“迎合”當下的 AI 浪潮。但事實上，情況恰好相反——我們是基於對大量 AI 負載的深入分析，才逐步總結並提出了這一概念。

在這一過程中，我們發現了許多新的技術需求與能力。例如，在 AI 安全方面，傳統基於 runc 的執行環境已經無法滿足要求，必須採用虛擬機級別的隔離方案，如 MicroVM，以提供更強的安全沙箱。同時，Agent 的任務數量與負載動態變化程度遠高於傳統電商類應用。以大模型調用工具為例，這些工具的執行邏輯通常十分輕量，但對隔離強度要求極高，必須運行在不同的沙箱環境中。更復雜的是，這些調用往往呈現出稀疏且不可預測的特性——大模型可能在某一時刻同時調用多個不同的工具，從而產生強烈的動態性與突發性（bursty）負載特徵。所以，我們認為這些負載的模式天然就是 Serverless 或者函數計算模式要去處理的。我們可以用幾個關鍵詞來總結一下，它本質上就是強隔離的、高併發的、高稀疏的負載特點，就是原本 Serverless 計算服務要解決的。

從我們的視角來看，可以明顯感受到一個時代性的轉變：在過去，我們所構建的能力對於傳統微服務應用而言，或許只是“癢點”；但在新興的 AI Agent 時代，這些能力卻成為必須解決的“痛點”。正因如此，我們認為 Serverless 與 AI 的結合，能夠為用户創造更大的價值，這也是我們之所以積極倡導“Serverless AI”理念的原因。

回到 Serverless AI 帶來的結構性變化，從基礎設施的角度來看，其核心問題在於——我們是否能夠通過相關技術，讓基礎設施更好地適配 AI 負載的特徵：包括強隔離、高併發以及高稀疏性。 同時，這種適配能力需要能夠在保障系統穩定性的前提下，為用户帶來更優的成本效益和性能表現。

InfoQ：阿里針對高稀疏負載做了哪些優化？

楊皓然： 在高稀疏負載場景下，系統既要保持實例的狀態，又要面對請求極少、指令稀疏的特性。這意味着實例在大多數時間裏是閒置狀態。當實例閒置時，系統會將其上下文狀態保存在內存中，同時釋放 CPU 資源，以便讓其他實例複用這些算力資源。由於狀態被保留在內存中，一旦新的請求到達，系統需要能夠在 1 毫秒內完成實例的喚醒。關鍵問題在於如何準確判斷請求已經到達某個實例。在傳統的容器架構中，由於缺乏內置網關或請求路由與分發模塊，系統往往無法精準地得知請求何時抵達，也不知道該將請求分配到哪個具體實例上。因此，這類架構通常依賴後台輪詢或檢測機制，導致請求喚醒延遲較高——通常需要約數秒左右。

相比之下，我們的系統通過設計一套專用的請求路由機制，能夠精確識別請求的到達時間與目標實例。這種架構使系統可以即時喚醒目標 Sandbox 實例，從而實現毫秒級響應，極大提升了高稀疏場景下的性能與資源利用率。

InfoQ：業內也有一些公司在提 Serverless AI，阿里雲的差異是什麼？

楊皓然： 我們其實並沒有過多去關注與友商或其他產品之間的差異。相較而言，我們更關注的是，如何真正幫助用户解決問題。面對多樣化的技術選型，用户往往需要做出艱難的抉擇，而我們的目標，是讓他們能夠通過我們的產品，更輕鬆、更高效地應對這些問題。

在基礎設施領域，最終的評價標準始終會迴歸到四個核心維度：性能、成本、安全性與穩定性。我們所進行的所有技術佈局與產品能力建設，實際上都是圍繞這幾個關鍵點展開的。以運行 AI Agent 為例，當用户需要使用大模型，或調用沙箱、瀏覽器（Browser Use）等工具來執行任務時，通常會有兩種選擇：要麼直接使用我們提供的平台能力，要麼基於一些流行的開源方案自行搭建系統。但如果綜合考量性能、成本與安全等要素，就會發現，並非所有的解決方案或產品都能在這幾個維度之間實現良好的平衡。而我們的目標，正是通過 Serverless AI 的架構設計與平台能力建設，幫助用户在這些核心指標上同時取得最優表現。

以開源自建為例，如今如果要實現類似 MicroVM 級別的安全隔離能力，往往需要依賴運行在裸金屬（Bare Metal）環境上的特殊計算形態。然而，這類機器在雲廠商體系中幾乎不具備彈性，無法像普通的阿里雲 ECS 虛擬機那樣實現快速創建、按需釋放或靈活伸縮。它們的資源形態更偏向靜態，這意味着企業在採用開源方案自建系統時，不僅需要自行搭建和維護整套基礎設施，還要面對資源無法彈性伸縮的問題。雖然這種方式在安全性上表現良好，但往往以犧牲彈性與成本效率為代價。

相比之下，阿里雲在 Serverless AI 方向上提供的能力，能夠在性能、成本與彈性之間實現更好的平衡。這正是我們的重要差異化優勢之一。 從產品設計的角度來看，我們無論在技術架構還是產品功能上，都針對 AI Agent 的高併發與高稀疏負載特性進行了大量優化。典型的 Agent 實例生命週期通常僅為幾個小時，而在此期間，超過 90% 的時間它處於空閒或等待狀態——要麼在等待大模型完成推理並下達指令，要麼在調用外部工具並等待返回結果。

針對這種“長時間空閒、短時高峯”的特徵，我們從底層技術架構、計量計費模型和資源調度機制等多方面進行了專門設計，以實現性能與成本的雙重最優。這些創新使用户能夠在保障安全與穩定的同時，充分釋放 Serverless 架構帶來的靈活性與經濟性。

我們會以更系統、更全面的視角來思考企業在當下如何真正實現 Agent 的落地。Agent 的落地絕不僅僅意味着擁有一個運行時環境那麼簡單。對於部分客户而言，單點的、原子化的能力可能已經足夠；但對於更多企業來説，AI 時代的應用技術棧要比傳統系統更加縱深，也更具複雜性。

因此，關鍵在於我們能否為客户提供一套完整而協調的產品組合能力。這套能力不僅應包含運行時本身，還需要覆蓋流量網關、流量治理、可觀測性以及記憶（Memory）等關鍵基礎模塊。只有將這些能力有機融合，構建出一個統一、連貫的體系，才能為客户提供端到端的一致體驗，從而真正支持 Agent 應用的規模化落地與持續演進。

InfoQ：在落地 Serverless AI 層面，不同類型的企業會面臨什麼樣的難點或阻力？

楊皓然： 不同類型的企業在落地 Agent 時的訴求與節奏存在明顯差異。

首先，走得最快的一批企業，無疑是那些頭部的基礎大模型公司。由於他們在這一領域本身就具備最強的技術積累和專業能力，因此對於所有圍繞大模型應用的探索，他們往往是最早的實踐者。對這類企業而言，他們在落地過程中遇到的更多是 Serverless AI 或 AI Agent 運行時層面的一些單點技術痛點。如果能夠在性能、成本和安全性之間找到更優的平衡點，並提供比現有方案更高效的解決思路，那麼這類客户通常會非常願意嘗試並採用新的解決方案。

相對而言，另一類較為傳統的企業目前還處在探索階段。他們已經意識到 Agent 是未來的發展趨勢，但還不清楚該如何與自身的現有業務體系相結合，進而真正創造業務價值。例如，哪怕只是最基本的模型工具調用，企業也會遇到諸多門檻。雖然通過一些開源工具，企業可以將存量 API 轉換為 MCP Server 的形式以供大模型調用，但如何讓模型進行有效、精準的工具調用，仍然是一個高門檻的問題。

因此，這類客户的訴求更傾向於尋求完整而有效的解決方案。他們希望我們不僅能幫助他們將存量業務系統轉化為可被智能體調用的工具（例如將 API 轉為 MCP Server 工具），還能確保這些工具能夠被大模型精準識別與高效調用。進一步地，他們還希望在此基礎上，將新產生的業務數據通過強化學習或模型微調的方式反哺模型，使模型能夠與企業的業務邏輯形成更深層次的融合。

對於這類企業而言，他們需要的不再是單點的技術支持，而是一整套端到端的 Agent 落地解決方案，涵蓋從業務系統改造到智能調用、再到模型持續優化的全流程能力。

InfoQ：對於不同類型的企業，Serverless AI 給客户帶來的比較直觀的優勢是什麼？

楊皓然： 舉一個在行業頭部基礎模型廠商中落地的例子，他們在採用該方案後，整體部署成功率得到了顯著提升。此外，吉利 作為國內領先的汽車製造企業，也在智能座艙方向上深度應用了 AI 能力。他們圍繞智能座艙構建了多種與 AI 強相關的功能，例如文生語音、意圖識別、路線規劃與導航等。舉個例子，當用户説出諸如“我要接一個人，路上順便找個玩具店買點東西”這樣的語句時，系統需要能夠精準識別用户的真實意圖，並基於此進行路徑規劃和導航決策。這些複雜的語義理解與生成能力，都對 AI 模型提出了極高的實時計算與資源調度要求。在引入我們的函數計算之前，吉利的 GPU 資源使用相對固定且粗放，整體資源利用率較低。而採用 FC 之後，系統能夠根據實例的活躍與閒置狀態進行計費，實現了資源的彈性伸縮與高效複用。由於吉利的用户在使用車輛時存在明顯的高峯與低谷時段，這一機制幫助他們將閒置的 GPU 資源充分利用起來，最終實現了約 30% 的成本下降。

另一類較具代表性的客户是義烏小商品市場，這是一傢俱有一定國企背景的上市公司。雖然整體風格偏傳統，但他們在擁抱 AI 技術方面的速度非常快。在實際應用中，他們主要聚焦於文生圖（Text-to-Image）場景，即如何利用 AI 快速生成商品的宣傳圖並完成上架。這不僅涉及 GPU 的使用，他們甚至還引入了阿里的 TPU，以進一步提升生成效率。

在這一過程中，我們為他們提供了一套完整的端到端文生圖解決方案。該方案在開源軟件的基礎上，結合了他們自身的業務需求與商品特點，針對具體場景進行了深度優化。例如，我們根據不同商品類型和展示要求，定製了圖像生成效果和模型參數的優化策略，確保生成的宣傳圖既符合審美，又能滿足電商上架的要求。這種一站式解決方案幫助義烏小商品市場高效地完成了 AI 能力的落地，實現了從傳統生產流程向智能化內容生產的快速轉型。

InfoQ：針對用户提到的 Serverless AI 的難點，如啓動延遲、GPU 彈性不足等有哪些補充觀點？

楊皓然： Serverless AI 並不是要將技術棧的所有部分都以 Serverless 的方式實現，這樣的做法並不合理。我們的思路是選擇最適合採用 Serverless 模式的環節進行優化，例如 Agent 的運行時管理就非常契合這種架構。

相對而言，大模型推理並不適合採用完全的 Serverless 方式。我們目前通常採用 P/D 分離架構來實現推理服務。儘管如此，業界也在嘗試引入一些 Serverless 的思想，例如在 P 與 D 分離的架構中，引入無狀態化設計，使兩類節點可以自由伸縮、提高資源調度靈活性。但從本質上看，大模型推理服務需要依賴高性能 GPU 來確保首包延遲，這類資源必須長期常駐，因此並不適合用完全 Serverless 的方式來實現。至於 GPU 彈性調度，在當前 GPU 資源依然極度稀缺的情況下，它的彈性是受限的彈性，無法像 CPU 那樣隨時按需擴縮。常見的實踐方式是：用户具備一定規模的基礎 GPU 資源，並在此基礎上增加一定範圍內的算力彈性。

從雲廠商的角度講，我們必須非常坦誠地指出：完全無限制的 GPU 彈性在當前階段是無法實現的。我們能做的是在常駐資源的基礎上，通過包年包月、按量計費或混合模式等多種方式，配合更優的資源調度與負載均衡策略，來提升 GPU 資源利用率，並進一步降低單卡成本。

Agent 時代，我們是否在疊加複雜度？

過去十年，微服務架構以“拆分、解耦、靈活”的理念幫助企業擺脱了單體系統的束縛，但也讓系統邊界、依賴關係與運維成本急劇上升。而當智能體（Agent）登上舞台，傳統微服務的複雜度似乎並未消減，反而被進一步放大。Agent 應用要求更高的動態性、異構性與隔離性——每一個智能體都可能在獨立沙箱中運行，並隨時調用外部工具或服務。這種“極度鬆耦合”的新常態意味着：企業不再僅僅在管理服務之間的依賴，而是在協調一個由數千智能體組成的動態生態系統。因此，關鍵不在於避免複雜性，而在於如何讓複雜性被平台吸收。正如楊皓然所指出，企業需要從傳統微服務的擴展和維護中抽身，藉助更高層次的 Serverless 與 AI 平台，將精力轉向智能化業務創新。Agent 時代的挑戰，不是簡單的架構升級，而是一場系統思維的重塑。

InfoQ：微服務的形態本身有變嗎？

楊皓然： 微服務的理念在 Agent 時代依然具有很強的適用性。例如，它所強調的“鬆耦合”原則在這一時代不僅繼續存在，甚至被進一步強化。在傳統微服務的視角下，許多組件或工具之間的鬆耦合程度通常是有限的——例如，我們並不會刻意讓它們在完全獨立的沙箱中、以極度分散的方式運行。

然而，在 Agent 時代，這種高度鬆耦合的模式反而成為必要。由於 Agent 需要在動態、異構且不確定的環境中調用大量外部工具與服務，必須保證各組件之間具有足夠的獨立性與隔離性，從而確保系統的安全性、靈活性與可擴展性。 ** InfoQ：許多公司可能剛剛在這一波 AI 浪潮到來之前，才剛剛完成自身內部微服務體系的建設與完善。**

楊皓然： 因此，一個值得深入探討的問題是：在微服務時代，系統架構已經具備相當高的複雜度，那麼在進入 Agent 時代後，企業該如何更高效地完成這一轉型？在微服務時代，我們曾擁有許多優秀的平台——例如當前我們正在構建的類似 SAE（Serverless Application Engine）這樣的產品——它們的目標就是幫助那些基礎設施能力相對薄弱的團隊，能夠快速採用並運行微服務架構。

如今，隨着 Agent 時代的到來，理念層面的轉變顯得尤為重要。企業需要重新審視資源投入的方向——不應繼續將大量精力消耗在傳統微服務應用的維護與擴展上，而應主動擁抱更具潛力的 Agent 架構。為了實現這一轉變，關鍵在於選擇更高效的平台與工具，讓團隊能夠從繁瑣的底層複雜性中解放出來，從而專注於構建更智能、更具創新性的應用。

TCO 平均降低 60%，百倍啓動加速，AgentRun 如何搞定智能體落地難題？

AgentRun 不是單一的性能優化工具，而是一套面向智能體時代的基礎設施重構方案——在保證高可用與高安全的同時，真正讓“百倍啓動加速、TCO 平均降低 60%”成為企業落地智能體的現實起點。

InfoQ：很多企業在部署和落地 Agent 時都會遇到挑戰，你們觀察到的主要問題有哪些？這些問題為什麼傳統模式難以解決，而你們又是如何更好應對的？

楊皓然： 舉個例子，在運行時層面，由於新的負載模式已經演變為強隔離、高併發、高稀疏的特徵，傳統的 PaaS 或 IaaS 架構並非為此設計，因此要麼彈性受限，要麼安全性受到挑戰。例如，還是以剛剛提到的基模廠商的應用為例——作為其核心產品入口，它在落地過程中就面臨了不少技術層面的挑戰。

這款產品是一個偏 C 端的應用，它設計了一些非常有趣的功能，其中最具代表性的是“一鍵分享項目”。這一功能極大地提升了產品的傳播性與用户體驗，但同時也帶來了較大的技術挑戰。原因在於，項目被分享出去之後，何時會突然成為爆點是無法預判的。

在傳統或現有的架構模式下，我們通常會為每個全棧項目在使用時單獨拉起一個 Sandbox 來執行任務。然而，當這些項目被用户分享出去後，這種模式往往就無法滿足需求了。因為一旦某個項目成為熱門工具或爆款應用，就可能在短時間內吸引大量流量，對系統的彈性伸縮能力提出極高要求。

目前市面上大多數同類產品的設計，仍然是以“單獨的 Sandbox 實例”為核心的。然而，這類項目本質上真正需要的並不是孤立的 Sandbox 實例，而是一個能夠根據流量變化實現快速彈性伸縮的 Sandbox 服務。如何在保證安全的前提下實現這種高彈性、高可靠的服務架構，正是其中最大的技術挑戰之一。

另一方面，可以打個比方：假設一個大型平台上存在幾十萬甚至上百萬個項目，但其中 99.9% 的項目實際上都是處於“冷”狀態的。如果為每一個項目都常駐一個運行實例，那無論從成本還是資源角度來看，都是完全無法承受的。

因此，這類系統必須具備能夠自動縮容至零，並根據流量變化實現快速拉起的能力。只有這樣，才能在保持高性能與高可用的同時，實現資源和成本的最優平衡。而這些問題，恰恰是當下 Serverless 架構或函數計算產品所擅長解決的。以上這些，正是我們在頭部企業中看到的，在大規模落地 Agent 應用或平台化部署過程中，運行時層面最典型的技術挑戰。

另外，對於一些相對傳統的企業來説，在推動 Agent 落地時往往會有一個非常現實的訴求：他們擁有大量的存量業務系統，希望這些系統能夠與大模型或智能體進行交互，成為可被調用的工具。這一需求非常自然，但要真正實現卻並不容易。首先，企業需要將現有的業務 API 改造為類似 MCP Server 的形態，使其能夠被大模型安全、規範地調用。其次，企業往往會擁有數量龐大的 API ——當這些 API 全部轉換為 MCP Server 後，就會形成一個規模巨大的工具集。

然而，這其中 可能有 99% 的工具在大多數場景下都不會被調用，這就帶來了新的挑戰。對於大模型而言，如何在成千上萬的內部業務系統 API 中精準地選擇、判斷並調用合適的工具，是一項極具難度的問題。如何解決大模型的工具選擇效率、調用準確性以及資源管理等問題，正是企業在 Agent 落地過程中普遍面臨的關鍵挑戰之一。而這些問題，也正是我們相關產品能力要重點去解決的方向——幫助企業更高效、更智能地將傳統業務系統接入大模型生態，實現人與智能體、智能體與系統之間的真正協同。

此外，可觀測性依然是一個永恆的主題。在微服務時代，由於應用被拆分成大量獨立的服務模塊，服務之間的調用關係複雜，因此對可觀測性的需求本身就非常強烈——企業需要具備全鏈路追蹤的能力，才能有效定位問題與優化性能。

進入 Agent 時代後，類似的需求同樣存在，甚至更加突出。因為如果一個 Agent 完全是“黑盒”的，企業自然不會放心將其直接部署到生產環境中。企業需要能夠清楚地知道——哪些輸入、哪些調用會消耗大量 token，系統的行為和資源使用情況是否可控，以及如何對這些過程進行監測與治理。

這個客户在這一過程中也進行了大量的方案對比與選型，最終發現我們的解決方案能可靠的支撐大規模業務體量，並在性能、成本上取得很好的平衡，因此成為他們的最優選擇。

InfoQ：此前看到阿里雲的 AgentRun 平均能為企業降低 60% 的 TCO 成本，這個數據是如何測算的？在上線前後，客户會有哪些明顯的指標或體驗變化？

楊皓然： 60% 的 TCO 降幅其實是一個相對保守的估計。在一些典型場景中，我們會對比客户採用自建方式實現類似 Agent 運行時能力所需的成本。舉個例子，如果企業採用自建模式，其資源往往需要 7×24 小時常駐運行。然而在實際使用中，大多數 Agent 或其對應的工具 Sandbox 在生命週期中都是低頻、稀疏活躍的，尤其在偏 C 端的應用場景下，Agent 或 Sandbox 的活躍比例通常只有個位數。這並非技術能力問題，而是由負載特性本身決定的。因此，採用傳統常駐方式會導致極高的資源浪費與成本開銷。

其次，從運維成本角度來看，企業如果要自行整合底層基礎設施與相關工具，還需要投入人力，例如招聘兩到三名具備經驗的基礎設施開發與運維工程師，以保障系統穩定運行。

綜合來看，將資源成本與運維成本相加後，TCO 降低約 60% 已經是一個相對保守的估值，在某些場景下甚至可能更高。

InfoQ：AI 時代，安全尤為重要。阿里雲的袋鼠安全容器據説實現了虛擬機級隔離和毫秒級啓動，那麼在 AI Agent 時代，安全容器與雲原生時代相比有哪些技術差異？

楊皓然： 袋鼠安全容器在技術思路上，與亞馬遜雲科技主導的開源方案 Firecracker 基本一致，但在我們的系統中，其實現方式存在較大的差異。我們將袋鼠安全容器與更大範圍的系統進行了深度、有機的整合。舉例來説，以“拉起容器實例”這一過程為例。如果在傳統的 Kubernetes（K8s）系統中執行該操作，會發現實際的主要開銷往往並不來自安全容器本身。無論是袋鼠安全容器還是 Firecracker，其自身的啓動時間都能控制在百毫秒級別。但若在 K8s 環境中啓動一個 Pod，從端到端的視角來看，整體耗時往往會達到數百毫秒甚至數秒，這背後存在許多需要優化的環節。

例如，鏡像管理方面，可以通過高速緩存或按需加載的方式來減少啓動延遲，從而避免在容器啓動前必須完整加載鏡像數據。同時，K8s 在容器啓停過程中還存在較多管控層面的開銷，如寫入 etcd 等操作，這些額外流程累積起來，往往遠高於使用袋鼠安全容器 MicroVM 啓動的時間成本。

因此，我們的平台從全鏈路優化的角度出發，系統性地消除了這些非必要的開銷。總體來看，我們更傾向於以系統化、垂直整合的思維來設計與優化整體運行時架構，而不僅僅侷限於某個單點技術的改進。

InfoQ：Agent 的上下文怎樣保持？用户中斷之後怎麼能接上話題？怎樣讓 Agent 看起來更智能？

楊皓然： 這一部分實際上涉及到負載特性的變化，即從“無狀態”向“有狀態”演進。為了適應這種模式，底層基礎設施必須進行大量針對性的優化。

在 Agent 場景 下，如何保持上下文成為關鍵問題。如今，我們通常需要通過 session 機制 實現這一點。來自同一會話的請求必須被路由到同一個實例上，而不能像傳統無狀態架構那樣隨機分配到任意實例，否則一旦請求落到新的實例，就會導致 Agent 之前的上下文丟失。這種機制本身並不複雜，但在實際實現中仍有一定挑戰。因為這是有狀態的對話場景，意味着實例可能需要在整個 session 生命週期內持續存在，而這期間的大部分時間，它可能處於閒置狀態。

為了解決這一問題，我們在底層運行時中設計了智能判定機制，能夠快速區分實例當前是活躍還是閒置。當實例處於閒置狀態時，我們僅在內存中保留其實例與 Agent 上下文，將 CPU 計算資源釋放出來，用户因此也無需為 CPU 佔用付費。而當新的請求或大模型的指令到達時，系統可以在 1 毫秒內喚醒處於閒置狀態的實例，並無縫銜接上下文繼續執行。通過這種方式，我們成功適配了高稀疏負載場景，實現了性能與成本之間的最佳平衡。這正是我們在 Agent 運行時設計中所追求的目標——既保證系統高效運行，又最大化資源利用率。

另一個常見的場景是：有些用户的 Sandbox 或 Agent 實例可能在執行數小時後就可以關閉，但他們希望在一週之後重新啓動時，系統能夠接着上一次的狀態繼續執行。這種需求在 Agent 訓練場景或偏 C 端的應用中十分常見。

針對這種情況，我們需要提供一種性價比更高的解決方案。例如，如果實例在長時間（如七天）後才會被再次喚醒，那麼我們顯然不應繼續使用內存來保存其狀態。相反，可以將狀態數據持久化存儲，在需要時再進行恢復。此時雖然恢復速度無法像內存中那樣做到 1 毫秒級，但通常只需幾百毫秒到數秒即可完成狀態恢復並繼續執行。

從用户體驗的角度來看，這種方案是一個性能與成本的合理平衡——雖然性能略有下降，但運行成本顯著降低，整體體驗依然可以接受。因此，Sandbox 或 Agent 的狀態持久化與恢復能力是運行時架構中非常關鍵的一環。我們目前正在持續完善這項能力，儘管尚未完全上線，但已經取得了初步成果。

InfoQ：這種上下文存儲時間的極限大概是多少呢？

楊皓然： 對於用户來説，他們對於存儲的時間極限肯定是不要有限制。我們現在能做到的存儲極限大概是一個月之內。

InfoQ：AgentRun 的性能和傳統方案比快了 100 倍，這個數字是怎麼得出來的？

楊皓然： 如果狀態數據被保存在內存中，用户只需為內存資源付費，並且系統可以在 1 毫秒內完成喚醒。這與傳統依賴完整容器啓動的方式相比，效率提升是巨大的。當前容器生態中也有一些類似的方案，但其喚醒時間通常需要約數秒左右，而我們能夠將這一過程縮短至毫秒級。

此外，函數計算（Function Compute）在冷啓動方面本身就具備顯著優勢。我們在此基礎上進行了大量針對性優化——既繼承了函數計算啓動迅速的特性，又結合有狀態、高稀疏負載的運行特徵，在調度機制、喚醒速度以及計量計費體系等方面進行了深度改進。

通過這些優化，我們能夠在保證極致性能的同時，實現更高的資源利用率與成本效率。

InfoQ：在計費模式上，系統怎麼判斷是真閒置還是假閒置？

楊皓然： 第一個維度是系統是否收到了用户請求。目前的函數計算產品與其他同類產品不同——任何用户請求都必須先通過函數計算系統的內部組件，再轉發給對應的 Sandbox。這種架構設計的初衷是為了支持快速的請求伸縮，也因此具備了天然的可觀測性。系統能夠準確知道某個實例何時開始執行請求、何時執行結束，而在這一時間段內，該實例顯然處於活躍狀態。

第二個維度是針對後台任務的判斷。即便實例當前沒有前端請求執行，後台仍可能存在一些後台任務，用於處理異步或週期性的動作。在這種情況下，我們會利用操作系統層面的監控能力，檢測實例運行過程中 CPU 時間片的消耗情況。當 CPU 使用量超過預設閾值時，我們就會認為該實例處於活躍狀態。通過這兩種手段結合，我們能夠高精度地判斷實例的活躍或閒置狀態，從而在資源調度與成本優化上實現更智能、更高效的管理。

面向開發者的易用性與生態建設

在智能體（Agent）快速發展的浪潮中，開發者體驗與生態建設已成為推動落地的關鍵環節。楊皓然指出，阿里雲並不希望 Serverless AI 僅服務於少數頭部客户，而是致力於讓中小企業與獨立開發者也能低門檻地構建、運行和管理智能體應用。

InfoQ：從開發者的角度來説，阿里接下來有哪些提升易用性的計劃？

楊皓然： 我們的產品並非只面向少數頭部用户設計，而是希望同時服務大量的中小客户和開發者羣體。未來，我們將持續推出多項關鍵能力，包括模型服務治理網關、系統可觀測性，以及 Sandbox（運行時環境）等。其中，Sandbox 將涵蓋 Code Sandbox 與 Browser Sandbox，通過深度整合這些運行時能力，進一步提升整體的開發與運行體驗。

在此基礎上，我們還會提供豐富的應用模板，使開發者能夠將基於主流開源 Agent 框架構建的應用，快速部署到我們的平台。同時，我們將把網關流量治理、身份認證、可觀測性以及記憶機制等能力有機結合，幫助用户高效落地各類 Agent 應用。總體而言，我們不僅專注於單點、原子化的產品能力打磨，更注重將這些能力系統化整合，形成面向不同客户需求的完整解決方案。

Serverless AI：全鏈路保障智能體的穩定高效運行

Serverless AI 的未來演進將同時在底層能力打磨與系統化整合兩個方向上深入推進。真正讓智能體成功落地的，不僅僅是強大的大模型，而是模型 + 基礎設施 + 數據治理的系統性協同。可以説，Serverless AI 不只是“更輕的計算形態”，而是一套面向 AI 原生時代的全鏈路智能體基礎設施標準——幫助企業以更低成本、更高效率實現智能體的規模化、可持續演進。

InfoQ：您怎麼看待 Serverless AI 未來的演進？

楊皓然： 我們的 Serverless AI 產品體系，主要圍繞兩個核心方向展開。

第一，聚焦原子化能力的打磨。 我們重點提升包括運行時、可觀測性、網關以及記憶機制在內的基礎能力，確保在性能、成本與安全性等維度上具備足夠的競爭力，從而在單點技術選型上贏得用户的信任與認可。

第二，將原子能力有機整合為完整的解決方案。 在此基礎上，我們進一步探索如何將這些能力系統化、場景化地結合起來，形成適配不同需求的端到端解決方案。例如，在強化學習這一未來極具潛力的垂直方向，我們正在思考如何幫助用户降低技術門檻、簡化實現路徑，以便他們能夠更高效地構建並應用相關能力。

總體而言，我們將繼續沿着這一思路，不僅打磨底層技術能力，更要構建起具備實際落地價值的 Serverless AI 整體解決方案。

在企業推進智能體落地的過程中，需要重點關注以下幾個方面。我們要充分認識到智能體的落地並不只是依賴於強大的模型能力。很多人誤以為只要使用性能優異的模型，就能輕鬆實現良好的效果，並與業務場景順利結合，從而快速證明業務價值。實際上，這種理解是不全面的。模型能力的提升固然重要，但僅有模型遠遠不夠。真正成功落地的智能體，必須依託完善的基礎設施與系統化解決方案，包括運行環境、調度體系、數據管理、觀測能力等。這些底層支撐共同構成了智能體能夠穩定、高效運行的關鍵基礎。因此，在企業智能體落地的過程中，除了要持續關注模型能力的演進，更應重視智能體基礎設施的建設與完善。

對企業而言可關注三個層面事情的推進：第一，業務實現工具化。 也就是説，企業需要思考如何將自身的業務功能轉化為可供 Agent 調用的工具，實現與智能體的高效交互。這是落地過程中的關鍵起點。在實踐中，需要評估現有的 API 是否能夠快速封裝為 MCP Server，並與 Agent 建立通信。但僅僅具備 MCP Server 還不夠，如果模型無法準確調用這些接口，其價值也會大打折扣。因此，還需要配套的解決方案，使模型能夠在不同場景下準確識別用户意圖，並正確調用企業已有的系統工具或 API。

第二，選擇合適的智能體基礎設施方案。第三，重視面向智能體的數據治理。 目前，使用 Agent 並不意味着它能立即在業務中發揮價值。企業需要讓業務數據持續與智能體交互，以幫助模型更好地理解業務邏輯、適應業務場景。這就要求具備完善的數據治理能力，包括數據隱私保護、安全合規管理與數據質量控制等環節。