5张图看懂OpenClaw的Harness设计

Harness这一概念近来热度很高，加之某些代码模型日益“龙虾化”，驱使我深入探究OpenClaw的Harness究竟是怎样构建的。

因此，我决定从OpenClaw的源代码着手，对其架构、执行流、记忆模块，以及内外工具与技能的调用逻辑进行了深度剖析...

如果你的工作涉及类似OpenClaw的项目，那么接下来的这五张图绝对不容错过：

OpenClaw的整体架构呈分层结构：涵盖了用户交互、网关控制、能力与扩展，直至底层的状态存储。

此图清晰地表明，OpenClaw是一个“网关先行”的设计。

它的上层对接多渠道输入，下层连接会话路由、插件体系、记忆模块及运行时，核心则是一条标准化的执行主线。

那么OpenClaw究竟如何同LLM协同工作呢？答案就在其 Harness 层。

可将Harness视为OpenClaw为LLM打造的一个结构化执行外壳：

这个外壳的职责是组装提示、挂载工具、集成技能与记忆、应用策略与安全约束，然后藉由Provider Adapter与各家LLM的API进行通信。这块逻辑可以说是稳如老狗。

正因Harness的存在，OpenClaw才避免了简单地“将文本抛给模型”，从而真正获得了可扩展、可管控、能落地的Agent执行力。

输入及上下文

Harness的“原料”涵盖用户消息、指令、会话记录、工作区文档、启动上下文，以及由插件提供的各种工具和技能。

Prompt组装模块

负责将系统提示、技能提示、文档、启动文件及运行时信息组合成最终提交给模型的prompt。

模型选择与策略

此层级决定了具体使用何种模型、推理的“思考”级别及认证凭据。同时，它也负责处理模型回退、以及特定钩子对模型选用和prompt的干预。这种写法就很灵性。

工具及安全沙箱

它为模型设定了能力调用边界，防止其直接触碰系统敏感区域，从而提升整体安全性。

Agent会话及执行环路

作为Agent Loop的实际执行层，其任务是创建Agent会话、接收流式响应、处理工具调用，并将工具执行结果反馈给模型。

供应商适配层

此模块统一封装了不同模型供应商的API调用，使得上层应用无需为每个模型都重写一套交互逻辑。

传输及认证

负责与模型服务建立连接，涵盖HTTP、SSE、WebSocket等多种传输协议及其认证机制。

LLM接口

OpenClaw的提示、工具集及参数在此处被传递给大模型，模型的输出也通过此接口返回。

会话持久化及回传

这是结果的落盘层，它将对话记录、流式增量及最终答复写回会话，并把结果分发至各类前端应用、命令行等上层入口。

为何消息能在不同渠道间共享上下文？

不论消息源自命令行、网页端还是其他外部渠道，它们最终都会汇入同一条执行主干：首先定位Session，接着运行Agent，然后决定回传方式。

各模块的配合如下：

• 各类消息渠道（如IM平台）负责接收信息

• 路由模块负责匹配正确的Agent与Session

• 编排层则将消息构造成一个可执行任务（包含上下文组织、状态回馈等）

• Agent负责内容生成，它会结合prompt/memory/skills等完成推理过程

• 出站/渠道插件负责按原渠道格式将结果返回

此图演示了一条消息从“接收”到“响应”的完整生命周期中，各核心组件间的互动次序。

OpenClaw在接收到消息后，首先会执行去重、序列控制和基础验证，随后结合账户、会话及话题线索，来定位到精确的Agent和Session。

紧接着，系统将正文、媒体文件、引用回复等信息整合为统一的上下文，并交由Agent运行时处理。在此期间，策略研判、钩子、输入状态提示、技能、工具调用和记忆检索等环节都会被激活。

待Agent生成结果后，系统会依据回复目标和线程关系，选定恰当的投递对象，将响应送回原始渠道。

OpenClaw的记忆功能并非单个模块，而是由「工作区内的记忆文件」、「Agent运行时的记忆工具」、「后台的索引检索层」这三个部分协同构成的。

如图所示：

• 在工作区中，MEMORY.md与memory/*.md文件构成了记忆的主体，这部分属于长期记忆。

• 在Agent运行时里，MEMORY.md的内容被直接注入上下文，仅用以覆盖会话启动时的背景信息，而memory/*.md则是通过memory_search / memory_get按需调取。

• 此外，后台存在一个记忆索引与检索层，它会将MEMORY.md和memory/*.md的内容为每个agent构建独立的SQLite索引。该索引层主要负责分块、嵌入和检索，其本身不存储记忆原文。

值得一提的是，关于“小龙虾”的个性设定文件（如SOUL.md / IDENTITY.md / USER.md等），尽管它们也作为启动时的人设上下文，但并未纳入memory_search的索引体系，因此在严格意义上不算是记忆，而应归类为人格/身份注入。

网关是中枢，而插件体系则是“小龙虾”能力无限扩展的基石。

下方的图示展现了插件从“发现、装载、注册到运行时激活”的整个生命周期，并说明了Plugin SDK是怎样支持各类插件的。

OpenClaw的插件设计理念，并非将能力硬编码到主流程中。

系统首先会扫描发现插件、验证其声明文件，然后根据配置来决定哪些插件会被激活并进入运行时环境。

一旦进入运行时，插件提供的能力并不会分散在系统各处，而是被集中注册到“运行时激活清单”中。

• 渠道类插件：负责对接消息来源；

• 平台类插件：主要用于扩展工具、钩子、供应商和技能；

• 网关注入点：承担将这些能力挂载到方法、路由和服务上的任务