1. 从"98个用例"这个数字说起：OpenClaw到底在解决什么问题
第一次看到"OpenClaw 的98个真实世界精彩用例"这个标题，我的反应是：又一个堆数量的清单文。但真正把 OpenClaw 跑起来、接上本地模型、让它替我操作浏览器和文件系统之后，我改主意了。98 这个数字不是营销噱头，它反映的是一个事实——当一个 AI 代理框架同时具备本地执行能力、跨平台部署能力和可插拔的技能系统时，它能覆盖的场景会自然膨胀到接近三位数。
OpenClaw 本质上是一个开源的 AI 代理运行时。你可以把它理解成一个"给大模型装上手脚"的中间层：模型负责思考和决策，OpenClaw 负责把决策翻译成真实的系统操作——打开浏览器、读写文件、调用命令行、控制机器人、操作办公软件。它用 Node.js 写核心运行时，用 Docker 做环境隔离，通过 skill（技能）机制扩展能力边界。这三个技术选型不是随便定的，后面我会逐个拆解为什么是它们。
这篇文章适合三类人看：一是手里有本地模型（比如通过 Ollama 部署的），想让模型真正"干活"而不只是聊天的开发者；二是做嵌入式、机器人、自动化方向，想把 AI 代理接进自己硬件项目的工程师；三是单纯对 AI 代理好奇，想找一个能跑起来、能改、能学的开源项目练手的人。我会把 98 个用例按场景归类，挑出最有代表性的那些讲透原理和操作，而不是罗列一遍名字就完事。
先说结论：OpenClaw 的价值不在于它内置了多少功能，而在于它的技能抽象层设计得足够干净，让你能用几十行代码把一个全新场景接进去。理解了这一点，98 个用例就不再是清单，而是一套可复制的方法论。
2. 部署这件事：为什么 Node.js 和 Docker 是绕不开的两道坎
2.1 Node.js 版本选择背后的真实坑
OpenClaw 的核心运行时基于 Node.js，这不是偶然。AI 代理需要大量异步 I/O——同时等待模型响应、监听文件变化、维持 WebSocket 连接、轮询任务队列。Node.js 的事件循环模型天然适合这种场景，而且 npm 生态里有大量现成的浏览器自动化、HTTP 客户端、文件监听库可以直接复用。
但版本选择上有个真实的坑。热搜词里出现了error installing 24.21.0: node.js v24.21.0 is not yet released，这说明有人试图装一个还不存在的版本。我的建议很明确：用 LTS 版本，不要追最新。截至我写这篇的时候，Node.js 20 LTS 是 OpenClaw 最稳的选择。安装方式上，Ubuntu 用户直接用 NodeSource 的源：
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs node -v # 应该输出 v20.x.xWindows 用户去官网下载 LTS 的 msi 安装包，装完之后在 PowerShell 里验证node -v和npm -v。这里有个细节：如果你之前装过多个版本，用where node确认一下实际调用的是哪个，避免 PATH 里旧版本抢先。
为什么强调版本？因为 OpenClaw 依赖的一些原生模块（比如做浏览器控制的）需要编译，Node 版本和这些模块的兼容性很敏感。我见过有人用 Node 22 跑，结果某个依赖的 prebuild 二进制不匹配，编译报错折腾一下午。LTS 不是保守，是省时间。
2.2 Docker 隔离：不只是"装个环境"那么简单
Docker 在 OpenClaw 部署里的角色，很多人理解错了。他们以为 Docker 只是为了让安装简单，其实核心价值是安全隔离。AI 代理会执行真实操作——删文件、发请求、跑命令。如果这些操作直接跑在你的宿主机上，一个模型幻觉就可能造成不可逆的损失。Docker 容器给了你一层边界：代理在容器里怎么折腾，宿主机是安全的。
安装 Docker Desktop（Windows/Mac）或者 Docker Engine（Linux）之后，有几个配置项必须检查。热搜里virtualization support not detected docker desktop failed to start是高频问题，根因是 BIOS 里的虚拟化支持没开。Windows 用户进 BIOS 打开 Intel VT-x 或 AMD-V，然后在"启用或关闭 Windows 功能"里确认 Hyper-V 和"虚拟机平台"都勾上了。
Linux 用户装完 Docker 后，记得把当前用户加进 docker 组，否则每条命令都要 sudo：
sudo usermod -aG docker $USER newgrp docker # 或者重新登录 docker run hello-world # 验证跑 OpenClaw 的容器时，我习惯挂载一个独立的数据卷，把代理的工作目录和宿主机隔开：
docker run -d \ --name openclaw \ -v openclaw-data:/app/data \ -p 3000:3000 \ openclaw/openclaw:latest注意：不要把宿主机的根目录或者用户主目录直接挂进容器。代理有文件读写权限，挂载范围越小越安全。需要它处理的文件，复制到数据卷里再操作。
2.3 WSL 环境下的验证流程
Windows 用户如果走 WSL 路线，热搜里提到的wsl --status是第一步。在 PowerShell 里跑这个命令，确认 WSL 版本和默认发行版。如果报错说没安装，先wsl --install，重启后再验证。WSL2 是必须的，WSL1 的网络和文件系统行为和真实 Linux 差异太大，Docker 和 OpenClaw 都跑不顺。
WSL 里装 Node.js 和 Docker 的流程和纯 Linux 一样，但有个网络细节：WSL2 用的是虚拟网络，容器端口映射到宿主机需要额外注意。如果你在 WSL 里跑 OpenClaw，想从 Windows 浏览器访问，用localhost:3000通常能通，因为 WSL2 做了端口转发。不通的话，在 WSL 里ip addr查到 IP，用那个 IP 访问。
3. 本地模型接入：Ollama 与 OpenClaw 的配合逻辑
3.1 为什么本地模型是 OpenClaw 的最佳拍档
OpenClaw 可以接各种模型 API，但我觉得它和本地模型（尤其是 Ollama 部署的）是绝配。原因有三：第一，代理场景下模型调用频率极高，一个任务可能触发几十次推理，走云端 API 成本和延迟都吃不消；第二，很多代理场景涉及隐私数据（本地文件、内部文档），数据不出本地是硬需求；第三，本地模型可以针对特定任务微调，比如专门优化工具调用格式的模型，在 OpenClaw 里表现会比通用大模型更稳。
Ollama 的部署本身很简单，官网下载安装包，装完ollama pull拉模型就行。关键是模型选择。不是所有模型都适合做代理。代理任务对模型的指令遵循能力和结构化输出能力要求很高——它得准确理解"调用哪个工具、传什么参数"，而不是自由发挥写一段散文。
我的经验是，参数量在 7B 到 14B 之间的指令微调模型，在工具调用任务上性价比最高。太小的模型理解不了复杂指令，太大的模型本地跑不动。具体选哪个，取决于你的硬件。有独立显卡（显存 8G 以上）可以跑 7B 量化版，纯 CPU 的话建议 3B 级别，速度能接受。
3.2 把 Ollama 接进 OpenClaw 的配置细节
OpenClaw 通过配置文件指定模型后端。典型配置长这样：
{ "model": { "provider": "ollama", "baseUrl": "http://localhost:11434", "model": "your-model-name", "temperature": 0.1 } }这里temperature设低是有讲究的。代理任务要的是确定性，不是创造力。温度高了，模型可能这次调用工具 A，下次调用工具 B，行为不可复现，调试起来很痛苦。0.1 到 0.3 之间是比较稳的区间。
如果 OpenClaw 跑在 Docker 里，Ollama 跑在宿主机上，localhost在容器里指向的是容器自己，连不上宿主机的 Ollama。这时候要么用host.docker.internal（Docker Desktop 支持），要么把 Ollama 也放进同一个 Docker 网络：
docker network create openclaw-net docker run -d --name ollama --network openclaw-net ollama/ollama docker run -d --name openclaw --network openclaw-net openclaw/openclaw然后在 OpenClaw 配置里把baseUrl改成http://ollama:11434。这个网络别名解析是 Docker 内置的，比记 IP 靠谱。
3.3 模型响应慢怎么办：几个实测有效的优化
本地模型跑代理，最大的抱怨是慢。一个任务等几分钟是常事。我试过几个优化方向，分享实测有效的：
第一，限制上下文长度。代理任务不需要超长上下文，把历史对话裁剪到最近几轮，推理速度会明显提升。OpenClaw 的配置里通常有maxContextTokens之类的参数，调小它。
第二，用流式输出。OpenClaw 支持流式接收模型响应，这样代理可以边收边处理，不用等完整响应。对用户体验提升很大，虽然总时间没变，但感觉快多了。
第三，任务拆分。与其让模型一次规划一个复杂任务，不如拆成多个简单步骤，每步单独推理。单步推理快，而且出错时容易定位。这其实也是 OpenClaw 技能系统的设计哲学——每个技能做一件小事，组合起来完成复杂任务。
4. 技能系统：98 个用例背后的统一抽象
4.1 一个技能长什么样：从最小可用单元讲起
OpenClaw 的 skill 机制是整个项目的灵魂。理解了它，你就能自己造出第 99 个、第 100 个用例。一个技能本质上是一个带元数据的函数：它声明自己叫什么、接受什么参数、做什么事、返回什么结果。OpenClaw 把这些技能的描述喂给模型，模型根据用户意图决定调用哪个。
最小技能的结构大概是这样：
module.exports = { name: "read_file", description: "读取指定路径的文件内容", parameters: { type: "object", properties: { path: { type: "string", description: "文件路径" } }, required: ["path"] }, async execute({ path }) { const fs = require("fs/promises"); return await fs.readFile(path, "utf-8"); } };就这么简单。description字段特别重要，模型就是靠它来判断什么时候该用这个技能。写 description 的原则是：说清楚"做什么"和"什么时候用"，不要写"这是一个读取文件的函数"这种废话，要写"当用户需要查看某个文件的内容时，读取并返回该文件的文本"。
4.2 98 个用例的场景归类
把 98 个用例按场景归类，大致能分成这么几大块，我挑每块里最有代表性的讲：
文件与系统操作类：读写文件、批量重命名、目录整理、日志分析、磁盘清理。这类用例是 OpenClaw 最基础的能力，也是最能体现"代理"价值的——你描述需求，它执行操作。比如"把这个目录下所有 .log 文件里包含 error 的行提取出来，汇总成一个报告"，传统做法要写脚本，OpenClaw 直接理解并执行。
浏览器自动化类：网页信息抓取、表单填写、定时截图、页面监控、多标签管理。这类用例依赖浏览器控制技能，OpenClaw 通过标准的浏览器自动化协议驱动真实浏览器。热搜里提到的openclaw windows companion就是 Windows 下的浏览器伴侣组件，负责建立 OpenClaw 和浏览器之间的连接。
办公文档处理类：批量生成文档、表格数据提取、PDF 内容解析、邮件自动分类回复。这类用例在企业场景里需求极大，而且往往是重复性劳动，交给代理再合适不过。
机器人与硬件控制类：这是 OpenClaw 比较独特的一块。热搜里openclaw+ros、rosclaw openclaw ros2 humble gazebo说明有人把 OpenClaw 和 ROS（机器人操作系统）接起来了。逻辑是：OpenClaw 做高层决策（"去厨房拿杯子"），ROS 做底层控制（电机、传感器、路径规划）。rosclaw就是这中间的桥接层。在 Gazebo 仿真环境里，你可以让 AI 代理控制一个虚拟机器人完成导航、抓取等任务，验证逻辑后再上真机。
嵌入式与物联网类：结合嵌入式开源项目，OpenClaw 可以作为边缘侧的智能决策层。比如农业病虫害识别场景，摄像头采集图像，本地模型识别，OpenClaw 根据识别结果决定是否触发喷药、报警、记录。这类用例的关键是低延迟和离线可用，正好是本地模型加 OpenClaw 的强项。
开发辅助类：代码审查、文档生成、依赖检查、测试用例生成、Git 操作。这类用例对开发者最友好，因为 OpenClaw 本身就在开发环境里跑，调用 git、npm、编译器都是现成的。
4.3 技能组合：单个技能不值钱，组合起来才值钱
98 个用例里，真正精彩的不是单个技能，而是技能的组合。举个例子：一个"自动整理下载文件夹"的任务，背后是"列出目录"+"识别文件类型"+"按类型创建子目录"+"移动文件"+"生成整理报告"这一串技能的组合。OpenClaw 的规划能力让模型自己决定调用顺序，你只需要描述目标。
这种组合能力带来一个反直觉的结论：你不需要为每个场景写一个专门的技能。把基础技能做扎实，让模型去组合，能覆盖的场景远超你预先设计的。我自己的经验是，20 个左右的基础技能，配合一个规划能力尚可的模型，就能覆盖日常 80% 的自动化需求。剩下的 20% 再针对性开发。
5. 跨平台部署：从 Windows 到安卓的实战路径
5.1 Windows 原生与 WSL 的取舍
Windows 上跑 OpenClaw 有两条路：原生 Node.js 环境，或者 WSL。我的建议是，如果你只是试用和开发技能，原生环境够了，装个 Node.js LTS，npm install跑起来就行。但如果你要跑 Docker 容器、要用到 Linux 特有的工具链、要接 ROS，那必须上 WSL2。
原生环境的一个坑是路径分隔符。Windows 用反斜杠，Linux 用正斜杠，OpenClaw 的技能里如果硬编码了路径，跨平台会出问题。写技能时用path.join()而不是字符串拼接，能避开大部分坑。
WSL 的坑主要在文件系统性能。WSL2 访问 Windows 文件系统（/mnt/c/...）比访问 WSL 内部文件系统慢很多。如果 OpenClaw 要频繁读写文件，把工作目录放在 WSL 内部（比如~/openclaw-data），不要放在/mnt/c下。
5.2 安卓部署：Termux 路线的可行性
热搜里openclaw安卓部署、如何用termux安装openclaw手机版下载步骤说明有人想在手机上跑。Termux 是个安卓终端模拟器，能装 Node.js。理论上，OpenClaw 的核心运行时能在 Termux 里跑起来。
但实际体验要泼点冷水。手机的性能和内存有限，跑本地模型基本不现实，只能接远程 API。而且 Termux 的后台进程管理很激进，系统随时可能杀掉 OpenClaw 进程。我的建议是：安卓部署适合做轻量级代理——比如定时任务、消息转发、简单文件操作，别指望它跑复杂任务。真要移动端用，不如把 OpenClaw 跑在一台常开的设备上，手机通过网页界面访问。
Termux 里装 Node.js 的流程：
pkg update && pkg upgrade pkg install nodejs node -v然后按正常流程装 OpenClaw。注意 Termux 的 Node.js 版本可能不是最新的 LTS，装之前确认一下版本兼容性。
5.3 部署方式对比
| 部署方式 | 适用场景 | 优点 | 主要限制 |
|---|---|---|---|
| Windows 原生 | 开发调试、轻量使用 | 安装简单、直接访问 Windows 文件 | 部分 Linux 工具不可用 |
| WSL2 | 完整功能、接 ROS/Docker | 接近真实 Linux 环境 | 文件系统性能、网络配置稍复杂 |
| Docker | 生产部署、环境隔离 | 安全隔离、环境一致 | 需要虚拟化支持、资源开销 |
| 安卓 Termux | 移动轻量代理 | 便携、常在线 | 性能有限、进程易被杀 |
6. 那些没人告诉你的踩坑经验
6.1 模型"假装"调用了工具
这是最隐蔽的坑。模型在响应里写了一段看起来像工具调用的文本，但格式不对，OpenClaw 解析不了，于是什么都没发生，模型却以为任务完成了。表现就是：代理说"我已经帮你删除了文件"，但文件还在。
根因是模型的工具调用格式和 OpenClaw 期望的格式不匹配。解决办法有两个：一是换一个工具调用能力更强的模型，二是检查 OpenClaw 的 prompt 模板，确保它明确告诉模型"必须用指定的 JSON 格式输出工具调用"。我在配置里会加一段强约束的 system prompt，明确格式要求，能显著降低这类问题。
6.2 技能描述写得太模糊导致误调用
前面说过 description 很重要，这里展开讲。如果你写"处理文件"，模型可能在用户说"我想看看这个文件"时调用它，也可能在用户说"删除这个文件"时调用它——因为"处理"太模糊了。结果就是误操作。
好的 description 要限定边界。比如"读取并返回指定文件的文本内容，不修改文件"，明确说了不修改，模型就不会在删除场景下误用它。我现在的习惯是，每个技能的 description 里都写清楚"做什么"和"不做什么"。
6.3 长任务中途失败没有断点
OpenClaw 执行多步任务时，如果第三步失败了，默认行为可能是整个任务回滚或者直接报错停止。对于耗时长的任务，这意味着前面的工作白费。
我的做法是在技能层面做幂等设计——每个技能执行前先检查目标状态，已经完成的步骤跳过。比如"创建目录"技能，先判断目录是否存在，存在就返回成功。这样任务重跑时不会重复劳动。另外，OpenClaw 的任务状态可以持久化到文件或数据库，重启后能恢复，这个配置项建议打开。
6.4 权限给太大导致误删
这是最痛的坑。我早期测试时，给代理挂载了整个用户目录，结果一个模型幻觉让它执行了删除操作，损失了一些文件。从那以后我定了条铁律：代理的工作目录必须是独立的、有备份的、权限受限的。
具体做法：在 Docker 里用非 root 用户跑 OpenClaw，挂载的目录设成只读（除非确实需要写），敏感操作（删除、覆盖）加二次确认机制。OpenClaw 支持在技能里加确认钩子，执行危险操作前先问用户。这个钩子值得花时间配。
6.5 网络请求超时没有重试
代理调用外部 API 时，网络抖动很常见。如果技能里没有重试逻辑，一次超时就导致整个任务失败。我在所有涉及网络请求的技能里都加了指数退避重试：失败后等 1 秒重试，再失败等 2 秒，最多重试 3 次。这个简单的改动让任务成功率提升了很多。
7. 从用例到方法论：怎么造出你自己的第 99 个用例
看完 98 个用例，最重要的不是记住它们，而是提炼出造用例的方法。我的总结是四步：
第一步，找重复劳动。你每天、每周重复做的事情，就是候选用例。整理文件、汇总数据、回复固定格式的消息，这些都是。
第二步，拆解成原子操作。把任务拆到不能再拆的步骤，每一步对应一个技能。拆得越细，技能复用率越高。
第三步，写技能，测技能。每个技能单独测试，确保输入输出符合预期。别等组合起来再测，那样出问题很难定位。
第四步，让模型规划，观察，调优。把技能交给模型，描述任务，看它怎么组合。观察哪里出错，是技能描述不清还是模型能力不够，针对性调整。
这套方法我用了几个月，现在我的 OpenClaw 里有三十多个自建技能，覆盖了从日常文件管理到定时数据抓取的各种场景。98 个用例是别人的，你自己的用例才是真正有价值的。
最后分享一个小心得：别追求一次做完美。先让代理能跑通最简单的任务，哪怕只是"读取一个文件并打印内容"，跑通了再逐步加复杂度。AI 代理这东西，跑起来比想明白更重要，很多坑只有跑起来才会遇到。
