过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。
当 Sandbox 并发规模进一步扩大后，问题也不再只是数据持久化和共享访问，客户端规模、缓存复用、小文件以及故障隔离等运行问题开始变得更加突出。
本文结合我们在 Agent RL（Agent Reinforcement Learning）场景中的实践，以及 JuiceFS 在云厂商 Sandbox 中的落地经验，介绍 Sandbox 数据的组织、跨云访问和挂载方式，并讨论大规模并发下遇到的问题和优化方向。
01 短生命周期 Sandbox，如何管理长生命周期数据？
以 Agent RL 为例，一次任务通常会经历任务分发、Sandbox 执行、轨迹采集、奖励评估和训练优化。任务执行产生的数据会继续被后续环节使用。
首先，计算生命周期与数据生命周期开始分离。Agent 任务启动时需要读取数据集、代码仓库、依赖环境、模型权重等内容；运行过程中又会持续产生执行轨迹、日志、中间文件和评测结果。Sandbox 可以在任务结束后销毁，但其中部分数据仍需保留，用于回放、分析、评估和后续训练。
其次，数据共享与任务隔离需要同时存在。每个 Sandbox 通常需要独立的工作目录和访问边界，但不同 Agent、Evaluator 或训练流程又可能访问同一份数据集、代码仓库，或复用前序任务产生的结果。
第三，数据需要跨不同计算环境流转。当任务分布在自建环境和不同云厂商的 Sandbox 中时，如果每个环境都维护独立的数据副本，不仅增加同步和管理成本，也会限制任务调度的灵活性。
02 JuiceFS 如何管理和接入 Sandbox 数据？
针对前面这些数据管理问题，下面介绍 JuiceFS 在实际 Sandbox 环境中的数据组织和接入方式。
用目录组织共享数据和任务数据
不同客户会根据自身业务特点采用不同的数据组织方式。结合现有客户的使用模式，一种比较典型的方式是：
- datasets 目录：用于存放评测数据集、训练数据集以及基准任务输入等核心数据；
- repos 目录：用于存放代码仓库、工具包以及相关依赖环境快照；
- 任务目录：根据不同任务、Runtime ID 以及训练版本等信息，在文件系统中创建独立目录，用于保存每一次任务运行过程中产生的数据。
通过这种方式，datasets、repos 等公共数据可以被多个任务共享访问，而每个任务又拥有独立的数据空间；同时，企业可以根据实际需求决定哪些数据需要长期保存，哪些数据可以在任务结束后进行清理，从而实现更加灵活的数据生命周期管理。
跨云 Sandbox 如何访问同一份数据
一些客户会基于安全、负载均衡、资源调度等因素，在多个云平台上同时使用不同厂商提供的 Sandbox 服务。
客户的核心数据（如训练集、推理数据等）通常存放在自有的数据平台或文件系统中，而不同云厂商的 Sandbox 环境则分别运行于各自的云基础设施之上。问题在于，不同云上的 Sandbox 如何访问同一份数据，而不需要分别维护数据副本。
在这类场景中，可以利用 JuiceFS 企业版的跨云数据访问能力，将统一数据保留在自有平台，同时允许不同云环境中的 Sandbox 按需访问。借助细粒度权限控制，各 Sandbox 之间可实现数据隔离，而不同云上的数据集、代码仓库、评测数据等资源也可纳入统一命名空间进行管理。
例如，当数据从 A 云环境写入后，B 云环境中的 Sandbox 可以快速读取并继续执行后续任务流程，从而提升任务调度的灵活性，也降低了多云环境下的数据管理复杂度。
面向强隔离 Sandbox 的 JuiceFS 数据挂载模式
要让 Sandbox 实际访问这些数据，还需要解决文件系统如何挂载到隔离环境中的问题。
目前，云厂商提供的 Sandbox 方案与一些企业自研 Sandbox 存在一定区别。从现有云上 Sandbox 架构来看，多数方案基于 Firecracker 等轻量虚拟化技术实现，各云厂商会在此基础上进行不同程度的优化。
这类 Sandbox 的核心特点是在虚拟机内部创建强隔离环境，使其与宿主机以及其他 Sandbox 实例之间保持隔离。因此，在这种强隔离架构下，数据访问不能简单依赖宿主机共享目录方式实现。
针对这一特点，目前的接入方式是在每个 Sandbox 旁运行一个独立的 JuiceFS 客户端。客户端通过云厂商提供的 Sidecar-like 机制随 Sandbox 拉起，并向业务 Sandbox 暴露本地挂载路径。
在该模式下，每个 Sandbox 均以独立身份对接后端 JuiceFS 服务，通过 VPC 网络访问部署在客户环境中的元数据服务，读取对应对象存储中的数据，并按任务需求挂载共享目录或独占目录。对于多任务、多组件间需要共享的数据，可通过共享目录实现统一访问，而各任务独有的数据则借助独立子目录进行隔离与保护，从而保障数据安全。
在权限管理方面，JuiceFS 企业版提供的 Token 访问控制能力可进一步实现细粒度的权限管理，确保不同 Sandbox 之间的数据访问安全可控。
03 JuiceFS 在云厂商 Sandbox 中的实践
目前，我们已在腾讯云和阿里云的 Sandbox 环境中完成 JuiceFS 的落地实践。
腾讯云：Agent Runtime 中的数据挂载方式
在腾讯云场景中，其采用 Agent Runtime 机制，提供文件系统层、实例层和存储层三种不同层级的隔离模式：
第一层是 Sandbox 内挂载块存储的方式。该块存储完全由单个 Sandbox 独占使用，并且 Sandbox 会基于该块存储创建独立的文件系统。这种情况下，其他环境无法访问该文件系统，实现了较强的数据隔离。
第二层是挂载腾讯云自身提供的存储服务，包括 COS 对象存储以及 CFS 文件存储。通过 mount 的方式，可以将对应存储挂载到具体的 Sandbox 环境中，本质上也是在 Sandbox 内部完成挂载。
第三种是 JuiceFS 的文件系统或子目录级隔离。 JuiceFS 可以将整个文件系统挂载到 Sandbox，也可以只挂载指定的子目录（subpath）。多个 Sandbox 因此可以共享同一个 JuiceFS 文件系统，同时通过不同子目录划分各自的数据访问范围，在共享数据与任务隔离之间取得平衡。
阿里云：FC 与 ACS 两种接入方式
阿里云目前主要涉及两个产品线：其中一个是 FC（Function Compute，函数计算）Sandbox，其实现方式与腾讯云较为类似，同样采用 Sidecar-like 进程模式，在每个 Sandbox 中启动一个客户端，用于完成 JuiceFS 的挂载。
另外一个产品线是 ACS（Container Compute Service，容器计算服务），其中也提供了 Sandbox 服务，但其实现方式有所区别。ACS 的方式是将支持 JuiceFS 挂载的能力集成到其驱动组件中。在实际使用过程中，由客户自行决定是否使用该能力以及具体的使用方式。后续相关代码也会计划放入其开源组件中。
目前，无论是腾讯云还是阿里云，JuiceFS 的挂载能力都同时支持社区版和企业版。
Sandbox 生命周期管理与挂载控制
在目前的 Sidecar-like 客户端模式下，JuiceFS 的挂载会在 Sandbox 启动阶段完成，整个挂载生命周期由 Sandbox 平台统一托管。例如，在阿里云环境中由 FC 管控平台负责管理，在腾讯云中则由 Agent Runtime 平台承担这一职责。
每个 Sandbox 对应一个独立的 JuiceFS 客户端，客户端随 Sandbox 创建并完成目录挂载。挂载过程中所需的 Token、挂载参数以及缓存目录等配置，均由 Runtime 平台统一注入和管理。
在这一机制下，企业版与社区版存在一定差异。企业版通过控制台和 Token 等能力提供了更完善的管控方式，各云厂商的平台也基本将这些能力集成到了自身的挂载管理流程中。
对业务侧而言，Sandbox 只需要看到挂载后的数据目录，而无需直接管理 JuiceFS 客户端。客户端的创建、配置、挂载和退出等过程均由 Sandbox 平台统一接管。
04 大规模 Agent Sandbox 场景下的挑战与优化方向
客户端扩展瓶颈
当前一个 Sandbox 对应一个独立的 JuiceFS 客户端，每个客户端在企业版中均被视为独立客户端实例。随着 Sandbox 数量增长，客户端数量以及对应的进程、连接和元数据请求也会同步增加。
然而，目前多数云厂商的 Sandbox 实现大多基于 Firecracker 虚拟化技术，而原生 Firecracker 并不支持类似 VirtIO-FS 的透传挂载方式。单个文件系统能够承载的客户端数量大约为 10 万级别。目前，我们已收到部分客户关于百万级甚至更高规模 Sandbox 的需求，客户端架构的优化已成为后续演进的重要方向之一。
一个正在探索的方向是引入类似 Mount Pod 的模式，在宿主机或指定节点上运行 JuiceFS 客户端，由多个 Sandbox 共享挂载能力。这样可以减少客户端实例数量和资源消耗，并进一步提升可支持的 Sandbox 规模。
缓存复用与数据加载效率
当前一个 Sandbox 对应一个独立的 JuiceFS 客户端，而 Sandbox 又可能分布在不同节点，因此客户端缓存很难在不同任务之间充分复用。在缺乏共享缓存层的情况下，大量重复的数据读取和加载压力会直接传导至对象存储；对于跨云 Sandbox 场景，还可能进一步增加跨云链路的带宽压力。
针对这一问题，我们计划结合任务调度、宿主机磁盘资源以及 JuiceFS 的缓存能力，提高热点数据的缓存复用效率。例如，将相关任务尽可能调度至相近节点，并利用宿主机磁盘构建分布式缓存，让模型数据集等高频访问数据尽可能靠近计算，减少从对象存储重复加载。
使用云厂商提供的 Sandbox，需要结合云厂商能够提供的缓存资源；自建 Sandbox，则可以根据客户自身基础设施进行规划，在性能、缓存容量和资源成本之间取得平衡。
小文件与元数据性能
在 Agent 执行过程中，日志、轨迹等数据往往表现为持续的小 I/O 写入、大量小文件生成以及频繁 flush，这对 JuiceFS 的元数据和写入性能提出了更高要求。
针对此类场景，我们将与业务方共同探讨优化策略，例如评估是否可以将大量小 I/O 合并为较大粒度的写入请求，或通过批量写入方式减少频繁的小文件操作。从业务侧调整数据写入模式，也有助于降低底层元数据服务的压力。
故障隔离与平台化治理
在大规模并发场景下，需要避免单个异常任务影响共享缓存、元数据服务或对象存储。例如异常访问产生大量请求时，需要尽可能控制其影响范围，避免波及其他任务。
如果后续进一步引入共享缓存、共享客户端或客户端池，原有的隔离边界也会发生变化。多个 Sandbox 共享底层资源后，需要重新考虑故障隔离、资源限制、访问权限以及共享客户端的生命周期管理。
另一方面，随着越来越多的平台将 Sandbox 作为面向不同团队或客户的公共服务，数据管理也会进一步延伸到多租户场景。不同租户之间需要保持清晰的数据与权限边界，不同类型的数据也需要采用相应的生命周期策略。
可观测性也需要随之完善，不仅要能够观察客户端和缓存状态，还需要了解整体存储使用情况、共享资源的运行状态以及异常影响范围，为后续的资源治理提供依据。
从目前的实践来看，Sandbox 本身并不难做到快速创建和销毁，真正麻烦的是它背后的数据不能跟着一起消失。轨迹、日志、评测结果和训练样本还要继续被后续任务使用，这也让存储逐渐从“给 Sandbox 提供一个目录”，变成需要长期参与整个 Agent 数据链路。
当规模从十万级继续向百万级发展时，Sandbox 客户端、独立缓存这些原本简单直接的设计也开始需要重新考虑。我们目前还在验证客户端复用、缓存和隔离等不同方案，也很希望和正在做 Agent Sandbox、Agent RL 或相关基础设施的团队交流各自遇到的问题。
