Pi Durable：让AI Agent崩溃后自动续跑的持久化方案

想象这样一个场景：你的AI Agent正在连续发送五封邮件，发到第四封时进程崩溃，留下一个未完成的工具调用。传统编码Agent的恢复方式很原始——重启服务、重启Agent、手动发送continue，然后祈祷它能自己想明白任务完成到哪一步。

Pi Durable（视频中口播为“PyDurable”）解决的就是这个痛点。它不是又一个编码Agent，而是一个TypeScript库：每一个任务、每一次工具调用都会被检查点（checkpoint）写入SQLite或JSONL这类持久化存储。服务器重启后，Agent直接从数据库读取状态，从断点继续执行，不需要任何人工干预。

传统Agent的崩溃恢复为什么这么痛

普通编码Agent的运行状态通常只存在于内存中。一旦进程挂掉，上下文、已完成的步骤、正在进行的工具调用全部丢失。恢复流程往往依赖人工：重新启动服务，重新初始化Agent，再把“继续”作为一条新指令喂给它。

问题在于，Agent并不真正知道自己崩溃前做到哪一步。它只能根据残存的对话历史去推测，推测错了就会出现重复发邮件、漏发邮件、或者把已完成的任务再做一遍。对于一次性任务，这种不确定性尚可忍受；对于长期在线的Agent，则是灾难。

检查点机制：状态落在磁盘而非内存里

Pi Durable的核心设计只有一句话：把Agent的每一步都持久化。具体来说，每个task、每个tool call在执行前后都会生成检查点，写入SQLite或JSONL文件。这些存储介质的选择颇具实用主义色彩——SQLite适合需要查询和事务的场景，JSONL则胜在人类可读、追加写入简单。

当服务器重启、进程重新拉起时，Agent做的第一件事不是重新规划，而是读数据库、核对状态、定位到最后一个成功的检查点，然后从那里继续。视频中强调的关键点是：你不需要发送continue。恢复动作是系统行为，不是用户行为。

这个机制带来的直接收益是可预测性。崩溃不再意味着任务状态的黑箱重置，而只是执行流的一次暂停。对于需要审计的场景，JSONL里的检查点记录本身就是一份完整的执行日志。

检查点（Checkpoint） 是分布式系统与容错计算中的经典概念：在程序执行的特定时刻，将内存中的关键状态（变量、进度、上下文）序列化并写入可靠存储，形成一份可回溯的快照。当进程崩溃或机器故障后，系统可以从最近一个有效检查点恢复，而不必从头重算。检查点的代价在于写入频率与性能之间的权衡——写得越频繁，恢复时丢失的工作越少，但I/O开销也越大。Pi Durable把这一思想下移到Agent层，检查点的粒度是单个task和单次tool call，相当于把Agent的执行流切成了可独立恢复的离散片段。

SQLite 是一个嵌入式关系型数据库，整个数据库就是单个文件，无需独立服务器进程，支持ACID事务和SQL查询。JSONL（JSON Lines）则是每行一个独立JSON对象的文本格式，优势是追加写入极其简单、人类可直接阅读、便于用grep等工具排查。两者在Pi Durable中承担的角色不同：SQLite适合需要按条件查询状态、保证写入原子性的场景；JSONL适合日志式追加、事后审计和快速人工检查。选择哪种介质，本质上是在查询能力、事务保证与运维简单性之间做取舍。

面向常驻Agent，而非CLI工具

Pi Durable的定位需要说清楚：它不是命令行安装的编码助手，也不是Pi这类编码Agent的替代品。它是一个TypeScript库，你把它import进自己的应用，在它之上构建自己的常驻Agent。

目标场景是那些通过Slack、邮件或Telegram触达的always-on Agent。这类Agent的特点是生命周期长、触发来源分散、对可靠性敏感。用户不会因为Agent崩溃就守在终端前手动恢复，他们甚至不知道崩溃发生过——这正是持久化检查点要保障的体验。

视频作者还演示了一个本地运行的小模型版本：在自己的机器上搭一个完全本地的常驻Agent。这个demo的意义在于降低验证门槛——不需要云服务、不需要大模型API，就能观察检查点机制在崩溃恢复中的实际表现。

常驻Agent（always-on Agent） 与一次性CLI工具的根本差异在于生命周期和触发模式：它长期驻留、由外部事件（消息、邮件、定时任务）异步唤醒，且往往同时服务多个渠道和用户。这类系统对可用性的要求接近传统后端服务，崩溃恢复必须是自动化的。与之相对，编码Agent通常在开发者终端中交互式运行，崩溃后由人重启即可。Pi Durable以库的形式提供持久化能力，正是为了让开发者在自建常驻服务时复用这套恢复语义，而不是被迫接受某个成品Agent的运行时约束。

一个值得注意的设计取舍

把每个工具调用都写入持久化存储，代价是额外的I/O开销和存储增长。对于高频调用的Agent，JSONL文件会快速膨胀，SQLite也会面临写入压力。视频没有展开讨论检查点的清理策略或压缩机制，这是实际落地时需要自行评估的部分。

另一个隐含约束是工具调用的幂等性。检查点记录的是“调用已发出”还是“调用已完成”，决定了恢复时是否会重放副作用。发邮件这类操作天然不幂等，Pi Durable的状态机必须精确区分这两种情况，否则崩溃恢复反而会制造重复发送。原作者在演示中未深入这一层，但从工程角度看，这是持久化Agent无法回避的核心问题。

幂等性（Idempotency） 指同一操作执行一次与执行多次对系统产生的最终效果相同。查询、读取类操作天然幂等；而发邮件、转账、下单等操作具有副作用，重复执行会造成真实损害。在崩溃恢复语境下，关键问题是检查点记录的是“意图”还是“结果”：若检查点写在调用发出之前，恢复时可能重放已产生副作用的调用；若写在完成之后，则崩溃窗口内的调用可能被永久丢失。常见的工程解法是为每次操作分配唯一ID并在下游去重，或采用“两阶段”记录（先记pending再记done），让恢复逻辑能识别并处理中间态。

小结

Pi Durable把分布式系统里早已成熟的检查点思想搬到了AI Agent层：状态不信任内存，只信任磁盘。对于构建常驻、多渠道、无人值守Agent的开发者，这个思路提供了一个比“崩溃后手动continue”可靠得多的基础。它是一个库而非产品，这意味着灵活性和集成成本同时存在——要不要用它，取决于你的Agent是否真的需要“活过”崩溃。