微軟向Azure Logic Apps agent工作流添加了沙箱化程式碼直譯器,Python、JavaScript、C#和PowerShell在Azure Container Apps(ACA)工作階段池上的Hyper-V隔離工作階段內執行。對建構者重要的底層細節:這是VM級隔離,而非容器級——比典型的Docker或gVisor沙箱對breakout和prompt-injection驅動的惡意程式碼提供更強的保證。支援每工作流的模型選擇,因此除了Azure平台本身之外,沒有鎖定到特定LLM提供商。
沙箱化程式碼執行一直是需要計算、轉換或視覺化的agent工作流的慢性瓶頸。直到最近,建構者還在拼接E2B、Modal、OpenAI的程式碼直譯器,或者用Firecracker或microVM自己滾一個。Logic Apps整合將直譯器定位為agent loop內的工具——LLM生成程式碼、在隔離中執行、回傳結果、繼續。在ACA工作階段池上啟用網路隔離時,「資料從不離開定義的網路邊界」,這是用於將企業資料保持在agent洩漏面之外的compliance表述。公告中的架構師框架瞄準多企業系統編排——ERP、CRM、資料庫、帶重試邏輯和稽核trails的API——不是greenfield的agent tooling。
生態系統解讀是VM隔離的程式碼直譯器正在成為雲原生原語,而不是自己建構的line item。Hyper-V比容器更重——冷啟動更慢、每次執行成本更高,但安全架構是企業agent部署在tool-use表面上的prompt-injection攻擊變得真實之後所需要的。AWS和GCP在不同成熟度上有類似的原語(帶隔離的App Runner、Cloud Run sandboxing、Sandbox API),雲提供商在VM級程式碼直譯器原語上的趨同意味著「我們應該使用E2B還是滾自己的」問題獲得了第三個答案:如果你已經在那裡,使用雲原生原語。鎖定成本是真實的——Logic Apps + ACA = Azure-only——但對於已經在Azure上有稽核和合規需求的組織,它消除了「滾自己的沙箱」風險類別。
如果你週一早上在Azure上建構agent:這是使「agent執行程式碼」成為核取方塊而不是服務整合專案的變化。如果你在AWS或GCP上建構:追蹤等效物,並期待相同的架構模式。轉變是沙箱化程式碼執行從agent建構者的責任轉向雲提供商原語,這種轉變是結構性的。