OpenClaw 架构深度解析：一个自托管 AI 助手运行时的设计之道

OpenClaw 的走红，让很多人第一次意识到：做一个"能用的 AI 助手"是提示工程问题，而做一个"可信、可维护、能长期陪伴的 AI 助手"，是彻头彻尾的系统工程问题。本文拆解 OpenClaw 的四层架构，从 Gateway 的线路协议到 Agent Loop 的完整生命周期，从 Markdown 记忆系统到插件与安全模型，还原一个生产级 AI Agent 运行时的设计之道。

一、为什么值得拆解 OpenClaw

过去两年，绝大多数"AI 助手"项目的主战场是提示词：怎么让模型扮演好角色、怎么写 system prompt、怎么 few-shot。这类项目把模型能力当成产品的全部，一旦离开聊天窗口就无所作为。

OpenClaw 走的是另一条路。它是一个开源（MIT 协议）、自托管的个人 AI 助手运行时：跑在你自己的硬件上——笔记本、Mac mini、VPS 或云端容器，接入你已经每天都在用的聊天渠道（WhatsApp、Telegram、Discord、Slack、iMessage、Signal 等二十多个），由 OpenClaw 基金会（美国 501(c)(3) 公益组织）维护，无付费层、无订阅、无遥测。

它的三个核心定位，决定了整个架构的走向：

1. 模型负责思考，OpenClaw 负责执行。 官方的说法是把 OpenClaw 定位为"Agent 的操作系统"——模型（Claude、GPT、Gemini、本地模型均可插拔）提供智能，OpenClaw 提供执行环境：会话管理、工具调用、记忆、设备控制、安全边界。
2. 本地优先（Local-first）。 状态、记忆、凭据全部保存在你自己的机器上，唯一出网的数据是模型 API 调用。这从根本上改变了信任模型：你不需要把生活交给第三方 SaaS。
3. 接口层与运行时解耦。 WhatsApp、Telegram、macOS 应用、Web UI 都只是"界面"，背后共享同一个 Gateway 与 Agent 运行时。换一个聊天渠道，Agent 的记忆与能力完全不变。

安装门槛也很低：Node.js 环境，一条 openclaw onboard 命令完成引导（含守护进程安装）。但真正值得技术工程师细看的，是它支撑这些能力的架构。我们从全景图开始。

二、架构总览：四层设计

OpenClaw 的整体架构可以概括为四层：控制平面 → Gateway 网关 → Agent 运行时 → 设备节点。

┌─────────────────────────────────────────────────────┐
│                    Control Plane                     │
│            （配置 · 鉴权 · 设备配对 · 审计）            │
└──────────────────────────┬──────────────────────────┘
                           │ token / 配对审批
┌──────────────────────────▼──────────────────────────┐
│              Gateway（单进程 Node.js 守护进程）        │
│         WebSocket 枢纽 · 默认 127.0.0.1:18789        │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐    │
│  │ Channel 插件 │ │ Provider 插件│ │ Memory 插件  │    │
│  │ WA/TG/Discord│ │ Claude/GPT..│ │ SQLite/QMD..│    │
│  └─────────────┘ └─────────────┘ └─────────────┘    │
└──────────────────────────┬──────────────────────────┘
                           │ 内部 API（同进程调用）
┌──────────────────────────▼──────────────────────────┐
│                  Agent Runtime                       │
│     会话队列 · 上下文组装 · Agent Loop · 记忆系统       │
└──────────────────────────┬──────────────────────────┘
                           │ WebSocket（role: node）
┌──────────────────────────▼──────────────────────────┐
│                    Nodes 设备节点                     │
│      macOS · iOS · Android · 无头设备                │
│   camera.* │ screen.record │ location.get │ canvas.* │
└─────────────────────────────────────────────────────┘

四个角色的分工非常清晰：

