第 1 章 OpenClaw 是什么？它和 ChatGPT 有什么不一样？

1.1 从「聊天机器人」到「会干活的数字同事」

过去几年，我们经历了几波 AI 工具的浪潮：

• 先是「对话式搜索」：ChatGPT、Claude、文心一言……
• 然后是「写代码、写文案」：Copilot、Cursor、各种 AI IDE 插件；
• 接着是「智能客服/机器人」：接入企业微信、Slack、网站客服的各种 Bot。

这些东西的共同点是：主要还停留在「说」的层面。

• 它们可以帮你理解问题、生成文本或代码；
• 但要真正触达你的世界——你的文件、邮箱、日程、服务器、家里的设备——往往需要你手动复制粘贴结果，再去点各种按钮、跑各种脚本。

这中间存在一个巨大的「最后 10 米」问题：
从「AI 想得明白」到「事情真的被做完」，差了一堵墙。

OpenClaw 试图干的事，就是在你和 AI 之间，把这堵墙拆掉，让 AI 真的动手：

• 可以访问你的邮箱，帮你整理和回复；
• 可以操作你的浏览器，帮你登录、填表、查资料；
• 可以在你的电脑上跑脚本、读写文件、开关设备；
• 可以定时在后台悄悄做事，不打扰你。

你可以把它想象成一个：

「坐在你电脑前、登录了你账号、能使用你所有工具的一位远程同事，但 TA 是 AI。」

1.2 OpenClaw 的核心理念：本地优先、开放、可黑（Hackable）

在深入技术之前，先说说这个名字。「Claw」是龙虾或螃蟹的螯——最有力的那只钳子。OpenClaw 的创始人选择这个词，因为项目的核心理念就是让 AI 不只是「说得好」，而是真的「抓得住」：抓住你的文件系统、邮箱、浏览器、终端，把事情做完。名字里的「Open」则强调完全开源。Logo 也是一只卡通龙虾，社区里大家习惯叫它「那只龙虾」。

从官网和 README 中，可以提炼出三个关键理念：

• 本地优先（Local-first）
  OpenClaw 默认跑在你的设备上：Mac、Windows、Linux 都可以。
  你的配置、技能、上下文记忆都在你掌控的环境里，外部服务只是被当作「模型提供商」或「远程 API」。

• 开放
  OpenClaw 是开源的，你可以：

  • 直接阅读源码，理解安全模型、权限边界；
  • Fork 一份，定制自己的版本；
  • 在社区生态中共享、复用他人写好的 Skills。

• 可黑（Hackable）
  作者和社区反复强调的一点是：你应该能随时「拆开」它。

  • CLI 是第一等公民，可以从终端操作几乎所有能力；
  • 配置文件、Skills、连接方式都可以用文本和代码来描述和修改；
  • 甚至有专门的「Hackable 安装方式」，鼓励你从源码开始玩。

这三点让 OpenClaw 和很多云端封闭的「AI 助手产品」有明显不同：
它更像一个开发者用的「个人 Agent 操作系统」，而不是一个最终形态的 SaaS。

1.3 OpenClaw、AI 模型与 Provider：搞懂三者关系

很多第一次听说 OpenClaw 的人会问：

• 「它和 ChatGPT 什么关系？自己带了一个 AI 模型吗？」
• 「听说它能有无限长期记忆，大模型的上下文窗口不是有限制吗？」
• 「怎么就能让 AI 变成某种性格？」

这一节专门回答这些问题。如果你已经理解 LLM API 的工作方式和 Agent 框架的基本原理，可以跳过。

1.3.1 OpenClaw 不是 AI，而是 AI 的「经纪人」

最重要的一点，先说清楚：

OpenClaw 本身不包含任何 AI 模型。
它是一个本地运行的编排层，负责把你的消息、上下文、记忆、工具描述打包好，发给远程（或本地）的大模型 API，再把模型的回答拿回来执行。

打个比方：

• 大模型（Claude、GPT、DeepSeek……）是一个极其聪明但「没有身体、没有记忆、每次见面都失忆」的专家；
• OpenClaw 是这个专家的经纪人：帮它记笔记、带它去现场、把工具递到它手里、替它挡掉不该接的活。

