Community Guide

OpenClaw 技术架构

用普通语言梳理 OpenClaw 的 Gateway、workspace、session、记忆、nodes 以及背后的运维取舍。

2026/03/13

一句话理解架构

OpenClaw 的核心，是一个常驻运行的 Gateway 控制平面，它协调渠道、session、工具和 nodes，而真正的 assistant 状态则保存在你自己可控的 workspace 里。

官方 README 对这一点说得很明确：Gateway 是 control plane，而 assistant 的真实体验跨越了渠道、工具、设备节点和浏览器界面。

所以 OpenClaw 不像一个“聊天壳”。Gateway 不只是转发消息，它还负责：

如果 Gateway 状态不健康，整套系统看起来都会不健康。

最务实的理解方式是：

这种拆法的价值在于：OpenClaw 可以长期运行，而不必把一切都塞进一个终端进程里。

OpenClaw 很重要的一点，是它把 assistant 状态尽量保持在可读文件里。

workspace 里常见的文件包括：

这不是偶然实现，而是架构本身。OpenClaw 把持久状态放在你能读、能管、能排查的地方。

OpenClaw 的 session 不只是“当前聊到哪里了”。它决定的是上下文、权限和隔离方式。

它会影响：

所以群聊和私聊不应该被期待成同一种记忆体验。

官方 memory 文档把这件事讲得比很多社区解释更清楚。

关键点是：

长期记忆保存在 workspace 的 Markdown 文件里
MEMORY.md 是整理后的长期层，偏向私聊主 session
memory/YYYY-MM-DD.md 是每天的运行记忆
recall 通过 memory_search 和 memory_get 完成
在 session 接近 compaction 时，OpenClaw 还能触发一次 pre-compaction memory flush，提醒 agent 先把值得留的内容写下来

这意味着“token 压力”和“记忆质量”有关系，但并不是同一个问题。

很多人会把问题粗暴理解成“上下文太长了”。更准确的说法是：

所以如果你忽略持久记忆这一步，token 可能越来越高，但 recall 仍然感觉很差。

Gateway 协调的几个外部层不应该被混为一谈：

这种拆法的价值在于：跑 Gateway 的机器，不一定就是拿着设备或浏览器的那台机器。

OpenClaw 的网络默认值是保守设计，不是巧合：

这也是为什么官方文档一直在提醒：不要随意把裸 Gateway 直接暴露到公网。

架构不是给工程师炫耀的。它决定了：

知道这些，和“只是装上了”之间，是有本质区别的。