• 控制平面：不参与消息流转，负责配置、鉴权模式、设备配对审批与审计账本；
• Gateway：一台主机只有一个 Gateway 守护进程，是所有消息通道与所有 WS 连接（客户端、节点）的中央枢纽，也是唯一允许打开 WhatsApp 会话（Baileys）的地方；
• Agent Runtime：大脑，负责会话队列、上下文组装、Agent Loop 执行与记忆；
• Nodes：你的物理设备（手机、电脑）以 role: node 接入同一个 WS 服务器，向 AI 暴露摄像头、屏幕录制、GPS、画布等设备能力。

一条消息的旅程是这样的：你在 Telegram 里发一句"帮我把今天的日程排一下"→ 对应 Channel 插件完成鉴权与入站归一化，交给 Gateway → Gateway 通过 agent RPC 把请求送入该会话的 Agent Runtime → Agent Loop 组装上下文（人格文件 + 记忆 + 会话历史 + 技能）调用模型，模型决定调用日历工具、读取你 iPhone 的位置（经 Gateway 下发命令给 Node）→ 结果流式回传 → Channel 插件按平台方言（Markdown 方言、长度拆分、媒体上传）格式化后回复你。

整个过程里，Gateway 是唯一有副作用的持久进程，Agent Runtime 的每次执行都是无状态的函数式调用（状态外置到会话存储与记忆文件）。这个"有状态的网关 + 无状态的执行"分离，是理解 OpenClaw 所有设计决策的钥匙。

三、Gateway：单进程控制平面

看架构图的第一反应可能是疑问：都 2026 年了，为什么 Gateway 是单进程？不搞微服务拆分？

这是 OpenClaw 最明确的一个设计取舍：面向个人场景，消息量撑不起微服务，而拆分带来的部署复杂度、跨进程状态一致性成本远大于收益。单进程换来三样东西：零开销的内部调用、一条命令的部署、天然的状态一致性。至于水平扩展——单机单用户场景下，它不是问题。

单进程不等于简单。Gateway 承担着所有"脏活"：协议解析、鉴权配对、插件生命周期、事件广播。

3.1 WebSocket 线路协议

所有客户端（macOS 应用、CLI、Web UI、自动化脚本）与所有节点，都连到 Gateway 同一个 WS 端口（默认 127.0.0.1:18789）。协议是 JSON 文本帧，三种帧覆盖全部交互：

// 第一帧必须是 connect（否则直接断开）
{ "type": "connect", "id": "c1", "params": { "auth": { "token": "..." }, "role": "node" } }

// 握手成功后，请求-响应
{ "type": "req",  "id": "abc123", "method": "send", "params": { "...": "..." } }
{ "type": "res",  "id": "abc123", "ok": true, "payload": { "runId": "r1" } }

// 服务端单向推送事件
{ "type": "event", "event": "agent", "payload": { "...": "..." }, "seq": 42 }

几个容易忽略但很见功力的协议细节：

• 入站帧按 JSON Schema 校验。协议 schema 用 TypeBox 定义，JSON Schema 和 Swift 客户端模型都从同一份 schema 生成——一处定义，多端一致，这是消除"协议文档与实现不一致"这类顽疾的标准做法。
• 副作用方法必须带幂等键。send、agent 这类有副作用的方法，服务端维护短期去重缓存，客户端重试不会造成重复发消息或重复跑 Agent。
• 事件不重放。Gateway 不为客户端保存事件历史，出现缺口（掉线、漏包）时客户端必须主动刷新快照。把"投递可靠性"的复杂度推给客户端，服务端保持简单——对单用户场景是正确的取舍。
• hello-ok 握手响应携带 features.methods / events，作为设备能力发现元数据，供客户端按能力裁剪 UI。

3.2 设备配对：信任的建立过程

安全模型是 OpenClaw 的重点（第七章展开），Gateway 的配对机制值得单独一看。所有 WS 连接都在 connect 帧中携带设备身份，新设备必须走配对审批：