所以当你说「OpenClaw 帮我整理了邮箱」，实际发生的是：

1. OpenClaw 收到你的消息；
2. OpenClaw 把消息 + 你的历史上下文 + 可用工具列表，打包成一个 API 请求，发给模型；
3. 模型回复「我需要调用 Gmail 工具，查询未读邮件」；
4. OpenClaw 在你本地 执行这个工具调用，拿到结果；
5. 把结果再发给模型，模型说「已整理完毕，给你总结……」；
6. OpenClaw 把最终回复发回给你的聊天窗口。

整个过程中，模型只负责「想」，OpenClaw 负责「记」和「做」。

1.3.2 Provider：模型从哪来

OpenClaw 支持多种模型提供商（Provider），你可以在安装时选择：

Provider	说明
Anthropic	Claude 系列，OpenClaw 默认推荐
OpenAI	GPT 系列
Google AI	Gemini 系列
Ollama / LM Studio	本地运行的开源模型（完全离线）
其他兼容 API	任何提供 OpenAI 兼容接口的服务

对 OpenClaw 来说，Provider 就是一个 HTTP API 端点 + 一把 API Key，仅此而已。你甚至可以同时配置多个 Provider，设定优先级和 Failover 策略（详见第 16 章运维部分）。

1.3.3 「无限长期记忆」是怎么实现的

大模型本身有上下文窗口限制（比如 128K token），而且每次 API 调用之间并不共享状态——模型「看完即忘」。

那 OpenClaw 的「长期记忆」是怎么来的？答案是 OpenClaw 在本地帮模型「记笔记」：

1. 对话历史存在本地：每次你和 OpenClaw 的对话，都被完整保存在本机的数据文件里；
2. 自动摘要与修剪：当历史太长时，OpenClaw 会自动对旧对话做摘要压缩，保留关键信息，丢弃细节；
3. 关键偏好持久化：你说过的「周末别打扰我」「GitHub 通知帮我归档」之类的偏好，会被提取存入长期记忆；
4. 按需注入上下文：每次给模型发请求时，OpenClaw 会从本地记忆中检索出跟当前话题最相关的内容，拼到提示词里一起发送。

用一张简化的流程图来看：

关键点在于：模型本身没有记忆，记忆全在 OpenClaw 这一侧。 模型每次只是在回答「一个信息量很丰富的提问」，而 OpenClaw 负责让每个提问都包含足够的背景。

这就是为什么 OpenClaw 可以做到「跨天、跨周甚至跨月」的上下文连贯——不是因为模型记住了，而是 OpenClaw 每次都把该记的东西重新告诉它。

1.3.4 「人格化」与「性格」是怎么做到的

当你觉得 OpenClaw 「有性格」——比如说话风格像一个靠谱的技术同事，或者像一个温和的私人助理——背后的机制其实很简单：

系统提示词（System Prompt）注入。

OpenClaw 在你的本地有一个工作区目录（~/.openclaw/workspace/），里面有几个关键的 Markdown 文件：

• SOUL.md：定义 Agent 的「灵魂」——说话风格、性格特征、价值观；
• AGENTS.md：定义有哪些 Agent 角色、各自负责什么；
• TOOLS.md：定义工具使用偏好与安全规则。

每次 OpenClaw 向模型发送请求时，都会把这些文件的内容拼装成系统提示词的一部分。模型收到的第一段话就是在被告知「你是谁、你该怎么做」。

举个极简的例子，如果你的 SOUL.md 里写的是：

你是一个经验丰富的技术同事，说话简洁、不废话。
遇到不确定的事情，优先确认而不是猜测。
用中文回复，技术术语保留英文。

那么每次请求模型 API 时，OpenClaw 发给模型的大致是：

系统提示词: "你是一个经验丰富的技术同事……"
长期记忆摘要: "用户偏好：周末少打扰；GitHub 通知归档……"
最近 5 轮对话: [...]
可用工具: [Gmail, Browser, Shell, ...]
用户新消息: "帮我看看今天有什么重要邮件"

模型拿到这些信息后，就会按照你设定的人格来回答和行动。换一套 SOUL.md，模型的表现风格就会完全不同——但 OpenClaw 的代码一行都不用改。

