# 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)的安装与配置。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/01_overview/1.1_what_is_openclaw.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.