Monday Meditations
Pi Durable：为什么不用 Temporal 或 Effect？
AI 总结
阅读要点根据本期转写整理；点击时间戳回听原话。
从单人会话走向长期、多人的 agent
Pi Coding Agent 的会话模型适合一个人与 agent 的短期交互。两人介绍 Pi Durable 的动机：让长期运行、多人参与、包含并行分支的 agent 能在不同运行环境中暂停和恢复。
把执行拆成可恢复的任务
核心思路是分别持久化任务意图与执行结果，把模型请求、工具调用和子 agent 纳入任务图。恢复时可以知道执行停在哪里，但工具是否可以安全重放仍需要明确声明。
持久化 harness 不等于持久化整个世界
文件系统、部署和外部服务仍有自己的状态。两人强调还需要快照、幂等操作或适当的存储设计；仅仅引入一个工作流引擎，并不能自动解决所有恢复问题。
把执行与状态存储放在同一设计里
需要一起恢复的状态必须能够原子地持久化。Pi Durable 内置任务调度，让应用也能加入任务与状态；较大的数据可以放在外部存储，在 harness 中保存引用。
为何不直接套用 Temporal 式抽象
他们希望检查点、名称和版本更显式，便于 agent 修改自身代码时理解持久化数据。讨论中对比了通过重放恢复函数调用栈与恢复自包含任务树的取舍。
为何没有选择 Effect
两人肯定 Effect 的结构化并发、错误和服务组合能力，但认为这些能力本身不等于跨进程恢复。引入其工作流方案还会带来整套生态与可移植性的取舍，因此选择保持底层自包含。
先验证底层数据模型，再增加抽象
他们邀请使用者尝试仓库中的示例，反馈数据与状态模型是否满足实际需求。更高层的状态管理封装仍在探索，团队也计划用自己的产品和实际应用检验这套基础。