OpenClaw部署全攻略：从安装、模型接入到微信/飞书/钉钉集成

先说结论：OpenClaw 这玩意儿，就是一只“龙虾”，它的核心价值不是给你一个聊天机器人，而是让大模型真正替你干活。你把它装到一台电脑、服务器或者 NAS 上，接上微信、飞书、钉钉，它就能在聊天框里听懂指令，然后去调用各种工具、读写文件、访问 API，再把结果推回给你。这篇实操手册是我把自己部署和折腾 OpenClaw 的过程完整梳理了一遍，从安装、初始化、接模型到写技能，能解决“Windows 下 node runtime not found”“Control UI 起不来”“接入本地模型报 unknown model”“微信飞书接不进去”这些大概率会遇到的问题。适合刚接触 OpenClaw 的新手，也适合部署完但不知道怎么二次开发的进阶玩家——照着抄作业，能省下好几个通宵。

1. OpenClaw 到底是什么：一只叫龙虾的个人助理 Agent

1.1 从名字看本质

OpenClaw 这个名字本身就是双重含义：Open 是开源，Claw 是螯钳，项目 Logo 又是一只龙虾，所以社区里都叫它“龙虾指南”。我第一次看到这名字还以为是个游戏外挂，后来才明白它是一个开源的智能体（Agent）框架。你可以把它理解为“给大模型装了手和脚”：大模型负责思考，OpenClaw 负责执行。

它的使用模式网上有人拿“遥控器”作类比，我觉得特别贴切。你手里的微信、飞书、钉钉就是遥控器面板，OpenClaw 是中间那台接收器，底下的各种 API、脚本、文档、数据库就是被遥控的家电。你在聊天框发一句“帮我把今天开会纪要整理成周报发到我邮箱”，OpenClaw 会先拆解任务，调用文档读取技能拿到内容，再调用邮件技能把邮件发出去，全程不需要你打开电脑操作。

1.2 它到底能干什么

按照现在社区里玩得比较多的场景，我整理成几个类别：

• 个人助理类：日程提醒、邮件草拟、会议纪要归纳、写小说和长文。热搜词里“openclaw 写小说”热度一直不低，因为这类长文本任务需要稳定的上下文管理，OpenClaw 的主动记忆机制刚好能接住。
• 消息平台接入：官方支持主流 IM，微信、飞书、钉钉都有对应的接入方案，这也是它最吸引人的地方——不需要开发 App，聊天窗口就是操作入口。
• 系统与设备控制：通过自定义技能调用本机命令，可以控制智能家居、执行脚本、监控服务器。有人拿它做 NAS 的语音助手，手机发条消息就能查磁盘状态。
• 工作流自动化：读取网盘文档、调用公司内部 API、定时爬取数据，把原本要写一堆脚本的事情变成一个对话即可触发的技能。

1.3 什么人适合折腾 OpenClaw

我的判断是，只要你满足下面任意一条，就值得装一个试试：

• 已经有本地大模型（比如 Ollama、LM Studio），想要一个跟这些模型对话并执行任务的入口；
• 是一个重度的微信/飞书/钉钉用户，希望有个 AI 助理藏在这些 App 里随时待命；
• 对智能体二次开发感兴趣，想用一套简单的“技能”体系把 Agent 接入自己的 API；
• 手上正好有一台吃灰的迷你主机、云服务器或 NAS，想给它派点正经活。

当然，OpenClaw 的安装和配置不是零门槛。它对 Node.js、Docker、模型配置都有一定要求，遇到问题需要看日志、查文档。这也是我写这份手册的原因——把那些散落在各个社区提问里的“坑”集中到一篇实操命令清单里。

2. 安装部署的完整路径：Win、Mac、Linux、虚拟机都能跑

2.1 官方脚本安装，但我不建议直接管道执行

OpenClaw 官网和一键部署脚本是最常见的安装方式，命令长这样：

bash复制curl -fsSL https://openclaw.ai/install | bash

这条命令虽然方便，但我个人一向不建议直接“管道到 bash”，因为你根本不知道脚本里做了什么。更稳的做法是先把脚本下载下来检查一下再执行：

