引言：AI 應(yīng)用的“電器時代”與運行時的“隱形枷鎖”

阿里云王堅博士曾不止一次的強調(diào)云計算的核心價值 —— 成為數(shù)字時代的“超級電網(wǎng)”；19世紀末，電力的發(fā)現(xiàn)開啟了人類歷史的第二次工業(yè)革命。然而，真正引爆這場革命的，并非僅僅是愛迪生發(fā)明的燈泡，而是特斯拉等人構(gòu)建的交流電系統(tǒng)和覆蓋千家萬戶的 “電網(wǎng)”。

電網(wǎng)讓創(chuàng)新者們不再需要為每個發(fā)明都配備一臺笨重的發(fā)電機，他們只需專注于創(chuàng)造——“電器”。

今天，由 LLM 驅(qū)動的新一輪“電氣革命”已經(jīng)到來。LLM 就是那座強大的新型“發(fā)電機”，正源源不斷地產(chǎn)生著“智能”。全球開發(fā)者正以前所未有的熱情，投身于各種 AI Agent 這些新型“電器”的創(chuàng)造 。

在這場智能大爆炸的面前，面對接踵而至的多樣化 AI 應(yīng)用場景，一個根本性的問題擺在我們面前：為這些 AI 應(yīng)用輸送“智能”的“超級電網(wǎng)”——我們現(xiàn)有的云原生運行時——真的準備好了嗎？

答案是，遠未準備好。無論是被譽為“云原生操作系統(tǒng)”的 Kubernetes，還是被看作“終極形態(tài)”的無服務(wù)器（Serverless），在面對AI應(yīng)用時都暴露出了深刻的架構(gòu)失配。它們就像第一次工業(yè)革命時期笨重、低效的蒸汽機，雖曾是中流砥柱，卻已然無法勝任驅(qū)動“電氣時代”的重任。

我們需要一場徹底的、面向AI的運行時革命。

第一章：來自一線戰(zhàn)場的炮火：AI應(yīng)用到底需要什么樣的運行時？

4 月初，MCP 的熱度一時點燃了 AI 應(yīng)用的又一波熱潮，大家真正的感受到了 Tool 的規(guī)范引入對于挖掘 LLM 潛能的價值，大模型真的有了手和腳，一下子 AI 應(yīng)用的關(guān)注點從單純驅(qū)動 LLM 轉(zhuǎn)移到了如何利用 Tool 構(gòu)建更加智能的 Agent。函數(shù)計算作為阿里云百煉、宜搭和開源魔搭社區(qū)等 MCP 市場的底層運行時，我們見證了第一波大規(guī)模 AI 應(yīng)用浪潮對運行時的真實沖擊。

過去 5 個月，我和產(chǎn)品，PDSA 們與超過 100 家尋求 AI 業(yè)務(wù)落地的客戶深入交流，也負責和阿里集團內(nèi)部幾個智能體平臺團隊進行了業(yè)務(wù)上的深度合作，同時和前線也幫助國內(nèi)幾家大的模型服務(wù)頭部廠商在函數(shù)計算產(chǎn)品上落地 Agent 平臺業(yè)務(wù)，涉及 Agent 運行時，Code Sandbox和Browser Sandbox 工具運行時。

理論是蒼白的，場景是鮮活的。我們先一起看看目前在阿里云函數(shù)計算上已經(jīng)落地的企業(yè) AI 業(yè)務(wù)場景，以及他們?yōu)榇烁冻隽嗽鯓拥摹盎A(chǔ)設(shè)施代價”。從這些正在真實發(fā)生的 AI 應(yīng)用場景，來剖析它們的共同特征，并推導出對下一代運行時的核心要求。

場景一：AI 開發(fā)平臺 MCP Server 托管場景 （AI Tool）

• 企業(yè)場景： 開展 MCP 市場的平臺客戶，例如百煉 MCP 市場，魔搭開源社區(qū) MCP 市場，宜搭 MCP 市場。
• 對運行時的核心要求：
  • 會話狀態(tài)管理：必須有輕量、高效的機制來維持長程會話的上下文與記憶，核心訴求就是能夠支持 MCP SSE 協(xié)議和 MCP Streamable HTTP 協(xié)議。
  • 輕量極速啟動：必須為每一次工具調(diào)用（特別是代碼執(zhí)行）提供毫秒級啟動、由于不同 MCP Server 業(yè)務(wù)調(diào)用規(guī)模不同，運行時的資源規(guī)格從 0.1C128M～1C2G。
  • 高頻工具調(diào)用的經(jīng)濟性：工具的調(diào)用是短暫，50～100 毫秒級、高頻的，運行時必須支持“按需執(zhí)行、閑時零成本”的模式，否則成本會爆炸。
  • 會話保持的經(jīng)濟性：早期 MCP Server 必須先保持一個 SSE 長連接，即便 MCP Streamable HTTP 協(xié)議，在會話保持的情況下，也需要長時持有實例，但實際業(yè)務(wù)請求呈現(xiàn)稀疏調(diào)用特征，需要在實例保持的情況下，按照實際的業(yè)務(wù)請求及執(zhí)行負載計費。
  • 平臺基礎(chǔ)設(shè)施代價評估：開始一段時間，MCP 市場上有 10W+ 的 MCP Server 托管，但只有不到 5W+ 的活躍 MCP Server 存在調(diào)用，在這種情況下，平臺只需要付出非常小的成本代價，因為大部分的 MCP Server 都屬于閑置狀態(tài)；在這種稀疏，不確定的場景下，不管是平臺一方的 MCP Server，還是用戶自托管只需要為活躍的調(diào)用付費。

