Replit 重做 Agent 沙箱：microVM 正在成为 AI 编程的安全底座

Replit 在 11 月 4 日披露了一次几乎没有用户感知、但足以影响 AI 编程产品竞争方向的底层重构：它已经将 Sandbox 引擎从共享宿主机内核的容器架构，迁移到基于 KVM 和 Cloud Hypervisor 的 microVM 架构。

这次迁移覆盖了数亿个项目，Replit 称整个过程没有发生数据丢失，新的系统已在生产环境稳定运行数月。每个 Sandbox 现在拥有独立的 Linux 客户机内核，外层由硬件虚拟化隔开，内层仍用 runc 容器区分开发环境、监控服务和其他组件。(frontier.replit.com)

**microVM 是一种裁掉大量传统硬件模拟、专门运行云工作负载的轻量级虚拟机。**它保留虚拟机最重要的安全特征——独立内核和硬件虚拟化边界，同时尽可能把启动速度、内存开销和管理方式做得接近容器。

这不是一次普通的云基础设施升级。它意味着 AI 编程 Agent 的竞争，正在从“模型能不能写出代码”，进入“平台敢不敢让模型长时间运行代码”的阶段。

为什么共享内核不再够用

**传统容器的主要问题不是隔离能力为零，而是所有租户仍然共享同一个宿主机内核。**容器可以通过 namespace、cgroup、seccomp 和 capabilities 限制进程，但一旦攻击者利用可达的内核漏洞完成逃逸，影响范围可能从单个容器扩大到宿主机上的其他工作负载、凭证和内部网络。

Replit 的旧 Sandbox 正是沿着这条路线演进的：最初是在 Google Compute Engine 虚拟机上运行 Docker，后来逐步加入持久化工作区、公开访问地址、Nix 软件包缓存、区域集群和可分叉存储。这套架构适合人类在浏览器中写代码，却不是为能够自主安装依赖、执行终端命令、修改配置并访问外部服务的 Agent 设计的。(frontier.replit.com)

**AI Agent 放大了代码执行环境中的不确定性。**人类开发者通常知道自己准备执行什么命令，而 Agent 可能根据网页内容、仓库文件、第三方依赖甚至恶意提示，临时生成下一步操作。

一个编程 Agent 在完成“修复登录问题”时，可能安装新的 npm 包、启动 Docker、读取环境变量、访问 GitHub、修改数据库迁移文件，再运行端到端测试。这里任何一个环节被污染，都可能让一次普通开发任务变成供应链攻击或凭证泄露事件。

**microVM 的价值是把“攻破工作负载”和“攻破物理宿主机”变成两道不同的题。**即使攻击者拿下 Sandbox 内的客户机内核，仍然需要继续跨越 KVM 和虚拟机监控器构成的硬件虚拟化边界，才能触及宿主机。

这并不代表 microVM 无法被逃逸，但它显著缩小了单个漏洞的爆炸半径。Kata Containers 对同类架构的定义也很直接：容器运行在拥有独立客户机内核的轻量级虚拟机内，硬件虚拟化成为传统容器隔离之外的第二道防线。(github.com)

Replit 没选 Firecracker

**Replit 选择的是 Cloud Hypervisor，而不是更常被 Agent 沙箱厂商提到的 Firecracker。**两者都使用 KVM，也都大量采用 Rust 生态中的 rust-vmm 组件，但产品取向并不完全相同。

Firecracker 是为无服务器函数和容器工作负载设计的极简虚拟机监控器，强调有限的虚拟设备、较低内存开销和快速启动。其官方规格显示，在指定测试环境下，从收到启动指令到 Linux 用户空间的 /sbin/init 启动不超过 125 毫秒，VMM 线程内存开销不超过 5 MiB。(github.com)

**Cloud Hypervisor 更适合 Replit 的原因，是它提供了更完整的云虚拟机生命周期能力。**Replit 特别看重 virtiofs、透明大页、设备热插拔、内存快照、实时迁移和嵌套虚拟化，并对 Cloud Hypervisor 做了补丁，以改善快照在裸金属和虚拟化环境之间的可移植性。(frontier.replit.com)

