首页 › ai-agents › 七成快照白存：续跑存储税实测

概述

METR 在 2026 年把前沿模型的 50% 任务时间跨度推到了约 14.5 小时（Opus 4.6），意味着一个自主智能体可能要连续跑上百步、写满一个文件系统才能交差。要让这种长任务"挂了能续"，业界默认做法是每一步打一个全量快照（checkpoint）。但这条捷径藏着两笔没写在账单上的税：其一是存储二次方膨胀——LangChain 实测全量快照模型按 O(N²) 增长，因为每一步快照都把累计上下文重新拷一遍；其二是七成空快照——Crab 论文指出超过 75% 的智能体回合根本不产生任何与恢复相关的状态，也就是说每打四个快照，有三个是白存。本文用一个 200 步的模拟长任务，横评六种断点续跑策略，量出每条路径真实交了多少存储税、换回了多大的恢复粒度。

六策略对比：200 步模拟实测

模拟设定：智能体共跑 N=200 步，每步增量状态 s≈50KB（消息+落盘文件），第 200 步累计状态约 10MB。下表存储量为该策略在整条任务周期内落盘的总量。

# 续跑策略 代表实现 存储复杂度 200步存储量 恢复粒度 OS副作用保留 上手成本 训练营变现
1 全量快照每步 LangGraph 默认 PostgresSaver O(N²) ~1.0 GB 任意步精确 仅agent层 极易 ★ 负资产
2 Delta 增量通道 LangChain Deep Agents v0.6 O(N) ~100 MB K步窗口 仅agent层 易 ★★★
3 应用层恢复 自建 chat-history 持久化 O(N) ~10 MB 仅对话续聊 完全丢失 极易 ★
4 语义感知 C/R Crab 沙箱运行时 ~O(0.25N) ~40 MB 按语义边界 完整 难 ★★
5 写时复制FS快照 overlayfs / zfs / btrfs O(1)/快照 ~200 MB 块级 完整 中 ★★
6 事件溯源重放 Temporal / AWS Lambda Durable O(N)事件 ~30 MB 重放确定性 取决于副作用 中 ★★★

一眼结论：策略 1 是"最省心、最烧钱"的极端；策略 3 是"最省存储、最假恢复"的极端——它便宜是因为它根本没保存能让智能体真正续跑的东西。真正能同时摁住两笔税的，是 4 和 6，但二者一个难、一个要重构执行模型。

深度分析

一、全量快照每步：O(N²) 的隐形账单

LangGraph 的设计哲学是"每一步都可观测、可回溯、可中断"，实现方式就是 BaseCheckpointSaver 在每个超级步（superstep）落一份全量状态。当状态只装对话消息时，N² 还不算刺眼；但当 Deep Agents 把文件系统也塞进 agent state 做上下文卸载时，第 k 步的状态大小 ≈ k·s，于是整条任务落盘总量 = Σ(k·s) ≈ ½·s·N²，这就是 Delta Channels 博客里那句"full-snapshot model grows at O(N²)"的数学根源。

# 默认全量快照——最省心，也最贵
from langgraph.checkpoint.postgres import PostgresSaver
graph = build_agent().compile(checkpointer=PostgresSaver(conn))
# 每个超级步都把 {messages, files, scratchpad} 整份写库
# N=200 步 ≈ 1GB 落盘，且 75% 是"空回合"的无谓拷贝

它的优势是恢复语义最干净：time-travel、human-in-the-loop 中断、回滚到任意步，全都现成。劣势是账单随任务长度二次方爬升，跑得越久越像在给云厂商的块存储打白工。训练营价值几乎为零——它不是技巧，而是默认，讲不出溢价点，只能当反面教材。

二、Delta 增量通道：只存 diff，每 K 步补一次全量

LangChain 在 2026 年 5 月推出的 DeltaChannel 给出的解法很务实：每一步只落增量（delta），每 K 步写一次全量快照封顶恢复延迟。存储从 O(N²) 砍到 O(N)，恢复延迟被锁在"最多回退到上一个全量点 + 重放后续 delta"的 K 步窗口内。更关键的是升级对上层透明——messages 和 files 在 Deep Agents v0.6 里默认 delta 化，interrupts、time-travel、工具调用 API 全部不变。

# Deep Agents v0.6：messages 与 files 默认 delta-backed
from deepagents import build_deep_agent
agent = build_deep_agent(
    model=...,
    checkpointer=DeltaChannelSaver(pg, full_snapshot_every=20),  # K=20
)
# 同样 N=200 步：落盘 ≈ 200×50KB(增量) + 10×≤10MB(全量) ≈ 100MB

代价是恢复粒度从"任意步"降级为"K 步窗口"，以及对增量 diff 的正确性依赖——一旦某条 delta 损坏，窗口内后续状态全废。它的训练营价值高：增量快照、窗口调优、delta 完整性校验都是可教学、可演示的硬技能，适合包装成"长任务降本"主题课。

