企业官网建设流程全解析

OpenClaw 本地部署实录：2 分钟装好环境，再接上大模型 Key 和 Skill 才算完整

如果你最近在逛 AI 社区，大概率见过 OpenClaw 这个名字。简单说，它是一个开源的智能体（Agent）运行框架，最早是 Clawdbot/Moltbot 这类托管服务的平替方案，后来因为本地化部署方便、 Skill 机制灵活，慢慢变成了很多人在自己电脑上跑 AI 助理的首选。它能做到的事情包括：挂上大模型 API 后自动执行任务、定时跑脚本、读写本地文件、调用外部工具，还能通过安装不同的 Skill 扩展能力边界。

这篇博文的核心内容就三件事：怎么在本地把 OpenClaw 快速装起来、怎么把大模型 API Key 配好、以及怎么把 Skill 集成进去。我尽量把每一步都写清楚，包括中间踩过的坑和网上文档里没细说的细节。适合想入门本地 AI Agent、但是不想折腾太久的朋友参考。

1. 为什么选 OpenClaw：先搞懂它解决什么问题

动手安装之前，先花两分钟想清楚一个事：OpenClaw 到底解决了什么问题？这决定了你后面怎么用，也决定了遇到报错时往哪个方向排查。

市面上能跑 Agent 的框架不少，比如 Dify、Coze、AutoGPT，还有各种开源项目。OpenClaw 的差异点在于它把“壳”和“大脑”拆得很干净。底层大模型可以随意换，本地部署的 Ollama、各家云 API 都行，框架本身不做模型训练，只管调度、记忆、工具调用和 Skill 生命周期。这种设计带来的直接好处是：你可以先用便宜的 API 跑通流程，之后再无缝切到更强的模型，代码和 Skill 都不用动。

再说 Skill 机制。OpenClaw 里的 Skill 本质上是一组指令加脚本的集合，装进指定目录后，模型在对话或执行任务时能自动感知并调用。打个比方，大模型像一个刚毕业的员工，能力很强但不知道公司流程；Skill 就是给他配的 SOP 手册和工具箱。没有 Skill 的 OpenClaw 只能做简单对话，装上 Skill 之后才能干活。

适合什么样的人用？我的判断是：如果你已经在用各类 AI 工具但觉得不够自由，或者想把自己的工作流沉淀成可复用的自动化任务，又或者你想完整掌控数据不想把东西全放在别人的服务器上，那 OpenClaw 很值得试。反过来，如果你只想找个聊天机器人随便玩玩，那它有点大材小用，直接用网页版更快。

还需要提一个容易混淆的点。OpenClaw 和 Clawdbot 的关系类似“自托管版”和“官方托管版”。Clawdbot 是商业托管服务，开箱即用但限制多、按量收费；OpenClaw 是开源实现，部署在你自己机器上，数据不出门，适合折腾，这也正是标题强调“本地部署”的原因。

2. 本地快速部署：从零到跑通只需要几分钟

先说结论：在 Linux / macOS 环境，OpenClaw 提供了一键安装脚本，正常情况下两三分钟就能跑起来。Windows 用户相对麻烦一点，建议直接上 WSL2 或者用 Docker，别在原生 Windows 环境下硬刚，依赖冲突的问题会让你怀疑人生。

2.1 环境准备与前置依赖

安装前先确认几件事：

• 操作系统：Ubuntu 22.04+/Debian 12+ 最稳，macOS 12+ 也可以。如果你想用 Windows，先装好 WSL2 并分配至少 4GB 内存。
• Node.js 版本：OpenClaw 是基于 Node.js 开发的，要求版本较新，实测 Node 18 能跑但会有警告，Node 20/22 最省心。
• 包管理器：npm 和 pnpm 都要有，pnpm 用于安装管理面板相关依赖。
• Python 3.10+（可选但建议装）：部分 Skill 依赖 Python 脚本，后面想装更多 Skill 时没有 Python 会很痛苦。

检查版本的命令很简单：

node -v npm -v python3 --version