设备热插拔和内存快照对在线开发平台尤其重要。Replit 可以先在 warm pool 中准备已经启动的 microVM，任务到来后再挂载用户磁盘，而不是为每次请求从头启动内核、加载镜像并恢复整个工作区。

嵌套虚拟化则解决了一个越来越现实的需求：用户和 Agent 可能希望在 Sandbox 内继续启动 Docker 或其他虚拟化工作负载。旧架构很难安全地把这类权限交给共享内核容器，而独立客户机内核可以把高权限操作限制在 microVM 内部。

| 方案 | 内核边界 | 启动与开销 | 兼容性 | 更适合的场景 | |---|---|---|---|---| | 普通 runc 容器 | 与宿主机共享内核 | 最低 | Linux 工具兼容性高 | 可信服务、内部任务 | | gVisor | 用户态实现 Linux 接口，减少宿主机内核暴露 | 通常低于完整 VM | 部分系统调用存在兼容成本 | 短任务、不可信代码执行 | | Firecracker microVM | 独立客户机内核与 KVM 边界 | 官方规格为启动不超过 125ms、VMM 开销不超过 5MiB | 设备模型极简 | Serverless、短生命周期沙箱 | | Cloud Hypervisor microVM | 独立客户机内核与 KVM 边界 | 依赖快照、预热池和具体配置 | 支持热插拔、快照、迁移和嵌套虚拟化 | 持久工作区、复杂 Agent 环境 | | Replit 新 Sandbox | Cloud Hypervisor 外层加 microVM，内部继续使用容器 | 完整环境交付约 500ms | 支持 Docker、远程磁盘和长期工作区 | AI 编程、并行 Agent、企业工作流 |

表格中的 500 毫秒并不是“空虚拟机启动时间”。Replit 的统计口径包括获取 Sandbox、挂载用户卷，并行配置 PostgreSQL、Git 备份和代理服务；单纯启动空 microVM 所需时间更短。(frontier.replit.com)

独立内核只是第一层

**Replit 这次升级最值得关注的部分，不是“每个用户有一台虚拟机”，而是它没有把虚拟机当成万能安全盒。**新的 Sandbox 仍然采用分层隔离：microVM 负责租户之间的硬边界，内部容器负责进程角色、资源限制和权限拆分。

一个 Sandbox 内的用户进程、监控程序、Docker 服务和支持组件并不拥有相同权限。Replit 根据角色配置 namespace、seccomp、设备访问和 Linux capabilities；运行 Cloud Hypervisor 的 VMM 进程本身则使用无 Linux capabilities 的非特权身份。(frontier.replit.com)

**这种“VM 外墙加容器内隔间”的设计，比每个组件都启动一台 microVM 更务实。**后者理论上可以增加组件级隔离，但也会显著增加内存、调度和启动成本，而且不一定改善最核心的跨租户安全边界。

Replit 的做法更像一栋独立办公楼：microVM 保证不同公司的楼宇不共用承重结构，内部容器再把机房、办公室和仓库分开。每个房间仍然需要门禁，但其中一扇门失效，不等于能直接进入旁边公司的楼。

把 Linux 内核砍到最小

**Replit 使用从 Linux tinyconfig 出发构建的极简客户机内核，以减少不必要的攻击面。**蓝牙、无线网络、USB、显示驱动等 microVM 不需要的子系统被直接移除，必要驱动则静态编译进内核，初始化后禁止继续加载内核模块。(frontier.replit.com)

这比“发现漏洞后尽快打补丁”更进一步，因为没有编译进内核的代码无法被攻击者调用。一个只负责跑编译器、数据库和测试工具的 Agent 环境，确实没有理由支持游戏手柄、无线网卡或桌面显卡驱动。

**Replit 给出了一组值得注意、但仍需视为厂商自报的数据。**它审计了 2026 年 6 月 1 日至 11 月 4 日公布的 6211 个 Linux CNA CVE，其中 5969 个、即 96.1%，通过及时合入上游修复或排除受影响代码而规避；4375 个修复在漏洞披露前已经进入其内核，另有 676 个 CVE 因配置中未启用相关功能而不受影响。(frontier.replit.com)

