1. OpenClaw 到底是什么OpenClaw 最近在 AI 圈子里的热度涨得很快。我第一眼看到这个名字的时候以为又是一款套了壳的聊天机器人后来仔细翻了一遍它的文档和社区讨论才发现这玩意儿跟普通聊天框完全不是一个物种。简单说OpenClaw 是一个开源的 AI 代理AI Agent框架它让大语言模型不只是陪你聊天而是能真正上手干活——读写文件、调用命令行、操作浏览器、执行定时任务甚至跨设备协同。很多人一听到AI 代理就头大觉得那是大厂研究部门才玩得动的东西。但 OpenClaw 的切入点恰恰是本地可部署、配置够简单、生态可扩展。它不强制你必须用某家云厂商的 API也不要求你有昂贵的 GPU 服务器只要你有一台能跑 Node.js 的电脑就能把 AI 变成一台 24 小时在线的数字打工仔。换句话说你睡觉的时候它在处理报表你在开会的时候它在整理项目目录你周末休息的时候它还在按计划执行自动化流程。这个项目的核心价值我认为可以概括成三句话第一把对话能力升级为执行能力第二把单次问答变成持续自动化第三把只能联网用变成本地私有化部署。对于程序员、运维、测试甚至是写文档、做数据分析的办公族这都是一个能实打实省时间的工具。所以这篇文章不是来介绍概念的我直接按我实际部署和使用 OpenClaw 的完整过程来写把我踩过的坑、试出来的最佳实践、以及配置细节全部摊开讲。想直接上手的人照着做就行。2. 部署与前期的环境准备2.1 先搞清楚 OpenClaw 运行需要什么OpenClaw 本质上是跑在 Node.js 环境下的一套代理框架所以最基础的要求就是你得有一台能稳定运行 Node.js 的机器。我这里说的机器范围很广Windows 台式机、Ubuntu 服务器、macOS 笔记本都可以甚至用 Termux 在安卓手机上跑也不是不行后面我单独讲移动端部署的玩法。硬件方面不用太焦虑。CPU 只要能跑 Node.js 就行内存建议至少 4GB因为 OpenClaw 本身占用不算高但如果你要同时跑本地大模型、浏览器自动化这些重活内存和磁盘就得多留一点。我在一台只有 4GB 内存的旧笔记本上跑过轻量级的 Qwen 模型日常任务处理问题不大但如果切换到 7B 以上的模型明显会卡。所以我的建议是如果你只是做任务编排和文件处理这类轻中度任务普通电脑完全够如果你想让它做复杂的代码生成或者长文本分析建议把 GPU 加到显存 6GB 以上或者干脆走 API 方式。安装之前先把基础环境准备好Node.js 18 以上版本、Git、以及一个包管理器npm 或者 pnpm 都行。Windows 下建议再装一个 PowerShell 7因为部分脚本在旧版 PowerShell 里会有兼容性问题。我自己第一次部署时就在这一步浪费了不少时间啥都没干先花半小时折腾环境版本后来学乖了所有项目统一用 nvm 管理 Node 版本哪里不对直接切换排查起来省心很多。2.2 Windows 和 Ubuntu 下的安装步骤这里我分开讲。Windows 安装我建议直接用项目仓库里的安装脚本或者手动 clone 仓库后执行安装命令。手动安装的好处是你能看清每一步做了什么出了问题也知道从哪里排查。大致流程是这样的git clone https://github.com/your-manual/openclaw.git cd openclaw npm install npm run setup这里要提醒一个很关键的细节npm install如果卡住绝大多数情况是网络问题导致部分依赖拉不下来。我遇到过很多次安装中断之后还得手动清理 node_modules 重新装。所以在国内网络环境下先把 npm 的 registry 换成国内镜像源能省掉后面一多半的坑npm config set registry https://registry.npmmirror.comUbuntu 上的安装思路类似但需要注意系统依赖。如果你的 Ubuntu 版本比较干净缺了 build-essential 和 python3编译某些原生模块时会报错。我踩过的坑是装bufferutil和utf-8-validate这两个包时编译失败最后装上 build-essential 就解决了。Ubuntu 用户在执行安装前先跑一遍sudo apt update sudo apt install -y build-essential python3 make g装完后第一次启动 OpenClaw 会进入一个引导式配置过程它会问你要不要检测网络环境、要不要生成默认配置目录等等。这一步不要一路回车跳过建议认真看一下。我就是最开始图省事直接默认配置结果后面所有模型接入都得重新改配置文件。OpenClaw 的数据和配置默认放在~/.openclaw/目录下后续改配置基本上都是在这个目录里操作。2.3 配置里的核心项逐一拆解OpenClaw 的主配置文件一般是~/.openclaw/config.yaml或者 JSON 格式取决于你用的版本。不管哪种格式核心配置项都围绕模型提供商和执行环境两块展开。模型提供商这里是最重要的一个环节。OpenClaw 的设计很聪明它把模型调用抽象成了一层接口下面可以挂不同的 provider。常见的有 OpenAI 兼容接口、Anthropic API、各类国产大模型 API还有我特别推荐的 Ollama 本地模型。配置一个 provider 的核心就是指定三个东西api_base接口地址、api_key密钥、model模型名。如果你打算用 Ollama 本地跑api_base 一般是http://localhost:11434/v1api_key 随便填一个占位符就行model 填你本地拉取的模型名称比如qwen2.5:7b。如果你打算走云 API就用官方提供的地址和 Key。配置文件大概长这样model_providers: primary: type: openai_compatible api_base: http://localhost:11434/v1 api_key: local-placeholder model: qwen2.5:7b执行环境这块OpenClaw 默认会给代理一个沙箱执行目录它只能在这个目录范围内读写文件别去动除非你明确知道自己在做什么。这个设计我很喜欢因为它相当于给 AI 划了一条安全线。我之前遇到过代理跑着跑着把日志文件写到用户主目录的情况就是因为手动改了 work_dir 却没配权限。改配置时work_dir、allowed_commands、max_steps这三个值建议一开始就设定好。allowed_commands决定了 AI 能调用哪些命令比如ls、cat、grep、python这类常用命令可以放行但rm -rf、sudo这种高风险命令默认最好别加白名单。2.4 Windows Companion 在做什么搜 OpenClaw 的时候很多人会看到windows companion这个词。这个 Companion 组件解决的问题是某些自动化操作在 Windows 原生环境下需要额外的权限或图形界面支持比如操作 Word、Excel 的 COM 接口或者调用系统级快捷键。OpenClaw 核心程序本身只是一个无头代理它没有 GUI而 Companion 就是架在中间的一层适配器。配置 Windows Companion 时核心是让 OpenClaw 主程序能找到并信任 Companion 进程。通常做法是把 Companion 编译成可执行文件放到指定目录然后在配置里声明它的路径和允许调用的能力范围。我测试过用它来让 AI 操作 Excel 表格确实能跑但速度比纯 Python 处理慢不少。如果你只需要处理 CSV 或 JSON我建议直接用脚本写操作逻辑做成 Skill效率高很多。Companion 更适合那些必须依赖 Windows 原生接口的场景比如 Outlook 邮件自动化、Excel 宏操作这类。3. 把模型接进来API 方式与本地模型3.1 云 API 接入换 Key 就能跑用云 API 是上手最快的方式。你只需要去你的模型服务商平台申请一个 API Key然后填进配置就行。以我常用的服务为例我将 OpenAI 的api_base、api_key、model写进配置之后启动 OpenClaw 再问一句帮我列出当前工作目录下的所有文件并统计行数它就能立刻开始调用工具执行。走云 API 的好处是模型能力强、上下文窗口大复杂推理不容易跑偏。而且现在国内可选的合规大模型 API 很多不少都提供免费额度够你日常玩一阵子。我建议新手第一次跑通 OpenClaw 用云 API因为你不需要先解决本地模型下载和显存的坑先建立任务下发—代理思考—工具调用—结果返回这个闭环感。跑通了再去折腾本地模型也不迟。有一个容易踩坑的地方很多 API 平台有访问限流和超时限制。OpenClaw 的默认请求超时时间可能跟某些平台的响应速度不匹配尤其当你的任务特别长、模型推理速度慢时容易在中间环节直接断掉。解决办法是在配置里把timeout调大比如设置成 300 秒。另外云 API 会产生费用我自己试过让它跑一个连续执行 20 分钟的任务消耗的 token 比我预想多不少。所以在正式任务前建议先在配置文件里开启 token 用量记录跑一次就心里有数了。3.2 本地模型与 Ollama 配合如果想完全离线跑Ollama 是一个绕不开的伙伴。OpenClaw 和 Ollama 的配合是我目前最推荐的本地方案。Ollama 负责把模型跑起来暴露一个 OpenAI 兼容的 HTTP 接口OpenClaw 通过这个接口调用模型。你甚至不需要额外写适配器直接把 provider 类型设为openai_compatible就好。Ollama 的安装我简单提一下Windows 和 macOS 都有官方安装包Ubuntu 下用官方脚本一键装。装完之后拉取模型我最早用的是qwen2.5:7b后来换成过llama3.1:8b也跑过phi3:mini。实测下来办公室自动化任务我用 7B 左右的模型就够了如果让它写代码逻辑比较复杂的东西我会切到 API 方式。配置上有一个细节值得注意本地模型的上下文长度受限于模型本身和你的内存大小。如果你给的 prompt 太长可能会把上下文撑爆代理就会丢失前面的对话状态。解决方案是两个方向一起用一是拉取模型时标注更大的上下文参数比如在 Ollama 里创建模型的 Modelfile 时设置num_ctx为 8192二是合理使用 OpenClaw 的会话压缩功能让代理在长任务中自动总结中间状态。这个我后面在技能设计部分再展开。3.3 API 和本地模型怎么选直接给结论追求效果选云 API追求隐私和稳定成本选本地模型两个都想要那就混搭——日常简单任务走本地复杂推理任务走云端。OpenClaw 可以同时配置多个 provider 并按规则切换这正是它被称为数字员工的原因之一你得像老板一样给不同员工分配最适合他的岗位。我自己的做法是用一个本地 7B 模型做文件管理、目录整理、定时提醒这些重复性较高的任务写代码、做数据分析报告的时候切到云 API。这套组合下来固定的 token 费用基本只有纯云方案的二分之一左右。需要注意OpenClaw 切换 provider 的策略配置在models段里你可以给每个模型设置标签和优先级。如果配置项比较陌生先别急着改复杂的路由策略把主 provider 和工作 provider 配好就够用了。4. 核心实操写一个 Skill 让 AI 自己干活4.1 Skill 到底是什么以及为什么要写OpenClaw 最吸引我的地方是它的 Skill 机制。Skill 翻译过来就是技能但跟你脑子里的技能不大一样。它本质上是把某一类任务的操作步骤、提示词、辅助脚本打包成一个目录放在 OpenClaw 的技能库里。你只要用自然语言提出需求代理会自动判断该用哪个技能来完成。比如我写了一个周报生成技能它就知道先去.txt或.md文件里收集这周的提交记录再读邮件草稿最后按模板生成周报文档。为什么必须用 Skill因为一个没有技能的裸代理像是一个很有潜力的应届生——你问他什么他都能聊但真要处理具体的业务流程他就开始瞎猜。而 Skill 相当于给他一本标准的操作手册告诉他每一步该做什么调用什么工具遇到异常怎么处理。我把 Skill 理解为成年人带 AI 上路手把手指定的操作 SOP。Skill 的目录放在~/.openclaw/skills/下面每个技能一个独立子目录。子目录里至少需要一个SKILL.md文件里面用结构化文本描述技能的触发条件和执行步骤。执行逻辑较复杂的场景可以放一个.py或.js脚本让代理调用。目录结构大概长这样~/.openclaw/skills/ weekly-report/ SKILL.md generate_report.py template.md4.2 配置技能的核心字段SKILL.md不需要写得很复杂关键是让代理能看懂什么时候用我以及怎么用我。我自己常用的模板如下--- name: weekly_report description: 生成项目周报收集本周 commit 记录按模板输出 markdown 周报。 trigger: 每周五、周报、本周进度 command: python3 generate_report.py allowed_context: work_dir/weekly_reports --- 执行步骤 1. 检查当前目录是否为 git 仓库若是则 git log --since7 days ago --prettyformat:%h %s。 2. 将步骤1的结果整理成列表。 3. 读取 template.md替换其中的占位符。 4. 将结果写入 work_dir 下的 weekly_report_YYYYMMDD.md。 5. 输出完成信息。这里trigger字段和description字段非常重要它们直接影响代理能否在合适的时候选中这个技能。我建议描述写得具体一点宁可啰嗦也不要写成生成周报这种一句话描述因为代理在识别任务时靠语义匹配描述越准确匹配率越高。command字段写的是代理需要调用的可执行入口。你可以让代理直接通过 shell 运行这个脚本也可以在步骤里拆成更细的命令。我倾向于把复杂逻辑写进脚本SKILL.md只保留最简步骤这样代理不容易在中间环节自由发挥跑偏。4.3 实战一个整理下载目录的技能我用一个非常生活化的例子说明整套流程。假设你希望 OpenClaw 每天凌晨把downloads目录里的文件按类型挪到对应文件夹。这个技能我命名为organize_downloads配置如下--- name: organize_downloads description: 按文件扩展名整理下载目录图片放到 images文档放到 docs压缩包放到 archives。 trigger: 整理下载目录、分类文件、downloads command: python3 organize.py --- 执行步骤 1. 扫描 work_dir/downloads 下所有文件。 2. 根据扩展名映射表把文件移动到对应子目录。 3. 输出每个分类的文件数量。 4. 对无法识别的类型放在 others 目录。配套的organize.py逻辑不复杂核心就是遍历、映射、移动。我记得第一次测试时发现一个问题如果有两个同名的文件被移动直接shutil.move会报错。后来我在脚本里加了一个带时间戳的改名逻辑。这也是我反复强调的——Skill 写完之后一定要自己先跑几轮边界测试你不可能指望 AI 一开始就完美处理所有异常情况。写好后你只需要对 OpenClaw 说一句帮我整理一下下载目录它就会自动匹配到organize_downloads然后开始执行。整个过程我不需要动一根手指。这背后实际上是一个意图识别 技能调用 脚本执行的完整链路也是我把 OpenClaw 称为数字打工仔的真正原因。4.4 设置定时任务让 AI 真正 7x24 小时工作前面提到24 小时数字员工靠手动下发指令还不够你还要让它能定时触发。OpenClaw 支持基于 cron 表达式的定时任务机制。你可以在配置里定义任务计划比如每天早上 8 点让 AI 检查邮件并生成待办清单每天晚上 10 点让 AI 把今天的开发日志归档。我配置一个简单的任务scheduled_tasks: - name: morning_check cron: 0 8 * * * prompt: 运行 morning_digest 技能整理今天的待办事项和日程输出到 daily_notes 目录。配置完重启 OpenClaw它就会按 cron 时间触发。这里有一个容易忽略的点计算机睡眠问题。如果设备睡眠定时任务不会执行。我一开始在笔记本上部署结果第二天早上发现任务根本没有跑。后来我把 OpenClaw 部署到一台常开的迷你主机上这个问题才算真正解决。如果你只有一台笔记本那就开启系统的不休眠计划。实测下来连续跑一周没问题但要注意散热和电池健康。5. 进阶玩法多代理协作、ROS2 与手机版部署5.1 多代理协作让几个打工仔分工解决复杂任务时单个代理往往容易在上下文中迷失。OpenClaw 支持多代理协作机制你可以定义多个不同角色的代理比如规划者、编码者、审查者让它们在一个工作流里分工配合。以我做过的一个数据分析任务为例规划者负责拆解分析步骤和产出指标定义编码者负责编写数据清洗脚本审查者负责检查脚本逻辑并最终输出报告。每个代理各管一段互相传递中间结果。配置多代理时最关键的其实是沟通边界。你得明确告诉每个代理它的输入是什么、输出要交给谁。否则会出现一种尴尬局面两个代理互相重复干活或者在等待对方结果时死循环。我在配置里为每个代理设定了max_steps上限一旦超过步数就强制终止并把中间结果上报。这是很有效的兜底策略。另外一个心得是多个代理之间传递的中间结果尽量用文件而不是纯文本。因为文件可以保存、追踪、校验在代理切换过程中不容易丢失上下文。我常用的做法是让 A 代理把结果写入 JSON 文件B 代理读取该文件继续处理。这比让代理在对话历史里保留大段文本要稳定得多。5.2 OpenClaw 与 ROS2、Gazebo 的联动很多人可能没想过OpenClaw 这类 AI 代理还能跟机器人仿真环境搭上关系。实际上将 OpenClaw 与 ROS2 结合是让 AI 通过自然语言操控机器人仿真任务的玩法。我在 Ubuntu 22.04 环境下试过搭配 ROS2 Humble 和 Gazebo让 AI 代理接收我下达的语义指令转换成具体的 ROS2 命令去驱动仿真环境里的机器人运行。这一堆关键字组合在一起看着吓人但拆开理解并不复杂OpenClaw 负责理解自然语言和决定调用什么函数ROS2 负责机器人底层通信和驱动Gazebo 负责提供一个仿真环境。OpenClaw 可以通过命令行接口发布ros2 topic pub或调用ros2 service call从而实现对仿真的控制。我的实验场景是这样的在 Gazebo 里加载一个差速驱动机器人我给 OpenClaw 说让机器人前进 1 米再原地右转 90 度代理就会自动执行一系列ros2命令。这一步听起来简单实际调通花了几天时间最核心的问题是权限和环境变量。OpenClaw 通过 shell 调用命令时默认环境下找不到 ROS2 的 setup 脚本路径。解决办法是在技能执行命令前先source /opt/ros/humble/setup.bash。如果你也打算走这条路必须把这一步写进技能的脚本里否则代理永远找不到ros2命令。5.3 安卓端 Termux 部署我原以为移动端部署属于能跑但不好用的鸡肋状态实际试过之后发现它的使用场景比我想象的多。特别适合做轻量级的提醒任务、信息抓取任务。Termux 是安卓上的终端模拟器支持安装 Node.js 和 GitOpenClaw 在里面的安装流程跟 Linux 很像但有几个障碍要先解决。安装 Termux 后第一件事是更新源和基础包pkg update pkg install nodejs git python接着安装 OpenClaw 同样依赖 Git clone 和 npm install。但是安卓文件路径比较特殊很多配置里写死的路径在移动端都会失效。我在配置 OpenClaw 的时候把所有绝对路径都改成了$(pwd)动态获取当前目录。另外Termux 在后台运行会被系统杀进程所以如果你想让它长时间在线需要在手机设置里关闭 Termux 的电池优化。我实测在手机上跑 7B 模型不现实内存扛不住所以手机上最好只做API 调用 技能执行的组合把复杂计算留给云端 API。5.4 如何让它真正 24 小时值守实现 24 小时值守的核心其实在于三件事一是任务要能自动触发定时任务或事件驱动二是代理要在异常退出后自动重启三是日志要能持久化方便事后复盘。我建议使用进程守护工具如 pm2 来守护 OpenClaw 主进程设置崩溃后自动重启。日志方面把输出写到独立文件pm2 start openclaw --name openclaw-agent pm2 logs openclaw-agent --lines 100我的经验是如果不设置自动重启半夜一次网络抖动就会导致代理进程退出早上一看啥都没干。用 pm2 之后连续运行一周基本不用管。这让我真正体会到了让它替我上夜班的感觉早晨醒来打开记录文件昨晚的任务清单已经全部跑完。6. 常见问题与排障实录6.1 快速排查表现象可能原因解决办法安装时 npm install 卡住网络源不稳定换国内 registry 镜像后重装启动时报模型连接失败api_base 或 api_key 配置错误检查 provider 配置项Ollama 地址确认是 localhost:11434定时任务不触发设备休眠或 cron 表达式不对开启休眠拦截用在线 cron 工具验证表达式代理执行操作权限被拒work_dir 或 allowed_commands 配置过窄手动调整白名单按需放行命令对话上下文太长后变笨上下文窗口被撑满开启会话压缩或换更大上下文模型Termux 后台被杀系统省电策略关闭电池优化设为前台服务6.2 我踩过的几个典型坑第一个坑是 Windows 下路径分隔符的兼容问题。OpenClaw 的技能脚本里我一开始用path/to/file这种 Linux 风格路径在 Windows 上跑就炸了。后来在写技能时统一用pathlib.Path处理路径终于消停了。如果你用的是 Windows写任何脚本时第一件事就别手写绝对路径和正斜杠代码习惯不好迟早踩坑。第二个坑是代理在执行命令时如果命令输出太多会把上下文瞬间撑爆。之前让它批量处理几千个文件的元信息结果输出内容全部堆在对话历史里直接导致后续步骤变慢。解决办法很简单在技能脚本里把输出汇总成摘要再返回别让原始明细全部暴露给代理。第三个坑是模型 provider 切换时的人格漂移。同一个任务用本地小模型跑和用云端大模型跑结果风格差异极大。如果你要求输出格式稳定最好在技能里明确指定输出模板并在 prompt 中强调格式要求不要在模型切换时才临时抱佛脚。我后来把所有输出型任务都配置了一个验证步骤如果生成结果不符合模板就让代理重新执行一次。这虽然额外花点时间但换来的是稳定和可控。6.3 经验技巧让代理任务失败时能自愈我强烈建议给每个正式任务都增加一个异常兜底环节不要在理想情况下能跑就不管不顾。我在技能里常用的方式是在脚本外层加try-except或者 shell 的||逻辑失败时给代理明确的提示和可选项。比如python3 generate_report.py || echo 报告生成失败请检查输入文件是否存在这样代理就知道往哪个方向排查而不是卡在一个错误上反复重试。更进阶一点的做法是让代理在失败后自行使用调试工具查看日志文件。坦白讲这个能力取决于模型的推理水平本地小模型经常做不到自动定位但云端大模型表现还不错。基于这一点我在重要任务上都走云 API。7. 写在最后我的实际使用体会我这一路从安装配置到写技能再到做多代理实验最大的感受是 OpenClaw 把AI 能力跟自动化能力之间的鸿沟实实在在地拉近了一大截。过去我想让 AI 帮我做点实际的事总得在脚本、接口、定时任务之间来回折腾现在它自己就能调度工具完成整条链路。当然它不是一个传上去就能跑的神器需要你动手配置技能、调整参数、设计异常处理但它比传统意义上的爬虫脚本、自动化工具聪明得多因为它具备了理解和判断的能力。如果你是个新手我建议你从最简单的场景开始不要一上手就整多代理和 ROS2 这种复杂组合。先搭一个能跑通的环境写一个整理下载目录级别的技能把它挂上定时任务运行一周你就能感受到数字员工的底子是怎么一回事了。等基础稳定之后再逐步加码去探索多代理协作、移动端值守这些进阶能力。实践过程中遇到问题别慌先看配置、再看日志、最后才怀疑模型能力——大多数坑都是前两个层面的问题。最后分享一个我私藏的小习惯每次改配置和技能之前我会在~/.openclaw/目录下先做一个备份因为 OpenClaw 的配置改动的调试成本不低备份能让你在改坏之后快速回退到可用状态。这个小动作已经帮我省了至少两次重装配置的功夫。你的数字员工能不能真正 24 小时在线靠的不是跑通那一下的激情而是这些看似琐碎但极其有用的工程习惯。 
长河君 · 2026/10/7 13:31:29 · 阅读 1.2k OpenClaw实战：部署AI代理框架，打造全天候自动化数字员工
1. OpenClaw 到底是什么OpenClaw 最近在 AI 圈子里的热度涨得很快。我第一眼看到这个名字的时候以为又是一款套了壳的聊天机器人后来仔细翻了一遍它的文档和社区讨论才发现这玩意儿跟普通聊天框完全不是一个物种。简单说OpenClaw 是一个开源的 AI 代理AI Agent框架它让大语言模型不只是陪你聊天而是能真正上手干活——读写文件、调用命令行、操作浏览器、执行定时任务甚至跨设备协同。很多人一听到AI 代理就头大觉得那是大厂研究部门才玩得动的东西。但 OpenClaw 的切入点恰恰是本地可部署、配置够简单、生态可扩展。它不强制你必须用某家云厂商的 API也不要求你有昂贵的 GPU 服务器只要你有一台能跑 Node.js 的电脑就能把 AI 变成一台 24 小时在线的数字打工仔。换句话说你睡觉的时候它在处理报表你在开会的时候它在整理项目目录你周末休息的时候它还在按计划执行自动化流程。这个项目的核心价值我认为可以概括成三句话第一把对话能力升级为执行能力第二把单次问答变成持续自动化第三把只能联网用变成本地私有化部署。对于程序员、运维、测试甚至是写文档、做数据分析的办公族这都是一个能实打实省时间的工具。所以这篇文章不是来介绍概念的我直接按我实际部署和使用 OpenClaw 的完整过程来写把我踩过的坑、试出来的最佳实践、以及配置细节全部摊开讲。想直接上手的人照着做就行。2. 部署与前期的环境准备2.1 先搞清楚 OpenClaw 运行需要什么OpenClaw 本质上是跑在 Node.js 环境下的一套代理框架所以最基础的要求就是你得有一台能稳定运行 Node.js 的机器。我这里说的机器范围很广Windows 台式机、Ubuntu 服务器、macOS 笔记本都可以甚至用 Termux 在安卓手机上跑也不是不行后面我单独讲移动端部署的玩法。硬件方面不用太焦虑。CPU 只要能跑 Node.js 就行内存建议至少 4GB因为 OpenClaw 本身占用不算高但如果你要同时跑本地大模型、浏览器自动化这些重活内存和磁盘就得多留一点。我在一台只有 4GB 内存的旧笔记本上跑过轻量级的 Qwen 模型日常任务处理问题不大但如果切换到 7B 以上的模型明显会卡。所以我的建议是如果你只是做任务编排和文件处理这类轻中度任务普通电脑完全够如果你想让它做复杂的代码生成或者长文本分析建议把 GPU 加到显存 6GB 以上或者干脆走 API 方式。安装之前先把基础环境准备好Node.js 18 以上版本、Git、以及一个包管理器npm 或者 pnpm 都行。Windows 下建议再装一个 PowerShell 7因为部分脚本在旧版 PowerShell 里会有兼容性问题。我自己第一次部署时就在这一步浪费了不少时间啥都没干先花半小时折腾环境版本后来学乖了所有项目统一用 nvm 管理 Node 版本哪里不对直接切换排查起来省心很多。2.2 Windows 和 Ubuntu 下的安装步骤这里我分开讲。Windows 安装我建议直接用项目仓库里的安装脚本或者手动 clone 仓库后执行安装命令。手动安装的好处是你能看清每一步做了什么出了问题也知道从哪里排查。大致流程是这样的git clone https://github.com/your-manual/openclaw.git cd openclaw npm install npm run setup这里要提醒一个很关键的细节npm install如果卡住绝大多数情况是网络问题导致部分依赖拉不下来。我遇到过很多次安装中断之后还得手动清理 node_modules 重新装。所以在国内网络环境下先把 npm 的 registry 换成国内镜像源能省掉后面一多半的坑npm config set registry https://registry.npmmirror.comUbuntu 上的安装思路类似但需要注意系统依赖。如果你的 Ubuntu 版本比较干净缺了 build-essential 和 python3编译某些原生模块时会报错。我踩过的坑是装bufferutil和utf-8-validate这两个包时编译失败最后装上 build-essential 就解决了。Ubuntu 用户在执行安装前先跑一遍sudo apt update sudo apt install -y build-essential python3 make g装完后第一次启动 OpenClaw 会进入一个引导式配置过程它会问你要不要检测网络环境、要不要生成默认配置目录等等。这一步不要一路回车跳过建议认真看一下。我就是最开始图省事直接默认配置结果后面所有模型接入都得重新改配置文件。OpenClaw 的数据和配置默认放在~/.openclaw/目录下后续改配置基本上都是在这个目录里操作。2.3 配置里的核心项逐一拆解OpenClaw 的主配置文件一般是~/.openclaw/config.yaml或者 JSON 格式取决于你用的版本。不管哪种格式核心配置项都围绕模型提供商和执行环境两块展开。模型提供商这里是最重要的一个环节。OpenClaw 的设计很聪明它把模型调用抽象成了一层接口下面可以挂不同的 provider。常见的有 OpenAI 兼容接口、Anthropic API、各类国产大模型 API还有我特别推荐的 Ollama 本地模型。配置一个 provider 的核心就是指定三个东西api_base接口地址、api_key密钥、model模型名。如果你打算用 Ollama 本地跑api_base 一般是http://localhost:11434/v1api_key 随便填一个占位符就行model 填你本地拉取的模型名称比如qwen2.5:7b。如果你打算走云 API就用官方提供的地址和 Key。配置文件大概长这样model_providers: primary: type: openai_compatible api_base: http://localhost:11434/v1 api_key: local-placeholder model: qwen2.5:7b执行环境这块OpenClaw 默认会给代理一个沙箱执行目录它只能在这个目录范围内读写文件别去动除非你明确知道自己在做什么。这个设计我很喜欢因为它相当于给 AI 划了一条安全线。我之前遇到过代理跑着跑着把日志文件写到用户主目录的情况就是因为手动改了 work_dir 却没配权限。改配置时work_dir、allowed_commands、max_steps这三个值建议一开始就设定好。allowed_commands决定了 AI 能调用哪些命令比如ls、cat、grep、python这类常用命令可以放行但rm -rf、sudo这种高风险命令默认最好别加白名单。2.4 Windows Companion 在做什么搜 OpenClaw 的时候很多人会看到windows companion这个词。这个 Companion 组件解决的问题是某些自动化操作在 Windows 原生环境下需要额外的权限或图形界面支持比如操作 Word、Excel 的 COM 接口或者调用系统级快捷键。OpenClaw 核心程序本身只是一个无头代理它没有 GUI而 Companion 就是架在中间的一层适配器。配置 Windows Companion 时核心是让 OpenClaw 主程序能找到并信任 Companion 进程。通常做法是把 Companion 编译成可执行文件放到指定目录然后在配置里声明它的路径和允许调用的能力范围。我测试过用它来让 AI 操作 Excel 表格确实能跑但速度比纯 Python 处理慢不少。如果你只需要处理 CSV 或 JSON我建议直接用脚本写操作逻辑做成 Skill效率高很多。Companion 更适合那些必须依赖 Windows 原生接口的场景比如 Outlook 邮件自动化、Excel 宏操作这类。3. 把模型接进来API 方式与本地模型3.1 云 API 接入换 Key 就能跑用云 API 是上手最快的方式。你只需要去你的模型服务商平台申请一个 API Key然后填进配置就行。以我常用的服务为例我将 OpenAI 的api_base、api_key、model写进配置之后启动 OpenClaw 再问一句帮我列出当前工作目录下的所有文件并统计行数它就能立刻开始调用工具执行。走云 API 的好处是模型能力强、上下文窗口大复杂推理不容易跑偏。而且现在国内可选的合规大模型 API 很多不少都提供免费额度够你日常玩一阵子。我建议新手第一次跑通 OpenClaw 用云 API因为你不需要先解决本地模型下载和显存的坑先建立任务下发—代理思考—工具调用—结果返回这个闭环感。跑通了再去折腾本地模型也不迟。有一个容易踩坑的地方很多 API 平台有访问限流和超时限制。OpenClaw 的默认请求超时时间可能跟某些平台的响应速度不匹配尤其当你的任务特别长、模型推理速度慢时容易在中间环节直接断掉。解决办法是在配置里把timeout调大比如设置成 300 秒。另外云 API 会产生费用我自己试过让它跑一个连续执行 20 分钟的任务消耗的 token 比我预想多不少。所以在正式任务前建议先在配置文件里开启 token 用量记录跑一次就心里有数了。3.2 本地模型与 Ollama 配合如果想完全离线跑Ollama 是一个绕不开的伙伴。OpenClaw 和 Ollama 的配合是我目前最推荐的本地方案。Ollama 负责把模型跑起来暴露一个 OpenAI 兼容的 HTTP 接口OpenClaw 通过这个接口调用模型。你甚至不需要额外写适配器直接把 provider 类型设为openai_compatible就好。Ollama 的安装我简单提一下Windows 和 macOS 都有官方安装包Ubuntu 下用官方脚本一键装。装完之后拉取模型我最早用的是qwen2.5:7b后来换成过llama3.1:8b也跑过phi3:mini。实测下来办公室自动化任务我用 7B 左右的模型就够了如果让它写代码逻辑比较复杂的东西我会切到 API 方式。配置上有一个细节值得注意本地模型的上下文长度受限于模型本身和你的内存大小。如果你给的 prompt 太长可能会把上下文撑爆代理就会丢失前面的对话状态。解决方案是两个方向一起用一是拉取模型时标注更大的上下文参数比如在 Ollama 里创建模型的 Modelfile 时设置num_ctx为 8192二是合理使用 OpenClaw 的会话压缩功能让代理在长任务中自动总结中间状态。这个我后面在技能设计部分再展开。3.3 API 和本地模型怎么选直接给结论追求效果选云 API追求隐私和稳定成本选本地模型两个都想要那就混搭——日常简单任务走本地复杂推理任务走云端。OpenClaw 可以同时配置多个 provider 并按规则切换这正是它被称为数字员工的原因之一你得像老板一样给不同员工分配最适合他的岗位。我自己的做法是用一个本地 7B 模型做文件管理、目录整理、定时提醒这些重复性较高的任务写代码、做数据分析报告的时候切到云 API。这套组合下来固定的 token 费用基本只有纯云方案的二分之一左右。需要注意OpenClaw 切换 provider 的策略配置在models段里你可以给每个模型设置标签和优先级。如果配置项比较陌生先别急着改复杂的路由策略把主 provider 和工作 provider 配好就够用了。4. 核心实操写一个 Skill 让 AI 自己干活4.1 Skill 到底是什么以及为什么要写OpenClaw 最吸引我的地方是它的 Skill 机制。Skill 翻译过来就是技能但跟你脑子里的技能不大一样。它本质上是把某一类任务的操作步骤、提示词、辅助脚本打包成一个目录放在 OpenClaw 的技能库里。你只要用自然语言提出需求代理会自动判断该用哪个技能来完成。比如我写了一个周报生成技能它就知道先去.txt或.md文件里收集这周的提交记录再读邮件草稿最后按模板生成周报文档。为什么必须用 Skill因为一个没有技能的裸代理像是一个很有潜力的应届生——你问他什么他都能聊但真要处理具体的业务流程他就开始瞎猜。而 Skill 相当于给他一本标准的操作手册告诉他每一步该做什么调用什么工具遇到异常怎么处理。我把 Skill 理解为成年人带 AI 上路手把手指定的操作 SOP。Skill 的目录放在~/.openclaw/skills/下面每个技能一个独立子目录。子目录里至少需要一个SKILL.md文件里面用结构化文本描述技能的触发条件和执行步骤。执行逻辑较复杂的场景可以放一个.py或.js脚本让代理调用。目录结构大概长这样~/.openclaw/skills/ weekly-report/ SKILL.md generate_report.py template.md4.2 配置技能的核心字段SKILL.md不需要写得很复杂关键是让代理能看懂什么时候用我以及怎么用我。我自己常用的模板如下--- name: weekly_report description: 生成项目周报收集本周 commit 记录按模板输出 markdown 周报。 trigger: 每周五、周报、本周进度 command: python3 generate_report.py allowed_context: work_dir/weekly_reports --- 执行步骤 1. 检查当前目录是否为 git 仓库若是则 git log --since7 days ago --prettyformat:%h %s。 2. 将步骤1的结果整理成列表。 3. 读取 template.md替换其中的占位符。 4. 将结果写入 work_dir 下的 weekly_report_YYYYMMDD.md。 5. 输出完成信息。这里trigger字段和description字段非常重要它们直接影响代理能否在合适的时候选中这个技能。我建议描述写得具体一点宁可啰嗦也不要写成生成周报这种一句话描述因为代理在识别任务时靠语义匹配描述越准确匹配率越高。command字段写的是代理需要调用的可执行入口。你可以让代理直接通过 shell 运行这个脚本也可以在步骤里拆成更细的命令。我倾向于把复杂逻辑写进脚本SKILL.md只保留最简步骤这样代理不容易在中间环节自由发挥跑偏。4.3 实战一个整理下载目录的技能我用一个非常生活化的例子说明整套流程。假设你希望 OpenClaw 每天凌晨把downloads目录里的文件按类型挪到对应文件夹。这个技能我命名为organize_downloads配置如下--- name: organize_downloads description: 按文件扩展名整理下载目录图片放到 images文档放到 docs压缩包放到 archives。 trigger: 整理下载目录、分类文件、downloads command: python3 organize.py --- 执行步骤 1. 扫描 work_dir/downloads 下所有文件。 2. 根据扩展名映射表把文件移动到对应子目录。 3. 输出每个分类的文件数量。 4. 对无法识别的类型放在 others 目录。配套的organize.py逻辑不复杂核心就是遍历、映射、移动。我记得第一次测试时发现一个问题如果有两个同名的文件被移动直接shutil.move会报错。后来我在脚本里加了一个带时间戳的改名逻辑。这也是我反复强调的——Skill 写完之后一定要自己先跑几轮边界测试你不可能指望 AI 一开始就完美处理所有异常情况。写好后你只需要对 OpenClaw 说一句帮我整理一下下载目录它就会自动匹配到organize_downloads然后开始执行。整个过程我不需要动一根手指。这背后实际上是一个意图识别 技能调用 脚本执行的完整链路也是我把 OpenClaw 称为数字打工仔的真正原因。4.4 设置定时任务让 AI 真正 7x24 小时工作前面提到24 小时数字员工靠手动下发指令还不够你还要让它能定时触发。OpenClaw 支持基于 cron 表达式的定时任务机制。你可以在配置里定义任务计划比如每天早上 8 点让 AI 检查邮件并生成待办清单每天晚上 10 点让 AI 把今天的开发日志归档。我配置一个简单的任务scheduled_tasks: - name: morning_check cron: 0 8 * * * prompt: 运行 morning_digest 技能整理今天的待办事项和日程输出到 daily_notes 目录。配置完重启 OpenClaw它就会按 cron 时间触发。这里有一个容易忽略的点计算机睡眠问题。如果设备睡眠定时任务不会执行。我一开始在笔记本上部署结果第二天早上发现任务根本没有跑。后来我把 OpenClaw 部署到一台常开的迷你主机上这个问题才算真正解决。如果你只有一台笔记本那就开启系统的不休眠计划。实测下来连续跑一周没问题但要注意散热和电池健康。5. 进阶玩法多代理协作、ROS2 与手机版部署5.1 多代理协作让几个打工仔分工解决复杂任务时单个代理往往容易在上下文中迷失。OpenClaw 支持多代理协作机制你可以定义多个不同角色的代理比如规划者、编码者、审查者让它们在一个工作流里分工配合。以我做过的一个数据分析任务为例规划者负责拆解分析步骤和产出指标定义编码者负责编写数据清洗脚本审查者负责检查脚本逻辑并最终输出报告。每个代理各管一段互相传递中间结果。配置多代理时最关键的其实是沟通边界。你得明确告诉每个代理它的输入是什么、输出要交给谁。否则会出现一种尴尬局面两个代理互相重复干活或者在等待对方结果时死循环。我在配置里为每个代理设定了max_steps上限一旦超过步数就强制终止并把中间结果上报。这是很有效的兜底策略。另外一个心得是多个代理之间传递的中间结果尽量用文件而不是纯文本。因为文件可以保存、追踪、校验在代理切换过程中不容易丢失上下文。我常用的做法是让 A 代理把结果写入 JSON 文件B 代理读取该文件继续处理。这比让代理在对话历史里保留大段文本要稳定得多。5.2 OpenClaw 与 ROS2、Gazebo 的联动很多人可能没想过OpenClaw 这类 AI 代理还能跟机器人仿真环境搭上关系。实际上将 OpenClaw 与 ROS2 结合是让 AI 通过自然语言操控机器人仿真任务的玩法。我在 Ubuntu 22.04 环境下试过搭配 ROS2 Humble 和 Gazebo让 AI 代理接收我下达的语义指令转换成具体的 ROS2 命令去驱动仿真环境里的机器人运行。这一堆关键字组合在一起看着吓人但拆开理解并不复杂OpenClaw 负责理解自然语言和决定调用什么函数ROS2 负责机器人底层通信和驱动Gazebo 负责提供一个仿真环境。OpenClaw 可以通过命令行接口发布ros2 topic pub或调用ros2 service call从而实现对仿真的控制。我的实验场景是这样的在 Gazebo 里加载一个差速驱动机器人我给 OpenClaw 说让机器人前进 1 米再原地右转 90 度代理就会自动执行一系列ros2命令。这一步听起来简单实际调通花了几天时间最核心的问题是权限和环境变量。OpenClaw 通过 shell 调用命令时默认环境下找不到 ROS2 的 setup 脚本路径。解决办法是在技能执行命令前先source /opt/ros/humble/setup.bash。如果你也打算走这条路必须把这一步写进技能的脚本里否则代理永远找不到ros2命令。5.3 安卓端 Termux 部署我原以为移动端部署属于能跑但不好用的鸡肋状态实际试过之后发现它的使用场景比我想象的多。特别适合做轻量级的提醒任务、信息抓取任务。Termux 是安卓上的终端模拟器支持安装 Node.js 和 GitOpenClaw 在里面的安装流程跟 Linux 很像但有几个障碍要先解决。安装 Termux 后第一件事是更新源和基础包pkg update pkg install nodejs git python接着安装 OpenClaw 同样依赖 Git clone 和 npm install。但是安卓文件路径比较特殊很多配置里写死的路径在移动端都会失效。我在配置 OpenClaw 的时候把所有绝对路径都改成了$(pwd)动态获取当前目录。另外Termux 在后台运行会被系统杀进程所以如果你想让它长时间在线需要在手机设置里关闭 Termux 的电池优化。我实测在手机上跑 7B 模型不现实内存扛不住所以手机上最好只做API 调用 技能执行的组合把复杂计算留给云端 API。5.4 如何让它真正 24 小时值守实现 24 小时值守的核心其实在于三件事一是任务要能自动触发定时任务或事件驱动二是代理要在异常退出后自动重启三是日志要能持久化方便事后复盘。我建议使用进程守护工具如 pm2 来守护 OpenClaw 主进程设置崩溃后自动重启。日志方面把输出写到独立文件pm2 start openclaw --name openclaw-agent pm2 logs openclaw-agent --lines 100我的经验是如果不设置自动重启半夜一次网络抖动就会导致代理进程退出早上一看啥都没干。用 pm2 之后连续运行一周基本不用管。这让我真正体会到了让它替我上夜班的感觉早晨醒来打开记录文件昨晚的任务清单已经全部跑完。6. 常见问题与排障实录6.1 快速排查表现象可能原因解决办法安装时 npm install 卡住网络源不稳定换国内 registry 镜像后重装启动时报模型连接失败api_base 或 api_key 配置错误检查 provider 配置项Ollama 地址确认是 localhost:11434定时任务不触发设备休眠或 cron 表达式不对开启休眠拦截用在线 cron 工具验证表达式代理执行操作权限被拒work_dir 或 allowed_commands 配置过窄手动调整白名单按需放行命令对话上下文太长后变笨上下文窗口被撑满开启会话压缩或换更大上下文模型Termux 后台被杀系统省电策略关闭电池优化设为前台服务6.2 我踩过的几个典型坑第一个坑是 Windows 下路径分隔符的兼容问题。OpenClaw 的技能脚本里我一开始用path/to/file这种 Linux 风格路径在 Windows 上跑就炸了。后来在写技能时统一用pathlib.Path处理路径终于消停了。如果你用的是 Windows写任何脚本时第一件事就别手写绝对路径和正斜杠代码习惯不好迟早踩坑。第二个坑是代理在执行命令时如果命令输出太多会把上下文瞬间撑爆。之前让它批量处理几千个文件的元信息结果输出内容全部堆在对话历史里直接导致后续步骤变慢。解决办法很简单在技能脚本里把输出汇总成摘要再返回别让原始明细全部暴露给代理。第三个坑是模型 provider 切换时的人格漂移。同一个任务用本地小模型跑和用云端大模型跑结果风格差异极大。如果你要求输出格式稳定最好在技能里明确指定输出模板并在 prompt 中强调格式要求不要在模型切换时才临时抱佛脚。我后来把所有输出型任务都配置了一个验证步骤如果生成结果不符合模板就让代理重新执行一次。这虽然额外花点时间但换来的是稳定和可控。6.3 经验技巧让代理任务失败时能自愈我强烈建议给每个正式任务都增加一个异常兜底环节不要在理想情况下能跑就不管不顾。我在技能里常用的方式是在脚本外层加try-except或者 shell 的||逻辑失败时给代理明确的提示和可选项。比如python3 generate_report.py || echo 报告生成失败请检查输入文件是否存在这样代理就知道往哪个方向排查而不是卡在一个错误上反复重试。更进阶一点的做法是让代理在失败后自行使用调试工具查看日志文件。坦白讲这个能力取决于模型的推理水平本地小模型经常做不到自动定位但云端大模型表现还不错。基于这一点我在重要任务上都走云 API。7. 写在最后我的实际使用体会我这一路从安装配置到写技能再到做多代理实验最大的感受是 OpenClaw 把AI 能力跟自动化能力之间的鸿沟实实在在地拉近了一大截。过去我想让 AI 帮我做点实际的事总得在脚本、接口、定时任务之间来回折腾现在它自己就能调度工具完成整条链路。当然它不是一个传上去就能跑的神器需要你动手配置技能、调整参数、设计异常处理但它比传统意义上的爬虫脚本、自动化工具聪明得多因为它具备了理解和判断的能力。如果你是个新手我建议你从最简单的场景开始不要一上手就整多代理和 ROS2 这种复杂组合。先搭一个能跑通的环境写一个整理下载目录级别的技能把它挂上定时任务运行一周你就能感受到数字员工的底子是怎么一回事了。等基础稳定之后再逐步加码去探索多代理协作、移动端值守这些进阶能力。实践过程中遇到问题别慌先看配置、再看日志、最后才怀疑模型能力——大多数坑都是前两个层面的问题。最后分享一个我私藏的小习惯每次改配置和技能之前我会在~/.openclaw/目录下先做一个备份因为 OpenClaw 的配置改动的调试成本不低备份能让你在改坏之后快速回退到可用状态。这个小动作已经帮我省了至少两次重装配置的功夫。你的数字员工能不能真正 24 小时在线靠的不是跑通那一下的激情而是这些看似琐碎但极其有用的工程习惯。