认识 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 就是一个零依赖示例）：
# 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 是这个转向里第一个把家底亮出来的。
更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。