04 协调状态机

文档摘要

04 协调状态机本节摘要:前三节讲了上下文源、纪元三件套、对话中途消息。本节收尾,讲决定「一个变化能否立刻生效」的协调状态机(reconcile)。当快照 diff 发现某个源变了,reconcile 不会无脑生效,而是返回四种状态之一:无变化(unchanged)、有更新(updated)、可替换(replacement-ready)、阻塞(blocked)。本节讲清这四种状态的含义,重点解释为什么需要「阻塞」——有些更新不能在工具执行中途插进来,必须等。读完本节,你就完成了对 System Context 机制的完整理解。一、为什么需要状态机上一节我们看到,快照 diff 发现变化后,系统要决定「怎么办」。

04 协调状态机

本节摘要:前三节讲了上下文源、纪元三件套、对话中途消息。本节收尾,讲决定「一个变化能否立刻生效」的协调状态机(reconcile)。当快照 diff 发现某个源变了,reconcile 不会无脑生效,而是返回四种状态之一:无变化(unchanged)、有更新(updated)、可替换(replacement-ready)、阻塞(blocked)。本节讲清这四种状态的含义,重点解释为什么需要「阻塞」——有些更新不能在工具执行中途插进来,必须等。读完本节,你就完成了对 System Context 机制的完整理解。

一、为什么需要状态机

上一节我们看到,快照 diff 发现变化后,系统要决定「怎么办」。但「怎么办」不是一个二选一(生效/不生效),而是要看情况:

变化很小,不需要换基准?→ 走中途消息即可
变化很大,基准得换?→ 开新纪元
变化想立刻生效,但当前正在执行工具,插进来会乱?→ 得等
根本没变化?→ 啥也不用做

这就是 reconcile 状态机要理清的事——给定一个变化,判断它现在该走哪条路。

二、四种状态

reconcile 返回四种状态:

状态	含义	系统动作
unchanged(无变化)	这个源的事实没变	什么都不做
updated(有更新)	有变化,但不需要换基准	走对话中途系统消息(第 03 节)
replacement-ready(可替换)	变化足够大,基准可以整体替换	开新纪元,用新基准
blocked(阻塞)	有变化,但现在不能生效,得等	暂存,等安全时机再 reconcile


快照 diff 发现变化
   │
   ▼ reconcile 判定
   ├─ unchanged ──► 无事
   ├─ updated  ──► 中途消息
   ├─ replacement-ready ──► 新纪元
   └─ blocked  ──► 暂存,等待

三、为什么需要「阻塞」态

本节重点是「阻塞(blocked)」——它是最容易被忽略、却最关键的状态。

考虑这个场景:某个上下文源(比如指令源)变了,理论上该立刻让模型知道。但此刻工具正在执行——模型刚请求改一个文件,工具正在写。如果这时把「指令变了」插进去,会发生什么?

工具结果可能基于旧指令,但中途消息说指令变了——语义混乱。
工具结算还没完成,在它完成前插消息会破坏安全边界(第 03 节)。

所以这种更新必须阻塞,等工具结算完、到了安全边界,再 reconcile 一次,那时它可能变成 updated 或 replacement-ready。

⚠️ 阻塞不是丢弃:blocked 的变化不会被丢,而是被暂存。等到了安全时机,它会重新被 reconcile,最终一定会生效(以 updated 或 replacement-ready 的形式)。阻塞只是「现在不行,等一下」。

四、状态会流转

重要认知:reconcile 的状态不是一成不变的,它会随时间流转。一个变化可能经历:


时刻1(工具执行中):变化被判定为 blocked
   │ 工具结算完成,到安全边界
   ▼
时刻2(安全边界):重新 reconcile
   ├─ 变化仍在,且可生效 ──► updated 或 replacement-ready
   └─ 期间又叠加了新变化 ──► 合并后一起判定

这种「暂存 + 重新 reconcile」的机制,保证了变化既不会被丢,也不会在不安全的时候硬插。

五、一个完整例子

把四节串起来,走一个完整例子:


回合 4 开始
   │
   ├─ 取各源最新事实,生成新快照
   ├─ 与上回合快照 diff
   │    └─ 发现「环境源」变了(你切了分支)
   │
   ├─ reconcile 判定「环境源变化」
   │    ├─ 时刻判定:工具正在执行 ──► blocked
   │    │
   │    ▼ 工具结算,到安全边界
   │    ├─ 重新 reconcile
   │    └─ 判定:变化不大,不需换基准 ──► updated
   │
   ├─ 走对话中途系统消息:插入「分支切到 dev」
   │
   ▼ 回合 5 模型调用(模型已知分支变了,基准缓存仍命中)

你看,四节的知识在这一个例子里全用上了:源、快照 diff、reconcile、阻塞、中途消息、安全边界、基准缓存。

六、第 8 章收尾:你现在理解的 System Context

读完第 8 章四节,你完成了全书最深主题的攀登:

节	讲了什么
01 上下文源	结构化事实集合的最小单元(稳定 key + loader + 纯渲染器)
02 三件套	基准(稳定文本)+ 快照(diff 用 JSON)+ 纪元(不可变有效期)
03 中途消息	对话进行中事实变化时,在安全边界插一条按时间顺序的消息
04 reconcile	四态状态机,决定变化能否立刻生效,blocked 保证不乱插

这套机制是 OpenCode 给模型管理上下文的「研究级」方案。它的核心思想是:用结构化代替字符串、用冻结代替频繁改写、用追加代替篡改、用状态机代替无脑生效。理解了它,你就理解了一个工业级 Agent 如何精确控制模型看到什么、何时看到、如何安全地让信息演化。

本节要点回顾

reconcile 是状态机:决定一个变化现在该走哪条路,返回四态。
四态:unchanged(无事)/ updated(中途消息)/ replacement-ready(新纪元)/ blocked(暂存等待)。
blocked 最关键:工具执行中途的更新必须阻塞,否则破坏安全边界、语义混乱。
阻塞不是丢弃:blocked 的变化被暂存,到安全时机重新 reconcile,最终一定生效。
状态会流转:同一个变化可能 blocked → updated/replacement-ready。
第 8 章结束:你已掌握 System Context 全貌——结构化、冻结、追加、状态机,这是工业级上下文管理的范本。

第 8 章结束。这套上下文机制还有一个紧密相关的主题——当上下文超过模型窗口时怎么办?那就是第 9 章的「上下文压缩」。