你让 AI 自己写代码、运行命令，就像把工具箱和房门钥匙一起交给一位速度很快、但偶尔会判断失误的助手。它可能只是整理文件，也可能误碰不该碰的东西。Perplexity 开源的 SPACE，想解决的正是这个问题：给每个 Agent 任务安排一间独立、可管理、用完能销毁的“工作室”。
SPACE 全称是 Sandboxed Platform for Agentic Code Execution，即“面向 Agent 代码执行的沙箱平台”。沙箱（Sandbox）是限制程序活动范围的隔离环境，避免它随意接触宿主机的文件、网络或其他进程。本文事实主要来自 Perplexity 的官方 GitHub 仓库，尚缺独立信源交叉验证。
不只是开一台小虚拟机
SPACE 使用 Firecracker microVM 运行代码。Firecracker 是 AWS 最初开源的轻量虚拟机技术；microVM 则是删去许多传统硬件模拟、功能更精简的微型虚拟机。它试图在进程级隔离与完整虚拟机之间找到平衡：保留独立虚拟机的边界，同时减少不必要的负担。
但 SPACE 并不是 Firecracker 本身，也不只是一个启动虚拟机的工具。它负责整套沙箱编排：应用通过 HTTP API——也就是用网络请求调用服务的接口——创建 Linux 环境、执行命令、收集输出，并管理环境的整个生命周期。
一个 template（模板）提供初始环境。由它创建的每个 sandbox 都有独立 VM 和可写文件系统，同一个 sandbox 还能连续运行多条命令。这样，Agent 可以先生成文件，再调用工具处理，最后读取结果，而不必每执行一步就换一个全新环境。
把执行过程拆成可控步骤
SPACE 的生命周期操作采用异步方式。应用发出创建、暂停或恢复请求后，API 先返回 operation ID（操作编号），调用方再轮询状态，确认任务是否完成。说白了，它更像取号办事：请求已经受理，但应用不能把“收到号码”误当成“操作完成”。
命令输出走独立的数据平面连接，并使用 session-scoped attachment token——只在特定会话范围内有效的连接凭证。控制沙箱的请求与传输运行结果的连接因此分开处理。
生命周期选项也不止创建和删除。SPACE 支持 keep、pause、suspend、wake 和 delete，分别用于保留、暂停、挂起、唤醒和删除沙箱。官方材料还列出 base snapshot（基础快照）恢复能力，以及 Kubernetes warm pools：预先准备已经启动的沙箱，让新建流程跳过一部分冷启动。不过仓库没有给出具体能快多少。
为什么现在值得看
Agent 正从“给建议”走向“亲自操作”。只要它能执行代码，问题就不再只是回答是否准确，还包括任务之间怎样隔离、执行现场怎样保留、失败后怎样恢复，以及长期不用的环境怎样暂停并重新唤醒。SPACE 把这些问题整理成统一接口，让上层应用决定运行什么、保留什么，底层平台负责环境、进程和输出连接。
这套系统可部署到本地 Kind/Kubernetes 集群。Kind 是在本机用容器搭建 Kubernetes 测试集群的工具；Kubernetes 则负责调度和管理一组服务。架构文档同时说明，SPACE 也能脱离 Kubernetes 运行，因此不能把后者理解为硬性依赖。
它还提供 E2B Compatibility Wrapper，可配合官方测试过的 E2B Python SDK 使用。不过这只是部分兼容层，文档明确列有支持范围和限制，不能等同于完整兼容 E2B。
据 Perplexity 与 Akamai 的公开材料，SPACE 此前已用于 Perplexity Computer，为 Agent 任务提供独立环境，并支持暂停、恢复、故障恢复和会话分叉；Akamai 也已在自家云上测试并上线。仓库显示项目采用 Apache License 2.0。
局限与未知
- 现有材料没有性能测试、启动时延或资源开销数据，无法判断实际部署成本。
- 仓库没有提供安全审计结果。microVM 隔离是设计基础，但不能据此宣称 SPACE 已被验证为安全。
- warm pools 只说明可减少部分冷启动流程，尚无具体提速幅度，也不足以证明系统已经“生产就绪”。