最近有工作需要用到这个东西，姑且研究一下。代码太多，没法一行一行审计，就挑重要的说一说吧。不排除以讹传讹的可能性。
之前写过一篇【RethinkAI】浅思Agent，研究得还是不够深入。
接入层：Channels
配置过OpenClaw的小伙伴可能知道，OpenClaw是允许通过各种即时通讯软件(IM)控制的，也允许本地的TUI/Web UI等方法交互。
假设我们配置好了OpenClaw+某一个IM（比如Telegram或者飞书），那么信息首先通过接入层的这些IM，然后通过各个IM的原生方法，将信息传到本地的Gateway中。比如WhatsApp会使用Baileys Web，Telegram会走grammY。
假设我们配置好了OpenClaw+本地TUI，那么信息就通过WebSocket+JSON的形式传给Gateway。
总而言之，这一步做的事情，就是将各个渠道信息，汇总给Gateway，进行后续处理。
中控层：Gateway
Gateway这一层算是比较重要的一层了，这一层长期运行，负责维护本地OpenClaw和所有Channel之间的连接、管理会话的状态、接收消息、发出任务指令、权限认证管理。
当消息从channel从外部渠道涌入后，Gateway层会：
- 消息识别与Session选择：把消息归入某个会话上下文。
- Agent选择（可选）：常规来说，OpenClaw每个session的运行是串行运行的，如果开启了Multi-agent Routing，那么Gateway还会将信息进行指派，分派给特定的agent进行处理。
- 进入队列（可选）：如果当前的session中，已经在跑了，那么Gateway会判断是否能并发跑，如果不能立即执行，就排队；否则就开始跑。这里的目的是，优先避免多个执行流同时改写同一会话状态。
- 上下文组装：真正运行前，Gateway会把当前的输入和相关的上下文组合起来。
- 开跑！：进入了模型推理和工具执行步骤，也就是实际开始运行了。
- 流式返回结果：Gateway会将结果以流式传输的形式，传递给原渠道。
这个过程中，消息可以有很多，所以，Gateway也会对消息进行排队处理、并发处理。
总而言之，这一步做的事情，就是对信息进行验证、整理并执行。
运行层：Multi-agent Routing与Agent运行层
Agent运行层这里，就比较直观了，我们可以通过观察日志窥见这里运行的细节，下面的日志我做了很大的简化，去除了一些无关痛痒的信息，比如时间戳等：
{"type":"message","message":{"role":"user","content":[{"type":"text","text":"Sender (untrusted metadata):\n```json\n{\n \"label\": \"openclaw-tui\",\n \"id\": \"openclaw-tui\",\n \"name\": \"openclaw-tui\",\n \"username\": \"openclaw-tui\"\n}\n```\n\n[Mon 2026-03-30 13:48 GMT+8] Can you create a directory named boo in my home dir? Create a hello world program in it."}]}}
{"type":"message","message":{"role":"assistant","content":[{"type":"toolCall","id":"functions.exec:0","name":"exec","arguments":{"command":"mkdir -p ~/boo && cat > ~/boo/hello.py << 'EOF'\n#!/usr/bin/env python3\nprint(\"Hello, World!\")\nEOF\nchmod +x ~/boo/hello.py","ask":"on-miss"}}],"api":"openai-completions","provider":"custom-dashscope-aliyuncs-com","model":"kimi-k2.5","stopReason":"toolUse",}}
{"type":"message","message":{"role":"toolResult","toolCallId":"functions.exec:0","toolName":"exec","content":[{"type":"text","text":"(no output)"}],"details":{"status":"completed","exitCode":0,"durationMs":10,"aggregated":"","cwd":"/home/iwakura/.openclaw/workspace"},"isError":false}}
{"type":"message","message":{"role":"assistant","content":[{"type":"text","text":"Done! Created:\n\n- **Directory:** `~/boo/`\n- **File:** `~/boo/hello.py` — a simple Python \"Hello, World!\" program\n\nWant me to run it to verify it works?"}],"api":"openai-completions","provider":"custom-dashscope-aliyuncs-com","model":"kimi-k2.5","stopReason":"stop"}}
{"type":"compaction","summary":"## Goal\n(no goal established - empty conversation)\n\n## Constraints & Preferences\n- (none)\n\n## Progress\n### Done\n- (none)\n\n### In Progress\n- (none)\n\n### Blocked\n- (none)\n\n## Key Decisions\n- (none)\n\n## Next Steps\n1. (awaiting user input to begin conversation)\n\n## Critical Context\n- (none)"}这里我们看到：
- 第一行的JSON是表示传进来的信息，通过Channels层和Gateway层处理得到的部分信息，我们发现，在信息之前，加上了一些元数据。
- 第二行是Agent调用本地工具。
- 第三行是Agent调用工具的结果。
- 第四行是Agent返回的信息。
- 最后一行是compaction，也就是压缩，这是为了尽量规避Context Rot的问题、降低上下文膨胀、保留任务状态等目标，将上下文做结构化摘要，以更短、更稳定的形式保留任务目标、约束、进度和下一步。
这就是Agent Loop的运行流程：信息处理-给出指令-运行指令-返回结果-返回信息。正如我在之前那篇文章中说的那样：
这里我们可以窥探到全貌，工作流程是：需求输入 - 云端模型处理 - 返回内容和指令 - 执行指令 - 根据指令结果判断正误。AI 还是那个 AI，那个接收不定长文本，输出不定长文本的 AI，只是 OpenClaw 对输出的结果进行了处理，提取出了工具，然后在终端执行。
那么Multi-agent Routing又是什么个东西？诸君可以将之理解为一个「按规则选大脑」的东西，同一个OpenClaw可能跟着不同的IM，比如同时接Telegram、飞书、Slack等，这个时候就需要选择，根据不同的IM，选择不同的Agent，从而获得不同的上下文等等。Multi-agent Routing 更像一个路由器：它可以根据消息来源、会话、身份、规则或显式配置，把请求导向不同 agent。按 IM 分流只是其中一种例子。
这里和NLP领域的传统Multi-agent Debate不同，这里没有Debate，更像是一个办事处，根据不同的需求选择进入不同的屋子，每个屋子里只有一个办事人员。当然，这些工作人员通常是不会走Multi-agent Debate那种交叉通信的，除非明确启用这一点。这里可以参见官方文档多智能体路由。
记忆层与Skills
那有读者可能会问了，「哎呀！那么这说的Memory和Skills又是个什么东西呀！」，别急。这两个东西其实没什么特别高大上的东西，它们就是Markdown文件！
Memory顾名思义，就是记忆啦，OpenClaw的记忆存储两类文件：长期记忆和短期记忆，短期记忆通常是以天为单位的，长期记忆就是长期的（不然呢……），记录更加稳定的，对于用户的描述。这些文件可以是AI维护，你也可以自己修改。在OpenClaw中，这些Markdown形式的记忆会被分块，然后存储到一个SQLite数据库中，从而依靠向量化的检索，加速调用。
Skills就是一个Markdown文件，包含了对于任务的描述，其实就是一个精细化的Prompt模板。
后记
到这里，我觉得该讲的都差不多讲了，粗粗地过了一遍，如果想要深入了解，那么就要去深挖OpenClaw的代码，不过那个代码库可是极其庞大。
OpenClaw的具体的架构流程也就是如此：IM/TUI给消息 - Channels层接收传递给Gateway层 - Gateway层将消息给到对应Session的对应Agent - 排队 - 组装上下文 - 调用云端API进行处理 - 运行工具 - 运行结果回传云端 - 给出返回信息 - 压缩上下文 - 将信息回传给IM/TUI。