SPACE 执行环境设计揭秘：Firecracker 多版本绑定、E0 参考与快照兼容性指南

SPACE是一个用于代理代码执行的沙箱平台（Sandboxed Platform for Agentic Code Execution），通过可插拔的运行时将 Agent 与用户代码隔离在 microVM 中运行。本文带你快速看懂它的执行环境设计：什么是E0 环境参考、为什么Firecracker 多版本绑定如此严格，以及快照跨环境兼容性的规则边界——即使是新手，也能一次性读懂这套身份机制。🧭

执行环境是什么：给 microVM 环境发"身份证"

在 SPACE 里，一次沙箱启动不只是"下载一个二进制"。一个**执行环境（Execution Environment）**把六样东西绑成一个整体：

• 运行时（如 Firecracker 版本）与字节级摘要
• 宿主机要求（Linux / x86_64 / KVM）
• 客户机平台（guest 操作系统与架构）
• 启动输入（直启内核版本与摘要）
• 隔离语义（硬件 VM 边界）
• 快照兼容档案（Firecracker snapshot 格式版本）

而整个定义的 SHA-256 哈希，就是这个环境的参考（reference）。文档中有一个关键区分：工件摘要（artifact digest）标识"字节"，环境参考标识"字节 + 执行要求的特定组合"——装上了不等于能选、能用、被批准。

E0 环境参考：默认基线是如何构成的 🎯

E0是当前编译进 SPACE 的默认环境定义，也是唯一通过生产资格认证的 Linux/x86_64 组合：

• 宿主机与客户端：Linux / x86_64，后端 KVM
• 运行时：Firecracker1.15.1（含 jailer 的二进制摘要，而非下载包哈希）
• 内核：Linux6.1.155（boot.profile=linux_direct_v1直启）
• 快照格式：Firecracker snapshot9.0.0

E0 的规范字节采用固定字段顺序、ASCII 键名与规范标量写法，由 canonical_descriptor 生成，并有独立的 E0 黄金向量 做校验锚点：

space.execution.environment schema=1 host.os=linux host.arch=x86_64 backend=kvm ... runtime.kind=firecracker runtime.version=1.15.1 boot.kernel.version=6.1.155 compatibility.state.version=9.0.0

对这个精确编码做 SHA-256，即得 E0 参考：sha256:3168c96b...11fa0b（完整值见 e0.json）。设计上的巧妙之处：JSON 的空格和字段顺序不影响身份，但任何改变启动/恢复语义的字段变化都会让参考彻底失效——想"偷偷"修改环境定义，哈希会立刻不匹配。

Firecracker 多版本绑定：三个编译环境一览

SPACE 的 runtime-manager 编目按版本记录了 Firecracker 与快照格式的对应关系，并预检了配套的 guest 内核：

几个值得记住的规则 🔑：

1. 安装 ≠ 选择：用space-rtmgr runtimes install fc-1.17.0装入新版本，并不会让节点切换到它；只有编译目录中批准的完整绑定（运行时 + 内核 + 摘要 + 兼容档案）才能被显式选中。
2. 部署身份限制：显式选择非 E0 环境需要SPACE_ENV为dev、test、staging、local-*等身份；生产、缺失或格式错误的身份只能选 E0。
3. E0 不可删：E0 的运行时与工件在托管存储中受删除保护，即使清单为空或重启后依然有效；坏掉的候选工件只影响自己，绝不会拖垮 E0。

快照跨环境兼容性：快照永远"记得"自己的出身 📦

这是最容易踩坑的部分。核心原则只有一句话：快照保留其原始的 VMM 与内核绑定，跨环境恢复不是升级路径。

• 两个非默认绑定目前支持冷启动与同环境内存快照；跨环境身份恢复直接拒绝。
• 非默认的快照捕获（CreateSnapshot）会携带环境绑定的沙箱身份，旧版 node-manager 在捕获前就会拒绝该请求——失败是显式的，而不是静默降级。
• 快照格式也随之升级：1.16.2 的 11.0.0 格式无法恢复 1.16.0 的 10.0.0 快照，所以编目必须逐版本核对上游SNAPSHOT_VERSION，而不是按发行号猜测。
• 滚动升级期间，非默认环境的 suspend 可能失败并留下驻留的暂停 VM：正确做法是升级节点后重试，或先恢复它；绝不要为了兼容旧读端而剥离绑定的元数据。

部署与验证建议

• 升级顺序：先部署 node-manager、template-manager、sandbox-manager 读端，再升级 builder 与客户端；混合版本期间，普通 E0 流量不受影响，非默认任务失败时给出显式错误，不静默回退。
• 回滚策略：停止产出带绑定的发布，继续使用保留的旧 schema 发布即可；只要带绑定的模板还在使用，就要保留兼容读端。
• 性能对比：项目内置基准脚本可对比 E0（A 臂）与 1.17.0/6.18.44（C 臂）的创建延迟、冷启动就绪和 stop/start 周期，见 bench-runtime-environments.py 与 基准说明。

总结与延伸阅读

SPACE 的执行环境设计可以浓缩为三条原则：安装不等于选择；解码不等于授权；快照永远跟随它的出身环境。环境参考作为不可变身份，贯穿模板构建、沙箱元数据与快照恢复的完整生命周期，让"哪个字节在哪个环境下运行"成为可审计、可校验的事实。

想继续深入？推荐以下资料 📚：

• 执行环境契约：docs/execution-environments.md
• 运行时与内核编目：docs/runtime-manager-catalog.md
• 环境编解码实现：crates/libs/execution/common/src/environment.rs
• 执行协议定义：proto/execution/v1/execution.proto
• 原生模板启动机制：docs/native-template-runtime.md