Perplexity 详解 AI Agent 沙箱的有状态系统设计

AI agent 沙箱看起来已是已解决的问题。毕竟，像 Firecracker 这样的项目——AWS 为其 Lambda 服务打造的开源微虚拟机技术——开箱即用就能提供强隔离，而且越来越多初创公司都在销售面向 agent 工作负载的托管沙箱。

不过，Perplexity 决定回到原点，因为团队相信隔离实际上并不是主要难题所在。

7 月 15 日，该公司推出了 SPACE，一个现在为其知识工作 agent 平台 Computer 提供底层支撑的沙箱平台。

在接受 The New Stack 采访时，Perplexity 基础设施副总裁 Nate Kupp 表示，真正的工程挑战在于状态管理——即暂停、恢复和分叉可能运行数天乃至数周的 agent 会话——跨越 Perplexity 用户为使用 Computer AI 助手而启动的数百万个沙箱。

Kupp 说："我们一直在反思的是，认识到我们的需求和我们规模的 agent 系统的需求，与现有参与者的情况大不相同。"

他说，团队希望 agent 能够"暂停、恢复并运行任务，不仅仅是数小时，而是数天乃至数周"，这些会话作为持久耐用的工件保留下来。

状态是困难所在

重要的是，SPACE 并未试图重新发明堆栈的最低层。Kupp 说，团队以 Firecracker 为核心构建块，使用 Kubernetes 进行云部署，从一开始就将跨环境可移植性——从云到本地数据中心再到笔记本电脑——作为设计目标。

大部分工作实际上位于这些微虚拟机上方的控制平面。Kupp 说，当 Computer 的 agent 框架将上下文引入沙箱时，系统必须快速暂停和恢复会话，在其他集群上重新启动它们，并保持它们的"可移植性和可分叉性，这样我们就可以分支出去，在不同方向运行不同的线程"。

支撑这一切的基础是 Btrfs——Linux 的 copy-on-write 文件系统，它使快照和分叉成为廉价的元数据操作，而非完整复制。Kupp 说，"这对我们取得的许多性能收益至关重要"，并且"对于 SPACE 构建所围绕的暂停、恢复、快照和分叉操作来说是非常自然的选择"。他说："我们做了一些早期原型，很快就发现这样的选择完美匹配，然后就一直沿用至今。"

在此基础上是公司发布帖子所描述的完整会话状态的滚动快照，包括实时内存。这些快照可能每分钟发生一次，一个会话可以回溯到一周之前。

Kupp 说，与现有供应商相比，"我们在所有关心的性能指标上都看到了 3 倍或更高的加速，此外成本也有了相当显著的改进。"他说，团队还在尾部延迟上投入了大量精力，调优 P95 和 P99 保证，因为沙箱性能直接影响用户的关键路径。

Kupp 说，"有状态系统极其难以构建"，指的是 Perplexity 在运行数百万个沙箱的同时必须达到的持久性和正常运行时间保证。

控制旋钮，而非权衡

在安全与性能的权衡问题上，Kupp 主张"这与其说是权衡，不如说是我们必须思考在哪里为客户设置控制旋钮"。由于每位客户都会将 Computer 接入 Salesforce、Slack、Snowflake 等各种数据源的不同组合，每种都有各自的风险档案。

除了他所说的 RBAC 和其他核心企业功能的"基本条件"工作外，Kupp 说团队专注于 agent 安全，包括为下游系统配置即时访问权限和在单个工具调用级别设置控制。

他说，管理员可以禁止任何写入访问，使 agent 根本无法写入业务系统，这是一种硬的、平台级的限制，而不是依赖模型行为的东西。Computer 还会标记敏感操作并提请用户批准。SPACE 目前还未使用硬件支持的机密计算，不过 Kupp 指出公司在整个堆栈中都与 Nvidia 密切合作。

目前，SPACE 的沙箱基本上是同构的，是为 Computer 工作负载调优的单一标准大小。这会改变，Kupp 说，因为"我们将把这个作为一个 API 产品提供"，对于更异构的外部工作负载具有沙箱大小调整的灵活性。

Perplexity 已在 3 月份宣布了一个更小范围的 Sandbox API，一项为 agent 构建的代码执行服务，基于 Kubernetes pod 而不是微虚拟机，随后会有私人 beta。公司还表示 Computer 很快将能在第三方沙箱上工作，而不仅仅是 SPACE。Kupp 说："我们在堆栈的每个级别都思考过这些扩展点，从沙箱层到 API 和 MCP。"

Kupp 也在审视堆栈下层，即本地和混合部署。他说，Perplexity 一直在与 Nvidia 合作其 RTX Spark 平台以处理本地 AI 工作负载，目的是将编排能力下沉到笔记本电脑。

公司最近发布了 Computer 新编排器模型的研究预览：GLM 5.2 的一个版本，这是一个开源中文模型，经过针对其框架的后续训练。

Kupp 说它的成本是"某些前沿模型的三分之一"。他解释说，最终的状态应该是一个编排器，能够根据经济合理性将工作路由到任何地方。"你可以在本地运行它。你也可以在云端远程运行它。"

这个路由问题即将与一个更大的问题相碰撞。Kupp 说，随着 agent 承担越来越多的工作，"我们真的会看到 GPU 和 CPU 的约束"，这转变了迄今为止几乎完全围绕 GPU 稀缺性的对话。如果 agent 会话继续从数小时延伸到数周，那么托管这些会话的 CPU 集群以及保持这些会话存活的状态机制，开始看起来不再像是基础设施，而更像是行业下一个的容量争夺战。