## 概述 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²)"的数学根源。 ```python # 默认全量快照——最省心，也最贵 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 全部不变。 ```python # 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。 ```python # 典型"假续跑"：只存对话，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。 ```python # 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 快照路。 ```python # 跨回合打 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 设计，否则重放会失真（这点正好踩在"回放失真"那期讨论的坑上）。 ```python # 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 / 事件溯源 / 语义感知三类把曲线压成了线性甚至亚线性。 ```mermaid %%{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 或块级快照、编排层做事件重放，三者各管一段。 ```mermaid flowchart TB subgraph Agent["Agent 框架层"] MSG["消息状态 delta 化
Deep Agents v0.6"] end subgraph Sandbox["沙箱运行时层"] GATE["语义门控
判定 25% 有效回合"] SNAP["Crab C/R 或 zfs 快照
保留 OS 副作用"] end subgraph Orch["编排执行层"] EVT["事件流落库
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](https://www.langchain.com/blog/delta-channels-evolving-agent-runtime) — LangChain 官方博文，给出"全量快照按 O(N²) 增长"的结论与 DeltaChannel 增量+K步全量方案，Deep Agents v0.6 默认启用。 2. [Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes — arXiv:2604.28138](https://arxiv.org/abs/2604.28138) — 论文指出"超过 75% 的智能体回合不产生恢复相关状态"，并提出 host-side 透明 C/R 运行时桥接 agent-OS 语义鸿沟。 3. [Task-Completion Time Horizons of Frontier AI Models — METR](https://metr.org/time-horizons/) — 前沿模型 50% 任务时间跨度基准，2026 年 Opus 4.6 约 14.5 小时，是长任务快照税被放大的根本原因。 4. [Long-Running Autonomous Agents: Drift, Checkpointing, Recovery — dikrana.dev](https://dikrana.dev/blog/long-running-autonomous-agents/) — 实战博客，记录长任务中 pass@1 在长任务上掉 24 分、目标漂移与 checkpoint 策略取舍的工程经验。 5. [Durable Execution for AI Agent Runtimes: Checkpointing, Replay, and Recovery — zylos.ai](https://zylos.ai/research/2026-04-24-durable-execution-agent-runtimes/) — 事件溯源/持久化执行综述，覆盖 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 等场景全覆盖。