企业官网建设流程全解析

现在本地跑智能体（Agent）的项目越来越多了，但绝大多数都绕不开云端、收费、数据隐私这几个坑。我最近一直在折腾 OpenClaw 的本地部署，趁着刚把整套流程跑通，把这次从零开始的部署记录整理成文。如果你也想在 Windows 机器上完整跑起一个属于自己的本地 AI Agent，这篇文章应该能帮你少走不少弯路。

OpenClaw 是一个主打本地优先的智能体运行框架，核心思路是把 Agent 的决策、工具调用、记忆存储全部放在你自己的电脑上完成，模型层既可以用本地推理引擎，也可以接各类 API。对我这种习惯把敏感数据留在本机的人而言，这种架构天然有吸引力。整个部署过程涉及环境准备、模型接入、权限配置、Skill 扩展等好几个环节，我会把每一步为什么这么做、做了之后能看到什么效果都讲清楚，方便你照着操作也能顺利复现。

适合看这篇记录的朋友主要有三类：一是刚接触本地 Agent、想在 Windows 上先跑通一个 Demo 的开发者，二是已经在用各类云端 Agent 服务、想评估本地方案是否可行的技术选型者，三是单纯对本地大模型应用感兴趣、想找一份完整实操案例的爱好者。下面直接进入正题。

1. 部署前的完整思路与准备工作

1.1 为什么选择 Windows 本地环境

不少 Agent 框架对 Linux 友好，但 OpenClaw 官方对 Windows 的支持已经比较完整了，原生 PowerShell 就能跑。我这次用的是 Windows Server 2022 的机器，配置是 8 核 CPU、32GB 内存、无独立显卡。说实话这个配置跑大模型推理并不算强，但 OpenClaw 本身是个控制层，真正的推理压力在模型服务上，所以机器配置差一点也能先把 Agent 框架跑起来。

选择本地部署还有一个现实原因：我对数据出口这件事比较敏感。把对话记录、工具调用日志、中间思考过程全部交给云端，即便服务商承诺保密，心里总觉得不踏实。本地部署能让所有状态文件、审批记录、工作目录都落在自己的磁盘上，数据边界非常清晰。如果你也有类似诉求，那本地部署就不是一个可选项，而是必选项。

1.2 环境依赖清单与版本选择

动手之前最好先把依赖捋一遍，省得装到一半才发现缺东西。我这次实际用到的环境组件如下：

Node.js 这块要特别提醒一句：OpenClaw 对 Node 版本有要求，太老的 16.x 会出现依赖安装失败，太新的非 LTS 版本偶发兼容性问题。我建议直接装最新 LTS 版，实测最稳。Git 主要是用来拉取社区 Skill 扩展和检查更新用的，如果不打算折腾扩展，可以暂时不装。

Ollama 的选择是出于两层考虑。第一，它支持 OpenAI 兼容接口，OpenClaw 可以直接走/v1/chat/completions路径接入，省去写适配器的麻烦。第二，Ollama 默认把模型存放在用户目录下的.ollama/models里，卸载清理都比较方便。模型我一开始选了 qwen2.5:7b，后来换了 deepseek-r1:7b 做对比，两者在 OpenClaw 上的接入方式完全一致，只是在推理风格和速度上有差异，这部分后面细说。

1.3 网络环境与镜像源策略

本地部署最怕的就是下载环节卡住。OpenClaw 本体是一个 npm 包，安装时要拉取大量依赖，来源主要是 npm 官方源和 GitHub。如果你所在网络的访问速度不理想，我强烈建议提前把 npm 源切到国内镜像，命令是：

npm config set registry https://registry.npmmirror.com

这步做不做直接影响安装体验。我自己第一次装的时候没换源，光等依赖就耗了差不多四十分钟，中间还失败了一次。换了镜像源之后，整个安装过程压缩到了五分钟以内。需要说明的是，镜像源只解决 npm 包拉取速度问题，如果后续要克隆 GitHub 上的 Skill 仓库，网速瓶颈依然存在，这个只能靠代理或者换时间段解决，没有太好的办法。

2. 核心安装流程与关键配置

2.1 npm 全局安装 OpenClaw

依赖就绪后就可以正式安装了。OpenClaw 的安装命令非常简单，一条 npm 全局安装指令搞定：

npm install -g openclaw

安装完成后，系统会把可执行文件链接到全局 bin 目录。在 Windows 上通常位于 npm 的 prefix 目录下，比如C:\Users\Administrator\AppData\Roaming\npm。这个路径后面会用到，因为 PowerShell 能否直接识别openclaw命令，完全取决于这个目录是否在系统 PATH 环境变量里。

