OpenClaw：介绍与定位
目录
- 一句话定义
- 术语对齐：自托管、Gateway、助手
- 产品边界：擅长方向（逐项说明）
- 产品边界：不擅长与必须补全的方向
- 能力分层：用一张流程图串起来
- 与「普通聊天机器人」的差异
- 关键能力导读（附原文入口）
- 多 Agent、语音与 Canvas：先知道存在，再决定启用
- 和本知识库其他文章的关系
- 原文链接速查
一句话定义
OpenClaw 是自托管的个人 AI 助手：你在自己控制的设备或服务器上运行 Gateway（控制面），通过统一会话与工具体系，把模型能力落到「能长期在线、能多通道触达、能调用工具」的实际体验上。官方仓库描述为 Personal AI assistant, any OS, any platform，见 README 开篇。
把这句话拆开，其实包含三个承诺：所有权（你的机器）、可达性（多渠道）、可执行性（工具与工作区）。缺少其中任意一个，体验都会迅速退化成「又一个聊天窗口」：没有自托管就没有数据与运行时的可控感；没有多渠道就只剩单一入口；没有工具与工作区，模型只能输出文本，无法稳定完成真实工作。
术语对齐：自托管、Gateway、助手
自托管到底意味着什么
自托管不是「安装在本机」这么简单，它意味着你对以下事项负责：
- 运行时可用性：机器休眠、网络断开、证书过期、磁盘满，都会直接变成「助手不可用」。
- 密钥与配置：API Key、OAuth、渠道 token 都在你侧；泄露路径包括配置文件、备份、日志与截图。
- 升级与兼容：OpenClaw 迭代节奏快，升级可能引入行为变化；你需要阅读 Updating 并在升级后跑
openclaw doctor。
Gateway 不是“聊天服务”
Gateway 是控制面：把渠道事件、会话状态、工具调用与策略串起来。官方 README 明确说 Gateway 只是控制面，产品体验在助手本身。因此评估 OpenClaw 时，如果你只测「Gateway 进程是否启动」，会漏掉真正决定体验的东西：会话是否正确、工具是否越权、工作区是否把长期规则写清楚。
“助手”与“模型”
用户口语里的「助手」往往混同于「某个大模型」。在工程上建议区分：
- 模型：提供语言与推理能力，但本身不负责渠道、工具与持久化策略。
- 助手（OpenClaw 这条路径）：模型 + Gateway + 工具 + 工作区/技能 + 你的运维策略。
产品边界：擅长方向（逐项说明）
多渠道统一
现实里很多人同时在 Telegram、Slack、Discord、企业 IM 里工作。若每个渠道单独做一个 bot，你会重复维护：鉴权、消息格式、命令解析、日志与告警。OpenClaw 的路线是把它们纳入统一的路由与会话语义（支持列表以 Channels 索引 为准）。
落地时你要意识到：渠道差异不会消失——@ 规则、线程、富文本、文件上传限制都不同。统一的是「你的助手逻辑与工具策略」，不是「所有渠道表现完全一致」。
常驻与自动化
个人助手的关键体验往往是「随时能找得到」。OpenClaw 通过 onboard --install-daemon 等路径把 Gateway 以守护进程方式运行（README Install 段落），并结合 Cron、Webhooks 等自动化能力（见 Automation 相关索引）。
落地含义：常驻带来便利，也带来风险——进程长期在线意味着配置错误会被放大；自动化意味着无人值守时要更严格的工具与入站策略。
可扩展工具链
OpenClaw 把浏览器、Canvas、Nodes、Sessions 等能力纳入工具体系（见 Tools）。这决定了两件事：
- 能力上限：没有工具，模型只能“说”；有工具，才能“做”。
- 风险上限：工具越多，越需要白名单、沙箱与审批（见 Security 与 README Security model）。
产品边界：不擅长与必须补全的方向
多租户 SaaS 模板
OpenClaw 的默认叙事偏 个人/单用户助手。若你要做 SaaS（多组织、多计费、多隔离），需要补齐：
- 租户隔离：数据面、配置面、密钥面、日志面。
- 审计与合规：谁改了什么配置、谁批准了 pairing、哪些工具被调用。
- 经济模型：token 成本、渠道费用、运行机器成本。
本知识库可以提供工程清单，但不能替你完成商业与法务设计。
“安装即合规”
官方对 DM 入站的安全默认很清晰：把入站 DM 当不可信输入，并提供 pairing/白名单等机制（README Security defaults，详见 Security）。但合规还包括数据分级、留存、导出与组织流程——这些必须由使用方定义。
替代完整企业安全体系
沙箱、远程访问、反向代理、容器化都属于“系统工程”。OpenClaw 提供能力与文档（例如 Docker sandboxing），但你仍要做威胁建模与运维演练。
能力分层：用一张流程图串起来
下面用 Mermaid 把「用户消息如何穿过 Gateway、落到工具与工作区」画成一条可读路径。注意：这是教学抽象，类名、RPC 与内部模块请以 Architecture 与 Agent 为准。
读这张图时建议你在心里回答四个问题（后面安装与实战篇会反复用到）：
- 入站身份：这条消息来自谁？是否已完成 pairing / 白名单？
- 会话归属：落在哪个会话与哪个 agent/workspace？
- 工具边界：本轮允许调用哪些工具？是否需要沙箱？
- 出站回传：回复走哪个渠道？是否需要节流或二次确认？
与「普通聊天机器人」的差异
很多团队第一次接 IM，会写一个「Webhook 收到消息 → 调一次大模型 → 回一条文本」的机器人。它也能工作，但与 OpenClaw 的典型取向差异在于：是否有统一控制面、是否把工具与沉淀当成一等公民。
| 维度 | 常见「一次性 Webhook 机器人」 | OpenClaw 的典型取向 |
|---|---|---|
| 运行时形态 | 常是请求触发、无统一会话控制面 | Gateway 常驻，统一会话、事件与工具 |
| 工具与沉淀 | 往往需要自研胶水层 | Tools / Skills / Workspace 有明确文档与路径 |
| 安全默认 | 依平台而异，容易忽略 DM 风险 | 文档强调 DM 不可信 与 pairing 默认（见 README Security defaults） |
| 客户端扩展 | 多为单一渠道往返 | 可选 macOS/iOS/Android 节点、Canvas 等（以官方平台文档为准） |
关键能力导读（附原文入口）
下表用于「知道去哪查」，细节以官方页面为准：
| 能力主题 | 你在落地时要抓住什么 | 原文入口 |
|---|---|---|
| Gateway | 控制面职责、远程与日志 | Gateway |
| 渠道 | 各 IM 的配置差异与排障 | Channels |
| 模型 | provider、OAuth、failover | Models、Model failover |
| 安全 | DM 策略、工具权限、沙箱 | Security |
| 工具与技能 | 工具清单与 Skills 机制 | Tools、Skills |
| 内部概念 | Agent、Session、协议 | Agent、Session model、Gateway protocol |
多 Agent、语音与 Canvas：先知道存在，再决定启用
官方 README Highlights 还提到 Multi-agent routing、Voice Wake / Talk Mode、Live Canvas（A2UI） 等。建议你采用「两阶段策略」：
- 先跑通最小闭环：Gateway + 单一渠道 + 基础对话 + 最小工具集。
- 再按需启用增强能力：每启用一类能力，就同步更新安全评审与运维手册。
不要默认「全开」：每多一个能力，就多一个失败域与成本域。
和本知识库其他文章的关系
OpenClaw与开源Agent框架实践侧重 Agent 通用工程套路（规划、执行、记忆、评测）；本专题侧重 OpenClaw 这条产品路径（Gateway、渠道、工作区、安全默认）。- 进阶主题见本站 多 Agent 方案 与 上下文与记忆管理策略。
- 与 Hermes-Agent 并列时，可先读 Hermes README 的 Migrating from OpenClaw。