▶ 原文链接

从 fork() 到舰队：设计一个智能体沙箱云

来源： AI Engineer | Abhishek Bhardwaj | Jul 13, 2026 播客： AI Engineer 分类： OpenAI 原文发表： Jul 13, 2026 纪要生成： 2026-07-20

---

嘉宾/话题简介

Abhishek Bhardwaj 是 OpenAI 强化学习与智能体基础设施团队的成员，曾参与 Google 的 CrosVM 项目。本集演讲从第一性原理出发，系统性地探讨了为什么需要沙箱、如何在单节点上安全运行不可信代码（如 ChatGPT 或 Codex 生成的代码），并深入解析了从简单的 fork() 调用逐步演进到基于硬件的微虚拟机的完整逻辑链。此外，他还详细阐述了基于 写时复制 的快照持久化方案，以及如何构建大规模、低延迟、高可靠的智能体沙箱云。

---

分节详述

为什么模型需要执行代码

本节重点

• 大模型在数学和代码推理上存在天然缺陷，仅靠预训练无法解决所有可验证奖励问题。
• 赋予模型工具调用能力，通过代码执行来获取可验证的奖励，是其逻辑推理能力的关键突破。
• 这种模式从训练侧延伸至产品侧，引发了对代码运行环境的迫切需求。

详细精要

• 模型推理的局限性与工具调用的突破：虽然大模型在“3+3”这类被互联网广泛记录的问题上表现良好，但对于“strawberry 有几个 r”这类少见问题，模型极易出错。
• 根本原因在于模型受限于训练数据的分布，缺乏实时计算与验证机制。
• 解锁这一难题的关键是赋予模型工具调用能力，让它能生成并执行代码。

• 对于任何具有可验证奖励的问题（即能通过程序判定真伪），模型可以通过执行代码并在环境中验证结果来实现“爬坡”优化，从而在数学、代码等领域表现优异。

• 训练侧的代码执行流程：在强化学习训练循环中，工具调用是核心组件。

• 训练循环提供任务或问题给模型，模型生成包含代码执行指令的响应。
• Harness（训练脚手架）负责解析模型响应并实际执行代码。
• Grader（评分器）评判执行结果的正确性，并将奖励信号回传以更新模型权重。

• 这一过程不仅训练模型何时调用工具，也确保了生成的代码确实能解决问题。

• 产品侧的代码执行需求：训练出的能力必须与产品侧的支持相匹配。

• 在产品侧（如 Codex Web 或 ChatGPT），Harness 同样负责解析并执行工具代码，但不再有训练循环。
• 这些代码可能运行在用户的笔记本电脑上，也可能运行在云的某个节点上。
• 尽管我们能预期模型生成的大多是非恶意代码，但良好的安全实践要求保护宿主机环境（无论是个人设备还是云节点）免受蓄意攻击或无意破坏。攻击可能包括提权获取 root 权限或利用内核漏洞。模型在极度热心地帮助用户时，甚至可能意外尝试提权。

💬 精华片段（中文）

"The key unlock was that given the model tool calling capability or a way to execute code, the model gets these verifiable reward questions around code and math correctly."

"关键的解锁点在于，赋予模型工具调用能力或执行代码的途径后，模型就能正确解答这些围绕代码和数学且具有可验证奖励的问题。"

沙箱的必要性与核心支柱

本节重点

• 沙箱是限制不可信代码、保护宿主机和数据安全的隔离环境。
• 研究场景和产品场景对沙箱的需求侧重点不同。
• 运行时的安全性、延迟、吞吐量和可靠性是沙箱云设计的三大支柱。

详细精要

• 沙箱的定义与价值：为了运行模型生成的不可信代码，必须引入沙箱。
• 沙箱是一种受控的隔离环境，允许模型代表用户执行工具调用和代码，而不会攻击底层系统或窃取其他用户数据。
• 在云端，一个节点可能运行多个沙箱，没有隔离机制可能导致用户数据泄露等灾难性后果。

• 当前很多智能体（如 Open Claw）在本地运行，这既是对过去 20 年云计算发展的讽刺，也预示着未来云端部署的必然趋势。持久化、长时间运行的云端智能体才是未来方向。

• 研究与产品场景的需求差异：虽同需沙箱，但优化目标各异。

