Replit 用 microVM 重写沙箱引擎

Agent 沙箱如今风靡一时。每隔几周就会有一家新的沙箱初创公司出现。在 Replit，我们运行沙箱已有近十年之久。多年来，我们一直运营着自研的沙箱基础设施，让任何人都能轻松在线编写代码，而如今 Agent 使用这些沙箱来构建应用，甚至完全不需要编写任何代码。

在过去几个月里，我们完成了沙箱引擎的全面重写并逐步上线，以提升安全性、能力以及跨云的可移植性。我们的 Bring Your Own Cloud 方案将 Replit 带入客户的 AWS、Google Cloud 或 Azure 环境。与大多数基础设施工作一样，我们必须在无人察觉的情况下完成这一切。我们平滑迁移了数亿个项目，没有数据丢失。在本文中，我们将深入介绍我们如何改变隔离边界、保持沙箱的高速，并让新引擎在规模化下运行。

在本文中，我们将深入介绍我们如何改变隔离边界并保持沙箱的高速。在第 2 部分中，我们将介绍如何在 Kubernetes 上同时编排数万个 microVM。

我们的工作为何重要

安全性、对齐与隔离管控是 AI 行业最热门的话题之一。OpenAI 的 Hugging Face 事件和 Anthropic 的评估事件向世界表明，自主 Agent 能够触及并损害其预期范围之外的现实系统。尽管这些评估可能降低了模型防护措施，但明确的结论是：在 AI 时代，传统的安全边界已不再足够。NIST 的 Agent 标准倡议和国会的审查已将隔离、身份与监控牢牢提上行业议程。

沙箱对 Replit 而言并非新品类。它是我们的客户自早期以来一直依赖的基础设施，也是我们纵深防御方法的基础。早期我们就意识到，随着 AI Agent 日益自主并被广泛采用，其运行环境也需要随之演进。行业如今正趋于一致地提出相同的要求。DeepSeek 的 DSec 进一步印证了弹性沙箱化计算基础设施的必要性，而 Kubernetes Agent Sandbox 或 Google 的 AX 与 Agent Substrate 等开源倡议则提供了额外的验证。今年早些时候，自 2025 年以来公布的精选 Agent 基础设施初创公司融资轮次中，Daytona、E2B、Runloop 和 Blaxel 的融资总额达 5930 万美元。

2025 年 11 月，我们着手重建沙箱基础设施，以支持更自主的 Agent、持久化工作区和更高的并发量。到 2 月，我们已在内部使用它。接下来的几个月里，我们对其进行了加固并逐步推广。

通往 MicroVM 之路

我们的沙箱引擎起步很简单：在 Docker 中执行无状态代码，分布在 Google Compute Engine 虚拟机上。多年来，我们增加了持久化工作区、公共端点、缓存的 Nix 包、区域集群，以及支持即时磁盘分叉的无底存储。当我们着手规划通往 microVM 的路径时，我们意识到从零开始要比将现有运行时从 Docker 移植到 microVM 容易得多。这也让我们能够快速进行原型开发和迭代，而不会危及现有系统。

microVM 是一种轻量级虚拟机，拥有自己的 Linux 内核和一组最少的虚拟设备。我们使用 KVM 将每个沙箱与宿主机以及其他客户的工作负载隔离开来。

容器仍然在每个沙箱内隔离进程。硬件辅助虚拟化现在则将沙箱本身隔离开来。

首先，我们需要选择一个虚拟机监视器（VMM）来运行每个 microVM。我们选择了 Cloud Hypervisor，它与 Firecracker 共享可复用的 rust-vmm 组件，并包含 virtiofs、透明大页、设备热插拔和实时迁移等功能。嵌套虚拟化还让我们能够运行会自行启动虚拟机的开发环境。热插拔和内存快照对我们的设计尤为有用，因为它们允许按需将客户的磁盘挂载到运行中的热池虚拟机上。我们还对 Cloud Hypervisor 打了补丁，以提升快照在我们支持的裸机和虚拟化环境之间的可移植性。

每个 microVM 内部都有一个最小化的 init 进程，负责启动、停止和监控其容器。主机通过 vsock 使用 gRPC 与其通信，vsock 是一种无需 IP 网络的主机到客户机通道。

所有基础组件就位后，我们需要一个单一的监管程序来搭建沙箱：启动 microVM、配置其网络、启动容器，并运行客户端用来通过我们的 river 协议与其交互的服务器。

