微软近日正式宣布Azure Container Apps Express基于全新通用沙箱层发布（GA），这一部署模型彻底简化了环境配置流程，以偏好性默认配置取代传统配置项，大幅降低开发门槛。Express与同步发布的Sandboxes组成核心技术组合，其中Sandboxes作为Express的计算隔离层，依托亚秒级启动能力与微VM隔离实现高效计算，且支持快照挂起恢复，为智能体场景提供快速恢复环境。Express具备多副本、按秒计费、零空闲成本等优势，同时定位为开发者优先与智能体优先，尤其强调AI辅助工作流创建与更新应用的速度显著优于手工配置，加速智能体工作流开发落地。该组合与谷歌Kubernetes Engine相关方案在架构上高度相似，瞄准智能体环境需求。Express作为Sandboxes之上的应用层，提供了包括多副本、自动扩缩容、HTTP入口、多环境变量等功能的精简能力，明确排除了自定义域名、GPU计算、环境级特性等扩展需求，其边界清晰且定位聚焦。在技术适配层面，Express基于Sandboxes底层平台原语，可预置资源池实现亚秒启动，具备突发扩展至数千并发沙箱能力，并通过挂起、恢复功能保障计算状态，进一步支撑智能体应用的灵活运行。目前Express已覆盖超40个Azure区域，公测期间积累的数千应用验证了其市场优先级，为智能体开发与部署提供了高效、轻量的新路径，进一步推动智能体场景的技术落地。

--91likeyou---

开发者可以直接使用 Sandboxes，而不必通过 Express。微软将 Sandboxes 定位于智能体平台（agent platforms）与安全代码执行服务。其顶层 ARM 资源为 Microsoft.App/SandboxGroups，被描述为共享配置的沙箱之间的管理边界，可类比为 Container Apps 环境。

Reddit上的反应表明，这一原语在正式发布之前便早已被使用。评论者 MuhBlockchain 提供了一个微软官方材料未曾提及的细节：

ACA Sandboxes 实际上是众多核心 Azure 服务（包括 Foundry Hosted Agents）的底层支撑。

其他人则描述了各自的部署情况。评论者 tankerkiller125real 写道，他的团队将其用作面向客户的智能体 harness 的 Python 沙箱。评论者 Minute_Passion_8077 描述了通过 Bicep 为客户部署它们的方式：

只要把它指向一个镜像就可以开始运行了。如果不需要了怎么办？直接缩容到 0。

当被问及 Sandboxes 与 Container Apps jobs 有何区别时，评论者 brianveldman 以生命周期作为分界线：

ACA Jobs 是为运行至完成（run to completion）的任务和批处理（从启动到运行再到完成）而设计的，而 Sandboxes 提供的是可编程、隔离的计算环境，并带有生命周期控制。

并不是所有人都认可"隔离"这一说法。评论者 RustOnTheEdge 对“硬件隔离的 microVM”这一描述公开表达了怀疑，但并未展开说明。有一个问题尚未得到解答：评论者 HgnX 询问 Azure Kubernetes Service 中是否也提供同样的能力，并指出他的团队之所以运行 AKS，是因为存在一些 Container Apps 无法满足的需求。

这种组合模式非常眼熟。Google Kubernetes Engine 将Pod快照（通过 gVisor 对 CPU 和 GPU 内存进行快照）与用于运行不受信任智能体代码的 GKE Agent Sandbox 搭配在一起。微软如今则将 microVM 隔离与基于快照的挂起/恢复相搭配，他们瞄准的是同一类工作负载。两家厂商回答的是同一个问题：如何为智能体提供一个空闲时零成本且能在不到一秒内恢复的隔离环境。

Express 本身则是位于其上的、带有偏向性的应用层，提供了 Container Apps 能力的一个精简子集：缩容至零、多副本、运行在微软托管域名上的 HTTP 入口、环境变量、手动密钥、IP 限制、日志流式传输，以及基于 HTTP、CPU 或内存规则的自动扩缩容。

被排除在外的能力确定了它的边界。Express 不支持自定义域名、可用区冗余、Key Vault 密钥引用、Easy Auth、Open、Dapr、jobs、工作负载配置文件（workload profiles）、GPU 工作负载、多修订版本与流量切分，也不支持系统分配的管理身份。它缺少服务发现，因此应用之间通过各自的公网 URL 通信，且入口仅支持 HTTP。微软的文档列出了完整的清单，还包括对出站子网（一旦设定便无法更改）以及每副本存储的限制。

微软对这一边界的态度是非常坦率的：当团队需要更强的网络控制、GPU 计算、高级配置或 Dapr 这类环境级能力时，建议采用标准环境。不过文档同时也将“快速原型开发”列为一种场景，团队快速构建之后，无需重新平台化（replatforming）便可继续在生产环境中运行。对于一个需要自定义域名、可用区冗余或 Key Vault 支撑密钥的工作负载而言，这两种说法在方向上是相互矛盾的。

访问权限同样比标准 Container Apps 更窄。Express 要求使用受 Microsoft Entra ID 支持的账户，不支持个人 Microsoft 账户。管理是通过专用界面而非 Azure 门户进行的：Container Apps 使用 containerapps.azure.com，Sandboxes 使用 sandboxes.azure.com。当被问及这些界面是否会取代门户时，MuhBlockchain 表示不会：

尽管包含了更多细节，但它只是一个独立的视图。你仍然可以通过常规的门户体验来管理它们。

已经在运行标准环境的团队拥有一条迁移路径，而且微软也给出了一些提示。自助迁移通过“归档与恢复”来实现：先归档现有环境，再将其恢复为 Express 环境。微软表示，该过程会保留应用与环境配置，耗时约 15 分钟，且不改变免费用量额度（consumption-free grant）。FAQ 还提到，迁移通知中包含一份退出（opt-out）表单，供需要额外审批或协调的组织使用，并指出处于非活动状态的环境（即没有运行中的应用或 jobs、且近期无活动的）可能会被归档并转入休眠。

在正式发布时，Express 已经覆盖超过40个Azure区域，几乎涵盖了提供 Container Apps 的所有公有区域。微软表示，在公测期间已创建了数千个 Express 应用，并且客户反馈确立了本次发布的优先级。

查看英文原文：Container Apps Express Reaches GA on a Newly Generally Available Sandbox Layer

🔥 热词：#Container · #Apps · #Express · #first · #Azure · #Express在新的通用沙箱层上正式发布 · #微软近期宣布Azure · #Express正式发布