1. 节点发起连接，Gateway 返回 challenge nonce，节点用本地密钥签名应答（v3 签名还绑定 platform 与 deviceFamily，元数据变更需重新配对）；
2. 用户在受信任的设备上确认（openclaw devices approve 或消息内 /approve）；
3. Gateway 签发长期设备令牌，后续连接免重复配对。

本机 loopback 连接可自动批准（保证本机体验顺滑），而 Tailnet、局域网等非本地连接一律需要显式审批——"物理就近"不等于"信任"。Gateway 自身的鉴权模式（token / password / Tailscale 身份 / trusted-proxy / none）独立于设备配对，对所有连接生效。

远程访问的首选是 Tailscale（身份随连接携带），SSH 隧道是零依赖的替代方案：

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

3.3 两条架构不变量

官方文档明确写了两条不变量，比任何功能列表都更能说明 Gateway 的设计意图：

• 每台主机只有一个 Gateway，且它是唯一打开 WhatsApp/Baileys 会话的地方。这是有意的单点：聊天会话凭证只在一处出现，攻击面与状态一致性问题同时收敛。
• 必须握手。首帧不是 JSON 或不是 connect，连接直接关闭——协议状态机保持简单，不给歧义空间。

此外，画布（Canvas）的静态资源由 Gateway 的 HTTP 服务器托管在 /__openclaw__/canvas/ 与 /__openclaw__/a2ui/ 路径下，与 WS 同端口——单进程的极端体现：一个端口，协议、界面、画布全托管。

四、Agent Loop：一次运行的完整生命周期

如果说 Gateway 是骨架，Agent Loop 就是心跳。每次你发消息触发 Agent 执行，背后是一条完整且严谨的生命周期。

4.1 运行顺序：从 RPC 到事件桥接

一次 Agent 运行的时序：

1. 入口：WebChat/UI 走 Gateway 的 agent RPC（同步等待用 agent.wait），命令行走 openclaw agent；
2. 参数校验与会话解析：确定目标会话，持久化运行元数据；
3. 快速确认：请求立即返回 {runId, status: "accepted"}——不阻塞，真正的执行在后台队列里排队；
4. runEmbeddedAgent 执行轮次：进入按会话隔离的执行队列，与全局队列协作，串行执行；
5. 事件桥接：执行过程中的 assistant 流式增量、工具调用进度（start/update/end）、最终结果，全部以 agent 事件回传给客户端。

注意第 4 步的关键词：串行。OpenClaw 不并发执行同一个会话的多轮 Agent 请求——这不是性能疏忽，而是正确性设计（下述写入锁）。多轮请求通过四种队列模式协调：

模式	行为	典型场景
steer	新请求注入当前运行，实时转向	你在 Agent 干活时补充指令
followup	当前运行结束后立即接续	排队追问
collect	收集新输入，择机合并	攒多条消息一次性处理
interrupt	打断当前运行，立即处理	紧急指令

4.2 会话写入锁

与串行队列配套的是会话写入锁：进程感知、文件实现（跨进程安全）、默认 60 秒等待、默认不可重入。作用是保证任意时刻一个会话文件只有一个写入者，彻底避免"两个运行交叉写会话历史"导致的上下文损坏。官方文档甚至专门写了卡住会话的诊断机制：session.long_running / session.stalled / session.stuck 三档事件，2 分钟未响应触发警告，超过 5 分钟且 3 倍警告时间才允许中止——对"锁到底会不会把系统卡死"这个问题，给出了完整的运维答案。

4.3 上下文组装：五源合成

每次调用模型前，Agent Runtime 都要组装上下文。OpenClaw 的公式是"基础提示词 + Skills 提示词 + 引导上下文 + 每轮覆盖"，落到文件系统上是三个约定文件：

• AGENTS.md——行为基线（必需）：Agent 是谁、边界在哪；
• SOUL.md——人格与语气（可选）：比行为基线更"灵魂"的设定；
• TOOLS.md——工具使用约定（可选）：什么时候该用什么工具。

