OpenClaw本地部署实战：接入Ollama与飞书，构建你的AI代理

1. 为什么我坚持把OpenClaw部署在本地

1.1 OpenClaw到底解决了什么问题

OpenClaw是一个开源的AI代理框架，核心思路是让你能把一个带记忆、能调用工具、能跑任务的智能代理，接入到各种日常聊天渠道里。它不是又一个套壳聊天网页，而是把“AI代理”这个概念落到了可自托管、可编程、可跨平台使用的实处。

我最早接触它的时候，第一反应是：这不就是又一个自动化机器人框架吗？但真正上手之后才发现，OpenClaw和传统的聊天机器人框架有本质区别。传统方案是你写一堆规则、关键词、对话流，告诉机器人“什么时候说什么话”。OpenClaw则完全反过来——你只需要给它一个身份、一组工具、一个模型后端，它在渠道里收到消息后，会自动判断意图、拆解任务、调用工具、组织回复。简单说，它把“对话逻辑”从写死变成了推理出来的。

这个思路带来的最大好处是：同一个代理，你既可以把它放到飞书群里帮大家查资料、记日程，也可以放到Telegram里当个人助理，甚至可以通过Web界面直接和它对话。底层模型不管是云端API还是本地Ollama拉下来的开源模型，OpenClaw都能统一接管。

1.2 本地部署和云端部署的核心差异

很多人第一反应是：OpenClaw官网有云服务，直接用不就行了，为什么要费劲本地部署？

我自己的理由有三个，而且都挺现实。

第一是隐私。我把代理接入了飞书工作群，群里经常有内部项目信息、会议纪要、客户资料。这些内容如果走云端API，等于把公司内部数据交给了第三方。本地部署意味着所有对话记录、会话状态、工具调用日志都留在自己的机器上。这一点对个人开发者或许没那么敏感，但对团队使用来说就是硬门槛。

第二是成本。云端服务的收费模式通常是按消息条数或者按时间周期计费。如果代理主要用来做群内答疑、定时任务，一天可能要产生几百次对话，一个月下来账单并不便宜。而本地部署的成本是一次性的——硬件购置或者已有的旧电脑，加上电费。模型推理走Ollama，完全免费。

第三是可控性。云端方案遇到问题，你只能等官方修复。本地部署之后，日志在我手里，配置在我手里，模型想换就换，渠道想加就加，整个运行链路全是透明的。这对我这种喜欢折腾的人来说，本身就是一种乐趣。

当然，本地部署也有代价：你需要一台配置过得去的机器，需要自己维护运行环境，遇到问题得自己排查。但如果你已经玩过Ollama、Dify、RAGFlow这类工具，那OpenClaw的部署难度其实还在它们之下。

2. 部署前的环境准备清单

2.1 硬件配置与内存预算

先说结论：OpenClaw本体对硬件的要求很低，真正吃配置的是你选择的本地模型。

OpenClaw框架本身是一个Node.js应用，跑起来大概占用200MB内存，CPU占用几乎可以忽略。但如果你要接本地大模型，那硬件预算就要按模型规格来算。

我自己用的是主力开发机，配置是i5-12400、32GB内存、RTX 3060 12GB显卡。这个配置跑7B模型非常流畅，跑14B模型略吃力但能用。如果你手头是16GB内存的机器，建议老老实实用7B以下模型。

这里我整理了一个模型和硬件需求的参考表，基于我自己的实测和社区反馈：

模型规格	参数量	内存需求	显卡显存需求	生成速度参考	适合场景
qwen2.5:3b	3B	4GB	2GB	极快	简单问答、任务提醒
qwen2.5:7b	7B	8GB	6GB	快	日常对话、内容总结
deepseek-r1:7b	7B	8GB	6GB	中等	推理任务、代码生成
qwen2.5:14b	14B	16GB	10GB	较慢	复杂任务、深度分析

