OpenClaw本地部署指南：Docker接入DeepSeek与微信飞书

最近圈子里聊得最热闹的，就是OpenClaw这个本地AI助理框架。一句话介绍：它是一个开源的智能体服务，把消息接收、模型调用、技能执行、多平台对接这些能力打包在一起，你部署在自己电脑或服务器上之后，它可以扮演你的私人助理、小说写作搭档、群聊机器人，甚至可以挂到微信和飞书上去用。模型层不像某些闭源服务锁死，OpenClaw支持自定义配置，尤其是能接DeepSeek、通义千问这一批国内大模型，这让它的使用成本和使用场景一下子亲民了很多。

这篇文章我会从头到尾走一遍"本地Docker安装部署+自定义配置国内大模型"的完整流程，覆盖Docker环境准备、OpenClaw容器启动、配置文件改写、DeepSeek等模型接入、微信和飞书渠道打通，以及我在实际操作中踩过的一堆坑。不管你是刚听说OpenClaw的新手，还是已经装了一半被某个报错卡住的半老手，都可以拿这篇当排查手册来对照。

1. 部署方案选型：为什么用Docker而不是裸装

1.1 OpenClaw的定位和核心能力

OpenClaw本质上是一个"消息进来、动作出去"的智能体调度器。你说一句话，它先交给配置好的大模型理解，模型给出意图和参数，然后OpenClaw再去调用对应的技能模块执行，最后把执行结果整理成回复返回给你。整个过程在本地闭环，所以你的对话记录、技能执行日志都是存在自己机器上的，隐私性好。

它能做的事取决于你给它装了什么技能。社区里有人用它写小说，有人把它接成微信群里的问答机器人，有人通过飞书机器人做日常任务提醒，还有人把它和家里的NAS组合在一起做一些自动化。写小说这个场景尤其受欢迎，因为长文章生成需要稳定的上下文管理，OpenClaw的会话机制刚好适合做这件事。

1.2 容器化部署带来的三个直接好处

我第一次用OpenClaw时图省事，直接按脚本在宿主机上装。结果Python环境和Node环境互相冲突，装到一半把系统自带的软件包搞坏了。后来换成Docker部署，清净多了。

容器化带来的三个直接好处：

• 依赖隔离：OpenClaw的运行环境和宿主机是隔开的，不会污染系统，软件的删除和升级也不会留下乱七八糟的残留。
• 升级回滚方便：镜像本身就是完整快照，升级出问题可以秒回原来的版本，不用再一点点翻文档找回滚命令。
• 迁移容易：同一份镜像加数据目录，从Mac换到Linux服务器、从Windows换到NAS，成本几乎为零。

如果你只是临时体验，那裸装也行；只要你想长期跑，我建议直接走Docker，省心程度不是一个量级。

1.3 资源需求心里有个数

OpenClaw本身是一个轻量服务，真正吃资源的是模型层。如果你用的是云端API，比如DeepSeek的在线接口，那么本地只需要很小的内存，2G内存的机器就够跑。如果你拉的是本地大模型，比如在NVIDIA NIM环境里部署模型再让OpenClaw调用，那就要看模型大小了，7B量化模型一般需要8G以上内存，再加上OpenClaw服务本身，建议至少16G内存的机器，不然对话响应会明显变慢。

2. 环境准备：把Docker这层地基打好

2.1 Windows上安装Docker Desktop

Windows上最常见的报错就是"Docker Desktop failed to start because virtualization support wasn't detected"。这通常是虚拟化没有开启导致的。

先确认BIOS里把Intel VT-x或AMD-V打开，然后Windows功能里要启用两项：Hyper-V和"适用于Linux的Windows子系统"。用管理员身份打开PowerShell执行：

powershell复制Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

执行完重启系统，再装Docker Desktop就顺了。还有一部分机器是Windows 10家庭版，家庭版不带Hyper-V，这种情况更推荐用WSL2后端。先把WSL2装好，打开Docker Desktop设置里的"Use the WSL 2 based engine"，基本就能跑起来。我在几台不同配置的Windows机器上试过，WSL2方案的成功率比Hyper-V高不少，遇到问题也更好解决。

2.2 macOS和Linux的Docker安装