bash复制curl -fsSL -o install_openclaw.sh https://openclaw.ai/install
less install_openclaw.sh
bash install_openclaw.sh

脚本执行完成后，用 openclaw --version 验证是否装好。如果提示找不到命令，要么是安装目录没加入 PATH，要么是安装过程中断。脚本一般会提示安装位置，你可以手动把对应的 bin 目录加进 ~/.bashrc 或 ~/.zshrc，再 source 一下。

安装完成后，OpenClaw 会在你的用户目录下建一个 .openclaw 文件夹，后面所有配置、技能、日志都在这里面：

bash复制ls -la ~/.openclaw

正常情况下你会看到 config.json、logs、skills、memory 这些目录。如果连这个文件夹都没生成，说明安装阶段就出了问题。

2.2 Windows 安装与那个著名的 node runtime not found

Windows 上最常见的安装报错就是热搜词里那个“window 安装 openclaw 出现 oneclaw node runtime not found”。我第一次看到这个报错时也愣了一下，还以为是拼写错误，后来确认是 Node.js 的运行时没被 OpenClaw 找到。

Windows 下的安装流程通常是：

powershell复制npm install -g openclaw
openclaw --version

oneclaw node runtime not found 的原因基本就两个：

1. Node.js 版本太老，OpenClaw 要求 Node 18 或更高版本。检查一下：

   bash复制node -v
   npm -v
   

2. Node.js 装了但 npm 全局目录不在 PATH 里。这种情况下 node -v 有输出，但 openclaw 命令找不到。用 npm prefix -g 查看全局安装路径，然后把该路径加到系统 PATH。

按我的经验，Windows 上最省心的方案不是 npm 全局安装，而是直接用 Docker Desktop：

powershell复制docker run -d --name openclaw -p 8089:8089 -v "$env:USERPROFILE\.openclaw:/root/.openclaw" openclaw/openclaw:latest

这样 Node 运行时全部封装在容器里，不会出现本机 node 版本不匹配的问题。唯一的代价是 Windows 下 Docker 的内存占用略大，建议给 WSL2 至少分配 4GB 内存。

2.3 Mac mini 上的 Docker 本地部署

Mac mini 跑 OpenClaw 是很多人的选择，毕竟 24 小时开机功耗低，ARM 芯片跑本地模型也够用。Docker 部署命令和 Windows 差不太多，只是因为 Mac 的目录结构不同，挂载路径要改一下：

bash复制docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 8089:8089 \
  -v ~/.openclaw:/root/.openclaw \
  openclaw/openclaw:latest

这里重点说下 --restart unless-stopped。Mac mini 如果重启，Docker 容器会自动跟着起来，OpenClaw 服务不用手动拉，对长期挂机非常友好。

M 系列芯片部署时如果遇到镜像拉取慢，给 Docker Desktop 配置镜像加速即可；如果遇到 platform 不兼容，加上 --platform linux/amd64 强制模拟运行，但速度会有损失。实测下来，Apple Silicon 原生 arm64 镜像运行效率高很多。

2.4 Linux 服务器、云主机和虚拟机

Linux 是 OpenClaw 的主场，无论是 Ubuntu、Debian、Kali 还是国产麒麟桌面系统，安装路径都差不多：先确保 Node.js 18+ 和 git 存在，然后执行官方脚本或者 npm 安装。

云服务器部署时有一个容易忽略的坑：安全组和防火墙没放行端口。OpenClaw 的 Control UI 默认监听 8089 端口，你本地浏览器访问 http://服务器IP:8089 打不开，先别急着怀疑服务有问题，检查云控制台的安全组是否放行了 8089。另外，如果服务器本身就是个裸系统，记得先更新：

bash复制apt update && apt upgrade -y
apt install -y curl git nodejs npm

虚拟机里装 OpenClaw 是另一类高频需求，尤其是用 U 盘启动系统、临时体验的用户。虚拟机里建议用桥接网络而不是 NAT，否则你从宿主机浏览器访问 Control UI 会非常别扭。还有，虚拟机的宿主如果内存只有 8GB，装 OpenClaw 没问题，但再接一个本地 7B 模型就比较吃力，建议纯 API 模式跑。

2.5 重装和那个 EBUSY 文件锁错误

