强化学习生态正在快速采用 Ray 作为后训练复杂工作流的统一计算运行时。Google Cloud 上已有客户用 Ray 跑多模态数据管道和前沿强化学习任务。但随着 agentic 和推理模型演进，一个关键瓶颈浮出水面：如何在规模上编排安全、隔离的沙箱，以执行动态回滚、代码生成和多轮工具交互。今天，Google Cloud 与 Anyscale 合作推出一个实验性 Ray 库，将 Google 开发的 agentic AI 技术带进分布式 Ray 集群，提供原生、高性能的沙箱能力。

设计 Ray Sandboxing 时，核心目标是让它自然融入现有 Ray 编程模型，而不是另搞一套隔离执行抽象。沙箱与 Ray 管理的其他资源具有相似属性：需要放置到机器上、分配资源、创建销毁、故障恢复、随负载伸缩。因此，每个高层沙箱通过一个 Ray Actor 表示：Ray 调度器决定在哪个节点运行沙箱并预留 CPU 和内存资源，沙箱 Actor 管理生命周期，gVisor 提供该节点上的隔离执行环境。从 Ray 2.58 开始，框架作者和研究者可以用与现有工作负载相同的 Ray API 来管理沙箱环境。例如，从 OCI 兼容镜像创建 gVisor 沙箱并返回 Actor 句柄，exec 调用就是普通的 Ray Actor 调用，沙箱可位于集群任意位置。创建的 Actor 是代理，会把操作转发给 gVisor。

沙箱 API 覆盖 agentic 工作负载所需的基本生命周期：从 OCI 容器镜像创建环境，设置 CPU 和内存限制，配置环境变量、工作目录和网络，执行命令，读写上传下载文件，检查沙箱状态，终止或删除环境。对于更低层用例，SandboxRuntime 提供对本地 gVisor 沙箱的直接访问，并允许用户在交给 gVisor 之前修改 OCI 规范。文档还展示了如何用该 API 在 Actor 内构建本地沙箱池。

为什么选 gVisor？运行模型生成的代码，意味着要把环境内的代码视为不可信。Ray Sandboxing 采用 Google 开源的 gVisor 作为初始沙箱运行时。gVisor 在用户空间实现了大量 Linux 系统调用接口，在负载和主机内核之间增加了额外的隔离边界。它兼容 OCI，支持标准容器镜像，无需向沙箱暴露 Docker daemon 或宿主机 Docker socket。这种组合对 agentic 工作负载尤其有用：环境足够轻量可以动态创建，同时比直接在普通容器中执行生成代码提供更强的隔离。gVisor 还提供亚秒级沙箱启动和低单沙箱内存开销，使得沙箱可以当作较细粒度的分布式资源使用。

未来的 Ray 版本中，计划扩展到其他沙箱运行时，如 Agent Substrate 或 Kata Containers。想尝试的话，可以查阅 Ray 文档和 GKE 上的 Ray sandboxing 用户指南，也可以在 GitHub issue 参与讨论。