Perplexity 开源 Agent 代码执行平台 SPACE，用 Firecracker microVM 隔离运行
Perplexity 开源了团队内部 agent 代码执行平台「SPACE」，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 里隔离运行，通过纯 HTTP/SSE API 对外服务
Perplexity 开源了内部使用的 Agent 代码执行沙箱平台 SPACE，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 中隔离运行，通过纯 HTTP/SSE API 对外服务。平台以 Template、Sandbox、Process、Command session、Operation 五个抽象组织生命周期，管理面异步写入 PostgreSQL 由控制器收敛，数据面经会话级 attachment token 用 SSE 直连沙箱进程，管理 token 与 attachment token 不可互换。抗冷启动采用 K8s 下的 Warm pools 与单机部署的 Base snapshots 两层方案，并提供 E2B 兼容层，用 E2B Python SDK 的应用可近乎无缝迁移。
推荐理由
AI 评分 71
原文拆解了 SPACE 的控制面与数据面分离、token 分域和抗冷启动方案，可看开源沙箱平台如何隔离不可信 Agent 代码。
主题
查看原帖we open-sourced SPACE, the sandbox platform we use internally for secure agentic runtimes. it powers Computer as well as our RL training and evaluation workloads. https://t.co/W2XKKCnzgX
正文
核心抽象：五个概念 + 严格分离的生命周期 · Template：起始文件系统与运行时配置（不可变，类似镜像），按内容寻址（sha256: digest） · Sandbox：一个 Template 的实例，独立 microVM + 可写文件系统 · Process：在 Sandbox 内执行的程序，同 Sandbox 内进程共享环境 · Command session：一次命令的连接信息与授权，创建即分配进程 ID，attach 才真正启动 · Operation：异步生命周期请求（create/pause/suspend/wake/delete）的追踪记录
关键设计：Sandbox 的生命周期长于创建它的请求，也长于承载其输出的连接。管理面是异步的，API 只把期望状态写入 PostgreSQL，由控制器和 worker 协调收敛，客户端拿 operation ID 轮询；数据面则完全独立，通过会话级 attachment token 经 SSE 直连沙箱内进程取输出。管理 token 与 attachment token 不可互换，这是它的安全边界之一。
架构：控制面/数据面分离 + 声明式调和 请求与执行分两条路径： · 管理面：Application → API → PostgreSQL（期望状态）→ 集群控制器 → 沙箱 Pod（K8s 模式下）→ 运行时 shim → Worker 服务 → Firecracker microVM → 客户进程。 · 数据面：Application ↔ Data plane ↔ 客户进程，旁路整个控制面，输出流不经过数据库。
Worker 负责 VM、网络、卷、模板、凭证，用 btrfs 写时复制构建根文件系统（这是快速克隆沙箱的关键）；模板与快照走对象存储（本地用 Versity S3 Gateway）。部署形态可插拔：Kubernetes 适配器（本地 Kind、云端 EKS 参考部署）或直接适配器（不经 K8s 直调 worker，支持单机运行）。
Pause 与 Suspend 的区分体现其状态机的严谨性：Pause 保留常驻内存（快恢复但非持久）；Suspend 生成 VM 内存 + 运行时状态 + 根文件系统的完整快照并释放资源（真正的持久化），两者都用 Wake 恢复。默认 6 小时无活动自动 Suspend（这是空闲限制而非最长存活时间）。
性能工程：两层抗冷启动 冷启动是 microVM 沙箱平台的体验瓶颈，SPACE 给了两个正交方案： 1. Warm pools（K8s 部署）：按“模板版本 × VM 规格”预启动一批就绪沙箱，create 直接领用，池空了才退化为冷启动； 2. Base snapshots（单机部署）：从基线快照恢复，跳过完整引导。
配合 Firecracker 本身亚秒级的 VM 启动和 btrfs CoW 文件系统克隆，整体面向“Agent 秒级拿到可用环境”的目标。
“可插拔运行时”：为未来预留的执行环境身份体系 这是仓库描述里 "pluggable-runtime" 的实质，也是设计上最有前瞻性的部分。每个执行环境被定义为主机平台 × 运行时绑定 × 客户平台 × 引导配置 × 隔离语义 × 兼容性Profile 的完整组合，整体 SHA-256 内容寻址。当前只实现了编译进代码的 E0 定义：Linux/x86_64 宿主、KVM、Firecracker 1.15.1（含 jailer）、内核 6.1.155、快照格式 9.0.0。
值得注意的三个原则： · 结构可解码 ≠ 可执行：解码成功、工件存在、节点健康，都不构成执行授权，三者分离校验； · 身份不可扩展含糊：任何改变引导/恢复语义的字段都必须产生新的 schema/引用，“加了字段还沿用旧引用”被明令禁止； · 主机平台类型里已预留 Linux/Windows/macOS 的区分身份，虽然当前只实现了 Linux 适配器。
这明显是在为未来支持其他 hypervisor、客户架构甚至非 Firecracker 运行时铺路，而不是把 Firecracker 硬编码进协议。
安全模型（分层清晰） · 硬件级隔离：Firecracker microVM 边界（KVM），这是对不可信代码的根本防线； · token 分域：管理面 bearer token 与数据面 attachment token 隔离； · 网络策略：沙箱 Pod 独立 namespace（sandboxes），NetworkPolicy 只放行 API 与控制器端口，出站默认限公网 IPv4 + 集群 DNS，可配 egress profile 精细管控，甚至有 TLS 拦截豁免机制； · 供应链：gitleaks、cargo-deny、supply-chain 目录、pre-commit/lefthook 一应俱全； · 内部 RPC 走 TLS，模板注册可限制可信 S3 bucket 白名单。
兼容性与工程成熟度 · E2B 兼容层（ECW）：在边缘翻译 E2B API 请求/响应，用 E2B Python SDK 的应用可近乎无缝迁移（语义映射：E2B 的 pause → SPACE suspend）； · 客户端零绑定：纯 HTTP + SSE，OpenAPI 规范直接服务在 /openapi-m1.json，不需要嵌入 Rust 库——这对采用率至关重要； · 运维面齐全：space-admin-cli（节点、暖池、模板构建）、Web UI、OpenTelemetry 可观测性、mdBook 文档； · 开发体验：tilt up 热重建，单测 + Kind 冒烟套件。