再加上三类动态来源：Skills 库（skills/<name>/SKILL.md，结构化的 SOP）、会话历史（持久化 JSON，含上下文窗口裁剪）、记忆检索（语义搜索命中注入，第五章展开）。组装时还按模型上下文窗口计算 token 预算，为压缩保留预留空间。

这套设计的精髓在于：每轮对话都是一次完整的"世界观重建"——Agent 每次醒来都知道自己是谁（SOUL.md）、你是谁（USER.md）、之前发生了什么（记忆与会话）、手边有什么工具。没有内置的隐藏状态，一切上下文都是显式文件，可审计、可版本控制。

4.4 Hooks 体系：全生命周期的可编程性

OpenClaw 把扩展点做成了贯穿 Agent Loop 的钩子体系。内部钩子（Gateway 侧）处理引导注入（agent:bootstrap）与命令路由；插件钩子覆盖了完整生命周期：

before_model_resolve → before_prompt_build → [模型调用] → before_agent_reply
→ before_tool_call → after_tool_call → tool_result_persist
→ before_compaction → after_compaction → agent_end

外加消息与会话侧的 message_received / message_sending / message_sent / session_start / session_end，以及 Gateway 生命周期的 gateway_start / gateway_stop。想在"发消息前做敏感词过滤"？挂 message_sending。想自定义工具执行的沙箱策略？挂 before_tool_call。这层设计让 Agent Loop 保持核心简洁的同时，把几乎所有的行为定制都外置到钩子。

4.5 超时矩阵：面向运维的设计

这里特别值得称道的是：OpenClaw 把"Agent 卡住了怎么办"当成一等公民来设计，超时参数全部显式：

参数	默认值	说明
agent.wait RPC	30s	同步等待接口的超时，超时后客户端改订阅事件
Agent 运行时上限	172800s（48h）	单次运行的最长执行时间（长任务场景）
模型空闲超时	云端 API 120s / 自托管 300s	流中断判定，触发重试
卡住诊断	2min 警告 / ≥5min+3× 才可中止	session.stuck 事件与恢复策略

配合流式重试（压缩后记忆缓冲区重置）、NO_REPLY 过滤器（模型决定"这条消息不用回"）、消息去重（避免工具回复与正文重复）——这些细节共同构成了"一次运行"从请求到回复的完整闭环。

五、记忆系统：Markdown 即数据库

OpenClaw 最"叛逆"的设计决策，是记忆存储：不用 SQLite 做主存储、不用 Redis、不用专用向量库（默认），就用纯 Markdown 文件。

5.1 双层记忆

工作区（~/.openclaw/workspace）里有两层记忆：

• 长期层 MEMORY.md：用户偏好、关键决策、持久知识。每次会话启动即全文注入上下文——相当于 Agent 的"核心价值观"，总是可见；
• 工作层 memory/YYYY-MM-DD.md：每日笔记，按日期分文件。不默认加载，而是被 memory_search / memory_get 按需索引检索——相当于"日记档案"，查了才有。

~/.openclaw/workspace/
├── MEMORY.md              # 长期记忆（每次会话注入）
├── memory/
│   ├── 2026-09-08.md      # 每日记忆（按需检索）
│   └── 2026-09-09.md
└── DREAMS.md              # 可选：梦境日志（人工审阅用）

为什么是 Markdown？四个理由：人类可读可改（你随时能直接编辑 Agent 的记忆）；Git 可版本控制（每一条记忆变更都有 diff）；零依赖可移植（复制目录就是迁移）；对模型天然友好（LLM 处理 Markdown 的效果远好于任意 schema 的行）。社区文章把它叫"Markdown 即数据库"，本质上是把"可解释性"放在了"查询性能"前面——对个人助手的记忆写入频率，这个取舍完全成立。

5.2 混合检索与可插拔后端

纯文本多了，光靠 grep 不够。OpenClaw 的 memory_search 是混合检索：向量相似度 + 关键词匹配双通道，融合排序后把最相关的记忆片段注入上下文。

