Agent Sandbox 极速版支持以存储卷 Volume 和动态挂载两种方式将外部存储挂载到 Sandbox，使数据跨 Sandbox 生命周期保留并支持多任务复用。
概述
Agent Sandbox 极速版支持将外部存储挂载到 Sandbox，使任务产生的数据能够跨 Sandbox 生命周期保留，并支持多个任务复用已有数据。
当前持久化存储主要提供以下两种挂载形态：
存储卷：将已有存储资源的挂载配置保存为可管理、可授权、可复用的云沙箱资源——Volume，使用时按 Volume 名称引用。
动态挂载：已有存储资源的挂载配置不会被保存为独立的资源，而是在每次请求过程中直接传入挂载配置，即直接挂载存储资源。
存储卷和动态挂载都可以在创建 Sandbox 时挂载，也可以在 Sandbox 运行后追加挂载。
存储卷 Volume
Volume 是云沙箱中用于保存存储挂载配置的独立资源。每个 Volume 保存已有存储资源（OSS、AgenticFS、AgenticBucket 或 JuiceFS）的挂载配置，具有名称、Team 归属和权限控制，业务应用可以按名称引用 Volume，而不需要在每次请求中重复提供完整存储挂载配置。同时，Volume 支持在创建 Sandbox 时挂载，亦可在 Sandbox 运行后追加挂载。
存储卷 Volume 涉及以下三个对象：
Volume：上层对外统一抽象，描述目标存储位置、访问范围、挂载方式等信息，是可以单独管理和授权的云沙箱资源。
底层存储：实际保存数据的持久化存储资源，例如 OSS Bucket、AgenticFS、AgenticBucket 或 JuiceFS。
本地挂载目录：Sandbox 内用于访问底层数据的本地路径。挂载成功后，应用可以像访问本地目录一样读写远端数据。
创建 Volume 不会创建或复制底层存储资源。
释放 Sandbox 或删除 Volume 也不会删除底层存储中的数据。
底层数据的保留和清理由业务侧负责，相关保留策略和清理操作需要通过对应存储服务单独配置或执行。
资源归属与权限管理
Volume 的权限模型包含管理权限、Team 归属和底层数据访问三个层面，企业可以据此划分运维团队和业务团队的职责，运维管理操作由 RAM 授权并按 Team 限定范围，业务人员只使用已配置的 Volume，不承担其生命周期管理。
管理权限
Volume 的创建、查询和删除等操作通过阿里云 OpenAPI 或 控制台 完成，由调用身份的 RAM 权限控制。企业可以分别授予所需的 Volume 管理权限，并按 Team 限定可管理的 Volume 资源范围。
例如，运维负责人可以负责目标 Team 的 Volume 创建和删除，普通运维人员仅具备查询 Volume 的权限。业务人员使用已配置好的 Volume，无需为了挂载存储而分配 Volume 的创建或删除权限。
Team 归属
Volume 属于指定 Team，同一 Team 内 Volume 名称不能重复。挂载 Volume 时，API Key、Sandbox 与 Volume 必须属于同一 Team，不支持跨 Team 引用。API Key 与 Team 的关系参见API Key 管理。
企业可以按团队、业务或环境规划 Team，将对应 Volume 纳入相应 Team 管理。Team 归属限定云沙箱资源的使用范围，实际数据访问范围还取决于 Volume 指向的存储资源和底层授权。
底层数据访问
Sandbox 的执行 RAM Role（下文简称执行 Role）需要具备访问目标存储的权限。挂载时，云沙箱通过执行 Role 获取 STS 临时凭证，并根据 Volume 配置收缩其权限范围。最终有效权限不会超过执行 Role 的授权范围，具体权限边界因存储类型而异。
OSS Volume 和 AgenticFS Volume 的权限边界有所区别：
OSS Volume：通过 Bucket 和对象前缀确定存储范围，通过只读配置指定读写模式。例如，将 Volume 配置为只读访问某个输入数据前缀，挂载时生成的 STS 临时凭证会限制在相应对象范围和读取操作内。
AgenticFS Volume：Access Point 绑定的目录决定权限边界。Access Point 下的子目录用于指定要访问的远端目录，但不能进一步收缩 STS 临时凭证的权限范围。需要按用户或租户隔离数据时，应为各隔离单元配置独立的 Access Point。
精细化数据权限规划需要同时确定 Volume 的 Team 归属和底层存储的权限边界。具体说明参见创建 OSS Volume和创建 AgenticFS Volume中的权限说明。
相关文档入口
存储卷目前支持以下几种类型，各类型的开通条件、权限配置、SDK 和模板要求，以及挂载验证与故障排查方法，参见对应操作文档：
Volume 类型 | 创建 | 挂载 | 追加挂载 |
OSS Volume | |||
AgenticFS Volume | |||
AgenticBucket Volume | |||
JuiceFS Volume |
动态挂载
动态挂载允许业务应用根据任务需要，将 OSS、AgenticFS、AgenticBucket 或 JuiceFS 等外部存储直接挂载到 Sandbox，而不需要提前创建 Volume。挂载成功后，应用可以通过 Sandbox 内指定的本地目录访问底层数据，无需将存储位置预先固化到 Sandbox 模板中。
资源归属与权限管理
在管理权限、Team 归属及底层数据访问方面：
动态挂载配置随请求直接提供，不会保存为独立的云沙箱资源。因此，动态挂载配置本身不具有名称、资源身份或生命周期，也不涉及 Volume 的创建、查询和删除等资源管理操作，不能像 Volume 一样通过 RAM 对挂载配置进行独立的资源级权限控制。
动态挂载配置本身没有 Team 归属，底层存储仍属于 OSS、AgenticFS、AgenticBucket 或 JuiceFS 等对应的云产品。
无论直接提供挂载配置还是引用 Volume，Sandbox 的执行 RAM Role 都需要具备访问目标存储的权限。挂载时，云沙箱通过执行 Role 获取 STS 临时凭证，并根据存储挂载配置进一步收缩其权限范围。最终有效权限不会超过执行 Role 已有的授权范围，挂载配置只能限制权限，不能扩大权限。
相关文档入口
各存储类型的前提条件、挂载参数、代码示例、验证方法及故障排查，参见对应操作文档。
存储类型 | 对应文档 | 说明 |
OSS | 创建 Sandbox 时直接配置 OSS 挂载。 | |
向运行中的 Sandbox 追加OSS挂载。 | ||
AgenticFS | 创建 Sandbox 时直接配置 AgenticFS 挂载。 | |
向运行中的 Sandbox 追加 AgenticFS 挂载。 | ||
AgenticBucket | 创建 Sandbox 时直接配置 AgenticBucket 挂载。 | |
向运行中的 Sandbox 追加 AgenticBucket 挂载。 | ||
JuiceFS | 创建 Sandbox 时直接配置 JuiceFS 挂载。 | |
向运行中的 Sandbox 追加 JuiceFS 挂载。 |
Volume 与动态挂载的区别
Volume 与动态挂载的主要区别在于挂载配置是否作为独立资源进行管理和授权：Volume 将存储挂载配置保存为独立的云沙箱资源，通过 Volume 名称进行引用；动态挂载则是在请求过程中直接挂载存储资源，中间少了一层抽象。详细区别如下：
对比项 | Volume | 动态挂载 |
资源形态 | 独立云沙箱资源，具有独立身份、Team 归属和权限控制。 | 非独立云沙箱资源，没有独立身份、Team 归属及权限控制。 |
配置方式 | 预先将存储位置、访问范围和挂载方式等保存为 Volume，使用时按名称引用。 | 在请求中直接传入挂载配置。 |
管理权限 | Volume 的创建、查询和删除由 RAM 控制。 | 受 Sandbox 操作权限和底层存储权限约束。 |
配置复用 | 多个任务可以引用同一 Volume。 | 动态挂载配置通常随单次任务生成。 |
适用场景 | 企业需要集中配置数据访问范围、划分资源管理职责，或多个任务使用一致的存储配置。 | 挂载配置随任务变化，无需保存为独立资源。 |
支持地域
存储卷（Volume）和动态挂载对应支持的地域相同，但不同存储类型略有差别：
AgenticFS 和 AgenticBucket 目前为白名单开放功能，如需使用，请向对应存储产品提交工单申请。
存储类型 | 地域 |
OSS | 请参考开服地域。 |
AgenticFS | 华东1（杭州）、华东2（上海）、华北2（北京）、中国香港、新加坡、马来西亚（柔佛州）。 |
AgenticBucket | 华东1（杭州）、华东2（上海）、华北2（北京）。 |
JuiceFS | 请参考开服地域。 |