Perplexity SPACE 沙盒开源，但生产规模仍是考验

Perplexity 已将其 SPACE 沙盒开源，尽管该公司认为，可靠的智能体基础设施仍依赖于艰难的生产环境实践。Perplexity SPACE 沙盒提供隔离的计算机环境，让 Perplexity Computer 能够执行代码，而不会暴露周边系统。因此，这次发布的意义远超一次常规的源代码公开。

CEO Aravind Srinivas 于 2026 年 10 月 19 日宣布了这一发布，并称沙盒本身已成为一种商品化能力。不过，他在发布帖文中也区分了创建一个沙盒与运营数百万个沙盒之间的差别。Perplexity 表示，SPACE 支持 Computer 所使用的沙盒能力，但这一规模说法尚未得到独立验证。

因此，矛盾并不在于开源与闭源之争，而在于自托管基础设施与由运营经验支撑的托管执行服务之间的较量。E2B 及其他沙盒提供商如今面对一个可信的开放替代方案，而 Perplexity 则必须证明，公开代码能够转移有意义的生产经验。

Perplexity SPACE 沙盒开放执行层

Perplexity 公开的是为其智能体提供隔离工作空间的底层机制，而非完整的 Perplexity Computer 产品。

SPACE 是 Sandboxed Platform for Agentic Code Execution 的缩写。其公开的 SPACE repository将其描述为一个平台，可在隔离的 Firecracker microVM 中运行智能体或用户代码。

microVM 是一种小型虚拟机，其启动开销低于传统服务器虚拟机。它为每项工作负载提供独立的内核边界，通常能提供比标准共享内核容器更强的隔离性。

应用程序通过 HTTP API 与 SPACE 通信。它们可以创建 Linux 环境、启动命令、接收输出、保留环境、暂停环境、唤醒环境或删除环境。

这一生命周期很重要，因为智能体很少只执行一条命令后便消失。研究或编程工作流可能会安装软件包、创建文件、运行程序、检查错误，然后再次尝试。

SPACE 将这些相关操作保留在同一个可写环境中。应用程序控制智能体尝试执行的内容，而平台则负责管理机器、进程及输出连接。

该项目主要以 Rust 编写，但客户端无需嵌入 Rust 库。它们通过 HTTP 进行交互，并通过服务器发送事件接收实时命令输出；这是一种标准的单向流式传输机制。

Perplexity 以 Apache License 2.0 发布该代码库。该许可证允许商业使用、修改和再分发，但须遵守许可条件。

该代码库远不止一个演示封装。它包含服务组件、API 定义、Firecracker 模板、冒烟测试、本地 Kubernetes 配置以及 AWS 参考部署方案。

其公开文档还涵盖预热池、快照、生命周期恢复、可观测性、出站网络策略和兼容性行为。这些都是团队超越基础代码运行器后才会出现的运营问题。

审阅时，该项目已获得约 1,600 个 GitHub stars 和 132 个 forks。这些数据表明开发者早期关注度较高，但不能证明其已被用于生产环境，也无法证明其安全质量。

Perplexity Computer 仍是一个独立的、更高层级的产品。该公司将 Computer 描述为一个编排器，能够研究、分析、创作、编程，并协调跨工具的长流程工作。

其官方 Computer overview称，该产品可在超过 20 个模型之间路由任务。SPACE 服务于该工作流部分环节下方的执行环境，而非其规划、模型路由、连接器或用户界面。

这种区别避免了一个容易产生的误解。安装 SPACE 并不能复现 Perplexity Computer。它为开发者提供了一层基础设施，可在其上构建自己的代码执行智能体和工作空间。

此次发布形成了文章的核心张力，因为基础设施代码只是运营平台的一部分。部署规范、容量规划、事故响应、安全审查和支持服务仍然不在 Git clone 之内。

Perplexity 为何此时开放 SPACE

此次发布将 Perplexity 的内部执行架构转化为一项公开的标准制定行动，而智能体平台仍在选择自己的基础设施。

AI 智能体日益需要完成的不仅是返回文本。它们会生成程序、转换文件、测试软件、分析数据集，并创建需要真实运行环境的产物。

在应用服务器上运行这些工作会带来显而易见的风险。模型生成的命令可能删除文件、消耗资源、查看机密信息，或发出非预期的网络请求。

一次性沙盒会将智能体的执行环境与周边服务隔离开来。如果任务失败，运营方可以销毁该环境，而无需重建主应用程序。