• 研究场景：极度强调吞吐量。需要大规模并行训练和生成大量 Rollout（对同一任务的不同回答尝试），以低成本获得高数量级的尝试。
• 产品场景：极度强调延迟。任何成功的产品都必须极快，如果沙箱启动慢或代码执行慢，会导致用户流失。
• 可靠性：对两者都至关重要。失败的任务等于浪费珍贵的 GPU 算力，目前 GPU 如同“黄金”一样珍贵。

• 安全性：同样重要。在训练侧，未对齐的模型如果提权可能攻击 OpenAI 基础设施，窃取模型权重；在产品侧，可能渗透基础设施或窃取用户数据。

• 设计沙箱云的三大支柱：本次演讲将聚焦于以下三点。

• 运行时：如何在单个节点上安全地运行沙箱。
• 持久化：赋予沙箱一个可持久化的“硬盘”，使其成为真正的知识工作者，而非一次性计算实例。
• 编排：如何在 ChatGPT 或 Codex 级别的大规模下，可靠地调度与管理海量沙箱。

💬 精华片段（中文）

"If you fail constantly, you've wasted like GPU tokens on both sides. And GPU is like gold right now."

"如果你经常失败，你就浪费了双方珍贵的 GPU 算力。GPU 现在就跟黄金一样。"

Linux 代码执行与攻击面分析

本节重点

• 线程是 Linux 的最小执行单元，通过系统调用请求内核服务。
• CPU 存在 Ring 0（内核模式）和 Ring 3（用户模式）的权限分级。
• Linux 系统面临两大攻击向量：提权获取 root 和执行内核模式漏洞。

详细精要

• Linux 的执行模型：理解沙箱必须先从 OS 运行原理出发。
• 线程是 Linux 中最小的执行单元。
• 内核通过系统调用为线程提供访问硬件等特权资源的接口。

• 当用户空间程序需要访问特权资源时，会执行特权指令触发上下文切换，将 CPU 从低权限状态切换至高权限状态。

• CPU 的权限分级与攻击面：处理器通过 Ring 实现权限控制。

• Ring 0：权限最高，运行内核模式代码。
• Ring 3：权限较低，运行用户模式代码。
• 攻击向量一：获取 root 权限。攻击者仍处于 Ring 3，但成为了系统上最高权限的用户，可读取 SSH 私钥、加密数据等几乎任何系统文件。
• 攻击向量二：内核模式漏洞。在 Ring 0 中执行恶意代码，这是灾难性的，攻击者可以转储进程内存。一旦发生，这将是“登上《纽约时报》”级别的安全事件。

💬 精华片段（中文）

"If you get kernel exploit, it's like it's a New York Times article waiting to happen."

"一旦你被内核攻击利用成功，那基本上就是等着上《纽约时报》头版的重大安全事件了。"

方案演进：从 fork-exec 到 gVisor

本节重点

• fork-exec 是最快但最不安全的方案，存在严重的安全和噪音邻居问题。
• 容器通过命名空间和 cgroup 实现资源隔离与控制，但仍共享宿主机内核，存在攻破边界风险。
• gVisor 通过用户态内核拦截系统调用，增加了攻击难度，但理论上仍存在连锁攻破宿主机内核的可能。

详细精要

• 方案 1：裸 fork + exec。这是最简单的工具执行模型。
• 工作原理：API 服务器为每个工具调用 fork 一个新进程，然后用 exec 执行模型所需的工具。
• 优点：性能最高，原生性能，几乎没有额外开销。

• 缺点：

  • 安全问题：派生的进程可以直接与宿主机内核通信，模型可以尝试攻击内核、提权或利用漏洞。
  • 噪音邻居问题：如果模型在一次工具调用中执行一个 while 循环并不断 fork 子进程，会耗尽节点资源，导致其他工具调用无法运行，整个节点瘫痪。

• 方案 2：容器。利用 Linux 内核特性加强隔离。

• 命名空间：提供资源隔离。例如，在 PID 命名空间内，进程认为自己是 PID 1，但宿主机看来只是普通进程；在挂载命名空间内，可以挂载文件系统而宿主机上看不到。这使得一个容器内的进程无法轻易干扰其他容器的资源视图。
• Cgroup：提供资源控制。可以限制一个容器组能消耗的 CPU、内存等资源量，有效防止“while+fork”这类操作拖垮整个节点。

