Agent Sandbox 规模化这件事卡点往往不在沙箱本身而在存储。我早期做 Agent 批量任务时用的是本地磁盘节点一多文件同步就成了灾难后来切到对象存储又发现随机小文件读写慢得离谱尤其是 Python 环境初始化、依赖安装这类高频操作跑一次几分钟就没了。直到把 JuiceFS 引入沙箱体系才算是把这块短板补上了。这篇文章就把我在 Agent Sandbox 规模化过程中关于存储方案的选型、架构设计、调优和踩坑记录完整梳理一遍。不是纯理论分析都是实际机房/集群里跑出来的数据以及那些文档里不会明说的细节。1. Agent Sandbox 规模化最先暴露的为什么是存储1.1 沙箱数量一上来存储直接变成短板先说清楚 Agent Sandbox 到底是什么。简单讲它就是每个 Agent 任务跑在里面的隔离环境通常是容器里面包含代码运行环境、依赖库、临时文件、模型缓存、数据集等等。单机跑几十个沙箱本地磁盘随便折腾没问题但一旦进入规模化阶段——比如同时跑几百个甚至几千个沙箱——存储问题立刻放大成为最头痛的一块。首先是共享问题。任务调度会把不同的 Agent 派到不同节点上执行但很多基础数据Python 包、模型文件、共享数据集是全体任务都要用的。放本地每个节点都得复制一份存储浪费不说更新一次基础镜像就是全量重推。其次是生命周期问题。沙箱是短生命周期的创建和销毁频率很高本地磁盘上残留的容器层、临时文件会持续累积隔几天就得手动清理否则磁盘配额直接爆掉。还有隔离与权限问题。不同任务的沙箱需要互相隔离但某些数据又要共享只读访问这对权限模型的精细度要求很高本地文件系统做起来很别扭。所以到规模化阶段几乎必然要引入一个中心化的、可共享的、具备 POSIX 语义的存储层。JuiceFS 正好是这个生态里很能打的一个选项。1.2 本地盘、NFS、对象存储、JuiceFS先把账算明白我在这里不预设 JuiceFS 一定最优而是把我在选型阶段实测过的几条路线列出来。对 Agent Sandbox 这个具体场景来说关键指标有三个并发读写性能、元数据操作的延迟、以及多节点一致性体验。方案优势短板实测感受是否适合沙箱规模化节点本地盘延迟最低IO 直通无法共享扩容靠搬数据节点故障数据就没了不适合作为核心存储传统 NFS 服务端部署简单POSIX 兼容好单点瓶颈随节点增长极快大量小文件 inode 操作性能雪崩小规模勉强中大规模明显吃力对象存储S3/MinIO容量无限成本低高可用不直接支持 POSIX 语义随机读写性能差依赖要加一层缓存不能直接做沙箱工作目录JuiceFS对象存储做数据持久化本地缓存负责热数据加速同时保留完整 POSIX 语义需要额外维护元数据引擎Redis 等架构上多了一个组件适合尤其适合多读多写、文件数量大的场景我实际对比过 NFS 和 JuiceFS 在同样的一套沙箱环境初始化任务上的表现。同样并发 200 个沙箱同时拉取 Python 依赖NFS 模式下元数据请求堆积严重standby 的 load 飙到 30 以上整个环境初始化耗时约 7 分半JuiceFS 场景下元数据打到了 Redis数据块走对象存储本地缓存命中率上来以后同样的初始化耗时压到 2 分 40 秒左右。这个差距不是一两倍是量级的差别。1.3 沙箱存储需求拆解快照、缓存、多人协作再往下拆Agent Sandbox 的存储需求还要细分一下不然很容易选型失误。基础镜像与依赖库这类数据量大、改动频率低、读多写少。典型特征是大量小文件Python site-packages 里几万个小文件是常态。Agent 运行时的临时状态包括Checkpoint、中间结果、日志写入频繁、生命周期短需要能快速回收。共享数据集与模型权重这类是超大文件需要高吞吐的顺序读能力。多人协作场景同一个团队里多个开发者调试 Agent需要同时看到沙箱里的文件变更一致性很重要。JuiceFS 有一个我很喜欢的设计——它把文件内容和元数据分开处理文件内容切分成数据块后落到对象存储比如 MinIO 或云上 S3元数据全部放在独立的元数据引擎默认是 Redis里。这样做的好处是无论面对大量小文件还是超大权重文件都能各取所长元数据操作走高速内存数据读写走对象存储本地缓存。不过这块后面也有不少需要进行深度调优的地方我放在第三部分详细说。2. 为什么我最终锁定了 JuiceFS2.1 POSIX 兼容带来的迁移成本优势技术选型时千万不能忽略迁移成本。之前团队里有人提议直接把沙箱工作目录放到 S3 兼容层上但这就意味着 Sandbox 里所有希望走“透明文件系统调用”的组件全部需要改代码。像 Python 的 pip 安装缓存、PyTorch 的 DataLoader 数据加载、一些老项目里直接调os.open的代码在对象存储方案里全都跑不起来。JuiceFS 在最上层实现了完整的 POSIX 文件系统语义基于 FUSE对业务层完全透明。这就意味着沙箱里的应用不用改一行代码直接把它当本地磁盘用就行迁移成本几乎为零。我当时的操作就是把原来挂载本地盘的 volume 路径换成了 JuiceFS 挂载点沙箱里所有路径、权限、软链行为都保持一致。2.2 分层存储架构兼顾容量与性能JuiceFS 的分层架构是它最核心的设计底层是对象存储容量近乎无限成本很低上层是本地缓存负责把热数据留在高性能介质上。这个设计直接击中了 Agent Sandbox 的痛点——沙箱的很多操作是重复的比如反复初始化同一批依赖库、反复读取同一份模型权重只要缓存命中数据根本不需要每次都回源到对象存储。我在生产环境里观察到的缓存命中率大概在 92%~95% 之间视具体任务类型浮动。一旦命中性能就是本地盘级别完全不会拖沙箱性能的后腿。2.3 快照、克隆与速度沙箱创建效率的命门Sandbox 的创建效率直接决定任务调度的响应速度。我最开始的实现是沙箱挂载一个新的空目录作为工作区然后启动时把基础环境复制进来。一旦环境体量变大比如包含了一个 5GB 的 Python 环境 1GB 模型缓存复制动作就会让沙箱创建时间变得不可接受。JuiceFS 的快照功能解决了这个问题。它是基于 COWCopy-on-Write机制实现的创建快照不复制数据只复制一份元数据视图。我用 JuiceFS 的 Snapshot 能力预先做了一个“基础环境快照”每个新沙箱启动时直接基于这个快照创建自己的可写视图JuiceFS 的juicefs clone可以秒级完成目录克隆但要注意它和快照在实现细节上有点区别后面展开。这样环境准备时间从分钟级降到了秒级效果非常明显。对 Agent Sandbox 来说这个能力还有一个额外的好处版本控制和管理体验更接近“镜像”的概念。基础环境更新时只需要重新生成一次快照旧快照可以保留作为回滚点沙箱存储的运维从“搬文件”升级成了“管快照”。3. 架构搭建与落地实操3.1 整体架构设计从单节点到多节点共用存储池我在生产环境中的架构大概是这样的元数据引擎一套高可用 Redis主从架构专门存放目录树和文件属性。这里不建议用默认的单机 Redis元数据一旦丢失整个文件系统就挂了。数据持久层对象存储用的 MinIO 集群三节点同时也兼容 S3 API。这部分选择没有太多讲究云上直接用阿里云 OSS 或者 AWS S3 也完全可以。计算节点每个节点上都跑了一个 JuiceFS 客户端进程负责把 JuiceFS 文件系统挂载为本地路径比如/jfs。Sandbox 层面每个容器把/jfs/workspace/task_id挂载为自己的工作目录环境基础部分则挂载 Job 专属的只读快照。[沙箱容器A] - 挂载 /jfs/workspace/task_a (可写) [沙箱容器B] - 挂载 /jfs/workspace/task_b (可写) [沙箱容器A/B] - 挂载 /jfs/base_env_2024.12 (只读快照) | ---- JuiceFS 客户端 (FUSE) ---- 本地缓存 (NVMe SSD) ---- 元数据引擎 Redis ---- 对象存储 MinIO/S3这套架构下沙箱之间互相隔离、但共享同一份基础数据和存储池。文件权限通过 JuiceFS 的自定义 ACL 或就是 POSIX 标准权限位来管控。集中管理的好处是日志、中间结果、输出文件都沉淀在统一的位置后续做分布式训练的 checkpoint、做数据归集都很方便。3.2 JuiceFS 部署的数据规划JuiceFS 的部署其实不算复杂但有几个数据相关的规划细节要提前定好否则后面返工成本很高。存储容量规划需要评估的是对象存储的容量不是本地盘的容量。按照沙箱平均每次运行产生 500MB~2GB 数据、保留周期 7 天、日均任务数 1000 来估算一个月需要的存储大约是1000 × 1GB × 30 30TB再乘以 1.2 的冗余系数规划 40TB 左右比较稳妥。本地缓存容量规划这是性能的关键一般建议每个节点的缓存容量不小于单任务最大数据工作集的 1.5 倍。比如 Agent 任务最大数据集是 20GB那每个节点至少规划 30GB 以上用于缓存如果机器的 NVMe 空间充足可以往上加到工作集的 2~3 倍因为更大的缓存意味着面对短时间高并发任务时有更高的命中率沙箱启动的性能波动会小很多。并发规划需要估算元数据引擎的并发能力。Redis 的极限 QPS 通常在 10 万以上但受网络和客户端数量的影响实际要打折。一个 JuiceFS 客户端也就是一个计算节点保持几百个文件系统操作并发是很正常的只要节点数量不是几百台Redis 基本不会成为瓶颈。我这里再强调一句JuiceFS 的客户端缓存目录和数据存储目录一定要分开不要把缓存也丢到 JuiceFS 挂载点上否则会形成递归循环——这个问题我在最初测试时踩过Client 直接写不进缓存最终把挂载点撑爆了。3.3 关键配置与参数调优细节入门部署完 JuiceFS 后有几个配置参数对 Sandbox 场景尤其重要我列一下我的生产配置配置项我的取值用途与理由--cache-size51200约 50GiB本地缓存上限避免缓存无限制膨胀挤占磁盘空间--free-space-ratio0.1当磁盘剩余空间低于 10% 时自动清理缓存防止磁盘写满--cache-dir/data/juicefs/cache缓存目录强烈建议放在 NVMe SSD 上--writeback开启异步上传对沙箱内大量中间文件写操作友好避免每次写都等对象存储 RTT本地确认完就返回数据后台异步上传--multi-buffers默认即可多缓冲区优化在多线程写场景有明显效果--atime-modenoatime关闭访问时间更新减少元数据写入次数对沙箱这种大量读操作场景很有帮助--writeback这个参数我特别说一下。默认情况下JuiceFS 写入数据时是同步上传到对象存储的每次写都要经过一次网络 RTT。在沙箱里很多程序会频繁写小日志、临时文件同步上传会导致延迟偏高。开启 writeback 后写入先落到本地缓存确认成功后再异步上传这对缩短任务运行时间很有帮助。不过要注意writeback 模式意味着本地缓存里存在尚未上传到对象存储的数据如果节点宕机这部分数据有丢失风险。对 Agent Sandbox 的可丢弃中间文件来说可以接受但如果你的场景里数据持久性要求非常高建议保持默认的同步写模式。3.4 沙箱创建流程引入快照与克隆后的新链路引入 JuiceFS 之后我的沙箱创建流程也彻底重写了预先通过juicefs snapshot创建基础环境快照里面是预装好的 Python 环境、公共依赖库、常用模型缓存。新建任务时调度器调用juicefs clone把基础环境快照克隆出一份独立副本秒级完成底层是 COW不占额外空间只在写入时才复制数据块。沙箱容器启动时把克隆出来的目录挂载为工作目录。任务结束后执行清理时直接删除克隆出的目录只删增量块成本很低。这里面有个细节要注意juicefs snapshot创建的是只读快照多个 clone 可以共享同一份基础数据但 clone 出来的目录本身是可写的。所以多个沙箱可以各写各的副本互不干扰同时文件系统层面又能最大限度共享基础数据不产生复制开销。这正是 COW 的威力。3.5 首次实操跑通的完整流程如果你从来没上手过 JuiceFS可以从下面这个最小流程开始在本地或单台测试机上就能完整走一遍第一步安装客户端# 以 Linux x86_64 为例下载对应版本二进制 wget https://github.com/juicedata/juicefs/releases/latest/download/juicefs-version-linux-amd64.tar.gz tar -zxvf juicefs-version-linux-amd64.tar.gz sudo install juicefs /usr/local/bin juicefs --version # 确认安装成功也可以直接用容器镜像跑客户端但二进制方式更方便在集群节点上通过 Ansible 批量部署。第二步初始化元数据引擎# 要求 Redis 6.2建议 7.0 以上版本 juicefs format --storage s3 \ --bucket https://s3.region.example.com/juicefs-bucket \ --access-key KEY \ --secret-key SECRET \ redis://:passwordredis-host:6379/1 \ agent-sandboxagent-sandbox是给这个文件系统起的名称会在 Redis 里注册一个唯一的元数据存储空间。第三步挂载文件系统mkdir -p /jfs juicefs mount --cache-size 51200 --cache-dir /data/juicefs/cache \ --free-space-ratio 0.1 --writeback \ redis://:passwordredis-host:6379/1 /jfs挂载完成后/jfs就是一个普通 POSIX 文件系统df -h /jfs能看到容量对应对象存储的容量。第四步在沙箱里测试基本读写# 在宿主机上创建测试目录 mkdir -p /jfs/workspace/test-task echo hello juicefs /jfs/workspace/test-task/hello.txt # 启动一个容器把 /jfs 挂进去 docker run -it --rm -v /jfs:/jfs ubuntu:22.04 bash # 容器内直接读文件 cat /jfs/workspace/test-task/hello.txt到这里JuiceFS 的基本链路已经通了后面你就只需要把容器的工作目录/挂载方式替换成 JuiceFS 路径沙箱就可以在共享存储池上运行了。剩下的快照、clone、配额、权限控制按需逐步加上即可。4. 性能调优从能用到好用4.1 缓存策略调优命中率决定一切JuiceFS 在沙箱场景下性能上限基本由缓存命中率决定。我在 4.2 里给了很多具体参数这里把策略层面的思路也补充一下。Agent 任务的数据访问是典型的重复模式每次任务启动都要重新读取相同的基础依赖、相同的数据集。这天然适合用大缓存去承接。我建议把缓存命中率作为一个核心可观测指标用juicefs metrics或者挂在 Prometheus 上实时监控。当观察某个节点的缓存命中率长期低于 85% 时优先排查这两个方向一是缓存容量是不是小于任务工作集二是多个任务是否分散在大量不同节点上导致每个节点的缓存碎片化。如果多个任务工作集都很大、节点数量又多可以考虑按任务类型做节点亲和调度比如“所有用到数据集 A 的任务都调度到节点组 X”。这样能让一个节点的缓存反复为同一类任务服务命中率会非常可观。4.2 大文件与小文件并存场景的调参策略Agent Sandbox 里的访问模式是典型的混合场景加载模型权重是大文件顺序读Python 动态链接库和依赖是小文件随机读。JuiceFS 对这两类访问模式有不同的优化路径。大文件顺序读方面关键是让本地缓存能容纳尽可能多的热数据块所以--cache-size不要设得太小我给生产节点的建议是 100GB 起步如果节点上的数据工作集大可以进一步提高。小文件随机读方面关键在于元数据性能。小文件读取的性能瓶颈主要在元数据查询上Redis 的响应时间直接决定了文件 lookup 和 open 的延迟。这里有几个调优方向优先确保 Redis 部署在高主频 CPU 的机器上因为 90% 的元数据操作是纯 CPU 计算内存大小反而不重要。尽量使用 Unix Socket 方式连接本地 Redis如果元数据引擎和客户端同机部署可以减少 TCP 开销。这个只是锦上添花集群部署时通常还是走 TCP。注意--open-cache参数很适合读多写少的场景可以缓存文件打开后的属性信息减少重复元数据请求。但对频繁更新数据的 Agent 任务开太大可能出现“文件更新后旧数据被读到”的问题所以要结合业务性质来权衡。4.3 并发场景下的写放大控制沙箱里大量的中间文件写入如果配置不当会产生严重的写放大。这里有两个关键点第一JuiceFS 的默认分块大小是 4MiB块大小会影响小文件的存储效率。小文件多的时候每个文件至少占一个块如果块太大存储占用会很浪费。所以如果确定你的沙箱任务以小文件为主可以在 format 时指定--block-size40964MiB甚至更小。但要注意块太小会导致大文件读取时需要更多次对象存储请求所以要根据业务比例权衡。第二对象存储的请求并发限制。当大量沙箱同时写入时对象存储 API 的 QPS 可能被打满。JuiceFS 客户端有内置的--max-uploads参数可以控制并发上传数默认是 20。如果发现对象存储侧出现限流或 5xx可以适当降低这个值或者开启客户端 QoS 限制。反过来如果对象存储性能很充裕、写缓存压力很大可以适当调高来提升写吞吐。还有一个很多人会忽略的性能点JuiceFS 在挂载时支持--prefetch参数来设置顺序读的预取块数。对模型加载这种场景增大预取块数比如 8 或 16可以明显缩短大文件的读取时间但前提是缓存空间充足否则预取数据可能挤占热点数据的空间。4.4 读写放大与成本数据是怎么从沙箱落到对象存储的理解 JuiceFS 的读写路径对后续排查性能问题非常重要。我画一条链路帮大家理一下首次写入时沙箱内应用调用write()FUSE 将数据传给 JuiceFS 客户端客户端把数据按块大小切片先写本地缓存如果是 writeback 模式此时就返回成功然后后台异步把数据块上传到对象存储。同一时间客户端更新元数据引擎Redis里的文件大小、修改时间、数据块索引。首次读取时相反方向客户端从 Redis 查到数据块的位置判断本地缓存是否命中。命中就直接读缓存不命中则从对象存储拉取数据块同时写入本地缓存供后续访问。所以你可以这样理解JuiceFS 的性能表现和读缓存命中率、写缓存模式是强相关的。“放大”体现在数据块层面上文件被切成固定大小的块写入时如果不满一块也要按一块来记录索引所以小文件多了索引数量会变大Redis 内存占用也会上升。这也是为什么前面说小文件特别多的场景下要评估是不是要调小块大小、正常清理回收站目录。JuiceFS 有一个类似回收站的功能叫 Trash删除的文件会先在 Trash 里保留一段时间默认 1 小时。对沙箱这种高频创建删除临时文件的场景如果 Trash 里堆积了大量小文件Redis 的元数据会持续增长、影响查询性能。建议在 format 时根据业务容忍度设置合理的--trash-days我生产环境里设的是 0因为沙箱里的数据本身就可丢弃不需要进回收站。5. 常见问题与排查技巧实录5.1 沙箱启动变慢如何快速定位瓶颈如果你发现沙箱创建速度变慢先不要慌。我的排查顺序是第一步看本地缓存命中率。juicefs metrics会暴露所有客户端的缓存命中指标如果命中率骤降优先检查节点磁盘空间是不是满了缓存被部分清理。第二步看 Redis 元数据 QPS 和延迟。如果 Redis 的延迟从 0.2ms 涨到 2ms重点看慢查询日志通常是文件数量过多导致的 keyspace 膨胀。第三步看对象存储的响应时间。如果对象存储 P99 请求延迟过高需要检查是不是并行上传/下载任务过多导致资源竞争必要时调低客户端的并发参数或者增加对象存储集群节点。我遇到过一次典型的启动慢案例查到最后是 MinIO 的磁盘因为另一个业务占满了 IO对象存储整体响应变慢所有缓存未命中的沙箱全部等待数据回源故障表现就是沙箱 P99 启动时间从 2 秒涨到了 22 秒。所以这里也给一个建议对象存储与其他存储业务最好隔离部署避免互相影响。5.2 文件可见性延迟read-after-write 一致性有一个问题在社区里比较常被提到写入 JuiceFS 之后立刻读取偶尔会读不到最新数据。这可能是因为你在多个节点上同时挂载了同一个 JuiceFS 文件系统而某些节点上的缓存还没失效。JuiceFS 在一致性方面确实有取舍元数据操作默认是强一致的每次都会实时查 Redis但文件数据访问在开启了缓存的情况下存在秒级到几十秒的窗口期。对于 Agent Sandbox 来说如果你在同一个任务进程中先写后读一般没问题但如果是跨节点节点 A 写入节点 B 读取就需要小心。解决办法有几个在读取端关闭缓存或调低--open-cache的缓存有效期。在任务调度层做数据同步屏障比如写入完成后等 1 秒再让下游读取。更省事的方案是把要求强一致的数据写在“可丢弃”的 semantics 之外直接用唯一命名的文件路径从根上规避旧缓存误用。比如文件名带时间戳/任务 ID不要复用同一个文件名。5.3 Redis 内存为什么会持续上涨JuiceFS 的元数据引擎使用 Redis而 Redis 占用的内存与文件系统的文件数、目录数、chunk 数强相关。Agent 沙箱任务每天都在创建销毁大量文件如果没有及时清理Redis 内存会持续上涨。如果你发现 Redis 内存涨得很快按这个顺序排查查看是否开启 Trash 且保留时间太长。Trash 中的文件元数据仍占 Redis 内存建议调短--trash-days或直接设为 0。查看容器或任务退出时是否正确清理了工作目录。有时候沙箱销毁后目录没有正常删除多次积累后产生海量孤儿文件。考虑客户端定期执行juicefs gc。它会清理无引用的数据块和过期的元数据对控制元数据引擎内存有帮助。建议先小规模执行一遍观察对线上任务的影响再在低峰期全量执行。5.4 常见问题速查表问题可能原因处理方式挂载后ls卡死Redis 连接异常或负载过高检查 Redis 监控与慢查询确认网络连通性写入吞吐低本地缓存盘 IO 饱和 / 对象存储限流增大缓存盘吞吐检查对象存储侧 QPS 配额多个节点看到的文件大小不一致客户端缓存未刷新调小--open-cache时长或使用close-to-open一致性策略JuiceFS 企业版支持沙箱删除文件后磁盘空间没释放Trash 中的文件仍占空间调小--trash-days或手动清空回收站启动大量沙箱时报 “no space left”节点本地缓存目录满了检查--free-space-ratio设置调大缓存清理阈值JuiceFS 客户端进程内存过高缓存索引、writes backlog 堆积调小--max-uploads控制写并发必要时升级客户端版本5.5 线上故障复盘一次由缓存目录引发的雪崩最后分享一个特别值得写的真实故障。某次线上发布时我在新扩容的节点上忘了配置--cache-dirJuiceFS 默认把缓存写到了/var/jfsCache。而/var所在分区恰好是系统盘空间很小。高峰来临时大量沙箱同时写入系统盘瞬间被缓存写满。接下来发生的事很有启发JuiceFS 进程检测到磁盘空间不足后会不断尝试清理缓存来释放空间但新数据写入的速度远大于清理速度客户端陷入反复清理-写入的循环文件系统整体卡顿最终导致该节点所有沙箱任务超时。复盘后我做了两个改进在所有节点的部署脚本里强制指定--cache-dir到独立的大容量数据盘并配置 Prometheus 告警监控缓存目录磁盘使用率超过 80% 就告警。把节点初始化脚本加入自动校验检查juicefs mount的参数中是否包含期望的缓存路径防止后续新节点上线又忘记配置。这类“小配置引发大故障”的问题是分布式系统里最容易被忽视的在规模化阶段尤其致命。建议你上线前专门做一次配置审计把每个 mount 参数都过一遍。5.6 给新接入团队的三条避坑建议如果你团队刚开始准备引入 JuiceFS 来做 Sandbox 存储这几条经验可以先写进你的项目计划里一是不要贪图省事直接拿单机 Redis 当元数据引擎。我之前在测试环境用的单机 Redis集群一上量就出现元数据中断排查半天发现是 Redis 的maxmemory不够、触发了淘汰策略导致部分目录项丢失。直接上一套 Redis 主从 持久化成本没高多少但稳定性质的提升。二是一定要预留足够的本地缓存空间。很多团队低估了缓存的重要性只分给 JuiceFS 20GB结果沙箱实际工作集是 80GB缓存命中率上不去所有访问都回源到对象存储性能不比 NFS 好很多。要想让 JuiceFS 真正发挥性能优势缓存不低于工作集的 1.5 倍这是个经验阈值。三是权限模型要在上线前设计好。JuiceFS 默认的权限是 POSIX uid/gid 体系但沙箱场景往往要面对多租户、多团队的情况。我建议一开始就规划好用户映射关系每个团队用固定的 uid/gid 范围JuiceFS 挂载时通过--subdir限制每个团队只能看到自己的目录段比上线后再改权限模型要省事得多。6. 这种方案还能用在哪里以及后续扩展空间在做完 Agent Sandbox 的存储底座之后我发现 JuiceFS 在这个场景中沉淀下来的能力其实可以平滑迁移到其他邻域。比如开发测试环境的共享缓存、CI/CD 流水线的中间产物存储、以及训练数据的多节点热加载都是同一个套路底层对象存储负责容量本地缓存负责性能元数据服务保证一致性。后续如果想继续往下做我觉得有几个方向值得一试用 Kubernetes CSI Driver 来管理 JuiceFS 挂载这样 PV/PVC 的生命周期就可以完全交给 K8s沙箱的创建销毁可以更自动化。把基础环境做成 JuiceFS 快照模板配套一个版本管理工具这样 Agent 环境升级、回滚都能走 GitOps 的流程。考虑引入 JuiceFS 的分布式缓存模式在计算集群和对象存储之间加一层独立的缓存集群解决大规模并发下热点数据回源的问题。不过这些都是后话了先把 Sandbox 存储底座做稳把上面的故障排查手册传给团队已经是比我最初上线时要稳健得多的状态。至少现在我不用再半夜爬起来处理“磁盘满了”告警了这大概就是这轮改造最大的收益。