预热沙箱池：当每个智能体任务都拥有专属机器时的基础设施经济学

如果你在任何真实规模下运行编程智能体 (coding agents)，你就拥有一支临时虚拟机舰队。你可能并没有主动申请这样做。但在你决定（且正确地决定）不信任的、由模型生成的代码绝不应该在应用程序的信任边界内执行的那一刻，这一切就发生了。每个任务都有自己的沙箱，每个沙箱都是一个微型虚拟机 (microVM) 或硬化容器。突然间，那个自以为在构建“智能体产品”的平台团队，实际上正在运营一些看起来非常像微型 AWS Lambda 的东西：池预热 (pool warming)、快照流水线、装箱调度器 (bin-packing schedulers)，以及一个针对无人认领环境的清理进程 (reaper process)。

陷阱在于假设你的容器编排直觉可以无缝迁移。有些确实可以。但 Kubernetes 是为了调度长周期的、同质化的服务而设计的，而智能体沙箱恰恰相反：生命周期短、极度异构，且创建速度之快让部署滚动更新 (rollout) 看起来像是在悠闲散步。那些挣扎的团队往往将沙箱基础设施仅仅视为“步骤更多的容器”。有趣的工程挑战——以及几乎所有的成本——都集中在四个问题上：冷启动、文件系统状态、装箱密度和弃置。

为什么每个任务都拥有专属机器

“按任务隔离”模型之所以胜出，原因很简单：智能体是一个连接到执行循环的不受信任的代码生成器。OpenAI 的 Codex 在其专属云容器中运行每个任务，预装好代码库，任务完成后即销毁，且默认关闭网络访问。Anthropic 的云服务以及所有主流沙箱供应商——E2B、Daytona、Modal、Fly.io——都趋向于同一种形态：会话作用域、隔离、可丢弃。

共享环境会同时在两个方向上失败。安全性：模型生成的代码可能会执行 rm -rf、窃取凭据或破坏后续任务依赖的状态。正确性：两个智能体在共享环境中安装冲突的依赖版本，会产生无人能复现的故障。按任务隔离从结构上消除了这两类问题，这也是为什么现在没有严肃的开发者再对此表示异议。

但这将成本转移到了其他地方。一个每天处理 10,000 个智能体任务的服务，现在每天需要启动 10,000 台机器。这支舰队的单位经济效益——机器启动速度、每台机器闲置时的内存占用、装箱密度——都变成了产品层面的关注点。一个需要 30 秒才能完成配置的沙箱，是对每个任务征收的 30 秒“税收”，而那些为单个工具调用就启动沙箱的智能体循环，在每个会话中要支付几十次这种开销。

冷启动：资源池是对流量的赌注

原始数据解释了整个预热池行业的兴起。Firecracker microVM 的冷启动——包括最小内核、用户空间初始化、网络设置——中位数大约在 110–200ms 左右，p99 超过 300ms。这还没算上克隆代码库、安装依赖或启动语言服务器的时间。一个从零开始构建的、现实中的“冷”智能体环境需要数十秒。而从内存快照恢复相同的环境，虚拟机本身只需要个位数的毫秒；Lambda SnapStart 的生产环境数据在 p50 左右约为 3ms。供应商提供的端到端数据如 Daytona 从预热池创建沙箱不到 90ms，以及 Fly.io 对其智能体专用机器提供的约 300ms 检查点/恢复 (checkpoint/restore)。

这就是“完全冷启动”和“从快照恢复”之间三个数量级的差距，而预热池就是你购买“极速体验”的方式。你预先启动 N 个环境到某个检查点——操作系统就绪、运行时已安装、常用依赖存在——然后要么让它们保持运行（支付闲置内存费用），要么创建快照并停放它们（支付存储费用和恢复延迟代价）。

规模估算问题才是最有趣的地方，因为这是在对你无法控制的流量下注：

• 规模太小：突发流量会掉进冷启动路径。冷启动延迟在并发下会产生叠加效应——一堆任务每个都在等待 30 秒，这就不再是延迟问题，而是宕机事故。
• 规模太大：你将全天候为闲置内存付费。与 CPU 不同，内存无法优雅地超卖；一个预热但闲置的资源池几乎是纯粹的成本。
• 太通用：预热起不到作用。一个预置的 Ubuntu 镜像能帮你省下 200ms 的内核启动时间，但省不掉主导实际启动时间的 40 秒 npm install。

最后一点是很多团队容易忽略的。有价值的快照不是“一个已启动的虚拟机”，而是“一个已启动且已经安装了该仓库依赖树的虚拟机”。这意味着你的预热池不是一个池，而是一个以环境指纹为键的缓存，这带来了所有缓存管理难题：当 lockfile 更改时的失效机制、基于流行度的保留策略，以及大量永远不值得预热的长尾环境。挂起/恢复 (Suspend/resume) 计费模型——即停放的机器按存储而非计算计费，如 Fly 的挂起机器——之所以存在，正是为了让一个巨大的、大部分闲置的缓存变得经济适用。

文件系统状态：写时复制 (Copy-on-Write) 是核心所在

第二个成本中心是将工作树导入沙箱。朴素的方法是：针对每个任务都执行 git clone 加上依赖安装。对于大型单体仓库 (monorepo) 来说，这需要花费数分钟，而且这是数分钟的无效工作，因为每天 10,000 个任务生成的几乎是完全相同的文件系统。

加载中…