Pi Durable 与 OpenCode 的架构对比

曾几何时，当你眯起眼睛远观，几乎所有主流编码框架的架构都大同小异。直到 Pi Durable 的出现。

在此之前，编码框架已经形成了一套相当可辨识的模式：一个包含对话的会话、一个不断向模型发送上下文的运行中 Agent 循环、在循环中进出的工具调用，以及持续运行直到任务完成的框架主体。

Claude Code、Codex、Pi 和 OpenCode 都各自实现了这套方案。

而 Pi Durable 的做法不同。它同样拥有对话，但将模型生成、工具调用、压缩（compaction）以及应用自定义工作全部设计为持久化任务。一个调度器在这些任务上运作，存储层同时保存了 Agent 的历史记录和框架尚未完成的工作。

这看似只是一个实现细节，实际上不是。它从根本上解锁了编码框架的全新能力。

本文将 Pi Durable 与 OpenCode 进行对比。OpenCode 在许多方面代表了典型的基于会话的框架，研究它的价值尤其大，因为它是开源的，并且暴露了足够的内部实现，可以看到一个成熟系统究竟是如何运作的。

以下是两种编码框架架构之间的主要差异。

1. Pi Durable 将 Agent 循环序列化到存储中

OpenCode 将会话作为系统中长期存在的核心部分。运行中的框架读取该会话来构造模型请求，并不断将结果和工具调用响应写回会话，然后决定何时再次调用模型。

需要强调的是，OpenCode 持久化了大量状态，你可能会因此认为它与 Pi Durable 一样具有持久性。但关键区别在于：存储的是会话状态还是执行状态。

OpenCode 存储的是会话状态。除了对话历史之外，它还持久化了提示词（prompt）、工具活动记录以及会话相关的其他状态。但 OpenCode 当前的架构只将活动中的执行过程保存在进程本地内存中，并未使其持久化。

Pi Durable 则存储了更多通常存在于运行器（runner）内部的内容。框架运行的一切都是任务。一次模型生成是一个任务，每一次工具调用是一个任务，扩展还可以引入新的任务类型。任务在推进过程中会存储检查点（checkpoint），并且可以在存储中保持未完成状态。

任务系统还单独记录了仍在进行中的执行过程，形成了一份持久化的工作台账。另一个进程可以打开同一个存储，找到未完成的任务，继续执行它们。

2. 让工作可被调度

在 OpenCode 中，活动的 Agent 循环负责推进工作。毕竟，它是一个循环——调用模型，处理返回的工具调用，持续执行直到本轮完成。如果有多个会话处于活动状态，每个会话都有各自的循环，由运行时驱动。

Pi Durable 将更多责任转移到了调度器上。由于生成和工具调用都以任务形式存储，调度器可以查看持久化状态，判断哪些工作可以运行。模型响应可以创建工具任务，这些任务可以创建更多工作或等待其他任务，而一个任务的完成可以让另一个任务变为可运行状态。

这也意味着工作不再绑定于启动它的进程。在笔记本睡眠、容器重新部署或机器内存耗尽之后，任务仍可以留在存储中。另一个进程可以打开同一个存储，查看哪些任务未完成且可运行，然后继续执行。

运行中的 Agent 循环不再需要负责推动工作前进，调度器可以根据存储的任务状态决定接下来应该运行什么。正如你将在下文看到的，这开启了一系列新的可能性。

3. 将应用状态与对话融合

OpenCode 在对话周围持久化了大量结构化状态，包括会话、消息、工具活动、待处理输入、上下文和事件。这些都支撑了跨轮次的工作。但这些状态主要服务于 OpenCode 自身的运行，应用状态通常存在于其他地方。

Pi Durable 将应用状态引入了框架本身。它为不适合放在对话记录中的状态引入了带类型的文档（typed documents）。计划、工单、待办列表、沙箱配置或其他应用数据都可以与对话一起存储。

更重要的是，文档与对话条目和任务参与同一个原子提交（atomic commit）。Agent 可以在一个提交中同时更新应用状态、记录产生该变更的对话内容、以及创建新的工作。这些部分不可能因为进程在两次写入之间崩溃而失去同步。

Pi 还定义了当对话分叉（fork）时文档的行为。文档可以跟随分叉点的值、使用最新的值，或在新对话中从头开始。

