第 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 帮我整理了邮箱」，实际发生的是：
- OpenClaw 收到你的消息；
- OpenClaw 把消息 + 你的历史上下文 + 可用工具列表，打包成一个 API 请求，发给模型；
- 模型回复「我需要调用 Gmail 工具，查询未读邮件」；
- OpenClaw 在你本地 执行这个工具调用，拿到结果；
- 把结果再发给模型，模型说「已整理完毕，给你总结……」；
- 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 在本地帮模型「记笔记」：
- 对话历史存在本地：每次你和 OpenClaw 的对话，都被完整保存在本机的数据文件里；
- 自动摘要与修剪：当历史太长时，OpenClaw 会自动对旧对话做摘要压缩，保留关键信息，丢弃细节；
- 关键偏好持久化：你说过的「周末别打扰我」「GitHub 通知帮我归档」之类的偏好，会被提取存入长期记忆；
- 按需注入上下文：每次给模型发请求时，OpenClaw 会从本地记忆中检索出跟当前话题最相关的内容，拼到提示词里一起发送。
用一张简化的流程图来看：
远程模型 API <-> OpenClaw（本地） <-> 你
alt [模型要求调用工具]
发送消息
① 查本地记忆，找相关上下文
② 拼装提示词（系统人设 + 长期记忆 + 近期对话 + 工具列表 + 新消息）
③ HTTP 请求
④ 模型推理
⑤ 返回结果
⑦ 本地执行工具调用
⑧ 把工具结果再送模型
返回最终回复
⑨ 保存本次对话到本地记忆
关键点在于：模型本身没有记忆，记忆全在 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 的骨架。下面这张图展示了从用户到执行层的完整分层：
执行层：手脚与器官
模型 Provider
Agent Runtime 智能体运行时
Gateway 控制平面
Channels 通道层
用户与外部世界
HTTP 请求
返回结果
执行结果
执行结果
执行结果
👤 你
Slack
iMessage
Discord
CLI / Web UI
SlackAdapter
iMessageAdapter
DiscordAdapter
...更多适配器
Gateway 进程
Session 管理
Agent 路由
Cron / Webhooks
配置与状态
Agent Runtime
提示词构造
SOUL.md + 记忆 + 工具列表
工具调用决策
远程模型 API
Anthropic / OpenAI / Ollama
Skills
Gmail / Todo / CRM
Nodes
macOS / iOS / Android
Browser
专用浏览器实例
从外到内，大致可以这样理解：
- 用户与外部世界
- 你和你的同事/家人，通过 Slack、iMessage、Discord 等各种聊天 App 给 OpenClaw 发消息；
- 有时也会通过 CLI 或 Web 前端直接和它交互。
- Channels（通道层）
- 每一种聊天平台都有一个对应的「适配器」：负责连接官方 API、收发消息、处理各自奇怪的格式和限制；
- 这些适配器把外部世界五花八门的消息，统一转换成内部的标准事件。
- Gateway（控制平面）
- 所有来自 Channels 的事件，最终都会汇聚到本地运行的 Gateway 进程；
- Gateway 维护：会话（Session）、当前在线通道、已安装技能、定时任务、运行中的 Agent 等等；
- 它通过 WebSocket/HTTP 为 CLI、Web UI 和其他客户端提供统一入口。
- Agent Runtime（智能体运行时）
- 当 Gateway 判定一条消息需要某个 Agent 处理时，会把消息交给对应的 Agent Runtime；
- Runtime 负责和模型对话、组织提示词、发起工具调用（Skills/Browser/Nodes）、把中间结果流式返回给 Gateway。
- 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.mdMarkdown 文件（不是 TypeScript/JavaScript 代码）； - Skill 的工作方式是把说明文本注入 Agent 的提示词，由模型调用
bash命令来执行； - Skill 的加载、扫描和提示词注入逻辑在
src/agents/和src/gateway/agent-prompt.ts中实现。
- 仓库根目录有
在后续深入章节（尤其是第 8、10、11、14 章），我们会在介绍某个概念时，给出更具体的「可以从哪几个文件/模块看起」的建议，帮你把抽象概念和真实代码一一对上。