存储后端本身是可插拔的（Memory 插件槽位，第六章展开）：

• memory-core：默认实现，SQLite 落盘向量索引；
• QMD、Honcho、LanceDB：第三方后端插件；
• memory-wiki：知识层插件，面向结构化知识。

常用运维命令：openclaw memory status（索引健康）、openclaw memory search <关键词>（手动检索）、openclaw memory index（重建索引）。还支持从 Codex、Claude Code 等工具导入既有记忆。

5.3 Memory Flush：压缩前的"睡前复盘"

这是 Agent Loop 与记忆系统的衔接点，也是最精巧的设计之一：在上下文压缩（compaction）发生之前，运行时插入一个静默轮次，提醒 Agent："上下文即将压缩，请先把重要内容存下来。"Agent 于是把关键信息、未完成事项写入 memory/YYYY-MM-DD.md，必要时更新 MEMORY.md——然后才允许压缩执行。

这个动作像极了人睡前把今天的重要事情"归档"到长期记忆。没有它，压缩就是一次有损的上下文截断；有了它，压缩变成一次"先备份再清空"的安全操作。Flush 甚至支持配置独立的小模型（如 ollama/qwen3:8b）来做这件事——归档不需要最聪明的模型，这又是一处成本意识。

5.4 Dreaming：后台记忆整合

更激进的实验性特性是 Dreaming：空闲时段的后台任务，对记忆做评分与整合——旧笔记的合并、矛盾记忆的消解、高频命中的内容向长期层晋升。评分门槛考虑分数、召回频率、查询多样性；整合建议写入 DREAMS.md 供人工审阅，而不是直接改写记忆。配套 rem-backfill CLI 可对历史记忆回填索引。

从 MEMORY.md 到每日笔记，从 Flush 到 Dreaming，OpenClaw 把"AI 助手如何记住你"这件事做成了一条完整的数据管线——而这整条管线的存储介质，只是几个 Markdown 文件。

六、插件体系：四个扩展槽位

OpenClaw 的可扩展性建立在四个扩展槽位上，每个槽位是一类能力的接口约定：

槽位	职责	典型实现
Channel	消息进出：鉴权、入站归一化、出站格式化	WhatsApp、Telegram、Discord、iMessage、Signal
Provider	模型接入：统一推理接口	Claude、GPT、Gemini、Mistral、本地模型
Memory	记忆存取：存储与检索语义	memory-core（SQLite）、QMD、LanceDB
Tool	能力扩展：Agent 可调用的工具	Shell、浏览器自动化、文件、搜索、摄像头

这个分类的好处是正交：换模型不动渠道，换记忆后端不动工具，任何一层都可以独立替换。模型与 Agent harness（Claude、Codex、本地模型）本身也是可换的插件——"模型即插件"让 OpenClaw 不与任何一家模型厂商绑定。

6.1 发现式加载

插件安装是发现式的：Loader 扫描工作区与 extensions 目录下的包，读取 package.json 中的 openclaw.extensions 字段定位入口，做 schema 校验后热加载：

{
  "name": "openclaw-plugin-weather",
  "version": "0.1.0",
  "openclaw": {
    "extensions": ["./src/index.ts"]
  }
}

入口文件里向运行时注册能力（以 Tool 为例，示意代码）：

export default function register(api: OpenClawAPI) {
  api.registerTool({
    name: "weather_lookup",
    description: "查询城市当前天气",
    parameters: { city: "string" },
    async execute({ city }) {
      const res = await fetch(`https://wttr.in/${city}?format=j1`);
      return { current: (await res.json()).current_condition[0] };
    },
  });
}

生态层面，ClawHub 作为插件共享市场（免费开源），社区已经有大量现成的 Channel/Tool 插件可直接安装。与前文呼应的是：插件解决"能力"，Skills 解决"程序性知识"——SKILL.md 是纯 Markdown 的工作流指令，随上下文注入；插件是真正的代码，随运行时加载。两者互补，共同构成扩展体系。