框架不再仅仅负责持久化对话及其执行过程，它还可以成为 Agent 所处理的应用状态的持久化宿主。

4. 将压缩移出关键路径

OpenCode 和 Pi Durable 都将存储的对话与当前提供给模型的上下文分离开来。OpenCode 即使在旧消息不再发送给模型后仍保留完整的对话记录。其压缩架构会创建一个包含滚动摘要和近期上下文的检查点，作为后续模型请求的历史边界，而不删除旧的对话记录。

在 OpenCode 中，压缩是会话生命周期中的一个特定环节。而 Pi Durable 则将压缩作为一个任务来处理，使用与模型生成和工具调用相同的任务系统。

这意味着 Pi 可以在到达上下文限制之前就开始压缩，并在 Agent 继续工作的同时在后台运行。当摘要准备好后，Pi 可以在之后的轮次边界处插入它。Agent 不必一定要到达上下文上限、停止、等待压缩完成，然后才能继续。

压缩还获得了与其他 Pi 任务相同的持久性保障。如果运行时在摘要生成过程中消失，压缩作为未完成的工作可以由任务系统恢复，而不是由活动的 Agent 循环从头开始重做。

因此，上下文维护可以移出 Agent 循环的关键路径，变成调度器可以提前启动、并行运行并独立恢复的工作，而底层对话保持完整无损。

5. 委托作为工作图

OpenCode 已经通过子 Agent 和子会话支持委托。父 Agent 可以启动另一个 Agent，在前台等待它，或让它在后台继续运行。但这些工作之间的协调仍然主要由运行中的框架管理。

Pi Durable 将这些关系纳入其持久化任务模型。任务和对话形成一棵所有权树。一个任务可以拥有子任务，一个工具可以为子 Agent 创建独立的对话，一个任务可以持久化记录它正在等待其他任务完成才能继续。

这围绕委托在对话之间的运作方式引入了新的语义。如果一个父任务被中止，Pi 可以将该中止传播到它所拥有的所有工作。后台工作可以跨越所有权边界，在创建它的前台工作完成后继续运行。更重要的是，即使对话变得空闲，任务也可以继续运行。

Pi Durable 的方法为调度器提供了更多关于委托工作的信息。调度器知道哪些任务拥有其他任务、哪些工作在等待、哪些工作被允许独立继续运行。这为调度更复杂的 Agent 和后台工作组合奠定了更坚实的基础。

6. 工具调用成为持久化工作

OpenCode 将工具调用作为活动 Agent 循环的一部分来执行。当模型请求调用工具时，运行时执行它，将结果记录在会话中，然后继续循环。对于许多编码工具来说，这种方式运作良好，因为操作可以简单地重复执行，或者其结果可以在之后检查。

Pi Durable 将工具调用本身也纳入了持久化任务模型。在工具执行之前，调用就会被存储为一个任务。这意味着 Pi 可以区分三种情况：一个从未被请求过的工具、一个正在运行的工具、以及一个已完成并返回结果的工具。

这看起来像是一个不起眼的恢复机制，但当 Agent 执行更多副作用操作时，它就变得至关重要。如果执行被打断且需要重启，重新读取一个文件是无害的。但一次部署、一笔支付或其他外部操作可能已经成功执行了，即使框架从未收到结果。简单地重新运行该工具可能会重复产生副作用。

Pi 允许工具自行定义是否可以安全地重放（replay）。可重放的工具可以在中断后重新运行。否则，Pi 可以将被中断的调用返回给模型（包括已经存储的输出），让模型决定下一步该怎么做。

对 Agent 系统进行微调度

Pi Durable 让人感觉这是迈向更复杂、更可组合的 Agent 系统的一步，在这样的系统中，调度将成为框架中远比以往更重要的组成部分。一旦我们将 Agent 的工作分解为小型的持久化任务，系统就拥有了更大的自由度来决定什么应该运行、何时运行、以及应该等待什么。

这里有一个操作系统的类比。进程的存在独立于它当前是否获得 CPU 时间，而调度器决定哪些可运行进程获得可用资源。Pi Durable 目前还没有像操作系统那样做任意抢占（preemption），但它使类似的模型成为可能。

基于会话的框架已经将编码 Agent 推到了很远的地方。Pi Durable 指向了一个新篇章：框架需要在更多资源上协调更多种类的工作，而调度将成为架构中远比以往更重要的组成部分。