Perplexity 把自家 Agent 运行时的隔离层拿了出来。
发生了什么
Perplexity 开源了 SPACE——支撑 Perplexity Computer 中每一个任务的沙箱平台，代码以 Apache 2.0 协议发布在 GitHub 上。其核心设计是：每个 Agent 任务独占一台 Firecracker microVM；凭证管理与出站网络流量都不在虚拟机内部处理，而是由 VM 之外的控制层统一接管。官方将其定位为经过生产验证的隔离方案，面向构建编码类、浏览类 Agent 的团队。
为什么重要
Agent 落地的瓶颈早已不是模型能力，而是「让它动手」之后的风险敞口。一个能执行 shell、能访问网页、能调用外部 API 的 Agent，本质上是在你的基础设施里跑一段来源不可控的代码。容器共享内核，隔离强度不足以应对提示注入导致的任意命令执行；传统虚拟机启动慢、开销大，难以做到一任务一实例。Firecracker 正是为这个夹缝设计的：轻量 microVM，保留硬件虚拟化级别的隔离边界，同时把启动开销压到可接受范围。
更值得关注的是 SPACE 把凭证和出站流量挪到 VM 之外。这意味着即使 Agent 在沙箱内被诱导执行恶意操作，它手里也没有可直接滥用的长期密钥，外联行为还要经过外部策略层。这是把「假设沙箱会被攻破」写进架构的做法，而不是把安全性寄托在模型不被骗上。
影响与看点
对开发者而言，SPACE 补上了一块长期缺失的基础设施拼图。此前做编码 Agent 的团队大多自建隔离方案，要么用容器加 seccomp 勉强凑合，要么直接在生产环境上冒险；现在有了一个可参考、可复用的生产级实现，自研成本显著下降。对行业而言，这延续了 Agent 基础设施开源化的趋势——运行时、沙箱、工具调用协议正在被逐层标准化，竞争焦点向 Agent 的策略与产品体验上移。
需要冷静看待的是：开源的是隔离机制，不是安全保证。策略配置、凭证轮换、出站白名单的具体规则仍取决于使用方，配置不当的沙箱和没有沙箱差别不大。另外，Firecracker 依赖 KVM，对宿主环境有前提要求，并非所有部署场景都能直接套用。
一个独立判断：Agent 安全正在从「提示词层面的防御」转向「系统层面的默认不信任」。SPACE 的价值不在于它多先进，而在于它把这种默认不信任做成了可以直接拿来用的工程件。