社区里常见的问题：“failed to remove ~/.openclaw: error: EBUSY: resource busy or locked, unlink”。这通常出现在你尝试卸载重装 OpenClaw 时，Windows 上尤其频繁。

原因是 .openclaw 目录下的某些文件还在被 OpenClaw 进程或 Node.js 进程占用。Linux/macOS 下一般 rm -rf ~/.openclaw 就完事了，但 Windows 下文件被占用时删除会报 EBUSY。正确的卸载顺序是：

1. 先停掉 OpenClaw：

   bash复制openclaw stop
   

2. 再强制结束残留的 node 进程：

   powershell复制taskkill /F /IM node.exe
   

3. 最后删除目录：

   powershell复制rm -Recurse -Force $env:USERPROFILE\.openclaw
   

如果你是用 Docker 部署的，那更简单，直接删容器和镜像：

bash复制docker stop openclaw
docker rm openclaw
docker rmi openclaw/openclaw:latest

再强调一次：.openclaw 目录里存放着你的配置、技能和记忆数据。删除前如果还想留配置，先把 config.json 和 skills/ 备份出来，不然重装后一切从零开始。

3. 初始化与命令行核心操作

3.1 openclaw init 交互式初始化的每一步

安装完成后的第一步是初始化。命令只有一条：

bash复制openclaw init

但这条命令背后会问你一堆问题，不同版本问题会略有差异，常见交互项包括：

• 给 Agent 起个名字；
• 设置角色人设，比如“你叫小龙虾，是一个贴心的个人助理”；
• 选择默认模型提供商；
• 填写模型名称或 API Key；
• 生成 Control UI 的 Web UI 密码。

这些配置最终都会写入 ~/.openclaw/config.json。如果你不想走交互，也可以直接用非交互模式指定关键参数。以 OpenAI 兼容接口为例，可以这样写：

bash复制openclaw init \
  --agent-name "lobster" \
  --provider openai \
  --base-url "http://localhost:11434/v1" \
  --api-key "ollama" \
  --model "qwen2.5:7b"

初始化完成后，建议立刻做一次“体检”：

bash复制openclaw doctor

这个命令会检查运行环境、目录结构、模型连通性等，把潜在问题一次性暴露出来。我每次改动配置后都会跑一遍，比直接重启服务省事得多。

3.2 常用命令速查表

以下是我实操中高频使用的命令。注意不同小版本的子命令命名可能略有区别，如果某个命令提示 not found，用 openclaw --help 看看当前版本的完整指令。

如果你习惯 Docker 部署，那服务管理命令就得换成 Docker：

bash复制docker start openclaw
docker stop openclaw
docker logs -f openclaw
docker exec -it openclaw openclaw config list

3.3 Control UI 无法启动的排查链路

热搜词里“openclaw control ui did not start”这个问题，我前前后后遇到过三次，分别对应三种不同原因。

第一次是端口被占。8089 端口被其他服务抢了，OpenClaw 起进程失败但报错信息不够直观。排查方式很简单：

bash复制lsof -i :8089
netstat -tlnp | grep 8089

如果有其他进程占用，换一个端口或者先把占用进程停掉。

第二次是初始化没完成。init 中途被我 Ctrl+C 打断了，config.json 里缺少必要字段，Control UI 启动时直接报错。这种问题重跑一遍 openclaw init 即可。

第三次最隐蔽，浏览器缓存。Control UI 页面是本地 Web 服务，但浏览器记住了旧页面的 Service Worker，导致页面一直白屏。用无痕模式访问，或者在开发者工具里清掉站点数据就好了。

排查这类问题的通用路径是先看日志：

bash复制openclaw logs --tail 50

日志里如果能看到 listen on 8089 之类的字样，说明服务其实起来了，问题大概率在浏览器或反向代理；如果只看到一堆 Error，再把对应的堆栈信息复制下来去搜索，比盲猜快得多。

3.4 config.json 里的核心配置项

配置文件是 OpenClaw 的中枢神经。我截取了一份最小可运行的配置骨架，字段含义写在了注释里（OpenClaw 的配置实际是 JSON 格式，无法带注释，这里仅做示意）：