一个容易踩坑的点：Ollama拉取模型时默认使用4-bit量化，也就是Q4_K_M版本，所以实际占用的内存比模型原始参数要小不少。比如7B模型原始大小约14GB，量化后只有4.7GB左右。如果你想追求更好的效果，可以手动拉取Q5或Q8版本，但内存和显存占用会相应上涨。

2.2 软件依赖：Node.js、Git和包管理器

OpenClaw是TypeScript写的，运行时依赖Node.js。我推荐安装Node.js 20 LTS或更高版本，18版本虽然也能跑，但部分新特性不支持，遇到问题不太好排查。

Windows用户建议直接用官方安装包，或者用winget命令一条搞定：

winget install OpenJS.NodeJS.LTS

Linux用户更推荐用nvm管理Node版本，避免系统包管理器自带的Node版本过旧：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20 nvm use 20

包管理器方面，npm就能用，但如果你需要编译部分原生模块，建议顺手装一个pnpm或者yarn。OpenClaw项目本身推荐pnpm，依赖安装速度更快，锁文件也更可靠。

另外，Windows用户还需要确保安装了Git Bash或者Windows Terminal，因为部分初始化脚本和调试命令需要走命令行交互。不用怕命令行操作，整个部署过程用到的命令不超过二十条。

2.3 本地模型选型：Ollama与千问/DeepSeek的搭配方案

说到本地大模型，Ollama基本是绕不开的工具。它是一个极简的本地推理服务，一条命令就能把模型拉下来并启动API服务。OpenClaw可以原生对接Ollama，不需要额外写胶水层。

模型选型上，国内用户最省心的是千问系列（Qwen2.5）和DeepSeek系列。千问的中文能力自不必说，通义实验室出品的模型在中文语境下表现一直很稳。DeepSeek-R1是推理型模型，在逻辑推理、代码生成、数学问题这些场景下表现突出，但它的“思维链”特性导致输出比较啰嗦，速度也偏慢。

我给OpenClaw推荐的组合是：

• 日常对话主力：qwen2.5:7b，兼顾速度和质量，中文润色、资料总结、闲聊都够用。
• 推理任务备选：deepseek-r1:7b，遇到代码调试、逻辑分析这类问题，切换到它。
• 轻量场景：qwen2.5:3b，手机远控或者低配机器上跑。

如果机器内存有32GB以上，可以尝试qwen2.5:14b，对话质量和上下文理解会有明显提升。我实测下来14b模型在长对话中的“忘性”比7b小很多，代理在多轮任务中不容易跑偏。

3. OpenClaw完整安装流程全解

3.1 Windows端安装步骤

Windows上部署OpenClaw，我是走了“官方推荐路径+踩坑修正”两步，这里把最终稳定的流程整理出来。

第一步，安装Node.js 20 LTS。这个不多说，网站下载安装包一路下一步。安装完打开PowerShell验证：

node -v npm -v

能输出版本号就说明环境没问题。

第二步，全局安装OpenClaw：

npm install -g openclaw

这条命令会把OpenClaw的命令行工具装到全局，后续直接通过openclaw命令启动。安装过程大概需要两三分钟，如果网络慢，可以换成国内镜像源：

npm config set registry https://registry.npmmirror.com npm install -g openclaw

第三步，初始化工作目录。我个人习惯单独建一个目录存放OpenClaw的数据和配置：

mkdir D:\openclaw-workspace cd D:\openclaw-workspace openclaw init

init命令会生成默认配置文件，包括config.yaml或openclaw.json（取决于版本），以及存放会话状态、日志的数据目录。

第四步，启动服务：

openclaw start

启动成功后会看到类似下面的输出：

OpenClaw server is running Local dashboard: http://localhost:3978

这时浏览器打开http://localhost:3978，就能看到OpenClaw的仪表盘界面，在这里配置渠道、管理会话、查看日志。

如果你的Windows系统开启了Hyper-V，也可以直接走Docker方式，后面专门讲。

3.2 Linux端安装步骤

Linux上的安装流程更干净，本质就是“Node环境 + 全局安装 + 启动服务”。

