什么是 Template
一句话定义
在 CubeSandbox 中，Template 是创建 Sandbox 的标准化母版。
它不是一个简单镜像标签，也不是一个压缩包，而是一个已经完成“环境准备、状态固化、可复用发布”的平台对象。后续每次创建 Sandbox，本质上都是在某个 Template 的基础上实例化。
为什么 Template 是 CubeSandbox 的核心概念
如果没有 Template，CubeSandbox 每次创建 Sandbox 都只能从最原始的输入现场做一遍：
- 拉镜像
- 解包文件系统
- 启动 Guest
- 初始化语言运行时
- 等待服务 ready
- 再把环境交给用户
这样做的问题非常明显：
- 启动慢
- 抖动大
- 无法高并发稳定交付
- 环境一致性差
CubeSandbox 之所以能把一个“完整可服务的隔离环境”交付得足够快，是因为它把 环境准备 和 实例交付 分成了两个阶段：
- 先制作 Template
- 再基于 Template 快速生成 Sandbox
Template 的存在，等于把“昂贵的初始化过程”从在线请求路径中提前剥离出去。
Template 不是镜像
这是最容易混淆的点。
镜像是输入
镜像（例如 OCI image）更像构建原材料。
它告诉系统：
- 基础文件系统内容是什么
- 需要哪些二进制、库、依赖
- 初始文件布局大致是什么
但镜像本身并不天然等于“可极速交付的沙箱环境”。
Template 是平台发布物
Template 是系统把镜像、初始化过程、快照、探针、暴露端口等信息整合之后，形成的 可被反复实例化的发布对象。
也就是说：
- 镜像更像“食材”
- Template 更像“备好菜的套餐”
CubeSandbox 真正反复复用的对象是 Template，不是原始镜像。
Template 到底包含什么
从概念上讲，一个 Template 至少包含四类内容。
1. 基础文件系统结果
Template 必须有一个可供后续实例复用的基础文件系统视图。
这部分通常来自：
- OCI 镜像
- Dockerfile 构建结果
- 初始化后的 rootfs
它决定 Sandbox 启动后“能看到什么文件”。
2. 预热后的运行状态
这是 Template 真正拉开差距的地方。
CubeSandbox 不只是保存“磁盘内容”，还会在冷启动并完成关键初始化之后，把可复用状态固定下来。这样后续实例就不必再从零等待所有运行时完成初始化。
这部分状态通常与快照能力直接相关。
3. 服务入口定义
Template 不只是“能启动”，还要定义“什么时候算可用”。
因此它通常还包含：
- 哪些端口需要暴露
- 哪个端口作为 probe / readiness 依据
- 哪些运行时行为是模板的一部分
对于代码解释器、浏览器自动化、开发环境这类场景，这一点尤其重要。
4. 平台元数据
Template 作为控制面的对象，还会携带元信息，例如：
- 模板 ID
- 来源镜像
- 规格和限制
- 创建状态与阶段
- 发布可见性或可用性状态
这些信息使 Template 能成为调度与 API 层真正可引用的对象。
Template 为什么不是“把环境打包一下”那么简单
如果只从表面看，Template 好像只是环境归档。
但实际上，Template 承担的是三个更深的角色。
1. 一致性锚点
Template 让一批 Sandbox 共享同一个起点。
这意味着：
- 相同 Template 创建出的实例环境一致
- 行为差异更多来自实例写时状态，而不是基础环境漂移
- 平台可以更稳定地复现问题与回滚变更
2. 性能锚点
Template 是极速交付的前提。
如果没有模板化，CubeSandbox 很难把“隔离环境 + 服务能力”同时做到低时延。
3. 发布锚点
Template 让环境从“开发产物”变成“平台发布物”。
用户不是直接操作镜像、内核参数、rootfs 路径，而是通过 Template ID 申请实例。
这和 Kubernetes 里 Deployment / PodTemplate 的作用有点像：它把底层细节收敛成了一个可发布抽象。
Template 的生命周期
可以把 Template 的生命周期理解成三个阶段。
1. 构建阶段
这一阶段的目标，是从原始输入生成可运行环境基础。
典型动作包括：
- 拉取或读取 OCI 镜像
- 构建 rootfs
- 安装依赖与初始化文件
- 准备基本运行环境
此时产物更接近“静态环境基础”。
2. 预热与固化阶段
这是 Template 和普通镜像分道扬镳的关键阶段。
系统会真正启动这个环境，让它走到一个“适合复用”的状态，然后再把状态固化下来。
例如：
- Guest 完成启动
- 语言运行时加载完毕
- 服务端口 ready
- 某些高频初始化已经做完
这一步决定后续 Sandbox 能否真正实现热启动与低抖动交付。
3. 发布阶段
一旦模板状态达到平台要求，它就从“构建中的临时结果”变成“可供请求引用的对象”。
此时控制面可以：
- 列出它
- 监控它
- 用它创建 Sandbox
- 在必要时删除或替换它
这一步把 Template 从构建流水线对象，变成了平台 API 对象。
Template 与 Sandbox 的真正关系
最常见的一句正确但不够完整的话是：
Sandbox 是由 Template 创建出来的。
更完整的说法应该是：
Template 定义了 Sandbox 的起点、基础状态和可复用准备结果；Sandbox 则是在这个起点之上的一次具体实例化。
这意味着：
- 同一个 Template 可以生成很多 Sandbox
- 这些 Sandbox 共享同一母版语义，但不共享实例级状态
- Template 决定基础一致性，Sandbox 决定运行时个体差异
Template 与 Snapshot 的关系
Template 和 Snapshot 高度相关，但不是同一个概念。
Snapshot 更偏机制
Snapshot 关注的是“如何保存与恢复某个运行状态”。
Template 更偏产品对象
Template 关注的是“一个可被平台发布和引用的环境母版”。
可以把两者关系理解成：
- Snapshot 是 Template 的关键能力组成部分
- Template 则是把 Snapshot、文件系统、服务定义和元数据组合起来后的平台对象
为什么 Template 在 Agent 场景里尤其重要
CubeSandbox 的主要场景之一是 AI Agent 的代码执行与工具调用。
这类场景对环境有几个特殊要求：
- 启动要快：Agent 通常频繁创建和销毁执行环境。
- 环境要稳定：同一个任务重试时，希望环境行为可复现。
- 服务要现成：很多环境不只是跑一次脚本，还需要已有的 Python、Node、浏览器或 API 服务。
- 隔离要强：不能因为追求速度退回共享内核模型。
Template 恰好就是同时满足这四点的关键抽象。
常见误解
误解一：Template 就是 Docker Image
不对。
Docker Image 是常见输入，但 Template 是 CubeSandbox 平台内部真正用于复用和交付的对象。
误解二：Template 越多越好
不一定。
Template 本身也是平台资产，需要构建、存储、管理和运维。过多模板会增加治理复杂度。
更合理的做法通常是：
- 用少量稳定模板覆盖主流场景
- 把场景差异控制在模板边界内
- 只在确实需要隔离环境差异时新增模板
误解三：有了 Template 就不需要实例级可写状态
不对。
Template 只是统一起点。Sandbox 在运行中仍然需要自己的实例级差异状态，例如临时文件、运行输出、依赖缓存、工作目录改动等。
平台设计者最该关注什么
如果你负责平台设计或运维，理解 Template 时要重点关注四件事：
- Template 是性能资产，不只是配置资产。
- Template 是一致性资产，不只是构建产物。
- Template 决定了 Sandbox 的默认运行语义。
- Template 的治理质量，会直接影响实例创建体验和系统稳定性。
与相关文档的关系
- 想看操作视角： 模板概览
- 想看创建命令： 从 OCI 镜像制作模板
- 想看实例对象： 什么是 Sandbox
- 想看状态复用机制： 什么是 Snapshot、冷启动与热启动
下一步
理解 Template 后，下一个问题通常是：
这个母版最后是如何变成一个真正运行中的隔离环境的？
这就要进入运行时抽象： 什么是 MicroVM、Runtime 与 Guest。