json复制{
  "agent": {
    "name": "lobster",
    "persona": "你是一个乐于助人的个人助理"
  },
  "model": {
    "provider": "openai",
    "baseUrl": "http://localhost:11434/v1",
    "apiKey": "ollama",
    "name": "qwen2.5:7b"
  },
  "ui": {
    "enabled": true,
    "port": 8089
  },
  "channels": {
    "wechat": { "enabled": false },
    "feishu": { "enabled": false },
    "dingtalk": { "enabled": false }
  },
  "memory": {
    "enabled": true
  }
}

我的建议是：能改配置就走 openclaw config set，少手动编辑 JSON。因为手动改文件一旦格式写错，整个服务起不来，排查反而更费劲。命令行改完后再执行：

bash复制openclaw restart

让配置生效。

4. 模型接入和切换：本地模型、NIM、多供应商

4.1 接本地模型：Ollama 是最省心的路径

本地模型接入是 OpenClaw 的一个核心使用场景。Ollama 是目前最简单的本地模型管理工具，装好之后，OpenClaw 只需要把模型提供商指向 Ollama 的 OpenAI 兼容接口即可。

先确保 Ollama 在跑：

bash复制ollama serve
ollama pull qwen2.5:7b

然后配置 OpenClaw：

bash复制openclaw config set model.provider openai
openclaw config set model.baseUrl http://localhost:11434/v1
openclaw config set model.apiKey ollama
openclaw config set model.name qwen2.5:7b
openclaw restart

这里有个关键点：apiKey 在 Ollama 场景下随便填什么都行，比如 ollama，只要不为空即可。很多新手在这里卡住，以为没 Key 就不能填，结果一直连不上。

如果你用的是 LM Studio 或 vLLM，思路完全一致，都是提供 OpenAI 兼容的 /v1 接口，只换 baseUrl 就行。

4.2 接入 NVIDIA NIM

热搜词中有“openclaw 配置 nvidia nim”。NVIDIA NIM 是 NVIDIA 推出的模型推理微服务，它可以本地跑 NIM 容器，然后暴露 OpenAI 兼容接口。配置 OpenClaw 时，核心参数是 provider=openai 加 NIM 的本地地址：

bash复制openclaw config set model.provider openai
openclaw config set model.baseUrl http://localhost:8000/v1
openclaw config set model.name meta/llama3-8b-instruct
openclaw config set model.apiKey your_nim_api_key
openclaw restart

注意 NIM 容器默认端口通常不是 11434，而是 8000，别搞混。另外 NIM 的服务名和版本号与 Ollama 不完全一致，要在 NIM 控制台或镜像列表里确认准确的模型 ID，填错就会报 unknown model。

4.3 多模型并行与运行时切换

OpenClaw 的优势之一是支持多模型配置。你可以把本地模型、OpenAI、DeepSeek 等都配进去，按需切换。不同版本的配置方式略有差异，但大致思路是维护多个模型配置源，然后给每个配置分配一个可识别的名称。

运行时切换模型，最简单的命令是：

bash复制openclaw model list
openclaw model switch qwen2.5:7b

如果你的客户端是通过 Control UI 或 IM 跟 Agent 对话，也可以直接在对话里用“切换模型到 xxx”这种自然语言指令来触发切换（前提是当前模型本身还能响应）。这个机制在日常使用中非常实用——平时用便宜的本地模型处理简单任务，遇到复杂问题再切换到更强的云端模型。

4.4 高频报错：unknown model 和 agent failed

“openclaw zero token 安装后 agent failed before reply: unknown model: deepsee” 这类报错，根因几乎都是模型 ID 没配对。模型 ID 不是随便起的网名，而是必须跟模型服务商返回的 ID 完全一致。

排查方式分两步：

1. 先手动测试模型服务本身的接口。以 Ollama 为例：

   bash复制curl http://localhost:11434/v1/models
   

   看返回的模型 ID 列表里，是否包含你配置的 model.name。
2. 如果 API Key 或服务地址有问题，curl 一下实际的聊天接口：

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

   这个请求能通，再去怀疑 OpenClaw 配置；请求都不通，问题根本不在 OpenClaw。

还有一类报错是“the agent run failed before producing a reply”，这个比较泛，常见原因有三个：