以Ubuntu 22.04为例，完整步骤如下：

sudo apt update && sudo apt install -y git curl curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs sudo npm install -g openclaw mkdir ~/openclaw-data && cd ~/openclaw-data openclaw init openclaw start

如果希望开机自启，参考systemd服务脚本。先找到openclaw的安装路径：

which openclaw

然后创建服务文件：

sudo nano /etc/systemd/system/openclaw.service

服务配置大致长这样：

[Unit] Description=OpenClaw Service After=network.target [Service] Type=simple User=你的用户名 WorkingDirectory=/home/你的用户名/openclaw-data ExecStart=/usr/bin/openclaw start Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

保存后执行：

sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw

这样OpenClaw就作为后台守护进程运行了，即使你退出SSH也不会断。

Linux部署重要的注意事项是权限问题。不要用root直接跑OpenClaw，尽量用普通用户+systemd托管的组合，避免数据目录权限错乱。

3.3 Docker一键部署方案

如果你不想在宿主机上装一堆Node依赖，Docker方案是最干净的。特别是飞牛NAS、群晖这类设备上，Docker几乎是唯一选择。

OpenClaw官方提供了Docker镜像，一条命令就能拉起完整服务：

docker run -d \ --name openclaw \ -p 3978:3978 \ -v /path/to/data:/data \ --restart unless-stopped \ ghcr.io/openclaw/openclaw:latest

解释一下几个参数：-p 3978:3978是把容器内端口映射到宿主机；-v是把数据目录挂载出来，日志和会话状态都在里面；--restart unless-stopped保证容器异常退出后自动重启。

跑起来之后，往浏览器输入http://NAS-IP:3978就能打开仪表盘。

Docker方式有一个隐藏优势：容器环境和宿主机隔离，升级或回滚版本只需要换镜像标签重启容器，不用担心污染系统环境。缺点则是日志查看和配置调整都要进容器操作，稍微绕一点。

我用Docker跑OpenClaw大半年，稳定性非常好，重启迁移的成本几乎为零。如果你机器的资源不算太紧张，我个人建议直接上Docker。

4. 让OpenClaw跑通本地大模型：Ollama对接实战

4.1 Ollama安装与模型下载

Ollama的安装方式不用多讲，官网下载对应平台的安装包装好就行。Windows用户安装完成后，Ollama会自动作为后台服务运行，监听11434端口。

验证Ollama是否正常运行，打开浏览器访问http://localhost:11434，能看到Ollama is running的提示。

拉取模型：

ollama pull qwen2.5:7b

如果还想准备一个推理备用模型：

ollama pull deepseek-r1:7b

拉取过程就是等待进度条走完，模型默认存放在用户目录下的.ollama/models文件夹里。

Windows用户注意一个坑：Ollama默认不会自动设置OLLAMA_HOST环境变量，但OpenClaw连接本机Ollama时默认走localhost:11434，所以不需要额外配置。但如果你是把Ollama装在另一台机器上，务必在OpenClaw配置里把地址改成那台机器的IP。

4.2 OpenClaw侧接入Ollama配置

OpenClaw接入Ollama的方式有两条路径：一种是在Web仪表盘的可视化配置界面里选模型供应商，另一种是直接改配置文件。

我习惯直接改配置文件，因为可以一次性把多个参数都写好。找到你初始化工作目录下的配置文件，找到模型相关的段落，按下面这种格式配置：

model: provider: ollama baseUrl: http://localhost:11434 id: qwen2.5:7b temperature: 0.7 maxTokens: 4096

关键字段说明：

• provider：固定填ollama，告诉OpenClaw走本地推理。
• baseUrl：Ollama服务的地址。本机部署就是http://localhost:11434，远程部署就填http://192.168.x.x:11434。
• id：模型名称，必须和ollama list里显示的Tag一致。填错会直接报模型不存在。
• temperature：采样温度。0.7是我实测比较平衡的值，既不会太死板也不会太发散。如果代理做的是代码生成这类确定性任务，建议降到0.3以下。
• maxTokens：单次回复的最大Token数。默认4096对大多数场景够了，但如果你让代理写长文，可以调到8192。