macOS上注意区分处理器架构：Apple Silicon芯片下载对应arm64版本的Docker Desktop，Intel芯片下载x86_64版本。安装包拖进Applications就完成，没什么好说的。但你要是用Mac Mini当服务器长期跑OpenClaw，建议在Docker Desktop设置里勾选"Start Docker Desktop when you sign in"，免得每次手动启动。

Linux这边，Ubuntu和Debian直接用官方脚本最省事：

bash复制curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

CentOS的话用yum安装docker-ce，步骤稍微多一点。装完之后验证一下：

bash复制docker version
docker run hello-world

能正常输出版本信息并跑通hello-world，环境就算OK了。

2.3 镜像下载慢？先配国内加速

很多朋友卡在第一步：镜像拉不下来，或者拉得极慢。这主要是因为Docker Hub的访问不稳定。常见做法是在Docker的daemon.json里配置国内镜像加速地址。

Windows在Docker Desktop的Settings → Docker Engine里改，Linux直接改/etc/docker/daemon.json：

json复制{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://dockerproxy.com",
    "https://docker.mirrors.ustc.edu.cn"
  ]
}

改完保存并重启Docker，再拉镜像速度就明显上来了。需要注意一点，镜像加速地址有时候会变动，如果某个地址失效，换一个就行，方法都是一样的。配好加速之后，拉OpenClaw镜像就不会一直卡在等待下载状态了。

3. 拉取OpenClaw镜像并完成首次启动

3.1 镜像拉取和数据目录规划

环境准备好之后，先规划一下数据目录。我习惯在宿主机建一个openclaw目录，里面分config、data、logs三个子目录，后端启动时把这三个目录挂载进容器，这样配置和会话数据都留在宿主机上，将来删容器重来也不丢数据。

bash复制mkdir -p /opt/openclaw/{config,data,logs}

拉取镜像：

bash复制docker pull openclaw/openclaw:latest

这里想说一句：OpenClaw版本更新比较频繁，建议拉取时带上版本号，不要无脑用latest。等社区里验证过的版本稳定了再用，避免新版本引入未知问题。我自己在长期跑的机器上用的是固定版本，至少能保证重复部署时行为一致。

3.2 首次启动与端口映射

首次启动命令：

bash复制docker run -d \
  --name openclaw \
  --restart=unless-stopped \
  -p 3000:3000 \
  -v /opt/openclaw/config:/app/config \
  -v /opt/openclaw/data:/app/data \
  -v /opt/openclaw/logs:/app/logs \
  openclaw/openclaw:latest

参数说明：-d表示让容器在后台运行，这样即使关闭终端窗口也不会中断；--restart=unless-stopped用来保证服务器意外重启后容器能自动拉起，这个参数对长期跑服务非常关键；-p 3000:3000把容器的3000端口映射到宿主机，浏览器访问本机3000端口就能进入Control UI；三个-v参数分别挂载配置、数据和日志目录，确保容器删掉重建后配置和会话历史还在。

启动后用docker ps看容器状态，再用docker logs -f openclaw看日志。第一次启动会生成默认配置文件，看到日志里输出类似"Control UI listening on 3000"这样的信息，就说明服务起来了。

3.3 Control UI一直没起来怎么办

浏览器访问http://localhost:3000，如果一直转圈，优先看这两个地方：容器的启动日志里有没有报错堆栈；端口是不是被其他程序占了。我遇到过一次本机的3000端口被某个开发服务占了，导致OpenClaw的Control UI怎么都访问不了，把端口映射改成3001后就正常了：

bash复制docker run -d \
  --name openclaw \
  -p 3001:3000 \
  -v /opt/openclaw/config:/app/config \
  -v /opt/openclaw/data:/app/data \
  -v /opt/openclaw/logs:/app/logs \
  openclaw/openclaw:latest

改端口的时候记得先把原来的容器停掉删掉，不然名字冲突会报错。

4. 自定义配置：接入DeepSeek等国内大模型

4.1 配置文件到底改哪里

OpenClaw首次启动后会生成一个默认配置文件，通常在挂载的config目录下，文件名一般是config.toml或config.yaml，具体看版本。这个文件是OpenClaw的大脑，模型接入、渠道对接、技能开关全都在这里控制。