• 模型服务超时或直接拒绝了请求；
• 上下文长度超限，尤其是本地模型默认上下文窗口太小；
• 用到的技能（Skill）运行报错，影响了整个 Agent 流程。

遇到这类报错，第一件事永远是 openclaw logs --tail 100，看日志里真正的堆栈信息。不要盯着一行 “agent run failed” 猜，日志里通常会有更详细的失败点。

5. 把 OpenClaw 接到微信、飞书、钉钉上

5.1 消息渠道的通用逻辑

OpenClaw 接入 IM 的本质，是把聊天平台的消息事件转发给 Agent，再把 Agent 的回复发回聊天窗口。不同平台的接入方式各有特点，但都绕不开三个要素：

• 平台侧的应用凭证（App ID、App Secret / Token）；
• OpenClaw 侧对应 channel 的开启；
• 消息回调或主动发消息的能力。

配置入口在 config.json 的 channels 段，也可以用命令开启。以飞书为例：

bash复制openclaw config set channels.feishu.enabled true
openclaw config set channels.feishu.appId "cli_xxx"
openclaw config set channels.feishu.appSecret "xxx"
openclaw restart

5.2 微信接入：最常用，也要最谨慎

微信是目前需求最强烈的接入渠道。围绕微信的接入方案，社区里主要有两种路线：一种是基于个人微信的自动化协议，另一种是基于企业微信的官方 API。

个人微信方案的优势是“像真的在用微信”，直接跟好友对话，但风险要提前讲清楚：使用非官方协议登录个人账号，有账号风控和封禁风险，建议用小号测试，不要拿主号乱试。接入步骤大致是：

1. 启动微信协议服务（可能需要单独跑一个容器或进程）；
2. 在 OpenClaw 配置里把这个服务地址填进去；
3. 开启 channels.wechat.enabled；
4. 用手机微信给机器人发一条消息测试。

企业微信路线更稳，但配置复杂度也更高：需要注册企业微信、创建自建应用、配置回调 URL、拿到 Corp ID 和 Agent ID。好处是官方支持，没有封号风险，适合团队内部用。

不管是哪种方案，第一次接入成功后都要注意一个细节：OpenClaw 的回复可能带着 Markdown 语法，微信私聊里渲染效果一般，如果出现一堆 ** 符号，要么在角色人设里加一句“回复请使用纯文本”，要么在配置里关掉 Markdown 输出。

5.3 飞书接入

飞书是目前体验最顺畅的渠道之一，因为飞书开放平台的能力比较完善，开发者后台可以配置事件订阅。

最基本的接入流程：

1. 打开飞书开放平台，创建企业自建应用；
2. 开启“机器人”能力；
3. 在“事件与回调”中配置请求地址，指向 OpenClaw 的飞书回调地址（一般是 http://你的IP:8089/webhook/feishu 之类，具体看日志提示）；
4. 获取 App ID 和 App Secret，配置给 OpenClaw；
5. 发布应用版本并确保企业内可用。

很多人在第 3 步卡住，因为回调地址必须是公网可访问的 HTTPS 地址。本地部署的话，需要内网穿透工具把 8089 端口暴露到公网，或者用 Cloudflare Tunnel 这类方案。飞书回调里也要配置 Encrypt Key 和 Verification Token，这些值要跟 OpenClaw 配置保持一致，否则事件验证不通过。

5.4 钉钉接入

钉钉的接入逻辑和飞书类似，流程稍简单一些：

1. 在钉钉开放平台创建企业内部应用；
2. 启用机器人，拿到 AppKey 和 AppSecret；
3. 配置机器人回调地址；
4. 把凭证填入 OpenClaw 的 channels.dingtalk 段；
5. 重启服务，往钉钉机器人发消息测试。

钉钉这边容易踩的坑是“关键词”设置：机器人默认有安全设置，你可能需要配置自定义关键词，比如“龙虾”，这样所有消息必须包含该关键词才会触发。测试时忘了带关键词，消息发出去没有任何回应，不是 OpenClaw 的问题，是安全策略把消息拦了。

6. 技能开发：让 OpenClaw 自己调用 API