場景二：交互式智能內(nèi)容創(chuàng)作助手（AI Agent）

• 企業(yè)場景： 市場營銷科技公司、大型企業(yè)的內(nèi)容創(chuàng)作與知識管理團隊。
• 實際用例： 市場經(jīng)理在一個富文本編輯器中輸入初稿，AI 助手可以實時地進行潤色、擴寫、總結(jié)。經(jīng)理可以進一步下達指令，如“幫我配一張科技感的頭圖”、“將這段翻譯成英文”、“把語氣變得更專業(yè)”。
• 應(yīng)用行為拆解：
  1. 多輪對話： 整個創(chuàng)作過程是一個持續(xù)的多輪人機交互會話。
  2. 上下文記憶： AI 必須記住之前的文稿版本、用戶的修改指令和偏好，才能提供連貫的創(chuàng)作建議。
  3. 異構(gòu)任務(wù)流： 這個過程混合了多種任務(wù)。文本潤色主要依賴 LLM（CPU密集），而“配圖”則需要調(diào)用文生圖的擴散模型（GPU 密集）。
  4. 流式響應(yīng)： 為了獲得更好的用戶體驗，AI 的回答（特別是長文本）需要像打字機一樣逐字流式輸出。
• 對運行時的核心要求：
  • 原生會話狀態(tài)管理： 必須有輕量、高效的機制來維持長程會話的上下文與記憶。
  • 會話保持支持 idle 能力： 會話保持，在一段時間沒有請求時，能夠自動釋放運行時實例，釋放前能夠提供回調(diào)入口，調(diào)用 Agent 內(nèi)部的記憶持久化邏輯，寫入持久化記憶中，然后縮0，下次請求能夠在毫秒級快速拉起實例。
  • 運行時的最大存活時間要求： 要求一直存活，但一直有請求的時候要能夠保證至少存活6個小時；
  • 異構(gòu)計算調(diào)度： 運行時需要能智能地將文本任務(wù)和圖像生成任務(wù)，分別調(diào)度到最合適的 CPU 和 GPU 資源上。
  • 低延遲流式通信： 需要原生支持 SSE (Server-Sent Events)或 WebSocket 等流式協(xié)議，以實現(xiàn)打字機效果。

場景三：個性化 AI 客服（AI Agent）

• 客戶畫像： 大型電商平臺、在線旅游（OTA）、SaaS 軟件公司。
• 實際用例： 某電商平臺的“主動式導購 Agent”。當一個用戶在某個昂貴的商品頁面停留超過3分鐘，并反復(fù)查看評論和規(guī)格時，AI Agent 不是被動等待提問，而是主動發(fā)起對話：“您好！我是您的專屬 AI 導購，xxx”
• 應(yīng)用行為拆解：
  1. 事件驅(qū)動： Agent 的啟動是由復(fù)雜的業(yè)務(wù)事件（如用戶行為日志、定時器）觸發(fā)的，而不是簡單的 API 請求。
  2. 數(shù)據(jù)密集： 在發(fā)起對話前，Agent 需要瞬間拉取并整合多個數(shù)據(jù)源：用戶的歷史訂單（CRM）、商品知識庫（向量數(shù)據(jù)庫）、實時庫存（ERP）等。
  3. 7x24小時待命： Agent 需要全天候“在線”，隨時準備響應(yīng)觸發(fā)事件；
• 對運行時的核心要求：
  • 豐富的事件源集成： 運行時必須能無縫對接各類業(yè)務(wù)事件源，如消息隊列、數(shù)據(jù)庫變更、行為日志流等。
  • 低延遲數(shù)據(jù)訪問： 必須提供高效的機制，讓運行實例能快速訪問 VPC 內(nèi)的各種數(shù)據(jù)服務(wù)，支持 VPC 網(wǎng)絡(luò)配置；
  • “永遠在線”的成本效益： 需要一種“縮容到零”但能被事件快速“喚醒”的機制，以極低的成本實現(xiàn)7x24小時的可用性。

場景四：通用 Agent 平臺+病毒式傳播的 AIGC 創(chuàng)意應(yīng)用（AI Agent + Sandbox）

• 客戶畫像： 面向消費者的（toC）通用 Agent 平臺公司，開展面向 C 端客戶的 AIGC 創(chuàng)意應(yīng)用
• 實際用例： 客戶是一個國內(nèi)頭部的基礎(chǔ)大模型服務(wù)公司，利用自己的大模型，結(jié)合面向 C 端的 Agent 平臺開展全棧開發(fā)，目的讓用戶可以通過提示詞寫出一個完整的項目工程，并且可以一鍵部署和分享出去。
• 應(yīng)用行為拆解：
  1. Agent 智能體： 通過和用戶對話，根據(jù)用戶輸入，以休閑益智類游戲為例，通過特定 LLM 生成游戲代碼；
  2. 代碼執(zhí)行驗證： AI Agent 生成代碼，然后需要一個 Code Interpreter Sandbox 來執(zhí)行驗證 AI 生成的代碼；
  3. 生成服務(wù)并分享： AI 生成的游戲項目完成驗證，用戶可以部署為一個服務(wù)，通過分享對外發(fā)布。
  4. 脈沖式流量： 應(yīng)用可能在某個晚上因為一個網(wǎng)紅的推薦而流量激增，并發(fā)請求在幾分鐘內(nèi)從10個飆升到10000個。
  5. 大文件處理： 應(yīng)用需要處理用戶上傳的高清照片，并生成高清結(jié)果圖，涉及較大的數(shù)據(jù) Payload。