这一基本理念并不新鲜。变化在于智能体操作的频率和多样性。生产服务可能需要创建大量隔离环境、流式传输输出、从故障中恢复、实施限制，并持续回收容量。

Srinivas 直接阐述了这一区别。他在公告中称沙盒已商品化，同时认为，在生产流量下提供这类服务，需要在许多微小细节上进行审慎工作。

这一说法同时从两个方向定位了 SPACE。Perplexity 一边降低拥有基础设施的门槛，一边将其运营历史作为值得信任该设计的理由。

开源也让 Perplexity 能够影响开发者如何将智能体接入算力。即使许多用户选择托管服务而不是自托管，获得广泛采用的 API 依然可能意义重大。

SPACE 包含一个 E2B 兼容组件，这一点尤其值得关注。兼容性降低了已基于成熟沙盒接口编写的应用程序的迁移阻力。

这种方式会对专业服务商施加压力。开发者可以考虑自行运行 SPACE，为私有基础设施改造它，或将其接口作为替代后端。

压力并不仅限于 E2B。Modal、Cloudflare、Daytona 以及通用云平台，均通过不同的抽象方式解决远程执行问题的部分需求。

有些强调托管式开发者体验。另一些则强调通用无服务器计算、地理分布、持久工作空间或部署灵活性。

Perplexity 凭借不同的资质进入这一领域。该公司表示，SPACE 支撑着一款面向消费者和企业的智能体产品的执行需求，而非仅作为独立基础设施服务存在。

这种与生产环境的关联让 SPACE 立即获得关注。但它也提高了证明标准，因为开发者会将公开项目与 Perplexity 对其内部运营的说法进行比较。

此次发布也有利于评估智能体系统的企业买家。他们可以检查架构、审查数据路径、测试出站网络限制，并考虑在自身环境内部署。

检查并不能消除风险。但它为安全团队提供了可评估的具体实现，而不是完全依赖产品描述。

对于 Perplexity 而言，外部贡献者可以发现缺陷、增加部署模式并扩大兼容性。公开开发也可能让 SPACE 作为共享基础设施而非专有依赖更具可信度。

这项战略押注十分明确。Perplexity 希望执行层变得开放且可替换，同时将产品差异化保留在编排、模型、界面、数据访问和运营能力上。

如果这种划分得以维持，开放 SPACE 不会削弱 Computer 的优势。它将扩大围绕 Perplexity 已在使用的架构进行构建的开发者数量。

如果无法维持，竞争对手便可获得 Perplexity 技术栈中有意义的一部分，却无需承担开发它的成本。因此，运营能力的转移质量决定了此次发布带来的是杠杆效应还是能力外泄。

Perplexity SPACE 如何在 Computer 之下运作

SPACE 将控制决策与命令执行分离，使智能体拥有持久环境，同时不将每条命令都视为一台新机器。

SPACE 部署从模板开始。模板定义了创建沙盒实例时所依据的初始环境。

每个沙盒都会获得自己的虚拟机和可写文件系统。随后，多个命令可以在同一环境中运行，在步骤之间保留文件和已安装的依赖项。

这种持久性支持更真实的智能体行为。智能体可以生成项目、安装依赖项、运行测试、检查失败原因、修改文件，然后再次运行测试。

应用程序首先通过控制 API 请求一个沙盒。生命周期变更是异步的，因此 API 会返回一个操作标识符，客户端可持续检查该标识符，直至操作完成。

这一模式避免了长时间的基础设施工作阻塞单个请求。它也让客户端能够以更清晰的方式重试或检查未完成的操作。

命令执行采用会话模型。应用程序创建命令会话、附加至会话、启动进程，并接收输出及最终退出结果。

输出通过使用会话专属附加令牌的独立数据平面连接传输。这种分离减少了进程输出客户端可获得的凭据范围。

除了简单的创建和删除，SPACE 还暴露了多个状态。根据对就绪速度与资源使用之间权衡的要求，沙盒可以保持活跃、暂停、挂起、恢复或终止。

即使未讨论价格，这些状态在经济层面也很重要。让每个环境始终处于完全活跃状态可以降低延迟，但会在空闲期间消耗更多容量。

关闭所有环境可以节省资源，但会迫使用户等待恢复。生产平台需要制定策略，在众多工作负载之间选择这些结果。

预热池解决了这一问题的一部分。它们会保留已启动、随时可用的环境，使新请求可以避免完整的冷启动。

预热池能够改善响应速度，但也带来了容量问题。运营方必须决定预留多少环境、如何替换不健康的实例，以及如何避免浪费。

