AI Agent 運行時相比傳統應用有什么不同：百家企業 AI 實踐觀察（二）

從本篇文章開始，我們將具體講講 AI 應用實踐過程中每一個環節的核心挑戰，以及我們對應的解法和思路。

作者：計緣

在本系列的開篇內容中，我們已經和大家一起理清了一些基本概念， 比如 AI 應用的定義，AI 應用的核心是什么，以及 AI Agent 的定義和推理模式等。

從本篇文章開始，我們將具體講講 AI 應用實踐過程中每一個環節的核心挑戰，以及我們對應的解法和思路。如果您對這些內容感興趣，推薦您關注阿里云云原生公眾號，后臺回復 “企業AI實踐” 獲得我們整理的完整的企業級 AI 應用構建的最佳實踐 PPT，配合系列文章一起食用，效果更佳。

今天我們聊聊 AI Agent 運行時。

如上文所述，我們正步入一個由 AI Agent 驅動的全新 AI 時代。AI Agent 運行時已不再是簡單的代碼執行環境，它演變成了一個動態、有狀態且可能是事件驅動的復雜系統。這個運行時負責管理 AI Agent 的完整生命周期，包括其狀態維護、與外部工具的交互以及多智能體間的協作行為。OpenAI 將 Agent 重新定義為“模型 + 指令 + 工具 + 運行時”的組合，這標志著 AI Agent 運行時本身已從“附屬組件”，躍升為不可或缺的“核心基石”。

AI Agent 運行時的挑戰點

AI Agent 的計算負載特征與傳統應用截然不同。傳統的 Web 服務通常具有可預測的請求-響應模式，而 AI Agent 的運行推理模式如上文所述，是多種多樣的，并非一次簡單的模型推理，而是一個復雜的、多輪次的循環工作流，涵蓋了持續的規劃、工具調用、自省和迭代式推理。它不是一次性的問答，而是一個為達成目標而不斷“思考”和“行動”的動態過程。比如 ReAct 模式在每一步都需要 LLM 進行推理以決定下一步是思考還是行動；而 CoT/ToT 為了做出更優決策，會模擬多條未來的推理路徑，這都極大地增加了并行的推理調用需求。

正因為這些特性，AI Agent 的一次運行可能是一種“脈沖式”或“突發性”的資源消耗模式——即在極短時間內進行高強度計算，隨后進入長時間的閑置狀態。這種動態推理過程雖然功能強大，但也帶來了顯著的延遲波動和高昂的基礎設施成本挑戰。

另外 AI Agent 正從理論走向實踐，這預示著人機交互和任務自動化的根本性變革。然而，賦予這些 Agent 強大能力的自主性、學習能力和工具使用特性的同時，也引入了前所未有的安全風險。比如提示注入（Prompt Injection），工具濫用與不受控的系統命令、權限泄露、上下文泄露與級聯故障等。所以運行 AI Agent 的環境需要是一個隔離的、訪問控制與系統調用攔截的、可嚴格管理資源的、具備可觀測與審計的環境，也就是沙箱環境（Sandbox）。

所以我們嘗試通過阿里云函數計算 FC 這種 FaaS 形態的 Serverless 計算產品，幫助企業解決 AI Agent 運行的構建效率、資源成本、Sandbox 三大挑戰。

函數計算 FC 作為 AI Agent 運行時的優勢

AI Agent 的獨特運行模式和對計算資源的需求在函數計算 FC 這種 FaaS 計算資源上找到相對完美的解決方案。這種對應關系可以通過下表清晰地展示出來：

AI Agent 運行時需求	函數計算 FC 的優勢
事件驅動與異步執行	多種原生的事件觸發器和異步任務執行模式
不可預測的突發性工作負載	自動、快速的彈性伸縮（從零到N）
高昂的計算資源閑置成本	按實際使用量計費
需要安全、隔離的執行環境	天然沙箱化的運行時
復雜、多步驟的工作流	與工作流引擎有深度集成
數據持久化	與OSS，NAS，PolarFS做好了深度集成
快速迭代與開發的需求	聚焦業務邏輯，而非基礎設施

