写在使用Openclaw之前openclaw诞生的场景，除了面对多Agent的治理外，还通过模拟人类操作来制定治理架构。

写在使用Openclaw之前

openclaw项目(openclawcn.com/)开创了工作流之后的Agent新的应用场景——Agent调度与治理。

Agent一开始以功能架构为核心，聚焦于功能封装与协议化通讯等，比如claude code就是以Agent为核心，定义mcp或者skills后，人类提示Agent使用skill。这是一种平铺的组织方式，开发者维护一个skill或者工具的列表，Agent或者Server意图识别后，Agent调用并返回结果，可能IDE会将调用拆解为多阶段任务，但本质上还是以功能为核心；又比如RAG应用，面对的也是单一Agent的功能。

而openclaw诞生的场景，除了面对多Agent的治理外，还通过模拟人类操作来制定治理架构。所以openclaw面向已经不在是功能封装，而是面向治理。本篇文章的行文思路，将深入拆解openclaw，先介绍openclaw的能力与场景形成最初观感，然后讲述openclaw的运转过程并拆解各模块的特点，最后研究openclaw的外部关联。

OpenClaw的能力

OpenClaw的核心能力是"让AI像人一样操作电脑"，直接操作专为人类设计的硬件接口比如读取屏幕、移动鼠标、打开应用、输入文字等，而非传统的通过协议调用api完成某些功能，通过一个拟人的、范围更广的接口来统一需要各种协议规范调用的其他接口（无非是选择加多了一个中间层），这种设计使它不依赖常规软件API就能操作任意软件，实现真正的跨应用流程自动化。调用的是更底层的硬件接口，本地化的架构就成为了必须。

使用场景举例：

通过聊天界面给openclaw下达命令：帮我查找小红书上关于 BYD的防导弹车的文章。它会自动调用操作系统接口，打开小红书截图，识别与定位输入框，点击并输入关键词，查找文章，逐文章打开并截图ocr与理解，形成总结，得到链接。响应给你。
群组使用：可以启动多个openclaw实例，加入同一个飞书群组。A实例负责制定计划，B实例负责执行，C实例review。用户可以往群组里@A，A制定后@B，B执行完@C，C再交给用户。
“养虾”：因为openclaw的理念是本地环境优先，又提供了有状态的记忆与上下文管理，所以衍生了AI圈子的“养虾"黑话。目的是基于本地环境调试Openclaw（或调试它如何更好地操作你的电脑），为特定目的安装工具、修改记忆与上下文，随后Openclaw可以比较成功地完成任务，是一种类似养成的模式。
更多场景：github.com/hesamsheikh…

通过用户侧的硬件接口，就能够帮助用户做到许多事情。但是，用户侧接口可能花里胡哨并不是给AI Agent使用的，对AI并不友好，增加了通用性却降低了准确性，这个是openclaw的应用挑战之一。

openclawcn.com/docs/start/…

OpenClaw的结构

具体文档：openclawcn.com/docs/concep…

Openclaw强调极简设计，所以脉络清晰。从“消息从哪里来、在哪里跑模型、怎么做扩展与控制”来理解系统结构：

Channel是消息入口，用来接受用户命令与交互
Gateway是分发控制门户，用来管理会话、管理权限、管理路由。
Agent是能力中枢，用来调用工具、记忆、决策。
Provider是LLM层的封装，用来控制对话与认证。
流转过程类似于下图：用户消息 → Channel适配器 → 网关服务器 → Agent Loop → LLM 调用 → 工具执行 → 响应返回。
通过事件循环looprun的方式运行与调度任务执行。

核心设计

openclaw具体文档：openclawcn.com/docs/concep…

参考自衍生项目：

github.com/smallnest/g…

github.com/sipeed/pico…

ACP（Agent Client Protocol）

有两个ACP协议，一个是IBM提出，另外一个是Zed提出，Openclaw使用的是后者，Agent Client Protocol规范了Agent如何与IDE或者软件交互（和vscode的LSP设计类似，agentclientprotocol.com）， openclaw强调Pi Agent设计("LLMs 本身就擅长编写和运行代码，不需要过多的包装")，认为Agent本身已经有编码能力，所以openclaw可以自行编写代码与执行，进而完成某些功能。所以，Openclaw中会嵌入ACP模块，允许Agent调用IDE。

Openclaw本身也是一个应用，应用与Agent通讯的规范也处于ACP范围，所以，ACP是openclaw中各个模块通讯的基石：