这组数字的意义不是证明 Replit 的内核“安全了 96.1%”，因为 CVE 数量不能直接等同于实际风险。它真正说明的是，极简内核让安全团队可以把大量无关代码从补丁队列中移除，把精力集中在 Sandbox 确实会执行的代码路径上。

网络控制必须放在 Sandbox 外

**Agent 沙箱最危险的能力往往不是执行命令，而是带着身份访问网络。**一个完全隔离但可以任意访问云元数据地址、企业内网和外部 API 的环境，仍然可能成为数据外泄或横向移动的起点。

Replit 因此把网络出口策略放在客户机外部执行。宿主机侧代理会检查 TLS 握手中的目标主机名、过滤 DNS，并拒绝不符合策略的流量；因为规则位于 microVM 外，Sandbox 内即使取得 root 权限，也不能通过修改客户机防火墙来关闭这些限制。(frontier.replit.com)

**出口限速与目的地授权也被拆成了两套机制。**虚拟网卡限速器在客户机外约束持续带宽和突发流量，而网络策略决定 Agent 究竟可以访问哪些地址。前者防止资源滥用，后者限制权限边界，两者不能互相替代。

这种设计比简单的“允许联网”开关更适合 Agent。开发任务可能需要访问 GitHub 和 npm，却没有理由访问云厂商元数据服务；数据分析任务可能需要访问公司数据库，却不应该将结果上传到任意网盘。

凭证不再进入工作负载

凭证代理是 Replit 新架构中比 microVM 更关键的一层，因为隔离环境一旦拿到长期凭证，围墙再厚也只能限制计算，不能限制授权。

Replit 的托管连接器通过 credential broker 转发对 GitHub、Google Docs 等服务的请求。Sandbox 发起经过授权的调用后，代理才在外部附加真实凭证，同时移除工作负载自行提交的认证头，并过滤响应中的敏感头信息。(frontier.replit.com)

这相当于把公司门卡留在保安室。Agent 可以提交“我要读取这个仓库”的请求，但不会直接拿到一张可以复制、保存并在任务结束后继续使用的长期门卡。

**npm 和 pip 流量也经过软件包注册表防火墙。**Replit 称系统会阻止已知恶意依赖进入 Sandbox，其编程 Agent 还会尝试替换或删除被拦截的软件包。这个机制不能消灭依赖投毒，但至少把供应链风险从模型的判断题，变成平台可统一更新的策略。(frontier.replit.com)

远程存储解决持久化难题

**microVM 要成为开发环境，必须同时处理“计算实例可以随时销毁”和“用户文件必须长期存在”的矛盾。**Replit 的文件系统因此不直接绑定在单台 microVM 上，而是放在远程块存储服务中，并按需读取数据。

Replit 为此实现了一个 vhost-user virtio-blk 后端，使远程磁盘在客户机里表现为普通虚拟块设备。写时复制让新分支可以引用已有数据块，只有发生修改时才产生新的存储占用，因此适合 Agent 并行尝试多个方案。(frontier.replit.com)

这类存储能力会直接影响 Agent 的产品体验。一个模型可以复制当前环境，分别尝试升级依赖、重构代码和回滚版本，再用测试结果选择最佳分支，而不必完整复制几十 GB 的工作区。

有意思的是，Replit 称这套块设备后端是其较早由 AI 完整编写的生产组件之一，经历了 5 至 7 轮迭代，最终采用同步与异步混合模型，以平衡吞吐量和延迟。(frontier.replit.com)

microVM 不是可靠性的万能药

**microVM 解决的是越权和跨租户风险，不会自动阻止 Agent 删除自己工作区里的文件。**如果用户明确授予 Agent 修改仓库和数据库的权限，那么模型执行错误命令、写坏配置或做出错误业务判断，仍然属于“权限范围内的失败”。

这一区分非常重要。沙箱负责限制 Agent 能接触什么，测试和事务系统负责判断 Agent 做得对不对，版本控制与快照负责在它做错后恢复。