這里先來整體看一下函數計算 FC 作為 AI Agent 運行時的方案拓撲圖：

函數計算 FC 作為 AI Agent 自身的運行時（Runtime）

函數計算 FC 作為 AI Agent 的運行時有兩種模式：

• 函數計算 FC 作為 AI Agent 自身的運行時。
• 函數計算 FC 作為輔助 AI Agent 的沙箱環境（Sandbox）。

編碼式 - 函數計算 FC 作為計算資源運行 AI Agent

FC 作為 AI Agent 的運行時有兩種類型：

• 用戶自研的 AI Agent。或者使用 Spring AI Alibaba、LangChain、LlamaIndex、Pydantic AI 等開發 Agent 的綜合框架開發的 AI Agent。
• 在 FunctionAI 平臺上，已經托管了一些現成的 AI Agent 組件，比如 OpenManus，Jmanus，ComfyUI，SD WebUI 等，可以一鍵拉起使用。

FC 作為 AI Agent 運行時的優勢：

• 函數計算 FC 觸發器機制，實現 AI Agent 可靈活被調度。
• 函數計算 FC 按請求擴縮，提升 AI Agent 資源利用率，降低資源成本。
• 函數計算 FC 支持多種存儲機制，提升 AI Agent 數據存儲的靈活性和安全性。
• 函數計算 FC 函數實例動態安裝依賴包，提升 AI Agent 業務形態多樣性。
• 函數計算 FC 支持 Seesion 會話親和，進一步提升 AI Agent 執行任務的一致性和隔離性。

Chat AI Agent 解析

我們拜訪中的很多客戶做的 Agent 服務于 Chat 場景，本質上就是負責和用戶對話交互的 Agent，用戶和企業產品的一次對話就會產生一個任務，由 Agent 負責執行這個任務。

這種 Chat Agent 最大的特點是執行任務的 2 個不確定性，和 1 個一致性：

• 不確定性：

  • 執行環境里的各依賴包的不確定性。
  • 拿用戶相關文件信息路徑的不確定性。

• 一致性：

  • 需要同一個會話（Session）的請求都分配到同一個實例中，從而保證執行任務在上下文環境、上下文數據方面的一致性。

以上兩個不確定的特性就是 AI Agent 運行時自身以及配合存儲產品需要解決的問題。

執行環境里的各依賴包的不確定性

這是因為這類 AI Agent 處理的任務是千奇百怪的，用戶的問題是無法窮舉的，所以無論是 AI Agent 的實現代碼邏輯也好，還是運行 AI Agent 的運行時也好，都不可能事先預置所有的依賴。而是只實現 AI Agent 的主干核心邏輯，以及一個隔離并靈活的運行環境，在執行用戶的任務時，當遇到需要使用三方依賴時，可以暫停執行任務，先安裝所需依賴，然后再繼續執行任務，所謂兵來將擋，水來土掩。

函數計算 FC 方案：函數計算 FC 天然具備這個能力，每個實例底層都是隔離的容器環境，通過 subProcess 可以直接執行像 pip 或者 npm 的包管理命令來動態安裝依賴，因為每個實例都是完全資源隔離的，所以同一個 AI Agent 函數的不同實例都可以是獨一無二的運行環境，有不同的依賴，既相當于每一次執行用戶任務運行環境都是完全隔離和完全不相同的，完美匹配這類 AI Agent 的不確定特性。

拿用戶相關文件信息路徑的不確定性

這個不確定性特性的本質是用戶數據隔離的問題。通常情況下，這類 Chat AI Agent 的文件路徑是以用戶（User ID）/會話（Session ID）/任務（Task ID）命名的，目的有兩個：

• 細粒度存儲用數據，方便后續做檢索，或者長期記憶存儲。
• 實現用戶級別，會話級別，甚至任務級別的數據隔離。