如果 Node 没有装或者版本太低，我建议用 nvm 装，别用 apt 装系统级 Node。原因很实际：apt 源里的 Node 版本往往偏旧，而 OpenClaw 对 Node 版本有硬性要求，版本不够会直接报错。nvm 的安装方式：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 22 nvm use 22

2.2 一键脚本安装的正确姿势

前置检查没问题后，直接跑官方安装脚本：

curl -L https://docs.openclaw.ai/install.sh | bash

这个脚本会自动完成几件事：拉取源码、安装 npm 依赖、创建默认配置目录（一般是~/.openclaw/）、注册系统命令。装完以后执行：

openclaw --version

能输出版本号就说明安装成功了。如果你想指定特定版本或者 GitHub 官方仓库的 main 分支源码，脚本也支持参数指定版本或仓库地址——这一点在热搜词里也有体现。我个人的建议是日常使用直接装稳定版，别追 main 分支，除非你明确知道某新功能需要最新的代码。

Docker 方案同样可行，适合不想污染本机环境的朋友：

docker run -d --name openclaw -v ~/.openclaw:/root/.openclaw -p 3000:3000 openclaw/openclaw:latest

但注意：Docker 方式和本机安装在使用体验上有一点差异，主要是 Skill 里如果涉及本地文件操作，路径映射会绕一些。追求省心，还是原生安装更好。

2.3 验证安装成果

装完以后别急着配 Key，先启动一个临时对话测一下框架本身正不正常：

openclaw chat

框架会提示你还没配置大模型，这是正常的。能看到交互提示符、输入内容后不直接崩溃，就说明核心框架没问题，接下来只需要把“大脑”接进去。这一步很重要——先确认壳没事，再考虑脑子，排查问题时会省很多力气。

3. 大模型 API Key 配置：把大脑接进去

OpenClaw 本身没有内置模型，它需要你提供一个“会思考的大脑”，这个大脑就是大模型的 API。配置的核心就是拿到 API Key 并填进配置文件里。

3.1 各家大模型 API 的获取方式

现在主流的方案基本分两类：本地模型和云 API。本地模型用 Ollama 跑，完全免费、数据不出机器，但需要你有还不错的显卡或足够的内存；云 API 按量付费，胜在开箱即用，响应快。从热搜词里也能看出，大家关心的话题集中在 DeepSeek、豆包、Groq、Minimax 等几家。

作为一个跑过多种方案的过来人，我的建议是：初次尝试先用云 API，别一上来就折腾本地大模型。原因很简单——本地模型除了 LLM 本身，还有显存占用、量化选择、上下文长度等一堆变量，任何一个环节出问题都会影响你对 OpenClaw 本身的判断。先用云 API 把 OpenClaw 跑熟，再考虑要不要本地化，是性价比最高的路径。

各家 API Key 获取渠道：

• DeepSeek 开放平台：注册后进入控制台，创建 API Key，新用户通常有免费额度。模型名填deepseek-chat或deepseek-reasoner。
• 硅基流动 SiliconFlow：聚合多家开源模型，注册送额度，适合想用各种开源模型但懒得本地部署的人。模型名像Qwen/Qwen2.5-7B-Instruct这种格式，直接在 OpenClaw 配置里填。
• Groq：主打极快推理速度，注册后可以在控制台创建 Key，有免费额度，模型名如llama-3.3-70b-versatile。
• 智谱、MiniMax、豆包：各有自己的开放平台，注册流程大同小异。MiniMax 的 H3 模型近期关注度挺高，配置方式和 DeepSeek 差不多，拉取模型列表时能看到。

如果你更倾向本地模型，Ollama 的方式特别简单。先装 Ollama，然后拉一个模型：

ollama pull qwen2.5:7b ollama serve

之后在 OpenClaw 配置里把模型服务地址指向 Ollama 就行，API Base 一般是http://localhost:11434。不过提醒一句：7B 模型跑简单对话和工具调用勉强可用，复杂推理任务的表现和云上大模型差距还是挺明显的。

3.2 配置文件修改与常见坑

OpenClaw 装好后会自动生成配置文件，路径是~/.openclaw/openclaw.json，里面可以配置大模型参数、Skill 目录、记忆存储等。不同版本默认配置略有差异，但核心结构是稳定的。