SPACE 还记录了基础快照。快照可以恢复预先准备好的文件系统状态，而不必为每项任务重新构建。

当智能体反复需要相同的语言、库或项目设置时，快照十分有用。但它们也会带来必须谨慎处理的版本控制和存储管理责任。

在隔离层，SPACE 默认使用 Firecracker。Amazon Web Services 创建 Firecracker，用于轻量级虚拟化工作负载，包括无服务器函数和容器。

公开的 Firecracker architecture使用 Linux 的基于内核的虚拟机技术来提供硬件辅助隔离。其精简的设备模型旨在限制启动开销和可利用的攻击面。

使用 Firecracker 并不会自动让整个服务变得安全。身份验证、主机配置、镜像来源、网络策略、内核更新、资源限制和租户隔离，仍需正确实施。

SPACE 还通过出口配置文件支持出站网络控制。出口流量是指离开沙箱的流量，例如某条命令下载软件包或联系外部 API。

这对于智能体而言是一个关键的策略层面。即使沙箱无法直接逃逸其虚拟机，拥有不受限制的出站访问权限仍可能传输敏感材料。

运营人员需要制定规则，区分必要的网络活动与危险访问。编程智能体可能需要访问软件包注册表，却没有理由联系内部管理服务。

公开仓库包含使用 Kind 进行本地部署的说明，Kind 通过本地容器运行 Kubernetes 集群。它还包含适用于 Amazon 托管 Kubernetes 服务的参考基础设施。

文档指出，SPACE 无需 Kubernetes 也能运行。这种灵活性扩大了其潜在受众，但也意味着运营人员必须了解哪些保障来自 SPACE，哪些来自周边调度器。

因此，Perplexity SPACE 沙箱代表的是一组相互协调的基础设施决策。微型虚拟机只是其中一个组件。

API 契约、生命周期状态机、预热容量、快照、身份验证、命令流式传输和恢复行为，共同决定系统在真实工作负载下是否仍然可用。

这一机制解释了为何 Srinivas 可以称这一原语为商品化能力，同时又为其运维工作辩护。与在反复故障和波动需求下维持可预测的行为相比，创建一台隔离 VM 要简单得多。

Perplexity SPACE vs E2B：本质上是自托管与托管运维之争

核心竞争并不在于哪个项目能够启动微型 VM，而在于智能体开始使用后，谁来承担运维负担。

E2B 已成为为智能体提供远程环境的常见接口。开发者使用其 SDK 创建沙箱、运行命令、操作文件，并在工具调用之间维持状态。

SPACE 通过其文档化的 E2B 兼容层承认了这一既有用户基础。该包装器允许受支持的 E2B 客户端行为指向 SPACE 部署。

这是务实的竞争举措。团队无需立刻重写智能体应用中的每一次调用，就可以评估 SPACE。

兼容性不代表行为完全一致。各提供商在生命周期语义、限制、网络、持久化、错误处理、可观测性和受支持的 SDK 功能方面都可能不同。

开发者必须测试其智能体实际使用的确切操作。一个基础命令示例无法揭示取消操作、网络中断、并发会话或主机故障下的行为。

Perplexity SPACE 与 E2B 的选择首先关乎所有权。托管平台由提供商负责容量、更新、可用性以及大部分安全边界的运维。

自托管 SPACE 则让采用者对部署、修改、数据位置和网络集成拥有更多控制权，同时也将更多运维责任转移给采用者。

对于小型开发团队而言，托管基础设施可以减少智能体上线前所需的工作。团队只需集成 API，并将重心放在应用本身。

受监管企业可能更倾向于将基础设施部署在获批准的云账户内。它们可以围绕沙箱服务应用既有的身份、日志、网络和合规控制。

没有哪一种选择能在所有情况下胜出。正确路径取决于工作负载敏感性、规模、人员配置、延迟要求，以及对外部服务依赖的容忍度。

即使从不实际部署，开源也会改变团队的议价能力。买方可以评估替代架构，并降低围绕单一专有执行服务进行设计的风险。

Apache 许可证也允许供应商围绕 SPACE 构建商业产品。这可能催生托管部署、企业支持或专用发行版。

如果兼容服务能够保留其接口，这样的生态系统将强化 Perplexity 的地位；若实现出现碎片化或安全修复滞后，则会削弱该项目。

专业供应商仍保有多项优势。托管服务可通过可靠性、地域容量、支持、接入体验、监控，以及更快获得新运行时功能来竞争。