• 對運行時的核心要求：
  • 原生會話狀態(tài)管理： 必須有輕量、高效的機制來維持長程會話的上下文與記憶。并支持大量的會話創(chuàng)建，應(yīng)對平臺日均百萬級客戶規(guī)模。
  • 會話保持支持 idle 能力： 會話保持，在一段時間沒有請求時，能夠自動釋放運行時實例，釋放前能夠提供回調(diào)入口，調(diào)用 Agent 內(nèi)部的記憶持久化邏輯，寫入持久化記憶中，然后縮0，下次請求能夠在毫秒級快速拉起實例。會話不要求一直存活，但一直有請求的時候要能夠保證至少存活6個小時。
  • 輕量級安全沙箱： 為規(guī)避 AI 代碼執(zhí)行的任何安全風險，為 AI 生成的代碼提供一個安全的執(zhí)行環(huán)境，提供秒級甚至毫秒級啟動、用后即焚的強隔離沙箱。
  • 安全沙箱存儲隔離： 要求能夠支持動態(tài)存儲掛載，會話之間存儲保持隔離，每一個會話只掛載對應(yīng)會話目錄，持久化會話目錄能支持 TTL 自動清理。
  • 支持大規(guī)模的 AIGC 應(yīng)用部署： 由于是 AI 生成代碼，可以不斷的創(chuàng)建分享新應(yīng)用，平臺會對用戶分享的工程數(shù)量做限制，但是從平臺長期商業(yè)化角度，考慮到用戶規(guī)模，未來要支持海量的應(yīng)用創(chuàng)建。
  • 極致的并發(fā)彈性： 分享后的休閑游戲，突然火爆之后，運行時必須能夠瞬時、自動地應(yīng)對1000倍以上的流量增長，且無需任何人工干預(yù)。
  • 高頻工具調(diào)用的經(jīng)濟性： 工具的調(diào)用是短暫、高頻的，運行時必須支持“按需執(zhí)行、閑時零成本”的模式，否則成本會爆炸。

總結(jié)：下一代 AI 運行時的七大核心訴求

從這些真實的用例中，我們可以清晰地勾勒出新一代 AI 應(yīng)用的共同畫像：它們是會話式的、工具增強的、事件驅(qū)動的、按需成本。這最終匯聚成了對理想運行時的七大核心訴求：

1. 會話管理： 能夠低成本、高效率地管理長程會話和狀態(tài)。
2. 流程編排： 內(nèi)建或無縫集成復(fù)雜任務(wù)流的編排能力。
3. 安全沙箱： 默認提供輕量、快速、強隔離的安全執(zhí)行環(huán)境，尤其是存儲隔離。
4. 極致彈性： 能對 CPU 和 GPU 等異構(gòu)資源實現(xiàn)從零到萬的瞬時、按需伸縮。
5. 應(yīng)用管理： 能夠管理十萬至百萬級應(yīng)用管理，應(yīng)用創(chuàng)建沒有額外費用；
6. 一直在線： 一種邏輯上的長時運行，上下文持久化，有請求時快速恢復(fù)執(zhí)行，無請求時按照 idle 縮0；
7. 成本效益： 能夠完美匹配AI應(yīng)用稀疏、不確定，脈沖式的調(diào)用模式，實現(xiàn)真正的“按價值付費”。

這些訴求，正是驅(qū)動著云端運行時，從傳統(tǒng)的 VM、到容器化的 K8s、再到新一代 AI 原生 Serverless 架構(gòu)演進的根本動力。

第二章：傳統(tǒng)容器運行時的“蒸汽機”困境

Kubernetes（K8s）作為當前云原生的“操作系統(tǒng)”和事實標準，其強大和通用性毋庸置疑。然而，當它直接面對形態(tài)各異、需求極致的 AI 運行時，將它應(yīng)用于 AI Agent、Sandbox 這類新興的、更加動態(tài)和細粒度的 AI 應(yīng)用場景時，K8s 的“通用性”設(shè)計哲學和實現(xiàn)細節(jié)暴露出了一系列深刻的問題，帶來了一系列具體而微的“摩擦”和“掣肘”。這些問題不是“K8s 行不行”，而是“用 K8s 做這件事，我們的代價、復(fù)雜度和天花板在哪里？”。

挑戰(zhàn)一：面向資源，而非運行時的元數(shù)據(jù)管理瓶頸

在 K8s 的架構(gòu)中，etcd是整個集群的“中央檔案室”和唯一的事實源頭。它存儲了集群中每一個資源對象（Pod, Service, ConfigMap, Job 等）的定義（Spec）和狀態(tài)（Status）。

但這個面向資源的“中央集權(quán)”設(shè)計，在面對巨量、高頻的函數(shù)創(chuàng)建/銷毀應(yīng)用場景時，會遇到以下幾個具體的瓶頸：

