1.1 什么是 OpenClaw：个人 AI 助手的设计哲学
生成模型：Claude Opus 4.6 (anthropic/claude-opus-4-6) Token 消耗：输入 ~130,000 tokens，输出 ~12,000 tokens（本章合计）
OpenClaw 是一个运行在你自己设备上的个人 AI 助手。与 ChatGPT、Claude.ai 这样的云端服务不同，OpenClaw 的核心理念是：你的 AI 助手应该属于你自己——运行在你的机器上，连接到你已经在使用的消息平台，所有数据存储在你的本地磁盘。
用 OpenClaw 项目的 README 来说：
"If you want a personal, single-user assistant that feels local, fast, and always-on, this is it."
1.1.1 "本地优先"（Local-first）理念与传统 SaaS 的对比
在过去几年中，"Local-first"（本地优先）理念在软件工程领域逐渐兴起。这个概念最早由 Martin Kleppmann 等人在 2019 年的论文 "Local-first software: you own your data, in spite of the cloud" 中系统阐述。其核心主张是：
数据所有权：用户的数据应该存储在用户控制的设备上，而非第三方服务器
离线可用：软件应该在没有网络连接时仍能工作（至少部分功能）
低延迟：本地操作不需要网络往返，响应更快
隐私保护：敏感数据不需要离开用户的设备
OpenClaw 践行了这一理念。下表对比了 OpenClaw 与典型云端 AI 助手的区别：
运行位置
服务提供商的云服务器
你自己的设备（笔记本、服务器、VPS）
数据存储
提供商的数据库
本地文件系统（~/.openclaw/）
对话历史
提供商控制
本地 JSONL 文件，你可以直接读取
记忆机制
提供商的专有实现
纯 Markdown 文件（MEMORY.md）
消息入口
提供商的网页/APP
你已有的消息平台（WhatsApp、Telegram 等）
定制能力
有限的 GPTs/Gems
完全可编程的技能系统 + 源码级定制
成本模式
月费订阅
按 API 调用付费（或使用订阅 OAuth）
当然，OpenClaw 仍然需要调用云端的大语言模型 API（如 Anthropic Claude、OpenAI GPT）来进行推理——本地设备通常没有足够的算力来运行大模型。但关键的区别在于：控制平面是本地的。你的配置、对话记录、工作区文件、记忆——这些都在你的磁盘上，你可以随时查看、备份、迁移。
从源码的角度来看，OpenClaw 的数据目录结构清晰地体现了这一设计：
1.1.2 单用户设计（Single-user）：为什么不做多租户
OpenClaw 从一开始就被设计为**单用户（Single-user）**系统。这是一个有意的设计决策，而非能力上的限制。在 README.md 中，项目这样描述自己：
"The Gateway is just the control plane — the product is the assistant."
在多租户（Multi-tenant）系统中，一个服务实例同时服务多个用户。这要求系统解决数据隔离、访问控制、资源配额等一系列复杂问题。OpenClaw 选择单用户设计，带来了几个显著的简化：
信任模型简化：默认情况下，主会话（main session）中的工具拥有对宿主机的完全访问权限——因为用户就是机器的所有者。正如
README.md中的安全章节所述："Default: tools run on the host for the main session, so the agent has full access when it's just you."
会话模型简化：所有直接消息（DM）默认共享同一个主会话，提供跨设备、跨通道的对话连续性。你在 WhatsApp 上和助手说的话，在 Telegram 上也能接着聊。
配置简化：一个 JSON5 配置文件统管一切，不需要用户管理系统或权限层级。
部署简化：一台机器运行一个 Gateway 实例，不需要考虑水平扩展或负载均衡。
当然，这并不意味着 OpenClaw 完全不考虑多用户场景。当你的助手被配置为接收来自不同人的消息时（例如在群组中，或开放了 DM 白名单），OpenClaw 提供了沙箱机制来隔离非主会话：
非主会话中的 bash 命令会在独立的 Docker 容器中执行，确保不同来源的消息不会干扰宿主机或彼此。我们将在第 24 章详细讨论安全模型。
1.1.3 多通道统一收件箱
OpenClaw 最引人注目的特性之一是它的多通道统一收件箱（Multi-channel Inbox）。你不需要为每个消息平台部署一个单独的 Bot——一个 OpenClaw 实例就能同时连接到所有支持的平台：
核心通道（内置于 src/ 中）：
@whiskeysockets/baileys
src/whatsapp/、src/web/
Telegram
grammy
src/telegram/
Discord
@buape/carbon + discord.js
src/discord/
Slack
@slack/bolt
src/slack/
Signal
signal-cli
src/signal/
iMessage (legacy)
原生 macOS imsg
src/imessage/
WebChat
Gateway 内置
src/channels/web/
扩展通道（位于 extensions/ 中，可选安装）：
Microsoft Teams
extensions/msteams/
BlueBubbles (iMessage)
extensions/bluebubbles/
Matrix
extensions/matrix/
Google Chat
extensions/googlechat/
Nostr
extensions/nostr/
Twitch
extensions/twitch/
Zalo / Zalo Personal
extensions/zalo/、extensions/zalouser/
LINE
extensions/line/
飞书 (Feishu/Lark)
extensions/feishu/
Mattermost
extensions/mattermost/
这种设计的核心思想是：消息通道只是传输层，AI 助手才是产品。无论消息从哪个通道进来，它们都被规范化为统一的内部格式，路由到同一个 AI Agent 进行处理，然后回复也通过相应的通道发回。
从用户的视角来看，这意味着你可以：
早上在 WhatsApp 上让助手帮你查日程
下午在 Slack 的工作频道中让它帮你总结文档
晚上在 Telegram 上让它帮你记录想法
而这些对话共享同一个上下文——助手"记得"你在不同平台上说过的话
从工程的视角来看，实现这一能力的关键在于 OpenClaw 的通道适配器（Channel Adapter） 架构。每个通道实现一个统一的接口，负责：
入站：监听通道消息，转换为 OpenClaw 内部格式
出站：接收 OpenClaw 的回复，转换为通道特定的格式发送
能力声明：告知 Gateway 该通道支持哪些功能（图片、音频、Markdown、反应、线程等）
我们将在第 11-13 章深入分析这一适配器架构的实现。
到这里，你应该对 OpenClaw 的核心理念有了初步了解。简而言之：
本地优先：数据和控制在你手中
单用户：为个人助手场景优化，降低复杂度
多通道：一个助手，所有平台
开源可定制：MIT 许可证，源码完全开放
接下来，让我们从架构的角度来看看这一切是如何组织在一起的。
Last updated