這里就會涉及到如何選擇存儲產品，目前我們遇到的，或者說阿里云上適合的存儲產品無非就是云盤，OSS，NAS 以及 PolarDB 新出的 PolarFS。

• NAS：NAS 有單集群 10 億個文件的 SLA 上限，但是 AI Agent 場景，尤其 Chat 類的 AI Agent 很容易就會超過 10 億個文件，所以 To C 端的大型或者通用 Chat AI Agent 如果要使用 NAS 需要通過多集群來規避 10 億文件的 SLA 上限問題。

  • 函數計算 FC 方案：函數計算 FC 和 NAS 有產品間的深度集成，可以方便地通過白屏化或 OpenAPI 或命令行工具的方式將 NAS 掛載到函數上。這里我們推薦一個用戶對應一個函數，該函數掛載 NAS 路徑時只掛載根路徑，也就是只掛載用戶（User ID）這一層。在 AI Agent 的邏輯里再去拼接使用會話（Session ID）/任務（Task ID）這后兩級目錄，因為會話和任務這兩級目錄的名稱是不確定的、是動態的，所以更適合在請求中拿到會話和任務的名稱后，在代碼里在用戶這級根目錄下動態創建，然后做文件數據的存取。

• 云盤+OSS：這兩個存儲介質通常是配合使用，整體的邏輯是使用云盤實時存儲 AI Agent 執行過程中產生的各種類型的文件數據，在任務執行完之后，打包上傳到 OSS 作為持久化。OSS 的文件對象命名也基本遵循用戶（User ID）/會話（Session ID）/任務（Task ID）這個規范。

  • 函數計算 FC 方案：函數計算 FC 和 OSS 有產品間的深度集成，也是類似 NAS 一樣的掛載方式，將 OSS Bucket 映射為掛載根目錄。同時函數計算每個實例都有隔離的云盤存儲空間。在函數中，使用各個編程語言自帶的操作本地目錄存取文件的方式使用這兩種存儲介質即可。

• PolarFS：PolarFS 本質上和 NAS 的用法一致。

會話（Session）請求親和性

會話（Session）請求親和性除了上述的保證執行任務在上下文環境、上下文數據方面的一致性以外，同一個會話或任務復用同一個實例，也減少了動態安裝依賴的時間耗費，從而提高了執行任務的效率。

在這個特性上，有幾個細節點：

• 實例在支持會話（Session）請求親和性的同時，還要具備排他性，也就是不能再接新的會話。
• 如果該 Session 持續某個時間段（比如1個小時）沒有請求輸入，這個實例主動銷毀，從而保證資源成本最優。
• 當實例要銷毀時，需要有機制保證數據都被處理完畢，比如打包上傳到 OSS。
• 如果 Session 請求來的時候發現需要恢復 Session（Session 不是新的，且實例不存在），如何具備這個判斷機制。

函數計算 FC 方案：

• 函數計算 FC 支持會話（Session）請求親和性。只需要請求時在 Header 里帶著 x-fc-session-id:<Session ID> 即可，帶著相同 Session ID 的請求會被分配到同一個實例中。

• 函數計算 FC 可以設置單實例可以接的會話（Session）數，也就是說當該配置設置為 1 時，就具備了排他性，不能再接新的會話了。當然你還可以設置為多單實例可以接多個會話（Session），這樣可以滿足更加靈活的業務需求。

• 函數計算 FC 具備 Session Idle Time 的配置項，如果設置為 1 小時，那么在 1 小時內沒有請求進來，實例就會自動銷毀，這個值可以根據業務需求靈活設置。

• 函數計算 FC 有完善的實例生命周期管理能力，當實例要銷毀前會調用 prestop 這鉤子方法，用戶可以在這個方法中做數據善后處理。