托管提供商还可以隐藏开源项目所暴露的运维复杂性。一个组件繁多的仓库对基础设施团队很有价值，但可能令应用团队望而生畏。

Perplexity 的优势在于其内部相关性的证据。该公司称，该平台支撑了 Computer 背后的沙箱能力，使这一设计拥有一个高要求的参考工作负载。

不过，单靠该仓库无法让外部人士复现或验证这一说法。它没有披露 Perplexity 的集群规模、服务级别结果、区域拓扑、事故记录或基础设施支出。

“数百万个沙箱”这一表述同样需要谨慎解读。它可能指累计创建量、峰值并发数、活跃环境数，或其他内部指标。

这些指标存在实质性差异。长期累计创建数百万个短生命周期沙箱，并不意味着同时运行数百万台虚拟机。

这一验证缺口并不会否定该项目。它只是限制了读者应从该公告中得出的结论。

开发者可以验证公开 API、代码、部署说明和测试。但他们无法仅凭这些产物验证内部生产规模。

因此，最可信的比较将来自独立部署。团队需要衡量创建延迟、故障恢复、命令流式传输、主机利用率，以及面对恶意工作负载时的行为。

他们还应跟踪运营平台的人力成本。一个技术能力出色的系统，如果需要专业基础设施团队持续介入，仍可能不具备经济性。

此次开源发布已经改变了竞争格局，因为它创造了另一种可审查的选择。但它尚未证明 SPACE 能够比托管服务带来更好的运维结果。

开放代码并不能证明生产环境安全性

SPACE 提供了有意义的实现细节，但其公开证据尚不足以验证 Perplexity 关于规模和安全影响的最广泛主张。

智能体沙箱处理的是风险异常高的工作负载。其核心目的，就是执行由模型生成、用户提供或从外部内容组装而成的命令。

这意味着运营人员必须假设某些命令会存在缺陷。他们还必须假设攻击者会故意测试隔离边界。

相较于直接在共享应用主机上运行不受信任的命令，微型 VM 能降低暴露风险，但并不能消除对分层防御的需求。

主机内核、虚拟化组件、存储路径、网络、控制 API 和镜像管道都可能包含漏洞。配置错误也可能削弱原本健全的架构。

该仓库包含私密漏洞报告流程，并声明只有最新的次要版本会获得安全修复。其公开的安全策略显示，截至审查时尚无已发布的安全公告。

没有安全公告，并不代表不存在漏洞。新项目往往需要经历时间、采用和对抗性测试，弱点才会暴露出来。

仅支持最新次要版本的策略也会增加采用者的工作。自托管 SPACE 的团队必须跟踪发布并及时更新，才能保持在受支持的安全窗口内。

生产就绪不止意味着防止 VM 逃逸。运营人员还需要处理租户身份验证、授权、配额、密钥处理、审计记录和可靠清理。

清理失败可能代价高昂或造成危险。被遗弃的沙箱可能继续消耗资源、保留敏感文件，或比预期更久地保存网络凭证。

出站访问同样值得重视。隔离工作负载仍可能通过探测外部系统、下载恶意代码或向攻击者发送数据造成损害。

SPACE 提供了策略机制，但采用者必须自行配置。出口配置文件的存在，并不能保证每个部署都会应用严格的默认设置。

模板和快照又形成了另一层供应链攻击面。受损的基础镜像可能影响从中创建的每一个沙箱。

运营人员需要可复现构建、依赖审查、镜像签名、漏洞扫描和受控的推广流程。开源许可证不会自动提供这些实践。

可观测性也可能暴露竞争性风险。日志和追踪有助于诊断故障，但草率的遥测可能捕获命令内容、文件路径、令牌或用户数据。

团队必须决定记录什么，以及保留多久。企业部署还需要控制谁能够检查智能体活动。

可靠性仍然是另一项不确定因素。沙箱可能在启动、运行、暂停、恢复或流式输出期间失败。

应用必须区分操作延迟与操作失败。它还需要具备幂等重试机制，以避免在响应丢失时创建重复资源。

Perplexity 的文档讨论了恢复和隔离行为，表明该项目处理了这些故障类别。公开基准将让这些能力更易于评估。

当前版本没有提供经过独立审计的吞吐量或可用性数据。它也没有说明公开配置与 Perplexity 内部生产环境之间的匹配程度。

公司经常围绕开源核心运行额外系统。内部调度器、容量预测、安全服务、部署自动化和事故处理工具，可能构成了很大一部分运维成果。