三、应用层恢复：便宜的陷阱

很多团队图省事，自己写一个把 messages 序列化进 Redis 的"续聊"功能就宣称支持断点续跑。Crab 论文把这类做法点名为 application-level recovery——它确实便宜（O(N)、几十 MB），但它只保留了对话历史，完全丢失了 OS 侧副作用：智能体上一步创建的临时文件、跑了一半的子进程、改过的环境变量、装了一半的依赖，在崩溃后统统不见。续跑出来的智能体相当于失忆+失能：记得自己说过要 npm install，却不知道那个命令其实崩在了一半、留了个坏掉的 node_modules。

# 典型"假续跑"：只存对话，OS 状态全丢
state = {"messages": agent.messages}
redis.set(run_id, json.dumps(state))   # 崩溃后恢复：messages 回来了
# 但上次 subprocess.Popen 起的后台进程、/tmp 中途文件、未提交的 git 改动 → 蒸发

它适合"纯对话型、无副作用"的轻量智能体（比如纯问答 bot）。但凡智能体动了文件系统或起了进程，它就不是续跑，而是重启。训练营价值低，因为"存个 JSON"没有技术门槛。

四、Crab 语义感知 C/R：只存那有用的 25%

Crab（Checkpoint-and-Restore for Agent SandBoxes）直接捅破了最核心的认知盲区：75% 的回合不产生任何恢复相关状态。一个回合如果只是纯文本推理、读了个文件没改、跑了个无副作用的查询，它根本不需要 checkpoint。问题在于"谁来判定哪个回合该存"——agent 框架只看到 tool call 看不到 OS 效应，OS 只看到状态变更却不懂回合边界，这就是论文定义的 agent-OS 语义鸿沟。Crab 用一个透明的 host-side 运行时桥接二者：在沙箱（容器/microVM）层挂钩，按回合语义判定"这一步动了 FS/进程/有状态外部资源吗"，只对命中的 25% 做 C/R。

# Crab 概念伪码：语义门控，只在有副作用的回合打快照
def after_turn(turn_id, os_diff):
    if os_diff.touched_fs or os_diff.spawned_proc or os_diff.mutated_state:
        crab.snapshot(turn_id)   # 只存这 25%
    # 其余 75% 直接跳过 → 快照数砍到 1/4

它的杀手锏是恢复语义完整——OS 副作用一并还原，比策略 2/3 都强；但代价是部署复杂，要接管容器运行时，与现有编排栈深度耦合。训练营价值中等偏上，适合做"自主智能体可靠性工程"高阶专题，门槛筛掉了大部分竞品。

五、写时复制文件系统快照：块级的暴力美学

overlayfs、zfs、btrfs 的 copy-on-write 快照是操作系统给的真·断点续跑底座：每次快照只存被改的块，O(1) 单次开销，能完整保留整个沙箱的文件系统与（配合 CRIU）进程状态。200 步模拟约落 200MB——比全量省，比 delta 贵，但胜在粒度可粗可细、对 agent 框架零侵入。Devin、OpenManus 这类需要在容器里实操的编码智能体，普遍走的就是这条 zfs/btrfs 快照路。

# 跨回合打 zfs 快照（bash 层示意）
# 每隔 K 步或检测到重要副作用时：
subprocess.run(["zfs", "snapshot", f"tank/sandbox@step_{turn_id}"])
# 恢复：zfs rollback tank/sandbox@step_187  → 整个 FS 瞬间回到那一步

缺点是恢复粒度是"块级"而非"语义级"——它能把你送回第 187 步的磁盘状态，却不知道第 187 步在任务语义上意味着什么；且与 agent 的消息状态是两套体系，对齐起来要自己写胶水。训练营价值中等，"容器快照 + 智能体"是运维向的扎实选题。

六、事件溯源 / 持久化执行：重放即恢复

Temporal、AWS 2025 年 12 月发布的 Lambda Durable Functions 代表另一条哲学：不存状态，存事件；要恢复就把确定性输入重放一遍。每一步的 tool call 入参被当作事件落库（O(N) 事件流，约 30MB），崩溃后从检查点重放事件流重建状态。它对"确定性副作用"天然友好——同样的输入重放得到同样的结果；但对"非确定性副作用"（实时抓取的网页、随机数、带时间戳的外部写入）需要专门的 replay-safe 设计，否则重放会失真（这点正好踩在"回放失真"那期讨论的坑上）。

# Temporal：activity 即事件，崩溃后自动从最后完成的 activity 重放
@workflow.defn
class AgentWorkflow:
    @workflow.run
    async def run(self, task):
        plan = await workflow.execute_activity(plan_activity, task)
        for step in plan:
            await workflow.execute_activity(do_step, step)  # 每步可恢复