安装完成后建议先验证一下版本：

openclaw --version

如果输出一串版本号，说明安装成功且 PATH 配置正常。如果提示"无法识别 openclaw 项"，那不用慌，后面第 5 节有专门的处理方案。

2.2 初始化用户目录与工作区

OpenClaw 首次运行时会在当前用户目录下创建.openclaw文件夹，用来存储配置、日志、权限审批记录和工作区文件。比如在我的机器上，路径就是C:\Users\Administrator\.openclaw\workspace。

这里有个容易忽略的点：工作区默认路径和启动命令时的当前目录并不一定相同。官方推荐把所有 Agent 操作文件放在.openclaw\workspace下，这样统一管理，备份和迁移都方便。如果你有特殊需求，可以在配置文件中修改工作区路径，但我建议新手先用默认值，跑通之后再考虑定制。

初始化方式很简单，直接运行：

openclaw

首次启动会引导你完成基础配置，包括选择模型提供商、填写 API Key（如果需要）、设置工作目录等。整个过程是交互式的，按照提示操作就行。

2.3 模型接入层的两种选择

OpenClaw 本身不带模型，它需要对接一个推理后端。目前主流有两条路线：接本地推理引擎（Ollama、LM Studio 等）或接云端 API（DeepSeek 等）。两条路线我都试过，分别说下体验。

先讲本地推理。我的做法是先启动 Ollama 服务，然后拉取目标模型：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

确认模型能正常对话后，再回到 OpenClaw 的配置界面，添加模型提供商时选择 Ollama，API Base 填http://localhost:11434/v1，模型名填qwen2.5:7b。这样 OpenClaw 的每次模型调用都会走本地端口，请求不出本机，数据完全闭环。

再讲 API 接入。如果你觉得 7B 量级的本地模型聪明程度不够，接 DeepSeek 的 API 是目前性价比比较高的选择。配置时在模型提供商里选 OpenAI-Compatible，API Base 填 DeepSeek 的接口地址，模型名填deepseek-chat，再把 API Key 填进去就行。和接 Ollama 相比，只是换了个 Base URL 和模型名，其他逻辑完全一样。

2.4 首次启动时的交互式配置细节

第一次运行openclaw时，它会生成一个配置文件并进入交互式对话界面。这里我遇到一个比较关键的问题：默认模型如果配置的是本地 Ollama 服务，而 Ollama 还没启动，界面会报连接错误。所以一定要先保证 Ollama 在后台运行。

我建议把 Ollama 注册成 Windows 服务，或者用ollama serve开一个常驻终端。千万不要用ollama run来替代ollama serve，因为前者会进入交互对话模式，占用终端不说，OpenClaw 调用时反而容易出问题。

配置完成后，OpenClaw 还会要求你预览并确认配置信息。此时你会看到一个类似这样的输出：

workspace: c:\users\administrator\.openclaw\workspace add ai later:

如果确认无问题，回车继续即可。这个环节比较友好，所有配置项都集中展示，方便你对照检查。

3. 模型选型与推理性能调优

3.1 7B 量级模型在 OpenClaw 中的实际表现

模型选型是本地部署里最影响体验的一环。我先在 OpenClaw 里接了 qwen2.5:7b 跑了几天，总体感受是：对于工具调用、文件读写、简单问答这类 Agent 基础任务，7B 模型完全够用。但如果你要它做深度的多步推理，比如"分析这个目录下所有日志文件，找出异常请求模式并生成汇总报告"，7B 模型会显得吃力，中间偶发逻辑断层。

后来我把模型换成了 deepseek-r1:7b，明显感觉在推理步骤的连贯性上好了不少。R1 系列在思维链上有专门优化，虽然参数量一样，但在 OpenClaw 里执行多步骤任务时，出错的概率肉眼可见地降低了。代价是首字延迟更高，同样一个问题，qwen2.5 可能两秒就开始输出，deepseek-r1 要等五秒左右。这个取舍要看你的场景偏重实时聊天还是偏重任务执行。

3.2 Ollama 服务参数调优与性能记录

Ollama 在 Windows 上默认配置已经不错，但有几个参数值得手动调整。一个是并发请求数，默认值偏保守，如果你在 OpenClaw 里同时跑了多个 Skill 并且希望它们能并行调用模型，可以在 Ollama 的启动命令里加上/set parameter num_parallel 2。另一个是上下文长度，OpenClaw 在工具调用时会把当前会话的中间信息打包送给模型，上下文窗口太小会导致早期对话内容被截断。我用 Ollama 加载 qwen2.5 时，会在启动时指定：

