[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-831":3,"consumer-news-interaction-831":39,"consumer-news-related-831":42},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:831","news","NEWS_ARTICLE",831,"资讯","Agent Sandbox 规模化：JuiceFS 探索与实践","博客园","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","","\u002Fnews\u002F831",[18],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"JuiceFS","2026-09-02T17:11","2026-09-02T20:37:48","https:\u002F\u002Fwww.cnblogs.com\u002FJuiceData\u002Fp\u002F22811276","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","\u003Cp>过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。\u003C\u002Fp>\n\u003Cp>当 Sandbox 并发规模进一步扩大后，问题也不再只是数据持久化和共享访问，客户端规模、缓存复用、小文件以及故障隔离等运行问题开始变得更加突出。\u003C\u002Fp>\n\u003Cp>本文结合我们在 Agent RL（Agent Reinforcement Learning）场景中的实践，以及 JuiceFS 在云厂商 Sandbox 中的落地经验，介绍 Sandbox 数据的组织、跨云访问和挂载方式，并讨论大规模并发下遇到的问题和优化方向。\u003C\u002Fp>\n\u003Ch2>01 短生命周期 Sandbox，如何管理长生命周期数据？\u003C\u002Fh2>\n\u003Cp>以 Agent RL 为例，一次任务通常会经历任务分发、Sandbox 执行、轨迹采集、奖励评估和训练优化。任务执行产生的数据会继续被后续环节使用。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>首先，计算生命周期与数据生命周期开始分离\u003C\u002Fstrong>。Agent 任务启动时需要读取数据集、代码仓库、依赖环境、模型权重等内容；运行过程中又会持续产生执行轨迹、日志、中间文件和评测结果。Sandbox 可以在任务结束后销毁，但其中部分数据仍需保留，用于回放、分析、评估和后续训练。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>其次，数据共享与任务隔离需要同时存在\u003C\u002Fstrong>。每个 Sandbox 通常需要独立的工作目录和访问边界，但不同 Agent、Evaluator 或训练流程又可能访问同一份数据集、代码仓库，或复用前序任务产生的结果。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第三，数据需要跨不同计算环境流转\u003C\u002Fstrong>。当任务分布在自建环境和不同云厂商的 Sandbox 中时，如果每个环境都维护独立的数据副本，不仅增加同步和管理成本，也会限制任务调度的灵活性。\u003C\u002Fp>\n\u003Ch2>02 JuiceFS 如何管理和接入 Sandbox 数据？\u003C\u002Fh2>\n\u003Cp>针对前面这些数据管理问题，下面介绍 JuiceFS 在实际 Sandbox 环境中的数据组织和接入方式。\u003C\u002Fp>\n\u003Ch3>用目录组织共享数据和任务数据\u003C\u002Fh3>\n\u003Cp>不同客户会根据自身业务特点采用不同的数据组织方式。结合现有客户的使用模式，一种比较典型的方式是：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>datasets 目录\u003C\u002Fstrong>：用于存放评测数据集、训练数据集以及基准任务输入等核心数据；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>repos 目录\u003C\u002Fstrong>：用于存放代码仓库、工具包以及相关依赖环境快照；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>任务目录\u003C\u002Fstrong>：根据不同任务、Runtime ID 以及训练版本等信息，在文件系统中创建独立目录，用于保存每一次任务运行过程中产生的数据。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>通过这种方式，datasets、repos 等公共数据可以被多个任务共享访问，而每个任务又拥有独立的数据空间；同时，企业可以根据实际需求决定哪些数据需要长期保存，哪些数据可以在任务结束后进行清理，从而实现更加灵活的数据生命周期管理。\u003C\u002Fp>\n\u003Ch3>跨云 Sandbox 如何访问同一份数据\u003C\u002Fh3>\n\u003Cp>一些客户会基于安全、负载均衡、资源调度等因素，在多个云平台上同时使用不同厂商提供的 Sandbox 服务。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"image\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>客户的核心数据（如训练集、推理数据等）通常存放在自有的数据平台或文件系统中，而不同云厂商的 Sandbox 环境则分别运行于各自的云基础设施之上。问题在于，不同云上的 Sandbox 如何访问同一份数据，而不需要分别维护数据副本。\u003C\u002Fp>\n\u003Cp>在这类场景中，可以利用 JuiceFS 企业版的跨云数据访问能力，将统一数据保留在自有平台，同时允许不同云环境中的 Sandbox 按需访问。借助细粒度权限控制，各 Sandbox 之间可实现数据隔离，而不同云上的数据集、代码仓库、评测数据等资源也可纳入统一命名空间进行管理。\u003C\u002Fp>\n\u003Cp>例如，当数据从 A 云环境写入后，B 云环境中的 Sandbox 可以快速读取并继续执行后续任务流程，从而提升任务调度的灵活性，也降低了多云环境下的数据管理复杂度。\u003C\u002Fp>\n\u003Ch3>面向强隔离 Sandbox 的 JuiceFS 数据挂载模式\u003C\u002Fh3>\n\u003Cp>要让 Sandbox 实际访问这些数据，还需要解决文件系统如何挂载到隔离环境中的问题。\u003C\u002Fp>\n\u003Cp>目前，云厂商提供的 Sandbox 方案与一些企业自研 Sandbox 存在一定区别。从现有云上 Sandbox 架构来看，多数方案基于 Firecracker 等轻量虚拟化技术实现，各云厂商会在此基础上进行不同程度的优化。\u003C\u002Fp>\n\u003Cp>这类 Sandbox 的核心特点是在虚拟机内部创建强隔离环境，使其与宿主机以及其他 Sandbox 实例之间保持隔离。因此，在这种强隔离架构下，数据访问不能简单依赖宿主机共享目录方式实现。\u003C\u002Fp>\n\u003Cp>针对这一特点，目前的接入方式是在每个 Sandbox 旁运行一个独立的 JuiceFS 客户端。客户端通过云厂商提供的 Sidecar-like 机制随 Sandbox 拉起，并向业务 Sandbox 暴露本地挂载路径。\u003C\u002Fp>\n\u003Cp>在该模式下，每个 Sandbox 均以独立身份对接后端 JuiceFS 服务，通过 VPC 网络访问部署在客户环境中的元数据服务，读取对应对象存储中的数据，并按任务需求挂载共享目录或独占目录。对于多任务、多组件间需要共享的数据，可通过共享目录实现统一访问，而各任务独有的数据则借助独立子目录进行隔离与保护，从而保障数据安全。\u003C\u002Fp>\n\u003Cp>在权限管理方面，JuiceFS 企业版提供的 Token 访问控制能力可进一步实现细粒度的权限管理，确保不同 Sandbox 之间的数据访问安全可控。\u003C\u002Fp>\n\u003Ch2>03 JuiceFS 在云厂商 Sandbox 中的实践\u003C\u002Fh2>\n\u003Cp>目前，我们已在腾讯云和阿里云的 Sandbox 环境中完成 JuiceFS 的落地实践。\u003C\u002Fp>\n\u003Ch3>腾讯云：Agent Runtime 中的数据挂载方式\u003C\u002Fh3>\n\u003Cp>在腾讯云场景中，其采用 Agent Runtime 机制，提供文件系统层、实例层和存储层三种不同层级的隔离模式：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第一层是 Sandbox 内挂载块存储的方式\u003C\u002Fstrong>。该块存储完全由单个 Sandbox 独占使用，并且 Sandbox 会基于该块存储创建独立的文件系统。这种情况下，其他环境无法访问该文件系统，实现了较强的数据隔离。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第二层是挂载腾讯云自身提供的存储服务\u003C\u002Fstrong>，包括 COS 对象存储以及 CFS 文件存储。通过 mount 的方式，可以将对应存储挂载到具体的 Sandbox 环境中，本质上也是在 Sandbox 内部完成挂载。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"image\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171056832-2074584208.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第三种是 JuiceFS 的文件系统或子目录级隔离。\u003C\u002Fstrong> JuiceFS 可以将整个文件系统挂载到 Sandbox，也可以只挂载指定的子目录（subpath）。多个 Sandbox 因此可以共享同一个 JuiceFS 文件系统，同时通过不同子目录划分各自的数据访问范围，在共享数据与任务隔离之间取得平衡。\u003C\u002Fp>\n\u003Ch3>阿里云：FC 与 ACS 两种接入方式\u003C\u002Fh3>\n\u003Cp>\u003Cimg alt=\"image\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171104696-1276463843.png?w=720&quality=65&strip=all\">\u003C\u002Fp>\n\u003Cp>阿里云目前主要涉及两个产品线：其中一个是 FC（Function Compute，函数计算）Sandbox，其实现方式与腾讯云较为类似，同样采用 Sidecar-like 进程模式，在每个 Sandbox 中启动一个客户端，用于完成 JuiceFS 的挂载。\u003C\u002Fp>\n\u003Cp>另外一个产品线是 ACS（Container Compute Service，容器计算服务），其中也提供了 Sandbox 服务，但其实现方式有所区别。ACS 的方式是将支持 JuiceFS 挂载的能力集成到其驱动组件中。在实际使用过程中，由客户自行决定是否使用该能力以及具体的使用方式。后续相关代码也会计划放入其开源组件中。\u003C\u002Fp>\n\u003Cp>目前，无论是腾讯云还是阿里云，JuiceFS 的挂载能力都同时支持社区版和企业版。\u003C\u002Fp>\n\u003Ch3>Sandbox 生命周期管理与挂载控制\u003C\u002Fh3>\n\u003Cp>在目前的 Sidecar-like 客户端模式下，JuiceFS 的挂载会在 Sandbox 启动阶段完成，整个挂载生命周期由 Sandbox 平台统一托管。例如，在阿里云环境中由 FC 管控平台负责管理，在腾讯云中则由 Agent Runtime 平台承担这一职责。\u003C\u002Fp>\n\u003Cp>每个 Sandbox 对应一个独立的 JuiceFS 客户端，客户端随 Sandbox 创建并完成目录挂载。挂载过程中所需的 Token、挂载参数以及缓存目录等配置，均由 Runtime 平台统一注入和管理。\u003C\u002Fp>\n\u003Cp>在这一机制下，企业版与社区版存在一定差异。企业版通过控制台和 Token 等能力提供了更完善的管控方式，各云厂商的平台也基本将这些能力集成到了自身的挂载管理流程中。\u003C\u002Fp>\n\u003Cp>对业务侧而言，Sandbox 只需要看到挂载后的数据目录，而无需直接管理 JuiceFS 客户端。客户端的创建、配置、挂载和退出等过程均由 Sandbox 平台统一接管。\u003C\u002Fp>\n\u003Ch2>04 大规模 Agent Sandbox 场景下的挑战与优化方向\u003C\u002Fh2>\n\u003Ch3>客户端扩展瓶颈\u003C\u002Fh3>\n\u003Cp>当前一个 Sandbox 对应一个独立的 JuiceFS 客户端，每个客户端在企业版中均被视为独立客户端实例。随着 Sandbox 数量增长，客户端数量以及对应的进程、连接和元数据请求也会同步增加。\u003C\u002Fp>\n\u003Cp>然而，目前多数云厂商的 Sandbox 实现大多基于 Firecracker 虚拟化技术，而原生 Firecracker 并不支持类似 VirtIO-FS 的透传挂载方式。\u003Cstrong>单个文件系统能够承载的客户端数量大约为 10 万级别\u003C\u002Fstrong>。目前，我们已收到部分客户关于百万级甚至更高规模 Sandbox 的需求，客户端架构的优化已成为后续演进的重要方向之一。\u003C\u002Fp>\n\u003Cp>一个正在探索的方向是引入类似 Mount Pod 的模式，在宿主机或指定节点上运行 JuiceFS 客户端，由多个 Sandbox 共享挂载能力。这样可以减少客户端实例数量和资源消耗，并进一步提升可支持的 Sandbox 规模。\u003C\u002Fp>\n\u003Ch3>缓存复用与数据加载效率\u003C\u002Fh3>\n\u003Cp>当前一个 Sandbox 对应一个独立的 JuiceFS 客户端，而 Sandbox 又可能分布在不同节点，因此客户端缓存很难在不同任务之间充分复用。在缺乏共享缓存层的情况下，大量重复的数据读取和加载压力会直接传导至对象存储；对于跨云 Sandbox 场景，还可能进一步增加跨云链路的带宽压力。\u003C\u002Fp>\n\u003Cp>针对这一问题，我们计划结合任务调度、宿主机磁盘资源以及 JuiceFS 的缓存能力，提高热点数据的缓存复用效率。例如，将相关任务尽可能调度至相近节点，并利用宿主机磁盘构建分布式缓存，让模型数据集等高频访问数据尽可能靠近计算，减少从对象存储重复加载。\u003C\u002Fp>\n\u003Cp>使用云厂商提供的 Sandbox，需要结合云厂商能够提供的缓存资源；自建 Sandbox，则可以根据客户自身基础设施进行规划，在性能、缓存容量和资源成本之间取得平衡。\u003C\u002Fp>\n\u003Ch3>小文件与元数据性能\u003C\u002Fh3>\n\u003Cp>在 Agent 执行过程中，日志、轨迹等数据往往表现为持续的小 I\u002FO 写入、大量小文件生成以及频繁 flush，这对 JuiceFS 的元数据和写入性能提出了更高要求。\u003C\u002Fp>\n\u003Cp>针对此类场景，我们将与业务方共同探讨优化策略，例如评估是否可以将大量小 I\u002FO 合并为较大粒度的写入请求，或通过批量写入方式减少频繁的小文件操作。从业务侧调整数据写入模式，也有助于降低底层元数据服务的压力。\u003C\u002Fp>\n\u003Ch3>故障隔离与平台化治理\u003C\u002Fh3>\n\u003Cp>在大规模并发场景下，需要避免单个异常任务影响共享缓存、元数据服务或对象存储。例如异常访问产生大量请求时，需要尽可能控制其影响范围，避免波及其他任务。\u003C\u002Fp>\n\u003Cp>如果后续进一步引入共享缓存、共享客户端或客户端池，原有的隔离边界也会发生变化。多个 Sandbox 共享底层资源后，需要重新考虑故障隔离、资源限制、访问权限以及共享客户端的生命周期管理。\u003C\u002Fp>\n\u003Cp>另一方面，随着越来越多的平台将 Sandbox 作为面向不同团队或客户的公共服务，数据管理也会进一步延伸到多租户场景。不同租户之间需要保持清晰的数据与权限边界，不同类型的数据也需要采用相应的生命周期策略。\u003C\u002Fp>\n\u003Cp>可观测性也需要随之完善，不仅要能够观察客户端和缓存状态，还需要了解整体存储使用情况、共享资源的运行状态以及异常影响范围，为后续的资源治理提供依据。\u003C\u002Fp>\n\u003Cp>从目前的实践来看，Sandbox 本身并不难做到快速创建和销毁，真正麻烦的是它背后的数据不能跟着一起消失。轨迹、日志、评测结果和训练样本还要继续被后续任务使用，这也让存储逐渐从“给 Sandbox 提供一个目录”，变成需要长期参与整个 Agent 数据链路。\u003C\u002Fp>\n\u003Cp>当规模从十万级继续向百万级发展时，Sandbox 客户端、独立缓存这些原本简单直接的设计也开始需要重新考虑。我们目前还在验证客户端复用、缓存和隔离等不同方案，也很希望和正在做 Agent Sandbox、Agent RL 或相关基础设施的团队交流各自遇到的问题。\u003C\u002Fp>\n\u003Cp>我们希望本文中的一些实践经验，能为正在面临类似问题的开发者提供参考，如果有其他疑问欢迎加入 \u003Ca href=\"https:\u002F\u002Fjuicefs.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">JuiceFS 社区\u003C\u002Fa>与大家共同交流。\u003C\u002Fp>","过去一段时间，我们在和云厂商以及 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\u002FO 写入、大量小文件生成以及频繁 flush，这对 JuiceFS 的元数据和写入性能提出了更高要求。 针对此类场景，我们将与业务方共同探讨优化策略，例如评估是否可以将大量小 I\u002FO 合并为较大粒度的写入请求，或通过批量写入方式减少频繁的小文件操作。从业务侧调整数据写入模式，也有助于降低底层元数据服务的压力。 故障隔离与平台化治理 在大规模并发场景下，需要避免单个异常任务影响共享缓存、元数据服务或对象存储。例如异常访问产生大量请求时，需要尽可能控制其影响范围，避免波及其他任务。 如果后续进一步引入共享缓存、共享客户端或客户端池，原有的隔离边界也会发生变化。多个 Sandbox 共享底层资源后，需要重新考虑故障隔离、资源限制、访问权限以及共享客户端的生命周期管理。 另一方面，随着越来越多的平台将 Sandbox 作为面向不同团队或客户的公共服务，数据管理也会进一步延伸到多租户场景。不同租户之间需要保持清晰的数据与权限边界，不同类型的数据也需要采用相应的生命周期策略。 可观测性也需要随之完善，不仅要能够观察客户端和缓存状态，还需要了解整体存储使用情况、共享资源的运行状态以及异常影响范围，为后续的资源治理提供依据。 从目前的实践来看，Sandbox 本身并不难做到快速创建和销毁，真正麻烦的是它背后的数据不能跟着一起消失。轨迹、日志、评测结果和训练样本还要继续被后续任务使用，这也让存储逐渐从“给 Sandbox 提供一个目录”，变成需要长期参与整个 Agent 数据链路。 当规模从十万级继续向百万级发展时，Sandbox 客户端、独立缓存这些原本简单直接的设计也开始需要重新考虑。我们目前还在验证客户端复用、缓存和隔离等不同方案，也很希望和正在做 Agent Sandbox、Agent RL 或相关基础设施的团队交流各自遇到的问题。 我们希望本文中的一些实践经验，能为正在面临类似问题的开发者提供参考，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。",4893,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":38},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":40,"likeCount":41,"commentCount":41,"contentLikeCount":41,"contentCommentCount":41,"sourceLikeCount":41,"sourceCommentCount":41},false,0,[43,52,58,65,73,79,86,92],{"id":44,"kind":7,"title":45,"summary":46,"image":47,"href":48,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":50},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[51],"人工智能",{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":57},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":59,"kind":7,"title":60,"summary":61,"image":62,"href":63,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":64},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":66,"kind":7,"title":67,"summary":68,"image":15,"href":69,"meta":70,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":71},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[72],"软件开发",{"id":74,"kind":7,"title":75,"summary":76,"image":15,"href":77,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":78},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":83,"href":84,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":85},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[51],{"id":87,"kind":7,"title":88,"summary":89,"image":15,"href":90,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":91},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8],{"id":93,"kind":7,"title":94,"summary":95,"image":96,"href":97,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":98},"NEWS_ARTICLE:834","用 Apache SeaTunnel 同步 DynamoDB 到 Redis，一个配置文件就够","作者：Ricardo Ferreira 编译：Debra Chen 假设你把客户数据存储在 Amazon DynamoDB 中，作为应用的唯一数据源（single source of truth）。但如今你需要同样的数据放在 Redis 里，进行快速缓存、实时分析，或是为向量搜索推荐引擎赋能。举例来","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F3195851\u002F202609\u002F3195851-20260902145155710-759131565.jpg","\u002Fnews\u002F834",[7,8]]