• 瓶頸一：強一致性的“寫入放大”效應(yīng)。 etcd 是一個基于 Raft 協(xié)議的強一致性鍵值存儲。當你在 K8s 中創(chuàng)建一個業(yè)務(wù) Pod 時，這個看似簡單的操作，在 etcd 層面會觸發(fā)一系列“重”操作：API Server 向 etcd 的 Leader 節(jié)點發(fā)起寫入請求，Leader 節(jié)點需要將這個寫入日志復(fù)制給多數(shù) Follower 節(jié)點，并等待它們的確認。這個過程是為了保證集群狀態(tài)的絕對可靠，但犧牲了極致的寫入性能。當成千上萬的函數(shù)實例被同時創(chuàng)建時，etcd 的 Raft 協(xié)議會成為寫入操作的瓶頸。
• 瓶頸二：“狀態(tài)更新”的風暴。 比“創(chuàng)建”更可怕的是“狀態(tài)更新”。一個 Pod 的生命周期中會經(jīng)歷多個狀態(tài)（Pending, ContainerCreating, Running, Succeeded等）。每個節(jié)點上的kubelet都會頻繁地向 API Server 匯報 Pod 的最新狀態(tài)，這些海量的狀態(tài)更新最終都會被寫入到 etcd 中。對于生命周期較短的業(yè)務(wù)場景，其短暫的一生中產(chǎn)生的狀態(tài)更新流量，遠比其創(chuàng)建時的流量要大。 這場“狀態(tài)風暴”會持續(xù)不斷地沖擊 etcd，消耗其 I/O 和 CPU 資源。
• 瓶頸三：“監(jiān)視（Watch）”機制的負擔。 K8s 的控制器模型依賴于“List-Watch”機制來感知資源變化。當集群中有數(shù)萬乃至數(shù)十萬個 Pod 對象時，大量的控制器（包括自定義的 Operator）會與 API Server 建立長連接來監(jiān)視這些 Pod 的變化。這會給 API Server 和 etcd 帶來巨大的內(nèi)存和連接壓力，導致事件通知延遲，整個集群的響應(yīng)“變鈍”。

K8s 的元數(shù)據(jù)管理是為“相對穩(wěn)定、長時間運行”的“服務(wù)”設(shè)計的，而不是為“巨量、瞬時、高頻生滅”的應(yīng)用設(shè)計的，它的可靠性來自于犧牲了一部分極致的規(guī)模化能力。

挑戰(zhàn)二：安全與隔離的“漏”與“重”：為“沙箱”付出的高昂代價

供 AI 代碼執(zhí)行的安全沙箱是 AI 應(yīng)用體系的核心組成部分，它要求在執(zhí)行不可信代碼（尤其是 LLM 生成的代碼）時，提供絕對安全、強隔離、輕量級、快速啟動的環(huán)境。K8s 在這方面提供了幾種選擇，但每種都有難以調(diào)和的矛盾。

• 原生默認隔離的“漏”： K8s 默認的 Pod 隔離基于 Linux Namespace 和 Cgroups，所有 Pod 共享宿主機的操作系統(tǒng)內(nèi)核，共享內(nèi)核的安全原罪。這意味著，一旦發(fā)生內(nèi)核漏洞利用或容器逃逸，整個節(jié)點的安全防線都可能被擊穿。對于需要執(zhí)行任意代碼的 AI Sandbox 場景，這種默認的隔離級別在執(zhí)行 AI 代碼安全風險完全不可預(yù)知的情況下是絕對不夠的。況且以面向人為操作的管控情況下，安全風險層出不窮，AI 驅(qū)動的業(yè)務(wù)邏輯實現(xiàn)下，尤其在商業(yè)的驅(qū)動下，以往任何漏洞都有可能被 AI 利用，運行時面臨更加極端的安全風險。
• 升級隔離方案的“重”： 為了解決共享內(nèi)核問題，基于輕量級虛擬化（MicroVM）的方案，如 Kata Containers，或基于用戶態(tài)內(nèi)核的 gVisor。它們確實能提供接近 VM 級別的強隔離。但問題在于：
  1. 性能開銷： 相比普通容器，它們有明顯的性能損耗（網(wǎng)絡(luò) I/O、文件訪問等），相比追求極致的 FaaS 平臺，很難犧牲通用型來實現(xiàn)極致的運行時優(yōu)化。基于 K8s 通用運行時之上構(gòu)建更加符合業(yè)務(wù)場景需要的輕量安全的沙箱能力本身是當下 Serverless，F(xiàn)aaS 平臺專注的領(lǐng)域；
  2. 運維復(fù)雜性： 針對特定安全需求，需要特定的運行時配置（RuntimeClass）、運行時的配置絕不僅僅是一個配置的修改，同時依賴底層的硬件和內(nèi)核支持，給集群的管理和維護帶來了極高的復(fù)雜性。

Serverless 容器在這方面確實做了一些很好的優(yōu)化， 用戶只需按需申請容器 Pod，自動匹配和管理底層計算資源，無需規(guī)劃節(jié)點容量，整體來看如何平衡隔離和性能是這類架構(gòu)核心關(guān)注點，并不是原生出發(fā)點；

挑戰(zhàn)三：資源模型的適配：“標準化”遭遇“定制化”

K8s 的核心是圍繞長時運行的服務(wù)設(shè)計的，其主力資源對象如Deployment和StatefulSet，好比是用來管理一支7x24小時運營的長途貨運車隊。但 AI Agent 和其工具的運行模式卻完全不同，他們更像追求按需，敏捷的“同城閃購”，彈性與速度成為支持 “同城閃購” 的核心訴求。

