微软近期宣布Azure Container Apps Express正式发布（GA），这是一种部署模型，省去了环境预置（provisioning）这一步骤，并用带有偏好性的默认配置（opinionated defaults）取代了大部分配置项。它与Azure Container Apps Sandboxes同步正式发布，后者正是 Express 所运行的隔离计算层。这一组合与谷歌今年在 Kubernetes Engine 上推出的方案在形态上一致。
Express 接收一个容器镜像、一个区域，以及应用所需的任意配置，随后自行完成计算、入口（ingress）和扩缩容的预置。应用运行在按秒计费的 CPU 之上，空闲时缩容至零，且不收取环境预置费用。微软将 Express 定位为"开发者优先"（developer-first）与"智能体优先"（agent-first），并明确强调了后者：
AI 辅助的工作流创建和更新应用的速度，远比任何人手工配置基础设施要快。
这种速度源自底层。微软的文档指出，Express 完全构建于 Container Apps Sandboxes之上，这是一种平台原语（platform primitive），它能从预热的资源池中预置以实现亚秒级启动，将每个工作负载分隔在各自硬件隔离的 microVM 边界内，并能突发扩展至数千个并发沙箱。Sandboxes 还支持挂起（suspend）与恢复（resume），对包括内存和磁盘在内的完整状态进行快照（snapshotting），并能在亚秒内完成恢复。
开发者可以直接使用 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、OpenTelemetry、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