配置好之后，重启OpenClaw服务，在仪表盘的“模型测试”页面发一条消息，如果能收到回复，就说明对接成功了。

4.3 千问与DeepSeek模型调参建议

本地模型的行事风格和云端大模型有明显差异，配置OpenClaw时必须做针对性调优，否则体验会很差。

先说千问。qwen2.5系列本身指令遵循能力很强，不需要太多花哨提示词。OpenClaw的系统提示词可以直接沿用默认，只需在模型配置里把temperature设为0.6到0.7之间，既能保证回复流畅又有一定创造性。如果代理负责的是知识问答类工作，建议再加一条上下文管理的配置，把contextWindow设为8192，让代理在长对话中记得更牢。

再说DeepSeek-R1。这个模型和千问完全不同，它在回答之前会做大量“思考”，输出里会带一大段推理过程。在OpenClaw里直接使用时你会看到回复特别长、特别啰嗦，因为那段“思考链”也被当作正常输出了。

我的处理方式是给DeepSeek单独建一套配置，把temperature降到0.4，同时把maxTokens拉到8192。如果你想让它输出更干净，可以在系统提示词尾部追加一句“不要输出任何思考过程，直接给出最终答案”。实测这样能压掉大部分废话。

这里放一个我实测的对比参考：

配置项	qwen2.5:7b	deepseek-r1:7b
temperature	0.6 ~ 0.7	0.3 ~ 0.4
maxTokens	4096	8192
适用场景	日常对话、总结、润色	代码、推理、分析
响应速度	快	慢（需要思考时间）

如果你不想手动切换模型，也可以给OpenClaw配置多个模型后端，在对话时通过指令动态切换。比如发送/model deepseek就让代理切换到DeepSeek，发/model qwen切回千问。这个功能在团队群里特别实用，日常问答用千问保证响应速度，遇到硬核问题手动切到DeepSeek。

5. 渠道接入：飞书、Telegram与Channel选择逻辑

5.1 飞书机器人接入全流程

接入飞书是我在OpenClaw上踩坑最多的环节，这里把完整流程理清楚。

第一步，在飞书开放平台创建企业自建应用。进入开发者后台，选择“创建企业自建应用”，填好名称和图标。

第二步，给应用添加机器人能力。在应用功能配置里找到“机器人”，启用机器人，这样你的应用就能以机器人身份加入群聊。

第三步，配置事件订阅。这个是最关键的一步，飞书需要知道把消息事件推送到哪里。OpenClaw会在启动时提供一个webhook地址，格式类似：

http://你的IP:3978/webhooks/feishu

在飞书开放平台的事件订阅页面，请求地址填这个URL，然后订阅接收消息事件。如果你用的是公网部署，这里填公网地址；如果只是局域网内测试，填局域网IP也没问题。

第四步，拿到凭据填写到OpenClaw。飞书开放平台会提供App ID和App Secret，加上机器人本身的Verification Token，这三个值在OpenClaw配置里对应填写。

第五步，把机器人拉进群聊，@它测试。正常的话它会自动回复，说明走通了。

一个很常见的问题：飞书开放平台要求事件订阅URL必须在公网可访问，否则无法验证URL有效性。如果OpenClaw部署在内网，就需要借助内网穿透工具把3978端口暴露到公网。

5.2 openclaw agent怎么选择channel

这个问题被问得非常多，其实“Channel”在OpenClaw里指的就是消息渠道，Agent可以同时接入多个渠道，但需要明确一点：它只需要在一个主渠道里工作，而不是每个渠道都活跃。

我拿自己的实际配置举例。我同时接了飞书、Telegram和Web仪表盘。飞书是工作群用的，Telegram是个人用的，Web是调试用的。如果三个渠道不做区分，代理会在三个地方同时响应，导致不同会话之间状态混乱。