这些是通用 Linux 虚拟机，而非绑定于单一应用构建工作流的环境。我们将同一基础用于我们的自动驾驶公司：智能体调查事件、审查代码、分析业务数据并对支持工单进行分诊。1 月下旬，我们将 microVM 和远程文件系统与访问策略、令牌代理、审计日志以及我们的 ZeroTrust 网络相结合，使团队能够针对他们实际使用的系统并行运行智能体。人们设定目标。隔离环境为智能体提供了完成工作的场所。

安全与隔离

过去一年中，出现了大量可导致本地权限提升（LPE）的 Linux 内核 CVE：Copy Fail、Dirty Frag（xfrm-ESP）、Dirty Frag（RxRPC）、Fragnesia、DirtyClone、epoll 竞态条件 PE 漏洞、Bad Epoll、GhostLock、FUSE 文件系统驱动缺陷。其中许多漏洞已存在多年，但 AI 的发展加快了这些漏洞被发现的速度。

我们之前的运行时使用 Linux 容器，它们共享主机内核。该内核中一个可触达的漏洞就可能让攻击者逃逸容器并访问主机上的其他工作负载、凭据或网络端点。并非每个内核 CVE 在每种配置下都可利用，但共享内核使得成功逃逸的后果严重得多。

使用 microVM 时，攻陷沙箱的客户机内核本身并不会攻陷主机内核。攻击者仍然必须跨越虚拟化边界。

为每个沙箱提供自己的内核还让我们能够支持 Docker 等工具，这些工具所需的权限我们无法在共享内核运行时中安全暴露。

最小化权限与内核攻击面

在我们的新设计中，一个沙箱由一个 microVM 及其内部运行的最小化 runc 容器组成。除开发环境外，支持服务负责处理 PostgreSQL、git 备份和安全请求代理。我们曾考虑为每个组件使用一个 microVM，但认为额外开销不值得，且并未实质改变租户隔离模型。容器仍然在 microVM 客户机内提供独立的命名空间、资源限制和特定角色的权限。

虚拟化边界并不能让其中的每个进程都获得同等信任。我们按角色配置命名空间、seccomp、设备访问和权限能力，因此用户进程不会继承监控代理的权限。Docker 在客户机内获得所需的额外权限，且永远不会触及物理主机。

VMM 本身以无特权身份运行，不具备任何 Linux 权限能力。

更小的内核，更小的攻击面

我们的客户机内核基于 tinyconfig 构建，而非标准发行版配置。我们剔除了 microVM 不需要的硬件子系统，包括蓝牙、无线、USB 和显示驱动。你的编码代理显然不需要 Nintendo Switch 手柄。必需的驱动被内置，客户机初始化时会禁用模块加载。鉴于今年内核 CVE 披露速度不断加快，我们的最小化内核构建完全避开了大多数受影响的代码区域，这让我们感到安心。

每日自动化让我们的内核构建持续向前推进，基于 Replit 构建的自主代理负责处理更新工作流，这是我们“自动驾驶公司”的一部分。

我们审计了 2026 年 6 月 1 日至 11 月 4 日期间发布的 6,211 个 Linux-CNA CVE，数据来自 CVEProject 和 kernel.org 的记录。我们规避了其中 5,969 个（96.1%），方式是及时合入上游修复或排除受影响代码。其中 4,375 个修复（70.4%）在披露之前就已合入，另有 676 个（10.9%）CVE 通过配置被排除。其中至少有 15 个被 Linux CNA 或 Red Hat 明确描述为可启用或可能启用 LPE。

最近的一个例子是 CVE-2026-98432，这是 Anthropic 演示的 Linux TCP 漏洞，可让远程攻击者获得 root 访问权限。我们在 10 月 12 日就合入了修复后的内核，早于该 CVE 发布，也早于 Anthropic 描述其利用方式两周多。

永不信任工作负载

eBPF 程序观察每个沙箱内的进程执行、文件访问和网络活动。Linux 安全模块（LSM）提供在内核边界强制执行限制的钩子。这些机制共同为我们提供了详细的运行时可见性，以及检测和阻止特定禁止操作的手段。

判定滥用和入侵的系统同样是自动化的。运行时遥测数据输入自主代理，持续演进我们已知的检测规则和禁止模式。我们后续会撰写更多关于 Replit 如何自动化威胁研究的内容，你可以把它想象成一台始终在线的安全摄像头，一旦识别出有害行为就立即阻止，并且每发现新情况都会变得更聪明。