• 如果 Session 請求來的時候發現需要恢復 Session 的最佳實踐為：

  • 在請求進入函數計算 FC 之前，需要有一個管控服務，該服務負責判斷 Session 是否存在，然后采取下一步對函數計算 FC 實例的使用方式。
    • 基于 Session ID 去查 OSS（或者是企業自己的數據表），如果有數據就走恢復邏輯（下載文件，恢復目錄），在實例中從 OSS 下載 Tar 包，并解壓。
    • 如果查不到，就是新的會話，在 Header 中設置新的 Session ID，走創建新實例的邏輯即可。

整體架構圖如下：

流程式 - AIStudio + 函數計算 FC 可視化構建 AI Agent

在這幾個月時間里，我們遇到了大量使用開源 Dify 構建 AI Agent 或者 AI 應用的客戶，這類客戶需要快速構建出可以輔助存量業務的 AI Agent，他們的關注點在業務上，并不會投入過多精力研究編碼式的構建方案，像 SaaS 類、泛企業類居多。

AIStudio 是什么

AIStudio 是阿里云自研的可視化構建 AI Agent 的產品。底層的工作流引擎基于阿里云 2018 年就商業化的產品云工作流（CloudFlow），底層算力基于函數計算。而前端的可視化部分我們基本沿用的Dify的設計語言。目的很簡單，就是讓用戶在不改變使用習慣的前提下享受到更靈活、更穩定、性能更好地可視化構建 AI Agent 的產品。

易用的同時性能更強：

• 兼容 Dify 的流程構建習慣

  • 使用 Dify 可視化流程編輯器的設計語言和 UE，最大限度兼容用戶在構建流程時的習慣。

• 具備正統流程引擎的高性能

  • 基于函數計算 FC 和云工作流 CloudFLow 實現的生產級流程引擎。

AIStudio 的優勢和特點：

• 支持函數計算節點，使構建流程的靈活性得到大幅度提升。
• 默認支持最大 1000QPS，且可以按需繼續提升。
• 多節點復雜流程依然具備穩定高可靠的執行性能。
• 除了 HTTP 以外，還支持多種調度方案，比如 OSS，SLS，Kafka，RocketMQ等。
• 具備完善的可觀測能力，包括整體流程和具體的每個節點的可觀測。

雖然目前 AIStudio 還有一些能力正在不斷完善中，但是針對上述開源 Dify 的硬傷問題已經具備了徹底解決的能力：

• 性能問題：

  • AIStudio 一個流程默認支持最大 1000QPS，且可以繼續提升。這個對絕大多數 AI Agent 來說已經是非常大的 QPS 了，畢竟流程里或多或少都需要和 LLM 交互。

• 安全問題：

  • 云原生 API 網關和 AIStudio 做了產品間集成，訪問基于 AIStudio 構建的流程，都可以通過云原生 API 網關側做管控，這里就包括了多種鑒權方式。
  • AIStudio 里唯一涉及到 API Key 的就是和 LLM 交互的配置，LLM 節點和 Agent 節點都可以配置由 AI 網關代理的 LLM，這樣 LLM 的 API Key 由 AI 網關做統一管理（后續文章會有解釋）。

• 會話調用問題：AIStudio 不僅支持定時調度能力，還具備幾十種云產品事件的觸發能力，被調度能力一騎絕塵。

• Nginx 問題：開源 Dify 核心問題之一就是它的網關層是一個 Nginx，Nginx 本身就有不少的短板（畢竟 ACK 的 Ingress 也不推薦使用 Nginx 了，而是云原生 API 網關）。所以通過云原生 API 網關 + AIStudio 完美規避這個問題。

• LLM 問題：

  • 自定義前置后置邏輯：AIStudio 提供獨有的函數計算 FC 節點，所以可以靈活地在 LLM 節點前后使用函數計算 FC 節點實現用戶自定義的業務邏輯。
  • 通過 LLM 節點和 Agent 節點配置由AI網關代理的 LLM 來解決以下問題：

    • Token 統計錯誤：在 AI 網關側做統一的 Token 統計觀測，維度更多，粒度更細。因為 AIStudio 可能只是 LLM 的其中一個調用方而已（通過按照消費者觀測）。

    • Proxy 訪問異常：通過 AI 網關代理 LLM 的 Fallback 能力提升 LLM API 的高可用性。

    • 動態結構化輸出：可以使用 AI 網關的插件或者在 LLM 節點后使用函數計算 FC 節點來實現。

    • Model Alias：通過 AI 網關代理 LLM 的 Model Name 切換模型的能力實現。