OpenClaw的解决方案是“活跃渠道”机制。我在配置里指定defaultChannel: feishu，这样所有消息默认在飞书渠道处理。如果某天我想在Telegram里用代理，只需要在Telegram里给代理发一条/channel命令，它就会把当前活跃渠道切换到Telegram。更多时候，我可以直接给不同渠道分配不同身份和独立会话，让它们互不干扰。

个人建议是：一个代理实例只服务一个主渠道，如果确实要多渠道使用，配置多个OpenClaw实例比在一个实例里反复切换要省心得多。

5.3 飞书输出截断问题处理

“openclaw在飞书输出容易被截断”这个热搜词，我猜不少人都遇到过了。飞书机器人发送消息有长度限制，单条消息最多约15000字节。但问题是OpenClaw生成的回复本身可能超过这个长度，尤其是让代理写代码、写长文、或者DeepSeek这类爱输出思考过程的模型，回复轻松破万字节。

飞书写入消息时如果遇到超长内容，有两种表现：一是只发送前半段，后半段莫名消失；二是直接报错，代理在飞书里卡住不动。

解决办法有三个方向：

第一，限制OpenClaw回复长度。在模型配置里把maxTokens调低，比如4096，这样大部分回复都能压进飞书限制内。

第二，配置消息分块发送。OpenClaw有自动截断和分块发送机制，但需要确认sendMessage的分块选项已经打开。如果版本支持，它会把超长回复拆成多条消息连续发送，飞书里看起来就是连续几条消息，不会被截断。

第三，如果以上两条都解决不了，给飞书渠道配置一个自定义“分段阈值”，低于这个阈值单条发送，高于则启用文件发送模式，把长文转成文本文件上传。

还有一个偏方我实测有效：在系统提示词里加一句“回复尽量精炼，控制在500字以内”。模型的输出变短了，截断问题自然就消失了。

6. 高频报错与排查记录

6.1 session file locked超时错误彻底解决

这个错误我在Windows和Linux上都遇到过，报错原文是：

agent failed before reply: session file locked (timeout 60000ms)

第一次看到这个报错的时候，我整个人是懵的。什么叫“session file locked”？OpenClaw会为每个会话维护一个状态文件，用于保存对话历史、上下文变量、任务状态。当多个进程（或者多个会话请求）同时想要写入这个文件时，系统会对文件加锁，防止并发写入导致数据损坏。锁的等待超时默认是60秒，超过这个时间还没拿到锁，就会报上面的错误。

这个问题的诱因，绝大多数时候不是OpenClaw本身坏了，而是你同时开了多个入口访问同一个代理实例。比如浏览器仪表盘开着没关，手机Web端又连着，后台还有一个定时任务在跑，三方同时操作同一个会话，文件锁冲突就发生了。

排查步骤我整理成一个流程：

第一步，打开任务管理器（Windows）或执行ps -aux | grep openclaw（Linux），检查当前是否有多个OpenClaw进程。正常情况下应该只有一个主进程，如果多了，全部杀掉重启服务。

第二步，关掉所有浏览器中打开的OpenClaw仪表盘标签页。这一步很关键，仪表盘本身会维持一个WebSocket连接，算作活跃会话。

第三步，检查数据目录下的锁文件。Windows路径大致在C:\Users\你的用户名\.openclaw\sessions，Linux在~/.openclaw/sessions。看到.lock结尾的文件，在服务完全停止的状态下删除即可。

第四步，如果频繁出现，把配置里的会话锁超时时间调大。在配置文件里找到：

session: lockTimeout: 60000

改成120000。但这只是缓兵之计，治标不治本，还是要靠前两步解决并发访问的问题。

6.2 代理回复缓慢或超时的排查思路

本地模型部署的代理，回复慢是常态。我自己用的RTX 3060跑7B模型，生成速度大约每秒15-20个Token，一段200字的回复要等十几秒。但如果你发现回复不是一般的慢，而是频繁超时失败，就要排查下面几个地方了。

