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

【免费下载链接】SPACE

Sandboxed Platform for Agentic Code Execution: pluggable-runtime sandboxes for running agent and user code in isolation.

项目地址：https://gitcode.com/gh_mirrors/space34/SPACE

点击查看免费下载

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 内核：

绑定	Firecracker	内核	快照格式	定位
E0	1.15.1	6.1.155	9.0.0	生产默认，始终受保护
非默认 1	1.17.0	6.1.155	12.0.0	仅限非生产显式选择
非默认 2	1.17.0	6.18.44	12.0.0	仅限非生产显式选择

几个值得记住的规则 🔑：

安装 ≠ 选择：用space-rtmgr runtimes install fc-1.17.0装入新版本，并不会让节点切换到它；只有编译目录中批准的完整绑定（运行时 + 内核 + 摘要 + 兼容档案）才能被显式选中。
部署身份限制：显式选择非 E0 环境需要SPACE_ENV为dev、test、staging、local-*等身份；生产、缺失或格式错误的身份只能选 E0。
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 与基准说明。