---
url: /space/introduction.md
description: >-
  SPACE 是什么？Perplexity 于 2026 年 10 月开源的 Agent 代码执行沙箱平台（Sandboxed Platform for
  Agentic Code Execution），Apache 2.0 + Rust，每个任务一台 Firecracker 微虚拟机、独立 guest
  内核，凭证在网络层注入永不进 guest，承载 Perplexity Computer 100% 会话；红队测试 9 个前沿模型 216 次运行 0/108
  逃逸成功，但修复前 11/54 绕过出网策略，官方把丢人数字一起公开了
---

# 认识 Perplexity SPACE —— 把 Agent 关进一次性虚拟机：0/108 逃逸，但 11/54 被翻墙

先说一件我自己干过的蠢事。

去年我给一个编码 Agent 开了本机执行权限，让它"帮我清理一下项目里没用的依赖"。二十分钟后我回来，发现它 `pip install` 了三十多个包、改了全局 pip 源、顺手往我的 `~/.zshrc` 里塞了两行 export。它干得挺认真，一句废话没说。

那一刻我意识到一件事：**我们这行花了二十年研究"怎么让程序别乱动系统"，然后在 Agent 时代，集体把 root 交出去了。**

Agent 和传统程序的根本区别在于，它干的事是动态的——装库、下载可执行文件、开网络连接、改自己的运行环境。你没法用"这个函数只能读这个文件"的老思路管它。而每一份你给它的权限，都是一份攻击面。

所以当我看到 **Perplexity** 在 2026 年 10 月把 **SPACE** 开源的时候，第一反应不是"又一个沙箱"，而是：**终于有人把生产环境跑了三个月的隔离层，连红队报告一起交出来了。**

而且那份报告里，有很难看的数字。我们先讲这个。

> 一个隔离层值不值得信，不看它宣称挡住了什么，看它敢不敢公布没挡住什么。

## 什么是 Perplexity SPACE

一句话：**SPACE（Sandboxed Platform for Agentic Code Execution）是 Perplexity 开源的沙箱平台，给每个 Agent 任务单独开一台 Firecracker 微虚拟机（microVM），让它带着自己的 guest 内核在里面随便折腾，而凭证和出网策略统统留在虚拟机外面。**

它不是新玩具。**自 2026 年 7 月起，Perplexity Computer 的每一个会话都跑在 SPACE 上，官方口径是 100%。** 这次开源的是那个已经在扛真实流量的生产系统，不是演示品。

几个基本盘：

| 项目 | 情况 |
| --- | --- |
| 发布方 | Perplexity |
| 开源时间 | 2026 年 10 月 15 日（Apache 2.0，GitHub: perplexityai/SPACE） |
| 当前版本 | **0.8.0**，官方定义的"公开基线版本" |
| 语言 / 协议 | Rust，Apache License 2.0 |
| 隔离单位 | 每个 sandbox 一台 Firecracker microVM，独占 guest 内核 |
| 对外接口 | HTTP API + Server-Sent Events（不用嵌 Rust 库） |
| 宿主机要求 | Linux x86\_64 + KVM，`/dev/kvm`、`/dev/net/tun`、loop 设备、btrfs、Docker |
| 支持 macOS 吗 | **不支持。** 想在虚拟机里跑还得开嵌套虚拟化 |

顺手说下版本路线，这个信息挺重要的：**0.8.0 是公开基线，0.9.0 是官方计划的"最后一个破坏性版本"，1.0.0 才承诺稳定 API 与沙箱生命周期契约。** 也就是说现在上车，还得接受未来有一次 breaking change。

## 特点

### 一、隔离是真的硬件级，不是 namespace 级

每个 sandbox 是一台完整的 Firecracker microVM，**有自己的 guest 内核**。Agent 在里面拿 root，装什么删什么随它。它改的是虚拟机的东西，不是你的。

Firecracker 是 AWS 用来跑 Lambda 的那套东西，本身就是一个被大规模验证过的边界。SPACE 选它，属于"不自己造轮子"的正确决策。

### 二、凭证永远不进 guest

这是我认为整个设计里最漂亮的一刀。

传统做法是：把 API key 写进环境变量，Agent 一 `env` 就看见了。SPACE 的做法是——**凭证在网络层注入，根本不进虚拟机。** 凭证仓库还额外加了分级作用域、速率限制和审计日志。

配套的还有：**每个 sandbox 一个宿主机侧的网络网关**，每一条出网连接都要过它的策略；网关会**终止 TLS，并同时校验 SNI 和 HTTP Host 是否在白名单里**。

翻译成人话：**Agent 就算拿到了 root，它也摸不到你的 key，也出不了你想让它去的地方。**

