过去十年，云上执行单元的默认答案是容器。容器启动快、密度高、镜像生态成熟，但当它被放进多租户 Serverless 平台或面向 AI Agent 的代码执行环境时，共享内核带来的隔离风险就被放大：一次内核漏洞或逃逸，就可能跨越租户边界。

于是，微虚拟机（MicroVM）这条曾属边缘的技术路线，正从“安全沙箱”变成云上的通用执行底座。

为什么容器不再够用

容器的隔离建立在 namespace 与 cgroup 之上，安全边界就是操作系统内核本身。对可信的内部负载，这种取舍并无问题；但在 FaaS、在线判题、多租户数据处理，尤其是让大模型生成的代码直接运行这类场景里，用户代码本身不可信，共享内核便不可接受。

传统虚拟机隔离彻底，但每个实例都要启动完整内核与设备模型，启动以秒计、内存开销以百兆计，撑不起每秒数千次的弹性需求。微虚拟机的思路是折中：仍给每个负载一套独立内核，却把设备模型裁到最小，只保留内存、时钟、串口等必要部件，其余交给宿主机。

几条主要技术路线

  • Firecracker：为 FaaS 与沙箱设计，约 125 毫秒完成启动，单机可承载数千实例。
  • Cloud Hypervisor：Rust 实现，更接近通用虚拟化，支持热插拔与较完整的设备模型。
  • Kata Containers：以 OCI 兼容方式把容器放进虚拟机，兼顾 K8s 体验与强隔离。
  • gVisor 等用户态内核：不依赖虚拟化，靠拦截系统调用实现隔离，是另一条路径。

衡量这类方案的核心指标已经趋同：冷启动延迟、单实例内存底噪、单节点密度，以及是否兼容 OCI 镜像与 K8s 调度。

AI Agent 带来的新需求

2024 年以来，让大模型生成并执行代码成为刚需。代码解释器、浏览器自动化、数据分析 Agent，都需要用完即弃且互不污染的执行环境，并要在几百毫秒内就绪，这几乎是微虚拟机的量身定制场景。

同时，Agent 调用呈突发式、长尾明显：白天高峰可能数万并发，夜间骤降。微虚拟机的小内存底噪与快速回收，直接决定单位任务成本的量级。

落地仍要面对的现实

微虚拟机并非没有代价。快照恢复要处理熵源、时钟与网络连接重建；镜像分发要解决数千节点同时拉取的热点；可观测性与调试工具链也比容器薄弱。宿主机内核安全更新与 CPU 侧信道缓解还会带来性能损耗，需要在隔离强度与开销之间持续调参。

调度同样关键：实例生命周期短，如何做出低抖动的放置决策，如何与既有服务网格、密钥管理、弹性伸缩体系对接，都是必须补齐的功课。

结语

从安全沙箱到通用执行底座，微虚拟机的角色变化，本质是云上隔离被重新定价：当负载来源越来越不可信，隔离不再是可选项，而是默认配置。容器仍会长期存在，但在多租户 FaaS 与 AI Agent 执行场景中，微虚拟机正在成为新的默认答案。