这一章的目标不是教你背命令，而是先把“你到底在安装什么系统”这件事讲清楚。只有当你真正理解OpenClaw 是一套长期运行的个人 AI 系统，而不是一次性聊天页面时，后面关于Gateway、Dashboard、工作空间、记忆、渠道、自动化、日志与健康检查的动作才会连成一条主线。

1.1. 本章说明：范围、事实基线与阅读方式

本章是正式正文的起点，任务不是直接把安装命令一股脑抛给读者，而是先把“我要搭建的到底是什么系统、为什么要这样装、先后顺序为什么不能乱”讲清楚。整章内容遵循同一条事实基线：先采用官方当前推荐的最短成功路径完成最小闭环，再在这个闭环之上逐步补齐平台差异、工具链准备、模型入口、排障方法和后续扩展路线。写法上坚持先讲清“是什么、为什么、有什么用”，再进入“怎么做、怎么查、怎么排错”，目的就是让第一次接触命令行与自托管助手系统的读者也能跟得上。

1.1.1. 本部分的核心目标：让从未折腾过命令行的新手，也能完成真正可执行的准备工作

本部分不直接进入OpenClaw 的正式安装，而是先帮你完成一件更重要的事：把“安装 OpenClaw”拆成一组新手真正能落地的准备动作。你需要先知道自己究竟要用什么系统、在哪里输入命令、什么叫管理员权限、如何检查自己的环境是不是满足条件、如何安装 Node.js、npm、pnpm、Git、Python、Docker 这些会在后续频繁出现的基础工具。只有这些底层准备扎实了，后面进入 onboarding、Gateway、Control UI、Doctor、记忆、渠道、自动化时，你才不会每一步都像踩地雷。

1.1.2. 本章的阅读方式：先认知，再操作；先最小成功，再逐步升级

你在阅读这一部分时，请始终记住两个原则。

第一，先理解，再复制命令。

第二，先拿到最小成功，再做进阶扩展。OpenClaw 官方当前推荐的主线依然是：先把 Node 环境与 CLI 装好，再运行 onboarding，再验证 Gateway 与控制面板，而不是一上来就同时研究 Docker、源码、多个渠道、多个模型和复杂插件。官方 Getting Started 直接把“安装 OpenClaw”“运行 openclaw onboard --install-daemon”“执行 openclaw gateway status”“执行 openclaw dashboard”组织成最短可用路径；官方 Install 页面也把安装脚本列为首选方案，并明确指出 Windows 上强烈建议通过 WSL2 运行。

1.1.3. 本部分的事实基线：当前最重要的几条官方口径

在正式展开之前，你先记住四条最关键的当前事实。

第一，OpenClaw 官方当前推荐的安装主线仍然是安装脚本，而不是让大多数新手从源码开始。

第二，Node 24 是推荐运行时，Node 22 LTS 目前仍兼容，兼容基线写到 22.16 及以上。

第三，Windows 平台如果想要最顺手、最少踩坑的体验，优先使用 WSL2，而不是把“原生 Windows”当作默认路线。

第四，官方安装脚本在macOS 与 Linux（包括 WSL）上会优先确保 Node 与 Git 可用，其中 macOS 缺少 Homebrew 时会先处理 Homebrew，Linux 侧会按 apt、dnf、yum 路线处理 Node 24 与 Git 的安装。

1.2. 前奏：新手小白到底要准备什么

很多新手第一次接触OpenClaw，真正困扰他们的并不是 OpenClaw 本身，而是“我连命令行都不熟”“我不知道去哪里输入命令”“我不知道怎么用管理员权限”“我不知道我的电脑缺了什么”。因此，这一章真正要解决的，不是某一条安装命令，而是你进入 OpenClaw 之前的全部底座问题。

1.2.1. 不只是聊天，而是一套会长期运行的个人AI 系统

你必须先把认知摆正：OpenClaw 不是普通聊天框，而是长期运行的 AI 系统。它的核心不是“网页里能不能聊两句”，而是有没有 Gateway、有没有工作空间、有没有模型入口、有没有记忆、有没有渠道、有没有后台任务、有没有状态检查与修复手段。你把它当成简单聊天工具，就会在后面不断误判：为什么还需要看 Gateway，为什么还有 Doctor，为什么有那么多 Markdown 文件，为什么会涉及系统服务与端口。

