KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
OpenClaw 解析 — keel 龙骨
OpenClaw 的参考信息：OpenClaw 解析
课程导读 · 把 20 个渠道、100 个插件、一个 Agent 收进同一个常驻进程
这门课针对一个具体问题：当 Agent 不再是「你打开它它才跑」的工具，而是一个 7×24 常驻、同时接入 WhatsApp / Telegram / Slack 的个人助理时，进程模型、安全模型、扩展模型分别要怎么改？
谁在常驻 → 一轮怎么跑完 → 危险动作怎么拦 → 消息从哪来到哪去 → 第三方怎么扩展它
五章的对应关系：
| 章节 | 解决的核心问题 |
|---|---|
| 01 定位与 Gateway | 为什么必须单例 Gateway，崩溃了怎么办 |
| 02 主循环与护栏 | 没有轮数上限的循环靠什么兜底 |
| 03 工具与执行安全 | deny / allowlist / full 三级 × 审批 × 会话模式怎么叠加 |
| 04 渠道与路由 | 渠道消息怎么归一化，多用户为什么是归因不是隔离 |
| 05 插件 / 记忆 / 部署 | bundled 扩展为什么也要守插件边界，审计为什么只存元数据 |
每章结构统一：正文机制 → 代码地图 → 关键取舍 → 自测题。
这门课的一条主线
常驻 + 多渠道 = 更大的攻击面与更长的生命周期
→ 于是所有「信任决策」都被推到边界上：渠道要配对、执行要分级、插件要签名
→ 所有「生命周期问题」都交给两个机制：单例锁（防重复）与循环检测（防失控）
→ 所有「隐私问题」都用「少存」解决：审计只存元数据，不存正文
→ 这三条解释了它大部分「看起来过分谨慎」的设计
第 02 章的工具循环检测、第 03 章的四层收紧、第 05 章的 Ed25519 目录签名与 metadata-only 审计，都能用这条主线串起来。读完你应该能回答：为什么它连自己 bundled 的 156 个扩展都不许 import 内部模块？
与其它板块的关系
- Hermes 板块：同为多渠道常驻助理。Hermes 用七种宿主平铺 + 技能自改进；OpenClaw 用单 Gateway + 插件单槽位。两门课对照读，能看到「常驻助理」这类产品的两种组织哲学。
- DeepSeek 板块：两者都是 TypeScript monorepo，但一个把扩展性做进内核（Cordis 插件响应式），一个把扩展性做进边界（插件 API + 签名市场）。
- 对比课：本板块代表「本地控制平面 + 渠道聚合」这一类，九槽位对比里有它的完整定位。
版本与可信度
- 分析对象是官方仓库 2026.8.1；同机另存有 2026.5.6 旧版可作演化参考，本课程结论一律以新版代码为准。
- 迭代快、文件多（
src/agents/tools/253 个文件），行号只作定位参考，请以符号名为准。 config/目录容易误解：它是构建与静态检查配置，不是运行时配置——运行时配置由src/config/加载与校验，这类易混淆点课程中均已标注。