{ "model": { "provider": "deepseek", "name": "deepseek-chat", "apiKey": "sk-你的Key", "baseUrl": "https://api.deepseek.com" }, "skill": { "dirs": ["~/.openclaw/skills"] }, "agent": { "name": "assistant", "language": "zh-CN" } }

配置完重启 OpenClaw：

openclaw restart

然后再次执行openclaw chat，随便问一句“你是谁”，如果正常返回且能说清自己是 OpenClaw 框架驱动的智能体，就说明 Key 配置成功。

配置时最容易踩的坑有三个。第一，模型名写错。各家平台的模型标识符不完全一样，尤其开源模型的名称格式有讲究，写错一个字都调用失败。第二，baseUrl 填错。有些平台要求填根路径，有些要求填/v1，OpenClaw 通常会自己拼接，如果你填了完整路径可能会出现重复前缀导致的 404。最稳妥的做法是先在 curl 里测一遍，确认 API 连通了再填进配置。第三，环境变量覆盖问题。如果你之前设置过OPENAI_API_KEY这类环境变量，OpenClaw 的优先级处理可能会和你预期不一致，出问题时先检查环境变量。

3.3 实测不同 Key 的效果差异

我实际用同一套 OpenClaw 配置，分别挂了 DeepSeek、Groq 和本地 Ollama 跑同样的任务，感受比较明显：

• DeepSeek-chat：综合表现很稳，中文理解好，工具调用准确率高，很少出现该调 Skill 不调的情况。长上下文场景下也能保持较好的指令跟随性。
• Groq 的 Llama 3.3 70B：响应速度确实快，基本感觉不到等待，但工具调用偶尔会抽风，需要多试几次或者在提示词里把规则写得更死。
• 本地 Qwen2.5 7B：速度取决于机器，我跑的时候能接受，但复杂任务的完成度明显不如云端模型。适合隐私敏感场景，不适合严肃生产力。

这个对比想说明一个事：OpenClaw 只是壳，最后的体验上限由你接的模型决定。别指望框架能弥补模型能力的不足。

4. Skill 集成：让 OpenClaw 真正能干活

配好 API Key 之后，OpenClaw 已经是一个能对话的智能体了。但说实话，这时候它还是“半成品”，因为没装 Skill 之前，它只能聊天不能做事。Skill 才是让它从“聊天机器人”进化为“干活助理”的关键。

4.1 Skill 目录结构与安装方式

OpenClaw 的 Skill 机制设计得很清爽。每个 Skill 就是目录下的一个文件夹，里面至少包含一个SKILL.md文件，用来描述这个 Skill 能做什么、在什么条件下触发、需要什么参数。部分 Skill 还会带独立的脚本文件（Python、Shell、Node 都可以）。

一个典型的 Skill 目录长这样：

~/.openclaw/skills/ ├── web-search/ │ ├── SKILL.md │ └── search.py ├── draw-chart/ │ ├── SKILL.md │ └── chart.py └── todo-list/ ├── SKILL.md └── todo.sh

安装方式分两种。一种是从社区/别人分享的仓库直接 clone 进目录：

cd ~/.openclaw/skills git clone https://github.com/xxx/openclaw-skill-web-search.git web-search

另一种是手动创建：自己写一个SKILL.md，再补齐需要的脚本。第二种方式灵活度最高，适合私有化工作流。

装完之后进入 OpenClaw 对话，输入/skills就能看到当前加载了哪些 Skill。如果发现新装的 Skill 没被识别，执行一下/skills reload或者重启进程即可。

4.2 手写一个 Skill：实操示例

理论说再多不如动手写一个。我拿一个超简单的例子演示——写一个“获取当前时间”的 Skill。虽然模型自己知道日期，但这个例子能完整展示 Skill 的工作机制。

在~/.openclaw/skills/get-time/下新建SKILL.md：

--- name: get-time description: 获取当前本地时间和日期。当用户问“现在几点”“今天日期”时使用。 args: - name: none description: 无需参数 ---

再建一个同名脚本script.py：

#!/usr/bin/env python3 from datetime import datetime now = datetime.now() print(f"当前时间：{now.strftime('%Y-%m-%d %H:%M:%S')}")

