阿里云沙箱快照将收费：Agent 长任务开始拥有“存档点”

阿里云宣布，云沙箱 Snapshot 将于北京时间 2026 年 9 月 7 日 00:00 起正式商业化计费，中国内地磁盘单价为 0.0021 元 / GiB / 时，海外区域单价为 0.001672 元 / GiB / 时。

Snapshot 是一种能够保存运行中沙箱完整状态的云服务能力，保存内容不仅包括磁盘文件，还包括内存状态。沙箱恢复后，可以继续使用快照创建时的运行环境，而不必从操作系统启动、依赖安装和任务初始化重新开始。

这项变化看起来只是一次计费调整，但它对应的是 Agent 基础设施的一次重要转向：云沙箱不再只是一次性执行代码的临时容器，而开始具备类似虚拟机“存档、读档、复制分支”的运行方式。

Snapshot 到底保存了什么

Snapshot 保存的是沙箱在某个时间点的全状态，包括内存和磁盘，而不是单纯打包一份文件系统。

传统的环境镜像通常解决的是“如何重新创建一个环境”，例如把基础镜像、依赖包、代码和配置文件重新部署到一台新实例中。Snapshot 解决的则是“如何回到某个已经运行到一半的现场”：进程状态、内存中的上下文、已经生成的中间文件，以及沙箱内部的运行进度，都可以随状态一起保存。

两者的差异可以类比为“重新安装软件”和“保存游戏进度”。前者可以恢复环境，却未必能恢复任务现场；后者保存的是任务执行到某一刻的完整状态。对需要连续运行几十分钟甚至数小时的 Agent 来说，后者更有价值。

阿里云目前披露的核心能力包括三类：

• 全状态快照：对运行中的沙箱执行快照，内容包含内存和磁盘。
• 秒级恢复：基于快照恢复沙箱，减少重新启动和初始化环境的等待时间。
• 并行克隆：从同一个快照克隆出多个新沙箱，用于并行探索不同执行路径。

需要注意的是，官方资料给出的“秒级”描述针对的是恢复和克隆能力，并不等同于所有任务都能在固定一秒内完成。实际耗时仍可能受到快照体积、区域、实例规格、并发量和调度状态影响。

对 Agent 最直接的价值：长任务可以断点续跑

Snapshot 最适合的场景，是那些失败成本高、执行链路长、又无法简单重试的 Agent 任务。

一个代码 Agent 可能需要先读取仓库，再分析依赖，运行测试，修改多个文件，启动服务，最后执行浏览器测试。任务执行到第 40 分钟时，如果因为网络抖动、工具调用异常或上下文状态错误而失败，传统做法通常是重新启动一个环境，再次执行前面的步骤。

这类重试不只是浪费模型调用次数，也会浪费计算资源和工程师等待时间。更麻烦的是，某些任务具有非确定性，重新执行时可能得到不同的依赖版本、不同的中间结果，甚至走上另一条推理路径。

有了 Snapshot，Agent 平台可以在关键节点创建快照。例如，完成依赖安装后保存一次，完成代码扫描后保存一次，完成测试环境初始化后再保存一次。一旦后续步骤失败，任务可以从最近的快照恢复，而不是从零开始。

这种机制尤其适合以下任务：

1. 长时间代码执行：包括大型项目构建、测试套件运行、数据预处理和编译任务。
2. 多轮工具调用：Agent 需要连续操作终端、文件系统、浏览器和数据库，任何一步失败都可能影响后续流程。
3. 交互式开发环境：用户暂停任务后，稍后继续使用原来的进程和上下文。
4. 带中间状态的科学计算：计算已经运行数小时，但还没有产出最终结果时，可以保存当前进度。
5. 需要人工审核的自动化流程：Agent 完成一阶段工作后暂停，人工确认后从原状态继续。

这里的关键不是“能不能重试”，而是“重试时需要付出多少代价”。Snapshot 把 Agent 任务从一次性流水线，变成了可以暂停、恢复和回滚的状态机。

并行克隆比普通扩容更适合 Agent 探索

并行克隆是 Snapshot 对 Agent 工作流的另一项重要价值，它允许多个沙箱从同一个中间状态出发，分别探索不同方案。

假设一个 Agent 已经完成了项目分析，并确定需要修改三处核心逻辑。平台可以先保存当前沙箱状态，再从这个状态克隆出多个副本：一个尝试最小改动，一个重构模块边界，一个使用不同算法。每个副本都拥有相同的初始文件、进程和运行环境，后续执行互不影响。

