六月的一天，Perplexity Computer的生产流量突然全部切到了新沙箱SPACE上——没有任何公告，没有灰度期。
一、为什么Agent需要专属沙箱
传统沙箱的致命局限：为代码而生，不为Session设计
传统沙箱的设计哲学很简单：跑一段代码，输出结果，销毁环境。容器、Docker、甚至Firecracker最初都是这个思路。它们擅长的是「短生命周期任务」——一个请求进来，执行完，释放资源。这在LLM推理场景里足够用。但Agent的工作模式完全不同。
Agent需要连续运行数小时甚至数天。它要读取文件、编辑文件、调用外部API、保存中间状态、在会话中断后继续。更复杂的是，Agent在执行过程中可能需要暂停、恢复，甚至从一个检查点分支出多个并行任务——一个经典场景是同时跑两份相似的实验，只是参数略有不同。传统沙箱没有「暂停」这个概念，只有「运行」和「死亡」。
「Agent跑得越久，沙箱越难受——这是所有做长期任务的人都会撞上的墙。」
这个墙体现在三个层面。第一，状态丢失。容器重启后，内存里的临时变量、未保存的文件编辑、进程间的连接全部消失。第二，权限膨胀。为了让Agent能跑任意命令，很多团队直接把root权限开足，等于给恶意代码敞开门。第三，成本失控。每个Agent任务都重新拉取基础镜像、安装依赖，而不是复用已有的工作负载。
长运行任务的三个核心矛盾
第一个矛盾是持久性 vs 隔离性。用户希望Agent的工作成果在沙箱销毁后依然保留，但沙箱的核心价值恰恰在于销毁时不留痕迹。这两个目标天然冲突。如果每次都在沙箱内持久化文件，那沙箱就和普通服务器没区别，隔离形同虚设。
第二个矛盾是快速启动 vs 完整环境。Agent任务要求沙箱几秒内就绪，但完整的开发环境（Python依赖、系统工具、浏览器）通常要几分钟才能装好。传统做法是预装镜像，但镜像越大，冷启动越慢；镜像越小，到达某个特定状态就越不可靠。
第三个矛盾是多任务复用 vs 单任务独占。理想情况下，同一个基础镜像应该被多个Agent任务共享以节省资源，但每个任务又有独立的文件系统和安全边界，不能互相干扰。这个矛盾在并发量上来之后特别尖锐——几万个Agent同时在跑，沙箱层必须做出取舍。
Agent基础设施的底层摩擦
Perplexity Computer面对的就是这三个矛盾的集中爆发。它的用户不只是发一条消息，而是在沙箱里写代码、跑脚本、编辑文件、部署服务，整个过程可能持续数小时。沙箱一旦崩溃，用户几小时的进度全丢。这就是为什么他们决定自己做一套专门为Agent设计的沙箱平台，而不是在现有方案上打补丁。
二、SPACE的架构选择
系统架构重构现场
Firecracker microVM：轻量隔离的代价与收益
传统沙箱的问题在于它们是为代码执行设计的，不是为长期会话设计的。Docker容器适合跑一下脚本，Jupyter Notebook适合交互式开发，但都不适合一个Agent连续跑几小时甚至几天的场景。
Agent在工作时需要持久化的文件系统、需要跨步骤的状态保持、需要随时暂停和恢复的能力。而代码执行环境只需要临时隔离——跑完就销毁。这是两套完全不同的需求。
Perplexity选择了Firecracker microVM。Firecracker是AWS开发的一个轻量级虚拟化技术，专门用于构建安全的容器实例。它比传统虚拟机轻量得多，启动速度在毫秒级，资源占用也小很多。每个Agent任务都会获得一个独立的Firecracker微虚拟机，任务完成后直接销毁。
这不是一个随便的决定。Firecracker的优势在于隔离性强、启动快、资源开销低。代价是它本质上是一个完整的虚拟机，而不是容器，所以某些需要细粒度控制的场景不如容器灵活。但对Perplexity来说，Agent需要的正是这种「用完即弃」的隔离模式。
架构选型评审现场
关键取舍在于：隔离程度 vs 资源效率。传统容器共享宿主机内核，资源开销小，但隔离弱；全量虚拟机隔离强，但启动慢、资源重。Firecracker走的是中间路线——用轻量级 hypervisor 实现近似虚拟机的隔离，同时保持接近容器的启动速度和资源效率。
对长运行Agent来说，这种选择是正确的。因为Agent运行的时间越长，安全隔离的需求就越重要——你不能让一个Agent在处理用户数据时，被同机其他进程的恶意代码影响。而微VM的轻量性又保证了高并发场景下的可扩展性。
滚动快照机制：如何做到暂停不丢状态
Agent跑得越久，沙箱越难受。这是所有做长期任务的人都会撞上的墙。
想象一下你的Agent正在执行一个复杂任务：浏览网页、读写文件、调用外部API、逐步完成任务。跑了三个小时后，网络断了，或者用户突然想把任务分支出去，或者你想把当前进度保存下来等明天继续。
传统方案要么不保存状态，要么把整个VM内存dump下来——前者丢了工作，后者太重。
Perplexity的滚动快照机制解决了这个问题。它不是在某个时刻把整个状态冻结，而是持续地、增量地把内存和文件系统的变化记录下来。你可以随时暂停、恢复，甚至把某个时间点的状态分支出来，启动多个并行任务。
Agent长运行状态保持
``mermaid
SPACE 滚动快照工作流程
机制的核心是增量记录。每一次内存页面变化和文件写入操作都被追踪，然后压缩存储到快照层。恢复时只需要加载最新的全量基线，再按顺序应用增量变更记录，就能重建出任意时间点的状态。
这带来了一个关键能力：Session和沙箱解耦。你可以创建一个Agent Session，它对应一个逻辑上的任务流，但这个Session可以运行在不同的沙箱实例上。你可以在某个沙箱里暂停任务，把状态分支出来，同时在另一个沙箱里基于同一个历史状态继续执行不同的路径。
架构设计获内部认可
这种设计对多步骤Agent特别有用。假设你在让Computer帮你完成一个复杂的项目——它可能需要先研究背景，再写草稿，最后润色。如果中途你想让两个不同的Agent实例分别从「写完草稿」这个状态开始，尝试不同的润色策略，你可以直接分支，而不需要重新从头开始。
Session与沙箱解耦：分支、恢复、重连的设计逻辑
Session是什么？在传统的沙箱模型里，Session和沙箱是绑定的。你创建一个沙箱，它就代表一个Session。沙箱销毁，Session结束。
Perplexity把这个关系拆开了。Session是一个逻辑概念，代表用户发起的一个任务流，包含上下文、文件、进度、工具调用记录等。沙箱是一个物理概念，是实际执行代码的隔离环境。
``mermaid
Session 与沙箱分离架构
这种分离带来的第一个好处是可分支性。你可以在任何时间点把当前Session的状态保存为一个快照，然后基于这个快照创建多个分支，每个分支独立运行，互不影响。
第二个好处是可恢复性。沙箱可能会因为各种原因崩溃——OOM、网络中断、系统错误。如果Session和沙箱绑死，沙箱挂了Session就没了，用户的所有工作都白费。但在SPACE里，Session状态独立于沙箱存在，沙箱挂了可以换一个沙箱重新加载Session，用户几乎无感。
第三个好处是可迁移性。任务可以在不同机器、不同区域之间迁移。一个用户在亚洲启动的任务，如果他的Session被转移到一个欧美区域的新沙箱，他只需要重连，不需要重新开始。
工程师的优雅设计
这种设计的代价是复杂度上升。你需要一个可靠的持久化层来存储Session状态，需要一个高效的快照复制机制，需要处理跨沙箱的状态一致性。但对Perplexity来说，这些复杂度换来的是Agent体验的根本性提升——用户可以真正信任一个Agent「放心跑，跑多久我都接得住」。
三、性能优化路径
从185ms到60ms：冷启动为什么能压得这么低
从185ms降到60ms，这不仅仅是优化，这是对底层基础设施的重写。冷启动延迟的每一个组成部分都有优化的空间：镜像加载、设备初始化、内存分配、网络配置。
Perplexity做的核心优化是预加载和缓存。对于常用的基础镜像和运行时环境，他们在宿主机层面做了热缓存，新沙箱创建时直接复用，而不是每次都从存储层加载完整镜像。此外，他们还对Firecracker本身的初始化路径做了裁剪——移除了Agent实际用不到的硬件模拟，只保留必要的虚拟设备。
数字本身说明了一切：中位延迟185ms到60ms，降幅超过67%。P90从447ms到89ms，降幅更夸张——超过80%。这意味着不仅平均值改善了，极端情况下的用户体验也大幅提升。对于一个用户等待「打开一个Agent会话」的场景来说，89ms的P90延迟几乎是感知不到的，而原来的447ms会让人明显感到卡顿。
流量峰值下的容错设计
Space在上线一周内承载了数百万次沙箱创建和数千万次重连操作。这对基础设施的容错能力提出了极高要求。
Perplexity的容错设计体现在几个层面。首先是沙箱级别——单个沙箱崩溃不会影响其他沙箱，也不会影响Session状态，因为Session数据持久化在独立的存储层。
其次是宿主机级别——一台宿主机故障只会影响其上的少量沙箱，系统会自动将这些沙箱迁移到其他健康的节点，同时保持Session状态的连续性。
第三是平台级别——即使整个数据中心出现问题，系统也能在其他可用区域无缝接管，用户感知的只是短暂的断连，而不是任务的丢失。
这种分层容错设计保证了系统的整体可靠性。对于长运行Agent来说，最重要的不是单个组件不出错——这是不可能的——而是出错后能快速恢复，且不损失用户的工作成果。
四、开源前后的关键取舍
什么决定保留，什么决定开源
开源从来不是一个简单的「是或否」的问题。Perplexity在决定将SPACE开源之前，必然经过了严格的评估。哪些组件可以公开，哪些需要保留私有，这需要从安全、竞争、维护成本三个维度来权衡。
从公开资料来看，Perplexity选择开源的是SPACE的核心框架和接口定义，而不是全部实现细节。这种做法既释放了社区价值——其他团队可以参考它的设计思路，又可以保护自己的核心差异化能力——具体的生产部署经验、优化技巧、与内部系统的集成逻辑。
开源的另一个关键考量是维护成本。开源项目不是「开了就完了」，需要持续的issue响应、PR审查、版本管理。Perplexity显然对这一点有清醒认识，所以开源的范围是精心设计的——既能产生生态价值，又不会成为维护负担。
生态之外的竞争对手视角
对于其他AI公司来说，Perplexity开源SPACE是一个重要的信号。它表明：第一，长运行Agent的沙箱管理是一个已经成熟的工程问题，有现成的解决方案；第二，这个领域的最佳实践正在走向标准化；第三，未来可能有更多围绕Agent沙箱的开源工具和云服务出现。
但对于Perplexity自己来说，开源不等于放弃优势。相反，开源可能是巩固优势的一种方式——当更多人用SPACE的架构，当生态围绕它发展，当最佳实践在社区中沉淀，Perplexity作为先发者和主要贡献者，自然处于更有利的位置。
五、我们能学到什么
架构不是选最炫的，是选最稳的
Perplexity的SPACE选择Firecracker而不是更炫酷的方案，选择增量快照而不是全量dump，选择Session和沙箱解耦而不是紧绑定——这些决策背后都有一个共同的原则：稳定性优先于创新性。
在Agent基础设施这个新兴领域，很容易陷入一个陷阱：因为技术新，所以要用最新、最炫的技术栈。但实际上，Agent要跑的是用户的真实任务，任何一个环节的故障都可能造成严重的后果。稳定的基础架构不是靠追逐新技术实现的，而是靠精心选择已经被验证的组件，并在关键路径上做充足的容错设计。
关于Agent沙箱的下一步建议
如果你在考虑为自己的Agent系统设计沙箱方案，有三个可执行的建议。
第一，不要重复造轮子。Firecracker、Kubernetes、现有的容器编排方案都有成熟的沙箱能力，先评估能不能复用，再考虑要不要自建。Perplexity的选择是自建，但这是在已有成熟方案无法满足其特定需求的情况下做出的决定。
第二，Session和沙箱分离。这是SPACE最核心的架构洞察之一。不管你用什么技术实现隔离，都要确保任务状态独立于执行环境存在。这是长运行Agent能够稳定工作的基础。
第三，性能指标要量化到毫秒级。185ms到60ms的优化看起来不多，但对用户体验的影响是巨大的。如果你的Agent用户等待沙箱创建超过100ms，他们会明显感知到卡顿，甚至开始怀疑系统的可靠性。设定明确的SLA，持续监控，持续优化。
Agent跑得越久，沙箱越难受——这是所有做长期任务的人都会撞上的墙。但解决这个问题的关键不是堆砌功能，而是回到基础设施的基本原理：隔离要够强，恢复要够快，状态要够稳。SPACE用10周时间证明了这一点：从概念到100%生产流量，这就是工程师文化的极限测试。
参考文献
- Perplexity AI on X: "Introducing SPACE, the sandbox platform behind Perplexity Computer." https://x.com/perplexity_ai/status/2077432518081744979
- Perplexity blog: "Making SPACE: Secure Runtimes for Long-Running Agents." https://www.perplexity.ai/hub/blog/making-space-secure-and-efficient-runtimes-for-long-running-agents
- Perplexity blog: "Secure Sandboxes for Agents." https://www.perplexity.ai/hub/blog/secure-sandboxes-for-agents
- Perplexity blog: "Open-sourcing SPACE, the sandbox platform behind Computer." https://www.perplexity.ai/hub/blog/open-sourcing-space
如果浏览器无法直接唤起微信，可在微信内打开公众号主页：计算机魔术师
