Perplexity 开源沙箱平台 SPACE，延迟降至 60ms 却撕开网络治理盲区

自主编写并执行代码正在成为智能体（AI Agent）的核心能力，而如何安全、廉价且极速地运行不受信任的代码，则是基础设施层最大的瓶颈。Perplexity 近日正式开源了其内部支撑 Perplexity Computer 功能的沙箱基础设施平台 SPACE（Sandboxed Platform for Agentic Code Execution）。

SPACE 在 GitHub 采用 Apache 2.0 协议开放，主要使用 Rust 开发，依托 AWS 开源的轻量级虚拟化引擎 Firecracker 构建，通过 HTTP API 与 Server-Sent Events（SSE）管理沙箱实例与实时命令流。在 Perplexity 的生产流量测试中，平台将沙箱创建的中位延迟（p50）从前供应商的 185ms 降至 60ms，降幅达 3.1 倍；p90 延迟更从 447ms 降至 89ms，缩短了整整 5.0 倍。但这项亮眼工程开源的背后，并不意味着开发者拉取代码就能一劳永逸。

60 毫秒背后的调度真相与架构成色

开发团队很容易将 60ms 的性能飞跃归功于底层的微虚拟机。然而 Firecracker MicroVM 本身虽具备毫秒级启动特性，但纯粹的裸机冷启动很难在复杂业务流中保持如此低的尾部延迟。Perplexity 真正解决的是应用层池化与调度开销。

系统深度整合了写时复制（Btrfs CoW）分支能力与完整的虚拟机内存检查点挂起、恢复机制。官方披露的 60ms 延迟，源于其生产环境中包含热池（Warm Pool）预分配与快照瞬间复活的混合调度设计。不过，官方至今未公开单沙箱的实际内存驻留（RSS）和极限密度跑分，这意味着该方案在大规模并发下对物理机内存的压榨程度仍有待独立验证。

截至 2026 年 10 月 17 日，SPACE 在代码仓库中并未发布正式打包的 Release，仅将 0.8.0 作为公开基线版本。此外，社区已经发现其依赖项中存在针对 unsafe-libyaml（RUSTSEC-2024-0449）的安全告警，暴露出这一平台仍处于从内部系统走向通用开源的早期磨合阶段。

堡垒未破，沙箱的安全死穴移向网关

业内防范不受信任代码的传统思路，主要聚焦在防止容器穿透宿主机内核。在这类硬件级隔离测试中，SPACE 的防线表现稳固：在官方披露的 108 次针对宿主机的 VM 逃逸测试中，成功率为 0；在完全阻断外网的环境下，网络绕过成功率同样为 0/54。

决定智能体安全边界的往往不是底层的虚拟化内核，而是放开外网时的网络代理策略。

真正的隐患发生在开放部分外网访问的真实业务场景中。官方测试记录显示，其早期外网网关曾暴露出基于 DNS 欺骗和共享公网 IP 路由的出口策略（Egress）绕过漏洞。智能体不需要突破虚拟机本身，只需利用网关对动态域名解析的信任缺陷，就能将受控数据外发。尽管官方表示已修复该问题，但项目文档指出了另一项关键机制限制：运行中的沙箱不支持动态刷新策略，挂起、恢复与分支均保留旧的网络策略，且出口策略采用权限叠加逻辑。

• 风险.智能体在沙箱内获取代码执行权后，网络平面与凭据注入机制才是最容易失守的高危地带。

托管服务的每小时几毛钱，对比自建的运维泥潭

SPACE 的开源为需要高频执行多租户代码的团队提供了一套架构范本，但在选型上，它并不是即下即用的 Docker 替代品。

部署 SPACE 有着严苛的基础设施前提：必须运行在 Linux x86_64 环境上，依赖底层 KVM 虚拟化权限、btrfs 文件系统、Docker 以及本地 Kubernetes Kind 集群。一套完整的自建方案，对计算节点底座与底层存储驱动有深度绑定。

对于中小开发团队而言，E2B 和 Daytona 这类托管沙箱服务大约只需每小时 0.1656 美元，即可省去维护复杂内核与存储栈的工程代价。SPACE 真正争夺的受众，是那些代码吞吐量达到临界点、受制于外部 API 延迟瓶颈，且具备底层内核维护能力的中大型工程团队。

• 建议.在日均代码执行量未形成规模前，优先采用托管沙箱；只有当调度延迟和账单成本成为产品核心瓶颈时，再考虑接盘复杂的虚拟化自建底座。