这与简单地启动三个新容器不同。新容器通常需要重新拉取镜像、安装依赖、复制代码和执行初始化脚本；Snapshot 克隆直接从已经准备好的运行现场派生分支。对于环境较重、初始化步骤较多的任务，节省的可能不只是启动时间，还包括大量重复计算。

并行克隆还可以服务于模型评测和 Agent 轨迹搜索。平台可以让多个 Agent 从同一个状态开始，分别尝试不同提示词、工具策略或代码修改方案，最后根据测试结果选择表现最好的分支。

不过，克隆并不意味着多个副本可以无条件共享所有资源。数据库连接、网络服务、临时凭证、随机数种子和外部文件锁都可能带来状态隔离问题。使用 Snapshot 做并行探索时，平台仍需要处理副本之间的资源命名、端口分配、数据写入隔离和外部副作用控制。

计费规则：内存会被按两倍计入存储用量

Snapshot 的计费并不是只按照磁盘大小计算，内存规格会以两倍权重计入 Snapshot 存储空间用量。

阿里云公布的计算方式如下：

Snapshot 存储空间用量 = 内存规格 × 2 + 磁盘规格

Snapshot 费用 = Snapshot 存储空间用量 × 磁盘单价 × 存储时长

其中，内存规格和磁盘规格均以 GiB 计算，存储时长按小时计算。中国内地和海外区域采用不同的磁盘单价。

| 计费项目 | 中国内地 | 海外区域 | |---|---:|---:| | 磁盘单价 | 0.0021 元 / GiB / 时 | 0.001672 元 / GiB / 时 | | 计费对象 | Snapshot 存储空间 | Snapshot 存储空间 | | 内存计入方式 | 内存规格 × 2 | 内存规格 × 2 | | 是否包含磁盘规格 | 是 | 是 | | 计算周期 | 按小时 | 按小时 |

举例来说，一个沙箱配置为 8 GiB 内存和 40 GiB 磁盘，那么 Snapshot 存储空间用量为：

8 × 2 + 40 = 56 GiB

如果该 Snapshot 存储在中国内地，理论小时费用为：

56 × 0.0021 = 0.1176 元 / 时

按 30 天、720 小时计算，费用约为：

0.1176 × 720 = 84.672 元

同样规格的 Snapshot 如果存储在海外区域，理论小时费用约为 0.093632 元，按 720 小时计算约为 67.415 元。上述计算只反映 Snapshot 功能本身的存储费用，不代表云沙箱实例、计算资源、网络流量或其他云服务费用。

| 示例配置 | Snapshot 用量 | 中国内地每小时 | 中国内地按 30 天估算 | |---|---:|---:|---:| | 4 GiB 内存 + 20 GiB 磁盘 | 28 GiB | 0.0588 元 | 42.336 元 | | 8 GiB 内存 + 40 GiB 磁盘 | 56 GiB | 0.1176 元 | 84.672 元 | | 16 GiB 内存 + 100 GiB 磁盘 | 132 GiB | 0.2772 元 | 199.584 元 |

对 Agent 平台而言，真正需要关注的不是单个 Snapshot 每小时几分钱，而是快照数量、保留时长和内存规格的乘积。一个平台如果为每个任务保存多个检查点，再为每个检查点保留数十个并行分支，成本会随着任务规模快速累积。

这项收费对开发者意味着什么

Snapshot 商业化后，快照生命周期管理会成为 Agent 平台的基础运维工作。

第一，开发者需要区分“恢复点”和“归档点”。恢复点是为了短期失败重试，通常只需要保留最近几个；归档点则可能用于审计、复现或长期保存。两者的保留周期不同，不应采用同一套策略。

第二，开发者需要控制快照创建频率。每次工具调用后都创建快照，虽然可以降低失败后的回滚距离，但也会增加存储成本和管理复杂度。更合理的做法，是在依赖安装完成、关键阶段结束、人工审核前和高风险操作前创建快照。

第三，开发者需要为克隆副本设置自动过期时间。并行探索的副本往往只在评测阶段有价值，任务完成后应立即清理未选中的分支。否则，短期实验可能转化为持续计费的闲置资源。

第四，开发者需要把快照和任务元数据绑定。一个可用的任务管理系统至少应记录快照创建时间、对应代码版本、Agent 配置、工具权限、数据版本和恢复原因。只有这样，恢复出来的沙箱才具备可解释性，而不是一个“能启动但不知道为什么存在”的黑盒状态。