• AI Agent 的“思考” vs. K8s 的“服務(wù)”： 一個 AI Agent 的核心是一個“思考循環(huán)”，問題回答完成，一個空閑的時間之后，它長時間處于待命狀態(tài)，等待外部事件觸發(fā)，然后進行一連串密集的計算和工具調(diào)用。它本質(zhì)上是有狀態(tài)的、單體的、觸發(fā)式運行。用 K8s 的工作負載來管理有狀態(tài)的，單體的 Agent，目前無法優(yōu)雅地處理 Agent“長時間待命，短時爆發(fā)”的模式。
• AI Tool 的“執(zhí)行” vs. K8s 的“任務(wù)”： 一個 AI Tool 的調(diào)用是一次性的、短暫的函數(shù)執(zhí)行。在 K8s 里，最接近的模型是 Deployment 或 Job。但為了執(zhí)行一個可能只耗時 200 毫秒的 Python 腳本（例如，調(diào)用一次天氣 API），開發(fā)者需要編寫一個Dockerfile，構(gòu)建一個容器鏡像，再編寫一個 Job 的 YAML 文件。這個過程的“儀式感”過重，管理和部署成本極高，完全違背了工具應(yīng)有的輕便和靈活。Knative 和 OpenFaaS 等項目試圖在 K8s 上構(gòu)建 FaaS（函數(shù)即服務(wù)）體驗，但這本身就證明了 K8s 原生能力的缺失，并引入了又一個需要維護的復(fù)雜技術(shù)棧，通過增加更多復(fù)雜性來“模擬”一個輕量級的能力。
• AI 應(yīng)用閃購屬性凸顯，C端需求的不確定性： 彈性規(guī)模受 K8s 系統(tǒng)原生設(shè)計，實例的創(chuàng)建/釋放存在全局瓶頸。K8s 的 HPA 需要幾十秒時間收集實例指標決策是否擴縮容，Pod 的啟動包含鏡像拉取、網(wǎng)絡(luò)分配、容器啟動等多個步驟，通常在幾秒到幾十秒；極端情況下，集群底層資源節(jié)點不足時，這通常需要數(shù)分鐘時間來進行擴容；面向通用性設(shè)計的穩(wěn)定性要求，無法滿足瞬時彈性的根本訴求，依賴業(yè)務(wù)基于 K8s 資源二次封裝。

挑戰(zhàn)四：使用和管理維度的無盡細節(jié)，成為平臺規(guī)模化的隱形成本

Kubernetes 復(fù)雜性已成為行業(yè)共識。開發(fā)者被迫從“算法工程師”轉(zhuǎn)型為“YAML 工程師”，平臺本身成為了創(chuàng)新的阻力。管理復(fù)雜的網(wǎng)絡(luò)策略、RBAC 權(quán)限等，本身就是一項高門檻的專家級工作；面對 AI 應(yīng)用創(chuàng)新敏捷開發(fā)訴求，K8s 的復(fù)雜性會拖累整個業(yè)務(wù)創(chuàng)新速度；即便 Serverless Kubernetes 能夠解決部分運維管理的問題，但其核心解決的是“我不想管理 K8s 集群”的問題。 它的核心是讓你用 K8s 的方式，但無需關(guān)心底層的服務(wù)器，你的交互對象依然是容器（Pod）。而當前 AI 應(yīng)用創(chuàng)新的核心邏輯是，我通過 Agent 框架快速的實現(xiàn)了一個 Agent 業(yè)務(wù)，我用 AI 快速的生成了一個應(yīng)用，核心訴求是“只想運行我的代碼”的問題，核心是完全不用關(guān)心任何基礎(chǔ)設(shè)施，包括容器。

第三章：傳統(tǒng)無服務(wù)器架構(gòu)運行時的“狀態(tài)枷鎖”

在我們深入剖析了傳統(tǒng)運行時及K8s體系在AI浪潮下的種種“不適”之后，一個自然的問題是：那么，被譽為云原生終極形態(tài)的無服務(wù)器（Serverless FaaS）架構(gòu)，就是那個“開箱即用”的答案嗎？

坦率地說，并非如此。傳統(tǒng)的、以無狀態(tài)為核心設(shè)計理念的 FaaS 架構(gòu)，與以 AI Agent 和 Sandbox 為代表的新興有狀態(tài)工作負載之間，存在著根本性的架構(gòu)失配。我們嘗試基于已有的函數(shù)計算構(gòu)建有狀態(tài)的AI Agent和Sandbox，一系列的挑戰(zhàn)接踵而至：

挑戰(zhàn)一：模擬會話導致復(fù)雜且脆弱的實例生命周期管理

問題描述： 為了模擬會話，每個會話都對應(yīng)一個配置了靜態(tài)預(yù)留實例的函數(shù)。這意味著，會話的生命周期必須與函數(shù)計算實例的生命周期嚴格同步。當一個用戶會話結(jié)束時，我們需要通過更新函數(shù)的彈性策略，將最小實例數(shù)從 1 調(diào)整為 0，以觸發(fā)實例的回收，從而避免產(chǎn)生不必要的閑置費用。這個過程被證明是“復(fù)雜且難以有效管理的”。

深度分析： 此問題的根源在于 FaaS 平臺設(shè)計的核心假設(shè)——實例是短暫且由平臺自動管理的。函數(shù)計算的實例生命周期（創(chuàng)建、調(diào)用、銷毀）是事件驅(qū)動的，其設(shè)計目標是響應(yīng)請求的潮汐變化，而非維持一個與外部業(yè)務(wù)邏輯（如用戶會話）同步的、長周期的狀態(tài)。雖然平臺提供了預(yù)留實例和生命周期掛鉤（如 Initialize，PreStop）等高級功能，但這些功能的設(shè)計初衷是為了應(yīng)對冷啟動或?qū)崿F(xiàn)優(yōu)雅停機時的狀態(tài)清理，而不是作為管理長連接會話狀態(tài)的核心機制。

我們被迫在應(yīng)用層“逆向工程”平臺的調(diào)度行為，通過 API 調(diào)用頻繁地修改基礎(chǔ)設(shè)施的彈性配置，這本質(zhì)上是在對抗平臺的設(shè)計理念。這種做法不僅增加了系統(tǒng)的復(fù)雜性，也使其變得非常脆弱。例如，我們需要額外考慮閑置會話的超時回收、會話中斷后的狀態(tài)恢復(fù)、以及更新彈性策略失敗時的補償邏輯等一系列棘手問題。這與 FaaS 承諾的“免運維”理念背道而馳，極大地增加了運營成本和系統(tǒng)的不可靠性，也印證了在無狀態(tài) Serverless 架構(gòu)中管理持久狀態(tài)的普遍挑戰(zhàn)。