1.3.5 一句话总结

角色	负责什么	在哪里运行
OpenClaw	记忆、调度、工具执行、人格注入、安全管控	你的本地机器
Provider / 模型	理解语义、推理、生成回复、决定调什么工具	远程 API（或本地 Ollama）
聊天平台	收发消息的「传话筒」	各平台服务器

理解了这一层关系之后，后面所有的「Session」「Agent Runtime」「Skills」「Channels」就都有了着力点：它们都是 OpenClaw 这个「经纪人」身上的不同器官，各自负责一块具体工作。

1.4 功能速览：多通道聊天、浏览器控制、系统访问、后台任务、技能平台

从功能角度，OpenClaw 可以被粗略拆成几块（后面章节会详细展开）：

• 多通道聊天入口（Channels）

  • 支持 Slack、iMessage、Discord、Google Chat、Teams、Matrix、Feishu、LINE、IRC、Mattermost、Twitch、WebChat……
  • 你和朋友/同事可以在任何一个自己熟悉的聊天平台里，像跟真人一样跟它说话；

• Gateway 控制平面（Gateway）

  • 统一管理 Session、配置、通道状态、心跳、Cron、Webhooks；
  • 提供 Web 控制台和 WebChat 前端；
  • 是所有 Agent、Skills、Nodes 的「中枢」。

• Agent 运行时（Agent Runtime）

  • 管理和模型之间的对话、工具调用（tool streaming）、分块输出（block streaming）；
  • 支持多 Agent 配置：可以为不同场景（代码、生活、运营）定制不同人格和能力。

• Nodes & Browser

  • Nodes 代表各种「有手有脚的设备」：Mac/iOS/Android 等；
  • Browser 工具可以启动和控制专用浏览器，截图、交互、上传下载、执行复杂网页操作。

• Skills 平台

  • 类似应用商店：有官方自带（bundled）、托管（managed）、工作区自定义（workspace）三种；
  • 你可以装别人写好的，也可以在它的帮助下写出自己的技能。

• 自动化与后台任务

  • Cron 任务、Webhooks、Gmail Pub/Sub 等，让 OpenClaw 可以在你不在线的时候替你「守着」；
  • 可以实现每日简报、异常监控、自动整理文档等常驻任务。

1.5 从官网与 README 解读产品定位

官网用大量用户反馈来传达一个核心感受：「这不像一个传统软件，更像一个有生命的伙伴。」

• 人们说它「在后台运行公司」；
• 说「这才是个人 AI 应该有的样子」；
• 说「感觉像二十年前第一次装上 Linux」：自由、可控、可以无限折腾。

而 README 的开头则更技术向一些：

• 它强调 Gateway 是控制平面；
• 强调 Node ≥ 22、npm/pnpm 安装方式、不同发布通道（stable/beta/dev）；
• 列出一长串已经实现的功能模块与文档链接。

综合来看，OpenClaw 的定位可以概括为：

一个以开发者为核心用户的本地 AI 助手运行时，兼顾「开箱即用」和「极致可扩展」。

1.6 本书路线图与阅读建议（按读者画像）

这本书会沿着这样的节奏展开：

• Part I：帮你站在「产品和用户」视角，看清 OpenClaw 的整体样子；
• Part II：梳理核心抽象和数据模型：Session、Agent、Channel、Node；
• Part III：深入 Gateway 与运行时的实现，从仓库结构和调用链入手；
• Part IV：聚焦 Skills 与自动化，教你写出自己的技能和工作流；
• Part V：从安全、部署、运维角度看「如何在真实环境长期跑 OpenClaw」；
• Part VI：做一次架构复盘，讨论哪些模式值得你在其他项目中复用。

针对不同读者：

• 个人玩家：可以快速扫一遍 Part I → 重点看 Part II 的概念 → 直接跳到 Part IV 第 11、13 章，按案例写出第一个 Skill；
• 集成工程师：在上述基础上，多花时间啃 Part III 的第 8、10 章，搞清消息链路再下手改代码；
• 架构/平台负责人：建议完整阅读，再结合自己团队的现有系统，思考第 14、15、16、17 章提出的那些权衡。

