OpenClaw 2.0 发布后“打工人要被取代了”这个说法在社交平台上转得很火。先给一个冷静的判断OpenClaw 2.0 是一款本地运行的 AI Agent 工具核心能力是把大模型接到你的文件系统和命令行上让模型真正去“执行任务”而不只是“给建议”。它确实能自动化掉一批重复操作但离取代打工人还差得很远。真正值得花时间搞清楚的是怎么把它装好、怎么接模型、怎么控制权限、怎么让它稳定跑批量任务。下面按这个顺序来写适合想从零开始体验 Agent 工具、但不想被营销话术带偏的人。1. OpenClaw 2.0 是什么一个能真正“干活”的 Agent1.1 和普通聊天助手的差异在“执行”用过 ChatGPT、Kimi 这类产品的读者应该熟悉一个场景模型能给出完整方案但不会真的把你的文件改掉不会真的去终端里跑一条命令。OpenClaw 这类 Agent 工具补的正是这一步。它会申请一个工作目录workspace在里面创建、修改、删除文件它还能执行经过审批的命令调用安装好的 skill 来完成固定流程。所以在测试环境里它更像是“一个能自己写代码、自己跑命令、自己看结果的实习生”而不是只会给建议的顾问。中文社区里有人习惯叫它“龙虾”因为名字和形象都比较容易联想到这个花名。这不妨碍使用但解题思路要按 Agent 工具来理解模型负责“想”OpenClaw 负责“做”。1.2 2.0 重点不是“惊艳”而是“能日常用”从社区里大家问的问题来看2.0 发布后讨论最多的反而不是某个单一功能而是这些Windows 下能不能用 PowerShell 安装安装时能不能指定目录能不能接本地 Ollama 模型有没有便携包可以免安装体验配置 NVIDIA NIM 具体要怎么做怎么卸载干净。这些需求非常现实。说明 2.0 真正被关注的点不是模型能力突然强了多少而是整个工具在往“普通人能在普通电脑上稳定跑起来”这个方向靠。我的判断是这个版本值得关注的地方在于它把 Agent 从“能跑 Demo”推进到了“能日常使用”的状态。1.3 “取代打工人”为什么现在还谈不上说句实话Agent 工具最适合处理的是规则清晰、流程重复、结果可检查的任务例如批量重命名文件、按模板生成周报、定时抓取网页信息、自动整理某个目录下的文档。这些任务过去很占时间现在确实可以让 Agent 去跑。但要让 Agent 正确理解“为什么这个需求是这个样子”、判断输出结果是否合理、在模型抽风时及时刹车仍然需要人参与。更核心的是Agent 每一步命令执行都涉及安全审批、权限边界和误操作风险。工具跑得越快人对工具的约束就要越严格。所以“取代”这个词现阶段更适合改成“重新分工”。2. 装之前先确认运行条件系统、模型、目录缺一不可2.1 支持的系统和我推荐的安装顺序从大家搜索和提问的情况看目前主要跑在三个环境Windows 10/11用 PowerShell 安装、Ubuntu 服务器、macOS。Windows 用户还会遇到 Docker 方案比如本地装了 Docker Desktop 之后再跑一个 OpenClaw 容器。我的建议是第一次学习不要急着上 Docker。先把 CLI 装在宿主机上跑通一条任务再考虑容器化。Docker 虽然能隔离环境但同时引入了端口映射、卷挂载、网络模式这些额外变量报错时排查链路更长。搜索里还有一个高频问题“PowerShell 安装 OpenClaw 能指定目录吗”。这类安装脚本一般会支持指定目录但具体参数要看脚本的帮助输出。如果你想把工具装到非系统盘或者团队多用户共用就提前去查安装参数别默认一路回车装完再迁。便携包是另一条路解压即用、不写注册表适合临时体验。但便携版通常不会自动配置 PATH你需要手动把可执行文件加到环境变量或者每次用完整路径调用。2.2 模型怎么准备Ollama、云端 API、NVIDIA NIMOpenClaw 本身没有内置模型它是个执行框架真正的“大脑”要自己接。常见三类模型来源模型来源适合场景主要代价注意点Ollama 本地模型免费、离线、数据不出机器吃显存和内存小模型复杂任务容易出错云端 API含阿里云百炼等省事、模型能力强按量付费、需要联网密钥和服务域名要配对NVIDIA NIM有 N 卡、想自建推理服务门槛较高要确认显卡、驱动和容器环境这里单独说“自定义模型服务地址”。很多配置教程会提到把请求地址指向自建服务或第三方服务技术上就是让 OpenClaw 把模型请求发到你指定的地址。这个能力本身很常规但实际使用时要注意服务地址是否稳定、接口是否真的兼容、鉴权是否可靠。不要因为某个地址便宜就直接用在生产环境接口一旦限流或返回格式不规范Agent 任务会大面积失败。2.3 .openclaw 目录和 workspace先想清楚再动手安装并初始化后OpenClaw 会在用户目录下创建一个.openclaw文件夹。Windows 上常见路径是C:\Users\Administrator\.openclaw\Linux 上常见路径是/root/.openclaw/。里面会存放配置、日志、命令审批记录以及一个 workspace 工作目录。workspace 就是 Agent 默认能操作的文件范围。为什么要单独强调这个目录因为 Agent 工具的权限边界就是靠目录划分的。如果工作目录指向一个敏感项目Agent 读写的范围就很大如果让它随便执行命令误操作风险也高。我建议把 workspace 指向一个专门用来跑任务的空目录比如D:\AgentWorkspace或/data/openclaw-workspace。不要让 Agent 默认去操作你的文档目录、代码仓库根目录尤其是刚开始还不熟悉它行为的时候。2.4 容易被忽略的网络和依赖版本问题OpenClaw 要连接模型服务就需要网络访问模型 API。如果你在云端服务器上部署还要确认服务器能访问对应域名以及是否需要配置代理环境变量。这里不展开讲网络方案只想提醒内网环境、公司网络策略严格的环境往往不是工具本身装不好而是模型 API 的域名根本不通。测试时先手动请求一下模型服务地址能通再让 OpenClaw 去连。另外OpenClaw 更新后如果配置报错优先看更新日志里有没有迁移步骤再检查.openclaw目录下的配置是否缺了新字段不要急着删配置重来。3. Windows / Win11 安装实操从 PowerShell 到第一条任务3.1 安装方式、PATH 与“cmdlet 无法识别”报错Windows 下最常见的安装方式是 PowerShell 执行安装脚本。装完之后如果新开一个终端输入openclaw还是提示无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。先别急着重装大概率是三个原因安装没有真正结束脚本最后一步写 PATH 时被权限拦住了当前 PowerShell 会话还是旧的环境变量需要新开终端安装目录没有被加入 PATH。处理顺序是先确认可执行文件到底落在哪个目录再检查环境变量最后重开终端验证。如果安装脚本支持指定目录就把目录固定下来避免装在临时目录里之后找不到。3.2 初始化看到 “add ai later” 不用慌第一次运行openclaw时通常会有初始化流程让你确认配置目录和 workspace 路径。有些场景下还会提示是否现在添加 AI 模型或者显示类似 “add ai later” 的选项。看到这个不用慌它只是告诉你现在也可以不接模型后续再配置。我的建议是先把 CLI 本身跑起来哪怕只是查看帮助命令确认安装没有根本性问题再去配模型。这样如果后续模型接不上至少能分清是工具问题还是模型服务问题。3.3 第一条真实任务先做小样本验证配置完模型之后不要一上来就布置大任务。先让它做一个文件操作在 workspace 里创建一个测试目录写一个 markdown 文件再读取它、修改它。为什么先做这个因为文件读写是 Agent 所有高级能力的基础。如果文件操作都不稳定后续代码生成、批量处理、信息整理都会跟着出问题。任务跑完后去 workspace 里检查文件是否真的存在、内容是否正确。这一步验证的不仅是模型能力还有目录权限、配置路径和编码格式。这里最容易忽略的是“模型回复了但文件没有写入”。遇到这种情况先别怀疑模型去看 workspace 路径是否存在、是否有写权限再看模型是否返回了正确的结构化指令。很多空转问题都出在这个环节。3.4 更新通道stable 还是 devOpenClaw 提供了更新命令可以选择通道。社区里常见的是openclaw update --channel stable # 或 openclaw update --channel devstable通道适合日常使用更新节奏慢、功能相对稳定dev通道能提前体验新功能但可能引入行为变化或配置格式变更。我的建议很简单学习和尝鲜可以用 dev但如果你已经把它接入了飞书、微信这类日常工具或者跑着定时任务就停在 stable。搜索里有人提到旧的 exec approvals 记录存在比如legacy exec approvals exist at /root/.openclaw/exec-approvals.json这类提示一般就是版本升级产生的旧记录迁移提醒按提示操作即可不需要手动删文件。4. 模型接入是重头戏不同方案怎么选、怎么配4.1 Ollama 本地模型省钱但不要高估小模型本地 Ollama 是目前很多人最先尝试的方案因为免费、离线可用。先用一个 7B 到 14B 的模型跑通流程再根据机器配置决定要不要升级更大模型。这里给一个我实测时的参考思路8GB 显存以内的机器优先小模型而且要把上下文长度设短一点16GB 或更高显存可以尝试中型模型如果没有独立显卡纯 CPU 也能出结果但速度和并发都要降下来单条任务慢几倍都很正常。注意Ollama 启动后本身会占一个本地端口OpenClaw 配置模型地址时填的是 Ollama 提供的本地接口不是模型名称就行。还要确认模型是否支持工具调用或函数调用。Agent 任务经常需要让模型输出结构化调用指令如果模型不支持就会出现“模型答了但 Agent 没有执行任何动作”的情况。4.2 NVIDIA NIM适合有 N 卡、想自建推理服务的用户“OpenClaw 配置 NVIDIA NIM”是个出现频率不低的检索词。NVIDIA NIM 可以理解为把模型推理打包成标准服务OpenClaw 通过接口调用它。优点是在部分场景下性能和部署一致性更好适合已经在用 NVIDIA 生态的用户缺点是门槛高一些。需要确认显卡型号、显存、驱动、NIM 容器运行环境。如果你只是想在个人电脑上跑跑 Agent 任务Ollama 通常更快上手如果你在做团队内部工具或实验环境再考虑 NIM。4.3 云端 API 和自定义模型服务地址云端 API 是最省事的选择不用显卡只要有密钥、有网络就能接入。国内用户如果使用云厂商的模型服务比如阿里云百炼通常只需要把 API Key 和对应的服务域名填进 OpenClaw 配置。另外要理解“自定义模型服务地址”的含义。OpenClaw 一般允许你把请求地址改成任意符合接口规范的服务。这个功能听起来很灵活实际使用时要先做连通性测试确认返回格式兼容再接入正式任务。测试时可以用一个简单的请求脚本看模型服务是否正常返回内容。能返回再让 OpenClaw 去对接。不要跳过这一步很多“配置了没反应”的问题根源都在模型服务地址本身就不通。4.4 免费模型为什么容易“翻车”很多人想全程用免费模型跑 Agent。我的看法是可以试但要把预期降低。免费模型往往伴随限流、上下文窗口小、工具调用不稳定这些问题。上下文短的问题尤其致命。Agent 任务需要把系统提示、任务描述、文件内容、历史记录塞进上下文模型看不到关键内容就会答非所问。工具调用不稳定则会导致 Agent 不调用命令、不写文件任务直接空转。所以如果连续几次任务失败别急着怀疑 OpenClaw先换一个更强的模型试试。很多问题会直接消失。5. Workspace、Skills 和命令审批安全边界怎么控5.1 workspace 是双刃剑别把它当杂物间前面说了 workspace 是 Agent 默认的文件操作范围。实际使用中我建议把 workspace 当成一个独立项目目录不在里面塞不相关文件。原因有两点一是 Agent 在处理任务时会扫描目录内容目录太乱会增加误判二是如果任务写错了路径破坏范围会被限制在这个目录内。换句话说workspace 不是给你临时堆文件的地方而是你和 Agent 之间的“工作台”。保持干净任务成功率会明显更高。5.2 exec-approvals.json命令审批不是报错很多人在日志里看到类似这样一段legacy exec approvals exist at /root/.openclaw/exec-approvals.json第一反应是报错了。其实这是命令审批机制的提示。OpenClaw 在执行某些敏感命令之前会把规则或历史审批记录写在这个 JSON 文件里。Linux 下默认在/root/.openclaw/Windows 下在用户目录的.openclaw\下。它的作用简单说就是让 Agent 不会在没有约束的情况下随便执行命令。你可以在里面看到哪些命令被允许、哪些命令需要每次确认。我第一次看到这个文件时把它理解成“Agent 的执行白名单”这样就好懂了。如果你升级版本后出现这个提示一般只是旧记录需要迁移或确认不用手动删文件。5.3 Skills / ClawHub功能扩展和来源风险Skill 是 OpenClaw 的一大扩展点可以把一类固定操作封装成可复用的技能。比如写周报、整理资料、调用某个接口更新数据。社区里有类似 ClawHub 这样的技能分发渠道。它和 OpenClaw 自带能力的区别可以粗略理解为自带能力是基础工具ClawHub 是别人打包好的“技能模板”。使用技能时最该注意的不是功能而是来源。skill 本质上包含模型提示词和可能执行的命令逻辑如果来源不可信里面的命令可能做你不希望的事。任何时候安装第三方 skill 前先打开看看内容确认它要访问哪些文件、调用哪些命令。这一步花不了几分钟但能避免很多安全问题。5.4 runtime metadata 和进程日志排查时的入口搜索里有人提到 runtime metadata还有人用下面这条命令检查进程ps aux | grep -i openclaw这些东西都是排查问题时的入口。比如任务明明提交了但没有任何反应先用进程命令确认 OpenClaw 还在不在再用日志或 metadata 看任务处于哪个阶段。不要一上来就改配置。判断标准是先确认“运行没运行”再确认“卡在哪一步”最后才决定“要不要重启、改参数”。6. 进阶组合飞书、微信、Obsidian 和云端部署6.1 接入飞书、微信别把聊天入口变成安全隐患把 OpenClaw 接入飞书或微信是很多人想要的场景。好处很明显不用开终端直接在聊天里发任务Agent 跑完把结果回传。但这里有两个安全前提IM 机器人是公开入口必须做好账号绑定和权限校验否则任何人都能触发任务接入后建议把命令审批打开尤其是涉及服务器操作的命令。不要因为图方便而把审批关掉。一旦有人误触发清空文件、重启服务这类操作后果很难收拾。这个入口越方便权限约束就越要严格。6.2 Obsidian 做项目管理思路比集成插件重要如果只是单文件笔记Obsidian 和 OpenClaw 结合的意义不大真正有价值的是“用 Markdown 文件当任务清单”。做法很简单在 Obsidian 仓库里建一个 tasks 目录每个任务一个 md 文件里面写上状态、负责人、截止时间。OpenClaw 通过读写这些文件来更新状态。这样你仍然用 Obsidian 做日常记录Agent 负责处理重复更新。关键是约定好文件命名和字段格式。格式不稳定Agent 理解起来就容易出错。比如状态只允许todo / doing / done三个值比让 Agent 自由发挥稳定得多。6.3 和 Codex 这类编码 Agent 怎么选OpenClaw 和 OpenAI Codex 都是 Agent 形态但定位有区别。Codex 更偏向代码任务读代码库、改代码、跑测试、提 PR。OpenClaw 更像一个通用 Agent能处理文件、命令还能接 IM、做项目管理扩展点更分散。如果你目标很明确就是提升写代码效率用 Codex 这类编码 Agent 可能更直接。如果你是想要一个能接各种工具的通用自动化入口OpenClaw 的形态更合适。两者不是取代关系按场景选就行。我自己会保留两个工具编码相关的活给编码 Agent通用任务和定时流程交给 OpenClaw。6.4 云端部署和 Docker给定时任务一个稳定的家云端部署的好处是 7x24 小时在线适合定时任务和团队共用。常见架构是 Ubuntu 服务器 Docker把 OpenClaw 跑在容器里再接飞书机器人。部署时要注意三件事数据卷要挂载持久化.openclaw配置不能丢日志要输出到宿主机目录方便后续排查容器内模型服务地址如果是宿主机上的 Ollama要用宿主机网络而不是容器默认的网络地址。第一次部署时先手动起一个简单容器确认能访问模型 API再逐步加映射和挂载。不要一上来就把所有参数都配齐出问题时很难定位。7. 常见问题排查按这个顺序来别乱改参数7.1 命令找不到、启动失败类现象PowerShell 报“无法将 openclaw 项识别为 cmdlet...”或者启动命令没反应。优先级先看安装日志确认安装是否完整确认可执行文件所在目录检查 PATH 环境变量重开终端再验证。如果是便携包直接用完整路径验证一次能跑就说明文件本身没问题只是 PATH 没配好。7.2 模型不响应、任务空转现象任务提交后没有输出或者 Agent 只回复文本但没有执行文件或命令操作。优先级先手动请求模型服务确认地址和密钥能不能通再看模型是否支持工具调用不支持就换模型再看上下文长度是否太小放不下任务描述最后才考虑换更强模型。7.3 输出为空、文件操作失败优先级看输入文件格式和编码看 workspace 路径是否存在、是否有写权限看磁盘空间是否充足看 OpenClaw 日志里有没有具体报错。这类问题经常不是模型能力不够而是前置输入和环境没有处理干净。7.4 任务卡住、进程占用过高优先级用ps aux | grep -i openclaw或任务管理器确认进程状态看 CPU、内存、网络是否异常看是否在等待命令审批卡太久就停掉重跑但先保留日志再重启。7.5 一份可以抄走的排查顺序表现象第一件事第二件事第三件事命令找不到确认安装目录检查 PATH重开终端模型不响应手动请求模型地址检查工具调用能力换模型输出为空看输入格式看 workspace 权限看日志任务卡住看进程状态看资源占用保留日志后重启7.6 卸载和清理搜索里有人问 OpenClaw 怎么卸载。卸载不只是删程序文件还要清理用户目录下的.openclaw。建议顺序是先备份 workspace 里还需要的文件再执行官方卸载命令最后手动确认.openclaw目录是否删除。如果只是暂时不想用了保留.openclaw问题不大但它里面的审批记录和日志会占空间长期不维护建议清掉。最后说回“取代”这件事。我个人的观点是OpenClaw 2.0 这一类工具真正改变的是任务分配方式而不是岗位数量。它把“我自己花两小时做重复操作”变成“我花十分钟把流程定义清楚让 Agent 去执行我再检查结果”。能不能用得好关键不在于模型多强而在于你有没有把任务边界、目录权限、审批规则和验证标准定清楚。建议从单条任务开始跑通之后再上批量再谈接入 IM 和云端部署。踩过几次之后会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。
OpenClaw 2.0 本地 AI Agent 实战：安装、模型接入与安全配置
OpenClaw 2.0 发布后“打工人要被取代了”这个说法在社交平台上转得很火。先给一个冷静的判断OpenClaw 2.0 是一款本地运行的 AI Agent 工具核心能力是把大模型接到你的文件系统和命令行上让模型真正去“执行任务”而不只是“给建议”。它确实能自动化掉一批重复操作但离取代打工人还差得很远。真正值得花时间搞清楚的是怎么把它装好、怎么接模型、怎么控制权限、怎么让它稳定跑批量任务。下面按这个顺序来写适合想从零开始体验 Agent 工具、但不想被营销话术带偏的人。1. OpenClaw 2.0 是什么一个能真正“干活”的 Agent1.1 和普通聊天助手的差异在“执行”用过 ChatGPT、Kimi 这类产品的读者应该熟悉一个场景模型能给出完整方案但不会真的把你的文件改掉不会真的去终端里跑一条命令。OpenClaw 这类 Agent 工具补的正是这一步。它会申请一个工作目录workspace在里面创建、修改、删除文件它还能执行经过审批的命令调用安装好的 skill 来完成固定流程。所以在测试环境里它更像是“一个能自己写代码、自己跑命令、自己看结果的实习生”而不是只会给建议的顾问。中文社区里有人习惯叫它“龙虾”因为名字和形象都比较容易联想到这个花名。这不妨碍使用但解题思路要按 Agent 工具来理解模型负责“想”OpenClaw 负责“做”。1.2 2.0 重点不是“惊艳”而是“能日常用”从社区里大家问的问题来看2.0 发布后讨论最多的反而不是某个单一功能而是这些Windows 下能不能用 PowerShell 安装安装时能不能指定目录能不能接本地 Ollama 模型有没有便携包可以免安装体验配置 NVIDIA NIM 具体要怎么做怎么卸载干净。这些需求非常现实。说明 2.0 真正被关注的点不是模型能力突然强了多少而是整个工具在往“普通人能在普通电脑上稳定跑起来”这个方向靠。我的判断是这个版本值得关注的地方在于它把 Agent 从“能跑 Demo”推进到了“能日常使用”的状态。1.3 “取代打工人”为什么现在还谈不上说句实话Agent 工具最适合处理的是规则清晰、流程重复、结果可检查的任务例如批量重命名文件、按模板生成周报、定时抓取网页信息、自动整理某个目录下的文档。这些任务过去很占时间现在确实可以让 Agent 去跑。但要让 Agent 正确理解“为什么这个需求是这个样子”、判断输出结果是否合理、在模型抽风时及时刹车仍然需要人参与。更核心的是Agent 每一步命令执行都涉及安全审批、权限边界和误操作风险。工具跑得越快人对工具的约束就要越严格。所以“取代”这个词现阶段更适合改成“重新分工”。2. 装之前先确认运行条件系统、模型、目录缺一不可2.1 支持的系统和我推荐的安装顺序从大家搜索和提问的情况看目前主要跑在三个环境Windows 10/11用 PowerShell 安装、Ubuntu 服务器、macOS。Windows 用户还会遇到 Docker 方案比如本地装了 Docker Desktop 之后再跑一个 OpenClaw 容器。我的建议是第一次学习不要急着上 Docker。先把 CLI 装在宿主机上跑通一条任务再考虑容器化。Docker 虽然能隔离环境但同时引入了端口映射、卷挂载、网络模式这些额外变量报错时排查链路更长。搜索里还有一个高频问题“PowerShell 安装 OpenClaw 能指定目录吗”。这类安装脚本一般会支持指定目录但具体参数要看脚本的帮助输出。如果你想把工具装到非系统盘或者团队多用户共用就提前去查安装参数别默认一路回车装完再迁。便携包是另一条路解压即用、不写注册表适合临时体验。但便携版通常不会自动配置 PATH你需要手动把可执行文件加到环境变量或者每次用完整路径调用。2.2 模型怎么准备Ollama、云端 API、NVIDIA NIMOpenClaw 本身没有内置模型它是个执行框架真正的“大脑”要自己接。常见三类模型来源模型来源适合场景主要代价注意点Ollama 本地模型免费、离线、数据不出机器吃显存和内存小模型复杂任务容易出错云端 API含阿里云百炼等省事、模型能力强按量付费、需要联网密钥和服务域名要配对NVIDIA NIM有 N 卡、想自建推理服务门槛较高要确认显卡、驱动和容器环境这里单独说“自定义模型服务地址”。很多配置教程会提到把请求地址指向自建服务或第三方服务技术上就是让 OpenClaw 把模型请求发到你指定的地址。这个能力本身很常规但实际使用时要注意服务地址是否稳定、接口是否真的兼容、鉴权是否可靠。不要因为某个地址便宜就直接用在生产环境接口一旦限流或返回格式不规范Agent 任务会大面积失败。2.3 .openclaw 目录和 workspace先想清楚再动手安装并初始化后OpenClaw 会在用户目录下创建一个.openclaw文件夹。Windows 上常见路径是C:\Users\Administrator\.openclaw\Linux 上常见路径是/root/.openclaw/。里面会存放配置、日志、命令审批记录以及一个 workspace 工作目录。workspace 就是 Agent 默认能操作的文件范围。为什么要单独强调这个目录因为 Agent 工具的权限边界就是靠目录划分的。如果工作目录指向一个敏感项目Agent 读写的范围就很大如果让它随便执行命令误操作风险也高。我建议把 workspace 指向一个专门用来跑任务的空目录比如D:\AgentWorkspace或/data/openclaw-workspace。不要让 Agent 默认去操作你的文档目录、代码仓库根目录尤其是刚开始还不熟悉它行为的时候。2.4 容易被忽略的网络和依赖版本问题OpenClaw 要连接模型服务就需要网络访问模型 API。如果你在云端服务器上部署还要确认服务器能访问对应域名以及是否需要配置代理环境变量。这里不展开讲网络方案只想提醒内网环境、公司网络策略严格的环境往往不是工具本身装不好而是模型 API 的域名根本不通。测试时先手动请求一下模型服务地址能通再让 OpenClaw 去连。另外OpenClaw 更新后如果配置报错优先看更新日志里有没有迁移步骤再检查.openclaw目录下的配置是否缺了新字段不要急着删配置重来。3. Windows / Win11 安装实操从 PowerShell 到第一条任务3.1 安装方式、PATH 与“cmdlet 无法识别”报错Windows 下最常见的安装方式是 PowerShell 执行安装脚本。装完之后如果新开一个终端输入openclaw还是提示无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。先别急着重装大概率是三个原因安装没有真正结束脚本最后一步写 PATH 时被权限拦住了当前 PowerShell 会话还是旧的环境变量需要新开终端安装目录没有被加入 PATH。处理顺序是先确认可执行文件到底落在哪个目录再检查环境变量最后重开终端验证。如果安装脚本支持指定目录就把目录固定下来避免装在临时目录里之后找不到。3.2 初始化看到 “add ai later” 不用慌第一次运行openclaw时通常会有初始化流程让你确认配置目录和 workspace 路径。有些场景下还会提示是否现在添加 AI 模型或者显示类似 “add ai later” 的选项。看到这个不用慌它只是告诉你现在也可以不接模型后续再配置。我的建议是先把 CLI 本身跑起来哪怕只是查看帮助命令确认安装没有根本性问题再去配模型。这样如果后续模型接不上至少能分清是工具问题还是模型服务问题。3.3 第一条真实任务先做小样本验证配置完模型之后不要一上来就布置大任务。先让它做一个文件操作在 workspace 里创建一个测试目录写一个 markdown 文件再读取它、修改它。为什么先做这个因为文件读写是 Agent 所有高级能力的基础。如果文件操作都不稳定后续代码生成、批量处理、信息整理都会跟着出问题。任务跑完后去 workspace 里检查文件是否真的存在、内容是否正确。这一步验证的不仅是模型能力还有目录权限、配置路径和编码格式。这里最容易忽略的是“模型回复了但文件没有写入”。遇到这种情况先别怀疑模型去看 workspace 路径是否存在、是否有写权限再看模型是否返回了正确的结构化指令。很多空转问题都出在这个环节。3.4 更新通道stable 还是 devOpenClaw 提供了更新命令可以选择通道。社区里常见的是openclaw update --channel stable # 或 openclaw update --channel devstable通道适合日常使用更新节奏慢、功能相对稳定dev通道能提前体验新功能但可能引入行为变化或配置格式变更。我的建议很简单学习和尝鲜可以用 dev但如果你已经把它接入了飞书、微信这类日常工具或者跑着定时任务就停在 stable。搜索里有人提到旧的 exec approvals 记录存在比如legacy exec approvals exist at /root/.openclaw/exec-approvals.json这类提示一般就是版本升级产生的旧记录迁移提醒按提示操作即可不需要手动删文件。4. 模型接入是重头戏不同方案怎么选、怎么配4.1 Ollama 本地模型省钱但不要高估小模型本地 Ollama 是目前很多人最先尝试的方案因为免费、离线可用。先用一个 7B 到 14B 的模型跑通流程再根据机器配置决定要不要升级更大模型。这里给一个我实测时的参考思路8GB 显存以内的机器优先小模型而且要把上下文长度设短一点16GB 或更高显存可以尝试中型模型如果没有独立显卡纯 CPU 也能出结果但速度和并发都要降下来单条任务慢几倍都很正常。注意Ollama 启动后本身会占一个本地端口OpenClaw 配置模型地址时填的是 Ollama 提供的本地接口不是模型名称就行。还要确认模型是否支持工具调用或函数调用。Agent 任务经常需要让模型输出结构化调用指令如果模型不支持就会出现“模型答了但 Agent 没有执行任何动作”的情况。4.2 NVIDIA NIM适合有 N 卡、想自建推理服务的用户“OpenClaw 配置 NVIDIA NIM”是个出现频率不低的检索词。NVIDIA NIM 可以理解为把模型推理打包成标准服务OpenClaw 通过接口调用它。优点是在部分场景下性能和部署一致性更好适合已经在用 NVIDIA 生态的用户缺点是门槛高一些。需要确认显卡型号、显存、驱动、NIM 容器运行环境。如果你只是想在个人电脑上跑跑 Agent 任务Ollama 通常更快上手如果你在做团队内部工具或实验环境再考虑 NIM。4.3 云端 API 和自定义模型服务地址云端 API 是最省事的选择不用显卡只要有密钥、有网络就能接入。国内用户如果使用云厂商的模型服务比如阿里云百炼通常只需要把 API Key 和对应的服务域名填进 OpenClaw 配置。另外要理解“自定义模型服务地址”的含义。OpenClaw 一般允许你把请求地址改成任意符合接口规范的服务。这个功能听起来很灵活实际使用时要先做连通性测试确认返回格式兼容再接入正式任务。测试时可以用一个简单的请求脚本看模型服务是否正常返回内容。能返回再让 OpenClaw 去对接。不要跳过这一步很多“配置了没反应”的问题根源都在模型服务地址本身就不通。4.4 免费模型为什么容易“翻车”很多人想全程用免费模型跑 Agent。我的看法是可以试但要把预期降低。免费模型往往伴随限流、上下文窗口小、工具调用不稳定这些问题。上下文短的问题尤其致命。Agent 任务需要把系统提示、任务描述、文件内容、历史记录塞进上下文模型看不到关键内容就会答非所问。工具调用不稳定则会导致 Agent 不调用命令、不写文件任务直接空转。所以如果连续几次任务失败别急着怀疑 OpenClaw先换一个更强的模型试试。很多问题会直接消失。5. Workspace、Skills 和命令审批安全边界怎么控5.1 workspace 是双刃剑别把它当杂物间前面说了 workspace 是 Agent 默认的文件操作范围。实际使用中我建议把 workspace 当成一个独立项目目录不在里面塞不相关文件。原因有两点一是 Agent 在处理任务时会扫描目录内容目录太乱会增加误判二是如果任务写错了路径破坏范围会被限制在这个目录内。换句话说workspace 不是给你临时堆文件的地方而是你和 Agent 之间的“工作台”。保持干净任务成功率会明显更高。5.2 exec-approvals.json命令审批不是报错很多人在日志里看到类似这样一段legacy exec approvals exist at /root/.openclaw/exec-approvals.json第一反应是报错了。其实这是命令审批机制的提示。OpenClaw 在执行某些敏感命令之前会把规则或历史审批记录写在这个 JSON 文件里。Linux 下默认在/root/.openclaw/Windows 下在用户目录的.openclaw\下。它的作用简单说就是让 Agent 不会在没有约束的情况下随便执行命令。你可以在里面看到哪些命令被允许、哪些命令需要每次确认。我第一次看到这个文件时把它理解成“Agent 的执行白名单”这样就好懂了。如果你升级版本后出现这个提示一般只是旧记录需要迁移或确认不用手动删文件。5.3 Skills / ClawHub功能扩展和来源风险Skill 是 OpenClaw 的一大扩展点可以把一类固定操作封装成可复用的技能。比如写周报、整理资料、调用某个接口更新数据。社区里有类似 ClawHub 这样的技能分发渠道。它和 OpenClaw 自带能力的区别可以粗略理解为自带能力是基础工具ClawHub 是别人打包好的“技能模板”。使用技能时最该注意的不是功能而是来源。skill 本质上包含模型提示词和可能执行的命令逻辑如果来源不可信里面的命令可能做你不希望的事。任何时候安装第三方 skill 前先打开看看内容确认它要访问哪些文件、调用哪些命令。这一步花不了几分钟但能避免很多安全问题。5.4 runtime metadata 和进程日志排查时的入口搜索里有人提到 runtime metadata还有人用下面这条命令检查进程ps aux | grep -i openclaw这些东西都是排查问题时的入口。比如任务明明提交了但没有任何反应先用进程命令确认 OpenClaw 还在不在再用日志或 metadata 看任务处于哪个阶段。不要一上来就改配置。判断标准是先确认“运行没运行”再确认“卡在哪一步”最后才决定“要不要重启、改参数”。6. 进阶组合飞书、微信、Obsidian 和云端部署6.1 接入飞书、微信别把聊天入口变成安全隐患把 OpenClaw 接入飞书或微信是很多人想要的场景。好处很明显不用开终端直接在聊天里发任务Agent 跑完把结果回传。但这里有两个安全前提IM 机器人是公开入口必须做好账号绑定和权限校验否则任何人都能触发任务接入后建议把命令审批打开尤其是涉及服务器操作的命令。不要因为图方便而把审批关掉。一旦有人误触发清空文件、重启服务这类操作后果很难收拾。这个入口越方便权限约束就越要严格。6.2 Obsidian 做项目管理思路比集成插件重要如果只是单文件笔记Obsidian 和 OpenClaw 结合的意义不大真正有价值的是“用 Markdown 文件当任务清单”。做法很简单在 Obsidian 仓库里建一个 tasks 目录每个任务一个 md 文件里面写上状态、负责人、截止时间。OpenClaw 通过读写这些文件来更新状态。这样你仍然用 Obsidian 做日常记录Agent 负责处理重复更新。关键是约定好文件命名和字段格式。格式不稳定Agent 理解起来就容易出错。比如状态只允许todo / doing / done三个值比让 Agent 自由发挥稳定得多。6.3 和 Codex 这类编码 Agent 怎么选OpenClaw 和 OpenAI Codex 都是 Agent 形态但定位有区别。Codex 更偏向代码任务读代码库、改代码、跑测试、提 PR。OpenClaw 更像一个通用 Agent能处理文件、命令还能接 IM、做项目管理扩展点更分散。如果你目标很明确就是提升写代码效率用 Codex 这类编码 Agent 可能更直接。如果你是想要一个能接各种工具的通用自动化入口OpenClaw 的形态更合适。两者不是取代关系按场景选就行。我自己会保留两个工具编码相关的活给编码 Agent通用任务和定时流程交给 OpenClaw。6.4 云端部署和 Docker给定时任务一个稳定的家云端部署的好处是 7x24 小时在线适合定时任务和团队共用。常见架构是 Ubuntu 服务器 Docker把 OpenClaw 跑在容器里再接飞书机器人。部署时要注意三件事数据卷要挂载持久化.openclaw配置不能丢日志要输出到宿主机目录方便后续排查容器内模型服务地址如果是宿主机上的 Ollama要用宿主机网络而不是容器默认的网络地址。第一次部署时先手动起一个简单容器确认能访问模型 API再逐步加映射和挂载。不要一上来就把所有参数都配齐出问题时很难定位。7. 常见问题排查按这个顺序来别乱改参数7.1 命令找不到、启动失败类现象PowerShell 报“无法将 openclaw 项识别为 cmdlet...”或者启动命令没反应。优先级先看安装日志确认安装是否完整确认可执行文件所在目录检查 PATH 环境变量重开终端再验证。如果是便携包直接用完整路径验证一次能跑就说明文件本身没问题只是 PATH 没配好。7.2 模型不响应、任务空转现象任务提交后没有输出或者 Agent 只回复文本但没有执行文件或命令操作。优先级先手动请求模型服务确认地址和密钥能不能通再看模型是否支持工具调用不支持就换模型再看上下文长度是否太小放不下任务描述最后才考虑换更强模型。7.3 输出为空、文件操作失败优先级看输入文件格式和编码看 workspace 路径是否存在、是否有写权限看磁盘空间是否充足看 OpenClaw 日志里有没有具体报错。这类问题经常不是模型能力不够而是前置输入和环境没有处理干净。7.4 任务卡住、进程占用过高优先级用ps aux | grep -i openclaw或任务管理器确认进程状态看 CPU、内存、网络是否异常看是否在等待命令审批卡太久就停掉重跑但先保留日志再重启。7.5 一份可以抄走的排查顺序表现象第一件事第二件事第三件事命令找不到确认安装目录检查 PATH重开终端模型不响应手动请求模型地址检查工具调用能力换模型输出为空看输入格式看 workspace 权限看日志任务卡住看进程状态看资源占用保留日志后重启7.6 卸载和清理搜索里有人问 OpenClaw 怎么卸载。卸载不只是删程序文件还要清理用户目录下的.openclaw。建议顺序是先备份 workspace 里还需要的文件再执行官方卸载命令最后手动确认.openclaw目录是否删除。如果只是暂时不想用了保留.openclaw问题不大但它里面的审批记录和日志会占空间长期不维护建议清掉。最后说回“取代”这件事。我个人的观点是OpenClaw 2.0 这一类工具真正改变的是任务分配方式而不是岗位数量。它把“我自己花两小时做重复操作”变成“我花十分钟把流程定义清楚让 Agent 去执行我再检查结果”。能不能用得好关键不在于模型多强而在于你有没有把任务边界、目录权限、审批规则和验证标准定清楚。建议从单条任务开始跑通之后再上批量再谈接入 IM 和云端部署。踩过几次之后会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。