协作式检查点:进度条、CancellationToken 和 AI Agent 的 steering,原来是同一个设计模式

引子

最近在研究开源 AI coding agent Pi 的架构,看到它处理"用户中途插话"这个功能(官方叫 steering)的实现方式时,忽然意识到一件事:这套机制我们早就在别的地方见过无数次了——进度条的取消按钮、.NET 的 CancellationToken,本质上都是同一个东西。

这篇文章想聊清楚这个模式:协作式检查点(cooperative checkpoint / yield point)。

抢占式 vs 协作式

先说结论:不是抢占式(preemptive),而是协作式(cooperative)。

真正的"随时打断"需要抢占——比如操作系统给线程发信号、强行挂起。这条路要处理任意时刻的状态一致性问题:锁有没有释放、原子操作有没有做完一半、部分完成的写操作要不要回滚。实现成本很高,也极容易出 bug。

协作式的做法反其道而行之:把连续的工作拆成一个个离散的、状态一致的单元(unit of work),只在单元与单元的边界上主动问一句"有没有新指令、要不要停"。单元内部完全不被打扰,这就保证了每次检查点触发时,系统状态都是干净、可预测的——不存在"打断到一半"这种情况。

进度条:同一个模式的最朴素版本

进度条从来不会在循环体内部任意时刻更新 UI——那样反而会拖慢速度,甚至造成竞态。它的做法是:每完成一个"块"(一个文件、一批数据、一次迭代),才去更新一次进度、顺便检查一下有没有取消信号。

块与块之间的边界,就是检查点。

CancellationToken:.NET 技术栈里早就有的例子

CancellationToken 是最典型的协作式取消:.NET 不会强行杀掉线程,而是要求你在循环体的安全点主动调用 token.ThrowIfCancellationRequested()。

取消请求什么时候真正生效,完全取决于检查点的粒度:

• 粒度越粗(比如一次处理 10000 行才检查一次),响应越慢;
• 粒度越细,响应越快,但检查本身的开销越大。

这其实是一个典型的工程权衡,没有标准答案,只有"适合当前场景的选择"。

Pi 的 steering:把粒度选在工具调用之间

Pi 是一个开源终端 AI coding agent,它支持在 agent 跑任务的过程中插入一条"steering 消息"来临时改变它的行为——比如它正在跑一串 bash 命令,你可以随时打断,让它改用别的方案。

它把检查点的粒度选在了工具调用之间:一次 bash 命令、一次文件读写,这些天然就是不可分割、状态一致的单元。选它们做检查点边界有两个好处:

1. 不需要在工具执行中途插入检查逻辑,避免搞乱工具本身的状态;
2. 响应速度足够——用户很少会在单个 bash 命令跑到一半时就着急打断。

具体流程是:工具执行完之后,检查一下有没有排队的 steering 消息;如果有,剩下还没跑的工具调用直接跳过(标记为"因插话被跳过"),把新消息插入对话历史,让模型立刻针对这次打断做出响应。

三者其实是同一个模式

场景	工作单元	检查点触发的动作
进度条	一个文件 / 一批数据	刷新 UI、检查取消信号
CancellationToken	循环体的一次迭代	ThrowIfCancellationRequested()
Pi 的 steering	一次工具调用	读取 steering 队列

三者的底层逻辑完全一致:用工作的自然分块边界替代真正的抢占式中断,用轮询代替信号。

一点延伸思考

这个模式能成立,前提是"工作单元"本身要足够小、足够自然。如果你的工作单元是一次跑几分钟的批处理任务,协作式检查点的响应延迟就会变得不可接受——这时候要么把单元拆得更细,要么就得认真考虑抢占式方案(比如真正杀掉子进程)。

反过来说,如果你发现自己在某个系统里到处塞抢占式的中断逻辑,搞得代码里全是锁和状态回滚,不妨想一想:能不能先把连续工作拆成天然的小单元,再用一个简单的检查点搞定大部分场景?这往往是投入产出比更高的选择。