企业官网建设流程全解析

OpenClaw 2.0 发布后，“打工人要被取代了”这个说法在社交平台上转得很火。先给一个冷静的判断：OpenClaw 2.0 是一款本地运行的 AI Agent 工具，核心能力是把大模型接到你的文件系统和命令行上，让模型真正去“执行任务”，而不只是“给建议”。它确实能自动化掉一批重复操作，但离取代打工人还差得很远。真正值得花时间搞清楚的，是怎么把它装好、怎么接模型、怎么控制权限、怎么让它稳定跑批量任务。下面按这个顺序来写，适合想从零开始体验 Agent 工具、但不想被营销话术带偏的人。

1. OpenClaw 2.0 是什么：一个能真正“干活”的 Agent

1.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 NIM

OpenClaw 本身没有内置模型，它是个执行框架，真正的“大脑”要自己接。常见三类模型来源：

这里单独说“自定义模型服务地址”。很多配置教程会提到把请求地址指向自建服务或第三方服务，技术上就是让 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、函数、脚本文件或可运行程序的名称。

先别急着重装，大概率是三个原因：

1. 安装没有真正结束，脚本最后一步写 PATH 时被权限拦住了；
2. 当前 PowerShell 会话还是旧的环境变量，需要新开终端；
3. 安装目录没有被加入 PATH。

处理顺序是：先确认可执行文件到底落在哪个目录，再检查环境变量，最后重开终端验证。如果安装脚本支持指定目录，就把目录固定下来，避免装在临时目录里之后找不到。

3.2 初始化：看到 “add ai later” 不用慌

第一次运行openclaw时，通常会有初始化流程，让你确认配置目录和 workspace 路径。有些场景下还会提示是否现在添加 AI 模型，或者显示类似 “add ai later” 的选项。

看到这个不用慌，它只是告诉你：现在也可以不接模型，后续再配置。我的建议是：先把 CLI 本身跑起来，哪怕只是查看帮助命令，确认安装没有根本性问题，再去配模型。这样如果后续模型接不上，至少能分清是工具问题还是模型服务问题。

3.3 第一条真实任务：先做小样本验证

配置完模型之后，不要一上来就布置大任务。先让它做一个文件操作：在 workspace 里创建一个测试目录，写一个 markdown 文件，再读取它、修改它。

为什么先做这个？因为文件读写是 Agent 所有高级能力的基础。如果文件操作都不稳定，后续代码生成、批量处理、信息整理都会跟着出问题。任务跑完后，去 workspace 里检查文件是否真的存在、内容是否正确。这一步验证的不仅是模型能力，还有目录权限、配置路径和编码格式。

这里最容易忽略的是“模型回复了，但文件没有写入”。遇到这种情况，先别怀疑模型，去看 workspace 路径是否存在、是否有写权限，再看模型是否返回了正确的结构化指令。很多空转问题都出在这个环节。

3.4 更新通道：stable 还是 dev

OpenClaw 提供了更新命令，可以选择通道。社区里常见的是：

openclaw update --channel stable # 或 openclaw update --channel dev

stable通道适合日常使用，更新节奏慢、功能相对稳定；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 跑完把结果回传。

但这里有两个安全前提：

1. IM 机器人是公开入口，必须做好账号绑定和权限校验，否则任何人都能触发任务；
2. 接入后建议把命令审批打开，尤其是涉及服务器操作的命令。

不要因为图方便而把审批关掉。一旦有人误触发清空文件、重启服务这类操作，后果很难收拾。这个入口越方便，权限约束就越要严格。

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...”，或者启动命令没反应。

优先级：

1. 先看安装日志，确认安装是否完整；
2. 确认可执行文件所在目录；
3. 检查 PATH 环境变量；
4. 重开终端再验证。

如果是便携包，直接用完整路径验证一次，能跑就说明文件本身没问题，只是 PATH 没配好。

7.2 模型不响应、任务空转

现象：任务提交后没有输出，或者 Agent 只回复文本，但没有执行文件或命令操作。

优先级：

1. 先手动请求模型服务，确认地址和密钥能不能通；
2. 再看模型是否支持工具调用，不支持就换模型；
3. 再看上下文长度是否太小，放不下任务描述；
4. 最后才考虑换更强模型。

7.3 输出为空、文件操作失败

优先级：

1. 看输入文件格式和编码；
2. 看 workspace 路径是否存在、是否有写权限；
3. 看磁盘空间是否充足；
4. 看 OpenClaw 日志里有没有具体报错。

这类问题经常不是模型能力不够，而是前置输入和环境没有处理干净。

7.4 任务卡住、进程占用过高

优先级：

1. 用ps aux | grep -i openclaw或任务管理器确认进程状态；
2. 看 CPU、内存、网络是否异常；
3. 看是否在等待命令审批；
4. 卡太久就停掉重跑，但先保留日志再重启。

7.5 一份可以抄走的排查顺序表

7.6 卸载和清理

搜索里有人问 OpenClaw 怎么卸载。卸载不只是删程序文件，还要清理用户目录下的.openclaw。

建议顺序是：先备份 workspace 里还需要的文件，再执行官方卸载命令，最后手动确认.openclaw目录是否删除。如果只是暂时不想用了，保留.openclaw问题不大，但它里面的审批记录和日志会占空间，长期不维护建议清掉。

最后说回“取代”这件事。我个人的观点是，OpenClaw 2.0 这一类工具真正改变的是任务分配方式，而不是岗位数量。它把“我自己花两小时做重复操作”变成“我花十分钟把流程定义清楚，让 Agent 去执行，我再检查结果”。能不能用得好，关键不在于模型多强，而在于你有没有把任务边界、目录权限、审批规则和验证标准定清楚。建议从单条任务开始，跑通之后再上批量，再谈接入 IM 和云端部署。踩过几次之后会发现，很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。