第7章：状态管理算法

Tue, 09 Jun 2026 00:00:00 +0800

“程序的本质就是状态与状态之间的转换。” —— Edsger W. Dijkstra

7.1 问题引入：百态纷呈的 Agent 系统

想象一个拥有超过 100 个状态属性的 AI Agent 系统。它需要同时管理：

对话历史：数十轮多模态消息，包含用户输入、模型回复、工具调用结果
工具权限：每个工具的授权模式（允许、拒绝、询问），可在运行时动态变更
用户配置：来自用户设置、项目设置、企业策略、命令行参数等多层级配置源
UI 状态：展开/折叠视图、模型选择、通知队列、输入提示等
任务状态：后台任务的生命周期、子 Agent 的运行状态、团队协作信息
会话元数据：会话 ID、权限模式、远程连接状态、推测执行状态

当多个组件同时读写这些状态时，如何确保变更可预测、不产生副作用？当配置文件在磁盘上被外部修改时，如何实时感知并正确合并？当会话中断后恢复时，如何从持久化的日志中重建完整状态？

这些问题的本质是一个经典的工程挑战：在复杂系统中实现可预测的状态管理。Claude Code 源码为我们展示了一套精巧的解决方案——它融合了不可变状态机、发布-订阅、选择器订阅、层级合并、事件溯源等多种算法思想，构建了一个既高效又可靠的状态管理体系。

7.2 算法思想

7.2.1 不可变状态机算法

核心原则：状态只能通过纯函数转换，旧状态永不修改。

不可变状态机的思想源自函数式编程：给定当前状态 S 和一个转换函数 f，新状态 S’ = f(S)。旧状态 S 在转换过程中不被修改，它依然可以被引用和比较。这一原则带来三大好处：

变更检测极其廉价——只需 Object.is(prev, next) 即可判断是否发生变更，时间复杂度 O(1)
不存在并发修改的竞态条件——因为没有人能修改已经发出的状态快照
天然支持时间旅行——旧状态快照可以保留，用于调试或回溯

Claude Code 在类型层面通过 DeepImmutable<T> 泛型强制保证不可变性。AppState 的核心字段被 DeepImmutable 包裹，编译器会阻止任何对深层属性的直接赋值。

// 类型层面的不可变保证
type AppState = DeepImmutable<{
 settings: SettingsJson
 verbose: boolean
 mainLoopModel: ModelSetting
 toolPermissionContext: ToolPermissionContext
 // ... 100+ 字段
}> & {
 // 少数包含函数类型的字段排除在 DeepImmutable 之外
 tasks: { [taskId: string]: TaskState }
 mcp: { clients: MCPServerConnection[]; tools: Tool[]; ... }
}

注意 DeepImmutable 与交叉类型 & 的组合使用：核心配置字段（settings、verbose、权限上下文等）被严格冻结；而包含回调函数或可变引用的字段（tasks、mcp）则排除在外。这是实用主义的不可变性——在类型安全和运行时灵活性之间取得平衡。

会话持久化 on Last Stand

第7章：状态管理算法

7.1 问题引入：百态纷呈的 Agent 系统

7.2 算法思想

7.2.1 不可变状态机算法