最近社区里有个话题讨论度很高起因是周红伟那句OpenClaw CoworkOpenClaw Skills 人人可用的 Skills。乍一看像玩文字游戏真去部署一遍就会发现这句话把 OpenClaw 的两条主线全讲清楚了它不是一个聊天窗口而是试图把 AI 变成你的同事同时它把门槛压到了 Skills 这一层让人人都能通过装技能的方式给 AI 扩能力。这周我把 OpenClaw 在 Windows 和 Ubuntu 上各跑了一遍也用 Skills 接口做了几个小工具这里把部署过程、机制理解、踩坑记录一起写出来。如果你正在纠结“AI Agent 到底能帮我干什么”“别人说的 Skills 是什么”“部署 Agent 是不是要写很多代码”这篇文章应该能解决大半疑问。我不会只贴命令会把每个关键选择的为什么也说清楚方便你下次举一反三。1. OpenClaw 到底在解决什么问题1.1 从 Chat 到 CoworkAI 交互范式的转变过去一年我们习惯了“Chat”式交互你打字提问AI 回答。这种模式对聊天、翻译、写文案够用但真把它当生产力工具时会很别扭——每次都要你把上下文喂给它它没有记忆没有工具甚至不知道你项目目录里有什么文件。OpenClaw 主打的 Cowork 是另一种交互范式你给 AI 一个目标它自己拆解步骤、调用工具、读写文件、执行脚本最后给你交付结果。打个比方Chat 模式像是你对着一个“什么都知道但什么都不会干”的顾问Cowork 模式则像是你招了一个实习生你跟他说“把这份周报整理出来”他会自己打开文档、查找资料、排版输出。这里有个容易被忽略的点Cowork 不等于自动化脚本。脚本是固定流程AI Agent 是动态决策。OpenClaw 会在任务中途根据当前文件状态、工具返回结果来调整下一步动作。比如让它“把项目里的 TODO 梳理成任务清单”它会先去扫代码、识别 TODO 标记、再按模块归拢而不是执行一条写死的命令。从实际体感上说Chat 是“你负责想AI 负责说”Cowork 是“你们共同负责做”。这个转变才是 OpenClaw 真正想做的事。1.2 OpenClaw 的定位开源的“数字同事”很多人第一次看到 OpenClaw 这个名字以为它只是又一个 Claude 封装壳或者某个新出的聊天客户端。实际上它的定位更接近一个开源的 AI Agent 运行时你给它接上模型OpenAI、Claude、本地模型都行给它配好工作目录和工具环境它就变成了一个可以驻留在你机器上的数字同事。名字里的 Open 对应开源Claw 对应“抓住”任务。合起来就是一个能主动抓住任务并完成的开放 Agent 框架。它做的事情归纳起来就四件接收任务描述拆解执行计划调用已注册的工具终端、文件系统、API、浏览器等按需加载 Skills 技能包补齐特定领域知识输出结果并记录执行过程这套设计和大家熟知的 Codex、Claude Agent 思路同源但 OpenClaw 的特点是更偏“本地优先”和“Skills 优先”。它不强求你把它当云端服务用而是鼓励你在自己的电脑或服务器上部署把 Skills 当成第一公民——你想让 AI 会什么就给它装什么技能包。这种可插拔设计让它在“个人知识工作”场景下特别顺手。1.3 社区里关于 WorkBuddy 时间线的讨论最近热词里有一句很有意思“WorkBuddy 这种是不是也都参考了 OpenClaw 才搞出来的你觉得时间对得上吧”这个讨论在社区里挺热闹。我的看法是与其纠结谁抄谁不如承认这个模式已经成了共识。OpenClaw 早一点把“Agent Skills 本地部署”的组合做成了开源参考实现后面出现的同类产品无论是否参考了它的代码都在验证同一条路线——未来的 AI 使用方式应该是“协作式”的技能应该是可持续积累的。对普通用户来说重要的是这个模式本身已经成熟到可以拿来用了而不是去考证时间线。2. 部署与初始化把 OpenClaw 跑起来2.1 环境准备清单动手部署之前先把环境理清楚。OpenClaw 依赖 Node.js因为它本身是 JS 生态的项目工具脚本也大量复用 npm 包。我建议你按这个清单准备项目推荐配置说明Node.js20.x 或更高18 以下版本会报语法错误建议直接用 nvm 装操作系统Windows 10/11 或 Ubuntu 22.04Windows 建议启用 WSL2模型接入OpenAI API Key或本地 Ollama本地模型建议 7B 以上3B 只够跑简单任务终端PowerShell 7 / Windows Terminal别用老版 cmd编码问题会烦死你额外工具Git、curl拉仓库和跑安装脚本都会用到如果你暂时没有 OpenAI 或 Claude 的 Key也不要卡在这一步。OpenClaw 支持通过 Ollama 接本地模型qwen2.5-3b 这种小模型也勉强能跑通整个流程只是推理质量会明显下降。先用小模型把链路跑通再换强模型是更务实的路径。2.2 Windows 上的典型安装路径Windows 用户最常见的坑不是 OpenClaw 本身而是它的子环境。OpenClaw 很多工具操作走的是 Linux 命令行Windows 原生 cmd 对权限模型、路径处理、shell 脚本的支持都不完整所以官方推荐在 WSL2 里跑。热词里那句“openclaw 无法安全验证 WSL 环境请在 PowerShell 中运行 wsl --status”就是这里踩坑的典型。安装分三步走第一步安装 Node.js。如果你已经装了 nvm-windows直接在 PowerShell 里执行nvm install 20 nvm use 20没装 nvm 的话去 Node.js 官网下载 20 LTS 安装包一路下一步即可。装完在终端验证node -v npm -v第二步配置 WSL2。在管理员 PowerShell 里执行wsl --install装完重启系统然后执行wsl --update wsl --status重点看输出的版本号必须是 WSL 2 而不是 WSL 1。如果你发现版本是 1用wsl --set-version 发行版名称 2转换。这个校验经常被忽略但 OpenClaw 在启动时会主动检查检查不过就直接拒绝联动工具。第三步在 WSL 里安装 OpenClaw。进入 Ubuntu 终端后执行curl -fsSL https://openclaw.example.com/install.sh | bash安装脚本会帮你配置好默认目录~/.openclaw/和模型配置模板。装完执行openclaw doctor这条命令会检查 Node 版本、WSL 环境、目录权限、模型配置等输出有问题的地方比装完两眼一抹黑强得多。我建议新手无论如何都先跑一遍 doctor它比任何 README 都直观。如果你不想全程待在 WSL 的终端里可以额外装 Windows Companion 客户端。这个工具本质是一个系统托盘程序负责在后台拉起 WSL 里的 OpenClaw 服务这样你可以直接用 Windows 下的编辑器或命令行去调用它感知上更像在用本机软件。配置时注意两个路径别填错WSL 发行版名称和项目工作区路径。2.3 Ubuntu 与云服务器部署要点Ubuntu 上部署比 Windows 简单核心就几条命令。先确认 Node 版本够用node -v curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs然后装 OpenClawcurl -fsSL https://openclaw.example.com/install.sh | bash如果你是部署到云服务器比如有些云厂商会提供免费试用实例建议额外注意三点。第一用tmux或systemd把它跑成常驻服务否则 SSH 断开进程就没了。我用 tmux 最简单粗暴tmux new -s openclaw openclaw serve # CtrlB 再按 D 脱离会话服务继续跑第二模型 API Key 不要写在命令行历史里建议放到环境变量文件或配置文件里。第三如果你只把它当内部工具监听地址绑定127.0.0.1就够了别暴露到公网否则会有一堆扫描器来尝试调用你的 API账单上会多出莫名其妙的费用。3. SkillsOpenClaw 的灵魂3.1 Skills 到底是什么一个带说明书的功能包如果把 OpenClaw 比作操作系统Skills 就是安装到系统里的应用程序。每个 Skill 是一个目录里面包含了三样东西一份说明文档SKILL.md、若干可执行脚本scripts/、可能还有一些参考文档reference/。说明文档是给 AI 读的不是给人读的。它会描述这个技能在什么场景下使用、输入什么、输出什么、有哪些注意事项。AI 在接到任务时会先根据任务描述去匹配用户启用的 Skills 列表找到最合适的技能包然后读取它的说明文档再调用里面的脚本执行。我理解 Skills 最好用“新同事的 SOP 手册”来类比。公司来了新人你不可能把所有知识都提前塞进他脑子而是给他一本操作手册遇到巡检任务就看巡检 SOP遇到客户投诉就看投诉处理 SOP。Skills 就是给 AI 准备的 SOP 手册需要哪个场景就抽哪一份出来看。这种设计的好处是解耦模型本身的通用能力不需要变变的是挂在它身边的技能库。今天你给它装一个“前端开发”技能它就能写页面明天你拆掉这个技能换一个“论文写作”技能它又能写论文。不需要重新训练也没有额外的微调成本。3.2 从零开发一个 Skills目录、SKILL.md 与脚本开发一个 Skill 比想象中简单。我先展示一个最朴素的例子做一个“Markdown 文章格式化”技能它接收一篇草稿输出带规范标题层级和清单的 Markdown 文件。步骤一创建目录mkdir -p ~/.openclaw/skills/md-formatter/scripts cd ~/.openclaw/skills/md-formatter步骤二写SKILL.md。这份文档是 AI 理解该技能的唯一依据写得越具体AI 用得越准--- name: md-formatter description: 将任意 Markdown 草稿按规范格式化补充层级编号、整理无序列表、统一代码块语言标签。 when_to_use: 需要输出结构清晰的 Markdown 文档或现有草稿标题乱序、列表零散时。 --- # Markdown 格式化 输入一段 Markdown 文本。 输出格式化后的 Markdown 文本。 规则 1. 标题层级不允许跳级H2 必须有编号。 2. 列表统一使用 - 符号禁止混用 *。 3. 代码块必须标注语言类型。 4. 如果发现标题编号缺失自动从 1 开始补齐。步骤三写执行脚本。这个技能其实可以用 Node 或 Python 实现我图省事用 Node#!/usr/bin/env node // scripts/format.js const fs require(fs); const input fs.readFileSync(0, utf8); const lines input.split(\n); let h2Count 0; let h3Count 0; const output lines.map(line { if (line.startsWith(## )) { h2Count; h3Count 0; return ## ${h2Count}. ${line.slice(3)}; } if (line.startsWith(### )) { h3Count; return ### ${h2Count}.${h3Count} ${line.slice(4)}; } return line; }).join(\n); process.stdout.write(output);步骤四给脚本加执行权限chmod x scripts/format.js然后在 OpenClaw 会话里测试“请用 md-formatter 技能格式化以下文档”它就会调用这个脚本。整个流程没有一行框架代码你写的只是业务逻辑这大大降低了开发门槛。我的经验是开发 Skills 时不要在 SKILL.md 里写太多抽象话术直接给规则。AI 对“规则列表”的理解远好于对“良好风格”的理解。规则越接近代码逻辑它执行得越忠实。3.3 现成的 Skills 怎么找、怎么装如果你不想自己写社区里已经积累了不少技能包。热词里反复出现的 superpower skills、nature skills、frontend development skills 以及 codex skills都属于这一类。superpower skills 是一套面向通用推理能力的技能集核心是“慢思考”包含问题拆解、多方案评估、反向验证等子技能。它适合你在处理复杂任务时强制 AI 先规划再执行避免它一上来就瞎写。前端开发 skills 则聚焦 Web 开发场景能从设计稿描述生成组件、自动补充测试用例、统一代码风格。寻找途径主要有三个GitHub 搜openclaw skills、官方 Skills 库、以及社区博客里分享的合集。安装方式基本都是把仓库 clone 到~/.openclaw/skills/目录下git clone https://github.com/xxx/openclaw-superpowers ~/.openclaw/skills/superpowers装完后重启 OpenClaw 服务然后用openclaw skills list验证是否加载成功。需要注意两点不要同时给 AI 挂太多技能包模型在匹配技能时会犹豫不决反而降低准确率建议同类技能只保留一个最优的比如前端方向留一个就够。顺便回应热词里“skills 打开新世界”的说法——我第一次真正感觉“打开新世界”不是在装好 OpenClaw 那一刻而是在自己写完第一个 Skill 并让 AI 反复调用、最终输出一份完全符合预期的文档时。那一刻你才意识到这个体系是可生长的你每给它加一个技能它就多一项稳定能力像在给自己的数字同事做培训。4. 用 OpenClaw Skills 干一件实事4.1 场景选择让 AI 帮你搭一个前端页面理论说太多没用我拿一个完整场景走一遍流程。这次的目标是让 OpenClaw 使用“前端开发”技能给我生成一个响应式落地页并在生成后自动做一次基础代码检查。选择这个场景的原因前端样式类任务的评价标准非常主观纯靠 Chat 容易来回拉扯但把任务拆成“生成 HTML/CSS、检查标签闭合、检查响应式断点”这些子步骤后AI 的完成质量会稳定很多。这正是 Cowork 模式擅长的——把开放问题变成结构化任务。我在~/.openclaw/skills/下准备了一个前端技能包目录结构大致是frontend-dev/ ├── SKILL.md ├── reference/ │ ├── html-template.md │ └── css-rule.md └── scripts/ ├── scaffold.js └── check.js这个技能包预设了两条核心规则页面必须包含移动端断点CSS 样式必须使用 CSS 变量。这样 AI 生成的不是“能看”的页面而是“符合项目规范”的页面。实际做项目时规范才是生产力。4.2 实操流程从指令到交付物在 OpenClaw 会话里我发出的指令大概是这样的用 frontend-dev 技能为“OpenClaw 技能分享会”做一张 1024px 以上优先的响应式落地页。要求 1. 包含活动主题、时间、地点、报名 CTA 2. 使用 CSS 变量定义主题色 3. 生成完成后运行代码检查OpenClaw 会先读取frontend-dev/SKILL.md确认技能能力范围再调用scaffold.js生成初始项目骨架然后根据 SKILL.md 中提到的设计规则填充内容最后调用check.js做校验。check.js的逻辑很简单检查 HTML 是否存在未闭合标签、断点媒体查询是否齐全、CSS 变量是否被引用但未定义。如果发现问题它会自动修正或者把问题清单反馈出来。整个过程大约两三分钟交付物是一个index.html和一个styles.css。放在以前我手动写一个高质量落地页至少要半小时AI 生成的版本虽然不能直接上线但作为初稿已经完全合格。我更看重的其实是它的工作方式它是先读技能包规则再动手不是自己发挥自由发挥。这意味着你把团队的编码规范沉淀成 Skills 之后AI 会天然遵守这些规范而不是每次重新调教。4.3 和 Obsidian 联动把知识库变成技能库除了代码类任务OpenClaw 也能做知识工作。热词里有一条“openclaw obsidian”我一开始没搞懂这俩怎么结合后来试了一下就明白了Obsidian 是你的知识库OpenClaw 是执行引擎Skills 是两者之间的桥梁。操作思路很简单写一个“笔记检索与周报生成”技能让 AI 扫描指定 Obsidian 仓库里的文件按日期过滤最近新增/修改的笔记然后按照固定模板生成一周工作总结。这个技能不需要多聪明核心就是几条 Find 命令和一套格式化模板但它的价值在于把重复的“翻笔记、凑周报”动作彻底自动化了。我这里踩过一个坑文件路径里的空格。Obsidian 仓库里很多文件名带空格如果脚本没有做好转义AI 会反复报“文件不存在”。后来我在 SKILL.md 里明确写了“路径必须加引号”这个问题就再没出现过。这种小规则你指望模型自己想出来是不现实的写进技能包才是正解。5. 常见问题与排查技巧实录5.1 WSL 环境校验失败很多 Windows 用户第一次启动 OpenClaw 就报“无法安全验证 WSL 环境”然后卡住。这个报错核心原因就两种WSL 版本不对或者 WSL 内核版本太旧。按下 Win 键输入“PowerShell”右键以管理员身份打开执行wsl --status wsl --update如果wsl --status输出的是 WSL 1就执行转换wsl --set-version Ubuntu 2如果输出是 WSL 2 但仍然报错大概率是内核没更新执行wsl --update后重启 Windows Terminal 再试。注意改完 WSL 版本之后已经安装的 OpenClaw 不用重装但配置文件里的路径如果指向旧发行版目录需要同步修改。5.2 Node.js 环境与安装源问题OpenClaw 对 Node 版本有硬性要求低于 18 会直接跑不起来。如果你机器上同时存在多个 Node 版本建议用 nvm 统一管理。Linux 下的安装命令curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20 nvm use 20Windows 下用 nvm-windows命令基本一致。另一个常见问题是 npm 安装依赖时超时甚至失败。如果你遇到安装特别慢的情况与其干等不如直接配置更快的镜像源再来一次npm config set registry https://registry.npmmirror.com装完还是想改回官方源的话npm config set registry https://registry.npmjs.org5.3 Skills 加载了却不生效最闹心的问题就是技能装好了AI 就是不用。我排查下来原因一般在三个地方。第一Skills 目录位置不对。OpenClaw 只会扫描~/.openclaw/skills/下的一级子目录你放深了一层它就看不见。第二SKILL.md 里的 description 写得太泛。AI 是按描述匹配任务的你写“处理文档”任务说是“格式化文本”匹配度不高它自然不走这个技能。解决方案是把描述写具体一点多写几个该技能能覆盖的说法。第三脚本没有执行权限。Linux 下chmod x scripts/*是常见救法Windows 下则是检查脚本的换行符尽量用 LF避免 CRLF 导致执行异常。5.4 模型选型与本地小模型的取舍OpenClaw 接入本地模型是目前讨论热度很高的话题尤其像 qwen2.5-3b 这种小模型很多人想知道能不能带起来。我的实测结论是能跑通流程但质量受限。3B 模型做简单工具调用、读取文件、生成固定模板内容没有问题但让它遵循复杂的 SKILL.md 规则就力不从心了经常出现规则读一半就开干的情况。如果预算允许建议本地模型至少 7B 起步对外开放 API 的强模型优先用在复杂推理场景用户本地模型用来跑敏感数据和离线任务。模型能力分级这件事越早规划越省心。核心指标我也给你列出来模型规模简单工具调用复杂规则遵循推荐场景3B 以下勉强差测试链路、个人玩具项目7B - 14B良好中等日常文档处理、代码初稿API 大模型优秀优秀生产级任务、复杂推理最后说点个人心得。折腾 OpenClaw 这几天我最大的感受是“Skills 你得亲手写一个才理解它的价值”。看文档一百遍不如自己创建一个格式化技能跑一次。当你第一次看到 AI 调用你写的脚本、按你定的规则完成任务时那种“我在训练我的同事”的真实感会彻底改变你对 AI 工具的看法。最后分享一个小技巧给 Skills 做版本管理。我建议把~/.openclaw/skills/目录整个做成一个 Git 仓库每改一个技能就提交一次。技能描述的改动有时候会让 AI 行为发生明显变化有了版本历史出问题就能迅速回滚不用靠脑子记忆“上一版规则到底是什么”。这个习惯成本极低但长期收益巨大尤其当你技能包多到十几个的时候。