挑戰(zhàn)二：函數(shù)隔離下的配置復(fù)用和管理問題

問題描述： 由于每個會話都需要創(chuàng)建一個獨立的函數(shù)來實現(xiàn)隔離，導致每個函數(shù)實例的配置（如環(huán)境變量、資源規(guī)格、網(wǎng)絡(luò)設(shè)置）都相對獨立。這使得跨實例、跨會話的配置復(fù)用變得異常困難，顯著增加了管理開銷。

深度分析： 在傳統(tǒng) FaaS 的世界里，“函數(shù)”是配置和部署的基本單元。平臺所有的管理和優(yōu)化都是圍繞函數(shù)展開的。當應(yīng)用場景迫使我們將“會話”這一應(yīng)用層概念與“函數(shù)”這一基礎(chǔ)設(shè)施層概念進行一對一綁定時，就破壞了配置復(fù)用的可能性。在一個更傳統(tǒng)的虛擬機或容器編排系統(tǒng)中，我們可以使用一個“鏡像”或“模板”來批量創(chuàng)建成千上萬個配置相同的實例。在傳統(tǒng) FaaS 方案中，每創(chuàng)建一個新會話，就意味著要進行一次完整的函數(shù)定義和配置過程，這相比傳統(tǒng)資源管理已經(jīng)足夠輕量和敏捷，但在追求極致的 Serverless 世界，我們認為這在管理上仍然是極其低效和復(fù)雜的。

挑戰(zhàn)三：原生基于函數(shù)隔離在高頻會話創(chuàng)建場景效率下降

問題描述： 為了給每一個新的會話提供一個隔離的環(huán)境，傳統(tǒng) Serverless 架構(gòu)不得不頻繁地通過 API 創(chuàng)建和刪除函數(shù)。創(chuàng)建操作引入的控制面時間成本滲透到了業(yè)務(wù)邏輯中，造成了不必要的負擔。

深度分析： 這是本次探索中最為關(guān)鍵和深刻的發(fā)現(xiàn)。控制平面的性能帶來了業(yè)務(wù)邏輯處理的隱形成本，在傳統(tǒng)架構(gòu)中管控是不得不面對的實際操作，相比資源創(chuàng)建，管控鏈路的消耗通常被認為理所當然。但相比 FaaS 平臺的數(shù)據(jù)平面——即實際執(zhí)行函數(shù)代碼的計算實例——被設(shè)計為可以大規(guī)模水平擴展，其控制平面——負責函數(shù)的創(chuàng)建、刪除、配置更新、路由規(guī)則變更等管理任務(wù)，盡管相比傳統(tǒng)架構(gòu)，已經(jīng)非常極致，但對于追求更極致的 Serverless 場景，我們希望能夠通過更多的函數(shù)維度配置復(fù)用，消除這樣的不必要時間。

每一次函數(shù)的創(chuàng)建或刪除，都不是一個輕量級操作。它涉及到在元數(shù)據(jù)存儲中讀寫記錄、更新 API 網(wǎng)關(guān)路由、配置網(wǎng)絡(luò)和安全策略、以及與底層資源調(diào)度器交互等一系列復(fù)雜的分布式事務(wù)。一個設(shè)計良好的 Serverless 業(yè)務(wù)系統(tǒng)，其函數(shù)集合應(yīng)該是相對穩(wěn)定的，而實例數(shù)量是動態(tài)變化的。依賴大量的函數(shù)隔離，模擬會話導致了函數(shù)定義本身的高頻變化。這種使用模式下，在需要極致高頻創(chuàng)建會話邏輯的場景，必然會觸及控制平面的請求限流，導致 API 調(diào)用延遲增高、甚至影響到平臺上其他用戶的正常使用，是典型地將應(yīng)用層問題錯誤地轉(zhuǎn)移到基礎(chǔ)設(shè)施層來解決所導致的架構(gòu)性問題。當然在不得不需要函數(shù)維度隔離的場景下，例如確保不同實例配置的差異化，可以通過預(yù)先創(chuàng)建函數(shù)資源的方式，維護一個函數(shù)元數(shù)據(jù)維度的緩存池解決高頻創(chuàng)建場景下的性能問題。

第四章：從“理念契合”到“能力完備”：函數(shù)計算為AI而生的進化之路

這些嘗試清晰地表明，我們遇到的所有挑戰(zhàn)并非孤立的技術(shù)難題，而是源自于一個共同的根源：試圖將一個本質(zhì)上有狀態(tài)、長周期、交互式的會話模型，強行適配到一個為無狀態(tài)、短周期、請求-響應(yīng)式事件設(shè)計的計算平臺上。

AI運行時完美“理念契合”Serverless運行時理念

機遇一：完善的事件驅(qū)動生態(tài)，完美契合未來多樣的 AI Agent 交互模式

• 萬物皆可為“觸發(fā)器”： Serverless 的事件驅(qū)動模型是構(gòu)建 AI Agent 的完美基石。一封新郵件、一次數(shù)據(jù)庫更新、一條 IoT 設(shè)備消息，都可以成為觸發(fā) Agent“感知-思考-行動”循環(huán)的事件。Serverless 平臺因此成為連接數(shù)字世界與物理世界的、無處不在的“神經(jīng)網(wǎng)絡(luò)”。