• 核心缺陷：容器本质上是共享同一个宿主机内核的进程。尽管资源视图被隔离，但容器内的进程仍可直接对宿主机内核发起系统调用，尝试获取整个宿主机的 root 权限或利用内核漏洞。Seccomp 可通过过滤系统调用来减小攻击面，但预先定义白名单很困难，会严重限制模型的创造能力，反馈循环不佳。

• 方案 3：gVisor。将安全边界提升至用户空间。

• 核心思想：减少对宿主机内核的暴露。gVisor 实现了一个用 Go 语言编写的用户态内核，即 Sentry。
• 工作流程：应用发起系统调用时，会被 Sentry 拦截并在用户空间处理，而无需直接陷入宿主机内核。文件系统操作由另一个名为 Gofer 的守护进程处理。
• 优点：即使应用的代码有攻击行为，它攻击的是 Sentry（运行在 Ring 3），而不是宿主机内核（Ring 0），攻击面大大减少。
• 缺陷：Sentry 和 Gofer 本身仍运行在宿主机上。这构成了一个两步连锁攻击的可能：先利用 Sentry/Gofer 的用户态漏洞，再利用其与宿主机内核的接口攻击内核。强大的模型有能力挖掘并组合这种漏洞。

💬 精华片段（中文）

"The fundamental problem with containers is that they're still native processes running on the host...a process in a container can still exploit the kernel boundary and try to get root or a kernel exploit."

"容器的根本问题在于，它们仍然是运行在宿主机上的原生进程……容器内的进程依然可以利用内核边界，尝试获取 root 权限或发起内核攻击。"

终极方案：基于硬件的微虚拟机

本节重点

• 硬件级虚拟化提供最彻底的隔离：客户机内核在 Ring 0 的特权对宿主机无效。
• 虚拟机监视器 管理虚拟机生命周期，并通过 dev/kvm 与内核交互。
• 半虚拟化 通过 virtio 提升 I/O 性能。
• 新一代 Rust 语言编写的微虚拟机 具备更小的攻击面、内存安全特性和细粒度设备隔离。

详细精要

• 硬件虚拟化的隔离优势：这是实现终极沙箱目标的关键。
• 目标：即使不可信代码获取了客户机的 root 权限，甚至利用了客户机内核，依然要保护宿主机的安全。
• 实现原理：Linux 的 KVM 提供硬件辅助的虚拟化。CPU 引入两种执行模式：
  • VMX root 模式：宿主机内核和 Hypervisor 运行此模式。
  • VMX non-root 模式：客户机内核虽也运行在 Ring 0，但在此独立环境中，其对硬件的完全控制权限被限制在客户机内部，无法触碰宿主机。

• 代价：客户机与宿主机之间每次切换都有性能开销，这是安全隔离需要付出的主要代价。

• VMM 的角色：虚拟化由 VMM 软件实现。

• 软件如 QEMU 就是一个 VMM，它通过 /dev/kvm 这个 Hypervisor API 与内核交互。它的工作包括设置内核、根文件系统（rootfs）、分配内存等。

• 客户机内部看到的块设备、网络设备等，当实际访问时，VM 会退出到宿主机上下文，由 VMM 进程中运行的后端代码来模拟这些设备。

• 半虚拟化与性能：通过虚拟化提升 I/O 性能。

• 半虚拟化 意味着客户机中的驱动程序知道自己正运行在虚拟机中，因此可通过 Virtio 这种更高效的 API 与宿主机通信，避免模拟真实硬件的巨大开销。

• 从宿主机视角看，客户机的一个块设备操作，可能只体现为一个线程的唤醒与执行，这一切运行得非常可靠且高性能。

• 微虚拟机的崛起：2023 年左右，新一代 VMM 出现，称为微虚拟机。

• 传统 QEMU 问题：代码庞大，支持众多架构和设备，用 C 语言 编写，其模拟的设备历来是虚拟机逃逸攻击的重灾区。
• CrosVM：由 Google 团队为 ChromeOS 编写，是首个基于 Rust 的 VMM。Rust 提供了内存安全保障，避免了 C 语言常见的内存漏洞，并去除了 QEMU 的冗余功能。
• 设备级隔离：将不同的设备（如块设备、网络设备）进行隔离。即使块设备代码被攻击者攻破，也无法访问网络资源，形成第二道安全防线。
• “Micro”的含义：“微”指的是 VMM 本身 的精简，而不是客户机。这些 Rust VMM 内存占用小、启动速度快。

