📂 源码解剖 · 🔍 调用链路 · 🛠️ 调试技巧 · 🤝 贡献指南

OpenClaw 源码剖析
从零读懂龙虾架构

Source Code Deep Dive: Understanding the Lobster Architecture

🏗️ 架构全景
⚙️ Gateway 网关
🧠 Agent 循环
📨 消息流转
🔧 工具系统
💾 记忆机制

GitHub 27.8k⭐ · 2026.3.2 最新版 · 十大执行步骤 · 四个反共识洞察

📖 4 大部分 | 16 章精讲 | 🏗️ 架构全景 | ⚙️ 核心模块

📨 数据流分析 | 🔌 扩展机制 | 📊 性能优化 | 🔐 安全模型

🔥 2026 年 3 月第一版 · 万字源码逐行解析

献给想深入理解 OpenClaw 内部运作机制的开发者

开始阅读 →

📑 全书结构

本书共 16 章,分为 4 大部分,全面剖析 OpenClaw 源码架构。第一部分讲解架构全景,包括整体设计哲学、目录结构、启动流程、配置系统;第二部分深入核心模块,涵盖 Gateway 网关、Agent 执行循环、会话管理、工具系统;第三部分追踪完整数据流,从消息接收、路由分发、工具调用到响应流式传输;第四部分探讨扩展机制,包括 Skills 加载器、Channel 插件系统、记忆后端、安全沙箱。

PART 1 · 架构全景
整体设计、目录结构、启动流程、配置系统
第 1 章
OpenClaw 设计哲学
本地优先、网关架构、上下文工程、二道贩子模式
第 2 章
源码目录结构
src 分层、apps 客户端、extensions 插件、docs 文档
第 3 章
Gateway 启动流程
服务生命周期、端口绑定、认证初始化、渠道监听
第 4 章
配置系统详解
JSON5 Schema、Zod 验证、热重载机制、Profile 隔离
PART 2 · 核心模块
Gateway 网关、Agent 循环、会话管理、工具系统
第 5 章
Gateway 网关 internals
WebSocket RPC、设备配对、健康检查、诊断事件
第 6 章
Agent 执行流水线
runReplyAgent、runAgentTurnWithFallback、runEmbeddedPiAgent
第 7 章
System Prompt 构建
上下文注入、工具描述、Skills 加载、Memory 集成
第 8 章
工具系统架构
Exec Tool、后台进程、沙箱隔离、权限过滤
第 9 章
会话管理机制
Session Key、DM Scope、历史压缩、持久化策略
第 10 章
模型提供商适配
Anthropic/OpenAI/MiniMax/Gemini、认证配置文件、故障转移
PART 3 · 数据流
消息接收、路由分发、工具调用、响应流式
第 11 章
消息接收层
inbound/monitor.ts、去重合并、权限检查、媒体下载
第 12 章
路由决策引擎
bindings 匹配、resolveAgentRoute、广播模式、回声检测
第 13 章
工具调用链路
Pi SDK 集成、createAgentSession、streamFn、事件订阅
第 14 章
流式响应传输
message_update、onPartialReply、deliverWebReply、分块发送
PART 4 · 扩展机制
Skills 加载、Channel 插件、记忆后端、安全沙箱
第 15 章
Skills 加载器
SKILL.md 解析、工作区扫描、优先级规则、元数据验证
第 16 章
插件与扩展系统
Plugin SDK、Channel 扩展、记忆后端切换、Hook 机制
Part 1 · Chapter 1
CHAPTER 1

OpenClaw 设计哲学

本地优先 · 网关架构 · 上下文工程 · 二道贩子模式 · 四个反共识洞察

1.1 什么是 OpenClaw

📋 本章要点:理解 OpenClaw 的核心定位;掌握四大设计原则;洞察上下文工程的本质;认识"二道贩子"模式的价值;学习四个反共识认知。

OpenClaw 是一个自托管、多渠道的 AI Agent 网关,它将 messaging platforms(WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等)连接到 AI coding agents。它作为单个持久进程运行,管理会话、路由消息、执行工具并协调 Agent 交互。

