技术讨论｜Pi Durable 与持久执行：普通会话如何获得可恢复的任务内核？

[ydflow]

讨论目标

下一步计划参考 Pi Durable，把 Trail 从研究专用恢复，推进到普通助手与长期个人任务可复用的持久执行内核。先讨论契约与最小实验，再决定采用范围。

当前起点与缺口

研究恢复设计 已描述 checkpoint 校验、原子写入、结果复用、配置身份与预算。未提交的远端读取仍可能重试，现有证据也有 headless、桌面与 runtime 的覆盖区别。

普通会话、任务图以及未来外部写操作，需要独立明确恢复语义。消息历史可以帮助理解对话，执行 checkpoint 还需要说明哪些动作已经提交、哪些结果可复用、哪些步骤处于不确定状态。

为什么参考 Pi Durable

Pi Durable 官方文档 提供了持久执行的设计参考。上游标注为实验性 API，适配需要固定版本并验证 Trail 的 Bun、Electron、Node、现有 Pi adapter 与存储契约。

其中运行时的 MemoryStorage 是存储实现概念，不等于个人长期语义记忆；后者另见 Memory 讨论。

建议的最小验证链路

创建只读两步任务
→ 提交第一步工具结果
→ 在第二步前强制结束进程
→ 重启并读取 checkpoint
→ 展示恢复依据
→ 继续任务并核对工具调用次数

实验应同时记录：已完成读取是否重复、预算是否保留、取消是否生效、配置变更如何处理、坏文件如何拒绝，以及哪里仍可能出现远端请求不确定性。

希望得到的设计意见

1. 应当直接采用、包装适配，还是先保留现有研究恢复内核？
2. session、run、turn、tool、task 的稳定身份如何映射？
3. 哪类任务能够自动重放，哪类必须等待用户核对？
4. 旧 checkpoint 如何迁移？上游 API 变化时怎样退出？
5. 哪个故障点应成为第一项桌面恢复验收？

预期产物

先交付版本固定的适配 PoC、兼容矩阵和 ADR。随后逐步扩展任务图、通用 checkpoint、副作用日志与故障注入矩阵。

实施任务：适配 RFC #10、任务图 #11、通用 checkpoint #12、副作用日志 #13、故障注入 #14。

---

社区导航 · 项目愿景 · 实施 Roadmap