ollama run qwen2.5:7b --num-ctx 8192

下面是两种模型在我这台无独显机器上的实测表现：

实测下来，纯本地方案的速度上限基本由 CPU 算力决定。32GB 内存跑 7B 模型是够用的，模型加载后占用大约 6GB 内存。如果你要跑 13B 或更大模型，建议内存至少 32GB，不然容易触发换页导致速度骤降。注意这里所有性能数据是在无 GPU 环境下测得，有独立显卡的话速度会快非常多。

3.3 云端 API 与本地推理的选型心得

我身边不少朋友问我一个问题：既然可以用 API，为什么还要折腾本地部署？我的回答是：两者解决的问题不一样。API 方案解决的是"效果优先"问题，本地方案解决的是"数据边界优先"问题。如果你处理的不是敏感数据，对推理质量又有较高要求，那直接接 DeepSeek API 是最省事的路径，部署时间可以压缩到 10 分钟以内。

但如果你像我一样，希望 Agent 的每一次工具调用都不经过第三方服务器，或者你有内部数据不能出网的硬性约束，那本地推理就是唯一选择。你可以先接 API 把整个 OpenClaw 的工作流验证通过，再切换到本地模型，用相同的配置跑一遍，看结果差异是否在可接受范围内。这种两步走的策略，能让你快速定位瓶颈到底是在框架层面还是模型层面。

4. 权限审批机制与 Skill 扩展实践

4.1 理解 exec-approvals 权限审批机制

OpenClaw 有一个安全设计让我印象很深：当 Agent 需要执行 Shell 命令时，它不会直接执行，而是会先写入一条审批请求，等待用户确认。这个机制的核心文件是.openclaw\exec-approvals.json，里面记录了哪些命令已被批准、哪些还在待审批状态。

第一次启动时如果你看到类似这条提示：

legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run `openclaw exec-approvals migrate`

意思是检测到了旧版本的审批记录文件，需要迁移到新格式。按提示执行迁移命令即可，不影响正常使用。这个机制的价值在于：Agent 再怎么自动化，Shell 命令这个层面始终需要人工兜底，能有效避免模型幻觉导致的误操作。

4.2 高效审批模式的个性化配置

对于高频命令，每次都弹审批会很烦。我的做法是把一些明确安全的命令预先加入白名单，比如文件读取、目录列表、git 状态查询等，这样既不牺牲安全，又能提升日常使用效率。

具体操作是在 OpenClaw 交互界面中，对某条命令选择"始终允许"，或者在配置文件里手动编辑exec-approvals.json。建议只对只读类命令做白名单处理，凡是涉及写操作、删除操作或网络请求的命令，最好保留逐次审批。这个度要你自己把握，总体原则是"可以懒，但不能全懒"。

4.3 基于 Skill 的自动化能力扩展

OpenClaw 的 Skill 机制有点像手机上的应用商店，每个 Skill 给 Agent 赋予一类新能力。比如接一个飞书通知的 Skill，Agent 就能在任务完成后主动把结果推送到飞书；接一个文档解析的 Skill，它就能理解 PDF、Word 等格式的文件内容。

Skill 的安装通常分两步：先将 Skill 仓库克隆到本地，然后在 OpenClaw 的配置里注册。以我安装的一个轻量项目管理 Skill 为例：

git clone https://github.com/some-user/openclaw-project-skill.git

然后把仓库路径写入 OpenClaw 的 Skill 配置目录。之后 Agent 就能通过自然语言指令调用这个 Skill。实测下来，Skill 扩展本身并不复杂，难点在于找到合适自己场景的 Skill，或者自己写一个，这需要你对 OpenClaw 的工具调用协议有基本了解。

如果你对项目管理有需求，网上有人把 Obsidian 和 OpenClaw 结合起来做项目管理的玩法，思路是用 Obsidian 管理知识库，OpenClaw 负责自动整理任务、生成周报，两者通过文件系统交换数据。这个玩法比较依赖本地文件结构的约定，但一旦跑通非常高效。

5. 常见问题与排查技巧实录

5.1 PowerShell 无法识别 openclaw 命令

这是我被问得最多的问题，也是 Windows 上部署 OpenClaw 最典型的坑。报错信息长这样：

openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

原因很简单：npm 的全局安装目录不在系统的 PATH 环境变量里，PowerShell 自然找不到可执行文件。解决办法是手动把 npm 全局目录加到 PATH。

具体操作：先运行命令查看 npm 的全局 prefix：

npm prefix -g

