一、OpenClaw 的核心架构
- 总体形态：以 Gateway 为中心的单控制平面
OpenClaw 的核心不是单纯聊天 UI，而是一个长期运行的 Gateway 守护进程。这个 Gateway 负责接入各种消息渠道、维护会话、承载控制平面，并通过同一个端口同时提供 WebSocket 控制接口、HTTP API、控制 UI 和 hooks。默认绑定在 127.0.0.1:18789，并且默认要求认证。 
你可以把它理解成这样：
消息渠道层
WhatsApp / Telegram / Slack / Discord / Signal / Teams / WebChat 等
→ 进入
Gateway 控制平面
路由、会话、工具调用、事件流、HTTP/WS 接口、UI、hooks
→ 驱动
Agent Runtime
模型推理、上下文拼装、工具执行、记忆读写、会话持久化
→ 再连接
Nodes / 设备能力层
macOS / iOS / Android / headless 节点，提供 camera、canvas、screen、location、system.run 等能力。 
⸻
- Gateway 层
Gateway 是 OpenClaw 的"中枢总线"，官方文档里强调它是单个长期存活进程，负责"routing, control plane, and channel connections"。它维护 provider 连接，暴露 typed WebSocket API，并发出 agent / chat / presence / health / heartbeat / cron 等事件。 
这层的特点是：
• 一个 Host 上通常只有一个 Gateway；
• 它是唯一打开某些关键会话的地方，例如 WhatsApp session；
• CLI、Web UI、桌面端、自动化组件都通过它接入。 
⸻
- Client 层
客户端包括 CLI、Web Admin、macOS app 等。它们各自与 Gateway 建立一个 WS 连接，发请求如 status / send / agent / system-presence，同时订阅事件。也就是说，前端并不直接操作模型和工具，而是通过 Gateway 统一调度。 
⸻
- Node 层
Node 是 OpenClaw 很重要的一层。官方文档说明，macOS / iOS / Android / headless 节点也通过同一个 WS 连接到 Gateway，但会声明 role: node，并暴露设备能力，比如：
• canvas.*
• camera.*
• screen.record
• location.get
甚至在已配对情况下可以执行 system.run。 
这意味着 OpenClaw 不只是"调用第三方 API 的 Agent"，而是一个能调本机/端侧能力的代理系统。
⸻
- Agent Runtime 层
OpenClaw 的 agent runtime 不是孤立的"聊天轮次"，而是以workspace + session 为核心。官方文档提到，默认只有一个 agent workspace 作为工具和上下文的工作目录；首次运行时会注入 AGENTS.md、SOUL.md、TOOLS.md、BOOTSTRAP.md、IDENTITY.md、USER.md 等文件内容到模型上下文。 
这说明它的 agent 运行逻辑，本质上是：
系统设定 + workspace 文件 + 历史会话 + 工具结果 + 附件
一起拼成模型上下文，然后驱动一次 agent run。 
此外，OpenClaw 通过集成 pi SDK，把 AI coding agent 能力嵌入到自己的 messaging gateway 里，而不是外部子进程式调用。官方列出的收益包括：会话生命周期控制、自定义工具注入、按上下文定制 system prompt、会话持久化、认证轮换、模型切换等。 
⸻
- Memory 层
OpenClaw 的 memory 很"本地优先"。官方写得很明确：memory 是 agent workspace 里的纯 Markdown 文件，文件才是 source of truth。默认有两层：
• memory/YYYY-MM-DD.md：按天追加的日志
• MEMORY.md：长期记忆，且只在 main private session 中加载，不进群聊上下文。 
这套设计的优点是可审计、可备份、可人读、可 Git 化；缺点是当规模上来后，检索、结构化召回和隔离性会遇到瓶颈。
⸻
- Automation / Hooks 层
OpenClaw 有 hooks 机制，可以在 session 生命周期中触发扩展逻辑，比如：
• 保存 memory snapshot
• 记录命令审计日志
• 在 session 开始或结束时触发自动化
• 写入 workspace 文件或调用外部 API。 
这说明它已经具备一定"事件驱动平台"的雏形，不只是单点 agent。
⸻
- 安全与远程访问层
官方安全文档反复强调：Gateway 是 loopback-first，远程访问优先建议 SSH tunnel / Tailscale / VPN，不建议直接公网暴露。控制 UI 在非 loopback 部署时还需要显式设置 allowedOrigins。同时，本地 session transcript 会落盘到 ~/.openclaw/agents//sessions/*.jsonl，这意味着磁盘访问权限本身就是重要信任边界。 
另外，OpenClaw 最近还修复过一个本地 WebSocket 相关的高危漏洞，研究者称其可能让恶意网页通过弱密码问题接管本地 agent；公开报道提到修复版本为 2026.2.25 或更高。 
⸻
二、如果你要自己落地 OpenClaw，这个架构图最好这样理解
可以抽象成 6 层：
-
接入层：Telegram / Slack / Discord / WhatsApp / WebChat
-
统一网关层：Gateway（WS + HTTP + UI + Hooks）
-
Agent 编排层：session、prompt、tool routing、model routing
-
能力层：本地工具、browser、canvas、cron、节点能力、外部 API
-
状态层：workspace、memory、session logs、config、pairing store
-
安全与运维层：auth、SSH tunnel/Tailscale、allowlist、审计日志、systemd/launchd。 
⸻
三、哪些架构最需要再次优化
我按"重要程度"排序。
- 最需要优化：Gateway 单点过重
现在 Gateway 同时承担：
• channel connection
• control plane
• WebSocket API
• HTTP API
• UI
• hooks
• agent run 入口
这带来的问题是：职责过于集中，单点压力大，故障域太宽。官方文档本身就显示它是一体化单长期进程。 
优化建议
把它拆成更清晰的逻辑层：
• Gateway Core：只做连接、鉴权、路由、事件分发
• Agent Worker：独立执行模型推理、工具调用
• Tool Runtime：高风险工具单独隔离
• UI/API Service：控制台与外部兼容 API 独立出来
这样会带来三点收益：
一是更容易横向扩展；二是 agent 推理阻塞不会影响渠道接入；三是安全隔离更清楚。
⸻
- 需要优化：Memory 仍偏"文件型"，结构化不足
官方 memory 以 Markdown 为主、workspace 为中心，这对个人助理场景很友好，但对复杂长期运行系统来说，存在几个问题：
• 长期记忆召回不够结构化
• 事实、偏好、任务状态容易混在一起
• 多 agent / 多 workspace 下难做统一索引
• 审计、去重、版本冲突会逐渐复杂。 
优化建议
从"Markdown source of truth"升级为"双层记忆架构"：
• 人类可读层：Markdown / Git 备份继续保留
• 机器可检索层：SQLite / Postgres + 向量索引 + entity graph
也就是：
Markdown 继续做"可编辑、可审阅"的真相源；
结构化数据库做"高性能检索、实体关系、时间线、任务状态"。
这是 OpenClaw 未来做企业版、多用户版、复杂工作流版时最关键的升级点。
⸻
- 需要优化：Node 能力边界太强，安全域要再收紧
官方文档明确提到，已配对节点可以暴露 camera、screen.record、location.get，甚至 system.run 这种远程执行能力。 
这类设计非常强，但风险也大：
• agent 被 prompt injection 后，危险动作半径很大
• 设备节点一旦配对，相当于把本机部分能力开放给 Gateway
• 单一配对信任模型对高价值机器不够细。 
优化建议
把 node capability 改成更细粒度的 capability-based security：
• 每个 node capability 单独授权，不是 node 一次性全信任
• system.run 必须二次批准或 allowlist 命令模板
• camera / screen / location 使用短时 token
• 高危命令改为"审批流 + 沙箱执行 + 审计回放"
如果你准备把 OpenClaw 用在个人电脑助手、自动驱动 Codex、管理邮件/文件，这一层一定要优先加固。
⸻
- 需要优化：多 Agent 隔离还不够"云原生"
官方提到支持 multi-agent routing，但当前核心状态仍大量依赖本地 workspace、session logs、pairing store、单 Gateway 运行模式。 
这意味着它更像"强个人代理系统"，而不是天然适配大规模多租户编排的平台。
优化建议
如果你的目标是"个人助手平台化"或"多个专属助手"：
• 每个 agent 独立 workspace
• 每个 agent 独立 session store
• 每个 agent 独立 memory index
• 高风险 agent 独立 OS user / 容器 / VM
• 通过 message bus 做跨 agent 事件通信
也就是从"多 Agent 路由"升级到"多 Agent 隔离运行"。
⸻
- 需要优化：可观测性还应该更标准化
官方提供了 logs、doctor、status、hooks、command logger，已经不错。 
但如果你真要生产化，仍不够：
• 缺少标准 tracing
• 缺少跨会话的工具调用链路可视化
• 缺少统一 token/成本/延迟/失败率指标
• 缺少 agent decision 的质量分析面板
优化建议
补 4 套观测：
• 业务观测：任务成功率、自动化完成率
• 模型观测：tokens、latency、fallback、tool-call error
• 安全观测：危险动作、审批、失败鉴权、异常来源
• 记忆观测：命中率、写入量、重复率、召回质量
如果没有这层，你后面很难判断"是模型问题、记忆问题、工具问题，还是渠道问题"。
⸻
- 需要优化：上下文拼装与会话压缩机制
官方架构说明里提到 context 包括系统 prompt、history、tool results、workspace files 等。 
这很灵活，但也意味着：
• 上下文会越来越长
• memory 注入和 workspace 注入容易互相污染
• 长链路自动化时成本高、漂移大
优化建议
需要把上下文拆成四类缓冲区：
• 硬规则区：系统策略、权限边界
• 任务区：当前任务目标、计划、状态
• 记忆区：仅召回当前任务需要的长期记忆
• 审计区：工具结果摘要，不直接塞全部原始日志
你可以把这理解为"从文件型上下文"升级成"分层上下文总线"。
⸻
- 需要优化：外部 API 与控制平面权限模型
官方文档里提到 OpenAI-compatible / Responses-compatible HTTP API 和 Gateway 走同一端口，而且一旦通过 Gateway auth，就被视为 trusted operator，并没有独立的 per-user tool boundary。 
风险
这在个人单用户场景下没问题，但扩展到团队或更复杂环境时，权限模型过粗。
优化建议
把权限拆成：
• operator 权限
• app 权限
• skill/tool 权限
• session 权限
• human approval 权限
否则未来一旦接企业邮箱、日历、代码仓库、生产服务器，权限边界会非常危险。
⸻
四、给你的结论
如果你问我一句话结论：
OpenClaw 当前架构适合"个人助手 / 单人高权限代理 / 本地优先自动化"，但如果想走向更稳的生产级平台，最该优先优化的是 4 件事：
第一，拆轻 Gateway；
第二，升级 Memory 为 Markdown + 结构化索引双层体系；
第三，把 Node 高危能力做更细粒度权限隔离；
第四，补上标准化 observability 与多 agent 隔离。
⸻
五、如果按你现在的使用方向，我建议的重构版架构
更适合你"个人电脑助手 + 自动驱动编码/业务流程"的版本可以是：
Channel Adapter 层
Telegram / Discord / WeChat-like / Web
API Gateway 层
鉴权、路由、事件总线、WebSocket
Agent Orchestrator 层
任务编排、模型路由、审批流、计划执行
Worker 层
Coding Worker / Browser Worker / File Worker / Scheduler Worker
Memory 层
Markdown Workspace + Postgres Metadata + Vector Index
Device Layer
Mac Node / Mobile Node / Headless Browser Node
Security Layer
RBAC + capability token + approval + audit + sandbox