它的训练营价值最高之一：持久化执行、重放确定性、副作用建模是真正的工程硬核，能讲出体系、能做实验、能收高客单。代价是心智负担重——你必须把智能体改造成"事件可重放"的形态，对存量代码不友好。

存储税增长曲线

下图直观对比六种策略随任务步数 N 增长的存储成本：全量快照的 O(N²) 抛物线在长任务里会迅速失控，而 delta / 事件溯源 / 语义感知三类把曲线压成了线性甚至亚线性。

%%{init: {'themeVariables':{'fontSize':'13px'}}}%%
xychart-beta
    title "断点续跑存储成本 vs 任务步数 N"
    x-axis "任务步数 N" [50, 100, 150, 200, 300, 400]
    y-axis "累计存储量 (MB)" 0 --> 1100
    line "全量快照每步O(N²)" [62, 250, 562, 1000, 999, 999]
    line "CoW文件系统快照" [50, 100, 150, 200, 300, 400]
    line "Delta增量通道" [25, 50, 75, 100, 150, 200]
    line "Crab语义感知25%" [10, 20, 30, 40, 60, 80]
    line "事件溯源重放" [8, 15, 22, 30, 45, 60]

续跑架构分层

真正工程化的长任务续跑，往往是分层叠加而非单选：应用层做 delta 消息、沙箱层做语义 C/R 或块级快照、编排层做事件重放，三者各管一段。

flowchart TB
    subgraph Agent["Agent 框架层"]
        MSG["消息状态 delta 化<br/>Deep Agents v0.6"]
    end
    subgraph Sandbox["沙箱运行时层"]
        GATE["语义门控<br/>判定 25% 有效回合"]
        SNAP["Crab C/R 或 zfs 快照<br/>保留 OS 副作用"]
    end
    subgraph Orch["编排执行层"]
        EVT["事件流落库<br/>Temporal / Lambda Durable"]
    end
    TASK["长任务 N=200步"] --> Agent
    MSG -->|每K步全量| GATE
    GATE -->|命中副作用| SNAP
    GATE -->|纯推理回合 75%| SKIP["跳过 ✗"]
    MSG --> EVT
    SNAP --> RECOVER["崩溃恢复：消息delta + OS状态 + 事件重放 三合一"]
    EVT --> RECOVER
    style MSG fill:#fef3c7
    style SNAP fill:#dbeafe
    style EVT fill:#dcfce7
    style SKIP fill:#fee2e2

推荐方案：按场景选税档

轻量对话型智能体（无副作用）：直接用策略 3 应用层恢复，几 MB 解决，别为不存在的问题付税。

中等长度、有文件操作的编码/研究智能体（N<100 步）：策略 1 全量快照每步仍是性价比之选——O(N²) 在 N=100 时还只是 ~250MB，省心比省钱重要。

长任务（N≥200 步）、消息与文件混载上下文：上策略 2 Delta 增量通道，把 O(N²) 压成 O(N)，这是目前改造成本最低、收益最直接的一档，LangChain Deep Agents v0.6 可直接抄。

需要在容器/microVM 里跑真实命令、要求崩溃后 OS 状态原样恢复：策略 5 写时复制文件系统快照打底，叠加策略 4 语义门控把 75% 空快照剔掉，既完整又省钱。

企业级、对可靠性有 SLA 要求的长流程编排：策略 6 事件溯源/持久化执行做骨架，把智能体改成事件可重放形态，配合 delta 与块级快照做热恢复——这是天花板，也是训练营能讲出高客单的唯一档位。

一句话收口：续跑不是"打不打快照"的二选一，而是"在七成空回合里，你愿意为那两成五的真状态交多少税"的精算题。默认全量快照是把账单写成了二次方，而真正成熟的长任务系统，都在想办法让快照既稀疏、又语义完整、又线性增长。

参考来源

  1. Delta Channels: Evolving our Runtime for Long-Running Agents — LangChain — LangChain 官方博文，给出"全量快照按 O(N²) 增长"的结论与 DeltaChannel 增量+K步全量方案，Deep Agents v0.6 默认启用。
  2. Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes — arXiv:2604.28138 — 论文指出"超过 75% 的智能体回合不产生恢复相关状态"，并提出 host-side 透明 C/R 运行时桥接 agent-OS 语义鸿沟。
  3. Task-Completion Time Horizons of Frontier AI Models — METR — 前沿模型 50% 任务时间跨度基准，2026 年 Opus 4.6 约 14.5 小时，是长任务快照税被放大的根本原因。
  4. Long-Running Autonomous Agents: Drift, Checkpointing, Recovery — dikrana.dev — 实战博客，记录长任务中 pass@1 在长任务上掉 24 分、目标漂移与 checkpoint 策略取舍的工程经验。
  5. Durable Execution for AI Agent Runtimes: Checkpointing, Replay, and Recovery — zylos.ai — 事件溯源/持久化执行综述，覆盖 AWS Lambda Durable Functions（2025-12 发布）等事件重放方案。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章