Perplexity开源SPACE：Agent执行沙箱走向可审计，隔离不等于业务授权
Perplexity于10月15日开源SPACE。本文结合官方代码、架构与版本文档，解析microVM隔离、任务生命周期及部署限制，说明为什么执行沙箱不能替代业务权限管理。
事件时间：2026年10月15日；整理发布：2026年10月16日。Perplexity 将用于 AI Agent 代码执行的 SPACE 开放为开源项目。相比又一款能回答问题的模型，这条动态更值得开发团队关注：当 Agent 开始写文件、调用命令和连续运行任务，真正需要解决的是把执行能力放进什么边界，而不是只在提示词中要求它“不要越界”。
发布了什么：公开代码，而非一键托管承诺
10月15日的 Semafor 报道确认了此次开源消息。官方 GitHub 仓库将 SPACE 定义为 Sandboxed Platform for Agentic Code Execution，并采用 Apache-2.0 许可证。它不是搜索界面或聊天客户端，而是供应用创建隔离 Linux 环境、运行命令、读取输出并管理环境生命周期的基础设施。
仓库创建于10月1日，不应把创建日期直接写成对外发布日。这里采用10月15日的公开报道作为本次新闻时间。开源许可解决的是代码使用条件，不意味着云资源免费、现成的托管服务可用，或部署后无需维护。
背景：Agent 的执行环境为何成为单独一层
传统问答产品主要输出文本；长任务 Agent 则可能下载依赖、生成脚本、保存中间文件，并反复执行命令。如果所有任务共享宿主目录或高权限账户，一次错误操作就可能影响其他任务。SPACE 的文档以 Firecracker microVM 作为隔离执行环境，让应用把需要运行的代码与自身服务分开。
根据官方架构，模板决定起始文件系统和运行配置，沙箱拥有独立的可写文件系统；同一个沙箱中的多个命令仍会共享其环境。创建沙箱、启动进程、接收输出是不同步骤。API 接受创建请求不代表环境已就绪，命令结束也不自动意味着沙箱已经删除。这些区别直接影响重试、清理与任务状态判断。
真正的影响：应用团队仍要负责“允许做什么”
本站分析：公开执行层代码有利于团队检查实现、评估自建与接入成本，但隔离只回答“代码在哪里运行”。应用仍需决定给 Agent 哪些凭据、能访问哪些域名、结果保留多久，以及何时需要人类批准。一个被关在独立虚拟机里的程序，如果拿到了生产数据库的高权限密钥，仍可能在授权通道内造成业务损失。
因此，评估不能只看启动速度。更实际的检查项包括：任务间文件是否分离、失败后是否可追踪、网络出口与密钥如何管理、暂停恢复是否保留了预期状态，以及清理流程能否可靠回收资源。本文未自行部署或做逃逸测试，不把厂商安全表述当作“绝对不会逃逸”的保证。
采用边界：开发环境示例不能直接当生产方案
官方安装指南要求 Linux x86_64、KVM 和相关设备支持，本地演示路径使用 Kind 与 Kubernetes，并涉及有特权能力的容器环境；指南明确提示开发密码和签名密钥不应被拿去连接生产凭据。架构文档也说明存在不依赖 Kubernetes 沙箱 Pod 的直接管理路径，因此不能简单说 SPACE 在所有部署中都必须使用 Kubernetes。
版本文档以0.8.0作为公开基线，并把稳定服务契约列为1.0.0阶段目标。团队选型时应固定实际评估版本，重新核对接口兼容性、镜像来源和回滚方式，而不是默认当前开发分支已经具备长期稳定保证。
适合哪些人关注
- Agent 与编程产品开发者：需要为用户代码、自动化脚本或持续任务提供隔离执行空间。
- 平台工程和安全团队：需要比较自建执行层、云沙箱服务及组织现有权限系统的边界。
- 技术采购负责人：应要求验证真实任务、失败恢复和运营成本，而非仅凭“开源”作采购结论。
对普通聊天用户，这不是必须立即安装的新工具。对正在让 Agent 真正执行工作的团队，它提供了一个可检查的执行层选项；合理的下一步是在不接触生产数据的环境中验证，再讨论接入业务。
来源参考与核验说明
以下资料于2026年10月16日核验。本文综合公开报道、官方代码与产品文档独立撰写；分析和建议为本站编辑判断，不代表独立安全审计结论。
