成都著名网站建设公司,做公众号时图片的网站,建设网站技术解决方案,企业网站建设现状第 3 章 整体架构鸟瞰#xff1a;Gateway Agents Channels Skills 本章的目标#xff0c;是在你已经对 OpenClaw 有了直观印象之后#xff0c;给出一幅「可以在脑子里挂起来」的架构全景图。 我们会先用文字描述一张架构图#xff0c;再从 Gateway、Agent Runtime、Chan…第 3 章 整体架构鸟瞰Gateway Agents Channels Skills本章的目标是在你已经对 OpenClaw 有了直观印象之后给出一幅「可以在脑子里挂起来」的架构全景图。我们会先用文字描述一张架构图再从 Gateway、Agent Runtime、Channels、Nodes/Browser、Skills 五个角度分别做简要拆解最后用一个贯穿全书的案例——「清空收件箱」——画出一条完整的时序线作为后续章节的锚点。3.1 官方 README 架构图的文字版README 里有一幅简洁的 ASCII 图大致是顶部一排聊天通道Slack、iMessage、Discord 等中间是一个标着 control plane 的 Gateway 矩形底部连着 Agent Runtime 和 CLI。把这幅图抽象一下可以看成五个层次。最上面是界面层Interface Layer包括各种聊天通道Slack、iMessage、Discord、Teams、LINE、Matrix、WebChat 等、CLI 命令openclaw agent ...、openclaw message ...、openclaw gateway ...以及 Web 控制台和 WebChat。中间是控制平面也就是 Gateway。它负责统一管理会话、通道连接、Agent 配置、技能、Cron、Webhooks、Nodes 状态这些东西。往上它暴露 WebSocket/HTTP API、配置接口和 UI往下它驱动 Agent Runtime、Skills、Nodes、Browser。再往下是智能体运行时Agent Runtime按「会话 Agent 配置」维护与模型的对话状态负责提示词构造、工具调用、输出分块对 Gateway 暴露一个「我能处理这条消息」的接口。然后是执行与扩展层。Skills 是高层任务逻辑做整理邮件、管理 Todo、拉取报表这类事情。Nodes 是 macOS/iOS/Android 等实际执行环境可以跑脚本、操作系统功能、采集多模态数据。Browser 是专用浏览器容器支持截图、DOM 操作、表单提交、文件上传下载。最底下是持久化与集成设施——存储 Session、消息历史、配置、审计日志以及与外部系统邮箱、日历、GitHub、云服务的 API 集成。从上到下是「从人到机器」从下到上是「从执行结果回到人」。接下来我们按照消息从上往下流、再从下往上流回来的顺序对这些层做更细一点的拆解。3.2 Gateway控制平面的职责和边界3.2.1 为什么需要一个「本地控制平面」许多早期的 AI 助手项目一开始只是一个 CLI 帮你发 HTTP 请求到模型 API再加几个简单脚本读写本地文件、调用浏览器自动化工具。这种设计一开始简单但当你想同时管理多个聊天通道、支持多用户或多会话隔离、让不同的 Agent 共享底层资源但又互相隔离、再加上 Cron、Webhooks、Nodes、Browser 等异步和长期任务……没有一个统一的「大脑」就很难控制住了。Gateway 的设计思路就是把这些「调度与治理」的职责集中到一处。它知道现在有哪些活跃会话、谁在说话、和谁说它管理着哪个通道在线、哪个掉线、速率如何它负责把消息路由给正确的 Agent它清楚有哪些技能可用、各自的权限和配置它编排 Cron 作业、Webhooks、Gmail Pub/Sub 这些自动化任务你还可以通过 Web 控制台和 CLI 随时观察它的状态、调整配置、停用通道或技能。3.2.2 Gateway 不做什么为了保持角色清晰Gateway 刻意不做几件事。它不直接调用大模型 API——这由 Agent Runtime 统一负责。它不直接编码每个业务场景的逻辑——这放在 Skills 里更合适。它也不直接和所有外部服务打交道——邮箱、CRM、云服务等入口通常通过 Skills 或 Nodes/Browser 来封装。你可以把 Gateway 看成一个很克制的中控它知道谁能做什么、什么时候该让谁上场但它自己只做必要的调度和治理工作。3.3 Agent Runtime思考与决策的「大脑」3.3.1 核心问题一条消息如何变成一系列「动作」当 Gateway 把一条消息分配给某个 Agent Runtime 时Runtime 要回答的问题是这条消息想表达什么意图需要查哪些上下文是否要调用某个技能或工具如果需要按什么顺序调在调用前后需不需要问用户一些澄清性问题什么时候任务算完成了怎么向用户汇报结果这些问题加在一起就是所谓的「思考与决策」过程。具体实现上Agent Runtime 通常会管理与模型的对话轮次和系统提示词包含 Agent 的 persona、责任范围、安全边界等把 Gateway 提供的「当前消息 Session 上下文」转换成模型的输入根据模型的输出决定是否发起工具调用调用之后再把结果送回模型生成最终回复或者进一步动作。3.3.2 为什么要把 Runtime 单独抽出来你完全可以把所有逻辑都写在 Gateway 里但那样 Gateway 会迅速膨胀成一个巨无霸复用 Runtime 到其他场景也很困难比如单机实验、IDE 插件、其他项目想在不动 Gateway 的前提下演进 Agent 的思考能力就更难了。把 Runtime 抽成一个清晰的子系统之后Gateway 只需要知道怎么把消息交给 Agent Runtime、怎么接收结果就行了。Agent Runtime 可以独立演进、替换甚至并存多种不同策略。将来要在别的平台复用 Runtime 逻辑也只需要适配其输入输出。在第 5 章我们会更细地拆解 Agent 抽象在第 10 章会看到 Runtime 参与一条消息处理的全过程。3.3.3 Workspace 文件用 Markdown 定义 Agent 的「灵魂」Agent Runtime 在构造系统提示词时会自动把~/.openclaw/workspace/目录下三个特殊 Markdown 文件的内容注入进去AGENTS.md控制 Agent 的职责范围SOUL.md控制性格语气TOOLS.md控制工具使用规范。这三个文件让每一个 OpenClaw 实例都可以被「人格化定制」而无需改一行代码——你只需要用自然语言告诉它该怎么做。第 5 章会详细介绍每个文件的格式和写法。3.4 Channels把几十种聊天平台塞进一套抽象里3.4.1 多通道的本质从 Slack 到 Discord再到 iMessage、LINE不同平台之间的差别主要在认证与连接方式、消息格式和能力、速率限制和错误模型这几个地方。但对 Gateway 来说一条入站消息本质上只需要几件信息来自哪个通道、来自哪个对端、正文是什么、关联的会话 ID 或者足以推断会话的元数据。Channels 层的职责就是各自用对应 SDK 和外部聊天平台打交道把外部事件转换成内部统一的InboundMessage结构把OutboundMessage转换回各自平台要求的格式处理掉平台差异。3.4.2 DM 策略与安全缺省OpenClaw 默认比较保守——未经明确配对的陌生人 DM 不会被 Gateway 直接处理需要你通过 CLI 显式批准。部分通道可以配置 open 模式但doctor命令会对此发出风险提示。多通道不仅意味着多入口也意味着多条潜在攻击路径需要统一策略来守门。第 14 章会专门讨论安全模型。3.5 Nodes 与 BrowserOpenClaw 的「身体」与「眼睛」3.5.1 Nodes把设备变成可远程控制的执行环境Node 是 OpenClaw 对「设备」的抽象。macOS 桌面端可以作为一个 Node提供系统通知、文件访问、应用控制、摄像头和屏幕采集等能力iOS 和 Android 客户端也可以作为 Node提供移动端的传感器和交互通道。Node 和 Gateway 之间通常通过 WebSocket 或自定义通道保持长连接。Gateway 可以向 Node 下发指令比如「播放一段 TTS」「截一张屏」Node 把执行结果以统一格式回传 Gateway可能还会转交给 Agent 或 Skills 进一步处理。3.5.2 Browser一台可控的专用浏览器Browser 工具一般不直接控制你日常用的 Chrome而是启动一个专用的浏览器实例通过 DevTools 协议或类似机制进行页面操作。当 Agent 决定要执行「打开 Gmail 收件箱筛选某类邮件并归档」时它可能走 API 技能Gmail API OAuth也可能走 Browser 自动化打开 Gmail 网页模拟人手工操作。具体走哪条路要看你在 Skill 中怎么配也可能是模型在 Runtime 中按上下文动态选的。3.6 贯穿案例从 Slack 一句「清空收件箱」到 Gmail 真正被整理接下来用一个完整案例把上面的这些组件串在一条时间轴上。假设你已经完成了 Onboarding配好了模型绑定了 Slack 通道安装并授权了一个 Gmail 管理的 Skill。3.6.1 场景描述你在 Slack 上对 OpenClaw 说「帮我清空一下收件箱里今天的 GitHub 通知顺便给我一个总结。」你期待的结果是所有来自 GitHub 的新邮件被归档或移动到某个标签OpenClaw 在 Slack 里回复一条「已经处理了 N 封邮件大致内容如下」。3.6.2 时序线文字版大致的时序流程是这样的。Slack App 收到你的消息事件Channel 适配器把它转成内部的InboundMessage记录通道类型、peer ID、文本内容、时间戳然后通过既有连接推送给 Gateway。Gateway 根据 channel peer 查找对应的 Session没有就创建确定当前绑定的 Agent把消息和 Session 上下文封装成请求发给 Agent Runtime。Runtime 读取当前消息和上下文你之前可能和它讨论过邮箱偏好构造提示词告诉模型当前可用的工具包括 Gmail 管理 Skill。模型推理后给出一个大致计划先调 Gmail Skill 查询今日来自 GitHub 的通知邮件然后对这些邮件执行归档操作最后汇总结果生成一段简要说明。Runtime 把「调用 Gmail Skill」的指令通过 Gateway 转给 Skill 管理器。Gateway 检查权限找到对应 Skill调用它。Gmail Skill 使用你在 Onboarding 时配的 OAuth 凭据调用 Gmail API搜索、归档邮件整理出处理结果返回。Runtime 拿到结果后再交给模型附上原始用户意图模型生成一段面向用户的自然语言总结——「今天共有 17 封来自 GitHub 的通知主要涉及 3 个仓库的 PR 和 Issue我已经全部归档并按仓库打上了标签。」Gateway 把回复生成为OutboundMessageSlack Channel 适配器转成 Slack 格式发出去你在聊天窗口看到结果。Session 记录这次对话的问与答审计日志记下一次 Gmail Skill 调用的高风险操作。3.6.3 这条线索在本书中的作用这条时序线会在后续多次出现但每次关注的角度不同。在第 4 章我们关注一条消息是如何映射/创建会话的Session 中存了哪些状态。在第 5 章我们关注 Agent 的 persona、工具列表、安全边界是怎么配的Runtime 怎么组织提示词。在第 6 章我们关注 Slack 适配器如何标准化外部事件、出站消息如何处理平台差异。在第 7 章我们想想如果你没有启用 Gmail API 而是选了 Browser 自动化这条线会怎么变。在第 10 章我们会把这里的文字版时序图变成「半源码版」用接近真实的 TypeScript 接口与函数名走一遍完整调用链。3.7 小结本章的重点不是把每个组件讲细而是让你有一张清晰的心智地图知道 OpenClaw 的主要构件和数据流向用一个具体的邮件整理案例把地图上的节点和连线串起来为后续章节埋下一条可以反复回到的「主线」。接下来在 Part II 里我们会从这条主线中摘出几个关键节点分别放大来看——先是「会话与身份」再是「Agent 抽象」接着是「Channels」最后是「Nodes 与 Browser」。每一章都会回到本章的这条时序线用更细的层级把它拆开。