• RAG/知識庫管理問題：我們不重復造輪子，AIStudio 支持檢索百煉知識庫的節點。將 RAG/知識庫管理交給更專業的百煉來處理。

典型場景探討

我們在與客戶的交流中，遇到使用可視化方式構建 AI Agent 最多的場景有以下幾類：

• 智能客服典型場景

  • 輸入：用戶問題（文本）+ 企業上傳的圖片
  • 處理：
    • 通過 VL 模型識別圖片內容，然后結合用戶的問題一起重新構建為新的問題。
    • 通過 LLM 模型對新問題進行推理。
    • 推理時需要結合企業的知識庫。
  • 知識庫構建
    • 企業的原始知識庫信息有多種格式：PDF，PPT，TXT，DOC
    • 使用了 Dify 自帶的知識庫及知識庫檢索能力，沒有構建自己的 RAG 邏輯，完全依賴 Dify 的能力。
    • • 使用 AIStudio，可以將知識庫構建移到百煉知識庫中。

• 營銷典型場景：營銷活動各素材的組裝。初始素材是企業設計團隊使用中臺部門搭建的 SD 平臺輔助做設計產出。然后會基于這些初始素材生成各種端側，各種尺寸的宣傳海報。這些不同的海報尺寸不一樣，初始素材的排布不一樣，但初始素材不能變。雖然前半段可以借助文生圖輔助，但后半段企業驗證過，目前的 DiT 模型沒法保證初始素材的完全一致性。所以目前后半段還是人工在處理。這個場景目前 Dify 和 N8N 都沒有好的實現方式。我們幫客戶企業設計的方案如下：

  • 因為后半段不涉及出圖，只是圖片尺寸的調整和現有素材的排布，所以最有效的方法是結合 LLM 的 Coding 能力，以寫 HTML+CSS 的方式來實現，然后再截圖。也就是通過自然語言告訴 LLM，寫一個頁面，頁面是什么尺寸，頁面上有哪些素材，每個素材在什么位置。
  • 該場景有幾個核心需求：
    • 初始素材存在哪，如何和存放素材的組件關聯集成。
      • 推薦使用 OSS。
    • LLM 節點和 Agent 節點支持多模態，客服場景也有涉及。
    • 需要有一個預覽 LLM 生成的 HTML+CSS 代碼的節點，本質上屬于一個 Code Sandbox，Run 代碼，可以通過 AIStudio 中的函數計算節點實現。
    • 需要有一個人工處理的節點，需要打斷流程，因為生成的圖片還是需要人工審核。
      • 這個能力 CloudFlow 本身是支持的，因為有回調模式，可以讓流程暫停，等待企業業務邏輯處理完后回調流程接口，繼續讓流程運行。
    • 將頁面截圖并保存在 OSS 的節點。

• 銷售場景：做產品銷售時，期望對營銷團隊或設計團隊，或產品團隊提供的圖片，在上架流程中做處理，比如去除背景，替換背景，局部改寫等。本質上就是借助 DiT 模型對圖片做處理。

  • 目前可以使用 AIStudio 中的函數計算 FC 節點，在函數中調用 FunctionAI 中的 ComfyUI 項目的 API 來實現。

函數計算 FC 作為輔助 AI Agent 的 Sandbox

如上文所述，為了確保 AI Agent 能夠安全、可控地運行，一個強大的沙箱環境（Sandbox）至關重要。這就像是為 AI Agent 提供一個安全的"游樂場"，讓它在其中探索和執行任務，同時又不會對外部真實世界造成意外影響。

