先说实话“AI 助手”这个词已经被各种产品用滥了大部分是聊天窗口里问一句答一句离“帮我干活”差得很远。我最近在 Windows 上完整搭了一遍 OpenClaw总算找到一个能把大模型、本地工具、自动化任务串起来的开源框架正好满足“全能智能工作助手”这个定位。这篇博文就把我从安装到实战配置的整个过程写出来包括踩过的“WSL 环境无法安全验证”这个经典坑。如果你是这类场景的受众——想在本地用 Ollama 或 Qwen 跑一个能自己调用工具的智能助手想用一个更轻量的 Agent 框架替代各种重型的商业方案或者单纯想看看 Agent 类项目该怎么落地——这篇文章会给出一份可以直接照做的参考。1. 项目拆解OpenClaw 要解决的真实问题1.1 “全能工作助手”到底是什么很多人在找“工作助手”的时候脑子里其实想的是一个能自动处理文档、整理信息、定时执行任务、根据指令操作电脑的 Agent。OpenClaw 解决的正是这个链条上的整理问题它把你手上的大模型 API 或本地模型作为决策大脑把 Skills技能作为手脚把任务编排逻辑做成一个可以持续运行的守护进程。简单说OpenClaw 是一个开源的智能体Agent运行框架它提供了一个核心调度器负责接收用户指令、拆分任务、调用模型、执行 Skill 并检查结果。一套 Skills 机制允许你用脚本或配置文件把各种操作封装成技能比如读文件、查日历、发通知、整理目录。多种模型接入方式既支持云端大模型 API也支持本地 Ollama 部署的模型这让隐私敏感场景也能用。一个 Windows Companion 组件目的是打通 WSL 和 Windows 原生能力比如剪贴板、窗口操作、系统通知。我更喜欢把它理解成一个“能给大模型装手脚”的框架。模型仍然是模型但有了 OpenClaw 之后模型输出的文本才能真正变成对电脑的操作指令而不是只停在聊天框里。1.2 为什么选择 WSL2 作为运行底座OpenClaw 在 Windows 上最推荐的运行方式是 WSL2。第一次看到这个要求的时候我也觉得有点绕明明 Windows 下能直接跑命令行工具为什么非要套一层 Linux 子系统实际用下来才明白OpenClaw 依赖大量 Linux 生态下的脚本工具和进程管理方式很多 Python/Node 库在 WSL2 下的兼容性远好于在 Windows 原生环境下折腾。Skills 机制本质上会频繁调用文件系统、路径解析、进程通信WSL2 的文件系统行为和 Linux 保持一致避免了一堆路径分隔符和权限的破事。更重要的是WSL2 是真正的轻量虚拟机资源隔离比传统方式更干净卸载也方便不会给 Windows 系统留一堆动态库和注册表垃圾。这个选择其实也暴露了一个现状Agent 类框架目前的主流开发环境仍然偏 LinuxWindows 用户想直接跑开源智能体WSL2 几乎是绕不开的中转站。接受这一点之后后面很多问题都好处理了。1.3 OpenClaw 的核心组件关系我在实际部署时把 OpenClaw 拆成三个层次来理解处理问题会清晰很多运行时层包括 Node.js 运行时、WSL2 子系统、OpenClaw 核心进程。模型层包括 Ollama 服务、已下载的模型文件、可选的云端 API Key。能力层包括 Skills 目录、配置文件、Windows Companion 进程。这三层互相独立出问题的时候可以一层一层排查。比如模型不响应先去 Ollama 里单独跑一下模型看是否正常比如 Skill 不触发先去检查脚本本身能否独立运行。核心组件的分离设计决定了这个框架的排障思路必须是“先独立验证再联合调试”。2. 环境准备先解决“SL2 环境无法安全验证”2.1 三条命令确认 WSL 状态我最初在 PowerShell 里启动 OpenClaw 安装脚本时直接弹出一句“无法安全验证 SL2 环境请在 PowerShell 中运行 wsl --status”。这个提示看着挺唬人其实就是 OpenClaw 的环境检测脚本发现 WSL 子系统的版本不对或状态不对。所以第一步永远不是急着装 OpenClaw而是先确认 WSL 本身健康。在 Windows PowerShell 里依次执行wsl --status输出里能看到默认版本、内核版本、分发版状态。如果提示“默认版本1”那就说明系统还在用 WSL1后面的步骤基本都会出问题。再执行wsl --list --verbose这一步可以查看已安装的 Linux 发行版。如果列表是空的说明你安装了 WSL 功能但还没有装任何发行版OpenClaw 当然找不到可用的 Linux 环境。最后确认内核wsl --update如果内核版本过旧先执行这个命令升级内核。我遇到的“无法安全验证”的情况90% 是内核更新被 Windows 更新策略卡住了手动执行一次就能解决。2.2 修复 WSL2 并确认版本当wsl --status里显示的默认版本还是 1 的时候需要执行wsl --set-default-version 2执行以后最好重启一次终端再执行wsl --status确认。如果系统提示需要启用虚拟机平台直接使用管理员权限执行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart这部分操作是 Windows 本身的功能开关不会影响系统的其他软件。我不建议跳过这一步直接去装 OpenClaw因为很多后面的报错根子上都是 WSL 版本不一致导致的间歇性问题。2.3 安装 Node.js 与 OpenClaw 本体OpenClaw 的核心进程基于 Node.js所以我先把 Node.js 环境准备好。这里有个小建议不要用 Windows 版本安装包装在 Windows 侧而是装进 WSL2 内部。因为 OpenClaw 跑在 WSL2 里如果 Node.js 在 Windows 侧跨系统调用会非常别扭。进入 WSL2 终端后执行curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs node -v npm -v确认 Node.js 版本高于 18OpenClaw 对太老的版本不友好。然后安装 OpenClaw 本体npm install -g openclaw openclaw --version如果一切顺利你会看到版本号输出。到这里最基础的环境已经通了。接下来要做的就是让这个框架能连上大脑——也就是大模型。3. 模型接入从云端 API 到本地 Ollama3.1 API 接入和本地模型怎么选OpenClaw 支持两种模型接入方式一种是通过 API 调用云端大模型另一种是通过 Ollama 接入本地模型。我的建议是优先把本地 Ollama 这条路走通再考虑 API。原因很简单本地模型不依赖外网连接调试 Skill 的时候响应稳定而且很多任务只是格式整理和信息抽取本地小模型完全够用。等你把整个流程跑顺了再切换 API 获得更强的推理能力也不迟。有朋友问过“OpenClaw 只能用接入 API 的方式使用算力吗”这其实是个误解。它更像一个调度器算力来自后端模型服务Ollama 就是本地算力最顺手的入口。3.2 Ollama 部署与 Qwen2.5-3B 示例在 WSL2 内部安装 Ollamacurl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:3b ollama serveollama serve会让 Ollama 在localhost:11434监听请求。这里注意一个关键点OpenClaw 在 WSL2 里访问 Ollama直接用localhost即可因为两者在同一个网络命名空间里。然后在 OpenClaw 的配置文件中添加模型配置。配置文件一般在~/.openclaw/config.yaml没有的话可以手动创建。核心内容类似model: provider: ollama base_url: http://localhost:11434 model_name: qwen2.5:3b temperature: 0.3温度参数我设置得比较低这是工作助手的通用设置。因为日常任务期望的是稳定输出不是创意写作温度太高容易让模型在生成 JSON 或操作指令的时候“发散”。3.3 模型参数与运行验证调整完配置后重启 OpenClaw 进程然后做一个最简单的最小化验证——直接问一个问题看它能不能基于当前模型给出回复。如果这一步通了说明 OpenClaw 到模型的链路是健康的后面配置 Skill 和 Windows Companion 时心理有底。如果请求超时优先确认 Ollama 是否还活着curl http://localhost:11434/api/tags能看到模型列表就说明 Ollama 正常。另外再确认 OpenClaw 的日志里没有出现端口冲突。Ollama 和 OpenClaw 最好别共用同一个端口否则会出现“模型能跑但助手不响应”的假故障。4. 用 Skill 把助手变成“真员工”4.1 Skill 的设计模式只接上模型那 OpenClaw 充其量是个高级聊天接口。真正让它从玩具变成工具的是 Skills。Skill 本质上是一个可被模型调用并执行的“动作包”。每个 Skill 由两部分组成一个描述自身功能和入参的元信息一段实际执行动作的代码或脚本。模型会根据用户指令判断应该调用哪个 Skill然后框架负责把参数传进去并执行。一个清晰的 Skill 应该满足三个条件单职责一个 Skill 只解决一个问题比如“整理目录”就别顺带“发通知”。输入输出明确入参是什么、出参是什么最好在描述里写清楚。可独立测试脱离 OpenClaw 也照样能跑这样排障时才不会互相甩锅。4.2 从零写一个文件整理 Skill这里我写一个实际跑过的 Skill作用是自动按文件扩展名整理目录。目录位置在~/.openclaw/skills/下每个 Skill 一个子目录。先创建描述文件skill.yamlname: organize_directory description: 将指定目录下的文件按扩展名移动到对应子目录比如图片、文档、压缩包 parameters: path: type: string description: 需要整理的目录路径 required: true然后是执行脚本run.pyimport os import shutil import sys target sys.argv[1] extension_map { .png: images, .jpg: images, .jpeg: images, .pdf: documents, .docx: documents, .txt: documents, .zip: archives, .gz: archives, .tar: archives, } for filename in os.listdir(target): ext os.path.splitext(filename)[1].lower() if ext in extension_map: dest_dir os.path.join(target, extension_map[ext]) os.makedirs(dest_dir, exist_okTrue) shutil.move(os.path.join(target, filename), dest_dir) print(fMoved: {filename} - {extension_map[ext]}/)最后重启 OpenClaw再对它说“把 /tmp/downloads 整理一下”模型就会读取 Skill 描述、拿到路径参数、执行run.py。整个过程就像给助手装了一只新“手”。多加几个这样的 Skill它才能算真正开始“工作”。4.3 绑定 Windows Companion让助手操作 Windows 原生能力模型本身跑在 WSL2 里但它执行的操作默认也只能局限在 Linux 环境。想让它操作 Windows 上的文件、发送系统通知、用剪贴板内容就需要 Windows Companion。Windows Companion 是一段运行在 Windows 侧的轻量服务进程OpenClaw 通过它来调用 Windows 的应用能力。配置方式不算复杂在 Windows 侧安装 Companion 组件一般跟着 OpenClaw 的 Windows 安装包一起装。启动 Windows 服务面板上的 “OpenClaw Companion”。在 OpenClaw 配置里启用windows_companion相关选项并指定允许的操作范围。我实际用来比较多的几个能力发送 Windows 通知、读取 Windows 剪贴板、打开本地文件目录。典型的场景是OpenClaw 在 WSL2 里完成了某个任务然后通过 Companion 弹一条 Windows 通知提醒我。这里有一个安全建议不要把所有 Windows 能力都开放给 OpenClaw。默认只开放你当前需要的比如通知和剪贴板读取。开放范围太大一旦模型被恶意指令引导代价会很大。5. 实战复盘搭一个“每日工作自动汇总”助手5.1 场景拆解与 Skill 编排光讲概念没意思我把我最近跑的一个真实场景完整拆出来给你看。需求每天早上自动读取指定目录里的工作日志文件汇总所有 TODO 和未完成事项生成一份简报文件然后通过 Windows 通知提醒我看。我把这个需求拆成四个 Skillread_directory扫描目录列出所有.md文件。read_file读取指定文件内容返回纯文本。extract_todos调用大模型从文本中抽取 TODO 和未完成事项。write_report把整理后的结果写入一个新的汇总文件并调用 Windows Companion 发通知。流程上OpenClaw 收到定时任务后会按顺序调用这些 Skill。每条 Skill 的入参来自上一条 Skill 的输出。这里需要做好中间件——也就是把文本在两套 Skill 之间传递的逻辑。为了让模型更容易组织流程我在配置里显式声明了 Workflowworkflow: - skill: read_directory params: path: /mnt/c/Users/me/worklogs - skill: read_file params: path_from: previous - skill: extract_todos params: input_from: previous - skill: write_report params: content_from: previous output_path: /mnt/c/Users/me/daily_report.md5.2 执行链路与效果实际执行的时候OpenClaw 的输出是一层层递进的。日志里能看到每个 Skill 的耗时、输入输出摘要和退出码。如果某个 Skill 出错它会直接停在那里不会自作主张继续执行后面的步骤——这个设计在 Agent 框架里非常重要宁可停下来等人处理也不要把错误结果一路传下去。跑完以后daily_report.md会自动生成Windows 侧也会弹出一条通知内容是“今日简报已生成”。这个流程从每天晚上写工作日志到第二天早上自动出报告已经在我这边稳定跑了将近两周。这段经验让我意识到一件事OpenClaw 这类框架能不能“干活”核心不在模型多强而在于你是不是愿意把日常重复动作拆成一个个稳定的小 Skill。模型是大脑Skill 才是肌肉。5.3 后续扩展微调、增量训练和更多 Skill当你把基础流程跑熟以后可以往两个方向升级。第一针对你自己的业务做小模型微调。比如我经常处理格式化很强的日志文本Qwen2.5-3B 基础模型虽然能抽取 TODO但偶尔会把日期格式搞错。为此我收集了一批标注好的工作日志样例对模型做了增量训练。微调后的模型在抽取准确率上明显提升而且因为模型是本地跑的整个数据闭环可以完全内部化。第二持续扩充 Skill 库。我后续准备加的几个方向包括定时备份配置、数据库查询接口、RPA 任务的启动与状态检查。每新增一个 Skill其实就是给助手增加一种操控现实世界的手段积累到一定数量之后它能覆盖的日常场景会越来越完整。6. 常见问题排查速查6.1 WSL 相关问题遇到最多的就是开头那个“无法安全验证 SL2 环境”。完整处理序列是wsl --status wsl --list --verbose wsl --update wsl --set-default-version 2执行完以后再跑一次openclaw --doctor或者环境检查命令确认所有项都通过。如果还是不行可以卸载当前发行版并重新安装 Ubuntuwsl --unregister Ubuntu wsl --install Ubuntu注意这会把 Linux 侧的已有数据清空建议先备份~/.openclaw目录。6.2 模型连接问题模型连接不上时按这个顺序排查curl http://localhost:11434/api/tags检查 Ollama 是否存活。检查 OpenClaw 的配置里base_url是否用了localhost而不是127.0.0.1两者在 WSL2 网络环境下偶尔行为不一样。确认没有多个 Ollama 实例在同时监听端口可以执行ps aux | grep ollama看看。如果模型加载慢可能是在消费磁盘 IO尤其是首次加载到内存的时候耐心等一下或者换更小的量化版本。6.3 性能与稳定性OpenClaw 长期挂着的话内存占用可能会缓慢上涨。我设了一个简单的定时重启机制每天凌晨三点重启一次 OpenClaw 服务同时清理日志。代价是可以接受的几分钟中断换来的是稳定运行。另外尽量避免在同一个 WSL2 实例里同时跑太多重型服务。我早期把 Ollama、OpenClaw、本地数据库全部塞在默认发行版里结果经常出现负载过高导致的响应超时。建议把内存占用大的服务拆分到不同发行版或者干脆限制 Ollama 的并发线程数。6.4 卸载与清理如果想彻底移除 OpenClaw最好的方式不是手动删安装目录而是先停进程再卸载 npm 全局包openclaw stop npm uninstall -g openclaw然后清理配置目录rm -rf ~/.openclawWindows Companion 则从 Windows 的“应用与功能”里单独卸载。因为 WSL2 的磁盘镜像会占空间也可以顺手执行wsl --unregister 发行版名称把整个 Linux 环境清理掉。尾声我的一点真实体会自己做智能工作助手这段时间最大的感受是“工具链的整合比模型本身更费心思”。模型选型、Skill 拆分、异常处理、定时任务每一步都在考验工程能力OpenClaw 的价值在于把这些拼图用一套还算清晰的规范串了起来。如果你也想搭一个自己的全能助手我建议别一上来就追求复杂功能先从“一个模型 一个 Skill 一个定时任务”做起把底座跑稳了再慢慢往上加。踩过几次坑之后你会发现真正好用的助手不是模型多聪明而是它背后的每个动作都足够可靠。