因此，应以更狭义的方式理解 Perplexity 的主张。该公司发布了与其沙箱架构相关的大量代码。

它并未移交复现 Perplexity Computer 背后服务所需的每一道流程，也没有发布足够的数据，让外部人士验证其宣称的生产规模。

这正是此次发布的核心权衡。开放代码提升了可审查性和控制力，而自托管则将更多责任交给采用者。

评估 SPACE 的团队应从威胁模型入手，而不是功能清单。它应识别不受信任的输入、受保护资产、允许的目的地和可接受的恢复时间。

随后，团队应测试常规演示会避开的故障场景，包括启动卡顿、输出流中断、主机容量耗尽、无效快照、凭证撤销和强制终止。

团队还应通过独立安全审查测试抗逃逸能力。一个旨在执行恶意代码的平台，理应比传统内部服务接受更多审查。

SPACE 看起来足够严肃，值得投入这项工作。现有证据并不足以证明可以跳过它。

三个信号将显示 SPACE 是否成为共享基础设施

下一阶段将由外部运营、安全响应和真实兼容性决定，而非仅靠对仓库的关注。

第一个信号是独立的生产部署。开发者应关注是否有组织在 Perplexity 自身环境之外运行 Perplexity SPACE 沙箱。

一份有意义的案例研究应描述工作负载形态、并发量、创建延迟、故障率和人员配置。一个 Logo 或安装公告所能揭示的信息要少得多。

独立运行将强化 Perplexity 的论点：这些代码传递了可用于生产环境的知识。反复出现的部署复杂性报告则会削弱这一论点。

社区贡献同样是这一首要信号的重要组成部分。对调度、运行时、部署目标或诊断功能的实质性改动，将表明外部开发者理解并能够扩展该架构。

第二个信号是项目的安全与发布记录。由于该平台从设计上就接受不受信任的代码，研究人员将会对 SPACE 进行测试。

在这一层面，提示词处理并非核心问题。关键在于，恶意进程能否跨越隔离边界、滥用凭据，或访问被禁止的网络。

透明的安全公告流程、及时的补丁以及清晰的升级指引将建立信任。悄无声息的修复或会破坏兼容性的安全更新，则会使企业采用变得更加困难。

用户还应关注 Perplexity 维护公开代码仓库的一致性。当内部开发不断推进、公开发布却逐渐滞后时，开源平台的价值便会下降。

第三个信号是在真实 Agent 工作负载下的兼容性。E2B wrapper 提供了一项直接测试：应用能否在不改变自身行为的前提下更换基础设施。

开发者应考察长时间运行的命令、文件传输、取消操作、重新连接、持久化以及并发会话。这些边缘情况揭示的信息，远多于一条成功执行的“hello world”命令。

可靠的兼容性将加大对托管沙箱提供商的压力。它会让团队能够将执行后端视为可替换的组件。

不完整的兼容性则会保留切换成本。提供商可以继续通过应用悄然依赖的行为来实现差异化。

Perplexity Computer 提供了另一个观察点。随着 Computer 处理更复杂的交付成果，用户将会遇到其执行环境的实际限制。

涉及软件包安装、长时任务、保留状态或生成文件的故障，能够揭示沙箱基础设施仍在何处限制产品。相关改进则可展现底层平台的推进速度。

构建知识密集型 Agent 的开发者还应考虑执行如何与上下文连接。沙箱可以运行代码，但仍需要经过精心挑选的文件和指令。

这使得信息检索和权限设计与计算隔离同样重要。在 Agent 获得访问权限之前，可搜索的 AI knowledge base 可以整理源材料。

Perplexity 发布 SPACE 沙箱，使得我们今天可以得出一个合理结论：Agent 执行正在成为独立的基础设施层，拥有自身的接口、兼容性考量和部署选择。

但这尚不足以证明自托管对每个团队都是最佳答案。当可靠性比基础设施控制更重要时，托管运维仍然具有价值。

因此，实际问题很明确：你的组织是否需要拥有执行边界，并且能否安全地运营这一边界？

如果答案是肯定的，请在恶意工作负载和真实故障条件下测试 SPACE。如果答案是否定的，则可利用其公开设计，向托管提供商提出更尖锐的问题。

请在未来三个月关注独立部署、安全披露和兼容性结果。这些信号将表明 SPACE 会成为共享的 Agent 基础设施，还是主要停留在 Perplexity 已发布的参考实现阶段。