> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/openclaw_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/01_overview/1.1_what_is_openclaw.md).

# 1.1 OpenClaw 是什么

你可能用过 ChatGPT，对它的聪慧印象深刻。但当你真正想让它帮你“干完一件活”时——比如每天定时检查邮件、从中提取任务清单、整理后发送给团队——你会发现一个尴尬的现实：**模型再聪明，也需要一套能连接真实工具、管理复杂流程、处理各种意外的运行系统**。

**OpenClaw 就是这样一套本地优先的个人 AI 助手系统。**

更准确地说，OpenClaw 是运行在你自己设备或服务器上的个人 AI assistant；其中 **Gateway 只是控制平面**，负责把消息、会话、工具、节点和权限边界接进同一套运行环境。它不是单纯的开发框架，也不是一组 SDK，而是一套可直接运行、可持续交互、可连接真实工具的智能体产品。

## 1.1.1 “智能实习生”的比喻

想象你招了一个聪慧但完全陌生的实习生，要让他独立完成复杂工作，需要什么？

* **明确的身份认证**：“你是谁，你有权限访问哪些系统？”
* **可靠的工具与权限边界**：“你可以用哪些工具，哪些操作禁止（如删除数据库）？”
* **完整的上下文记忆**：“前面说过什么，现在的状态是什么，不要忘记细节。”
* **突发情况的应对**：“系统超时了该怎么办，重要操作前要不要先问一下？”
* **完整的操作日志**：“你干了什么、为什么这么做，万一出问题好追查。”

OpenClaw 的作用正是这样：**为 AI 智能体构建一个可控、可审计、可恢复的运行环境**。它不改变 AI 本身的聪慧程度，但让这份聪慧能够被安全地、可预测地用在真实业务中。

## 1.1.2 OpenClaw 解决的三个让人头疼的问题

### 问题 1：孤立的 AI 能力

大模型的基本交互模式是一问一答。用户提问 → 模型思考 → 返回答案 → 对话结束。整个过程中：

* 记忆有限且不可控——上下文窗口一满，早期指令就被“忘掉”
* 没有“手脚”——不能主动读文件、查数据库、调用真实 API
* 没有“边界”——你无法限制它删除重要数据、暴露机密信息

**OpenClaw 的解决方案**：

* 构建持久化会话（Session），让 AI 在多轮对话中保有连续上下文
* 提供工具系统（Tool），让 AI 调用真实的 API、Shell 命令、文件操作、浏览器
* 设置访问控制与黑白名单，确保 AI 只能做被授权的操作

### 问题 2：多渠道接入与身份混乱

你可能需要在 Telegram、WhatsApp、Slack、本地 Control UI Chat 等多个入口部署同一个智能体。这时的挑战是：

* 不同渠道的消息格式不同
* 用户身份如何在多个渠道间统一？
* 如何防止越权访问（用户 A 的数据被用户 B 看到）？
* 如何在任何渠道暂停、恢复、审核正在运行的任务？

**OpenClaw 的解决方案**：

* Gateway 网关统一接收来自多个渠道的消息，格式化成统一内部表示
* 聊天渠道通过 pairing / allowlist 等机制建立可信发送者关系；而手机、桌面端、摄像头等设备能力则通过独立的 node/device pairing 接入
* 运行时未配置时，直接消息仍可能回落到主会话；但当前 onboarding / quickstart 默认会写入更偏隔离的 `session.dmScope: "per-channel-peer"`，所以新安装通常不是“所有 DM 共用主会话”
* 如果需要进一步做多用户隔离，应结合 agent 路由与会话策略；`identityLinks` 的作用是把同一用户在多渠道的身份合并到同一会话，而不是做隔离拆分
* 集中式会话管理：无论从哪个渠道发来的请求，都由同一控制平面维护会话状态

### 问题 3：可靠性与可审计性缺失

当 AI 在生产环境中运行时，你需要：

* **容错能力**：如果模型超时、API 失败，是重试还是回退到备选方案？
* **成本管理**：多轮交互中 Token 消耗可能快速积累，导致账单意外增长
* **决策可追溯**：AI 做了什么决定、为什么这么做、结果是什么——全程有日志可查
* **人工介入口**：对关键操作（如删除、扣费）要求人工确认
* **故障恢复**：系统崩溃或中断时，任务可以从上一个完整状态恢复，而不是重新开始

**OpenClaw 的解决方案**：

* 控制平面实现故障恢复、超时管理、回退链路、熔断机制
* 用量观测与成本治理：内置用量视图和成本摘要，硬预算与告警依赖 provider 控制台、外部监控或插件治理
* 人在回路（HITL）门控：高风险操作前自动暂停，等待人工审批
* 完整的审计日志：每个决策、执行、成功/失败都有记录

## 1.1.3 OpenClaw 最适合什么场景

如果你的需求满足下列特征，OpenClaw 是理想的选择：

**完美契合的场景**：

* 需要多步推理与工具调用的任务（如“帮我总结邮件、提取行动项、发送给 Slack”）
* 需要跨多个渠道部署同一套智能体（Telegram + WhatsApp + 内部系统）
* 任务的输入输出格式多变，用硬编码规则容易出错
* 对可控性、可追溯性、安全性有强需求（运维、研究、内部自动化等）
* 希望在自己的设备或服务器上运行，强调本地优先与数据主权
* 能接受 CLI + 配置驱动的安装、调优和持续维护

**不太适合的场景**：

* 简单的一问一答对话 → 直接用 ChatGPT/Claude 就够了
* 编程助手需求 → Cursor 专门优化过，体验更好
* 业务流程完全规则化、不需要模糊推理 → Zapier/n8n 硬编码规则更高效
* 不能接受任何自部署成本 → 用 Dify/Coze 这样的云托管方案更方便

接下来，[1.2 节](/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/01_overview/1.2_scenarios_comparison.md)会用一张表详细对比 OpenClaw 与其他工具的区别，[1.3 节](/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/01_overview/1.3_concepts.md)会用一张图与一张表介绍五个核心概念。如果你迫不及待想动手，可以直接跳到[第二章](/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/02_setup.md)的安装与配置。