LangGraph 团队最近发布了 DeltaChannel，一个专门解决长运行 Agent checkpoint 存储爆炸的新原语。核心数字很直观：200 轮编码会话，传统全量快照存 5.3GB，DeltaChannel 只要 129MB——41 倍压缩，状态恢复性能几乎无损。
问题：O(N²) 的 checkpoint 增长
LangGraph 默认每步都写全量状态快照。对短生命周期 Agent 没问题，但消息历史和文件是只增不减的累加器。
Checkpoint N 包含从第 1 步到第 N 步的所有内容。增长在 checkpoint 层复合：每步序列化比上一步更多的数据，写更大的 blob，占更多内存。 serialization 时间、写放大、冗余存储，三重代价。
解法：只存 diff
DeltaChannel（langgraph 1.2 beta）改变累加状态字段的 checkpoint 方式。普通步骤只写该步新增更新的微小 delta，定期写全量快照来限制恢复成本。
对 Deep Agents 来说，消息和文件都用 delta 存储。完整 Agent 执行历史还在，只是成本是原来的一小部分。
工作机制
正常步骤 — DeltaChannel 只写该步新增内容，一个微小 delta。
定期快照 — 每 snapshot_frequency=K 步写一次全量快照（deepagents 默认 50）。恢复时不需要重放会话开始以来的所有 delta，只需回退到最近的快照——最多 K 步。
没有定期快照的话，超长会话的恢复会变得极慢。
底层增长仍是二次的（因为每 K 步有一次快照），但系数是基线的 ~1/K。在实际会话长度下，O(N) 的 delta 项占主导，且恢复成本被 K 限定，resume 延迟保持平稳。
实测数据
Workload A：轻量编码 + 搜索
存储起初增长缓慢，随后因全量快照复合而急剧加速。500 轮时基线累计 4GB，delta channels 保持在 110MB 以下。节省比例从 10 轮的 6 倍增长到 500 轮的 41 倍。
Workload B：多文件编码会话
每轮状态更重，O(N²) 曲线更快变陡。基线在 200 轮就达到 5.3GB——一个真实的 Agent 工作下午。节省比例在 200 轮达到 41 倍，仍在攀升。
两个 workload 都收敛到相同的 ~K× 渐近线，但 heavier workload 更快到达，因为更大的每轮写入更激进地放大了二次系数。
snapshot_frequency 可配置：更高的 K 意味着每会话更少全量写入、更高存储节省，代价是恢复时多 replay 一些 delta。
API 与迁移
两个参数：
- reducer — 纯函数 (state, list[writes]) → new_state，必须满足 batching-invariant：分批执行和合并后执行结果相同。这是自定义 delta-backed state 时唯一需要做对的事。
- snapshot_frequency — 全量快照频率（默认 1000，deepagents 用 50）
整个 API 表面变化就这些。现有工具、中断处理、time-travel 全部继续工作。
迁移零成本：DeltaChannel.from_checkpoint 遇到纯状态值（非 _DeltaSnapshot）时直接用它作为基态。现有线程继续工作——升级后的第一个新 checkpoint 开始在该基态上写 delta。
Delta channels 已在 deepagents v0.6 和 langgraph v1.2 中默认开启。
为什么重要
长运行 Agent 是行业方向。Agent 跑得更深、上下文更厚，runtime 必须能 scale。DeltaChannel 把存储从指数增长压到线性，让 Agent 有时间真正「变聪明」，而不是被基础设施卡脖子。