1.7 架构鸟瞰：单机上的「个人 Agent OS」

在真正展开详细架构（第 3 章）之前，我们先粗略勾勒 OpenClaw 的骨架。下面这张图展示了从用户到执行层的完整分层：

从外到内，大致可以这样理解：

1. 用户与外部世界

   • 你和你的同事/家人，通过 Slack、iMessage、Discord 等各种聊天 App 给 OpenClaw 发消息；
   • 有时也会通过 CLI 或 Web 前端直接和它交互。

2. Channels（通道层）

   • 每一种聊天平台都有一个对应的「适配器」：负责连接官方 API、收发消息、处理各自奇怪的格式和限制；
   • 这些适配器把外部世界五花八门的消息，统一转换成内部的标准事件。

3. Gateway（控制平面）

   • 所有来自 Channels 的事件，最终都会汇聚到本地运行的 Gateway 进程；
   • Gateway 维护：会话（Session）、当前在线通道、已安装技能、定时任务、运行中的 Agent 等等；
   • 它通过 WebSocket/HTTP 为 CLI、Web UI 和其他客户端提供统一入口。

4. Agent Runtime（智能体运行时）

   • 当 Gateway 判定一条消息需要某个 Agent 处理时，会把消息交给对应的 Agent Runtime；
   • Runtime 负责和模型对话、组织提示词、发起工具调用（Skills/Browser/Nodes）、把中间结果流式返回给 Gateway。

5. Tools / Skills / Nodes / Browser（「手脚」与「器官」）

   • Skills：围绕特定任务或系统（如 Todo 管理、邮箱、CRM）的扩展逻辑；
   • Nodes：macOS/iOS/Android 等执行环境，可以控制本机应用、摄像头、屏幕；
   • Browser：专用浏览器实例，可以独立于你日常浏览活动执行自动化操作。

用一句话概括：

Channels 把外部世界接进来，Gateway 负责「分发和管控」，Agent Runtime 负责「思考和决策」，Skills/Nodes/Browser 负责「真正动手」。

在后面的章节里，我们会一层层把这张示意图拆开：
从「一条消息」出发，顺着它在这些组件间的流动轨迹，把架构和源码一起讲清楚。

1.8 源码索引约定：从概念跳到代码的大致路径

从这一章开始，书中提到的每一个核心概念，都会尽量给出「大致可以去看哪一块代码」的指引。由于 OpenClaw 本身在快速演进，具体文件名和路径可能会有调整，这里只给出模块级别的导向：

• Gateway 相关代码

  • 主要集中在仓库的 src/ 与 apps/ 下面：负责启动 Gateway 进程、管理 WebSocket/HTTP 接入、维护 Session 和通道状态。
  • 当你在书里看到「Gateway 如何路由一条消息」这类描述时，可以在源码中搜索 Gateway 入口和路由相关的模块来比对。

• Channels（通道适配器）相关代码

  • 每种聊天平台是 src/ 下的独立顶层目录：src/slack/、src/discord/、src/imessage/ 等；
  • 适配器里包含：连接初始化、事件监听、消息入站/出站的转换逻辑，共享工具函数集中在 src/plugin-sdk/。

• Agent Runtime 与会话模型

  • 在源码中会有专门负责 Session、Agent 配置与调用链的模块；
  • 这些模块定义了「一条消息如何变成一次模型调用」「调用过程中如何接入工具」等核心逻辑。

• Skills 与插件系统

  • 仓库根目录有 skills/ 目录：每个 Skill 一个子目录，核心是一个 SKILL.md Markdown 文件（不是 TypeScript/JavaScript 代码）；
  • Skill 的工作方式是把说明文本注入 Agent 的提示词，由模型调用 bash 命令来执行；
  • Skill 的加载、扫描和提示词注入逻辑在 src/agents/ 和 src/gateway/agent-prompt.ts 中实现。

在后续深入章节（尤其是第 8、10、11、14 章），我们会在介绍某个概念时，给出更具体的「可以从哪几个文件/模块看起」的建议，帮你把抽象概念和真实代码一一对上。

下一篇 第 2 章 从安装到第一句“Hello“：快速体验 OpenClaw