七、安全模型：可信网关 × 不可信执行

个人 AI 助手的安全难题在于：它要接入你所有的聊天渠道、读你的文件、控制你的设备——权限越大，越不能天真。OpenClaw 的安全模型可以用官方的一句话概括：可信网关，不可信执行，确定性策略（Trusted gateway, untrusted execution, deterministic policy）。

7.1 入站：一切消息都不可信

从聊天渠道进来的每一条消息，默认都是不可信输入。通道层是第一道防线：

• 鉴权：各渠道各自的方式——Baileys（WhatsApp）用 QR 扫码配对，Telegram 用 TG_BOT_TOKEN，Discord 用 DISCORD_BOT_TOKEN，iMessage 直接复用 macOS 原生登录态；
• 白名单：allowFrom 列表精确控制谁能触发 Agent；
• DM 策略：paired（默认，先配对后对话）/ open / disabled 三档，配对审批走 openclaw pairing approve <channel> <code>；
• 群组策略：requireMention——群聊里必须 @机器人才响应，防止 Agent 被群消息淹没或被陌生人诱导。

7.2 执行：工具调用的分级管控

消息可信不代表 Agent 的每个动作都可信。工具执行层面：

• exec 审批：Shell 命令逐条审批，Agent 想执行新命令需要你确认——相当于手机上的权限弹窗；
• 沙箱：主会话的工具默认在宿主机执行，OpenClaw 支持为 Agent 配置沙箱模式（不同 Agent 实例可以有不同信任级别）；
• 网关鉴权：gateway.auth 独立于配对，对所有 WS 连接生效；none 模式仅限本机 loopback，任何公网/局域网入口都强制要求显式鉴权模式。

7.3 审计：出了问题能查到哪一步

审计账本（Audit Ledger）有个很聪明的细节：容量受限、只记元数据。日志不复制提示词、消息正文与工具参数（敏感信息不落第二份盘），只记录"谁在什么时候触发了什么操作"的投影。容量滚动淘汰，隐私与可追溯性兼顾。

为什么强调"确定性策略"？因为提示词注入是 AI 助手的第一攻击面——模型可能被诱导，但 allowFrom 列表、配对审批、exec 确认这些控制点是代码里的 if 判断，不依赖模型"自觉"。把安全边界从提示词层移到系统层，这是 OpenClaw 安全模型最有借鉴价值的决策。

八、多代理路由与 Agent 协作

OpenClaw 支持一台 Gateway 上运行多个相互隔离的 Agent 实例，通过 agents.mapping 把不同渠道/会话路由到不同实例：

{
  "agents": {
    "mapping": {
      "group:discord:123456789": {
        "workspace": "~/openclaw/clawd",
        "model": "anthropic/claude-opus-4.5",
        "systemPromptOverrides": "在群聊中保持简洁直接。",
        "identity": { "name": "Clawd", "emoji": "🦞" }
      },
      "dm:telegram:*": {
        "workspace": "~/openclaw/work",
        "memorySearch": { "enabled": true },
        "sandbox": { "mode": "all" }
      }
    }
  }
}

每个实例有独立的 workspace、模型、人格、记忆、工具集与沙箱策略——工作 Agent 和私人 Agent 可以跑在同一台机器上互不污染。官方示例里就有"私聊走全沙箱 + 工作记忆"的配置思路。

跨 Agent 协作则通过 sessions_* 工具族：sessions_list（列出会话）、sessions_send（向另一个会话投递消息，支持静默委托模式）、sessions_history（读取会话历史）、sessions_spawn（派生新会话）。一个 Agent 可以把子任务委托给另一个 Agent 的会话，拿到结果再汇总——多 Agent 协作的最小闭环。

Canvas 与 A2UI：给 Agent 一块"画布"

Agent 的输出不止文本。Canvas 是 Gateway 托管的、Agent 可编程编辑的渲染面，A2UI（Agent-to-UI）则更进一步：Agent 直接输出带 a2ui-* 属性的 HTML 片段，Canvas 解析属性声明、推送到浏览器渲染，用户的交互事件再回流为工具调用：

