1.概述

OpenClaw 将传统的对话式机器人进化为具备行动能力的 Agent。它部署在您的本地硬件环境中，作为持续运行的智能助手，通过现有的消息系统与交互界面无缝接入并执行任务。

2.内容

2.1 什么是OpenClaw

OpenClaw 是一个可自托管的个人 AI 助手平台 。

它可以运行在您自己的基础设施上------无论是笔记本电脑、VPS、 Mac mini，还是云容器环境。

OpenClaw 将 AI 模型与您已经在使用的即时通讯工具无缝连接，例如：

WhatsApp
Discord
Slack
iMessage
Microsoft Teams

让 AI 助手真正融入您的日常沟通环境，而不是局限在某个网页或独立 App 中。

2.1.1 从"提示工程"到"系统工程"

OpenClaw 将 AI 助手视为一个基础设施问题，而不仅仅是提示工程问题。

它不会依赖让 LLM"记住上下文"或通过复杂提示词来维持安全与稳定。

相反，OpenClaw 在模型之外构建了一套结构化的执行环境，包括：

完整的会话管理机制
独立的长期与短期记忆系统
工具沙箱与权限控制
消息路由与多渠道编排

LLM 提供智能，
OpenClaw 提供操作系统。

模型负责"思考"，OpenClaw 负责"执行"。

2.1.2 数据与控制权：始终掌握在您手中

您可以完全掌控：

助手运行在什么位置
消息如何路由
可使用哪些工具
会话如何隔离

模型 API 请求仍然会发送至：

Anthropic
OpenAI
或您自部署的模型服务

但以下内容全部保留在您的基础设施中：

对话历史
工具执行记录
会话状态
编排逻辑与系统控制流

智能可以在云端，

控制权必须在本地。

2.2 架构介绍

2.2.1 OpenClaw：AI 代理操作系统

OpenClaw 并非对 AI 模型 API 的简单封装。

它是一个 AI 代理操作系统（Agent OS）。

OpenClaw 将 AI 视为一个系统工程问题，而不是提示工程问题。

它关注的是：

会话生命周期管理
记忆与上下文持久化
工具沙箱与权限控制
访问控制与身份隔离
任务编排与执行流管理

AI 模型提供智能；OpenClaw 提供执行环境。

模型负责推理与生成，

OpenClaw 负责状态、控制与执行。

2.2.2 中心辐射式架构

OpenClaw 采用中心辐射式架构，以一个统一网关作为系统核心控制平面。

该网关连接：

WhatsApp
iMessage
Slack
macOS 本地应用
Web UI
CLI

所有用户输入统一进入网关，再由网关路由至代理运行时。

2.2.3 核心组件说明

1️⃣ 网关

网关是一个 WebSocket 服务器，负责：

接入各类消息平台与控制接口
统一认证与访问控制
消息路由与会话隔离
将输入分发到对应的代理运行时实例

它是整个系统的控制平面。

2️⃣ 代理运行时

代理运行时负责完整的 AI 执行循环（Agent Loop）：

从会话历史与记忆系统中组装上下文
调用模型 API
解析工具调用指令
执行系统能力（例如浏览器自动化、文件操作、Canvas、计划任务等）
持久化更新后的状态

模型是推理引擎，

运行时是执行引擎。

关键优势：接口层与运行时解耦

OpenClaw 的核心设计优势在于：

将"接口层"（消息来源）与"助手运行时"（智能与执行所在层）彻底分离。

这意味着：

您可以通过任何消息应用访问同一个持久助手
对话状态集中管理
工具权限统一控制
多渠道共享记忆与执行能力
所有核心状态保留在您的硬件之上

AI 不再被困在某个聊天窗口中，

而是成为一个跨接口、跨场景的长期运行系统。

插件化扩展架构

OpenClaw 的核心设计原则之一是：

扩展能力，而不侵入核心。

系统通过插件机制进行功能扩展，无需修改核心代码即可增加新能力。这使 OpenClaw 在保持稳定内核的同时，具备高度可演进性。

插件主要通过以下四种方式扩展系统：

1️⃣ 频道插件（Channel Extensions）

用于接入新的消息平台，例如：

Microsoft Teams
Matrix
Mattermost

通过频道插件，可以将 OpenClaw 的代理能力无缝扩展至新的通信环境，而无需调整运行时逻辑。

2️⃣ 内存插件（Memory Extensions）