但除了運行 AI Agent 自身以外，還有一大類是編外的，用于輔助、提升 AI Agent 或基模能力的沙箱環境（Sandbox）場景，同樣也是函數計算 FC 擅長的。

目前我們交流與落地實踐的有四大類編外沙箱場景：

Code Sandbox

這一類場景的本質就是在一個隔離的環境中運行由用戶生成的或者 LLM 生成的代碼，分為兩種業務場景：

• 協助訓練基模的 Coding 能力：給 LLM 喂需求，由 LLM 生成代碼，然后拉起函數計算 FC 實例，運行代碼，評判結果。
• 實時運行展示用戶編碼類的任務：這里包括執行后端代碼，也包括執行渲染前端代碼。無論是基模公司還是互聯網企業的 AI 場景，都有相似的需求。比如 Gemni 的 Canvas 能力，千問的網頁開發能力，MiniMax 的 Agent 生成代碼并運行的能力等。

Code Sandbox 場景的一些挑戰點：

• 運行環境支持多種編程語言，無論是基模還是增強存量業務的 AI Agent 都不可能限制用戶只使用某一種或某幾種開發語言。

  • 函數計算 FC 具備所有開發語言運行環境的特性天然匹配這個特性。

• 判定結果不僅僅是代碼運行結果是否達到預期，還會收集代碼執行過程中的硬件指標（并不是所有機型都提供獲取這類指標的接口），抓容器的指標，判斷衡量代碼執行效率。

  • 函數計算 FC 提供能把這些數據拿走的能力，數據抓出來后給到另一個服務做衡量（另一個函數）。

• 執行代碼的任務不僅僅是單線程任務，可能會起子線程并行處理任務。

  • 函數計算 FC 支持實例內再起多線程執行子任務的能力，得益于函數計算 FC 的實例是完全獨立的環境，只要函數規格夠，多線程運行也不會影響其他實例，不會產生資源爭搶。

• 訓練基模 Coding 能力這個場景，大家可能覺得它是一個離線場景，對時延要求不高，但其實并不是這樣，反而對時延要求很高。因為訓練 Coding 這個鏈路還涉及到 GPU，如果在執行 Code 這個環節消耗太多時間，就意味著 GPU 有很大概率要空轉，產生資源浪費，所以通常對執行 Code 環節都有嚴格的時延要求，具體的時延情況是根據能讓 GPU 持續運行的整體節奏而定的。

  • 對時延要求高且非常敏感的場景，廣告領域的 RTA 絕對算一個，函數計算 FC 有成熟的 RTA 方案，并且支撐著不少大型企業的 RTA 業務，所以在優化冷啟動，解決時延方面有足夠的經驗。那么在 Code Sandbox 這個場景通常會使用彈性實例與毫秒級快照實例組合的方式來保證時延要求。

Browser Use Sandbox

Browser Use 其實并不是一個很新的東西。

在 AI 場景下，當前 Browser Use 主要有兩類主要的應用場景：

• 輔助數據采集，比如需要登錄的一些網站，獲取論文報告等。
• 做聯網搜索，目前主流搜索引擎的 API 能力參差不齊，且價格不菲，所以通過 Browser Use 做聯網搜索在靈活性和成本方面都是較優的選擇。

當 AI Agent 的任務從封閉的模擬環境擴展到開放、動態且充滿潛在誘惑的互聯網時，其面臨的安全挑戰也隨之升級。對于一個在 Web 上操作的 AI Agent 來說，互聯網不再僅僅是信息的來源，它本身就是一個動態的、可能包含惡意內容的輸入源。網頁的內容直接影響 Agent 的感知和決策，所以這就是為什么 Browser Use 也需要沙箱環境的原因。

Browser Use Sandbox 場景的一些挑戰點：

• 需要 Session/Cookie 親和性。輔助數據采集時，需要登錄后才能獲取到數據，所以需要相同 Session 的請求分配到同一個實例中，避免反復登錄。

  • 上文中已經解釋了函數計算 FC 是如何支持會話（Session）親和性的。所以也是天然適配 Browser Use 的特性。