<button a2ui-action="confirm_order"
        a2ui-params='{"orderId": "A1024"}'>
  确认下单
</button>

用户点击 → Canvas 把 confirm_order 事件转成 Agent 工具调用 → Agent 更新状态 → Canvas 增量重渲染。这就是"生成式 UI"的最小实现：Agent 不用学会画整个界面，只需要声明式地描述交互意图，渲染与事件绑定交给 Canvas 运行时。

再加上两个自动化触发器——Cron（时间驱动，定时任务）与 Webhooks（事件驱动，外部系统回调）——OpenClaw 就不只是"你问它答"的聊天机器人，而是一个可以主动运行、被外部事件唤醒、还能用可视化界面与人交互的常驻运行时。

九、设计取舍与启示

把前八章串起来，OpenClaw 的三个"反直觉"决策其实指向同一套哲学：

决策	反直觉之处	背后的取舍
单进程 Gateway	2026 年不搞微服务	个人场景无水平扩展需求；换零部署成本与状态一致性
Markdown 记忆	不用数据库/向量库	牺牲查询性能，换可读性、可版本控制、可解释性
事件不重放	服务端不保证投递	把可靠性复杂度推给客户端刷新，服务端保持极简

它们共同的原则是：为一个人服务，为一个人优化。企业 SaaS 的每一分"健壮性"（多副本、强投递、分布式存储）在单用户场景下都是纯粹的复杂度税。OpenClaw 敢于砍掉这些，才换来了一条命令的部署和全程可审计的透明性。

对想自建 Agent 系统的工程师，我认为有四条最值得抄的作业：

1. 有状态的网关 + 无状态的执行。会话状态外置（会话文件、记忆文件），Agent 执行本身是纯函数式的——这让重试、压缩、多实例都变简单。
2. 串行是特性不是缺陷。按会话串行 + 写入锁，用"慢一点"换上下文一致性，配合队列模式（steer/followup/collect/interrupt）覆盖所有交互意图。
3. 上下文全显式。人格是文件（SOUL.md）、行为是文件（AGENTS.md）、记忆是文件——每轮组装都是可审计的"世界观重建"，没有任何隐藏状态。
4. 安全靠确定性策略，不靠提示词自觉。配对、白名单、exec 审批、沙箱，全是代码层控制点；提示词只负责体验，不负责安全。

十、结语

OpenClaw 用四层架构回答了一个越来越重要的问题：当模型能力趋同、价格趋降之后，AI 助手产品的护城河在哪里？它的答案是——在运行时。会话管理、记忆管线、设备接入、安全边界、插件生态，这些"模型之外"的系统工程，才是把大模型变成"你的"助手的真正门槛。

如果你只想亲手验证一遍文中的架构，最小路径是：装好 Node 22+ → openclaw onboard（含守护进程安装）→ openclaw gateway status 看健康 → 接一个 Telegram Bot 试试消息旅程。完整文档见 docs.openclaw.ai。

---

参考资料

1. OpenClaw 官方文档：Gateway 架构
2. OpenClaw 官方文档：Agent Loop
3. OpenClaw 官方文档：Memory System
4. OpenClaw 官方文档：Gateway 协议 / 安全 / 多代理路由 / 自动化
5. GitHub：openclaw/openclaw
6. dev.to：OpenClaw Architecture — The Four-Layer Design Philosophy Behind an AI Assistant Runtime
7. 博客园：OpenClaw 深度解析：从架构设计到技术实现
8. 知乎：万字图文详聊 OpenClaw
9. AtomGit：OpenClaw 技术白皮书
10. OpenClaw 学习实践系列（数据获取/中间层/算力调度）

注：本文基于 2026 年 9 月时点的 OpenClaw 版本撰写。项目迭代较快（如记忆后端、Canvas 端口等细节在社区资料与官方文档间存在版本差异），请以官方文档为准。