真正可靠的 AI 编程平台至少需要四类护栏同时工作。

• microVM 和客户机内核负责跨租户隔离；
• 网络与凭证代理负责限制外部权限；
• Git、写时复制存储和数据库分支负责回滚；
• 测试、审计日志和人工审批负责判断修改是否应该进入生产环境。

Replit 还在每个 Sandbox 中部署跨越宿主机侧和客户机侧的安全监控组件，通过 eBPF 观察进程执行、文件访问和网络活动，并利用 Linux Security Modules 执行限制。该组件可以在崩溃或遭到篡改后自恢复，安全规则从合并到全量热更新的目标时间低于 15 分钟。(frontier.replit.com)

Agent 基础设施的竞争点变了

**Replit 的重构表明，microVM 正从高安全等级的可选配置，转向云端 AI 编程产品的默认执行边界。**模型能力越强、任务持续时间越长、能够调用的工具越多，平台就越不能假设工作负载会遵守约定。

gVisor、Kata Containers、Firecracker 和 Cloud Hypervisor 代表了不同的隔离路线，但行业正在形成一个共同判断：普通容器适合运行已知服务，却很难单独承担多租户自主 Agent 的最终安全边界。gVisor 官方甚至直接强调“容器不是沙箱”，因为共享内核意味着一个漏洞仍可能造成逃逸。(github.com)

**Replit 的优势是它不只在卖一个临时运行代码的 Sandbox，而是在迁移已有的大规模开发平台。**数亿个项目、持久磁盘、数据库、Git 备份、公开预览、Docker 和企业连接器，使这次工程难度远高于从零搭建一个短生命周期代码执行服务。

它的代价也很清楚。microVM 会增加内存占用、调度复杂度、内核维护成本和宿主机虚拟化要求，预热池还会消耗没有直接服务用户请求的闲置资源。Replit 目前公布了约 500 毫秒的完整环境获取时间，却没有披露单 Sandbox 成本、预热池命中率和高并发下的尾延迟。

**最终决定这套架构好不好用的，不是架构图上的隔离层数，而是规模化运行时的成本和故障率。**Replit 下一篇文章计划解释如何在 Kubernetes 上同时编排数万台 microVM，这部分数据会比“我们使用了 microVM”本身更值得看。(frontier.replit.com)

OpenAI Hub 观点

**Replit 这次重构方向正确，而且比单纯更换虚拟化技术更完整。**它把独立内核、宿主机侧网络策略、凭证代理、软件包防火墙、远程写时复制存储和运行时监控放进同一套控制面，开始形成真正面向自主 Agent 的执行基础设施。

但 microVM 不应该被包装成“Agent 不会闯祸”的答案。它只能让事故尽量停留在被授权的空间里，无法替代最小权限、测试验证、可回滚存储和高风险操作审批。

**AI 编程 Agent 的下一阶段竞争，不会只看模型一次生成多少行代码，而会看它能否在隔离环境中安全工作几十分钟甚至数小时。**当产品开始允许 Agent 并行运行、访问企业系统、安装任意依赖并启动自己的容器时，Sandbox 就不再是一项后台功能，而是与模型本身同等重要的核心产品。

Replit 把这张底牌翻了出来，也等于提高了行业门槛：以后再说“我们的 Agent 可以自主执行代码”，用户会继续追问——它运行在哪里、共享谁的内核、网络出口由谁控制、真实凭证有没有进入环境，以及出错后能不能完整回滚。

参考来源

• Cloud Hypervisor：Replit 新 Sandbox 采用的虚拟机监控器，提供热插拔、快照、迁移和嵌套虚拟化能力。
• Firecracker：AWS 发起的轻量级 microVM 项目，可用于对比极简 VMM 的启动速度和资源开销。
• Kata Containers：将容器工作负载运行在轻量级虚拟机中的开源运行时，可用于理解“容器内体验、虚拟机级隔离”的架构。
• gVisor：Google 开源的用户态应用内核，通过减少工作负载直接接触宿主机内核来增强容器隔离。