什么是 MicroVM、Runtime 与 Guest
一句话定义
在 CubeSandbox 中，一个 Sandbox 能够真正跑起来，至少依赖三层运行时抽象：
- MicroVM：隔离载体
- Runtime / Shim：平台与实例之间的运行时桥梁
- Guest：实例内部看到的操作系统环境
这三者共同定义了 CubeSandbox 的执行模型。
为什么必须把三者拆开理解
很多人第一次接触 CubeSandbox 时，会下意识地把它理解成：
- “就是一个更快的 VM”
- 或者“其实还是容器，只不过外面套了层 VM”
这两种理解都不够准确，原因就在于它们把不同抽象层混在了一起。
CubeSandbox 的关键能力恰恰来自 把接口层、隔离层、Guest 环境层拆开设计：
- 接口层要兼容现代容器 / SDK 生态
- 隔离层要提供强边界
- Guest 层要像真实开发环境一样可运行
这三层合在一起，才形成 CubeSandbox 的产品特征。
什么是 MicroVM
定义
MicroVM 是一种面向轻量化工作负载的微型虚拟机形态。
它保留了虚拟化带来的强隔离边界，但尽量压缩设备模型、启动链路和资源开销，使其比传统通用虚拟机更适合高并发、短生命周期、平台型场景。
在 CubeSandbox 里的角色
在 CubeSandbox 中，MicroVM 的核心职责只有一个：
为每个 Sandbox 提供独立 Guest 内核和独立执行边界。
它解决的是“安全与隔离”问题，而不是“如何定义环境”或“如何接入容器生态”。
为什么不是容器替代词
容器强调的是进程级封装与共享宿主机内核。
MicroVM 强调的是：
- 独立 Guest 内核
- 硬件虚拟化边界
- 更强的故障与攻击面隔离
所以在 CubeSandbox 里，MicroVM 是“安全基础设施”，不是“更重一点的容器”。
什么是 Runtime / Shim
定义
Runtime / Shim 是连接平台控制逻辑与底层虚拟化实例的桥梁。
它的作用不是“提供隔离”，而是“把一个隔离实例纳入标准化运行时控制模型”。
在 CubeSandbox 里的意义
CubeSandbox 不是从零发明一整套运行时接口，而是尽量接入现有容器运行时生态。
这时就需要 Runtime / Shim 去承担几个关键任务：
- 接收来自上层的创建、删除、状态查询等操作
- 把这些操作转换成底层实例管理动作
- 管理 Guest 启动资产、socket、生命周期事件
- 为工具链与节点侧管理提供统一入口
换句话说，Runtime / Shim 是“平台控制语言”和“虚拟化执行语言”之间的翻译层。
为什么这一层很关键
如果没有 Runtime / Shim，CubeSandbox 就只能作为一个孤立虚拟化系统存在； 如果只有 Runtime / Shim 而没有微虚拟机，它又会退化成普通共享内核容器模型。
因此这层的意义是：
让强隔离实例可以被现代平台像管理容器一样管理。
这正是 CubeSandbox 非常独特的一点。
什么是 Guest
定义
Guest 指的是 Sandbox 内部看到的操作系统环境，也就是实例内部“认为自己所处的机器世界”。
它通常包括：
- Guest 内核
- 用户态文件系统
- init / service / shell / 运行时环境
- 进程、网络设备、文件、端口等实例内部对象
为什么 Guest 不是“虚拟机内部所有东西”的简单别名
在概念上，Guest 关注的是 实例内部视角。
用户执行代码时接触到的是 Guest：
- 看到的文件系统是 Guest 视角
- 执行的进程在 Guest 中运行
- 监听的端口属于 Guest 内服务
- 读取到的网络设备与 IP 也是 Guest 内部视角
所以 Guest 是“用户工作负载所在世界”，而不是平台侧控制对象本身。
三者之间的关系
可以用一句最简洁的话概括：
- MicroVM 提供边界
- Runtime / Shim 提供控制
- Guest 提供环境
关系一：MicroVM 承载 Guest
Guest 并不是悬空存在的，它运行在 MicroVM 提供的隔离上下文中。
关系二：Runtime / Shim 控制 MicroVM 生命周期
Runtime / Shim 不直接等于 Guest，也不等于 MicroVM；它负责把平台动作落实到这些底层实体上。
关系三：用户主要感知 Guest，平台主要控制 Runtime 对象
用户以为自己在“一个环境里工作”； 平台实际上在管理的是一组运行时对象、socket、虚拟化状态和节点资源。
这两个视角通过 Runtime / Shim 被接到一起。
为什么 CubeSandbox 不是“容器外面套一层虚机”
这是一个常见但危险的误解。
如果只是“容器外面套层 VM”，通常意味着：
- 虚拟化只是附加包装
- 运行时模型仍然以容器为主
- Guest 环境只是附属壳层
而 CubeSandbox 的实际模型更像是：
- 用容器生态的接口与平台管理习惯来组织对象
- 用微虚拟机作为真正隔离基础
- 用 Guest 环境作为工作负载实际运行空间
- 用模板和快照把性能做上去
所以它不是“容器 + VM 壳”，而是 运行时接口、虚拟化隔离与模板快照复用三者重新组合后的系统。
这三层各自解决什么问题
| 概念 | 主要解决的问题 | 不负责什么 |
|---|---|---|
| MicroVM | 强隔离、独立内核、执行边界 | 不定义模板，也不决定用户 API |
| Runtime / Shim | 生命周期控制、接口适配、资产组织 | 不直接提供安全边界 |
| Guest | 提供实例内部运行环境与用户视角 | 不承担控制面编排职责 |
理解这张表非常重要，因为很多架构讨论的混乱都来自“某一层被错误期待承担另一层职责”。
运行路径视角：一次创建请求如何穿过这三层
你可以把一次 Sandbox 创建大致理解为如下过程：
- 控制面决定要创建一个 Sandbox
- 节点侧调用 Runtime / Shim 入口
- Runtime / Shim 准备运行时资产、socket、配置
- 底层拉起或恢复 MicroVM
- Guest 环境在该 MicroVM 中变成可运行状态
- 用户请求最终落到 Guest 内部服务或进程
这条链路中：
- 控制面主要认识“对象和状态”
- Runtime / Shim 主要认识“运行时动作”
- MicroVM 主要承担“边界与承载”
- Guest 主要承载“工作负载与服务”
为什么这对 Agent 场景特别重要
AI Agent 场景往往同时要求：
- 执行不可信代码
- 快速创建环境
- 拥有较完整的用户态能力
- 与 SDK 和已有业务模型兼容
这四件事如果单靠容器，很难同时极致满足； 如果只靠传统 VM，又很难达到需要的启动性能与平台化管理体验。
CubeSandbox 通过这三层抽象的配合，才把这几种诉求拼在了一起。
常见误解
误解一：Guest 就是 rootfs
不对。
rootfs 只是 Guest 环境的文件基础之一。Guest 还包括内核、进程、运行时状态和实例视角。
误解二：Runtime 只是一个命令行工具
不对。
命令行只是入口形态之一。更重要的是 Runtime / Shim 背后承载的生命周期管理与平台接口角色。
误解三：只要有 MicroVM，系统就天然高性能
不对。
MicroVM 主要解决隔离问题。CubeSandbox 的高性能还依赖模板、快照、资源组织、网络和节点调度设计。
你应该记住的核心判断
如果只记一句话，请记住：
CubeSandbox 不是单纯在“跑虚拟机”，而是在通过 Runtime / Shim 管理一批以 MicroVM 为隔离边界、以 Guest 为用户环境的 Sandbox 实例。
下一步
理解了三层运行时模型后，下一个问题自然是：
为什么这些 Guest 环境可以这么快地被交付出来？
答案就在状态复用机制里： 什么是 Snapshot、冷启动与热启动。