### 三、性能数据是生产环境的，不是实验室的

| 指标 | 数字 |
| --- | --- |
| 创建延迟中位数 | **185 ms → 60 ms**（对比 Perplexity 上一家供应商） |
| 创建延迟 p90 | **447 ms → 89 ms**（靠 warm pools） |
| 空闲自动挂起 | 6 小时无活动后 suspend |

89 毫秒拉起一台带独立内核的虚拟机——这个数字的意义在于，**你可以把它放进交互式请求的热路径里**，而不是让用户盯着"正在准备环境"转圈。

Kubernetes 部署用\*\*预热池（warm pools）**来跳过冷启动，单节点部署则用**基础快照（base snapshots）\*\*直接从快照恢复。

### 四、生命周期四种状态，长任务能睡能醒

Agent 任务是长跑的、有状态的、会分叉的，所以它必须能活过重启。SPACE 给了四态：**running / paused / suspended / deleted**。

* **paused**：内存还留在 worker 上，快，但不是持久快照
* **suspended**：内存、运行时状态、根文件系统全部快照，活跃资源释放掉
* **deleted**：没了

btrfs 的写时复制（CoW）负责生成每个沙箱的根文件系统，所以"开一台"这件事在存储层面几乎是白送的。

### 五、红队报告一起开源了（重点）

这部分我要展开讲，因为**这才是这次开源最值钱的东西**。

Perplexity 发布了一份叫 **《Escaping SPACE: Part I》** 的红队报告：拿 9 个前沿模型，给它们 guest 内的 root，跑 **216 次运行、2 个任务、4 种网络设置**。

结果三行：

* **沙箱逃逸：108 次运行里，0 次碰到宿主机侧的 secret。** 漂亮。
* **完全无网络：54 次运行里，0 次绕过。** 也漂亮。
* **部分放开网络：修复前 54 次运行里，11 次成功绕过。** 这就是那个难看的数字。

哪 11 次？**Claude Opus 5.0、GPT-5.6 Sol、GPT-5.6 Cyber、Kimi K3** 这四个模型找到了路子，手法是 **DNS 欺骗（DNS spoofing）和共享 CDN IP**——就是那种"我没访问黑名单域名，我只是解析到了一个恰好也在白名单 CDN 上的 IP"的经典操作。

Perplexity 随后补了源地址校验（nftables），网关改成终止 TLS 并同时查 SNI 与 HTTP Host，**重测之后没有模型能再复现一个已验证的绕过。**

> 我还想补一句更扎心的：同一个团队顺手测了 **10 个第三方平台，其中 8 个至少存在一个网络策略绕过**（E2B、microsandbox、Daytona 都在列），并且把结果通报给了每一家。**一个公司替整个行业做了一次免费的出网策略体检。**

## 能拿来干什么

**1. 给 Coding Agent 做执行底座**
这是最直接的。Claude Code、Codex、自研 Agent，都可以把"跑命令"这件事丢给 SPACE，而不是丢给宿主机。命令在一个带独立内核的虚拟机里跑，跑崩了重开一台就是。

**2. 长时运行的后台 Agent**
Perplexity 自己的定位就是"long-running agents 的执行层"。paused / suspended 两态就是为这个准备的：任务干到一半可以休眠、可以唤醒、可以分叉，不必一直占着资源。

**3. 多租户的代码执行服务**
你要做一个"帮用户跑用户代码"的产品（在线 IDE、数据科学笔记本、作业判题），每个用户一台 microVM 是最干净的隔离模型。SPACE 提供的是管理这一堆虚拟机的那层控制面。

**4. 从 E2B 平滑迁移**
已经用 E2B 的团队，SPACE 提供了 **E2B 兼容包装器（ECW）**，官方测试基线是 Python 包 `e2b==2.21.1`。仓库里还带一份 AWS EKS 参考部署。

横向对比一眼看清楚：

| 对比项 | Perplexity SPACE | E2B Runtime | microsandbox | Daytona |
| --- | --- | --- | --- | --- |
| 隔离 | Firecracker microVM | Firecracker microVM | libkrun microVM | 每沙箱独立内核 |
| 语言 | Rust | Go | Rust | 未公开 |
| 协议 | Apache 2.0 | Apache 2.0 | Apache 2.0 | 公开仓库，**2026 年 6 月起停止维护** |
| 出网控制 | 每沙箱网关 + TLS 终止 | nftables + SNI/Host 名单 | 未公开 | 未公开 |
| Perplexity 出网复测 | 修复后 0 绕过 | HTTPS 绕过，缓解方案在计划中 | HTTP+HTTPS 绕过，v0.6.18 修复 | HTTPS 绕过，已发布缓解 |