我的习惯是修改前先备份原文件：

bash复制cp /opt/openclaw/config/config.* /opt/openclaw/config/config.bak.$(date +%Y%m%d)

改完配置必须重启容器才能生效：

bash复制docker restart openclaw

这一步很多人会忘，改完配置直接发消息发现还是老模型在回复，然后怀疑配置没生效。记住，每次改完config之后容器重启一次，问题就少一半。

4.2 接入DeepSeek的标准写法

DeepSeek是现在社区里接得最多的国内模型，开放API格式和OpenAI兼容，所以OpenClaw里配置起来也简单。在配置文件的模型段落里，找到类似llm或model的配置块，改成：

yaml复制model:
  provider: openai_compatible
  base_url: "https://api.deepseek.com/v1"
  api_key: "sk-你的DeepSeek密钥"
  model_name: "deepseek-chat"
  temperature: 0.7

然后重启容器，在OpenClaw的对话界面里发一条消息测试，如果正常回复，说明接入成功。

这里有几个点容易翻车：base_url不要漏掉末尾的/v1，漏了之后会报接口404；api_key要到DeepSeek开放平台去申请，别拿别人分享的测试密钥去试；model_name不建议写成deepseek-r1这类不带chat后缀的名字，除非你明确知道自己在干什么。我实际测试过，同样的配置，deepseek-chat的响应速度和稳定性都更适合日常对话。

4.3 Zero Token模式报错"unknown model: deepseek"的排查

热词里有一条"openclaw zero token 安装后 agent failed before reply: unknown model: deepseek"，我猜不少人都遇到过。这个报错的意思是：模型配置里的名字和实际连接的模型不匹配。

Zero Token模式是OpenClaw的一种省成本玩法，不依赖在线API，而是通过本地模型或免费模型端点来跑。但如果你在zero token模式下把model_name写成了deepseek，而后端实际上没有注册这个名字的模型，服务端就会直接拒绝请求，报unknown model。

解决办法分两步。第一步，确认你到底走的是API模式还是Zero Token模式。走API就按4.2节配，模型名要和平台提供的一致；走Zero Token就要确认模型管理列表里有没有deepseek这个ID，模型ID通常是一个明确注册过的标识，不是随便写的友好名。第二步，检查日志里模型注册部分，看启动时加载了哪些模型：

bash复制docker logs openclaw 2>&1 | grep -i model

日志里会列出已注册的模型ID，把配置里的model_name改成对上号的名字，重启就好。整个过程其实不复杂，就是得静下心看日志，日志里什么都写着。

4.4 通义千问和其他国产模型

除了DeepSeek，通义千问的API也是OpenAI兼容格式，接入思路完全一样。改base_url和model_name就行：

yaml复制model:
  provider: openai_compatible
  base_url: "https://dashscope.aliyuncs.com/compatible-mode/v1"
  api_key: "sk-你的DashScope密钥"
  model_name: "qwen-plus"

如果你有NVIDIA NIM环境，OpenClaw也支持配置NIM端点，base_url指向你的NIM服务地址，模型名填NIM里部署的模型ID。这个方案适合那些对数据比较敏感、想在本地GPU上跑模型的团队，具体配置方式和API模式类似，只是base_url变成了你自己的服务地址。国产模型里还有GLM、Moonshot这些，只要API兼容OpenAI格式，基本都是同一套接法，学会一个等于学会全部。

5. 渠道打通：接入微信和飞书

5.1 微信接入的几个注意事项

OpenClaw接微信，简单说就是把它变成一个"微信机器人"，你在微信里给它发消息，它通过Webhook回调把消息传给OpenClaw，OpenClaw再调用模型处理并回复。社区里有很多人这么干，把它接成群聊小助手。

实操上需要注意两点：微信端要有办法把消息转发出来，这通常需要一个桥接服务，不要直接使用个人微信主账号去跑，既容易触发风控也影响日常使用；另一个是群聊消息很多，建议在配置里限制触发条件，比如只在有人@机器人时才响应，避免每条群消息都消耗Token。我见过有人没做这层限制，一个热闹群一天能把额度烧光。