• 主流微虚拟机：

  • Firecracker：从 CrosVM 分支而来，用于 AWS Lambda 和 Fargate。
  • Cloud Hypervisor：更通用的 Rust VMM，由多家公司共同维护。网上的微 VM 服务通常由这几款 VMM 之一驱动。

• 操作微虚拟机：使用 API 创建沙箱。

• 启动过程：Harness fork 出一个 VMM 进程，该进程暴露 Unix Domain Socket API。通过 API 调用 create（传入内核、rootfs、CPU、内存等配置）和 start。VMM 调用 /dev/kvm，客户机开始运行。

• 宿主机与客户机通信：客户机沙箱内运行有一个 PID 1 进程，它暴露一个 API 服务器。宿主机通过 VSock（一种特殊的套接字，用于宿主机与客户机之间高效通信）与该 API 通信，执行保存状态等操作。

• 微虚拟机的权衡与演讲者观点：

• 优点：提供最强的硬件级隔离；攻击链极长（需攻破 KVM 技术栈和设备）；可对设备进行隔离和使用 seccomp 加固，实现纵深防御。
• 缺点：有性能开销（VM exit 是重量级操作）；内存管理不灵活，需要通过 balloon driver 被动回收内存；GPU 直通困难，Virtio-GPU 只能提供高级库访问，而用于直接访问的 VFIO 不支持多租户共享一块 GPU。
• “七阶段悲伤”理论：演讲者观察到，所有团队最终都会从容器、gVisor、V8 等方案折腾一圈后，发现无法放弃完整 Linux 环境的强大功能，最终选择 VM 以获得完整功能与安全性的统一。
• 最终建议：永远倾向于更安全的解决方案。作为公司，安全失信一旦发生就极难挽回，而性能问题可以通过系统层面的技巧来弥补。如果你是一个创业公司，请从微虚拟机开始，这会为你省下两年的“悲伤”历程。

💬 精华片段（中文）

"My view is that security like system tricks can cover performance issues, but they cannot hide security breaches... I would call it the seven stages of grief, the seven stages of sandboxing. In the end, everyone always wants a VM."

"我的观点是，性能问题可以用系统层面的技巧弥补，但安全漏洞却无法被掩盖……我愿意称此为 "沙箱七阶段悲伤" 。最终，所有人都还是会选择虚拟机。"

持久化：解锁智能体的下一把钥匙

本节重点

• 带有持久化存储的沙箱能从一次性执行环境进化为能处理长期任务的“知识工作者”。
• 增量快照是可靠性、大规模扩展和智能体高级探索的基础。
• 实现持久化的两种方式是显式快照和始终在线存储，其核心技术是写时复制和分布式文件系统。

详细精要

• 持久存储的价值：只给智能体一个无状态的 Linux 环境是不够的。
• 智能体在预训练中已经学会如何像人类一样使用计算机，一旦给予它们一个带有持久化磁盘的计算机，它们就能进行长期工作（如创建演示文稿、Github 仓库等）。

• 反面案例：如果节点宕机或任务失败，所有未保存的工作都会丢失，既浪费算力也很糟糕的用户体验。

• 持久化解锁的三大用例：持久化并非仅仅是存储，它还会反哺可靠性和规模。

• 可靠性与故障恢复：对一个长时间运行、安装了众多软件包的任务，定期进行检查点保存。当节点故障时，可以在另一个节点的沙箱上从上次检查点瞬间恢复状态。这也能支持滚动升级和 A/B 测试。
• 支持超长任务：类似 Codex Gold Mode，用户需要连续几天运行任务，必须依赖快照来保证状态不丢，并能跨节点持续执行。

• 高级搜索与探索：Harness 可以保存沙箱状态，然后分叉出多种解决路径，像蒙特卡洛树搜索一样进行回溯和探索，这是解决如发现新药物等复杂问题的关键能力。

• 快照方案的设计要求：在 ChatGPT 级别产品中部署快照方案，必须满足以下几点。

• 增量快照：每次只保存相对于上一次快照的变化差异，否则全量快照会消耗天价存储和带宽。
• 速度快：快照、创建和恢复操作本身必须极快，以支持高频调用和良好用户体验。

• 两种模式：显式保存由 Harness 调用 API 触发；始终在线保存则自动将数据写穿到云端。

• 关键设计选择：块级 vs 文件级快照：

