背景：沙箱从「安全措施」变成「运行时地基」
过去两年讨论智能体安全，话题大多集中在提示注入、工具权限与输出过滤。这些讨论默认了一个前提：智能体会在某个地方执行动作，而那个地方的安全性是既定的。但当智能体开始真正写代码、装包、跑测试、调 API，这个前提就不成立了——执行环境本身成了设计对象。
Perplexity 的经历是一个具体样本。公司在二月推出 Computer 个人智能体产品，起初采用一家商业沙箱供应商；随后自建了这套被称作 SPACE 的平台来替换它。据官方博客转述，自替换完成起，SPACE 承载了 Computer 的全部会话，每天处理数百万次沙箱创建；在相同生产流量下对比，沙箱创建速度是此前供应商的三到五倍。10 月 15 日，这套内部基础设施以 Apache 2.0 许可对外开源。
需要留意的是，不同来源对「何时投产」的叙述并不一致：Unite.AI 的报道称公司在七月替换供应商、SPACE 自七月起承载全部会话；Crypto Briefing 则写平台在 2026 年 6 月进入生产。两者相差约一个月，且都未给出精确的切换日期。对读者而言，这不影响对架构的判断，但说明「生产验证时长」这个数字目前只能按季度而非按月来读。
更值得注意的其实是这样一句话：Perplexity 把智能体治理定位成一个工程问题，并认为开源是解决它的必要条件——因为能 inspect、能改、能基于它构建的人越多，发现的弱点就越多。这个判断决定了 SPACE 的形态：它不是一份白皮书，而是一套已经在生产流量上跑了数月、可以被别人拉下来部署的代码。
SPACE 不提供推理循环、工具生态、记忆机制或编排能力，也不绑定任何模型。它的作用域止于「智能体产生的代码与命令在哪里运行、运行环境如何隔离、状态如何保留、凭证如何交付」。理解这一定位很重要：引入 SPACE 不会让智能体变聪明，它改变的是智能体能安全地在多大范围内动手，以及动手之后能不能接着上一次继续。
两个原语：模板与沙箱
官方仓库的自述只有一句：插件化运行时沙箱，用于隔离运行智能体代码与用户代码。落到操作上，整套系统围绕两个可管理的对象展开。
| 对象 | 官方语义 | 可施加的操作 | 工程含义 |
|---|---|---|---|
| 模板 Template | 起始环境的定义，决定运行时与启动组件 | 构建、发布、拉取、预取、驱逐、删除 | 把「环境」变成可版本化、可分发的制品，而非每次重建 |
| 沙箱 Sandbox | 模板的一个实例，拥有自己的虚拟机与可写文件系统 | 创建、停止、启动、暂停恢复、快照、分叉、销毁 | 把「一次运行」变成有生命周期、可寻址、可回滚的对象 |
| 环境绑定 | 决定运行时版本与内核的组合 | 随模板发布传递，随沙箱原子持久化 | 让「这个沙箱跑在什么上面」成为可声明、可复现的事实 |
仓库提交记录给出了当前初始 Linux/x86_64 绑定的具体版本：Firecracker 1.15.1 配 Linux 6.1.155，以及 Firecracker 1.17.0 配 Linux 6.18.44。这个细节看似琐碎，实际上是把「环境」从一句 Docker 镜像名细化到了虚拟机监控器与内核版本——对需要复现与安全审计的团队，这个粒度是必要的。
模板与沙箱的分层还带来一个直接收益：模板可以被预热与缓存。仓库中存在热池策略配置与模板预取、驱逐逻辑，父模板可通过 btrfs 的 send/receive 机制恢复与拉取。这意味着「启动一个环境」与「从零构建一个环境」被拆成了两件事，前者追求延迟，后者追求可复现。
隔离层：Firecracker microVM 与那 60 毫秒
SPACE 用 Firecracker microVM 作为隔离边界。与在共享操作系统内做软件隔离不同，每个沙箱拿到的是一台拥有独立操作系统的小型虚拟机，隔离发生在技术栈更靠下的位置。这是 AWS 开发的虚拟化技术，也是近年来函数计算与沙箱类产品常见的选择。
性能上的关键数字是创建延迟。Perplexity 称中位创建延迟约 60 毫秒，此前为 185 毫秒，削减幅度约三分之二；Crypto Briefing 的报道给出了同一组数字。把这个数字放进上下文看会更有意义：60 毫秒意味着智能体在一次会话里反复开新沙箱、换环境、分叉试错，在人的感知上几乎是即时的——这会直接改变编排层的写法，因为「开一个干净环境」不再是需要节省的昂贵操作。
| 指标 | 数值 | 来源与口径 |
|---|---|---|
| 沙箱创建延迟中位数（当前） | 约 60 毫秒 | Perplexity 官方，经 Crypto Briefing 转述 |
| 沙箱创建延迟中位数（此前方案） | 约 185 毫秒 | 同一来源，未说明是否为同一测量方法 |
| 相对前供应商的加速倍数 | 3 至 5 倍 | 官方博客转述，注明为相同生产流量下的对比 |
| 每日沙箱创建量 | 数百万次 | 官方口径，量级表述而非精确值 |
| 重连事件 | 数千万次 | 官方口径，量级表述而非精确值 |
这里有一处需要读者自己判断的口径张力：60 毫秒对 185 毫秒是约 3.1 倍，落在官方所称「3 至 5 倍」区间的下限附近；但官方并未说明这两个倍数是否来自同一指标与同一测量窗口。稳妥的读法是——加速幅度在三倍量级是得到了两处叙述支持的，精确到「几点几倍」目前没有可核验的依据。
凭证治理：把密钥挡在沙箱之外
SPACE 在设计上把沙箱当作不可信环境对待。这一点在凭证处理上体现得最直接。
- 网络访问由平台侧管理：沙箱能连到哪里不由沙箱自己决定，而由控制平面的网络策略决定。
- 平台托管凭证保存在沙箱之外：智能体可以访问被授权的服务，但用于访问的那把钥匙并不存放在它的工作环境里。
- 支持自带密钥加密：官方称支持 BYOK 加密，凭证只在需要的那一刻注入，不写入沙箱内部。
- 出口策略持续细化：仓库在 10 月 15 日的提交中新增了操作者级别的出口配置（operator egress profiles），说明网络出口是仍在演进的治理面。
这套设计的价值不在「更安全」这个形容词，而在于它把一次典型的智能体事故路径切断了。常见的失败模式是：智能体为了完成任务去找缺失的文件、补失败的请求、绕过权限拒绝，在此过程中触碰到了本不该触碰的东西。如果凭证就在它的工作目录里，那么一次越权读取就直接等于凭证泄露；如果凭证被外部持有、按需注入，那么读取行为本身不构成泄露，攻击者还需要再突破一次边界。
官方对这套边界的表述也留了余地：模型层面的护栏降低不安全行为发生的概率，外围系统的独立控制则限制智能体能触及的范围、并在护栏失效时收敛损害。换句话说，SPACE 的定位是「护栏失效之后的那一层」，而不是「让护栏不必存在」。
状态：暂停恢复、滚动快照与会话分叉
长任务是智能体区别于问答产品的核心形态，而长任务必然遭遇中断：人会插话、需要补信息、要审阅草稿、网络会断、客户端会关。SPACE 的应对是把运行状态变成可管理的对象。
- 暂停与恢复：沙箱可暂停后再恢复，恢复后文件与运行中的状态都还在，不必从头重来。
- 滚动快照最长一周：官方称系统保留最长七天的滚动快照，用于中断后的续跑。仓库中也能看到卡死快照清理、孤儿恢复 Pod 回收等治理逻辑——这类「清道夫」组件的存在，恰恰说明快照不是免费的。
- 只存变更而非整体复制：官方说明系统存储的是变更部分，而不是反复复制整个环境，以降低创建、恢复与分叉的开销。这是把 60 毫秒创建延迟做出来之后，还能让快照不至于拖垮系统的关键。
- 会话分叉：可以在工作区的两个副本里分别试两种做法，出错后回到更早的文件状态。这项能力对应的是智能体工作流里很实际的一类需求——同一个数据清洗任务，两种方案并行试，挑好的那个。
把这三件事合起来看，SPACE 实际上把「一次运行」从一段进程提升成了一个可寻址、有历史、能派生分支的对象。对上层编排来说这是实质性的改变：重试不再等于重做，审阅不再等于打断，试错不再等于污染。
控制平面：七个组件各自负责什么
从仓库目录与提交记录可以还原出控制平面的职责划分。这套划分对想自建同类设施或评估其复杂度的团队最有参考价值。
| 组件 | 职责 | 值得注意的设计点 |
|---|---|---|
| space-api | 主 API，对外提供生命周期操作 | 生命周期变更异步执行，返回 operation ID 供调用方轮询 |
| space-admin-api | 管理面 API | 与主 API 分别配置停机与滚动策略，含优雅排空 |
| space-internal-api | 内部 API，运行两副本 | 状态落在 Postgres 行锁与声明令牌上，RPC 为一元调用 |
| space-data-plane | 数据平面，充当 guest 桥接 | 命令输出走独立连接，使用会话级 attachment token；原生会话走 SSE |
| cluster-controller | 集群控制器，负责驱逐与修复 | 含瞬态生命周期清扫、失败沙箱清理、可恢复故障修复等兜底协调器 |
| credential-manager | 凭证管理 | 独立的凭证权威与注入存储，是「密钥不进沙箱」的落点 |
| node-api / build-manager / volume-manager | 节点、构建与卷管理 | node-api 通过 Kubernetes TokenReview 认证，令牌有效期 600 秒；构建管理器令牌 7200 秒 |
工程治理上还有两处小细节值得一提。一是仓库用 ARCHITECTURE.toml 配合 cargo arch 做架构约束：单个 Rust 文件不超过一千行（基线中列出了 99 个超限文件），并禁止新增 common、util、core 这类泛化包名。二是 guest 内核的构建缓存被记录到 GHCR 的内容寻址标记上，原来的完整重建需要约三十分钟。这两件事都不面向使用者，但它们透露出一个信号：这套代码是按长期维护的基础设施标准写的，而不是一次性的研究成果发布。
红队：108 次尝试与「没有逃逸」能证明什么
官方称在 2026 年 9 月组织了一次红队演练，测试者尝试了 108 次越界攻击，没有一次成功从虚拟机逃逸到宿主系统。同时，少量尝试找到了绕过网络限制的方法，官方称已修复，且在后续复测中两种被识别出的攻击方式均未成功。官方还表示，把在其他沙箱平台上发现的同类弱点披露给了对应厂商。
这个结果应该怎么读？三点限定条件是必要的。
- 它是厂商自组织的演练：测试者、测试范围与攻击手法由 Perplexity 安排，未见第三方机构署名或完整测试报告公开。作为正面证据有效，但强度不等同于独立审计。
- 零逃逸不等于零绕过：官方自己就写明存在网络策略被绕过的情况并已修复。隔离边界与网络边界是两件事，前者守住不代表后者没有缺口。
- 108 这个样本量偏小：对一个面向公众开源、会被大量二次部署的系统，这个量级只能说明常见路径被覆盖过，不能说明攻击面已被穷尽。
反过来说，愿意公开「找到了网络策略问题」这一点，本身比只公布零逃逸更有信息量。它给出的读法是：隔离层经受住了定向测试，网络策略层是被攻破过又被补上的——而后者恰恰是后续使用者需要持续关注的地方。官方在 10 月中旬仍在提交与出口策略相关的改动，也印证了这一层仍在演进。
路线对照：托管沙箱、容器沙箱与本地沙箱
把 SPACE 放进当前的可选项里看，大致有三条并存路线，取舍各不相同。
| 路线 | 代表形态 | 优势 | 代价与适用边界 |
|---|---|---|---|
| 商业托管沙箱 | E2B、Daytona 一类托管服务 | 接入快、无需运维集群、按量付费 | 执行环境在第三方；Perplexity 替换供应商的理由正是稳健性与弹性不足 |
| 容器与本地沙箱 | Docker Sandboxes、本地容器与微型虚拟机方案 | 单机可跑、开发者上手门槛低、无集群依赖 | 隔离强度与多租户治理弱于虚拟机方案；难以承载大规模并发会话 |
| 自建虚拟机沙箱平台 | SPACE 这类以 Firecracker 为底座的控制平面 | 隔离边界靠下、状态可管理、凭证可外部化、可私有化部署 | 需要 Kubernetes 与运维能力；组件多、治理复杂；本地部署可用 Kind，但生产化仍需投入 |
值得注意的是 SPACE 在这三者之间留了一个过渡口：它提供了一个 E2B 兼容包装器，配合经过测试的 E2B Python SDK 工作。这相当于对已经用了托管沙箱的团队说——你可以先按 API 兼容的方式换底层，不必重写接入代码。对一项刚开源、尚无大量第三方部署案例的基础设施来说，这个兼容层比任何性能数字都更能降低采用门槛。
工程可落地性：Rust、Kind 与 E2B 兼容层
实现语言是 Rust，主体为一个 crate 工作区，外围有一个 Go shim 与一个前端控制台，服务间通过 protobuf 定义接口。调用方不需要嵌入 Rust 库，而是通过 HTTP 与服务端事件与它交互。
部署路径上，官方文档覆盖在本地 Kind 集群中的安装与认证配置，仓库根目录带有 Tiltfile 与 Helm chart，架构指南则说明如何在不依赖 Kubernetes 的情况下运行。数据库侧同时保留 PostgreSQL 与 SQLite 两条迁移路径，后者更可能服务于本地与小规模场景。
三点可落地性判断：
- 许可友好度较高：Apache 2.0 属宽松许可，允许修改与商用，对想把它作为产品底座的团队限制较少；引入前仍应以仓库内 LICENSE 文件的实际内容为准。
- 兼容性设计务实：E2B 兼容层加上 HTTP/SSE 的交互方式，意味着接入成本主要集中在运维而非代码改造。
- 运维门槛是真实存在的：这是一套含 API、管理面、内部面、数据平面、集群控制器、凭证管理、节点与卷管理的分布式系统，本地试跑用 Kind 可行，生产化则需要一支能管 Kubernetes 与 Firecracker 的团队。对多数中小团队，托管方案在总拥有成本上可能仍更划算。
生态侧，官方称 CoreWeave 与 Akamai 已在各自云平台上测试并上线 SPACE，并正推进向各自客户开放；Crusoe 也计划将其纳入托管 AI 服务组合。Perplexity 表示将把 SPACE 扩展为更完整的智能体运行时平台，并提到与 Nvidia 等方面围绕此类基础设施的安全标准展开合作——这部分属于路线图表述，尚无交付时间点。
局限与冷静判断
- 红队结果是自组织的：108 次尝试零逃逸为官方口径，未见独立第三方署名报告；同时官方已承认存在网络策略被绕过的情况。作为参考有效，作为合规依据不足。
- 投产时长存在口径分歧：一处来源写七月替换并全量承载，另一处写六月投产。生产验证时长目前只能按半年量级估计，不是精确值。
- 加速倍数的测量口径未公开：60 毫秒对 185 毫秒约为 3.1 倍，官方另称 3 至 5 倍，二者是否为同一指标未说明。这些数字来自单一厂商在其自身流量上的测量，未见到独立复现。
- 「数百万次创建」是量级表述：官方未给出精确计数方法与时间窗口，不宜据此推算可用性指标。
- 运维复杂度是采用的主要门槛：组件数量与 Kubernetes 依赖决定了它不是「装一个包就能用」的东西。多数团队的现实选择可能仍是托管服务，SPACE 更适合有明确数据主权或规模化成本诉求的场景。
- 它解决的是执行层，不是能力层：引入后智能体的任务成功率、规划质量、工具调用可靠性都不会因此改变。把它当成安全与状态基础设施来评估是合适的，当成性能方案则会失望。
- 版本与接口仍在演进：初始公开发布提交在 10 月初，此后十余天内仍在提交出口策略等治理类改动，接口稳定性与升级路径需要持续跟踪，生产项目应锁定版本。
总体而言，SPACE 的价值在于把一件此前各自为政的事情标准化了：智能体到底该在哪里动手。它给出的答案有清晰的层次——虚拟机级隔离、凭据外部化、状态可管理、控制平面可审计，并且这套答案已经在每天数百万次的真实创建上跑过。对正在自建智能体执行环境的团队，它提供了一个可以直接对照的参考实现；对更多的团队，它提供的是一份 checklist：你的沙箱有没有把凭证挡在外面，有没有把状态存下来，有没有想清楚网络出口归谁管。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。