背景
根據 InfoQ 的報導，微軟近期宣布 Azure Container Apps Express 正式進入一般可用（GA）階段。這是一種新的部署模型，最大特點是移除了傳統上必須先建立環境（environment）的佈建步驟，並以一套預設意見（opinionated defaults）取代大部分的手動設定。與 Express 同步 GA 的，還有其底層的運算基礎：Azure Container Apps Sandboxes，一個提供硬體隔離的獨立運算層。這個「上層簡化部署、下層強化隔離」的組合，與 Google 今年在 Kubernetes Engine 上推出的方案在架構思維上高度相似，顯示兩大雲端供應商正在回答同一個問題：如何為 AI 代理（agent）提供一個閒置時不計費、啟動時又能在一秒內回復的隔離執行環境。
核心內容與運作方式
使用 Express 時，開發者只需提供容器映像、目標區域以及應用程式所需的設定，剩下的運算資源佈建、入口（ingress）與擴縮容都由平台自動處理。應用程式運行在消費型 CPU 上，採按秒計費，閒置時可縮減至零，且不收取環境佈建費用。微軟將 Express 定位為「開發者優先、代理優先」（developer-first and agent-first），並明確指出後者的意涵：AI 輔助的工作流程建立與更新應用程式的速度，遠遠超過人工手動設定基礎設施的速度。
支撐這種速度的關鍵在底層。根據微軟文件，Express 完全建立在 Container Apps Sandboxes 之上。Sandboxes 是一種平台原語（platform primitive），從預熱池（prewarmed pools）中佈建以達到次秒級啟動，每個工作負載都被隔離在獨立的硬體隔離 microVM 邊界內，並可爆量擴展至數千個並發沙箱。Sandboxes 還支援暫停與恢復（suspend and resume），能快照包含記憶體與磁碟在內的完整狀態，並以次秒級速度還原。開發者也可以不透過 Express 直接使用 Sandboxes，微軟將這條路徑定位給代理平台與安全的程式碼執行服務。其頂層 ARM 資源為 Microsoft.App/SandboxGroups，作為共享設定的沙箱管理邊界，概念上類似 Container Apps 環境。
社群回饋與技術脈絡
Reddit 上的反應顯示，這個原語在正式公告前似乎已被廣泛使用。有評論者指出，ACA Sandboxes 實際上支撐了多項 Azure 核心服務，包括 Foundry Hosted Agents，這一點微軟官方資料並未明說。也有團隊分享實際用途，例如為面向客戶的代理框架（agent harness）建立 Python 沙箱，或透過 Bicep 為客戶部署，只需指向映像即可運行，不需要時就縮減到零。被問及 Sandboxes 與 Container Apps jobs 的差異時，有評論者以生命週期作為分界：Jobs 設計用於執行至完成的批次任務，而 Sandboxes 提供的是可程式化、具生命週期控制能力的隔離運算環境。
當然也有保留意見。對於「硬體隔離 microVM」的說法，有評論者表達了未加闡述的懷疑。另一個未獲解答的問題是：同樣的能力是否會出現在 Azure Kubernetes Service 中，因為有團隊基於 Container Apps 無法滿足的需求而選擇了 AKS。從產業脈絡來看，Google Kubernetes Engine 將 Pod 快照（透過 gVisor 對 CPU 與 GPU 記憶體建立檢查點）與 GKE Agent Sandbox 搭配，用於執行不受信任的代理程式碼；微軟則以 microVM 隔離搭配快照式暫停恢復，瞄準同一類工作負載，兩者的技術路線不同，問題意識一致。
功能範圍與限制
Express 提供的是 Container Apps 能力的精簡子集，包含縮減至零、多複本、微軟管理網域上的 HTTP ingress、環境變數、手動密鑰、IP 限制、日誌串流，以及基於 HTTP、CPU 或記憶體規則的自動擴展。但它的排除清單同樣清楚地定義了邊界：不支援自訂網域、區域備援、Key Vault 密鑰參考、Easy Auth、OpenTelemetry、Dapr、jobs、工作負載設定檔、GPU 工作負載、多修訂版本與流量切分，也不支援系統指派的受控識別。由於沒有服務探索機制，應用程式之間只能透過公開 URL 通訊，且 ingress 僅限 HTTP。此外，出站子網路設定後無法變更，每複本儲存空間也有上限。
微軟明確建議，需要更細緻的網路控制、GPU 運算、進階設定或 Dapr 等環境層級能力的團隊，應使用標準環境。但文件同時又把「快速原型開發後直接留在生產環境」列為使用情境，對於日後需要自訂網域或 Key Vault 密鑰的工作負載而言，這兩種說法方向並不一致，值得在採用前釐清。存取方面也較標準 Container Apps 更窄：Express 要求 Microsoft Entra ID 帳戶，不支援個人微軟帳戶；管理介面則是獨立的 containerapps.azure.com 與 sandboxes.azure.com，而非 Azure 入口網站。不過據社群說法，這只是額外的檢視介面，常規入口體驗仍可管理。
既有團隊的遷移路徑也已備妥：將現有環境封存後還原為 Express 環境，微軟表示過程約 15 分鐘，保留應用程式與環境設定，且不影響消費型免費額度。遷移通知中附有退出表單，供需要額外核准流程的組織使用；長期無活動的環境則可能被自動封存休眠。GA 時 Express 已覆蓋超過 40 個 Azure 區域，幾乎涵蓋所有提供 Container Apps 的公有區域，微軟表示公開預覽期間已建立數千個 Express 應用程式，本次版本的功能優先順序即來自客戶回饋。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。