先看证据
开源的是一层执行底座
Perplexity 开源了 SPACE（Sandboxed Platform for Agentic Code Execution），这是 Perplexity Computer 为智能体任务运行代码的沙箱平台。项目以 Apache 2.0 发布，当前公开基线为 0.8.0，面向需要运行编码或浏览智能体的团队。应用通过 HTTP API 创建 Linux 环境、执行命令，并用服务器发送事件（SSE）接收输出。
这次开源值得读，不是因为“智能体能执行代码”本身新鲜，而是因为执行环境开始成为智能体产品的基础设施问题。智能体会安装软件、调用服务，还可能以 root 权限操作自己的环境；同时，任务又可能持续很久、保留状态并分叉。SPACE 的设计试图让这些操作留在来宾系统里，而不把宿主机和凭据一并交给智能体。
隔离虚拟机，也隔离控制权
SPACE 为每个沙箱任务启动一台 Firecracker 微型虚拟机，拥有独立的来宾内核和可写磁盘。模板提供初始文件系统，沙箱则是该模板的一次实例；同一沙箱里可以连续运行多条命令。底层用 btrfs 的写时复制创建根文件系统，减少重复准备环境的成本。
更重要的边界在虚拟机之外：宿主机上的专属网络网关控制每个出站连接，密钥不会被放进来宾系统，而是由网络层注入。凭据存储还支持分层作用域、速率限制和审计日志。服务端由 PostgreSQL 支撑的 API、控制器、工作服务和数据平面组成，工作服务负责虚拟机、网络、卷、模板与凭据等资源。换句话说，隔离不只靠“虚拟机够不够硬”，还依赖外部控制面不把权限和网络通道无条件交给任务。
持久状态带来速度与资源取舍
SPACE 把沙箱生命周期分成运行、暂停、挂起和删除。暂停时，虚拟机内存仍留在工作节点上，因此它不是可持久保存的快照；挂起则会保存内存、运行状态和根文件系统快照，并释放活跃资源。默认情况下，空闲六小时后沙箱会进入挂起状态，这让长任务能保留进度，也意味着系统需要管理快照和恢复过程。
部署方式也影响启动速度。Kubernetes 部署可以用已启动的沙箱暖池，单节点部署则使用基础快照；前者预留热资源，后者避免持续保留一批已启动实例。Perplexity 报告称，生产环境创建延迟的中位数从旧提供方的 185 毫秒降至 60 毫秒，创建延迟的第 90 百分位从 447 毫秒降至 89 毫秒。快速创建不是免费的抽象能力，而是由预热、快照和资源回收策略共同换来的。
红队测试暴露了另一条边界
Perplexity 的测试把“逃出虚拟机”和“绕过网络策略”分开衡量。团队让九个模型在来宾系统内拥有 root 权限，围绕两项任务、四种设置进行了 216 次运行；其中 108 次针对虚拟机逃逸，没有一次触及宿主机侧的秘密。无网络设置下，54 次尝试也没有成功绕过限制。
但在部分网络开放的 54 次运行中，修复前有 11 次绕过出站策略，四个模型找到了路径。攻击利用了 DNS 欺骗和共享 CDN IP 地址。Perplexity 随后加入基于 nftables 的源地址校验，并让网关终止 TLS，再同时核对 SNI 与 HTTP Host 是否符合允许列表；复测中没有模型产生经验证的绕过。这个结果说明，微型虚拟机可以把宿主机隔在来宾之外，却不能自动证明网络出口规则没有漏洞。
部署前要分别验收两种安全性
Perplexity 称 Perplexity Computer 的全部会话都运行在 SPACE 上，并把它定位为生产环境验证过的隔离层。但“在自家产品中使用”与“对所有工作负载都安全”不是同一个结论。报告还提到，对十个第三方平台的测试中，八个平台至少出现过一种网络策略绕过，并已向受影响厂商披露；材料没有提供足以让读者逐一比较这些平台的测试细节，因此不应把这个比例当成通用基准。
对技术负责人来说，可执行的判断是把来宾隔离与出站控制列成两项独立验收：验证高权限任务无法触达宿主机，再针对 DNS、共享 IP、TLS 与主机名校验测试允许列表是否能被绕过。部署 SPACE 还需要 Linux x86_64、KVM、/dev/kvm、btrfs 和 Docker，支持本地 Kind（Kubernetes）或直接运行，不支持 macOS。它提供了一条可自托管的路线，但不会替团队决定哪些凭据能被代理、哪些目标可访问，也不能免去随着策略和依赖变化而复测的责任。