在 Windows 上通常输出C:\Users\Administrator\AppData\Roaming\npm。然后按下 Win 键搜索"环境变量"，在系统变量里找到 Path，点击编辑，把上面的目录加进去。保存后重新打开 PowerShell，再运行openclaw --version就能识别了。

5.2 迁移 legacy exec-approvals 提示怎么处理

有次升级 OpenClaw 之后，启动时突然出现开头提到的legacy exec approvals exist提示。我没有第一时间处理，结果发现所有 Shell 命令审批都被重置了，之前白名单全部失效。后来在官方文档里找到原因：新版改了审批记录的数据结构，需要显式迁移。

执行一条迁移命令即可：

openclaw exec-approvals migrate

顺便提醒一句：升级版本之前，最好把.openclaw目录整体备份一下。这个目录虽然不大，但里面装着你所有的配置、权限记录、工作区文件，一旦损坏恢复成本极高。

5.3 模型接入后对话无响应

模型配置正确但 OpenClaw 对话没反应，这个问题一般出在连接层。我的排查顺序是固定的：先确认 Ollama 服务在跑（ollama list能出结果），再用curl测试接口连通性：

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d "{\"model\":\"qwen2.5:7b\",\"messages\":[{\"role\":\"user\",\"content\":\"hi\"}]}"

如果 curl 正常返回但 OpenClaw 无响应，再检查配置文件里的 API Base 是否多了或少了末尾的斜杠。这个细节特别容易出错，http://localhost:11434/v1和http://localhost:11434/v1/在某些版本里都行，但如果你填的是http://localhost:11434少了/v1路径，那请求就会落到错误端点，自然没反应。

5.4 彻底卸载 OpenClaw 的两种方式

卸载这件事看着简单，实际有坑。如果你直接用 npm 卸载：

npm uninstall -g openclaw

程序文件会被删掉，但.openclaw用户目录下的配置和工作文件都还在，里面可能包含你之前所有会话记录和审批授权，属于敏感数据。所以卸载前一定要考虑是否需要保留。如果要彻底清干净，手动删除用户目录下的.openclaw文件夹即可。如果你用的是安装包装的，可以在系统的"添加或删除程序"里卸载，效果一样。

5.5 常见问题速查表

最后把这次部署和后续使用中遇到的高频问题整理成一张速查表，方便你有问题时快速对照：

6. 更新机制与日常维护建议

6.1 稳定版与 Dev 版的更新策略

OpenClaw 的迭代速度非常快，官方提供了两条更新通道：stable（稳定版）和 dev（开发版）。日常使用建议保持 stable 通道，命令是：

openclaw update --channel stable

如果你对某个新功能特别感兴趣，想提前体验，可以临时切到 dev 通道。但我在 dev 版本上踩过一次坑，某个中间版本在 Windows 上文件路径处理有 bug，导致工作区无法正常创建。所以我的建议是：除非官方公告里明确说明某个功能只在 dev 版可用，否则别轻易切通道。

另外，更新前务必确认一件事：当前有没有正在执行的 Agent 任务。有一次我在一个长任务跑到一半的时候执行了更新，结果进程被自动终止，任务状态没有正常保存。虽然不是严重事故，但重新跑一遍的时间成本挺高的。更新前先让 Agent 停下来，这算是我用自己的时间买来的一条教训。

6.2 数据备份与恢复的日常化

本地部署最大的优势是数据都在自己手里，但如果你不备份，这个优势也会变成劣势。磁盘故障、系统重装、误删文件夹，任何一个不幸事件都可能导致所有配置损失。

我现在的习惯是每周做一次.openclaw目录的整体备份，压缩后传到另一台机器或网盘。这个目录里最重要的是exec-approvals.json（所有权限审批记录）和workspace（工作区文件），这两块恢复成本很高，必须重点保护。配置文件本身不大，通常几百 KB 到几 MB，备份一次几秒钟的事，但能省掉未来数小时的重新配置时间，非常值得。

如果你在 Windows 上使用，还可以利用任务计划程序写一个简单的定时备份脚本，每周自动执行压缩和复制操作，这样连手动备份的精力都省了。

OpenClaw 这套东西我前后跑了差不多两周，日常任务比如整理 Markdown 笔记、批量重命名文件、定时抓取网页信息生成摘要，都已经交给它托管了。随着模型迭代，本地模型的推理能力也在逐步提升，这个方案的上限还有很大增长空间。我也在计划下一个阶段尝试接入更多 Skill，特别是把 Obsidian 的项目管理流程整体交给 OpenClaw 来编排，让整个本地的知识工作流形成一个真正的闭环，到时候有结果了再回来分享。