6.1 技能机制的原理

如果说模型是龙虾的大脑，那技能（Skill）就是它的手。OpenClaw 的技能体系本质上是一套“工具调用”的标准化定义：你把一个 API 或脚本封装成技能，OpenClaw 根据用户指令判断该调用哪个技能，提取出参数，执行并返回结果。

技能目录一般位于：

bash复制~/.openclaw/skills/<技能名>/

每个技能目录里至少要有一个 SKILL.md，里面用结构化格式描述技能的名称、触发条件、参数和运行方式。OpenClaw 启动时会扫描这个目录，把可用技能注入到 Agent 的“工具箱”里。

6.2 实操：写一个能查天气的 SKILL.md

假设你有一个天气 API，希望 Agent 在用户问天气时自动调用它。技能文件大致是这个样子：

yaml复制---
name: weather
description: 查询指定城市的实时天气情况，当用户问天气、气温、降水时使用。
parameters:
  type: object
  properties:
    city:
      type: string
      description: 城市中文名，如北京、上海
  required:
    - city
---
run: python3 /root/.openclaw/skills/weather/run.py

对应的 run.py 负责把参数拼成 URL，请求 API，再把结果打印为标准输出：

python复制import sys
import json
import urllib.request

city = sys.argv[1]
url = f"https://example.com/weather?city={city}"
with urllib.request.urlopen(url) as resp:
    data = json.load(resp)
print(data["weather"])

写完技能后，让 OpenClaw 重新加载：

bash复制openclaw skill list

如果列表里能看到 weather，说明技能加载成功。接着你直接问一句“北京天气怎么样”，Agent 应该会调用技能并返回天气查询结果。

技能开发有三条实战经验：

• 参数定义越明确，Agent 识别率越高。别只写 city，把“城市中文名”写清楚，模型就不容易把参数填错。
• run 命令要写绝对路径，尤其是 python3，有些环境里默认是 python，写错直接执行失败。
• 技能输出尽量精简，模型回复时会基于技能返回的内容再组织语言，输出太啰嗦反而容易干扰 Agent 的最终回答。

6.3 读取不了文档的处理

“openclaw 读取不了文档”是个高频问题。大部分人的使用方式是把文档路径直接甩给 Agent：“读取 /tmp/report.pdf 总结一下”。结果 Agent 回复读不了。

OpenClaw 默认是不会随便读文件的。你需要在配置里开启文件读取能力，或者给它挂一个文档处理技能，让它调用对应的解析工具。比较常见的处理思路有：

1. 把文档转成纯文本或 Markdown，保存到 Agent 能访问的目录；
2. 安装一个文档解析技能（比如支持 PDF、DOCX 解析的脚本）；
3. 给技能传入文件的绝对路径，确保运行用户有读取权限。

文件权限是我遇到最多的坑。用 Docker 部署时，容器内用户和宿主机用户不同，文件放在宿主机的用户目录下，容器里可能读不了。解决方案是把要读的目录也挂载进容器，例如加一个 -v /data/documents:/workspace/documents，再让 Agent 读取 /workspace/documents/xxx.pdf。

7. 进阶玩法：主动记忆、Harness 与 Hermes 对比

7.1 主动记忆（Active Memory）：给龙虾装一个长期工作记忆

大模型最大的短板是“聊完就忘”。OpenClaw 用主动记忆（Active Memory）机制来解决这个问题。它把对话、事件、任务状态等关键信息沉淀到本地存储中，让 Agent 在下次交互时能调用这些历史信息。

开启方式：

bash复制openclaw config set memory.enabled true
openclaw restart

记忆的数据保存在 ~/.openclaw/memory/ 下。你可以直接查看记忆文件的内容，甚至在维护时手动清理。

实际使用中，主动记忆的价值主要体现在两个场景：

• 长期任务跟踪：比如你让 Agent 每周五下午帮你汇总项目进展，它需要记住这个定时任务以及每次汇总的情况。
• 个性化服务：它记住了你的偏好，比如“用户一般上午开会，下午写代码”，后续安排日程时会自动避开。

