Agent4S｜OpenClaw 的运行过程是什么

拆解OpenClaw从消息接入、会话分配到上下文组装和工具执行的过程，解释记忆、技能、工具及MCP在运行链路中的作用。

> 作者：王洋　·　[阅读微信原文 ↗](https://mp.weixin.qq.com/s?__biz=MzkyNjY0NjI3NA==&mid=2247485794&idx=1&sn=02b63c97671037dc18e365f22e0b27bc&chksm=c235600ff542e9194f4ea6e9ae77edde42106702688accc884cce8b0b2183250c3e4a1a83d04#rd)

# Agent4S｜智能体框架举例：OpenClaw 的运行过程是什么

内容摘要

1、OpenClaw 的运行是消息接入、会话归属、上下文装配和执行循环共同组成的系统过程。

2、模型调用之前，system prompt、workspace 文件、memory、tools、skills 元数据、历史和附件会被组织成一整包上下文。

3、模型判断之后，任务会通过读取 skill、调用 tool、结果回写和 MCP 连接继续推进。

全文约 3795 字，阅读时间约 8 分钟。

OpenClaw 文章封面

当用户给 OpenClaw 发送一条新的消息，如“把会议录音整理成纪要并发给团队”这个任务之后，会发生什么？

## 一条消息进入 OpenClaw 之后会先经过哪些环节

官方文档把 OpenClaw 定义为一个自托管 Gateway，它连接 WhatsApp、Telegram、Discord、iMessage 等聊天应用，也把会话、工具和多智能体路由放进同一套系统里。[1] 当一条消息进入 OpenClaw 之后，Gateway 先解决的是：这条消息从哪里来、属于哪条会话、该由谁处理，这一段外层链路。[2]

消息进入之后，不会立刻送进模型。系统会先把它归到某个 session。session 可以理解为这条消息所属的会话作用域。它决定这条新消息应该接在哪段历史后面，也决定系统接下来要读取哪一组上下文。没有 session，系统就只能把每条消息当成孤立输入处理；有了 session，系统才能把多轮历史、附件、工具结果和先前状态接到同一条任务链上。[3]

在 session 之后，系统还要确认由哪个 agent 来处理消息。agent 不是一句提示词，也不是单纯的“角色设定”，而是一个完整执行单元。它有自己的 workspace，也带着 AGENTS.md、SOUL.md、USER.md、状态目录和 session store 这些内容。消息一旦分配给某个 agent，后续的上下文组织、模型调用、工具使用和结果返回，就都围绕这个执行主体展开。[4]

workspace 也在这一阶段进入流程。它不是一个普通文件夹，而是 agent 的工作区。系统在这里放置规则文件、身份设定、长期记忆、日常记录和运行时状态。消息归到某个 agent，本质上也意味着系统已经确定了接下来要用哪个工作区来处理任务。[5]

把这一段链路压缩起来看，OpenClaw 在处理一条消息时，先做的是四件事：先由 Gateway 接收消息，再用 session 确定会话归属，然后确认由哪个 agent 处理消息，最后进入对应的 workspace。这里也正好可以带出三个基础概念：Gateway 是入口层，session 是会话作用域，agent 是执行主体。OpenClaw 的第一步不是“让模型回答”，而是先把消息放到正确的执行位置上。

图1：OpenClaw 从聊天入口到回复输出的运行链路

## OpenClaw 在调用模型之前会怎样组织上下文

当消息完成接入、归属和分配之后，OpenClaw 才进入模型调用阶段。但即便到了这一步，系统也不会把“用户刚发来的那句话”单独交给模型。OpenClaw 在调用模型之前，会先把一整包上下文组织出来。用户输入只是起点，不是全部 prompt。[6]

模型真正看到的内容，首先包括系统提示。OpenClaw 会在每次运行时组装系统提示，把当前可用的工具列表、skills 列表元数据、时间和运行时信息，以及 workspace 中的一组关键文件一起放进去。这些文件通常包括 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、BOOTSTRAP.md 和 MEMORY.md。它们分别承担不同作用：有的定义 agent 的规则和职责，有的定义表达风格和行为边界，有的描述身份、工具和初始化信息。模型看到的不是一句“请你扮演某某角色”，而是一套完整规则。[7]

用户输入之外，memory 也会进入上下文。这里需要特别区分 memory 和 context。context 指的是本次调用时一并送入模型的整包内容；memory 则是其中一类更长期、可复用的信息来源。OpenClaw 把 MEMORY.md 作为长期记忆，把 memory/YYYY-MM-DD.md 作为日常记录。系统在每个私聊 session 开始时会加载 MEMORY.md，也会自动加载今天和昨天的 daily notes。换句话说，memory 不是临时对话历史，而是系统主动保留下来的持续性信息。[8]

tools 也不是“模型自己知道怎么用”的模糊概念。OpenClaw 会把 tools 以结构化函数定义的形式发给模型 API。这样一来，模型知道的就不只是“可以说什么”，还包括“当前有哪些动作可以调用、这些动作分别需要什么参数、返回什么结果”。工具进入上下文之后，模型的输出空间就从文本扩展到了动作。[9]

skills 的位置更值得单独解释。OpenClaw 不会在一开始就把所有 skill 的完整说明全部塞进系统提示，而是先放入 skills 的元数据。系统先告诉模型当前有哪些 skill 可用、各自大概适合处理什么任务；只有在模型判断某个任务需要某种固定做法时，才会按需读取对应的 SKILL.md。官方文档里一处强调，skills 通过 SKILL.md 为 agent 提供 how 和 when；另一处又说明，系统提示默认只放 skills metadata，完整 instructions 按需加载。正因为这样，skill 看起来像 prompt，但它并不等于 prompt。它更像一份方法说明书，解决的是“这类任务通常怎么做”，而不是直接代替执行主体。[10]

历史消息和附件也会一起进入上下文。session 决定了当前这条消息要接到哪段历史后面，附件和工具结果也会成为后续判断的一部分。模型真正看到的输入，因此不是“用户刚发来的这句话”，而是用户输入、系统规则、工作区文件、长期记忆、工具定义、技能索引、历史消息和附件一起组成的一整包上下文。

放在 OpenClaw 里看，prompt 这个词的边界已经明显扩大了。prompt 不再只是用户发来的那一句话，而是用户输入、系统提示、记忆、工具定义、技能元数据和历史结果一起构成的整包输入。理解了这一点，才会知道智能体系统里的模型判断，为什么总是建立在“上下文工程”之上，而不是建立在一句孤立提问之上。

图2：OpenClaw 的上下文组装与执行循环

## OpenClaw 在模型给出判断之后会怎样继续执行任务

当 OpenClaw 把上下文交给模型之后，模型首先要做的，不是立刻生成最终回复，而是先判断下一步该怎么推进任务。任务很简单时，模型可以直接回复；任务一旦需要外部动作，系统就会进入下一步执行。[11]

第一种情况是直接回复。如果用户的问题很简单，只需要基于现有上下文给出说明、解释或判断，模型就可以直接生成答案，由系统返回给用户。这一类流程最接近普通聊天程序，但它只是 OpenClaw 能力中的最简单情况。

第二种情况是读取 skill。当模型判断当前任务需要某种固定做法，例如会议纪要整理、信息核对、格式化输出或某类标准流程，它就会去读取对应的 skill。skills 本质上是 SKILL.md 方法说明书，解决的是“这类任务通常怎么做”。它给模型提供步骤、方法和注意事项，但 skill 自己不维护 session，不负责上下文循环，也不会独立执行工具链路。正因为如此，Skill 像流程，却不等于 agent；它补充的是方法，不承担执行主体的职责。

第三种情况是调用 tool。模型如果需要读文件、处理附件、查询信息、发送消息、执行命令或访问外部服务，就会调用系统已经暴露给它的工具。工具调用之后，系统会把返回结果重新写回上下文，再交给 agent 继续判断下一步。这里真正推动任务持续前进的，不是单次模型输出，而是“模型判断—工具调用—结果返回—再次判断”这一整套循环。

这时 agent 的作用才真正显现出来。agent 会基于模型输出、工具结果和更新后的上下文，继续决定后面是否还要读文件、发消息、执行命令，或者进入下一轮调用。也就是说，agent 不是一句提示词，而是驱动整个执行循环向前推进的主体。Skill 提供方法，tool 提供动作，agent 负责把方法和动作串起来。

MCP 讲的是另一条线。它不负责定义方法，也不直接承担执行循环，而是解决“外部客户端怎样标准化接进来”这个问题。openclaw mcp serve 会把 Gateway 中已经路由完成的会话暴露成 MCP conversations 和 transcript/history tools，让外部 IDE 或其他 MCP 客户端可以复用这些会话和历史。放在这里看，MCP 更像连接层，不是方法层，也不是执行层。[12]

因此，当用户向 OpenClaw 发出“把会议录音整理成纪要并发给团队”这个任务之后，系统会先把这条消息、历史记录、AGENTS.md、SOUL.md、memory、tools 和 skills 元数据一起组织成上下文，以判断这不是一句话能完成的任务。然后会去读取“会议纪要规范”这类 skill，再调用读文件、处理文本或发消息相关工具。工具返回结果之后，agent 会再根据更新后的上下文决定是否继续处理、调整格式或发送给团队。等结果返回给用户之后，如果这个流程还需要被外部 IDE 或 MCP 客户端复用，系统再通过 MCP 接口把会话和历史发送出去。

综上所述，把 OpenClaw 的一次运行过程拆开之后，看到的就不只是一个产品流程，而是一套完整的 LLM API 使用方式和上下文工程方法。输入只是起点，真正决定系统表现的，是它怎样组织上下文、怎样调用方法、怎样推进执行，以及怎样把内部执行过程接到外部世界。

参考资料

[1] OpenClaw Docs. Documentation index. https://docs.openclaw.ai/index

[2] OpenClaw Docs. Gateway configuration. https://docs.openclaw.ai/gateway/configuration

[3] OpenClaw Docs. Session. https://docs.openclaw.ai/concepts/session

[4] OpenClaw Docs. Multi-agent. https://docs.openclaw.ai/concepts/multi-agent

[5] OpenClaw Docs. Agent workspace. https://docs.openclaw.ai/concepts/agent-workspace

[6] OpenClaw Docs. Context. https://docs.openclaw.ai/concepts/context

[7] OpenClaw Docs. System prompt. https://docs.openclaw.ai/concepts/system-prompt

[8] OpenClaw Docs. Memory. https://docs.openclaw.ai/concepts/memory

[9] OpenClaw Docs. Tools. https://docs.openclaw.ai/tools

[10] OpenClaw Docs. Skills. https://docs.openclaw.ai/tools/skills

[11] OpenClaw Docs. Agent loop. https://docs.openclaw.ai/concepts/agent-loop

[12] OpenClaw Docs. CLI MCP. https://docs.openclaw.ai/cli/mcp

---