• 块级快照原理：Linux 磁盘被抽象为块设备。文件系统通过 inode 数据结构将文件逻辑偏移量映射到一个或多个逻辑块上。通过追踪哪些逻辑块发生了变化，并只打包、保存这些变化的块，可以实现超高效的增量快照，避免了基于文件粒度的写放大问题。

• 虚拟机内存储性能：在 VM 内部，直接提供块设备 抽象比 9p 类似共享文件夹 的方式性能高得多，因为客户机内核可以利用自己的页面缓存，大幅减少昂贵的 VM 退出。

• 解决方案实现：

• 显式持久化（快照/恢复）：
  • 使用写时复制技术：在基础镜像上创建一个零拷贝的可写层。写入时，变化的数据块被写入新层。
  • 快照时，通过 fiemap ioctl 找出可写层中变化的数据块范围，打包上传至对象存储。
  • 异步优化：API 可在后台启动上传后立即返回，实现极低的快照延迟。
  • 恢复：根据快照 ID 和图谱关系拉取所有差异层，并按顺序应用到基础镜像上，从而在块级别精确恢复沙箱状态。
• 始终在线持久化：
  • 基于对象存储（如 S3/GCS）或持久块存储之上，编写一个用户态文件系统。
  • 利用 NBD 技术，在沙箱内部暴露为一个普通的块设备。
  • 分层缓存架构：在 VM 内部有块缓存，在集群内有本地缓存，最终数据写回对象存储。这种架构既保证了 POSIX 兼容性，又提供了高性能。

💬 精华片段（中文）

"If you give them a computer with an actual disk that can be saved, then they become a true knowledge worker. I think storage is the next unlock here."

"如果你给他们一台有真实硬盘的电脑，并且数据可以保存下来，他们就能成为真正的知识工作者。我认为，存储是下一步要被解锁的关键能力。"

编排：从单节点到全球舰队

本节重点

• 编排层负责在跨区域的机器集群中高效调度沙箱。
• 通过微虚拟机的内存快照和预热池技术，可大幅降低启动延迟。
• 快照感知调度利用节点上已有的快照层来智能路由请求，实现毫秒级恢复。

详细精要

• 编排层挑战与结构：单节点的方案必须能在全球范围的多个节点上可靠运行。
• 基础设施由分布在不同区域的集群组成。
• 顶层控制平面根据区域负载等因素，选择一个离ChatGPT集群近的集群，以降低延迟。

• 集群内调度器根据节点负载、失败状态等因素，智能选择一个节点来运行沙箱，低延迟和可靠性仍是核心原则。

• 用于降低启动延迟的优化：

• 预热池：预先启动一批待命的沙箱，有请求时立刻分配。代价是消耗空闲状态的 CPU 和内存。
• 微虚拟机内存快照：利用微 VM 可以保存客户机内存的特性，在请求到来时，从内存快照瞬间启动一个沙箱，启动时间可缩短到毫秒级。

• 混合方案：使用一个较小的预热池，当需求激增时，从内存快照快速扩容，兼顾速度与资源消耗。

• 快照感知调度：将持久化与编排深度结合，优化沙箱恢复速度。

• 一个完整的沙箱状态可能由多个快照层组成。
• 当需要从某个快照恢复沙箱时，调度器会检查集群内各节点已经缓存了哪些层。
• 调度器会优先选择已缓存全部或大部分所需层的节点，从而避免从云端拉取大量数据，实现最快的恢复和创建速度。这是一种使用缓存亲和性来加速调度的实践。

💬 精华片段（中文）

"You can actually take a memory snapshot of a micro VM and just-in-time start it in milliseconds as the request comes. So you can leverage this nice micro VM property."

"你实际上可以保存微虚拟机的内存快照，当请求到来时，能以毫秒级的速度即时启动它。这就是你可以利用的微虚拟机的优秀特性。"

---

专业术语注释