从高阶玩法来看，主动记忆还可以和主动记忆检索结合：文档里有一句话“构建具备长期工作记忆的智能体”，本质上是把记忆从“聊天上下文”升级成“结构化知识库”。你可以定期把重要的业务文档写入记忆目录，让 Agent 在需要时引用，而不是每次聊天都从零开始。

7.2 Harness 和 Hermes 到底在对比什么

社区里有人问“openclaw harness hermes 对比”，其实这两个术语对应的概念层次不同。

Harness 指的是 OpenClaw 的运行容器和执行环境。它决定了 Agent 以什么方式运行：是长驻服务，是定时任务，还是单次执行的命令行工具。你可以把它理解为“跑车的底盘”，同一套 Agent 逻辑可以套在不同 Harness 上，以适配不同的运行场景。

Hermes 则偏向消息通道和事件交互层面。它负责把外部消息源（IM、Webhook）的事件转换成 Agent 能理解的标准输入，再把 Agent 的输出投递回外部渠道。如果说 Harness 是“引擎”，Hermes 更接近“方向盘和仪表盘”——它管的是人机交互的输入输出。

所以两者的对比不是“谁好谁坏”，而是看你想要什么样的运行模式。如果你想做驻留式个人助理，重点研究和调优 Harness；如果你想在多个 IM 平台间灵活切换，Hermes 的适配层更值得花时间。

7.3 长文本场景调优：写小说、论文和长报告

“openclaw 写小说”是目前讨论度很高的玩法。长文本生成对模型和上下文管理的要求比普通聊天高一个量级，我实测下来有几个值得注意的点：

• 本地小模型（7B 级别）写短篇还能看，写长篇容易前后矛盾，建议长文任务切到云端强模型。
• 把大纲和设定写入主动记忆，让 Agent 每次续写前先回顾，能明显提升一致性。
• 拆任务：别让 Agent“直接写一本小说”，而是让它先写人物设定、章节大纲，再逐章生成。OpenClaw 的技能体系天然适合这种拆解式任务流。
• 上下文长度要在模型服务端配置好。Ollama 默认上下文可能只有 2048，写长文很快就会“失忆”，调大上下文窗口是有必要的，但也会增加显存占用。

长文本场景下，我的习惯是把“角色设定”和“当前章节”分成两个文件，写进技能里，让 Agent 每章开始前都读取一次。这样即使模型上下文窗口不大，也能通过主动读取保持连贯性。

8. 高频问题速查和我的几个收尾建议

8.1 高频问题速查表

我把安装、配置过程中最高频的问题整理成一张表，方便你排查。如果你遇到的问题不在表里，就用 openclaw logs --tail 100 看日志，然后带着日志去社区搜索，效率最高。

8.2 我自己的几个习惯

折腾 OpenClaw 这么久，我形成了几个固定习惯，算是“过来人”的小经验：

第一，改任何配置前先备份 config.json。有时候一个实验性的配置改动会把整个服务弄崩，有备份直接 cp 回去就能恢复。

第二，长驻服务的 Linux 服务器上，我会把 OpenClaw 注册成 systemd 服务。虽然 openclaw start 也能后台运行，但 systemd 能实现开机自启、崩溃自动拉起，长期稳定性好很多。大致服务文件如下：

ini复制[Unit]
Description=OpenClaw
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/openclaw start --foreground
Restart=always
RestartSec=5
User=root

[Install]
WantedBy=multi-user.target

然后执行：

bash复制systemctl daemon-reload
systemctl enable openclaw
systemctl start openclaw

第三，把模型、渠道、技能这三种变更分开操作。一次只改一个维度，改完立刻测试。很多人出问题是因为同时换了模型又改了渠道配置，一旦报错都不知道是哪个环节引起的。

第四，多利用 openclaw doctor 这个自检命令，而不是靠肉眼查配置。它能把环境问题、配置缺失、模型连通性一次性体检完，节省大量时间。

最后再提一个不算技巧但很重要的心态：OpenClaw 的版本迭代很快，命令和配置结构会变，遇到了跟你搜索到的教程对不上的情况，先看自己版本的 openclaw --help，大概率是最新用法，而不是你操作错了。折腾这类开源智能体的乐趣，本来就在于“今天踩坑，明天懂原理”，慢慢来，你的龙虾会越来越听话。