Perplexity 开源智能体沙箱 SPACE：每个任务一台 Firecracker 微虚拟机，9 个模型 108 次越狱尝试均未逃到宿主机

设计要点：智能体在沙箱内拥有 root 权限，可以跑命令、装包、调外部服务，但宿主机不受其控制；每个沙箱配一个独立网关，对每条出站连接执行出口策略。沙箱的生命周期独立于创建它的请求和输出连接，可以暂停、分叉，或连同内存和磁盘快照挂起、之后原地唤醒，适合长时间、有状态、会分支的智能体任务。项目用 Rust 编写，应用通过 HTTP API 和 SSE 调用，不必嵌入 Rust 库。

红队结果：Perplexity 同步发布《Escaping SPACE: Part I》，让 9 个模型配置在虚拟机内拿 root，尝试窃取宿主机侧密钥或访问被封锁的地址。108 次逃逸尝试无一突破虚拟机-宿主机边界，即便模型能看 SPACE 源码、装软件、联网搜索；完全断网的 54 次测试也无一绕过网络策略。但在只放行少数软件包仓库的「部分联网」场景下，修复前有 4 个模型在 54 次中成功 11 次，手法是 DNS 欺骗或共享 IP 路由。Perplexity 也强调，没观察到逃逸不等于证明了隔离。

谁能用：代码免费开源（github.com/perplexityai/SPACE），可商用；官方文档提供在本地 Kind 集群部署的流程和 AWS EKS 参考部署，也说明了脱离 Kubernetes 运行的方式；附带 E2B 兼容层，可用经测试的 E2B Python SDK 对接。Perplexity 未宣布托管版 SPACE 服务或定价；Perplexity Computer 用户的任务本身已跑在 SPACE 上。截至发稿 GitHub 约 43 星。

解读：让智能体「随便跑代码」已经成了 AI 产品标配，隔离做不好就是安全事故。Perplexity 把生产在用的沙箱开源，还附上用前沿模型攻击自家沙箱的结果，比一句「我们很安全」有说服力；而「部分联网时 4 个模型找到绕过方法」这一条，恰好提醒所有做智能体产品的团队：真正难守的是网络白名单，而不是虚拟机。讨论：1. 自建 SPACE 和直接用 E2B 等托管沙箱，你的团队会怎么选？2. 「用 AI 攻击 AI 沙箱」会不会成为智能体基础设施上线前的标准测试？