如果只抓一条主线，我会先抓 Gateway 到运行时这条链
我不会先从“最有趣的模块”开始
读 OpenClaw 这类源码导读，最大的危险不是看不懂某一章，而是读法散掉。
如果每次都被 Browser、Sandbox、Sub-agent、ACP 这些局部亮点吸走注意力，最后你会知道很多零件，但脑子里没有一条主骨架。
所以如果我只能抓一条主线，我会先抓：
- Gateway 怎么接住消息
- 消息怎么进入控制平面
- 控制平面怎么把任务送进运行时
- 运行时怎么组织上下文、工具和执行结果
为什么先从 Gateway 开始
因为 OpenClaw 不是“本地单体 Agent”，它首先是一个要面对 Discord、Telegram、Webchat 这类入口的真实系统。
如果不先抓入口，你很容易误把它读成“又一个 Agent runtime”，而忽略它真正困难的地方：
- 消息从哪来
- 多渠道如何统一
- 会话身份怎么映射
- 路由和绑定怎么做
这也是为什么我会把它先当 control plane 源码导读，而不是普通 Agent 教程。
第二步：控制平面才是系统骨架，不是配角
很多人读真实系统时，会下意识把注意力放在“模型怎么调”“工具怎么跑”。
但 OpenClaw 更值钱的地方，恰恰是把控制平面做成了明确结构：会话生命周期、路由、队列、绑定、策略、状态管理，这些都不是边角料。
第 20 章 ACP 其实很能说明这一点。它把一个新能力拆成三层：
- 控制平面
- 接口层
- 后端实现
这就暴露了 OpenClaw 的系统思路：真正难的不是“接个新 Agent”，而是“让这个能力安全、可恢复、可流式、可绑定地进入整个系统”。
第三步：再进入运行时，才不容易迷路
等消息入口和控制平面骨架立住之后，再去看 Pi 引擎、上下文、记忆、工具、Sandbox、Browser，理解会完全不同。
这时候我关心的不再是“这里有几个模块”，而是：
- 这些能力怎么被同一个运行时组织起来
- 哪些状态在会话层，哪些状态在运行时层
- 工具结果、上下文和记忆分别在哪条链路里发挥作用
没有前面的入口和控制平面，运行时很容易被读成一堆独立特性。
ACP 这章为什么反而能证明这条读法是对的
第 20 章不是最基础的一章，但它把这条主线讲得很清楚。
它展示的不是“Claude Code / Codex 怎么接进来”，而是：
- 消息流水线如何触发 ACP
- AcpSessionManager 如何管理会话生命周期
- SessionActorQueue 如何串行化每个 session 的操作
- RuntimeCache 和 session identity 如何处理复用与重启恢复
- 外部 Agent 输出如何被流式 relay 回父会话
这其实就是一条非常典型的“入口 -> 控制平面 -> 运行时适配 -> 输出回流”链。
如果现在时间很有限
如果我没有时间读很多章，我会优先抓这四类内容：
- 项目定位和整体结构
- Gateway / 控制平面 / 消息流水线
- Pi 引擎与核心运行时能力
- ACP 作为外部 runtime 接入样板
只要这四类先串起来，后面的扩展、安全、插件、外部协议就不再是散点。
最后一个判断
OpenClaw 最不该被读成“功能清单”。
它更应该被读成一条系统链：消息怎么进，控制怎么立，任务怎么跑，结果怎么回。
只有先把这条链抓住，后面的源码细节才有坐标。