每个沙箱都有一个安全监控器，同时运行在 microVM 的主机侧和客户机侧。该组件受监督，能够在崩溃或被篡改后自愈并重启，或在推出新版本时重启。为保证始终在线的安全性，我们优化了持续交付流水线，使安全组件在变更合入后不到 15 分钟内即可在所有生产环境运行的沙箱中更新和热重载。由于我们在内核层面使用 eBPF 和 LSM 运行，这也使我们能够快速进行临时修复，以应对零日内核漏洞，甚至早于主线提供修复。

当 eMudhra 的中间 CA 密钥被泄露时，证书信任成为整个行业亟待解决的安全问题。我们的沙箱测试框架自动将更新后的 CA 证书包注入所有正在运行的沙箱，使我们能够通过现有的控制路径做出响应，而不是要求客户逐个更新每个环境。

隔离网络

每个沙箱都可以使用相同的私有 IP 地址，因为它拥有自己的网络命名空间和路由表。Linux 虚拟路由转发（VRF）将这些重叠的网络隔离开来，而连接跟踪在流量离开和返回时保留路由身份。基线防火墙规则限制对云元数据和基础设施地址范围的访问，并在需要私有连接的地方提供明确的允许规则。

对于具有出口策略的沙箱，强制执行在客户机之外进行。主机侧代理检查 TLS 握手主机名而不解密应用负载，过滤 DNS，并拒绝允许路径之外的流量。客户机无法禁用这些主机侧规则。私有端点隧道同样为工作负载提供本地套接字，同时将其凭据保留在主机上。

虚拟网卡速率限制器也在客户机之外强制执行配置的入站和出站带宽限制，允许有界突发同时限制持续流量。更改客户机的网络配置不会移除 VMM 的限制器。带宽控制用于遏制资源滥用，它与决定允许哪些目的地是分开的。

保护凭据和供应链

我们的托管连接器使用凭据代理将请求转发到上游服务，例如 GitHub 和 Google Docs。代理在执行授权后附加上游凭据，因此工作负载可以使用该服务而不会收到其账户 API 密钥。它会移除调用方提供的身份验证标头，并剥离敏感的响应标头和尾部。

npm 和 pip 等包管理器也通过注册表防火墙路由其请求。任何安装已知恶意依赖项和包的尝试都会被立即阻止，从而首先防止我们的用户及其代理将有害内容带入其沙箱。我们的编码代理了解这一点，并自主为用户替换或移除被阻止的依赖项，以提高供应链安全性。

无底存储

每个沙箱的文件系统位于我们的远程块存储服务上，该服务按需获取数据。启动大型工作区并不意味着要先下载其整个文件系统。

为了与我们的自定义块设备服务集成，我们编写了一个 vhost-user virtio-blk 后端。此进程与 Cloud Hypervisor 一起运行，处理客户机的块 I/O，使我们的远程磁盘显示为常规虚拟块设备。它还摆脱了在一个主机内核中管理数百个网络块设备的做法，这种做法过去因意外的死锁和节点故障给我们带来了很多痛苦。这也是我们在 Claude Sonnet 4 时代最早完全由 AI 编写的组件之一，经过五到七次迭代才整合为当前在生产中运行的同步/异步混合模型，该模型在保持低延迟的同时最大化了吞吐量。

写时复制存储也让 fork 变得廉价。新磁盘可以引用现有块，并在写入时产生分歧。我们还实现了优雅的存储重连，这样滚动发布可以排空未完成的 I/O、持久化磁盘并重新连接，而无需重启客户机。

保持沙箱快速

要启动一个沙箱，我们需要启动 Linux 内核、拉取镜像、启动容器并启动客户机代理。我们的最小客户机内核启动很快，而热池让我们可以提前完成大部分剩余工作。获取一个沙箱大约需要 500 毫秒，包括挂载客户的卷并并行配置支持服务。这是磁盘已挂载时的交接时间，因为启动一个空 VM 要快得多。

同时为数万个沙箱做到这一点，远不止热池那么简单。在第 2 部分中，我们将介绍如何在 Kubernetes 上编排这一切。

接下来是什么

该系统已在生产环境中健康运行了几个月。我们在没有任何中断的情况下迁移了数亿个项目，并实现了更快的启动时间、更强的隔离和演进的安全原语。我们将继续投资于安全，并分享更多关于我们 Kubernetes 编排和自动化安全研究背后的选择。与此同时，去 Replit 上构建一些东西吧。

致谢

由 Connor Brewster、Jason Dellaluce、Adnan Abdulhussein、Luis Hector Chavez 以及 Replit 计算平台团队的其他成员撰写。如果你想与我们一起从事前沿基础设施工作，我们的团队正在招聘。