OpenClaw生态系统的基础通信协议
支持多向连接的互操作标准
多Agent协作的核心机制
跨平台应用集成的桥梁
企业级AI协作工作流的保障

┌─────────────────────────────────────────────────────────────────────────────┐
│                          goclaw ACP Architecture                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌─────────────┐      ┌──────────────┐     ┌─────────────────────────────┐  │
│  │   Gateway   │────▶│ ACP Manager  │────▶│      Runtime Registry      │  │
│  │   (WebSocket)│     │  (lifecycle) │     │    (backend plugins)        │  │
│  └─────────────┘      └──────────────┘     └─────────────────────────────┘  │
│         │                    │                        │                     │
│         │                    ▼                        ▼                     │
│         │           ┌──────────────┐        ┌─────────────────┐             │
│         │           │Actor Queue   │        │  ACP SDK        │             │
│         │           │(per-session  │        │  Adapter        │             │
│         │           │ serialization)│       │  (acp-go-sdk)   │             │
│         │           └──────────────┘        └─────────────────┘             │
│         │                    │                        │                     │
│         ▼                    ▼                        ▼                     │
│  ┌─────────────┐      ┌──────────────┐      ┌─────────────────────────────┐ │
│  │   Agent     │────▶│Thread Binding│────▶│      ACP Runtime            │ │
│  │  (spawn_acp)│      │  Service     │      │   (stdio process)           │ │
│  └─────────────┘      └──────────────┘      └─────────────────────────────┘ │
│                                                                             │
└───────────────────────────────────────────────────────────────────—─────────┘

openclaw引入了acp作为中间层，用户在channels层下达命令之后，通过websocket到达gateway，然后通过acp与Agent层通讯，如果Agent需要调用额外的第三方Agent服务，openclaw也可以作为ACP Client调用第三方Agent。

多Agent系统

Agent系统的核心：记忆、工具、skills、多级Agent与无状态调用。

记忆系统，因为openclaw强调本地运行环境，所以记忆系统是基于文件系统的文件而非数据库，并且分离为短期记忆与长期记忆。记忆系统用于辅助构建上下文。长期记忆作为一个单独的md文件，然后在笔记文件夹中，写入多个md文件作为"今日笔记"。对于一个本地单机程序而言，这个设计已经足够。
工具系统。Agent系统中定义工具注册中心并抽象了工具接口，工具有普通工具、ACP编码工具（自己写代码与执行）、Agent工具（包装其他Agent作为工具）。tools最终会作为调用LLM的请求参数，并进入LLM判断工具是否使用的逻辑，通过tool_call决定是否调用tool。
Skills系统，Skills是面对Agent的概念，与本地环境比较强相关。Skills是一个个markdown文件与对应的静态资源的集合，通过轮询文件夹中的内容，会在内存中构建Skills对象，将Skills注册到Agent中，初始化比如检查二进制文件、预安装npm依赖等。与tools类似，最终也会经过tool_call的逻辑决定是否调用skills。
多级Agent功能。旨在将一次任务拆解为多个步骤，交给多级Agent完成再汇总；或者用于无状态session调用。

沙箱sandbox机制

提供了简单的沙箱机制用来运行shell命令，核心原理是利用docker包，使用docker客户端创建一个容器，将内部系统与工作目录挂载进去，随后在docker容器的环境中运行shell命令，形成隔离的安全效果.

	resp, err := t.dockerClient.ContainerCreate(ctx, &container.Config{
		Image:      t.sandboxConfig.Image,
		Cmd:        []string{"sh", "-c", command},
		WorkingDir: t.sandboxConfig.Workdir,
		Tty:        false,
	}, &container.HostConfig{
		Binds:       binds,
		NetworkMode: container.NetworkMode(t.sandboxConfig.Network),
		Privileged:  t.sandboxConfig.Privileged,
		AutoRemove:  t.sandboxConfig.Remove,
	}, nil, nil, containerName)
	if err != nil {
		return "", fmt.Errorf("failed to create container: %w", err)
	}
    ...

    if err := t.dockerClient.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
		return "", fmt.Errorf("failed to start container: %w", err)
	}

Session与状态管理

OpenClaw 将每个智能体的一个直接聊天会话视为主会话。直接聊天折叠为 agent::（默认 main），而群组/频道聊天获得各自的键。session.mainKey 会被遵循。