真正的AI Assistant 与普通 Chatbot 最大的区别，恰恰是持续在线、连续记忆、多入口与主动工作能力。

1.2.2. 在准备阶段真正要解决的六个最小问题

你在本章需要解决的最小问题只有六个。

第一，我准备用哪一台设备来跑OpenClaw。

第二，我知道去哪里输入命令吗。

第三，我知道如何获取管理员权限吗。

第四，我知道如何查看系统版本、CPU、内存、磁盘、网络、端口这些基础信息吗。

第五，我知道如何安装Node.js、npm、pnpm、Git、Python、Docker 吗。

第六，我知道如何用最小动作验证这些工具是否安装成功吗。

1.2.3. 新手最容易犯的错，不是不会装，而是路线太多

第一次上手时，最危险的不是知识少，而是把安装脚本、npm、pnpm、Docker、源码、VPS、旧手机、树莓派、本地模型、多个聊天渠道、多个 Agent 全挤在同一次学习里。这样做几乎必然会把原本清晰的问题搅成一团。你现在真正需要的是：先把一台设备、一个终端、一个 Node 运行时、一种安装方式、一个模型入口和一条验证路径跑通。其余的一切，后面自有安排。多即是少，少即是多。

1.3. 搞清楚“入口”：终端、命令、路径、权限

对新手来说，最陌生的通常不是OpenClaw，而是“终端”这个世界本身。下面我们先把这些基础入口讲清楚。

1.3.1. 什么叫命令行、终端、Shell、控制台

你可以把“终端”理解为一个专门用于向电脑下达文本指令的窗口。你在这个窗口里输入的每一行命令，都是在告诉系统“请做某件事”。Shell 则是终端里真正解释这些命令的那层程序。例如，Windows 上常见的是命令提示符（cmd）、PowerShell 或 Windows Terminal；macOS 与 Linux 上常见的是 Terminal 里的 zsh、bash、fish 等。对新手来说，现在不必深究这些名字的全部差异，只需要先记住一句话：后面你看到的安装命令、检查命令、启动命令，绝大多数都不是在浏览器里输入，也不是在文档里点按钮，而是在终端里逐行执行。

1.3.2. 什么叫“管理员权限”或“提升权限”

电脑里有些操作只允许更高权限的用户执行，例如安装系统级软件、写入受保护目录、管理系统服务、修改防火墙、安装Docker Desktop、启用 WSL2、配置 systemd 服务等。Windows 上这通常叫“以管理员身份运行”；Linux 与 macOS 上更常见的是用 sudo 临时提升权限。你可以把它理解成：普通权限像住户，管理员权限像物业总控钥匙。不是所有事情都要用管理员权限，但遇到系统级安装与服务配置时，你必须知道怎么用。

1.3.3. 什么叫 PATH、当前目录、绝对路径与相对路径

这是新手高频混淆点。PATH 是系统用来搜索可执行程序的一组目录列表。你输入 node、git、python、npm 这些命令时，系统就是沿着 PATH 去找对应程序。当前目录，是你终端此刻所在的文件夹。绝对路径，是从磁盘根位置开始写清楚完整位置，例如 Windows 下某个盘符路径，或 Linux/macOS 下从根目录开始的路径。相对路径，则是相对于当前目录去写。理解这几个概念的实际意义在于：当你执行命令提示“找不到”“没有权限”“文件不存在”时，很多时候不是程序坏了，而是 PATH 没配好、目录站错了、路径写错了。

1.3.4. 什么叫“复制命令”和“真正执行命令”

新手常见误区是：在文档里看到了命令，就以为看懂了；或者复制以后没有按回车执行，就误以为电脑没反应。正确的动作顺序是：先打开对的终端，再把命令粘贴进去，再按回车执行，然后观察输出。安装与排错时，输出结果比命令本身更重要。因为你真正要看的不是“我有没有输入”，而是“系统怎么回应”。

