最近社区里不少人在聊 OpenClaw 这个智能体框架，它有个特别接地气的昵称叫“小龙虾”，因为 OpenClaw 直译过来就是“张开的爪子”，再加上开源社区喜欢起外号，一来二去“小龙虾”就叫开了。但名字归名字，真正让它在智能体圈子里火起来的，是它把“搭建一个能干活的多功能智能体”这件事的门槛压得特别低——你不需要从零写 Agent 框架，也不需要理解复杂的多智能体调度逻辑，装好之后配置一个本地模型，就能拥有一个能规划任务、调用工具、处理文档的 AI 助手。
这篇教程写给谁？写给那些想在本地机器上把 OpenClaw 完整跑起来的人。不管你之前有没有玩过智能体框架，只要会基本的命令行操作，能分得清终端和文件夹，就能跟着这篇文章把环境搭好。我会把安装过程中的原理、坑点和优化方案一起讲清楚，让你是真正“掌握”它，而不是稀里糊涂敲一通命令然后碰运气。
1. 先说清楚：OpenClaw 是什么，为什么要本地装
1.1 “小龙虾”这个名字怎么来的
OpenClaw 这个名字本身起得挺形象。英文里 claw 指爪子、螯，open 代表开源开放，连在一起就是“一只张开的爪子”。社区里玩谐音梗的人不少，顺着“爪子”联想到小龙虾的大钳子，于是“小龙虾”这个中文外号就传开了。你会在各种技术交流群里看到“今天把小龙虾喂了个文档”“小龙虾本地跑起来了”这种说法，说的都是 OpenClaw。
名字是小事，但它暗示了一个核心设计：这个框架擅长“伸手”去拿东西、去抓信息、去操作外部工具。它定位的是一个智能体运行框架——所谓智能体，和普通聊天机器人最大的区别在于，它不是只“说话”，而是会把你的任务拆成步骤，然后自己去查资料、跑命令、调接口，最后把结果整理给你。OpenClaw 做的就是把这套能力模块化，让你不用关心每一步背后的工程实现。
这类框架其实有很多，但 OpenClaw 的差异化在于安装和配置相对轻。它不需要你部署一套庞大的微服务集群，也不需要你懂 Kubernetes 或者容器编排，在一台普通开发机上就能跑起来。所以它特别适合个人开发者、小型团队，以及所有想先把智能体玩明白再考虑扩大规模的人。
1.2 本地部署到底解决什么问题
我见过不少人一开始习惯直接去用在线平台，填个 API Key 就能跑起来，为什么还要费劲本地装？这里有几个非常实际的理由。
第一是数据隐私。你要交给智能体处理的，往往不只是“今天天气怎么样”这种公开问题，而是内部文档、代码片段、接口文档甚至合同条款。这些东西发到别人的公共服务上，等于把家底亮给外人看。本地部署意味着所有请求都在你的机器上完成，模型调用、工具调用、日志存储全部本地化，敏感信息不出门。
第二是可控性。在线平台给你什么模型、什么工具、什么插件，你就得用什么，限制比较多。本地部署之后，模型可以随时换，想接开源模型就接开源模型，想用自己的微调模型也没问题。工具函数是自己定义的，权限边界自己说了算，不会出现平台规则莫名其妙把你功能砍掉的情况。
第三是成本。在线平台通常按 token 计费，跑一个复杂任务动辄消耗几万 token，日积月累不是小数目。而本地部署搭配本地模型，主要花的是电费。硬件是你自己的，跑多跑少没有额外账单。哪怕你选择接云端 API，本地框架本身也不收费，整体成本更可控。
当然，本地部署也有代价，比如需要自己维护环境、排查问题、处理版本升级。但换个角度想，这些“代价”恰恰是学习智能体框架内部工作原理的最好途径。你亲手装一遍、配一遍、调一遍，对 OpenClaw 的工作机制理解就会完全不同。
1.3 这篇教程适合谁读
如果你属于下面几类人，这篇教程就是写给你们的：
- 想入门智能体开发，但被“Agent”“工具调用”“多智能体协作”这些概念劝退的新手。
- 已经用过在线 AI 服务，想在本地给自己搭一个私人的、可定制的 AI 工作助理。
- 需要把智能体集成到现有项目里，想先评估 OpenClaw 是否适合做底座的开发者。
- 纯粹喜欢折腾工具、追开源项目的爱好者。
你的基础不需要多高。熟悉终端基本操作（cd、ls、mkdir），知道怎么装软件，遇到报错能复制日志去搜一下，这就够了。剩下的，我会一步步带着走。
2. 安装前的准备工作：硬件、系统与依赖
2.1 硬件要求：别被“大模型”三个字吓到
很多人一听“本地 AI”，第一反应是“我电脑跑得动吗？”其实 OpenClaw 本体非常轻，它本质上是一个 Node.js 编写的智能体编排框架，真正的算力消耗发生在“跑模型”这一步。如果你暂时不打算在本机跑大模型，而是接一个云端的模型 API，那 OpenClaw 对硬件的要求和随便跑一个网页服务没区别。
我来分开说。只跑 OpenClaw 框架本身，CPU 4 核以上、内存 8GB 就能非常流畅地运行，甚至 4GB 内存的机器也能跑，只是并发一多会吃力。它的负载主要来自框架内部的逻辑编排、上下文管理、工具执行，这些和普通 Node.js 服务没本质区别。
如果你打算本地跑模型，那就要看模型。以目前常见的开源对话模型为例，7B 级别的量化模型需要至少 6GB 显存，13B 级别需要 10GB 以上，更大的模型就只能靠 CPU + 大内存硬扛或者直接放弃。我的建议是：如果你没有独立显卡，先用云端 API 跑通流程；如果你有 8GB 以上显存的显卡，可以本地模型和 API 混用，小任务走本地，重任务走云端。这个策略又省钱又实用。
存储方面，代码仓库本身很小，不到 100MB，依赖安装完大概几百 MB。但如果要放模型文件，一个量化模型动辄 4GB 起步，多放几个模型就上 T 了。所以最好给项目目录留出 20GB 以上的可用空间，不要放在系统盘快满的位置。
2.2 操作系统和运行环境怎么选
OpenClaw 官方对三大桌面系统都支持，Windows、macOS、主流 Linux 发行版都能跑。不过根据我的实际体验，不同平台安装时需要注意的点差别很大。
Linux 是最省事的，因为大部分依赖工具链在 Linux 上都有成熟的发行版支持。如果你有一台 Linux 服务器，哪怕是云上买的廉价 VPS，安装过程基本能一路绿灯。macOS 也还行，特别是 Apple Silicon 芯片的机器，只要注意一下 Node.js 的架构版本别装错就行。需要单独说一下 Windows。OpenClaw 本身可以跑在 Windows 上，但很多底层工具（尤其是和编译相关的）在 Windows 下容易出幺蛾子。我强烈建议 Windows 用户优先考虑在 WSL 里面安装，也就是 Windows Subsystem for Linux。用 WSL 的好处是，你可以获得一个接近原生 Linux 的环境，绝大多数安装脚本、依赖工具都不会因为路径分隔符、权限模型不同而报错。如果你不想用 WSL，也可以直接用原生 Windows，但要做好遇到玄学问题后手动修复的心理准备。
接下来是运行时版本。OpenClaw 基于 Node.js 开发，所以 Node.js 是必须装的。版本方面，我建议装 Node.js 20 以上的 LTS 版本，因为框架用到了不少新特性，老版本 Node.js 跑起来会直接报语法错误。你可以用 node -v 检查当前版本，如果发现版本过低，不要纠结，直接升级到最新 LTS。
包管理器方面，项目自带锁文件，用的包管理器是 pnpm。你没装 pnpm 的话也没事，可以用 npm install -g pnpm 来装。注意：如果你项目里同时存在多个 Node 版本，建议安装一个 Node 版本管理工具来切换，避免升级系统包时把环境搞乱。我个人习惯用一个版本管理器，因为平时要维护不同项目的不同 Node 版本，管理工具切换起来非常方便。
2.3 装前检查清单
进入安装流程之前，先花两分钟做个体检。你要确保下面这几项都满足：
- Node.js 版本不低于 20，终端里运行 node -v 能正常输出版本号。
- 包管理器 pnpm 已安装，运行 pnpm -v 能输出版本号。
- Git 已安装，运行 git --version 能输出版本号。如果没有装 Git，后续拉取代码会卡在第一步。
- 网络能正常访问代码仓库和依赖源。这里不需要特殊手段，但如果你在的企业网络有严格防火墙限制，可能要先确认代理规则允许终端走正常流量。
- 磁盘空间足够，前面说了建议 20GB 以上，这样一个模型加一堆依赖都不会捉襟见肘。
- 确定好自己的模型接入方式。是用本地模型，还是用云端 API，还是先跑内置测试模式。这个决定影响后面的配置文件怎么填。
- 关闭可能占用常用端口的服务。OpenClaw 默认会起一个 Web 服务，端口一般在 3000 到 3100 之间，如果你机器上已经有服务占用了这些端口，后面启动时就会冲突。可以先打开终端跑一下 netstat -an | grep 3000（Windows 用 netstat -an | findstr 3000）看看端口占用情况。
这套检查做完，你就可以放心地进入正式安装了。千万别跳过环境检查直接装——我在帮别人排查安装问题时，至少有一半的问题出在基础环境没配对，比如 Node 版本太老、没装 Git、磁盘已满。环境对了，后面就顺了。
3. 完整安装流程：从拉代码到跑起来
3.1 拉取源码：仓库结构先看清
安装的第一步是把项目代码拉到本地。官方推荐的方式是用 Git 克隆仓库。找一个你打算放项目的目录，执行：
git clone <项目仓库地址> openclaw cd openclaw我习惯把仓库地址单独写成一个变量，方便后面如果换了新地址不用改命令。拉完之后，先别急着装依赖，花一分钟看看目录结构。一个典型的 OpenClaw 项目仓库里会有这几个重要的东西：
- package.json：项目入口，依赖清单和脚本命令都在这里。
- pnpm-lock.yaml：锁定依赖版本，保证团队和不同环境下装出来的依赖一致。
- config 或 settings 目录：存放配置文件，可能包含默认配置和示例配置。
- src 或 packages 目录：核心源码，如果你是二次开发者，重点看这个。
- docs 目录：官方文档，本地安装遇到问题第一时间查这里，别急着去搜索引擎。
- plugins 或 tools 目录：插件和内置工具的注册位置。
看明白结构之后，你就不容易在后面的配置阶段迷路。比如你以后想给智能体加一个自定义工具，第一反应就知道该去哪找注册入口；想改默认模型，也知道配置目录在哪里。
3.2 安装依赖：注意包管理器的版本坑
进入项目目录后，运行依赖安装命令：
pnpm install这一步会读取 package.json 和 pnpm-lock.yaml，把项目需要的所有依赖包下载到本地 node_modules 目录。看起来就一句话的事，实际跑起来可能遇到几个坑。
第一个坑是 pnpm 版本和 lock 文件不兼容。如果框架是用新版本 pnpm 生成的锁文件，而你本地是旧版本 pnpm，命令行会提示锁文件格式版本不一致。解决办法很简单，升级 pnpm 到最新版。也可以先跑 pnpm --version 看看版本号，如果低于要求，就执行 npm install -g pnpm@latest 升级。
第二个坑是某一些依赖是原生模块，需要在安装时执行编译。这类模块在 Windows 上最容易出问题，因为它们依赖 Windows 的构建工具链。如果你在原生 Windows 上安装报了一堆和 node-gyp、visual studio 相关的错误，不用硬啃，最好的出路就是切换到我前面说的 WSL 环境再来一遍。
第三个坑是网络问题。依赖包数量不少，如果网络不稳定或者连接依赖源比较慢，install 过程会中途卡住或者报错。这种情况下可以重试几次，通常断点续传机制会接着下载；如果始终不稳，可以考虑换一个网络环境。记住，不要为了解决下载速度问题去乱改镜像源和代理配置，尤其是不要引入任何需要特殊手段才能访问的源，那会让问题变得更加复杂，还容易给自己惹上不必要的麻烦。
依赖安装成功之后，可以顺手跑一下 git status，确认仓库目录没有被安装过程污染。正常状态下，除了 node_modules 和可能的临时文件外，不应该出现其他改动。
3.3 首次启动：初始化向导做了什么
依赖装好以后，打开项目的 package.json，看 scripts 部分。通常会有一个 build 或 start 脚本，也可能是直接引导进入初始化流程的命令。以常见的项目来说，你需要先执行：
pnpm build这一步会把 TypeScript 源码编译成 JavaScript，或者把前端资源打包好。如果你跳过构建直接启动，可能会遇到“找不到 dist 目录”或“模块解析失败”的报错。我第一次装的时候就跳过看 README 的步骤，直接跑启动命令，结果卡了半天才意识到没构建。
构建完成后，执行启动命令：
pnpm start首次启动时，OpenClaw 会检查工作目录下有没有配置文件。如果没有，它会自动进入初始化向导模式。向导会问几个问题，包括：
- 你要给这个智能体起什么名字。
- 使用哪个模型提供方（本地模型服务还是云端 API）。
- 基础工作目录设在哪儿。
这些问题现在答错了也没关系，因为向导结束后会生成一个配置文件，你随时可以修改。我建议首次跑通时保持默认选项，把流程走完，之后再去模板文件里调整细节。
启动成功的标志，是终端里出现类似“server started”的日志，并告诉你 Web 控制台地址。如果这一秒出现了，恭喜你，OpenClaw 本体已经装好了。剩下的事情就是把它和模型对接起来，让它真正拥有“智能”。
3.4 接入模型：本地模型和云端 API 二选一
OpenClaw 只是一个框架，自带的大脑是空的。它需要对接一个大模型，才能执行理解、规划、生成这些核心任务。模型接入有两条路线，我分别讲讲怎么做选择和怎么配。
第一条路线，对接本地的模型推理服务。你需要先在机器上安装一个本地模型运行环境，然后从模型社区下载一个开源模型文件。本地模型服务的默认地址一般是 http://127.0.0.1:11434 这类，你需要在 OpenClaw 的配置里把模型提供方指到这个地址，并填写所使用模型的名字。配置大概长这样：
model: provider: local baseUrl: http://127.0.0.1:11434 modelName: "your-local-model-name" temperature: 0.7这样做的最大优点是免费、私密、无调用次数限制。缺点则是生成速度受限于你的硬件，半天说不出一个字的情况也不是没遇到过。所以本地模型我只推荐给有显卡的人尝试，纯 CPU 跑大模型真的是一种煎熬。
第二条路线，对接云端 API。你需要在某个模型服务商那里申请一个 API Key，然后在配置里把端点和 Key 填进去。配置大概长这样：
model: provider: api apiKey: "sk-xxxx" baseUrl: "https://api.example.com/v1" modelName: "some-cloud-model"云端 API 的优点是模型能力强、推理速度快，不用折腾本地硬件。缺点是要付费，数据也会经过第三方服务器，敏感场景需要谨慎。我个人目前用的就是混合策略：普通问答和代码任务走云端 API，处理本地私有文档时切到本地模型，这样兼顾隐私和效果。
如果你两条路线都不想动，很多框架还会提供一种“模拟模式”或者“测试模式”，用假的模型响应来让你体验完整流程。这个模式适合先跑通链路、调试工具函数，等一切就绪再接真实模型。
4. 跑起来之后：核心配置与实用扩展
4.1 主配置文件的几个关键字段
OpenClaw 启动后会在工作目录生成一个主配置文件，格式通常是 JSON 或 YAML。它相当于整个智能体的总控台，理解了这个文件，你就掌握了修改任意行为的钥匙。
核心字段大概有这几个：
- agent / name：智能体名称。这个名字会出现在对话日志和控制台里，你可以改成符合自己习惯的名字。
- model / provider：模型提供方类型。切换本地模型和云端 API 就是改这个字段。
- model / modelName：具体使用的模型名称。注意，模型名称要和你的模型服务端提供的名字完全一致，大小写都不能错。
- systemPrompt 或 system prompt 模板：这是智能体的系统提示词，决定它的“人设”和行为边界。比如你可以把它设置为“你是一个严谨的代码审查助手，所有建议必须附上代码示例”。修改这里的措辞，比在每次对话里反复强调要管用得多。
- tools 或 plugins：启用的工具列表。有些工具默认关闭，需要你手动打开。
- workspace 或 workingDirectory：智能体执行工具命令时的工作目录。这个字段要格外小心，如果设置成系统根目录，那智能体在运行文件操作或命令执行工具时就有了很大的权限，风险较高。我一般是建一个专门的沙箱目录，只允许它在那里面折腾。
- log / level：日志级别。调试阶段建议设成 debug，跑稳定了再改回 info，否则日志会刷得非常快。
- port：Web 控制台端口。如果和本机其他服务冲突，改这里就行。
每次改完配置文件，都需要重启服务才能生效。很多新手改了配置没重启，然后来问“怎么不生效”，这个坑一定要记住。
4.2 给智能体加工具和技能
一个只有对话能力的智能体，严格来说还算不上“智能体”。OpenClaw 的价值在于它的工具调用能力。它内置了一批常用工具，比如网页读取、文件读写、命令执行、代码运行等等。你可以在配置文件的 tools 区域看到它们，以列表形式存在，大概是这种结构：
{ "tools": [ { "name": "web_search", "enabled": true }, { "name": "file_read", "enabled": true }, { "name": "file_write", "enabled": true }, { "name": "command_exec", "enabled": false } ] }把 enabled 改成 true，重启之后这个工具就能被智能体调用了。但我要提醒一句：工具不是越多越好。工具越多，模型在选择时就越容易犯迷糊，可能明明该用 A 工具的却用了 B 工具。更危险的是，像 command_exec 这种能执行系统命令的工具，一旦开启等于把一台电脑的终端权限交给了模型。如果模型接的是云端 API，那你的机器就暴露在一个外部系统面前。我的建议是：最小权限原则。默认只开启确实需要的两三个工具，用得到再加。
如果你想给智能体加一个完全自定义的工具，比如“读取某个内部系统的数据再返回摘要”，流程也不复杂。你需要在项目里写一个工具函数，然后在工具注册表里登记。注册完成后，模型会自动根据工具描述决定何时调用它。所以最关键的是把工具描述写清楚，最好标明“参数是什么、什么时候用、什么时候不要用”。我在实际使用中试过用模糊描述注册工具，结果模型经常在不该调用的时候调用，后来把描述写具体、加上使用限制，准确率立刻上来了。
4.3 多实例与项目隔离
OpenClaw 是可以同时跑多个实例的。比如你既想要一个处理代码的助手，又想要一个处理文档的助手，两者的人设、工具、模型都可能不一样。最简单粗暴的方法是把项目复制两份，各自独立配置、独立启动。缺点是比较占空间，而且公共依赖会重复装。
更好的做法是利用一个工作目录参数，在同一个项目里指定不同的配置文件和工作空间来启动多个实例。具体做法我建议参考官方文档，因为不同版本对多实例支持的方式不同。不过核心逻辑是相通的：每个实例要独立占用一个端口、一个工作目录、一套模型配置。这样它们之间完全隔离，互不干扰。
项目隔离的意义不只是“各个实例互不串门”，更重要的是安全。你在 A 实例配了一个开放命令执行的工具，在 B 实例里如果把权限收了，两个智能体的能力边界就是分开的。我见过有人把实验性的工具和正式项目放在同一个实例里，结果实验工具误操作，影响到了正式任务。分开之后，这种问题基本就绝迹了。
5. 高频问题与排查记录
5.1 依赖装不上的典型原因
依赖安装失败是新手最常碰到的第一个拦路虎。我见过的常见原因按出现频率排，大致是这三类。
第一类是 Node.js 版本不兼容。报错信息里通常会出现“engine mismatch”“requires Node.js >= x”之类的提示。解决办法非常直接，升级 Node 版本，别在旧版本上死磕。
第二类是包管理器混乱。同一个项目里同时用了 npm、yarn、pnpm 的锁文件，或者之前用 npm 装到一半，换了 pnpm 继续装，导致 node_modules 处于一个残缺状态。解决的姿势是：删掉 node_modules 目录、删掉所有锁文件（如果项目自身带了锁文件，则不要删项目的，而是删掉临时生成的那份），然后统一用项目指定的包管理器重新安装。
第三类是网络不稳定导致部分包下载失败。表现为安装过程中一堆 ECONNRESET、ETIMEDOUT 报错。这种没什么优雅的办法，多试几次，或者换个网络环境。一定不要为了解决速度问题去配置来历不明的代理或特殊通道，那些东西表面看着快，实际会引入安全和合规隐患，出了问题反而更麻烦。
5.2 启动报错：端口、权限、文件锁
服务启动失败，最常见的报错是端口被占用。你会在日志里看到“EADDRINUSE”之类的字样，后面跟着一个端口号。解决办法：要么改 OpenClaw 配置中的端口，要么先停掉占用该端口的服务。Linux 和 macOS 下可以用 lsof -i :端口号 查看是谁占用了端口，Windows 下可以用 netstat -ano | findstr 端口号 再配合任务管理器处理。
第二类是权限问题。比如你在某些系统上没有写权限，导致服务无法在配置目录写入日志文件。报错信息一般会提示“EACCES: permission denied”。这种情况不用动什么大手术，把工作目录的所有权改成当前用户，或者以管理员身份运行一次命令，改完权限记得改回来。
第三类是文件锁问题。项目里有某种 .lock 文件残留，启动时发现文件被锁住，直接拒绝启动。你只需要找到对应的 lock 文件删掉就行。但注意别把 pnpm-lock.yaml 这种依赖锁文件删了，那是正常文件，删了反而会导致依赖版本错乱。
5.3 模型连不上、回答乱码怎么办
模型连接失败的排查步骤可以按顺序来。第一步，看物理连接。直接在你用来测试 API 的工具里访问模型服务的健康检查接口，看看是不是根本连不上。如果连不上，问题在模型服务本身或者网络；如果能连上，问题在 OpenClaw 配置。第二步，检查 baseUrl 是否填对。这个字段很容易因为多了一个斜杠、少了一个路径而请求失败。第三步，看 API Key 是否有效、是否超过了额度。很多服务商在额度用尽后不会报“余额不足”，而是会给你返回一个比较模糊的 429 或 401 错误，容易让人误以为是代码问题。
回答乱码的问题，多半是模型上下文格式设置不对。模型返回的内容是 JSON 格式，OpenClaw 解析之后却显示出一堆转义字符，那大概率不是模型问题，而是框架内部解析时采用的字符编码和你终端的编码不一致。Windows 下这个问题尤其常见。你可以在配置文件里检查字符编码相关设置，或者直接把终端切换成 UTF-8 编码。另外提醒一句，如果你用的是本地模型，有些小型模型本身生成中文能力就弱，输出乱码可能因为它压根没学会好好说中文。这种情况就别折腾框架了，换个中文能力更强一点的模型才是正路。
5.4 性能调优：内存和 CPU 占用控制
用了一段时间之后你会发现，OpenClaw 如果不调优，会吃不少资源。默认配置下它会一次性把很多模块加载进内存，即使当前根本用不到。要控制内存占用，最直接的办法是减少加载的插件数量。插件列表里关掉不用的，内存占用能肉眼可见地降下来。
第二个办法是调整模型调用参数。比如把最大上下文长度调小一些，模型收到的历史消息少了，消耗的时间和显存都变小，响应速度也会快一些。代价是智能体可能“记性”变差，超过长度之后记不住前面的对话。你需要根据自己任务的复杂度平衡。
第三个办法是调整日志级别。把 debug 日志改成 info 或 warn，能显著降低磁盘写入压力。可别小看日志的影响，我碰到过一个案例，一个高频运行的智能体，debug 日志一天能写几十 GB 磁盘，把机器硬生生写满了。改成 warn 之后，磁盘占用直接归零。
如果你是本地模型派，还有两个硬件层面的调优技巧。一是开启 GPU 加速，确保模型推理服务真的用上了显卡；二是给模型服务设置可用的显存上限，防止它在跑大任务时把所有显存占满，导致整个系统卡死。这些设置通常在模型服务自己的配置里，不在 OpenClaw 里，但调好了之后 OpenClaw 的体验也会跟着好。
6. 一点个人经验，收尾
装 OpenClaw 这件事，难度不大，但很考验耐心。我自己第一次装的时候，卡在依赖编译那一步折腾了几个小时，后来换了个干净环境五分钟就过了。所以如果你的安装过程碰到莫名其妙的报错，别急着死磕，先怀疑环境问题，别怀疑代码问题。
还有一个小建议：把它跑起来之后，先别急着接复杂的大模型、配一堆工具。拿最简单的模型，开一个文件读取工具，让它读一个你的项目文档、总结要点。这一步走通了，说明整个链路是健康的，再逐步加技能、换模型、开命令执行。保持这样一个从简到繁的过程，你会走得很稳。
这框架的扩展空间真的不小。你可以在它上面做私人知识库助手、代码库问答机器人、自动化报告生成器，甚至把几个 OpenClaw 实例拼成一个多面手小团队。希望这篇教程能帮你把环境装好，把第一个智能体跑起来。后面我会继续分享工具开发的实战细节，到时候再聊。