用于替换或增强默认存储后端。

支持：

向量数据库（语义检索）
知识图谱系统
替代默认的 SQLite 存储方案

这允许开发者根据场景需求选择不同的持久化与检索策略，从轻量本地存储到分布式知识系统。

3️⃣ 工具插件（Tool Extensions）

用于扩展代理可调用的系统能力。

除内置的：

Bash 执行
浏览器自动化
文件系统操作

之外，可以通过工具插件注入自定义能力，例如：

数据库访问
企业内部 API
DevOps 控制
业务系统集成

代理的能力边界，由插件决定。

4️⃣ 提供商插件（Provider Extensions）

用于接入新的模型提供方或自托管模型。

支持：

自定义 LLM API 适配层
私有模型部署
多模型策略切换

模型智能可以来自任何地方，OpenClaw 只负责统一调度与编排。

插件加载机制

插件系统位于 extensions/ 目录，采用**基于发现（discovery-based）**的加载模型。

核心加载流程：

插件加载器（src/plugins/loader.ts）扫描工作区包
检查 package.json 中是否存在 openclaw.extensions 字段
根据声明的 schema 进行配置验证
验证通过后执行热加载（hot load）

这种机制带来几个关键优势：

无需硬编码注册
支持模块化分发
支持运行时动态扩展
插件与核心完全解耦

3.核心组件

1️⃣ 通道适配器（Channel Adapters）

每个消息平台都由一个专属适配器负责接入。

部分适配器为内置模块（例如 src/telegram/、src/discord/、src/slack/、src/imessage/ 等），其他平台则可通过频道插件扩展接入。

所有适配器实现统一接口，并对入站与出站消息进行规范化处理。因此，OpenClaw 的核心运行时无需关心平台之间的 API 差异。

尽管不同平台的协议、数据结构与身份验证方式差异巨大，每个适配器都遵循同一个抽象接口，并承担四项核心职责：

一、身份验证（Authentication）

不同平台采用不同的认证机制：

WhatsApp
使用 Baileys 库进行二维码配对，凭据存储于 ~/.openclaw/credentials。
Telegram
通过 TELEGRAM_BOT_TOKEN 环境变量提供机器人令牌。
Discord
通过 DISCORD_BOT_TOKEN 环境变量完成认证。
iMessage
依赖 macOS 原生集成，并需要正确签名的"信息"应用。

适配器封装了各平台的认证流程，使运行时无需处理平台差异。

二、入站消息解析（Inbound Normalization）

不同平台的消息结构差异显著。

入站解析层负责：

提取纯文本内容
处理媒体附件（图像、音频、视频、文档）
解析表情与特殊符号
维护回复链与对话上下文

解析完成后，消息会被转换为统一的内部格式。

这意味着 OpenClaw 的核心逻辑无需关心消息来源------它只接收标准化事件。

三、访问控制（Access Control）

通道层是安全控制的第一道防线。

支持多层访问策略：

1️⃣ 允许列表（Allow List）

例如：

复制代码

