4月19日，TiDB 联合亚马逊云科技、PPIO 等伙伴，在北京举办 AI Founders Meetup。
PPIO 联合创始人兼 CTO 王闻宇受邀出席，并依托对 Agent Infra 趋势判断，现场分享《为什么云端Agent需要专属沙箱？》主题。
PPIO 沙箱是专为 Agent 场景设计的新一代运行时基础设施，提供了一个安全隔离的云端沙箱环境来执行 AI 生成的代码，是国内首款兼容 E2B 的沙箱产品。
近期，PPIO 发布云端沙箱部署工具 PPClaw 和 PPhermes，可在云端一键部署 OpenClaw 和 Hermes Agent，为广大 AI 开发者提供 24 小时安全、低成本运行的 AI 助手。
为什么云端 Agent 需要有专属沙箱来支撑？王闻宇给出了自己的判断：沙箱加记忆、运维、编排的一套完整解决方案，将是未来 AI 时代的全新基础设施。
AI 不只是"答题机"了
早期的 AI 主要用于获取信息，今天的 AI 已经完全不一样了。它既可以查阅资料，还能抓网页、编程、做计划，是一个能够执行复杂任务的工具。
这一转变，倒逼出一个新需求：安全、隔离、可控的运行环境。
和传统应用不同，AI Agent 在执行任务时存在天然的不确定性------它可能修改系统驱动和配置，访问敏感资源，在执行链路中产生无法预测的副作用。更重要的是，它的执行过程需要完整保存数据流以便随时恢复，而它的使用方式高度弹性------并非 7×24 小时满载运行，而是需要时全力跑，不需要时完全静止。
传统的虚拟机和容器方案并非为此设计，既不够轻量，也难以满足 AI 负载弹性使用的特点
PPIO 的判断是：AI 时代需要一种新的虚拟化技术------沙箱（Sandbox）。相比传统的容器和云主机，沙箱要安全、合理、轻量，容易启动和扩展，符合当前这个时代对基础设施的要求。
三种场景，三种问题
PPIO 从实际业务出发，将沙箱应用场景分为三类，每类都有其特定痛点。
场景一：Vibe Coding / 通用 Agent
这是当前最主流的沙箱需求。编辑器场景的任务生命周期很短------一次 coding session 可能只有几个小时------但状态必须保留。用户不知道什么时候会回来继续，沙箱不能丢失任何上下文。
核心诉求：快速启动 （毫秒级）、闲时暂停/恢复，且对用户完全透明无感。
PPIO 目前的 Vibe Coding 轻部署方案已引入 TiDB 作为数据库后端，对用户的动态可运行产物，可以快速抽离成 Docker 部署在云端；有用户时快速唤醒扩展，没有用户时自动释放资源------AI coding 出来的程序，大多数使用次数很少，云部署完全够用。
场景二： 强化学习 训练 / 批量代码评测
DeepSeek 的爆火让强化学习重回视野，各大模型公司大力投入 RLHF 和 GRPO 训练。强化学习的本质是训推一体------在模型探索过程中，需要大量并发环境同步运行。
这对箱提出了极高要求：分钟级高频启动、极高并发支撑、持续数天的满载运行。
GPU 在中国非常贵，对模型公司来说是最宝贵的资源。沙箱的并发能力直接影响 GPU 集群的利用率，进而影响整个训练成本。PPIO 的方案是用大量 CPU 沙箱并发来弥补 GPU 的紧张，在模型推理的间隙给 GPU 加载其他任务，把每一片算力都榨干。
场景三：长时在线服务（OpenClaw 场景）
这是三类场景中最复杂的一个，也是 PPIO 投入最多的地方。长时运行意味着三个必须解决的难题：
-
持久化：环境状态和记忆都不能丢，而且要可迁移
-
运维：出问题要能恢复、能自愈、能被观测
-
成本：7×24 小时在线，但用户实际活跃时间每天不到 2 小时------大量算力被白白浪费
专为云端Agent 设计的长时运行沙箱
让沙箱"记住一切"------接入 Mem9
长时运行的第一个挑战是记忆。
沙箱本身具备不错的持久化能力------可以对文件系统和内存状态做完整的 Pause 镜像，支持 Snapshot 快速恢复，也支持挂载对象存储让实例销毁后数据不丢。
但单一沙箱有一个根本性缺陷：记忆与环境耦合。一旦实例被销毁，记忆、配置、上下文一起消失；Snapshot 绑定实例，迁移依赖状态，无法做到跨设备、跨实例的无缝迁移。
PPIO 的解法是引入独立的记忆层------Mem9。Mem9 提供了几个关键能力：
-
Hybrid Search：关键词 + 向量检索，Agent 能高效回忆相关记忆
-
跨设备、跨实例可迁移：换 Sandbox、换机器，记忆无缝跟随
-
零配置接入：Agent 写入即持久化，不需要自己搭数据库和向量索引
-
开源可自托管：Apache 2.0，可以跑在自己的基础设施上
记忆与环境解耦之后，OpenClaw Agent 即使在沙箱实例被回收后，依然能完整恢复所有上下文，真正实现"换个沙箱，还是那个 AI"。
让沙箱"自己照顾自己"------PPClaw & PPHermes
长时运行的第二个挑战是运维。
沙箱是一个运行载体，它有完整的生命周期管理能力（创建/删除/复制/回滚/隔离），但它不知道里面的应用是否健康。OpenClaw 在执行任务过程中会修改配置，出问题是家常便饭------而沙箱层面无法感知，更无法自愈。
PPIO 为此推出了两个运维工具：
PPClaw：对沙箱能力进行封装，提供面向 OpenClaw 的 API 管理和诊断能力，让运维人员能直接看到 Agent 的运行状态。
PPHermes：实现自动故障恢复链路------异常发生 → 尝试自动恢复 → 修复成功则继续；修复失败则触发手动 Snapshot 回滚。由于记忆独立存储在 Mem9，回滚时记忆完整保全，用户几乎感知不到任何中断。
让沙箱"会睡觉"------成本降低一个数量级
长时运行的第三个挑战，也是最直接影响商业可行性的挑战：成本。
"7×24 小时在线，不等于 7×24 小时活跃。"统计数据显示，OpenClaw 实际每日运行时长不足 2 小时。用虚拟机承载这个 workload，超过 90% 的计算资源被白白烧掉。
PPIO 的解法听起来简单，做起来不易：让沙箱像人一样睡觉。
技术实现上，通过在 Gateway 层截获消息、监测任务心跳，系统可以精准判断每个沙箱的活跃状态------有网络流量或 Cron 任务触发时立即唤醒，空闲超时后主动进入休眠。整个过程在 200 毫秒内完成状态恢复，用户几乎感知不到切换。
效果：
-
冷启动时间 < 1 秒
-
Pause 后状态恢复 < 200ms
-
计算成本相比 VM 降低 87% ，综合下来相比 VM 可降低一个数量级
已有客户通过沙箱克隆能力，将原本的 VM 方案成本压缩至原来的十分之一。
沙箱是未来 AI 时代的全新基础设施
在分享的最后，王闻宇把视野拉到更远处。他认为，沙箱的演进将沿着三条主线展开：
从"可选"到"必选"：今天主流 Agent 框架已开始内置沙箱；未来不提供沙箱的 Agent 框架将面临安全和可靠性质疑。沙箱会成为 AI 应用的默认运行环境，而非可选项
从"单一场景"到"统一底座"：Coding Agent、RL 训练、Eval/Benchmark、Agent 托管------这些场景目前分散在不同的基础设施上，未来将收敛到同一套标准化 Sandbox API。
从"计算资源"到"完整栈"：沙箱不只是 VM 或容器的替代品。它需要配套记忆持久化、应用运维、成本编排，以及数据库、向量存储、对象存储等关键组件。
"沙箱加记忆，加运维，加编排的一套完整的技术，才是未来 AI 时代的全新基础设施。"