• 響應(yīng)式與自主性的統(tǒng)一： AI Agent 天生就是一個事件驅(qū)動的系統(tǒng)，它“感知”外部事件，然后“思考”和“行動”。基于事件驅(qū)動，AI Agent 可以實現(xiàn)從被動響應(yīng)用戶查詢，到主動監(jiān)測環(huán)境變化、自主執(zhí)行任務(wù)的巨大飛躍，成為真正的“自主智能體”。

機遇二：輕量敏捷的運行時沙箱，為 AI Sandbox 量身打造，防止 AI“逃逸”

• 從重量級 VM 到輕量級 MicroVM： 以 MicroVM 為代表的輕量級虛擬化技術(shù)，可以在極短時間內(nèi)啟動一個具有強內(nèi)核級隔離的微型虛擬機。這為 AI 運行時提供了完美的“沙箱”——既能保證運行第三方或不可信 AI 模型的安全性，又能實現(xiàn)遠超容器的隔離級別，是解決 GPU 等多租戶安全隔離問題的理想答案。

• 可擴展的執(zhí)行環(huán)境： 基于沙箱技術(shù)，我們可以為每個 AI 應(yīng)用定制一個包含特定依賴庫、數(shù)據(jù)卷和環(huán)境變量的、可復(fù)用的“運行時快照”。這極大地加速了冷啟動過程，實現(xiàn)了環(huán)境的快速分發(fā)與一致性。

機遇三：極致彈性的天作之合，應(yīng)對AI流量不可預(yù)測性的“脈沖風暴”

• 從零到萬的瞬間伸縮： 一個 AI 應(yīng)用可能在一夜之間引爆全球流量。無服務(wù)器架構(gòu)與生俱來的、近乎無限的擴展能力，使其成為承載這種“病毒式”傳播應(yīng)用的唯一合理選擇。企業(yè)無需預(yù)估和儲備昂貴的 GPU 集群，只需為實際發(fā)生的計算付費，完美匹配 AI 應(yīng)用高度不確定的業(yè)務(wù)發(fā)展曲線。

• 事件驅(qū)動的 AI 代理（Agent）中樞： AI 正從簡單的“請求-響應(yīng)”模式，演變?yōu)槟軌蛑鲃痈兄㈨憫?yīng)外部事件的智能代理。無服務(wù)器架構(gòu)的事件驅(qū)動本質(zhì)，使其成為構(gòu)建 AI Agent 的天然“神經(jīng)中樞”，能夠無縫連接各種數(shù)據(jù)源、API 和物理世界事件，驅(qū)動 AI 進行決策和行動。

機遇四：異構(gòu)算力的精細化調(diào)度與成本優(yōu)化，AI 應(yīng)用“一直運行”，但只為真正的請求付費

• 算力“管弦樂團”： 函數(shù)計算平臺不是單一的 CPU 樂器，而是一個能夠指揮 CPU、GPU、XPU 等多種算力的“管弦樂團”。通過將復(fù)雜的 AI 任務(wù)分解到不同的函數(shù)中，平臺可以為每個步驟智能匹配最經(jīng)濟、最高效的算力，實現(xiàn)前所未有的資源利用率和成本效益。

• AI 開發(fā)者的核心任務(wù)是構(gòu)建“智能”，而非運維“設(shè)施”。FaaS 致力于將基礎(chǔ)設(shè)施完全抽象掉，讓開發(fā)者只關(guān)心業(yè)務(wù)代碼的愿景，與 AI 開發(fā)者的訴求完全一致。

盡管挑戰(zhàn)重重，但無服務(wù)器架構(gòu)的核心理念——極致彈性、按需使用、免運維、開箱即用——與 AI 應(yīng)用的爆發(fā)式、不可預(yù)測的負載模式高度契合。這與 AI 應(yīng)用的需求有著驚人的、靈魂深處的一致性，這種在“核心理念”上的高度契合和一致性讓我們相信，我們需要的不是放棄，而是一次深刻的進化。 同時我們看到行業(yè)領(lǐng)導者 AWS 也在 AI 應(yīng)用運行時領(lǐng)域投出了重磅發(fā)布：AWS AgentCore，基于 AWS Lambda 構(gòu)建 Agent Runtime，AI Sandbox 運行時，這更加堅定了我們的信心和目標。

阿里云函數(shù)計算 AI 原生運行時進化之路

面對上述困境，我們需要一個全新的、為 AI 而生的“超級電網(wǎng)”。進化的無服務(wù)器架構(gòu)（函數(shù)計算）正朝著這個方向演進，它必須具備六大核心支柱：

1. 為請求賦予會話屬性： 如果說 LLM 是 AI 智能的源泉，會話就是 AI 應(yīng)用的記憶與意識，突破無狀態(tài)計算枷鎖。
2. 重新定義事件驅(qū)動： 突破單個事件設(shè)定，成為 AI Agent 的天然“神經(jīng)系統(tǒng)”，連接萬物，驅(qū)動智能。
3. 運行時沙箱的安全革命： 以 MicroVM 為安全基石，以會話，存儲維度運行時隔離賦予 Agent 安全的“行動力”，實現(xiàn)強隔離、快啟動。
4. 異構(gòu)能力的“管弦樂”： 成為能精細化調(diào)度 CPU、GPU 等多種算力的“指揮家”，實現(xiàn)極致的成本效益。
5. 端到端的全景可觀測： 以 MCP，A2A 等標準協(xié)議連接智能載體，以 OpenTelemetry 等開放標準點亮“智能黑盒”，提供企業(yè)級的運維能力。
6. 解決狀態(tài)的成本困局： 函數(shù)計算以請求維度計費為其核心特點，在突破狀態(tài)枷鎖之后，AI應(yīng)用狀態(tài)的維持，務(wù)必會帶來請求資源的長期占有，和 AI 應(yīng)用“稀疏”且“不可預(yù)測”的調(diào)用模式下的成本困局。