{
  "channels": {
    "whatsapp": {
      "enabled": true,
      "allowFrom": ["+1234567890"],
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

仅允许指定号码或用户名与机器人交互。

2️⃣ 私信策略（Direct Message Policy）

paired（默认）------首次交互需审批
open ------ 接受所有私信（不推荐）
disabled ------ 拒绝所有私信

3️⃣ 群组策略（Group Policy）

强制 @ 提及才响应
群组级允许列表
群组访问隔离

通过在通道层实现访问控制，可以防止未经授权的输入进入代理运行时。

四、出站消息格式化（Outbound Formatting）

每个平台都有自己的限制与规则：

Markdown 方言差异
消息长度限制
媒体上传 API 不同
输入指示器与在线状态管理

适配器负责：

自动拆分超长消息
渲染平台兼容的 Markdown
上传媒体文件并生成引用
管理"正在输入"状态

运行时只输出逻辑响应，适配器负责平台兼容性。

2️⃣ 控制接口（Control Interfaces）

OpenClaw 提供多种与网关交互的方式，覆盖不同的使用场景与操作习惯：

Web 用户界面
命令行界面（CLI）
macOS 桌面应用
移动节点（iOS / Android）

这些接口本质上都是网关的客户端，只是形态不同。

🌐 Web 用户界面

Web UI 基于 Lit Web Components 构建，并由网关直接提供服务。

默认访问地址：http://127.0.0.1:18789/
无需额外 Web 服务器，网关自身承担全部服务职责。

控制面板包含：

聊天界面
配置管理
会话检查
节点管理
健康监控

Web UI 本质上是控制平面的可视化界面。

💻 命令行界面（CLI）

CLI 基于 Commander.js 构建，从 openclaw.mjs 启动，核心逻辑位于 src/cli/program.ts。

常见命令示例：

复制代码

openclaw gateway        # 启动网关
openclaw agent          # 直接调用代理
openclaw channels login # 登录 WhatsApp 或 Signal
openclaw message send   # 发送消息
openclaw doctor         # 运行健康诊断
openclaw onboard        # 引导式初始化

CLI 适用于自动化脚本、服务器部署与高级用户操作。

🍎 macOS 应用

macOS 客户端位于 apps/macos/，使用 Swift 编写。

主要能力：

菜单栏常驻
网关生命周期管理（启动 / 停止 / 重启）
语音唤醒与一键对话覆盖层
嵌入 WebChat
通过 SSH 控制远程网关

它本质上是一个本地控制中枢。

📱 移动节点（Mobile Nodes）

iOS 与 Android 客户端通过 WebSocket 连接网关，并在握手中声明：

复制代码

{ "role": "node" }

它们不仅是聊天终端，更是可调用的设备能力节点。

移动节点可暴露：

摄像头访问
屏幕录制
地理位置
本地 Canvas 渲染

网关可通过 node.invoke 协议方法调用这些能力，使手机成为代理工具链的扩展。

3️⃣ 网关：系统控制平面（Gateway Control Plane）

网关实现于 src/gateway/server.ts，运行于 Node.js 22+，基于 ws WebSocket 库构建。

默认绑定：127.0.0.1:18789
仅使用回环地址以保证安全。

网关不仅是路由器，更是整个系统的唯一真实数据源（Single Source of Truth）。

连接拓扑

以下组件全部连接至网关：

WhatsApp（Baileys）
Telegram（grammY）
Discord（discord.js）
CLI
Web UI
移动节点

所有交互都通过 WebSocket 进行。

4.系统提示词架构

🧩 工作区配置体系（Workspace Configuration System）

OpenClaw 通过文件化配置定义代理行为，而非硬编码逻辑。

代理的能力、风格与约束均可在工作区内调整。

一、静态配置文件（Static Layer）

这些文件构成代理的基础行为框架。

1️⃣ `AGENTS.md` 核心代理指令（必选）

这是默认捆绑的核心配置文件。

定义内容包括：

代理可执行的操作范围
全局约束条件
安全边界
适用于所有会话的不可协商规则

它是系统级行为基线（Operational Baseline）。

2️⃣ `SOUL.md` 个性与语气（可选）

定义代理的表达方式，而非能力边界。

包含：

语气风格
回答结构
表达习惯
互动节奏

⚠️ 不涉及工具行为或安全策略。

它只影响"如何说"，不影响"能做什么"。

3️⃣ `TOOLS.md` 工具使用约定（可选）

记录用户在本地环境中的工具使用说明。

例如：

哪些目录可读写
运行 bash 时的约定
企业 API 使用规范

这不是工具注册表。

工具定义由 OpenClaw 自动生成并注入。

🔄 动态上下文（Per-Turn Context Assembly）

在每一轮对话中，运行时都会动态组装上下文，而不是静态拼接全部信息。

包括：

会话历史

当前会话的最新对话记录
从持久化 JSON 文件加载
保证连续性与上下文记忆

技能文件（`skills/<skill>/SKILL.md`）

技能是结构化的操作指南。

每个技能包含：

任务目标
操作步骤
工具调用规范
约束条件

可以理解为"标准操作流程（SOP）"。

技能是完成特定任务的能力模块，而非提示片段。

记忆检索（Memory Retrieval）

运行时通过语义搜索：

找到与当前问题相似的历史对话
提取相关背景
避免注入冗余信息

只保留高相关度内容，以防提示膨胀。

🛠 工具定义层（Auto-Generated Tool Layer）

工具定义由系统自动生成，并注入模型。

分为两类：

内置工具

位于：

src/agents/pi-tools.ts
src/agents/openclaw-tools.ts

包括：

Bash 执行
浏览器自动化
文件操作
Canvas
核心系统能力

插件工具

通过扩展系统注册：

复制代码

api.registerTool(toolName, toolDefinition)

允许开发者添加自定义能力，例如：

企业 API
数据库访问
DevOps 控制
外部系统集成

基础系统层（Runtime Base Layer）

运行时还会注入：

Pi Agent Core 指令集

来自代理运行时库 @mariozechner/pi-agent-core，提供：

工具调用协议
执行规则
响应格式约束

最终系统提示的构成

最终发送给模型的上下文由以下元素组合而成：

AGENTS.md（行为基线）
SOUL.md（风格控制）
TOOLS.md（使用约定）
动态技能注入
会话历史
记忆检索结果
自动生成的工具定义
Pi Agent Core 指令

这种可组合式上下文构建模型意味着：

您可以通过编辑工作区文件改变代理行为，而无需修改源代码。

与此同时，运行时仍然严格执行：

权限检查
沙箱隔离
工具执行控制

行为可配置，执行不可绕过。

互动与协调机制

1️⃣ Canvas 与 Agent-to-UI（A2UI）

Canvas 是一个由代理驱动的可视化工作空间。

它以独立服务器进程运行，默认监听端口：18793

为什么独立运行？

Canvas 与主网关分离，出于两个核心考虑：

1️⃣ 故障隔离

如果 Canvas 崩溃，网关与消息通道仍可继续运行。

2️⃣ 安全边界分离

Canvas 是代理"可写"的界面层。

将其与控制平面分离，可以防止 UI 渲染逻辑影响系统核心状态。

换句话说：

网关 = 控制平面
Canvas = 可视化呈现层
代理 = 执行与决策层

三者职责明确、相互解耦。

工作流程（Execution Flow）

Canvas 与代理之间通过 A2UI（Agent-to-UI）协议协作。

整体流程如下：

① 代理生成界面内容

代理调用 Canvas 更新方法，并生成包含 UI 内容的 HTML。

HTML 中可以嵌入 A2UI 属性，用于声明可交互行为。

② Canvas 服务器解析内容

Canvas 服务端：

接收 HTML
解析其中嵌入的 A2UI 指令
建立交互映射

A2UI 本质上是一个桥接层，让代理能够声明式地定义 UI 行为，而无需直接控制前端逻辑。

③ WebSocket 推送更新

Canvas 通过 WebSocket：

将更新后的内容推送至已连接的浏览器客户端
实现实时同步

系统采用事件驱动模型，而非轮询刷新。

④ 浏览器渲染交互界面

客户端：

渲染 HTML
绑定 A2UI 事件
将用户交互事件回传至服务器

代理从而可以：

观察用户操作
更新界面
执行后续逻辑

Canvas + A2UI 的设计解决了一个关键问题：

如何让代理安全地生成可交互界面，而不是仅输出文本。

优势包括：

UI 与控制平面隔离
可恢复的界面状态
实时同步
事件驱动交互
明确的安全边界

代理负责"生成界面逻辑"，

Canvas 负责"安全渲染与同步"。

A2UI（Agent-to-UI） 是一种声明式交互框架，使代理能够通过生成带有特定语义属性的 HTML 来构建可交互界面。

代理无需编写或控制 JavaScript 代码。

它只需输出结构化的 HTML，并在元素上标注 A2UI 属性，即可声明：

可点击行为
表单提交
状态更新
事件回传

这些特殊属性会被 Canvas 运行时解析，并自动绑定对应的前端交互逻辑。

换句话说：

代理负责声明"界面是什么、行为是什么"，

A2UI 负责实现"交互如何发生"。

这使代理能够安全地创建动态 UI，而不直接操控客户端脚本环境。

复制代码

<div a2ui-component="task-list">
  <button a2ui-action="complete" a2ui-param-id="123">
    Mark Complete
  </button>
</div>

当用户点击按钮时，交互流程如下：

1️⃣ 客户端触发事件

用户在界面上的点击行为会被客户端捕获，并通过 WebSocket 发送一个操作事件到 Canvas 服务器。

2️⃣ 服务器转发为工具调用

Canvas 服务器接收到该事件后，将其转换为标准化的工具调用，并转发给代理运行时。

3️⃣ 代理更新内部状态

代理处理该操作。例如，它可能在内部状态中将任务 123 标记为"已完成"，更新会话数据或触发后续逻辑。

4️⃣ 代理调用 Canvas 更新

状态更新完成后，代理调用 Canvas Update 方法，生成新的界面内容。

5️⃣ 实时推送与自动刷新

Canvas 服务器将更新后的内容通过 WebSocket 推送至客户端，客户端自动重新渲染界面，无需页面刷新。

整个流程是事件驱动且双向流式的：

用户操作 → 事件上报 → 代理决策 → 状态更新 → UI 重渲染

多平台支持

Canvas 是跨平台的统一界面层，不依赖特定终端。

macOS 应用：使用原生 WebKit 视图渲染
iOS 应用：封装在 SwiftUI 组件中
Android 应用：通过 WebView 显示
Web 浏览器：可直接在独立标签页中访问

所有平台共享同一套 Canvas 协议与更新机制。

2️⃣ 语音唤醒与通话模式

🎙 语音唤醒（Always-On Wake Word）

语音唤醒功能支持：

macOS
iOS
Android

系统提供始终开启的唤醒词检测。

只需说出：

"嘿 OpenClaw"

助手即可被激活，并立即进入监听状态。

除了唤醒词外，您也可以使用键盘快捷键进行"按键通话"（Push-to-Talk），适用于需要更高隐私或更精确控制的场景。

🔊 音频处理流程

语音交互采用流式处理模型：

1️⃣ 本地设备采集音频

2️⃣ 音频流发送至 ElevenLabs 进行实时转录
3️⃣ 代理运行时处理文本请求
4️⃣ 通过 ElevenLabs 的文本转语音（TTS）生成语音响应
5️⃣ 响应实时播放

整个过程是双向流式的，减少等待时间，提升对话自然度。

☎️ 通话模式（Conversation Mode）

通话模式在语音唤醒基础上扩展为连续对话体验。

特点包括：

免提对话（Hands-Free）
持续监听上下文
中断检测（Bar-Interrupt）
实时语音反馈

当助手正在讲话时，您可以随时插话，系统会检测语音中断并立即停止播放，转而处理新的输入。

这使交互更接近人与人之间的自然对话。

3️⃣ 多代理路由（Multi-Agent Routing）

多代理路由机制允许您将不同的通道、私信或群组，定向到彼此完全隔离的代理实例。

每个代理实例可以独立拥有：

专属工作区（Workspace）
独立模型配置
不同的行为规则与权限策略
独立的记忆与会话历史
单独的工具集合与沙箱策略

🎯 典型应用场景

个人助手与团队助手分离
不同群组使用不同语气或能力
测试环境与生产环境隔离
不同客户或部门独立运行

例如：

私人 WhatsApp 使用轻量模型
公司 Slack 群组使用企业策略与更严格权限
开发测试群使用实验模型

设想这样一个场景：

你的 Discord 服务器机器人 需要呈现出类似 Claude Sonnet 那样亲切、乐于助人、偏社区管理员风格的形象；

在 OpenClaw 中，这种差异化需求无需额外开发逻辑，只需通过多代理路由与独立工作区配置即可自然实现。

你可以为不同渠道绑定不同的代理实例，并分别定义：

使用的模型
行为规则（AGENTS.md）
语气风格（SOUL.md）
工具集合与权限策略
会话与记忆隔离方式

这种方式的核心优势在于：

不同场景拥有不同智能体，而不是让一个智能体扮演所有角色。

结果是：

Discord 保持轻松、社区化风格
两者互不干扰
配置清晰可控

这正是多代理路由的设计初衷：

在同一基础设施之上，实现多角色、多策略、多模型的自然分层。

复制代码

{
  "agents": {
    "mapping": {
      "group:discord:123456": {
        "workspace": "~/.openclaw/workspaces/discord-bot",
        "model": "anthropic/claude-sonnet-4-5",
        "systemPromptOverrides": {
          "SOUL.md": "You are a helpful Discord moderator..."
        }
      },
      "dm:telegram:*": {
        "workspace": "~/.openclaw/workspaces/support-agent",
        "model": "openai/gpt-4o",
        "sandbox": { "mode": "always" }
      }
    }
  }
}

这种路由机制不仅仅是"多实例部署"，而是为复杂场景提供结构化隔离能力。

它支持一系列强大的应用模式：

场景化角色分层

您可以为每个社区创建独立的角色实例，并针对该社区的文化、语气与使用习惯进行优化。

例如：

技术社区 → 更专业、偏工程表达
游戏社区 → 更轻松、互动性更强
企业内部 → 更正式、流程导向

每个角色拥有自己的行为规则与上下文记忆，而不会互相污染。

工具与权限分级

不同上下文可以配置不同的工具访问权限。

例如：

Discord 社区机器人 → 允许浏览器自动化与公开信息抓取
客服私信代理 → 禁止浏览器访问，仅允许内部知识库查询
内部运维代理 → 允许执行受控的命令行工具

工具能力不再是"全局开关"，而是上下文级策略。

安全隔离与沙箱控制

针对不受信任的用户或开放群组，可以启用更严格的沙箱策略：

限制文件系统访问
强制 Docker 隔离
缩减可调用工具范围

即使存在提示注入尝试或恶意输入，影响范围也会被限制在当前隔离上下文中，不会波及其他代理实例。

这是一种结构性风险控制，而非单纯依赖提示词防御。

行为灰度测试

您可以在某个上下文中测试新的客服策略或模型版本，而不会影响其他已经稳定运行的代理。

例如：

在测试群验证新的语气策略
在单个客户环境中试验新工具链
部署实验模型而不干扰生产环境

多代理路由天然支持灰度发布与分层迭代。

4️⃣ 会话工具（Agent-to-Agent Communication）

会话工具为代理之间提供了一套结构化的通信机制，使不同会话中的代理能够相互协调与协作。

这意味着：

代理不再是孤立的聊天实例，而是可以互相沟通的智能体网络。

当需要多个代理协同处理复杂任务、分工执行步骤或共享上下文信息时，会话工具尤其有价值------无需在不同聊天窗口之间手动复制粘贴信息。

核心能力

1️⃣ `sessions_list` --- 发现活跃会话

用于查询当前活跃的会话实例。

代理可以：

查看哪些代理在线
识别可协作的目标实例
判断任务是否应转交给特定上下文

这为动态调度与分工奠定基础。

2️⃣ `sessions_send` --- 跨会话发送消息

允许一个代理向另一个会话发送结构化消息。

支持"静默委派"模式，例如：announceStep: "ANNOUNCE_SKIP"

在该模式下：

任务会被转发
原始会话用户不会收到通知
协作过程对用户透明

适用于后台任务协调或内部代理协商。

3️⃣ `sessions_history` --- 获取其他会话记录

允许代理查询另一个会话的历史交互。

典型用途：

在协作前获取背景信息
了解其他代理已完成的步骤
基于跨会话上下文做出决策

该能力使代理具备"组织级记忆"，而非仅限于单会话视角。

4️⃣ `sessions_spawn` --- 创建新会话

以编程方式生成新的会话实例，用于：

任务委派
子流程拆分
长任务异步执行
建立临时工作线程

这使代理能够动态扩展其执行结构。

5️⃣ 定时操作（Cron Jobs）与外部触发器（Webhooks）

OpenClaw 支持两种自动化机制：

⏱ 定时触发（Time-Based Automation）
🌐 事件触发（Event-Based Automation）

它们共同构成代理的"主动执行能力"。

定时操作（Cron Jobs）

定时任务允许您在指定时间自动触发代理执行操作。

例如：

每天上午 9 点生成一份工作摘要
每周一推送项目进度
每晚自动备份与报告分析结果

您只需通过配置定义调度规则，代理将在指定时间自动运行，并将结果发送至目标会话（例如主会话或指定频道）。

示例场景：

每日 09:00

→ 触发代理

→ 生成摘要

→ 推送至主会话

无需保持聊天窗口开启，也无需手动触发。

外部触发器（Webhooks）

Webhook 提供了一个外部系统触发代理行为的入口。

当外部系统向指定端点发送事件时，网关会将该事件转换为代理可处理的上下文输入。

典型应用包括：

邮件到达触发自动处理
CI/CD 任务完成后生成报告
表单提交后创建任务
支付成功后执行通知

例如，邮件系统（如 Gmail）可以在收到新邮件时向 Webhook 端点发送通知，从而触发代理执行分类、摘要或自动回复。

自动化模型

两种机制分别代表：

Cron → 时间驱动
Webhook → 事件驱动

它们都通过配置完成，无需编写额外代码。

这意味着：

无需自定义脚本
无需修改核心逻辑
无需额外服务编排

代理可以自动执行重复任务，也可以实时响应外部系统事件。

5.总结

OpenClaw 不是一个简单的聊天机器人框架，而是一套完整的 AI 代理操作系统。它将模型能力、会话管理、工具调用、权限控制与多通道接入统一在一个可自托管的控制平面之上。通过多代理路由、插件扩展、Canvas 可视化界面、语音交互、跨会话通信以及定时与 Webhook 自动化机制，OpenClaw 实现了从"对话式 AI"到"可执行智能体系统"的跃迁。

模型负责思考，运行时负责执行，网关负责协调。

在保持数据与控制权本地化的同时，OpenClaw 让 AI 真正成为可编排、可隔离、可扩展的基础设施。

6.结束语

这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！

另外，博主出新书了《Hadoop与Spark大数据全景解析》、同时已出版的《深入理解Hive 》、《Kafka并不难学 》和《Hadoop大数据挖掘从入门到进阶实战 》也可以和新书配套使用，喜欢的朋友或同学，可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。

OpenClaw 架构设计全解析

1.概述

2.内容

2.1 什么是OpenClaw

2.1.1 从"提示工程"到"系统工程"

2.1.2 数据与控制权：始终掌握在您手中

2.2 架构介绍

2.2.1 OpenClaw：AI 代理操作系统

2.2.2 中心辐射式架构

2.2.3 核心组件说明

1️⃣ 网关

2️⃣ 代理运行时

关键优势：接口层与运行时解耦

插件化扩展架构

1️⃣ 频道插件（Channel Extensions）

2️⃣ 内存插件（Memory Extensions）

3️⃣ 工具插件（Tool Extensions）

4️⃣ 提供商插件（Provider Extensions）

插件加载机制

3.核心组件

1️⃣ 通道适配器（Channel Adapters）

一、身份验证（Authentication）

二、入站消息解析（Inbound Normalization）

三、访问控制（Access Control）

1️⃣ 允许列表（Allow List）

2️⃣ 私信策略（Direct Message Policy）

3️⃣ 群组策略（Group Policy）

四、出站消息格式化（Outbound Formatting）

2️⃣ 控制接口（Control Interfaces）

🌐 Web 用户界面

💻 命令行界面（CLI）

🍎 macOS 应用

📱 移动节点（Mobile Nodes）

3️⃣ 网关：系统控制平面（Gateway Control Plane）

连接拓扑

4.系统提示词架构

🧩 工作区配置体系（Workspace Configuration System）

一、静态配置文件（Static Layer）

1️⃣ AGENTS.md 核心代理指令（必选）

2️⃣ SOUL.md 个性与语气（可选）

3️⃣ TOOLS.md 工具使用约定（可选）

🔄 动态上下文（Per-Turn Context Assembly）

会话历史

技能文件（skills/<skill>/SKILL.md）

记忆检索（Memory Retrieval）

🛠 工具定义层（Auto-Generated Tool Layer）

内置工具

插件工具

基础系统层（Runtime Base Layer）

最终系统提示的构成

互动与协调机制

1️⃣ Canvas 与 Agent-to-UI（A2UI）

为什么独立运行？

工作流程（Execution Flow）

① 代理生成界面内容

② Canvas 服务器解析内容

③ WebSocket 推送更新

④ 浏览器渲染交互界面

多平台支持

2️⃣ 语音唤醒与通话模式

🎙 语音唤醒（Always-On Wake Word）

🔊 音频处理流程

☎️ 通话模式（Conversation Mode）

3️⃣ 多代理路由（Multi-Agent Routing）

🎯 典型应用场景

场景化角色分层

工具与权限分级

安全隔离与沙箱控制

行为灰度测试

4️⃣ 会话工具（Agent-to-Agent Communication）

核心能力

1️⃣ sessions_list --- 发现活跃会话

2️⃣ sessions_send --- 跨会话发送消息

3️⃣ sessions_history --- 获取其他会话记录

4️⃣ sessions_spawn --- 创建新会话

5️⃣ 定时操作（Cron Jobs）与外部触发器（Webhooks）

定时操作（Cron Jobs）

外部触发器（Webhooks）

自动化模型

5.总结

1️⃣ `AGENTS.md` 核心代理指令（必选）

2️⃣ `SOUL.md` 个性与语气（可选）

3️⃣ `TOOLS.md` 工具使用约定（可选）

技能文件（`skills/<skill>/SKILL.md`）

1️⃣ `sessions_list` --- 发现活跃会话

2️⃣ `sessions_send` --- 跨会话发送消息

3️⃣ `sessions_history` --- 获取其他会话记录

4️⃣ `sessions_spawn` --- 创建新会话