5.2 飞书接入更像"正规军"

相比微信，飞书的开放平台更完善，机器人支持Webhook事件订阅，接入OpenClaw的过程也更规范。在飞书开放平台创建企业自建应用，拿到App ID和App Secret，然后在OpenClaw配置里填上：

yaml复制channel:
  feishu:
    app_id: "cli_xxx"
    app_secret: "你的飞书应用密钥"
    event_encrypt_key: ""
    verification_token: ""

配置好后把飞书的事件接收地址指向OpenClaw的回调路径，重启容器就能在飞书里和机器人对话了。飞书这边还有个好处，机器人可以在工作群里做审批提醒、日程汇总，实用性比微信更强。如果你是给团队用，飞书方案是首选，权限管理和消息类型都更清晰。

6. 常见问题与排查实录

6.1 Control UI无法访问

症状：浏览器打不开http://localhost:3000，或者打开后一直白屏。排查顺序：先看容器日志有没有报错，再用netstat或ss检查端口有没有监听，最后确认防火墙有没有放行端口。社区里还有一种情况是Control UI启动之后又被本地代理抢占了端口，这时候把端口改掉、重启容器基本能解决。

6.2 Docker Desktop虚拟化相关的报错

Windows上跑Docker Desktop最常见的两个报错：一个是"virtualization support wasn't detected"，另一个是"incompatible version of Windows"。前者按第2节里说的，开BIOS虚拟化、启用Hyper-V和WSL2；后者一般是系统版本太老，Docker Desktop新版要求Windows 10较新的版本，升级系统补丁就好。我在Windows 10老版本机器上遇到过，升级到最新的Windows 10 22H2之后问题消失。

6.3 模型请求慢、回话卡死

如果DeepSeek接入了但回复特别慢，先检查API服务商的状态页，有时候是厂商侧负载高。本地侧的话，把OpenClaw容器日志打开，看每次请求的耗时记录，如果模型调用就花了好几十秒，那问题基本出在网络或模型服务端，不是OpenClaw本身的问题。另外确认容器里的时间与宿主机一致，时间漂移会导致API鉴权失败，这个坑比较隐蔽。

6.4 资源占用异常和日志清理

OpenClaw跑久了，data目录里的会话记录会越来越大。建议定期清理旧会话，或者通过配置只保留最近N天记录。日志文件也一样，挂载的logs目录如果一直不轮转，会撑满磁盘。我一般配一个简单的定时任务，每周把超过30天的日志压缩归档，保持目录干净。

6.5 常见问题速查表

7. 场景实践：让OpenClaw帮你写小说

7.1 写小说场景的配置思路

热搜词里"openclaw 写小说"热度很高，我实际也试过。用OpenClaw写小说，核心不在模型，而在上下文管理和人设保持。我的做法是在Skill目录里写一个小说写作技能，把角色设定、世界观、行文风格写死，每次对话时自动附加到Prompt里，模型就不会漂移了。

很多人以为丢一句"帮我写个小说"就能出好作品，实际上生成到第三章就开始前后矛盾。把设定固化到Skill里之后，我发现模型输出的连贯性提升非常明显，人物说话的口吻也不再乱跳了。

7.2 上下文窗口和记忆管理

长篇小说的问题是上下文会超窗口。DeepSeek的上下文窗口有限，章节写多了，前面的设定会被挤掉。我的经验是：让OpenClaw在每轮结束时输出一个"剧情摘要"，下一章开始前把摘要作为前置输入，这样即使上下文被截断，核心设定还能保留。这个技巧和模型无关，纯靠Prompt设计，但对谁都有效。

7.3 一点个人心得

把OpenClaw真正常态跑起来之后，我发现最有价值的不一定是某个具体功能，而是它把"本地运行+私有数据+模型可换"这三件事凑齐了。你可以用免费API测试，也可以换更贵的模型追求质量，所有数据都在自己手里，这种感觉是云端服务给不了的。写作、RSS总结、群聊机器人，都是我日常在用的场景。

最后再分享一个小技巧：配置文件和Skill目录最好纳入Git管理，每次改配置之前提交一次，出了问题可以直接回滚对比。这个习惯帮我省了不知道多少排查时间，也推荐给你。