第五，敏感数据必须纳入安全审查。因为 Snapshot 包含内存状态，内存中的令牌、临时文件内容、用户输入和进程上下文都有可能被一并保存。即使这些内容没有落盘，也不能简单地假设它们不会进入快照。涉及生产凭证、个人信息或高敏感业务数据时，需要明确快照的访问控制、保留期限和删除机制。

与镜像、检查点和容器重启怎么选

Snapshot 适合保存“正在运行的现场”，但它不是所有场景下的最佳方案。

| 方案 | 保存内容 | 恢复速度 | 适合场景 | 主要限制 | |---|---|---|---|---| | 环境镜像 | 操作系统、依赖和文件系统基线 | 通常需要重新启动和初始化 | 标准化部署、批量创建环境 | 不保存进程内存和任务进度 | | 应用层检查点 | 由应用自行保存的中间数据 | 取决于应用加载逻辑 | 训练任务、数据处理、可控计算流程 | 需要应用主动支持，改造成本较高 | | 容器重启 | 容器文件和可持久化数据 | 较快，但通常要重新初始化进程 | 无状态服务、短任务 | 无法完整保留运行中的内存状态 | | Snapshot | 内存与磁盘等沙箱运行状态 | 官方定位为秒级恢复或克隆 | 长任务 Agent、交互环境、并行探索 | 需要承担快照存储费用和状态管理复杂度 |

从产品定位看，Snapshot 更接近面向 Agent 的“运行时检查点”，而不是传统意义上的镜像仓库。它的优势在于保留进程级现场，代价则是快照更依赖具体运行环境，生命周期和安全管理也更复杂。

商业化前创建的快照也会开始计费

2026 年 9 月 7 日 00:00 是此次计费生效的明确时间点，商业化前已经创建的 Snapshot 也会从该时间开始进入计费范围。

这意味着，开发者不能只检查 9 月 7 日之后新建的快照。此前为了测试、压测或验证功能而创建的 Snapshot，只要继续保留，就可能产生费用。阿里云建议用户在商业化生效前释放不再使用的 Snapshot 资源。

在计费生效前，建议至少完成以下检查：

• 列出全部 Snapshot，确认所属项目、区域、创建时间和关联任务。
• 删除已经完成验证、没有恢复价值的临时快照。
• 为仍需保留的快照记录用途和预计删除时间。
• 检查快照对应的内存和磁盘规格，估算长期保留成本。
• 为并行克隆任务设置清理流程，避免副本无限期存在。
• 对包含敏感信息的快照重新评估访问权限和保存周期。

判断：它解决的是 Agent 落地中的“可恢复性”问题

Snapshot 的商业价值不在于把沙箱启动速度再缩短一点，而在于让 Agent 任务具备更接近生产系统的容错能力。

当前很多 Agent 演示可以在几分钟内完成，但真正进入开发、运维和企业流程后，任务往往会变长，工具调用会变多，外部依赖也会变复杂。只要任务持续时间足够长，“失败后从头再来”就会成为明显的成本来源。

Snapshot 把一次长任务拆成多个可恢复阶段，并让同一个阶段能够派生出多个执行分支。这对代码修复、浏览器操作、数据分析、自动化运维和模型评测都有现实意义。特别是在需要让多个 Agent 探索不同路径时，快照克隆比重复初始化一批全新环境更符合运行效率的要求。

但它也不是免费的性能开关。内存按两倍计入存储用量，意味着高内存沙箱会比直觉中更快累积费用；快照保存的状态越多，生命周期管理和安全审计越重要；并行克隆越方便，越需要配套的副本清理和外部副作用隔离。

因此，Snapshot 更适合已经开始处理长任务、失败重试和并行探索的 Agent 团队，而不是所有短脚本都默认开启的基础能力。对于运行时间只有几秒或几分钟、可以快速重建环境的任务，镜像和应用层检查点可能更经济；对于需要保留复杂运行现场的任务，Snapshot 的价值会明显上升。

阿里云此次将云沙箱 Snapshot 推向商业化，释放出的信号很清晰：Agent 基础设施正在从“把模型放进沙箱里执行”，走向“管理一组可暂停、可恢复、可复制的运行状态”。当 Agent 真正开始承担长链路工作时，能否在失败后回到现场，可能比单次执行速度更决定系统是否可用。

参考来源

• IT之家：阿里云 Snapshot 云沙箱快照功能下月 7 日起商业化计费：提供商业化时间、区域单价、计费公式及存量快照计费说明。