先看模型加载状态。Ollama默认会在模型空闲5分钟后自动卸载，下一次请求时要重新加载到内存，这个加载过程可能要等十几秒甚至半分钟。如果代理频繁触发这种冷启动，体验就是“每次都要等老半天”。解决方式是启动Ollama时加上OLLAMA_KEEP_ALIVE=24h环境变量，让模型常驻内存。

再看是不是多个用户同时在用。如果群里多人同时@代理，代理需要排队处理请求，单个请求的等待时间会指数上升。这种情况要么限制群内同时触发的人数，要么升级硬件换更快的推理方式。

还有一个容易被忽视的点：模型上下文窗口越长，推理越慢。如果你设置了8192的上下文，代理每次都要处理前面积累的所有历史对话，Token多了之后单次响应时间会暴增。如果对长记忆的需求不强，把上下文窗口调回4096，响应速度立竿见影。

6.3 常见问题速查表

我把在部署和日常使用中收集到的高频问题整理成一个速查表，给后来的人少走弯路：

问题现象	可能原因	解决办法
安装时npm报EACCES权限错误	Node.js全局目录权限不足	用sudo执行，或修改npm全局目录归属
打开仪表盘显示空白页	浏览器缓存冲突	硬刷新（Ctrl+Shift+R），或换浏览器访问
飞书收不到代理回复	事件订阅URL未正确配置	检查webhook地址和事件订阅状态
回复内容乱码	模型编码异常	重启OpenClaw，并在配置里强制使用UTF-8
代理答非所问	上下文被其他会话污染	清理会话历史，重启服务
内存占用持续上涨	长期运行未释放资源	定期重启服务，升级到最新版本
模型拉取卡在进度条	Ollama默认源下载慢	在环境变量中改用国内镜像源
定时任务不触发	时区配置错误	检查系统时区和OpenClaw的schedule参数

7. 部署心得与建议

7.1 OpenClaw和WorkBuddy怎么选

经常有人问我：“OpenClaw和WorkBuddy哪个好？”这个问题其实问反了。它们根本不是同类工具，谈不上谁替代谁。

WorkBuddy本质是一个跑在手机上的自动化助手，主打场景是“让AI帮你操作手机App”——帮你发消息、帮你查资料、帮你点外卖。它的优势在端侧集成度，跟手机交互深度绑在一起。

OpenClaw则是跑在你自己的服务器或PC上，所有对话和任务都在你的环境里执行，核心优势是“连接一切”：连接你的消息渠道、连接你的模型后端、连接你的数据目录。如果追求的是手机端自动化操作，WorkBuddy更适合；如果你想在飞书群或者Telegram里挂一个7x24小时的智能代理，想自己控制数据，想接入本地大模型，OpenClaw是更合理的选择。

7.2 我在实际部署中踩过的几个坑

最后说几个我在部署心态和经验层面的体会。

不要图新鲜一上来就装最新版。OpenClaw迭代速度非常快，大版本更新后配置文件格式可能变化。我遇到过升级后发现配置不兼容、服务直接无法启动的情况。现在我的习惯是锁定一个稳定版本跑业务，新版本先在Docker环境里验证没问题再切换。

日志是好东西。OpenClaw的日志目录里记录了所有请求、响应、工具调用、报错信息。遇到问题不要瞎猜，先把日志翻一遍。很多时候问题原因就明明白白写在日志里，只是你不愿意看而已。

模型选型比功能配置更重要。我见过太多人把时间花在追求“花里胡哨的功能”上，结果模型太差，回复质量拉胯，整个代理就是个玩具。先把一个7B模型调好、把提示词打磨好，再考虑加更多能力，这样你的OpenClaw从第一天起就是可用的。

如果你也想在自己的机器上搭一个7x24小时在线的AI代理，希望这篇文章能帮你少踩几个坑。部署这个东西说难不难，说简单也不简单，关键就是花点时间把环境和配置吃透。祝顺利。