关键特性

  • 单一 Gateway 进程:服务所有渠道和客户端,统一控制平面
  • Pi SDK 运行时:使用 @mariozechner/pi-agent-core@mariozechner/pi-ai@mariozechner/pi-coding-agent
  • 配置驱动:严格的 Zod Schema 验证(OpenClawSchema
  • 插件架构:支持 Channel 扩展和自定义集成
  • 多 Agent 路由:每 Agent 独立 workspace 和 sessions
  • 沙箱支持:基于 Docker 的隔离,用于不受信任的会话
"OpenClaw 表面上是 AI 产品,底层更像一个本地消息操作系统。Gateway 才是 control plane,assistant 只是它呈现出来的产品形态。" —— OpenClaw README

1.2 四大设计原则

原则一:本地优先(Local-First)

OpenClaw 的所有状态、配置、会话历史都存储在本地(默认 ~/.openclaw),确保用户对数据有完全控制权:

  • 数据主权:会话记录、记忆文件、认证凭证全部本地存储
  • 离线可用:即使断网,已配置的本地模型仍可运行
  • 隐私保护:敏感信息不出本地,仅必要的 API 请求发送到模型提供商
  • 可迁移性:复制 ~/.openclaw 目录即可完整迁移到新机器
~/.openclaw/ 目录结构
~/.openclaw/
├── openclaw.json          # 主配置文件(JSON5)
├── .env                   # 环境变量覆盖
├── credentials/           # OAuth/API Key 存储
│   └── whatsapp/<accountId>/creds.json
├── agents/
│   ├── main/
│   │   ├── agent/auth-profiles.json  # 认证配置文件
│   │   └── sessions/sessions.json    # 会话历史
│   ├── researcher/
│   │   └── ...
│   └── writer/
│       └── ...
├── workspace/             # 默认工作区
│   ├── AGENTS.md
│   ├── SOUL.md
│   ├── MEMORY.md
│   ├── memory/YYYY-MM-DD.md
│   └── skills/
├── logs/                  # 日志文件
└── state/                 # 运行时状态

原则二:网关架构(Gateway Pattern)

OpenClaw 将自己定位为 Gateway(网关),而非简单的聊天机器人。网关是整个系统的控制平面:

  • 统一入口:所有 IM 渠道的消息都汇总到 Gateway
  • 集中路由:根据 bindings 规则将消息分发到不同 Agent
  • 资源调度:管理工具调用、模型选择、并发控制
  • 状态同步:维护全局会话树、记忆索引、诊断事件
🏗️ Gateway 网关架构图
用户层(User Layer)
WhatsApp · Telegram · Discord · Slack · Signal · iMessage
网关层(Gateway Layer)
消息监听 · 路由分发 · 安全验证 · WebSocket RPC · 健康检查
代理层(Agent Layer)
会话管理 · 上下文组装 · 工具选择 · 模型调用 · 记忆读写
工具层(Tools Layer)
文件读写 · 命令执行 · 浏览器控制 · Web 搜索 · 第三方 API
记忆系统(Memory System)
QMD 后端 / SQLite Builtin · FTS5 全文检索 · sqlite-vec 向量搜索

原则三:上下文工程(Context Engineering)

这是 OpenClaw 最核心的竞争力。它不是简单地调用模型 API,而是精心构建完整的运行时上下文:

  • 路由上下文:确定哪个 Agent 处理、关联哪段 session history
  • 工具上下文:加载哪些 tools、它们的描述和参数 schema
  • 技能上下文:注入哪些 SKILL.md、如何影响 system prompt
  • 环境上下文:工作目录、可用文件、系统规则、时间时区
  • 记忆上下文:长期记忆召回、跨会话引用、语义搜索
⚠️ Token 消耗真相:一个看似简单的"帮我整理投标方案"请求,实际消耗的 token 可能比你想象的多 3.8 倍以上。因为 system prompt 会注入大量上下文:工具描述、Skills 文档、记忆文件、workspace 说明等。

1.3 "二道贩子"模式

OpenClaw 不生产智能

在最核心的 attempt.ts 中,OpenClaw 实际上把球踢给了外部 SDK —— Pi SDK

  • Pi SDK:真正执行 Agent Loop、调用模型、管理工具循环
  • OpenClaw:负责鉴权、文件读写、上下文组装、会话管理、渠道适配
  • 类比:OpenClaw 是包工头,Pi SDK 是施工队;OpenClaw 准备好一切,Pi SDK 负责最终执行
agents/pi-embedded-runner/run/attempt.ts · 核心调用逻辑
// 真正的模型调用在 Pi SDK 中
export async function runEmbeddedAttempt(ctx: AttemptContext) {
  // 1. 准备工作目录和沙箱环境
  const workDir = resolveUserPath(ctx.userPath);
  const sandbox = resolveSandboxContext(ctx.sandboxMode);
  
  // 2. 加载 Skills 和上下文文件
  const skills = loadWorkspaceSkillEntries(workDir);
  const bootstrap = resolveBootstrapContextForRun(...);
  
  // 3. 创建工具集(部分来自 Pi SDK)
  const tools = createOpenClawCodingTools({
    exec, process, apply_patch,  // OpenClaw 自研
    read, write, edit, glob, grep  // 来自 pi-coding-agent
  });
  
  // 4. 构建超长的 system prompt
  const systemPrompt = buildEmbeddedSystemPrompt({
    workDir, tools, skills, bootstrap, ctx.metadata
  });
  
  // 5. 创建 Agent Session(Pi SDK)
  const session = createAgentSession({ model, tools, systemPrompt });
  
  // 6. 流式调用模型(Pi SDK 内部实现)
  const streamFn = session.agent.streamFn;
  const result = await streamFn(effectivePrompt);
  
  // 7. 订阅流式事件
  subscribeEmbeddedPiSession(session, {
    onPartialReply, onBlockReply, onToolCall, onTurnEnd
  });
  
  return result;
}

启示:未来 AI 应用的核心竞争力

这个模式揭示了一个重要趋势:

  • 不在于你会调多少模型 API(这是 commodity)
  • 而在于你能把信息的前后处理做到多极致
  • 上下文工程:如何组装 prompt、管理记忆、调度工具、控制成本
  • 交付机制:如何流式传输、错误恢复、用户体验优化

1.4 四个反共识洞察

洞察一:核心竞争力是上下文工程

大家平时最爱讨论的是:装哪个模型、接哪些 Skill、能不能配十个龙虾专家。但从系统结构看,OpenClaw 真正最值钱的地方,其实是它怎么把用户消息嵌进一个完整运行时:

  • 路由到哪个 agent
  • 关联哪段 session history
  • 加载哪些 tools
  • 拼上哪些 skills
  • 带上哪些 runtime metadata
  • 加入哪些 workspace/context files
  • 遵守哪些 channel rules

也正因为这样,它给人的感觉是更懂你、更懂场景、更理解你的意图,乃至懂得主动行动完成任务。这背后不是说 AI 具备了人的意识,也没到 AGI 时代提前到来那么夸张,而是靠充分的上下文装配实现了一种"智能增值"。

洞察二:OpenClaw 其实是个"二道贩子"

很多人以为 OpenClaw 内部实现了复杂的模型调用逻辑。但看了源码才发现,在最核心的 attempt.ts 里,它其实是把球踢给了外部 SDK —— Pi。

OpenClaw 本身并不生产智能,它更像是一个极其出色的包工头。它负责把脏活累活(鉴权、文件读写、工具调用、上下文管理)都干完了,最后把整理得干干净净的数据喂给 SDK。

洞察三:把提示词写漂亮

很多人谈 Agent,还停留在设定角色、给几个规则,再加一点历史对话的水平。但 OpenClaw 的 system prompt 做的事情,是把工具能力、调用风格、安全边界、Workspace、Sandbox、Docs、Skills、Memory、Reply tags、Voice 等都显式地翻译进 prompt 中。

这个思路很工程化,也很现实。因为大模型不是天然懂你,它只是被喂了一个尽可能完整的世界状态。

🚨 警告:写得越杂,越会带来成本、延迟、注意力稀释和溢出风险。这也是为什么 OpenClaw 设计了大量 history limiting、auto-compaction、context window guard、context pruning 这些"内存管理与垃圾回收"系统。

洞察四:本地消息操作系统

你如果只从用户界面看,会觉得它像一个会聊天、会调用工具的机器人。但从架构看,它更是一个本地优先的消息操作系统:前面接很多渠道,里面有统一控制平面,下面挂 agent runtime、tools、nodes、session store、skills、web UI、CLI、memory。

📝 第 1 章小结

  1. OpenClaw 定位:自托管、多渠道的 AI Agent 网关,单一进程服务所有渠道
  2. 四大原则:本地优先、网关架构、上下文工程、插件扩展
  3. "二道贩子"模式:OpenClaw 准备上下文,Pi SDK 执行模型调用
  4. 四个洞察:上下文工程是核心竞争力、提示词要精简、本质是消息操作系统
  5. Token 消耗:system prompt 注入大量上下文,需警惕成本膨胀

💡 思考题

  • □ 如果您的企业需要构建类似的 Agent 网关,您会借鉴 OpenClaw 的哪些设计?
  • □ 如何在上下文丰富性和 Token 成本之间找到平衡点?
  • □ 如果您要优化 OpenClaw 的 system prompt 构建逻辑,您会从哪些方面入手?
APPENDIX

附录:十大执行步骤全景图与贡献指南

A. 一条消息的十大旅程

🔄 完整执行链路:从用户消息到 AI 回复
Step 1:餐厅开门(Gateway 启动)
auto-reply/monitor.tsmonitorWebChannel() · 建立统一会话、频道、工具、事件分发能力
Step 2:服务员接单(消息接入)
inbound/monitor.ts · 去重合并 → 权限检查 → 媒体下载 → 标准化封装 → 防抖队列
Step 3:领班分单(路由决策)
auto-reply/monitor/on-message.ts · resolveAgentRoute() · 根据 bindings 路由到 Agent
Step 4:帮厨备菜(准备工作)
get-reply.ts · 确认 Agent → 准备 workspace → 理解媒体 → 加载历史 → 解析指令
Step 5:主厨调火(模型配置)
get-reply-run.ts · runPreparedReply() · 整理模型配置 → 处理特殊指令 → 校验思考等级
Step 6:后厨排队(任务调度)
agent-runner.ts · runReplyAgent() · 队列管理 → 记忆刷新 → 失败重试 → 成本统计
Step 7:主厨就位(执行准备)
agent-runner-execution.ts · runAgentTurnWithFallback() · 注册上下文 → 容错布置 → 路径选择
Step 8:按菜谱下锅(单次调用)
run.ts · runEmbeddedPiAgent() · 确认排队规则 → 补齐模型细节 → 遍历认证配置
Step 9:真正开炒(模型推理)
attempt.ts · runEmbeddedAttempt() · 准备环境 → 加载 Skills → 构建 system prompt → Pi SDK 流式调用
Step 10:传菜上桌(回复送达)
process-message.ts · dispatchReplyWithBufferedBlockDispatcher() · 整理碎片 → 分块发送 → 送达用户

B. 贡献指南

步骤操作命令/链接预计时间
1. Fork 仓库 GitHub 上 Fork 主仓库 github.com/openclaw/openclaw 1 分钟
2. 克隆代码 Clone 到本地并安装依赖 git clone && pnpm install 5 分钟
3. 选择方向 Bug 修复、新功能、文档改进 查看 Issues 列表 10 分钟
4. 创建分支 基于 main 创建 feature 分支 git checkout -b feat/xxx 1 分钟
5. 开发测试 编写代码 + 单元测试 + 手动测试 pnpm test 数小时 - 数天
6. 提交 PR Push 并创建 Pull Request 遵循 PR 模板 30 分钟
7. Code Review 回应 reviewer 意见并修改 GitHub Comments 数小时 - 数天
8. 合并发布 通过 CI 后合并到 main 等待下一个 release 1-7 天

C. 参考资源

  • 官方 GitHub:github.com/openclaw/openclaw(27.8k⭐)
  • 官方文档:docs.openclaw.ai
  • DeepWiki:deepwiki.com/openclaw/openclaw
  • 源码解析文章:woshipm.com/ai/6350530.html
  • Release Notes:github.com/openclaw/openclaw/releases
  • 中文社区:open-claw.org.cn/dev
  • 贡献者论坛:discord.gg/openclaw-dev
  • 安全公告:openclaw.ai/security/advisories