直面挑戰(zhàn)，作為 Serverless 領(lǐng)域的領(lǐng)導者，阿里云函數(shù)計算（FC）正以先行者的姿態(tài)，用一系列硬核升級，將AI原生運行時的構(gòu)想落為現(xiàn)實。

第一步：以“智能會話”原生 AI 應(yīng)用原語破解狀態(tài)枷鎖，開發(fā)復(fù)雜度降低一個數(shù)量級

• 業(yè)務(wù)價值： 開發(fā)者在構(gòu)建復(fù)雜對話式 AI 和多輪工具 Agent 時，無需再依賴外部狀態(tài)系統(tǒng)，極大地降低了架構(gòu)復(fù)雜度和端到端延遲。
• 能力升華： 通過多維度的會話親和與 Session API，函數(shù)計算將會話的定義權(quán)和生命周期管理權(quán)交還給開發(fā)者，實現(xiàn)了與業(yè)務(wù)邏輯的深度集成。

第二步：以“會話即沙箱”重塑安全邊界，提供金融級隔離保障

• 業(yè)務(wù)價值： 企業(yè)可以構(gòu)建大規(guī)模、高密度、多租戶的 AI Agent 或 Sandbox 服務(wù)。每個用戶的會話都運行在一個完全隔離的“氣泡”中，為在線編程、AI 代碼助手等商業(yè)模式提供了絕對安全的基石。
• 能力升華： 通過動態(tài)掛載和會話級計算與存儲隔離（依托 MicroVM），實現(xiàn)了極致的資源優(yōu)化和業(yè)界頂級的安全保障。

第三步：以“智能負載探測”革新成本模型，實現(xiàn)業(yè)務(wù)與成本雙贏

• 業(yè)務(wù)價值： 徹底改變了 Serverless 在有狀態(tài)和后臺任務(wù)場景下的成本模型，使得企業(yè)能以極低成本，運行需要“持續(xù)在線”的復(fù)雜 AI 應(yīng)用（如 7x24 小時待命的 Agent）。
• 能力升華： 突破傳統(tǒng)的 Freeze/Unfreeze 模式，升級為按實際業(yè)務(wù)負載動態(tài)探測資源消耗，實現(xiàn)了從“為資源付費”到“為效果付費”的哲學轉(zhuǎn)變。結(jié)合請求級 Idle 能力與動態(tài)快照，完美平衡了性能、彈性和成本。

第四步：以“開放標準”擁抱生態(tài)，簡化連接與觀測

• 業(yè)務(wù)價值： 大幅降低構(gòu)建企業(yè)級 AI 應(yīng)用的架構(gòu)復(fù)雜度，開發(fā)者無需自行搭建復(fù)雜的鑒權(quán)、服務(wù)發(fā)現(xiàn)和流式通信設(shè)施，也擁有了“上帝視角”的運維能力。
• 能力升華： 原生支持WebSocket, gRPC, SSE流式親和等現(xiàn)代協(xié)議和JWT等鑒權(quán)方式；與網(wǎng)關(guān)服務(wù)集成打通了 A2A，MCP 應(yīng)用互通；全面擁抱 OpenTelemetry標準，點亮了 AI 工作流這個“智能黑盒”。

第五步：以“DevPod”統(tǒng)一云上云下，提供所見即所得的開發(fā)體驗

• 業(yè)務(wù)價值： 解決了 AI Serverless 應(yīng)用開發(fā)與調(diào)試的“黑洞”問題，提供與云端完全一致的環(huán)境，極大提升開發(fā)效率，是 AI 應(yīng)用工程化“最后一公里”的堅實保障。

結(jié)語：為新時代的“電器發(fā)明家”鋪路

回顧歷史，電網(wǎng)的修建，深刻地改變了世界的經(jīng)濟地理和創(chuàng)新格局。今天，一個 AI 原生的云端運行時的進化，其意義也遠不止于技術(shù)本身。

這是一次設(shè)計哲學的升華：從“讓應(yīng)用適應(yīng)平臺”到“讓平臺主動理解和適應(yīng)智能應(yīng)用”的轉(zhuǎn)變。當一個強大、易用、經(jīng)濟且安全的 AI 運行時成為像水電一樣的基礎(chǔ)設(shè)施時，它將極大地降低創(chuàng)新的門檻。一個獨立的開發(fā)者、一個小型創(chuàng)業(yè)團隊，將有能力去創(chuàng)造和部署世界級的 AI 應(yīng)用。這才是技術(shù)平權(quán)的真諦，是激發(fā)全社會創(chuàng)新潛能的關(guān)鍵。

我們的終極目標，是實現(xiàn)函數(shù)計算無服務(wù)器架構(gòu)的進化，使其成為AI智能體時代的、默認的、無形的“世界計算機”。在這條新修的“超級電網(wǎng)”上，開發(fā)者可以完全專注于 AI 應(yīng)用的創(chuàng)造和業(yè)務(wù)邏輯的實現(xiàn)，而將背后的一切復(fù)雜性——資源、伸縮、記憶、安全、運維——都透明地交由平臺處理。這不僅僅是關(guān)于運行代碼，這是關(guān)于托管智能、賦能創(chuàng)造、并安全地連接 AI 與現(xiàn)實世界的偉大征程。

新時代的“電氣革命”已經(jīng)到來，而我們，正致力于為所有“電器發(fā)明家”，鋪設(shè)那條通往未來的、最堅實的道路。