保存后执行/skills reload。这时候如果你在对话里问“现在几点”，模型会识别出这个意图，调用 get-time Skill，并返回脚本输出。整个过程看起来是“对话式”的，但背后其实是模型在决策“该不该用工具、用哪个工具、参数怎么填”。

这才是 Skill 的核心价值：把模型的意图识别能力和外部脚本的执行能力绑在一起。模型负责判断“用户想要什么”，脚本负责“实际执行”，两部分通过SKILL.md的声明建立联系。

4.3 进阶 Skill 用法说明

除了手动安装和编写，社区里已经有不少现成的高质量 Skill 可以借鉴，比如与 Codex CLI 配合的编码类 Skill、用于大模型微调数据处理的 Skill、面向 HarmonyOS“仓颉”开发的专用 Skill 等。你在搜索引擎里看到各种“某某 Skill 推荐”的帖子，其本质都是这类文件包的集合，装法和我上面写的一致。

进阶用法里最值得关注的是多 Skill 协作。OpenClaw 允许你同时装几十个 Skill，模型会根据当前对话上下文自动选择合适的 Skill。比如你问“帮我查一下天气，然后把这个信息写进今天的日报里”，模型可能先调用天气查询 Skill，再调用文档写入 Skill，两次调用之间自己完成数据传递。这种多步骤调度能力是 OpenClaw 区别于普通聊天插件最核心的一点。

不过我得提醒一件事：Skill 不是越多越好。

实测下来，装太多 Skill 有两个副作用：一是模型在做意图识别时可能“看花眼”，本来一个很简单的请求它反而犹豫该用哪个工具；二是某些 Skill 的提示词会和主提示词冲突，导致行为异常。我的建议是装够用就行，不需要的技能先注释掉或挪出目录，给模型减少决策负担。

4.4 Skill 与 Prompt 的边界感

还有一个很多人容易混淆的点：Skill 和提示词（Prompt）的区别。简单说，Prompt 是给模型的指令，Skill 是给模型的工具。Prompt 教模型“怎么想”，Skill 让模型“能做到”。

具体到 OpenClaw 里，你可以在主配置里修改系统提示词，定义智能体的性格、回复风格、默认行为规则。而 Skill 只负责提供能力，不负责调整模型行为。两者配合使用、互相独立，是很重要的设计理念——这保证了你换 Skill 不会影响智能体的人设，改提示词也不会影响已装 Skill 的正常调用。

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

部署过程中踩坑是必然的，我把高频问题整理成一个速查表，方便你遇到问题时直接对照排查。

再说几个容易被忽略但我实际踩过的点。

升级 OpenClaw 版本时，不要直接覆盖旧版本，最好先备份~/.openclaw/下的配置文件和 Skill 目录。虽然官方说配置是向前兼容的，但 Skill 的接口规范偶尔会有细微调整，旧 Skill 在新版本上可能跑不起来。我个人的习惯是：升级前先看 release notes，确认没有 breaking change 再升。

还有一个容易被忽略的“隐形坑”，就是.env或 shell 配置文件里的环境变量。某些情况下你之前在环境变量里设置的 API Key 会被 OpenClaw 优先读取，导致配置文件里的新 Key 不生效。排查时用env | grep -i key看一眼现场环境，往往能发现问题。

最后一点建议，关于日志。OpenClaw 跑出问题时，别急着重新安装，先看日志。日志通常在~/.openclaw/logs/目录下，里面有完整的调用链路和执行记录，排查 Skill 不生效、API 报错这类问题时，日志里的信息比任何文档都直接管用。

安装时遇到奇奇怪怪的报错先别慌，拆开看无非就是网络、依赖、配置三类问题。把错误信息复制到社区搜索框里，大概率能直接找到答案——这项目活跃度高，踩过坑的人不少。

最后再分享一个小技巧：把常用的 Skill 统一放在同一个目录下，用 git 做版本管理。每次调整完 Skill 内容后提交一次，出问题随时回滚。我自己的~/.openclaw/skills/就是一个 git 仓库，这习惯救过我很多次。