3.0 OpenClaw Overview¶
核心洞察
OpenClaw 的State Management哲学可以用一句话概括：磁盘优先、层层设防、配置驱动。每次 run 从磁盘恢复状态（不假设进程常驻），压缩前先 Memory Flush 保存再丢弃，工具过滤用 7 层配置管道而非 LLM 判断。它不追求单用户的极致性能，而是在多渠道、多用户场景下提供可靠、可恢复、可审计的State Management。
分析基础¶
| 项目 | 值 |
|---|---|
| 来源 | GitHub 开源 openclaw/openclaw |
| 规模 | 11,295 个 .ts/.js 文件，~2.15M 行 |
| 架构 | Gateway 服务 + 多渠道收发 + 嵌入式 Agent 运行时 |
OpenClaw 是一个 Gateway 多渠道平台。消息可能来自 Slack、Discord、Web 等不同渠道，两条消息之间可能间隔数小时，Gateway 随时可能重启。这决定了它必须把所有状态写到磁盘，每次 run 从磁盘恢复——这是与 Claude Code（进程内存优先）最根本的差异。
State Management 核心原则¶
1. 磁盘优先，可恢复
对话历史持久化为 JSONL transcript，会话元数据持久化为 SessionEntry JSON，原子写入防崩溃损坏。这带来了 Claude Code 不需要面对的问题：反序列化后需要 sanitizeSessionHistory 校验修复，Gateway 和磁盘之间需要 RPC 同步。详见Context Management。
2. 防御性编程，先保存再丢弃
压缩不是直接丢弃旧消息，而是五步安全网：Memory Flush 先写盘（Memory 系统）→ 可插拔 Provider 压缩 → transcript 替换 → 补注入 AGENTS.md 关键约束 → 检查点支持回滚（Context Management）。
3. 配置驱动，可审计
工具过滤用 7 层策略管道而非 LLM 分类器（Tool Management），Skill 白名单按 Agent 配置而非模型判断（Skill 系统）。在多用户场景下，配置驱动比模型驱动更可预测、成本更低、更易审计。
与 Claude Code 的关键差异¶
| 维度 | Claude Code | OpenClaw |
|---|---|---|
| 状态住在哪 | 进程内存（快但不持久） | 磁盘（慢但可恢复） |
| 压缩哲学 | 保缓存优先 | 保信息优先 |
| Memory 召回 | Sonnet 主动预取（每 turn 自动） | memory_search 被动检索（按需） |
| 权限判断 | LLM 分类器（灵活但不可预测） | 配置管道（可预测但需预定义） |
| 动态 Context注入 | Attachment 系统（30+ 类） | 无等价机制 |
| Sub-agent 状态共享 | Fork 共享 Prompt Cache | 独立 Session（无缓存概念） |
| 运行时状态修改 | 无 | Steer 机制（Sub-agent） |