术语	解释
Harness	在模型训练或产品推理中，负责解析模型输出、实际调度执行代码或工具调用的脚手架程序。
可验证奖励	一种问题属性，指该问题的答案可以通过一个确定的程序（如代码）来验证其对错。
沙箱	一个安全隔离的执行环境，用于运行不可信代码，限制其对宿主机、网络或其他用户资源的访问。
Rollout	在强化学习中，特指让模型根据一个任务指令生成的一条完整应答或执行轨迹。
系统调用	用户空间程序请求操作系统内核执行特权操作的接口，如访问磁盘、网络和创建进程。
Ring 0/Ring 3	X86 架构中 CPU 的执行特权级别。Ring 0 拥有最高权限（内核），Ring 3 权限最低（用户应用）。
命名空间	Linux 内核特性，用于隔离一组进程对某一类系统资源的“视图”，如独立的 PID 列表、挂载点等。
Cgroup	即 Control Group， Linux 内核特性，用于限制、控制和统计一组进程所能使用的资源总量(CPU, 内存等)。
Seccomp	一种 Linux 内核的安全特性，允许进程定义一个精细的系统调用过滤器，以缩减内核攻击面。
gVisor	一个应用级内核，在用户空间模拟 Linux 系统调用，减少了应用对宿主机内核的直接接触。
Sentry/Gofer	gVisor 的核心组件之一，负责在用户空间处理系统调用/负责通过 9p 协议代理文件系统操作。
KVM	基于内核的虚拟机，是 Linux 内核中的一个模块，将内核转换为 Hypervisor。
Hypervisor	虚拟化监视器，在宿主机上创建并运行虚拟机的软件、固件或硬件。
VMX root/non-root mode	Intel 硬件虚拟化技术中的两种执行模式，为 Hypervisor 和客户机提供硬件隔离的执行环境。
VMM	虚拟机监视器，一个负责管理虚拟机生命周期，并利用 KVM API 的用户态进程。
QEMU	一个流行的开源机器模拟器和 VMM，功能强大但代码庞大。
半虚拟化	一种虚拟化技术，客户机 OS 知道自己运行在虚拟环境中，并通过特定 API 与 Hypervisor 高效协作。
Virtio	半虚拟化框架的标准 I/O 接口，允许客户机与宿主机进行高效的块设备和网络 I/O。
微虚拟机	相对于 QEMU 等重型 VMM，指用 Rust 等语言实现的内存安全、启动快、代码精简的新型 VMM。
CrosVM/ Firecracker / Cloud Hypervisor	三个主流的 Rust 微虚拟机代表，分别起源于 Chromium OS/AWS/多家厂商合作。
VSock	一种基于地址族 AF_VSOCK 的套接字，为宿主机和其管理的客户机提供高效的通信方式。
检查点	在某一时刻保存进程或系统完整运行状态的快照，以便未来从该点恢复执行。
蒙特卡洛树搜索	一种用于决策的启发式算法，通过随机抽样模拟结果来构建搜索树，以此寻找最优行动路径。
增量快照	一种数据备份技术，只保存自上次快照以来发生变化的数据块，而非全量拷贝。
inode	索引节点，Linux 文件系统中用于存储文件的元数据（如大小、权限）以及指向数据块指针的数据结构。
写时复制	一种优化策略，多个调用者在请求资源时获取相同的指针，只有当调用者试图修改资源时，系统才真正创建私有副本。
FIE map	一个 Linux ioctl 命令，用于获取文件的物理盘区布局，可精确找出文件数据在磁盘上的物理块分布。
NBD	网络块设备，允许一台机器通过网络将一个块设备提供给另一台机器使用。
快照感知调度	在编排系统中，调度器根据目标节点上已缓存所需状态的快照层，来智能分配任务以加速恢复。

---

延伸思考

1. 攻击链的有效性争论：虽然微虚拟机攻击链长且复杂，但随模型能力指数级增强，它们发现和组合零日漏洞的能力也在提升。这种军备竞赛的未来会是怎样？硬件级隔离是终点，还是仅仅是安全演进的一个阶段？
2. 性能与安全的动态平衡：演讲者旗帜鲜明地优先选择了安全。但在延迟极度敏感的消费级 AI 产品中，微虚拟机的 VM exit 开销是否真的能被完全“掩盖”？在没有详尽 Benchmark 的情况下，工程团队如何设定可接受的性能退化阈值？
3. 快照一致性与应用层逻辑：基于块级别的快照虽然干净，但它等同于给整个机器按了“暂停-保存”。对于在沙箱内运行的有状态应用（如数据库、缓存），这种形式的快照可能产生“崩溃一致性”数据，应用是否要为此投入额外的恢复逻辑？
4. 持久化存储的未来：演讲提到用 S3/GCS 作为最终存储后端。对于高频读写的智能体工作负载，这种分层缓存架构的成本和延迟尾部效应如何？这是否会催生专门针对智能体工作负载设计的新一代分布式存储系统？

原文发表：Jul 13, 2026  ·  纪要生成：2026-07-20