1.4. 先建立系统认知，再谈下一步动作

如果你把OpenClaw 只看成一个“会回复消息的机器人”，你很快就会被大量术语淹没：模型、上下文、Token、API、会话、网关、工作空间、记忆、技能、渠道、守护进程、Cron、Heartbeat、Node、控制面板、配置文件、环境变量。真正让新手崩溃的，并不是某一条命令本身，而是缺少一张能把这些概念串起来的认知地图。因此，这个补充专题的目标不是让你背定义，而是把整套系统拆成你能拿来做判断的几个层次：脑子是什么，手脚是什么，记忆放在哪里，命令从哪里进入，结果从哪里出来，系统出问题时又该从哪里排。

用第一性原理来理解，OpenClaw 最底层做的事情并不神秘：它调用一个或多个大语言模型，把消息、上下文、工具调用、文件和配置组织成可持续运行的工作流，然后通过 Gateway 作为中枢把外部世界与模型世界连接起来。也就是说，模型负责理解与生成，工具负责执行与查询，工作空间负责长期连续性，Gateway 负责路由与状态，Dashboard 负责观察与交互，Doctor 与日志负责排障。这五块拼在一起，才构成你真正能长期使用的个人 AI 系统。

如果你用系统思维去看OpenClaw，就会发现它并不是一个孤立程序，而是一个带有反馈回路的运行体。输入层是聊天消息、定时任务、文件更新、外部API 返回；处理层是模型推理、工具选择、会话状态更新、记忆压缩与规则判断；输出层是回复消息、生成文件、调用外部系统、写入日志与更新记忆。RAG 与自我反馈机制正是在这个处理中起作用：前者负责把“模型本来不知道但可检索到的信息”临时送进上下文，后者负责让系统根据执行结果、历史记录与错误信息修正下一轮动作。你后面看到的许多“明明模型不傻，却还是做不好”的情况，往往不是模型太弱，而是检索、记忆、权限、路由、工具结果验证这几个环节没设计好。

1.4.1. AI、生成式 AI 与 LLM：不要把“会聊天”误认为“懂系统”

AI 是人工智能的大概念，包含规则系统、机器学习、深度学习、搜索、规划、感知、推荐、优化等很多路线；生成式 AI 是其中更强调“生成文本、图像、音频、代码”等输出的一类；LLM，也就是大语言模型，则是生成式 AI 中专门处理语言与多模态推理的重要分支。新手常见误区是把这三个概念混成一个词，仿佛它们都等于“聊天”。实际上，聊天只是最容易看见的交互界面，而不是能力全貌。一个模型擅长写作，不代表它擅长长期规划；一个模型擅长解释代码，也不代表它擅长替你在多渠道之间持续监听消息。

从安装和使用OpenClaw 的角度，你不需要先成为机器学习研究者，但你至少要知道：模型只是“大脑的一部分”，不是整套系统。没有文件、记忆、工具、权限、运行时与状态管理，再强的模型也只能像一个被关在玻璃罩里的高智商问答器；有了 Gateway、Skill、Channel、Workspace、Cron、Heartbeat 这些机制，模型才从“会说”升级为“能长期工作”。这也是为什么OpenClaw 的文档会把安装、配置、状态检查、工作空间、人设文件、记忆文件与渠道接入放在同一张知识地图里。

把这一层想通以后，你就不会再纠结一个常见误解：为什么我已经有ChatGPT、Claude、Gemini、DeepSeek、豆包、Kimi 这些应用了，还需要 OpenClaw？答案不是“谁取代谁”，而是“谁负责什么”。通用聊天产品更像随开随用的前台窗口，OpenClaw 更像你自己控制的一套后台与中枢。前者强调快速提问，后者强调长期运行、渠道连接、工具调用、个人化文件体系与可运维性。

1.4.2. Chatbot、Copilot、Assistant 与 Agent：看起来很像，工作边界不同

Chatbot 的核心模式是“你问我答”。它通常以单个聊天窗口为主要交互边界，对连续性的依赖较弱，对外部工具和长期运行的要求也不高。Copilot 则往往嵌在某个宿主环境里，比如编辑器、办公套件、浏览器或操作系统，它强调“伴随式辅助”，帮助你在当前环境里补全文本、解释代码、生成命令或完成局部操作。

