前阵子有个做运营的朋友问我有没有办法让 AI 不只是聊天而是自己打开浏览器、填表单、下载报表我第一反应是推荐了一堆 RPA 工具但后来发现他要的不是写死的流程而是“说一句话、电脑自己去办”的效果。研究了一圈最终落到了 OpenClaw 这个项目上。简单说OpenClaw 是一个开源的大模型电脑操作智能体框架它把大模型和鼠标键盘、命令行、文件系统、浏览器这些真实操作连接起来让 AI 从“对话框里的回答者”变成“屏幕前的操作员”。这篇文章我会结合自己的实际部署经验把 OpenClaw 的安装步骤、配置文件逻辑、模型接入方式以及它背后的“感知—规划—执行”原理一次讲清楚。如果你正好在折腾本地部署大模型或者想给自己的 AI 应用加一双“手”这篇应该能省你不少事。1. OpenClaw 到底是什么先把它放在 AI 应用栈的正确位置1.1 从“能聊天”到“会动手”大模型需要一副手脚现在的大模型不管是云端接口还是本地跑的开源模型本质上都是一个“文字进、文字出”的系统。你跟它说“帮我把这个文件夹里所有照片按日期重命名”它能给你写出一段 Python 代码甚至写得很好但代码不会自己运行文件不会自己改名。OpenClaw 解决的就是这个“最后一公里”问题。它相当于给大模型装上了一套“操作系统级别的接口”读取屏幕图像、移动鼠标、点击按钮、输入文字、执行 Shell 命令、读写文件、调用浏览器。用户只需要用自然语言描述目标剩下的拆解、规划、调用工具、检查结果都由模型在 OpenClaw 提供的框架里自动完成。很多人第一次听说 OpenClaw 会把它和 RPA机器人流程自动化混为一谈。差别其实很明显RPA 是“录下来再回放”流程是写死的页面一改就得重新录OpenClaw 是“理解目标再行动”每一步都是模型根据当前屏幕状态临时决定的页面改版、按钮位置变了它也能通过视觉去重新定位。这种灵活性是传统自动化工具给不了的。1.2 OpenClaw 能干什么不能干什么从我的实践来看OpenClaw 比较擅长这几类场景浏览器操作打开网页、搜索、填表、点击、提取页面内容。桌面应用控制操作本地 GUI 程序比如打开办公软件处理文档。命令行任务执行 shell 命令、跑脚本、看输出、根据结果决定下一步。文件与数据整理批量重命名、格式转换、读取 CSV 或 Excel 做简单分析。它不擅长什么也得说清楚。首先是涉及高精度、低延迟的工业控制类操作模型思考需要时间不适合做毫秒级响应的事情。其次是敏感场景下的资金操作、身份认证流程这类事情我建议永远不要让 AI 全自动跑审批机制必须开着。再就是上下文特别长的任务比如连续操作几个小时、中间涉及海量历史信息模型会逐渐“忘事”需要人工干预或分阶段执行。1.3 为什么我坚持“本地部署优先”OpenClaw 本身支持对接云端模型接口也支持本地模型。我个人的建议是只要机器条件允许优先把模型也放到本地。核心原因有三个。第一是隐私你会让 AI 操作电脑它必然要读取屏幕内容、文件内容这些数据经过网络送到第三方服务心理上总是别扭的。第二是成本高频操作任务会消耗大量 token长期用云端接口费用不低本地模型一次投入硬件成本后面基本是“电费换效率”。第三是可调试性本地部署时模型输出、工具调用记录都在自己手里出了问题能一条一条日志去查云端接口则像个黑盒。当然本地部署对硬件有要求尤其是模型需要具备视觉理解能力时显卡显存是硬门槛。这块我在后面模型选型部分会展开说先记住一个结论OpenClaw 的部署难度不高真正的门槛在模型选型和环境配置。2. 部署前的关键决策环境选型、依赖准备与模型路线2.1 系统选择Windows、macOS、Linux 到底哪个省心先给结论如果你想“少踩坑”首选 Linux其次是 macOSWindows 也能跑但要多花点心思。原因很现实。OpenClaw 这类智能体框架大量依赖进程管理、文件权限、Shell 环境这些在 Linux 和 macOS 上都是原生能力。Windows 的问题主要出在权限模型和命令环境上。很多人在 Windows 上装完发现命令执行报错、文件权限不对、莫名其妙的“你需要来自 Administrators 的权限”提示——这些我在第 6 章会专门讲排查这里先说省心程度。如果你手头只有 Windows 机器有两个能明显降低痛苦值的做法一是装好 WSL2把 OpenClaw 和模型运行时都放到 Linux 子系统里跑Windows 这边只负责显示和输入二是如果坚持直接在 Windows 原生环境装尽量用 PowerShell 7 而不是老的 5.1因为新版对 UTF-8 编码、符号链接的支持都更好很多诡异报错能少一大半。内存建议 16GB 起步32GB 不嫌多。大模型跑起来之后OpenClaw 自身进程、浏览器自动化进程、模型推理进程同时活着内存很容易吃紧。硬盘方面OpenClaw 本体很小真正占空间的是本地模型文件一个视觉模型动辄 8GB 到 40GB预留 50GB 以上比较稳妥。2.2 依赖安装与版本权衡不管哪个系统有几个基础依赖是绕不开的依赖版本建议用途说明Node.js18 LTS 或更高OpenClaw 主程序运行环境npm 包管理Git2.30拉取仓库、版本管理Docker最新稳定版可选用于容器化部署模型运行时或 OpenClaw 本身Python3.10部分工具链、脚本执行依赖Ollama最新稳定版可选本地模型运行时提供 OpenAI 兼容接口Node.js 的版本要注意一下。太老的版本比如 16 以下跑新版本 OpenClaw 会缺 API太新的 LTS 反而问题不大但不要太激进地追非 LTS 版本。社区里关于“OpenClaw 2.0”的讨论我经常看到主要涉及配置格式和审批机制的升级如果你是从旧版本升上来务必先看升级说明不要直接覆盖安装否则容易触发配置文件格式不兼容的问题——后面有一节专门讲这个。Docker 在什么情况下必须装如果你选择用容器方式跑 OpenClaw或者准备用 NVIDIA NIM、vLLM 这类容器化推理服务来提供模型能力那 Docker 就是必需的。如果你只是用 Ollama 直接跑模型、用 npm 直接装 OpenClawDocker 可以先不装减少一层资源开销。2.3 模型选型本地模型还是 API视觉能力为什么重要OpenClaw 操作电脑的核心链路里最关键的能力不是“会说话”而是“看得懂屏幕”。这就是为什么我建议选型时优先看具备视觉理解能力的多模态模型。纯文本模型不是不能用但局限很大。OpenClaw 内部有一个降级机制当模型没有视觉能力时它主要通过操作系统的可访问性接口Accessibility Tree来“感知”界面元素。这个方案在很多现代应用里是可行的但碰到自绘界面的软件、网页里的 canvas 元素、老旧的桌面程序可访问性接口经常拿不到有效信息任务就瘸腿了。视觉模型的选型思路看你的硬件条件显存 24GB 以上比如 RTX 3090/4090可以跑 Qwen 系列、GLM 系列等中等尺寸视觉模型效果能满足日常操作需求。显存 12GB 到 24GB需要选量化版本或者蒸馏后的小模型精度会有点损失。没有独立显卡别硬撑直接用云端 API 反而是更务实的选择。如果你选择本地路线Ollama 是最省事的模型运行时。它把模型下载、量化、GPU 加速、OpenAI 兼容 API 都打包好了一个命令就能把模型服务拉起来。具体怎么接入 OpenClaw我在 3.3 节会给完整配置示例。如果你在跑 NVIDIA NIM思路也是一样的NIM 本质上也是提供 OpenAI 兼容的推理服务只是封装得更企业化一些。3. OpenClaw 安装部署与初始化从零到能跑起来的完整过程3.1 主程序安装npm 与 Docker 两条路线怎么选OpenClaw 的安装目前有两条主流路线一个是 npm 全局安装一个是拉 Docker 镜像。我先把两条命令都放出来再说怎么选。npm 路线npm install -g openclaw openclaw init openclaw startDocker 路线docker pull openclaw/openclaw:latest docker run -it --name openclaw \ -v ~/.openclaw:/root/.openclaw \ -v /var/run/docker.sock:/var/run/docker.sock \ --network host \ openclaw/openclaw:latest两条路线的差别在于隔离性和集成度。Docker 路线的好处是环境隔离干净卸载也彻底适合不想把全局 Node 环境搞乱的人缺点是要处理容器和宿主机之间的文件、显示、网络共享配置复杂度高不少。npm 路线的好处是直接和系统环境打通操作鼠标键盘、读写文件、调用本机的 Ollama 服务都更自然缺点是全局环境会被污染安装和卸载都不够干净。我自己的选择是 npm 路线。原因很直接OpenClaw 的价值就在于操作本机把它关在容器里反而要额外解决一堆“容器访问宿主机 GUI 和文件”的问题属于自己给自己加戏。如果你确实有环境隔离的需求Docker 路线也完全可行但建议先用 npm 跑通再考虑容器化。注意不同版本、不同渠道安装的 OpenClaw命令入口可能略有差异。安装好后先执行openclaw --version确认版本再往下配置。版本太老的话很多配置项的名字对不上照着文档写也会报错。3.2 初始化与配置文件解析认识 ~/.openclaw第一次运行openclaw init会在用户目录下生成一个.openclaw文件夹这是 OpenClaw 的核心中枢。里面通常包括配置文件类似openclaw.json或claw-config.json全局配置模型接入、审批策略、浏览器设置都在这里。exec-approvals.json命令审批规则文件标记哪些命令允许自动执行、哪些需要人工确认。sessions/会话记录保存每一轮任务的历史消息方便回溯和恢复。logs/运行日志排查问题的主要依据。很多人在初始化之后会遇到一条提示legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run op...。看到这个别慌这不是错误是版本升级后的配置迁移提醒。旧版本里审批配置的格式比较自由新版本收紧了格式规范所以检测到旧文件时会提示你需要迁移。解决方式很简单先备份旧的exec-approvals.json然后看一眼提示里给的迁移命令执行完之后确认任务审批规则还在不在即可。如果迁移命令执行失败多半是旧文件里有非标准的规则写法把备份文件里不需要的规则删掉只保留核心条目再重试。配置文件里最核心的其实是两部分模型配置和审批策略。审批策略我会在原理章节展开这里先看模型配置——因为不把模型接上OpenClaw 就是一个空壳。3.3 接入模型后端以 Ollama 和 OpenAI 兼容接口为例OpenClaw 的模型接入设计很标准任何提供 OpenAI 兼容接口的服务都可以作为它的后端。这意味着一台机器上如果用 Ollama 跑着模型OpenClaw 只需要知道“去哪里找模型服务”就行。Ollama 安装完成后默认监听http://localhost:11434把模型拉下来即可ollama pull qwen2.5vl:7b-instruct模型拉好之后OpenClaw 配置文件的模型部分大致长这样{ model: { provider: openai-compatible, baseUrl: http://localhost:11434/v1, apiKey: ollama, modelName: qwen2.5vl:7b-instruct, temperature: 0.2, maxTokens: 4096 } }这里的几个参数我说明一下。apiKey填什么无所谓因为 Ollama 本地不校验密钥但字段必须存在否则会触发客户端的鉴权逻辑报错。temperature我建议设低一点0.2 左右比较合适因为操作电脑是个“精确活”不需要太多创造性温度高了模型容易自嗨输出一些不存在的工具调用参数。maxTokens不要设太小模型每生成一次工具调用的 JSON 结构都要消耗不少 token4096 是我的起点长任务我会调到 8192。如果你用的是 NVIDIA NIM配置思路完全一样只需要把baseUrl换成 NIM 提供的服务地址modelName换成对应的模型标识。整个行业在接口兼容性上已经形成事实标准了OpenClaw 能对接的远不止 Ollama 和 NIM只要遵守 OpenAI 兼容协议大部分推理服务都能接进来。配置完模型之后启动 OpenClawopenclaw start首次启动它会做环境自检检查模型服务是否连通、检查浏览器 driver 是否可用、检查权限配置。看到输出里模型连接成功的信息就说明基础链路已经通了。接下来先让它做一个简单任务比如“打开系统自带的计算器”先验证最基础的 GUI 操作能力。4. 原理拆解大模型到底是怎么“握住鼠标”的4.1 感知层先要“看得见”屏幕OpenClaw 要让模型基于真实屏幕状态做决策第一步是解决“看见”的问题。这一层目前主要有三条技术路线。第一条是截图 视觉模型。系统定时对屏幕截图把图像交给多模态模型理解模型从图像里“看”到当前打开了什么窗口、按钮在哪里。这条路线最通用对任何软件都有效但代价是每次截图都要经过视觉模型处理延迟高、token 消耗大。第二条是 OCR 坐标映射。系统先用 OCR 引擎识别屏幕上的文字把文字内容和坐标位置提取出来再以结构化文本的方式喂给模型。模型不需要真正“看懂图像”只需要根据文字位置推理应该点哪里。这条路线胜在速度快、成本低但对纯图标、无文字的按钮就无能为力。第三条是可访问性接口。系统通过操作系统的无障碍 API比如 Windows 的 UI Automation、macOS 的 Accessibility直接读取界面元素树得到按钮的名字、类型、坐标、状态。这是最精确、开销最小的方案但要求应用本身实现对无障碍协议的支持。OpenClaw 实际运行时不会只用一条路线而是根据当前任务和环境动态选择。桌面软件操作优先尝试可访问性接口失败则回退到截图视觉理解网页操作会结合 DOM 结构提取和截图能力。这种多模态感知的组合是它比单纯脚本自动化更“抗造”的关键。4.2 规划层任务被拆成工具调用的过程感知层把屏幕“翻译”给了模型接下来就是模型的主场把用户目标拆解成一系列可执行的工具调用。这个过程本质上是一个 ReAct 风格的循环。我给一个简化版流程系统把用户目标、当前屏幕感知结果、可用的工具列表一起组装成提示词发给模型。模型输出一个结构化的工具调用意图比如click(x854, y512)、type(texthello)、shell(commandls -la)。解析器把模型输出里的工具调用提取出来交给执行层去真的执行。工具执行完把结果截图、命令输出、错误信息作为“观察结果”追加到上下文中。带着最新的观察结果模型进入下一轮思考决定下一步动作。这个循环一直持续到模型认为任务目标已经达到或者触发停止条件。关键在于每轮循环都会把执行结果反馈给模型模型可以“看到”自己刚才点击之后的屏幕变化再决定怎么修正。这种“思考—行动—观察”的闭环就是 OpenClaw 能应对动态界面的底层原因。不过这个循环也有代价每一步都要走一遍完整的“模型推理”如果任务有 50 个步骤就是 50 次 API 往返延迟和消耗自然上去了。所以 OpenClaw 在工具调用策略上不是每个原子动作都交给模型而是支持“复合工具”比如一个“搜索并打开网页”的复合工具内部封装了一串标准操作模型只需要调用一次。这既是性能优化也是减少模型出错面的手段。4.3 执行层审批机制与安全护栏大模型操作电脑听上去很酷但危险也是真的。让模型自由执行 shell 命令意味着它可能在某个判断失误的瞬间运行rm -rf、下载恶意文件、修改系统配置。所以 OpenClaw 在执行层设计了一套审批机制这就是exec-approvals.json存在的意义。审批策略一般分几个等级。第一级是白名单配置里明确允许执行的命令模式这些命令直接自动执行比如ls、cat、python script.py。第二级是需确认命令匹配到某些危险特征比如包含rm、sudo、curl下载执行前弹出人工确认框用户点头才继续。第三级是完全禁用某些策略下干脆禁止模型调用指定的危险操作。我强烈建议第一次配置的人把审批策略设在中间档位允许低风险操作自动执行但所有涉及文件删除、系统修改、网络请求的命令都需要人工确认。等你对模型在当前环境下的表现有把握了再慢慢放宽白名单。这个机制是 OpenClaw 最值得称道的设计之一它承认了“模型可能犯错”这个事实并提供了兜底而不是假装 AI 永远正确。4.4 上下文管理与任务记忆还有一个容易忽略但决定任务成败的细节上下文管理。模型能力再强上下文窗口也是有限的。一个复杂操作每一轮感知结果、工具输出、思考过程都在消耗上下文空间到后面模型会“忘记”最开始的目标。OpenClaw 的解决方案是分层记忆。工作记忆保留在当前会话中存储最近的感知和操作记录超过窗口后做截断或摘要长期记忆则落到sessions/目录的文件里跨会话保留。实际遇到长任务执行到一半“跑偏”多半就是上下文被截断或摘要失真导致的。这部分的启示是不要把 OpenClaw 当成一个可以连续工作几小时的无人值守机器人它更适合“任务分块、逐步确认”的使用方式。这不是缺陷而是目前技术条件下的理性设计。5. 把 OpenClaw 用起来三个真实任务从配置到落地5.1 任务一打开浏览器搜索并整理核心信息第一个任务我建议从最常用的浏览器场景开始。目标是让 OpenClaw 打开搜索引擎查询“OpenClaw 最新版本”然后把搜索结果里的标题和链接整理成一个列表。任务提示词我建议这样写而不是一句话丢给模型请执行以下步骤 1. 打开默认浏览器 2. 在搜索框中输入“OpenClaw 最新版本”回车搜索 3. 读取搜索结果页找出前五条结果的标题和链接 4. 将结果整理成 Markdown 列表输出到屏幕上为什么强调分步骤因为实验下来把目标拆成显式步骤能让模型少走很多弯路。虽然理论上模型自己会拆解但提示词里给一个清晰的“脚手架”能显著降低它自由发挥的概率尤其是本地小模型这一步很关键。实际跑这个任务时常见的坑有两个。一个是浏览器驱动没配好OpenClaw 需要调用浏览器自动化接口第一次运行会有依赖下载网络不好时容易失败重试即可。另一个是模型输入的搜索框定位不准如果用的是截图加视觉模型页面加载慢可能会让它截到白屏。解决方法是把截图延迟设置大一点或者把任务分成“打开浏览器”和“搜索”两步减少单轮执行的复杂度。5.2 任务二批量整理本地文件第二个任务贴近日常把某个文件夹里所有文件名含日期的文件按年份子目录归档。这类任务测试的是 OpenClaw 的文件操作和 shell 命令能力。任务提示词可以这样写请扫描 /home/user/downloads 目录 找出所有文件名匹配 20240312 这种日期格式的文件 按年份如 2024创建子目录并把文件移动到对应目录。 在移动前先列出将要执行的操作清单确认后再执行。“确认后再执行”这句很有用。它会让模型在真正改变文件状态之前先把计划以文本形式输出一遍。因为我在审批策略里对mv命令设置了需要确认所以模型即使想直接执行系统也会拦住。两层防护叠加文件操作的安全性高不少。这个任务实测下来最容易出的问题是模型对“正则提取日期”的处理不够稳定。有时它会漏掉格式特殊的文件宁可多花几轮让模型先ls看清文件名再干活。另外日期文件命名格式要提前确认计算机的“日期格式”和人类的直觉之间差距可能很大。5.3 任务三跑一个数据处理脚本并读回结果第三个任务偏开发者向让 OpenClaw 执行一个 Python 脚本处理完数据后把关键结果讲给用户听。这个场景特别能体现“操作电脑”的价值因为不是每个使用者都会自己读 Python 输出。任务提示词请运行 /home/user/scripts/analyze_log.py 脚本会自动读取日志文件并生成 summary.txt。 运行完成后读取 summary.txt 的内容 把其中的核心指标列出来并用简单的话解释这些指标的含义。这里 OpenClaw 的执行链路是模型调用 shell 工具执行python命令得到返回码和输出确认脚本正常退出再调用文件读取工具打开summary.txt拿到内容后用自己的语言总结。整个过程不需要用户写代码、不需要手动打开终端一句自然语言就完成了。这类任务的坑集中在 Python 环境上。如果 OpenClaw 进程的 PATH 里找不到python命令或者脚本用的依赖没装全执行会直接失败。建议在任务提示词里直接指定完整解释器路径比如/usr/bin/python3 /home/user/scripts/analyze_log.py别赌环境变量。另外脚本输出如果是中文记得确认终端的编码设置有些环境下编码不对会出现乱码模型拿到乱码自然总结不出正确内容。6. 高频问题与排查实录我踩过的坑希望你别再踩6.1 高频问题速查表问题现象常见原因解决办法提示“需要来自 Administrators 的权限”Windows 下 OpenClaw 数据目录创建/写入失败检查~/.openclaw目录归属和可写权限用普通用户目录安装别放系统盘根目录model not found模型名称写错或本地服务未加载该模型在 Ollama 里执行ollama list确认精确名称连接模型服务超时baseUrl 写错、端口被占用、服务未启动先用curl http://localhost:11434/v1/models验证连通性legacy exec approvals exists警告旧版本审批配置与新版本格式不兼容备份旧文件按提示执行迁移命令只保留核心规则任务执行到一半卡死上下文截断、模型陷入工具调用死循环降低任务复杂度提高 maxTokens设置最大循环步数浏览器自动化失败浏览器驱动缺失或浏览器版本不匹配检查 driver 安装日志更新浏览器到稳定版本本地模型回答质量差模型太小或量化太狠换更大尺寸模型确认 GPU 显存足够避免 fallback 到 CPU点击位置总是偏移屏幕分辨率/缩放比例和系统假设不一致修正系统显示缩放设置或调整 OpenClaw 的屏幕坐标计算参数6.2 一个完整排查案例任务卡在“查找文件”这一步我之前调试过一个小任务让 OpenClaw 找到某个目录下的 Excel 文件并读取内容。任务很简单但它卡在“查找文件”这一步出不来翻来覆去地列目录、报错、再列目录。排查步骤是这样的。先看日志确认模型到底在做什么发现它在用find命令找文件但每次返回的结果都是空的。手动跑一下find发现目录路径没问题、文件也在问题出在 OpenClaw 执行命令时的工作目录和预期不一致。OpenClaw 默认工作目录是它自己的安装目录或用户目录而不是我任务描述里的绝对路径目录。之前模型生成的命令虽然写了目标目录但因为命令拼接方式的问题实际执行时被截断了。解决方法是改掉任务提示词的写法把路径变量写成可直接复用的形式并明确要求“每次命令都使用完整绝对路径不要依赖当前工作目录”。这个问题在新手阶段很常见因为人下意识以为 AI 会像自己一样知道“当前在哪个目录”但实际上模型的每个命令都在独立的执行环境里全局状态并不牢靠。排查过程中还有一个非常管用的手段把 OpenClaw 的日志级别调到 debug然后跟着每一步工具调用的输入输出看。它能无死角地告诉你“模型想干什么、系统执行了什么、结果是什么”所有看似玄学的问题最终都能在日志里找到答案。6.3 长期稳定运行的几点个人心得跑了一段时间 OpenClaw 之后我总结出几个让整个系统更稳定的经验。模型层面如果条件允许把视觉模型和文本规划模型分开配置会更好用。视觉模型负责理解截图文本模型负责任务规划和工具调用决策各干各擅长的。虽然 OpenClaw 默认允许单模型跑通全部环节但“多模型各司其职”的上限明显更高。提示词层面任务描述里的目标和约束写得越明确成功率越高。特别是涉及文件操作时一定在提示词里加一句“操作前先展示计划确认后再执行”这句话能帮你挡住一大半误操作。系统层面养成看日志的习惯。不要等到任务失败了才去翻日志跑任务的过程中偶尔瞄一眼logs/下的最新输出经常能在模型刚跑偏的时候就及时发现省得浪费一整轮。最后审批机制永远不要全关。即使你对当前模型表现已经很有信心也要保留关键操作的闸门。OpenClaw 这类工具的使用哲学是“让 AI 干活但把把关权留在自己手里”。我个人在实际操作中的体会是OpenClaw 这类项目最打动我的不是“AI 完全自主操作电脑”这个口号而是它给出了一套务实的中间态该自动的自动该确认的确认模型能力不够时靠架构设计来补。把期望调整成“AI 把活儿干到八成剩下两成由我来收尾”你用它做事的幸福感会直线上升。最后再分享一个小技巧写任务提示词时尽量用“先……再……最后……”的步骤式表达而不是一段散文式的目标描述。同样是让 AI 操作电脑前者成功率能高出不少。这背后是一个朴素的道理——你把路线画得越清楚它跑偏的概率就越低。