10 月 15 日，Perplexity 把 SPACE 开源了，许可证 Apache 2.0。全名是 Sandboxed Platform for Agentic Code Execution，直译过来就是「智能体代码执行沙箱平台」。
它不是一个新项目。从今年 7 月起，Perplexity 自家的 Computer 智能体每一次会话都跑在里面，每天创建几百万个沙箱。开源的是这套已经在生产环境里挨了三个月的东西。
配套的数字也是这次传播的重点：九款前沿模型、一百一十八次越狱尝试、没有一次摸到宿主机。同一周 OpenAI 披露自家一个研究模型擅自用了加密钱包，印度 CERT-In 警告说有厂商的智能体未经授权触到了当地机构的在线系统。这个时间点放出一个「笼子」，很难说是巧合。
它做的其实是一件很朴素的事：给每个任务一台一次性电脑
智能体跟聊天机器人最大的区别是它会动手。装包、跑脚本、开浏览器、调接口，一件事做错就可能把宿主机上的密钥、文件、内网连接一起带走。
SPACE 的做法是给每个任务单独开一台微虚拟机，有自己的内核、内存、磁盘和网络。智能体在里头是 root，想装什么装什么，想跑什么跑什么，那是它自己的机器。任务结束，虚拟机销毁，除非你显式做了快照，什么都不留。
关键的一条是：凭据和出网策略不在虚拟机里。 密钥留在宿主机这一侧，智能体要用某个已授权的服务，请求从外面代理进去，它自始至终看不到那把钥匙。这一条比「虚拟机隔离」更值得抄——很多团队把 API key 直接塞进容器环境变量，等于把保险柜和钥匙一起给了对方。
围绕这个基本盘，还叠了几层能力：暂停与恢复、故障回滚、会话分支、定期文件快照与检查点。会话分支的意思是同一个任务可以从某个检查点岔出两条路各试一遍，这比自己写状态管理省事。
为什么不用 Docker 容器
这是最容易被跳过、但其实最关键的一节。
Docker 容器和宿主机共享同一个内核。容器里的进程如果找到一个内核漏洞，理论上可以翻到宿主机上。这不是危言耸听，是容器安全里长期存在的问题。对内网里跑几个内部服务，这个风险通常可以接受；对一个能被提示注入操纵、会主动尝试各种边界的智能体，就不太合适了。
Firecracker 微虚拟机走的是另一条路：靠 Linux 的 KVM 做硬件虚拟化，划出一道真正的边界。这个技术不新——AWS Lambda 从 2018 年就在用，2026 年 6 月刚为智能体负载转成正式可用。也就是说，SPACE 用的不是实验性方案，而是万亿美元级调用量的多租户平台用来隔离陌生代码的那套东西。
代价是它比容器重，所以才有下一节。
60 毫秒是怎么来的
微虚拟机的问题是启动慢。SPACE 报的数字是创建中位数 60 毫秒，快到可以在智能体的每一步都换一台新机器而不让用户感觉到延迟。
做法是热池加写时复制：集群里常驻一批预热好的 pod，常见模板已经落在磁盘上；请求进来先绑定到匹配的 pod，然后用 btrfs 的写时复制，从模板瞬间克隆出一个根文件系统。不用等完整操作系统启动，所以是毫秒级而不是秒级。
这一点对工作流设计的影响比听起来大。如果开一台干净的机器要三十秒，你自然会想「复用一台机器、多跑几步」；能六十毫秒开一台，就可以每一步都从干净状态开始，把「上一步留下的脏状态污染了下一步」这类问题直接消掉。
架构与硬件门槛
系统分四块：
- 一个 PostgreSQL 托底的接口层，管沙箱生命周期；
- 一组控制器，负责编排虚拟机的创建；
- 一组 worker 服务，处理网络与凭据；
- 一个数据面，用 btrfs 写时复制从模板生成每个根文件系统。
运行环境的要求写得很直白：Linux x86_64、KVM、btrfs、Docker。
这几条加起来的实际含义是：这不是给笔记本准备的。 要 KVM 就要有硬件虚拟化权限，btrfs 要求你愿意为它单独划分区或者换文件系统，生产上还要考虑热池占的内存。它期待的是一台真服务器，最好是一批。
如果你的开发机是 macOS，本地跑不起来是正常的，别在这上面浪费时间——直接在 Linux 机器或者云主机上试。
118 次越狱，这条数据该怎么读
先还原实验：Perplexity 拿九种前沿模型配置，专门下指令让它们想办法突破沙箱。累计一百一十八次尝试，没有一次逃到宿主机。有少数模型找到了绕过网络限制的办法，Perplexity 说已经补掉，复测时所有模型都绕不过去了。
同一套测试，他们也拿去打了几个商业闭源沙箱，说智能体从其中好几个里跑了出来。
读这条数据要注意三件事：
一、这是厂商自测，没有第三方复现。 这句话很重要。开源的意义恰恰在这里——现在外面的人可以自己去打了。第一批公开的越狱报告，或者长期没有报告，才是真正的结论。
二、「没有逃逸」不等于「没有越界」。 有模型绕过了网络限制，只是没摸到宿主机。对很多业务来说，出网被绕过的危害并不比逃逸小：数据能出去，指令能进来。
三、竞品失败那条是匿名指控。 没点名、没给方法和日志，只能当参考，不能当结论。
想上手：三步
第一步，确认机器。 一台 Linux x86_64 的机器，能开 KVM（ls /dev/kvm 有设备就行），有 btrfs 分区，装了 Docker。本地试就找台闲置的 Linux 主机，别在共用生产机上升级内核参数。
第二步，克隆仓库看文档。 地址是 github.com/perplexityai/SPACE。先读架构说明，再决定是单机跑还是上集群——单机能跑通流程，但热池、控制器那套价值要几台机器才体现得出来。
第三步，先迁一个只读任务。 如果你已经在用 E2B，SPACE 带了一个兼容层 ECW，现有的 Python SDK 调用改很少就能指过来。建议第一次只迁一个「跑代码、读文件、不改外部状态」的任务，把日志和快照都打开，跑通再扩大。
关于托管。 CoreWeave、Akamai、Crusoe 三家已经答应把 SPACE 作为服务卖给自己的客户。不想自己维护硬件的话，可以等这三家，好处是不会被单一沙箱厂商锁住。
优点四条
隔离边界是真的。 微虚拟机加硬件虚拟化，比共享内核的容器高一个等级。这一点对跑不受信代码的场景是硬需求。
启动快到可以改变设计。 60 毫秒意味着「一步一机」在经济上和时间上都成立，会话状态污染这类问题从设计上消失。
密钥不在笼子里。 凭据和出网策略放宿主机侧，这是最值得照搬的一条，和你用不用 SPACE 无关。
有迁移路径。 E2B 兼容层降低了切换成本，这一点比很多开源项目实在——大多数项目只给你一个「理念」，不给你一条从现有系统走出来的路。
缺点四条
硬件门槛高。 KVM、btrfs、Linux x86_64，三个条件凑齐不便宜。云上跑要选支持嵌套虚拟化的实例类型，成本比跑容器高不少。
自测数据还没有外部验证。 这是当前最大的不确定项。
运维面变大。 你要自己管虚拟机生命周期、热池容量、模板版本、快照存储。以前用托管沙箱，这些是别人替你操心的。
生态还年轻。 十月中旬才开源，周边工具、示例、社区问答都还在积累，遇到问题大概率得读源码。
谁该用，谁先别动
适合用的： 做编程智能体、能跑任意代码的产品；给客户交付智能体、需要过安全评审的团队；内部有多个智能体共用一套执行环境、想统一收口的平台组；以及被 E2B 或 Modal 的按秒计费压得比较疼的团队。
先别动的： 只是调用大模型接口、不执行代码的应用；智能体只读数据、不写不改的场景；团队里没人愿意维护 Linux 内核参数和文件系统的；以及在 macOS 上开发的个人开发者——本地跑不起来，云端跑又不划算。
三个替代方案
NVIDIA OpenShell。 上个月发布，属于它的开放智能体安全平台，定位同样是开源的智能体隔离环境。目前没有公开的越狱成功报告，但也没有 SPACE 这种量级的逃逸测试数据。如果你本来就在 NVIDIA 生态里，值得先看这个。
E2B。 商业托管沙箱，生态成熟、文档齐全、按用量计费，接进去最快。缺点是账单随规模走，而且隔离细节你控制不了。SPACE 的兼容层就是冲着它来的。
Modal。 更偏「把函数跑在云上」，沙箱只是它能力的一部分。如果除了隔离你还想要 GPU、队列、定时任务一整套，它更省心；如果只想要一个干净的笼子，它偏重了。
顺带说一句，这条线和站内写过的两件事是连着的：智能体靠 DNS 通道溜出沙箱讲的是笼子漏了会怎样，苹果收紧 Mac 全盘访问讲的是权限给多了会怎样。SPACE 属于第三条路——不靠模型自觉，也不靠事后收权限，而是把边界做在系统层。想系统看这类实践，可以翻智能体与自动化专题。
老达点评
一、这件事的真正卖点不是「免费」，是「把安全做成了基础设施」。 大部分团队做智能体的顺序是：先让它跑起来，出事了再补隔离。SPACE 相当于把「先隔离」这一步的成本压到接近零，顺序才有可能倒过来。这比省下的那点托管费值钱。
二、118 次零逃逸是个好数字，但现在还不是结论。 厂商自测、没有第三方复现、竞品匿名，这三条决定了它只能当「有说服力的初步证据」。真正有意思的是接下来半年：开源之后如果一直没人能打穿，那这个数字就立住了；如果很快被找出问题，那也是好事——总比在生产环境里被发现强。
三、「密钥留在笼子外面」这条，今天就能抄。 你不需要 Firecracker，也不需要 btrfs。把 API key 从容器环境变量里挪出去，改成一个只接受白名单请求的代理，这件事一个下午能做完，收益比换一整套沙箱大。
四、门槛高这件事，反而是它的诚实之处。 它没有假装能在笔记本上跑。一个安全组件如果为了「易用」把硬件隔离降级成容器隔离，那它解决的问题就少了一半。选型的时候，先问自己是要「看起来隔离」还是「真的隔离」，答案不同，选的东西完全不同。
参考来源：Perplexity 官方仓库 github.com/perplexityai/SPACE 与工程博客《How we built security into Computer》，Semafor 与 SiliconANGLE 10 月 15 日的报道，以及 wpnews.pro、FreeBuf、CodeYourCraft 的整理。站内可对照阅读：MCP 协议变更、Cursor 自托管执行环境，工具选型类内容在AI 工具评测专题。