• 需要基于內存擴容，這個場景比較吃內存，且大多數語言內存回收機制都不好。

  • 函數計算 FC 默認按請求擴容，此外還支持用戶配置按時間和并發度擴容，為了支持 Browser Use Sandbox 場景，又支持了按內存擴容的能力。

• 優雅下線，也就是實例要銷毀時做 Browser Use 操作的后處理。

  • 依托函數計算 FC 的生命周期管理能力，通過 prestop 鉤子函數做 Browser Use 收集數據的后處理操作。

RL Sandbox

有一些基模企業或做通用 AI Agent 的企定，會專注在垂直類場景，這類企業會針對特定場景對 LLM 或 AI Agent 算法做定向強化學習。

這類強化學習場景對于客戶來說，希望有一個獨立的、隔離的運行環境，即沙箱環境，會有以下共同的訴求點：

• 安全性：Agent 在訓練初期的行為往往是隨機且不可預測的。在沙箱中，錯誤的決策不會造成任何實際損失。
• 高效率與可復現性：沙箱環境可快速拉起，快速復制相同的環境，讓 Agent 在短時間內經歷海量的訓練。同時，研發可以精確控制每個環境的每一個變量，從而能夠復現實驗結果，進行可靠的對比分析。
• 降低成本：不希望過多維護 IaaS 資源，隨用隨拉起，并且強化學習也不是實時業務，如何最大限度提升資源利用率也是降低成本的優化手段。
• 運行環境完整性：沙箱環境不要有太多限制和約束，期望和一臺 Linux 機器一樣去使用。甚至可以設置一些系統級參數。

函數計算 FC 作為 FaaS 形態的 Serverless 計算產品，天然匹配以上這些需求，所以企業選擇使用函數計算 FC 作為 RL Sandbox 的底座。

RL Sandbox 場景的一些挑戰點：

• 動態安裝依賴，企業的業務環境會構建為一個容器鏡像，但只是包含最基礎，最小閉環的依賴。在真正執行時可能會需要動態安裝依賴。

  • 上文中已經介紹過函數計算 FC 實例內支持動態安裝依賴。

• 實例不能被復用，避免影響執行結果，污染執行過程產生的數據。

  • 函數計算 FC 默認實例是可以被復用的，這樣可以大幅降低冷啟動，減少 RT。但同時也可以通過配置關閉實例復用的能力，從而滿足這類強化學習的場景。

仿真訓練 Sandbox

仿真訓練 Sandbox 場景目前主要聚焦在具身智能場景。

具身智能仿真訓練基本流程：

• 使用 NV Omniverse 提供的可視化界面，構建虛擬環境，準備環境數據。

• 構建好仿真環境和數據后，生成任務包，將任務包分發到 GPU 服務跑訓練任務。該服務使用的框架大多數也是 NV Omniverse 里的 Isaac Sim。

• 分發任務的邏輯通常會使用 Airflow，且 Airflow 的流程是比較簡單的。

• GPU 服務跑完訓練任務后，狀態會回調 Airflow，由 Airflow 統一來展示這次任務的執行結果。

函數計算 FC 具身智能仿真訓練方案：方案分為兩種類型。

• 函數計算 FC 具身智能仿真訓練自閉環方案：

  • 不帶流程的方案：適合任務分發簡單的企業，或者剛開始做仿真訓練的企業。
  • 帶流程的方案：適合任務分發相對復雜的企業。

• Airflow + 函數計算 FC 的具身智能仿真訓練方案：適合對 Airflow 模式非常認同的企業。

無論是編碼方式構建 AI Agent，還是可視化流程式構建 AI Agent，一旦脫離了 LLM，就不存在 AI 一說了。所以 AI Agent 如何合理地、生產級地與 LLM 結合，將是我們下篇文章的核心內容。

關注阿里云云原生公眾號，后臺回復 “企業AI實踐”，即可獲得完整的企業級 AI 應用構建的最佳實踐 PPT。