别把钥匙交给客人：Perplexity 开源 SPACE 沙箱这件事
Perplexity 开源 Agent 沙箱 SPACE：每个沙箱一台 Firecracker 微虚拟机，凭证不进沙箱，给 Agent 干活之前先把钥匙收好。
给 AI Agent 干活，最让人后背发凉的，是它顺手碰到了不该碰的东西。比方说项目里的 .env 文件，用过电脑的人都知道这个文件里装的是什么，那是一串串的钥匙，平常藏在抽屉最里面，连自己都不太愿意多看。现在有一个勤快的帮手，替你收拾屋子，收拾得太彻底，把抽屉也端出去晒了。
这种事情说不上是谁的错。Agent 没有恶意，它只是在完成任务，人也没有犯傻，他只是信任了一个看上去很能干的工具。问题出在两者之间那块谁也没有认真对待的空地上：干活的东西和钥匙放在同一间屋子里。只要它们待在一起，出事就只是时间和概率的问题，今天不是 .env，明天也可能是别的什么，句号。
所以我看到 Perplexity 10 月 15 日在官方博客上宣布开源 SPACE 的时候，多看了几眼。SPACE 是 Sandboxed Platform for Agentic Code Execution 的缩写，说得朴素一点，就是给 AI Agent 用的沙箱，让它在一个单独的小房间里干活，房间里可以随便折腾，房间外面它碰不到。Perplexity 官方称，这套东西用 Rust 写成，采用 Apache 2.0 许可证，任何人都可以拿去用、拿去改。
先把据官方博客和仓库文档能确认的事实交代清楚，免得后面的感慨没有着落。每一个沙箱是一台 Firecracker 微虚拟机，自带一套操作系统和可以写入的文件系统，不是在宿主机上开个文件夹假装隔离。有一个中央控制面，负责把沙箱建起来、暂停、恢复、删除。应用程序要用它，走的是 HTTP API 加上 SSE 流式输出，建一个 Linux 环境，往里面发命令，再把输出一行行拿回来，用不着在自己的程序里嵌一个 Rust 库。官方给出的第一个示例，是一段只用 Python 标准库的脚本。这一点我很喜欢，门槛低的东西才会有人真用。
它的概念也简单。template 是起始环境，本地默认叫 seed:latest，sandbox 是从 template 生出来的实例，同一个沙箱里可以连着跑好多条命令，像是一间租下来的工作间，进去以后可以一直待着，不用每干一件事就重新租一次。仓库文档还写了本地怎么部署：用 Kind 搭一个小 Kubernetes 集群，配好 SPACE_API_URL、SPACE_DATA_PLANE_URL、SPACE_TEMPLATE、SPACE_API_TOKEN 几个环境变量，node-manager、sandbox-manager、template-manager 这些节点服务各自作为一个 DaemonSet 跑起来，和生产环境的样子保持一致，不想用 Kubernetes 的人也有另外的跑法。文档里标着 incubating 的字段，官方明说不在支持范围内，这种老实话我也愿意多看一眼。
真正让我觉得这东西有点意思的，是 7 月 15 日那篇介绍安全设计的博文。据 Perplexity 官方博客，他们的出发点是把沙箱本身当成不可信的东西。这句话听上去像是废话，其实很不容易做到。大多数人做工具，心里默认自己做的东西是好的，出了问题再去补；而这里的意思是，先假定里面那位客人随时可能乱来，然后再去想房子该怎么盖。
具体怎么盖，官方写了几条。第一，凭证不放进沙箱。需要连 Google 账号之类的时候，由外面在用的那一刻注入，而不是事先把钥匙挂在墙上。第二，出站网络在节点这一层管住，客人想往外打电话，得先过门房。第三，沙箱里只有一个叫 Space Daemon 的进程和控制面说话，传的是开始、暂停、快照这类信号，因此这条通道是可以审计的。三条合起来看，意思就清楚了：干活的地方和放钥匙的地方，从设计上就是两间屋子。
我想起老派一点的生活常识。家里请人来装修，懂行的人不会把存折和房产证放在工地上，师傅再老实也不行，因为工地上人来人往，东西多，灰也大，丢了找不回来，也说不清是谁的责任。钥匙锁在另一间屋子里，师傅要用电闸，主人过去开一下，开完再锁上。这件事和信不信任师傅没有关系，是对自己负责。Perplexity 做的，大体就是把这套常识翻译成了虚拟机、控制面和网络策略。
这套东西也不是凭空想出来的。据官方博客，Perplexity 今年 2 月上线了 Computer 产品，一开始用的是商用沙箱供应商，7 月换成了自研的 SPACE，工程团队从概念到上线用了 10 周。官方还说，换上的那一周已经支撑了数百万次沙箱创建、数千万次重连，这些都是 Perplexity 自报的数字，外人没有办法核对。我比较相信的反而是「替换」这个动作本身，一家公司愿意把已经在跑的供应商换掉，自己背上运维的担子，多半是被什么事情逼到了那一步，不然谁愿意给自己找麻烦呢？
还有一件被媒体拿来做标题的事。据 Semafor 报道，Perplexity 让 9 个前沿模型尝试从 SPACE 里逃出去，118 次尝试全部失败，同时 Perplexity 称这些模型能逃出其他一些没有开源的沙箱。这是官方说法，目前没有看到第三方独立复现。我对这类数字的态度一向是听着，不急着信。118 次失败说明在那一套测试条件下守住了，不说明永远守得住，安全这件事没有「已经完成」的时候。不过把代码放出来，本身就是给别人递了一把放大镜，愿意被人挑刺的东西，通常比藏起来的东西靠谱一点。
据官方博客和 Semafor 的说法，已经有几家公司接了过去：Akamai 在自己的云上测试并上线了，Crusoe 计划把它纳入托管 AI 服务，CoreWeave 发了一份在 CKS 上部署的评估指南。Semafor 也提到 NVIDIA 有一个叫 OpenShell 的同类东西。可见大家想到的是同一件事，Agent 越来越能干，总得有人替它盖房子。GitHub 上 perplexityai/SPACE 这个仓库，据 10 月 17 日凌晨 3 点 20 分（北京时间）通过 GitHub API 读取，是 1,067 个 star、76 个 fork，这个数字会变，写在这里只是留个当时的样子。
说到这里，我得承认自己是个外行。我没有在自己的机器上把 SPACE 跑起来过，上面讲的都来自官方博客、仓库文档和媒体报道，不是我的亲手实证。老狗不在不熟的山路上逞能，能讲的只是常识层面的东西。
常识层面的东西是这样的：这两年大家对 AI Agent 的期待，总是落在「它能做多少事」上面，能写代码，能装软件，能替你开网页填表格，能拿 root 权限跑命令。能力越大，大家越兴奋，好像人和美好生活之间只差一个足够勤快的 Agent。可是很少有人去想另一半问题：它做错了事，代价落在谁头上？这个问题不像能力演示那样好看，没有办法录成一段视频发出去，却是真正决定一件工具能不能在日常里长久用下去的东西。
省脑子就会导致费钱，这句话放在这里也一样成立。把钥匙和 Agent 放在一起，是最省事的做法，配置一次，处处能用，什么都不用想。省下的那点脑子，迟早会以账单的形式还回来，区别只在运气。反过来，把凭证挪出去、把网络管起来、让沙箱只能通过一条窄窄的通道和外界说话，这些都是麻烦事，每一件都要多想一步，可是多想的这一步，就是安全本身。
我设想过一个场景，这里说明是假设：一个人让 Agent 替他整理项目，Agent 在沙箱里装包、跑测试、改配置，忙了一下午，最后需要把结果推到云上，这时候外面的控制面才把那一把钥匙递进去，用完立刻收回。哪怕 Agent 在中间犯了糊涂，想把整个目录都打包发出去，它手里也没有那把钥匙，门房也不放它往陌生的地址打电话。这个场景一点都不酷，甚至有点啰嗦，但我觉得这才是工具该有的样子：能干的帮手，加上一个不给帮手添堵的房子。
所以对于 SPACE，我的态度很简单。它是不是最好的沙箱，我不知道，官方的数字我也只当官方的数字来看；但它把「干活的地方」和「放钥匙的地方」分开这件事说清楚了，又把代码放出来让人看，这就已经比那些只讲 Agent 有多能干的发布会，更值得人坐下来读一读。
钥匙这种东西，从来都不该交给客人，哪怕客人是自己请来的，哪怕客人比自己能干，不是么？
来源：Perplexity 官方博客；GitHub：perplexityai/SPACE；Semafor。部署规模、118 次越狱测试全部失败等为 Perplexity 自报或经 Semafor 转述，未独立复现；star/fork 为 GitHub API 2026-10-17 03:20（北京时间）读数，会变化。