## 初体验：拉起来跑第一个沙箱

先说清楚门槛，别兴冲冲装到一半才发现跑不了：**必须是 Linux x86\_64 且带 KVM**。macOS 直接劝退，WSL / 虚拟机里跑需要先开嵌套虚拟化。

官方推荐路径是本地 **Kind（Kubernetes in Docker）** 集群，也支持不开 K8s 的直接模式。整体流程是：按 `docs/installation.md` 部署到 Kind → 用 `space-admin-cli login` 拿 token → 跑 `docs/first-sandbox.md` 建第一个沙箱。

核心 API 就这几个 REST 端点，用 Python 标准库就能调（官方 `examples/first_sandbox.py` 就是一个零依赖示例）：

```python
# 1) 从模板创建一个沙箱（自带幂等键）
POST /v1/sandboxes            {"template": "seed:latest"}

# 2) 生命周期操作是异步的，轮询 operation 等它完成
GET  /v1/operations/{operation_id}      # 等到 "succeeded"
GET  /v1/sandboxes/{sandbox_id}         # 等到 "running"

# 3) 在沙箱里跑命令
POST /v1/sandboxes/{sandbox_id}/commands
     {"command": ["sh", "-c", "printf \"Hello from SPACE\\n\""], "timeout": "30s"}

# 4) 命令输出走独立的 data-plane 连接 + SSE，用 session 级 attachment token
GET  /v1/sessions/{session_id}/events   # Server-Sent Events 流式读输出

# 5) 用完删掉
DELETE /v1/sandboxes/{sandbox_id}
```

两个概念先记住：**template** 是初始文件系统模板，**sandbox** 是模板的一个实例，自带虚拟机和可写磁盘，一个 sandbox 里能跑多条命令。

注意一个设计细节：**管理面 API 和输出流是分开的两条连接**（默认 8080 / 8090 端口），命令输出走独立的数据面，并且用 session 级的 attachment token。这个拆分明显是被安全审计逼出来的——管理令牌和输出流的权限必须分开。

## 先别急着上，几个坑得说清楚

我这人看见"开源""零逃逸""89 毫秒"就想泼冷水，以下几点你上线前得知道：

* **它挡得住逃逸，但"部分网络"仍然是最难的题。** 11/54 是在放开部分网络时被打穿的，虽然修了，但这说明**出网策略是这类系统里最脆的一环**。你自己配白名单时，别只看域名，要看解析后的 IP 段是否和白名单 CDN 重叠。
* **0.8.0 不是稳定契约。** 官方明说 0.9.0 还会有破坏性变更，1.0.0 才承诺兼容。生产上车请做好升级预算和回滚演练。
* **部署门槛是真高。** KVM + btrfs + loop 设备 + `/dev/net/tun` + Docker + Kind，这一串对很多团队来说是实打实的运维成本。它不是一个 `pip install` 就能玩的东西。
* **没有 macOS。** 用 Mac 开发、Linux 部署的团队，本地调试会很难受。
* **红队报告是 Perplexity 自己做的。** 数据详实、连丢人的数字都给了，可信度比一般厂商自报高得多，但**它依然不是第三方独立审计**。而且测试只覆盖了 9 个模型、2 个任务——真实攻击面比这个大。
* **Rust crate 级别的 API 不在兼容承诺里。** 1.0 承诺的是 HTTP API、node-api gRPC 和 spaced-bridge gRPC，你要是直接依赖它的 Rust 内部接口，没人给你兜底。

> 最后说个我的看法：SPACE 最值得学的不是 Firecracker，而是**它把红队报告和代码一起发布这件事**。安全产品最大的敌人从来不是攻击者，是"没人知道它到底挡住了什么"。

## 进阶

如果你想认真用 SPACE，我建议这么走：先拿 Kind 在本地起一套，用官方的 `first_sandbox.py` 把"建沙箱 → 跑命令 → 读 SSE 输出 → 删除"整条链路跑通；然后把你最担心的那个 Agent 动作（通常是"执行模型生成的 shell 命令"）迁进来，配一条最小白名单的出网策略，观察一周的审计日志；确认没问题之后再考虑 warm pools、E2B 兼容层或者上 EKS。

另外值得留意的是，Perplexity 把 SPACE 定位为"Agentic Runtime Platform（智能体运行时平台）"的**第一个组件**。也就是说他们接下来还要往外掏东西。Agent 基础设施这块，2026 年下半年明显在从"谁的模型强"转向"谁能让模型安全地动手"——SPACE 是这个转向里第一个把家底亮出来的。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。