@Rickkkkkkk 博客有提到，实现方式有点不一样。
https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon


3.1 Cycle：无界会话的基本单元

把会话想象成一串从左到右排开的 turn。窗口有上限，turn 在累积，窗口终会被填满。如果不干预，会话到达上限时要么结束，要么悄悄退化。

运行时在到达上限之前的几个固定位置介入。我们称这些位置为 checkpoint。每个 checkpoint 处，运行时派出一个独立的 writer subagent：读取迄今的对话，将一份结构化状态写入磁盘。主 Agent 继续工作，writer 并发执行，互不干扰。

当窗口接近真正的上限，运行时执行一次 rebuild：切断当前窗口，开启新窗口，用已持久化的文件作为种子重建上下文。主 Agent 在新窗口中醒来，状态已摆在面前，继续工作。从模型视角看，对话从未中断；从运行时视角看，一个新的物理窗口已经开始。

一段被 checkpoint 打过点、最终以 rebuild 收尾的 turn 序列，是一个 cycle。Cycle 没有数量上限——每一个 cycle 受限于物理窗口大小，但逻辑会话是 cycle 的链，而那条链没有最大长度。
3.2 为什么提早提取

一种自然的直觉是把提取拖到窗口快满时。我们发现这恰好是反着的。

第一，模型在高上下文利用率下能力会衰减。这在文献中被称为 "lost in the middle"：随着输入变长，对中段材料的注意力下降，结构化提取的可靠性显著降低。要求模型在它的压缩能力正在退化的时刻去做最关键的压缩，是一桩划不来的交易。

第二，提取本身需要空间。Writer 必须读完历史、维持解读、写出结构化输出——全部在同一个窗口里。95% 利用率下已无处思考；30% 利用率下则游刃有余。

因此 checkpoint 在远低于上限处触发——大致在已配置预算的 20%、45%、70%。每一次触发都是对前一次的增量更新，没有任何一次是孤注一掷的总结。最末尾接近上限的那次 rebuild，不是一次仓促的压缩，而是将一路记下来的结构化记录变现的时刻。