夜雨聆风小龙虾openClaw系列4--四大核心概念：Agent/Gateway/Channel/Skill详解
在前三篇文章中，我们已经了解了：
• OpenClaw是什么、能做什么（🦞 一只会聊天的"小龙虾"） • 为什么越来越多人选择把AI助手从云端迁回自己的服务器 • OpenClaw的整体架构设计——一张图看懂这个系统是怎么运转的
今天这篇文章，我们要深入拆解OpenClaw架构中的四大核心概念：Agent、Gateway、Channel、Skill。
这四个概念构成了OpenClaw的骨架。理解它们，你就掌握了理解OpenClaw任何功能设计的钥匙。
先来看一张图：四大概念的关系
┌─────────────────────────────────────────────────────────────┐│ Gateway 网关层 ││ (消息路由中枢、连接管理、安全控制) │└─────────────────────────────────────────────────────────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ▼ ▼ ▼┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐│ Channel │ │ Agent │ │ Skill ││ 通讯渠道 │ │ AI代理系统 │ │ 技能插件 ││ (20+平台接入) │ │ (大脑+工具) │ │ (能力扩展) │└─────────────────┘ └─────────────────┘ └─────────────────┘ │ ▼ ┌─────────────────┐ │ AI Provider │ │ (模型提供商) │ └─────────────────┘一句话概括：
• Agent 是大脑，负责思考和决策 • Gateway 是神经系统，负责消息路由 • Channel 是感官，负责与外界通讯 • Skill 是超能力库，负责执行具体任务
下面我们逐一深入。
一、Agent —— OpenClaw的"大脑"
Agent不是简单的聊天机器人
很多人以为Agent就是ChatGPT那样的聊天界面——你问一句，它答一句。但在OpenClaw中，Agent是一个能感知、决策、执行的自治系统。
想象一个私人助理：
• 你跟他说"帮我订明天去上海的机票" • 他不会只回你一句"好的"，而是会问你几点出发、偏好哪个航司、经济舱还是商务舱 • 确认信息后，他会去查航班、比价、帮你预订、把行程发你邮箱
OpenClaw的Agent就是这样工作的。
Agent的核心组件
根据OpenClaw源码（src/agents/ 目录623个文件），一个Agent由以下核心组件构成：
| Agent Runtime | ||
| Context Engine | ||
| Memory System | ||
| Tool Registry | ||
| LLM Interface |
Agent的工作流程：Agent Loop
Agent的核心是一个循环（Loop），伪代码如下：
async function agentLoop(message: Message) { // 1. 构建上下文 const context = await contextEngine.build(message); // 2. 获取可用工具 const tools = toolRegistry.getAvailable(); // 3. LLM推理：理解意图，决定行动 const response = await llm.generate(context, tools); // 4. 如果需要工具，执行工具 if (response.requiresTool) { const result = await toolExecutor.run(response.toolCall); // 递归处理，直到完成任务 return agentLoop(result); } // 5. 返回最终结果 return response.content;}举例：你让Agent"帮我总结一下今天的邮件"
1. 理解意图：Agent识别出这是一个"邮件总结"任务 2. 选择工具：从Tool Registry中找到Gmail技能 3. 执行工具：调用Gmail API获取今天的邮件 4. 处理结果：拿到邮件内容后，再次进入Loop 5. 生成总结：LLM生成摘要，返回给你
多Agent协作（ACP协议）
OpenClaw支持多Agent协作。复杂任务可以拆分给多个子Agent：
• 研究Agent：专门负责信息搜集 • 编码Agent：专门负责写代码 • 审核Agent：专门负责代码审查
它们通过**ACP（Agent Communication Protocol）**协议通信。主Agent像项目经理一样分配任务，子Agent各司其职。
二、Gateway —— OpenClaw的"神经系统"
如果说Agent是大脑，那Gateway就是连接大脑和外界的神经系统。
Gateway的核心职责
根据源码（src/gateway/ 目录271个文件），Gateway负责：
| 统一入口 | call.ts | |
| 连接管理 | boot.ts | |
| 路由决策 | ||
| 认证授权 | auth.ts | |
| 健康监控 | channel-health-monitor.ts |
消息的生命周期（Gateway视角）
一条消息从用户发出到收到回复，在Gateway层面的流程是：
接收消息 → 认证鉴权 → 路由决策 → 转发Agent ↓返回结果 ← 格式转换 ← 渠道适配 ← 接收响应详细步骤：
1. 接收：通过WebSocket或HTTP接收消息 2. 认证：验证用户是否在白名单，是否有权限 3. 路由：根据消息类型、用户配置，决定发给哪个Agent 4. 转发：将消息包装成内部协议，发给Agent 5. 等待：等待Agent处理完成 6. 适配：将Agent的响应转换成目标渠道的格式 7. 发送：通过对应Channel发送给用户
Gateway的高可用设计
生产环境中，Gateway支持：
• 多实例部署：多个Gateway实例同时运行 • 负载均衡：消息均匀分配到各实例 • 故障转移：某个实例故障时，流量自动切换
这保证了你的AI助手7×24小时在线。
三、Channel —— OpenClaw的"感官系统"
Channel是OpenClaw与外界的通讯接口。如果把Agent比作大脑，Channel就是它的感官——眼睛、耳朵、嘴巴。
Channel的本质：统一抽象层
OpenClaw支持20+个通讯平台：WhatsApp、Telegram、Discord、飞书、iMessage、Slack、Email...
如果没有Channel层，每个平台都要单独适配。Channel提供了一个统一抽象层：
用户(WhatsApp) ──┐用户(Telegram) ──┼──> Channel层 ──> 统一消息格式 ──> Gateway用户(Discord) ───┤ (平台无关)用户(飞书) ──────┘每个Channel相当于一个适配器，负责：
• 平台API调用 • 消息格式转换 • 用户身份映射 • 群组管理
Channel支持的通讯类型
根据源码（src/channels/ 目录69个文件），Channel支持：
| 即时通讯 | ||
| 办公协作 | ||
| 传统渠道 | ||
| 社交媒体 |
Channel配置实战
在 openclaw.json 中配置Channel：
{ "channels": { "telegram": { "botToken": "YOUR_BOT_TOKEN", "allowlist": ["@your_username"], "dmPolicy": "allow" }, "discord": { "token": "YOUR_DISCORD_TOKEN", "dmPolicy": "deny", "guildIds": ["YOUR_GUILD_ID"] }, "feishu": { "appId": "YOUR_APP_ID", "appSecret": "YOUR_APP_SECRET", "encryptKey": "YOUR_ENCRYPT_KEY" } }}白名单与权限控制
**白名单（Allowlist）**是OpenClaw的重要安全机制：
• 只有白名单中的用户才能与Agent对话 • 可以按Channel配置（Telegram允许谁，Discord允许谁） • 可以按Agent配置（不同Agent有不同白名单）
为什么需要白名单？ 因为你的Agent可能连接到公网（通过Tailscale或公网IP），任何人都能发消息给它。白名单确保只有授权用户能访问。
四、Skill —— OpenClaw的"超能力库"
如果说Agent是大脑，Channel是感官，那Skill就是Agent能使用的超能力。
Skill的本质：语义化的能力单元
Skill不是简单的函数库。每个Skill都有语义描述：
• 这个Skill是做什么的？ • 在什么场景下使用？ • 需要什么参数？ • 返回什么结果？
Agent可以根据用户意图，自主选择使用哪个Skill。
Skill的两种形态
1. 内置技能（开箱即用）
OpenClaw内置了20+个技能，开箱即用：
| github | ||
| browser | ||
| web-search | ||
| 1password | ||
| apple-notes | ||
| github-issues |
2. 自定义技能（用户开发）
你可以开发自己的Skill。一个Skill的基本结构：
my-skill/├── SKILL.md # 技能定义（名称、描述、触发条件）└── tools/ # 工具实现 └── my-tool.tsSKILL.md 示例：
# My Skill## 描述查询公司内部的员工信息## 触发条件当用户询问员工信息时自动触发## 工具- searchEmployee: 根据姓名搜索员工- getEmployeeDetails: 获取员工详细信息Skill vs Tool vs Plugin 的区别
这三个概念容易混淆，一句话区分：
| Tool | |||
| Skill | |||
| Plugin |
ClawHub技能市场
OpenClaw有一个ClawHub技能市场（类似npm或App Store）：
• 发现技能：浏览社区贡献的技能 • 一键安装： openclaw skill install github• 版本管理：自动更新、回滚
你可以在ClawHub找到别人分享的Skill，也可以把自己开发的Skill分享给社区。
五、用一个场景串联四大概念
光讲概念不够直观。我们用一个完整场景，看看四大概念是如何协作的。
场景：你在Telegram上让OpenClaw帮忙查天气
Step 1: Channel接收消息
你在Telegram发消息："今天北京天气怎么样？"
• Telegram Channel接收到这条消息 • 进行平台协议转换（Telegram API → OpenClaw内部格式） • 提取用户信息、聊天ID、消息内容
Step 2: Gateway路由消息
• Gateway接收到来自Channel的消息 • 认证：检查你（用户ID）是否在白名单 • 路由：根据配置，决定发给哪个Agent（默认Agent） • 转发：将消息发送给Agent Runtime
Step 3: Agent处理请求
• Agent Runtime启动一个Agent Loop • Context Engine构建上下文（你是谁、你们之前的对话、当前时间...） • LLM推理：识别意图是"查询天气"，需要调用天气Skill
Step 4: Skill执行工具
• Agent从Tool Registry中找到天气Skill • 天气Skill调用天气API（如OpenWeatherMap） • 获取北京的实时天气数据 • 返回给Agent
Step 5: Agent生成回复
• Agent拿到天气数据后，再次进入LLM推理 • LLM组织语言："北京今天晴，气温15-22°C，空气质量良..." • 生成最终回复内容
Step 6: Gateway返回结果
• Gateway接收到Agent的响应 • 格式转换：将纯文本转换成Telegram支持的格式（Markdown） • 发送给Telegram Channel
Step 7: Channel发送给用户
• Telegram Channel调用Telegram Bot API • 发送消息到你的Telegram聊天窗口 • 你看到回复："北京今天晴，气温15-22°C..."
协作流程可视化
你(Telegram) │ ▼[Channel: Telegram适配器] │ "今天北京天气怎么样？" ▼[Gateway: 路由 + 认证] │ 验证用户 → 转发给Agent ▼[Agent: 决策 + 上下文] │ 识别意图 → 调用天气Skill ▼[Skill: 天气查询] │ 调用天气API ▼[Tool: HTTP请求] │ 返回天气数据 ▼[Agent: 生成回复] │ "北京今天晴，气温15-22°C..." ▼[Gateway: 格式化] │ ▼[Channel: Telegram发送] │ ▼[你看到回复]整个流程耗时：通常1-3秒，取决于网络延迟和LLM推理时间。
总结
今天我们深入讲解了OpenClaw的四大核心概念：
| Agent | ||
| Gateway | ||
| Channel | ||
| Skill |
它们的关系：
• Channel把外界信息传给Gateway • Gateway把信息路由给Agent • Agent决定调用哪些Skill • Skill执行具体任务，返回结果 • 结果沿原路返回给用户
理解了这四大概念，你就能：
• 看懂OpenClaw的任何配置项 • 理解官方文档的表述 • 设计自己的多Agent工作流 • 开发和发布自定义Skill
预告下一篇：《Gateway架构设计：消息路由的中枢神经》
我们将深入Gateway内部，看看它是如何管理千万级连接、保证消息不丢失、实现故障转移的。