Assistant 比 Chatbot 更强调长期关系和个性化，但在很多产品里，这个词常常只是营销层命名，并不必然意味着真正的自治。Agent 才更接近 OpenClaw 所在的范畴：它不仅能理解指令，还能根据规则、上下文、权限和工具进行多步执行、结果检查和后续调整。

你可以把这四类角色想成四种工作方式。Chatbot 像前台问讯台；Copilot 像贴身副驾；Assistant 像愿意长期记住你偏好的助理；Agent 则像带着流程、权限和工具箱的执行者。真正的难点并不在于名字，而在于系统有没有把“计划、执行、检查、改进”这四步串起来。只要一个系统只能停留在回答层，没有工具、没有状态、没有反馈、没有记忆治理，它就很难真正称得上Agent。

OpenClaw 最有价值的地方，正是把 Assistant 与 Agent 之间那条常被忽视的鸿沟补齐了。它不是单纯给模型换个聊天壳，而是把长期运行的Gateway、文件化人格、结构化记忆、技能系统、多渠道入口与后台调度放在同一平台中。这样一来，你的 AI 才不只是“此刻回答得不错”，而是“明天还能在相同规则下继续工作”。

1.4.3. API、API Key、Token、上下文窗口与速率限制：安装前要搞清楚

API 是应用程序编程接口。对 OpenClaw 新手来说，可以把它理解成“你的 OpenClaw 去找模型服务商说话时使用的正式通道”。你在网页或 App 里直接和模型聊天，背后通常也是调用 API，只是平台已经替你包装好了；而你自己部署 OpenClaw 时，往往需要亲自准备 API Key、选择模型、设置供应商、控制配额和查看报错。也就是说，OpenClaw 不是凭空产生智能，而是通过 API 把外部模型能力接到你自己的系统上。

API Key 是访问这条通道的密钥，最基本的原则只有一句：把它当密码管理。不要把 Key 写进公开仓库，不要发在聊天群里，不要截图泄露，不要随手写进会同步到公共云盘的纯文本文件。更稳妥的做法，是把它放进向导、系统密钥链、环境变量或受控的配置文件中，并给不同用途分开计费与权限边界。你后面如果用多个供应商，最好再建立“主用 Key、测试 Key、备用 Key”的习惯，这样即使一个供应商短时异常，你也不至于整套系统同时停摆。

Token 这个词最容易让新手混乱，因为它至少有三层常见含义。

第一层是认证Token，也就是一种登录或接口访问凭证；

第二层是计费或上下文Token，也就是模型把文本拆成的统计单位，输入和输出越长，Token 消耗通常越多；

第三层是系统内部的短时授权票据，例如控制面板接入、设备配对或一次性引导流程中用到的临时令牌。你在阅读文档时一定要分清它说的是哪一种。很多“为什么明明还有额度却报错”或“为什么我有密码却不能访问”的问题，本质上就是把这三种 Token 混为一谈了。

上下文窗口决定了模型一次能稳定看见多少内容。它不是越大越好，而是越适合当前任务越好。窗口太小，长对话和多文件任务容易丢上下文；窗口足够大，但如果你把无关聊天、重复日志和过多历史都塞进去，也会导致成本上涨、重点稀释、响应变慢。RAG、记忆压缩与工作空间文件的真正价值，就是帮助系统把“需要长期保存的信息”和“需要当场召回的信息”分层处理，而不是把一切都硬塞进同一次提示里。

速率限制与配额限制是部署阶段最容易被误判为“系统坏了”的问题之一。许多新手第一次看到 401、403、429、quota exceeded、rate limit、model not found、insufficient balance、region not allowed 一类报错，会本能地怀疑安装失败。其实这些报错常常说明软件已经能正常访问服务，只是认证、余额、权限、模型名、地区限制或请求频率触碰了供应商边界。所以你在排障时要先区分：这是本地环境问题，还是供应商接口问题；是 CLI 没装好，还是模型配置不对；是 Gateway 没起来，还是 API Key 没权限。