每一个Session作为一个文件存储在磁盘，并且维护cache在内存中，管理Session的数据结构是多叉树，除了方便组织与索引之外，可以每次 LLM 调用之前从内存上下文中修剪旧的工具结果，这个过程叫会话剪枝。每一次聊天与任务下达时，会有对应的sessionKey，执行Agent调用之前，会通过sessionKey找到历史上下文，并且识别其中作为tools、user、assistant的消息，进而通过某种剪枝策略将历史消息压缩，随后传入Agent调用。可以基于一次Session的对Agent调用多次，也可以每一个session创建一个新Agent形成无状态调用。

剪枝策略：

const (
	// PruneStrategyLRU removes least recently used sessions
	PruneStrategyLRU PruneStrategy = "lru"
	// PruneStrategyLFU removes least frequently used sessions
	PruneStrategyLFU PruneStrategy = "lfu"
	// PruneStrategyTTL removes sessions past their TTL
	PruneStrategyTTL PruneStrategy = "ttl"
	// PruneStrategySemantic uses semantic similarity to deduplicate
	PruneStrategySemantic PruneStrategy = "semantic"
	// PruneStrategySize removes largest sessions first
	PruneStrategySize PruneStrategy = "size"
)

Gateway设计

Openclaw的Gateway设计是整个项目的调度中心，是一个长生命周期的后台进程，负责协调所有的消息输入、输出、会话管理以及与控制平面的交互。既连接外部的channel（各种即时聊天平台），又负责底下多Agent的执行与调度。

gateway会暴露一个websocket接口，用于外部通讯。并且通过json-rpc的规范进行cs交互。
通过事件驱动与异步处理，完成消息接收与处理的解耦
负责路由与生命周期管理，收到消息后，gateway负责查找或者生成session，并根据channel路由到底下的Agent层。并且作为守护进程，它还会负责相关定时任务的调度与执行。
负责宿主的管理界面等
数据流程：
1. Ingestion (摄入): 用户在 Telegram 发送消息 -> Telegram Channel 适配器接收 -> 转换为 StandardMessage。
2. Queueing (入队): 消息被推送到 Gateway 的调度队列。
3. Routing (路由): Gateway 调度器取出消息，根据 ID 查找或创建 Session。
4. Execution (执行):
  - 加载历史上下文。
  - 构建 Prompt（System Prompt + History + Tools）。
  - 调用 LLM 进行推理。
  - 如果模型决定调用工具，Gateway 协调 Skill 执行并反馈结果。
5. Response (响应): Agent 生成最终文本 -> Gateway 接收 -> 路由回 Telegram Channel -> 转换为 Telegram 格式 -> 发送给用户。

外部联系与评价

OpenClaw 已经超过 250K stars(2026-03-04)，超过了 React（243K）和 Linux（220K）, 4 个月从 0 到 GitHub 第一。

首先是AI的热度让Openclaw借到了东风，另外是无关技术栈的特点让他的覆盖范围超过了React（前端领域）与Linux（内核领域），可以跑在mac、window、手机甚至是单片机，本地化运行的特点让它离用户更近，拟人地运用硬件接口又是直观接近用户的方式。

按照数据结果来看，以产品与研发的视角而言，"这打破了"大型项目必须大团队"的迷信。专注、极致的产品思维 > 人海战术"。

用户侧硬件接口确实可以统一底下许多软件与服务的交互，也能够横向关联许多日常需求，这让人看到了智能化生活的影子，甚至与如果在车机上或智能家居上安装类似openclaw的工具，用户侧接口的力量可以进一步释放，因为这是最简单与易于理解的东西，用户接近之后有了更高的反馈感，俗称用户粘性。

但是，Openclaw也是存在很多问题。

首先是安全性，这个是AI时代一直存在的；本地环境的AI意味着它可以访问到高级权限的东西：删除你的文件，读取你的密码等，狂欢夜的背后是火鸡的鸣叫。
其次纵观Openclaw的整体架构，符合自称的”AI自举“，由AI编写出来的项目，蒸馏出的内容没有新东西，还是属于"新瓶装旧酒"，也就意味着许多成熟架构面对的问题它仍然存在，并没有解决。便捷性是靠更多的token堆积出来的，长链路的旧架构还是存在了准确性降低的问题。
本地化的强绑定会导致迁移困难。
网络上许多Openclaw使用示例，其实通过常规的工作流、claude code也能完成，Openclaw只是给出同等级下一个解决方案，是否采用需要取舍决定。

无可否认，Openclaw是一个现象级的产品，简约的设计与直观的产品思路，让它可以被称为”是生产力基础设施的革命“，其背后隐藏的用户诉求与发展趋势值得深究，在此之前，应该先去使用，试着养虾与琢磨这次变革，成为一起吃螃蟹的人。