1. 为什么我在本地办公电脑上跑一个"龙虾"
先说句实在话：OpenClaw 这套东西，第一眼看上去很像又一个大而全的 AI Agent 平台，网上铺天盖地的都是"AI 接管电脑""数字员工"这类口号，实际部署的路数却被写得稀碎。我最初也是抱着试试的心态，想着反正本地已经有 Ollama 和几个开源模型，不如把这个"龙虾"（有人叫 OpenClaw，有人叫龙虾，其实都是同一个项目）装到办公电脑上，让它去处理一些需要组合工具的杂活。
但真正动手之后我才发现，OpenClaw 的价值恰恰在于"本地优先"这四个字。它不像某些云端 Agent 平台那样需要把数据送到第三方服务，而是可以完全跑在你自己控制的机器上：模型走本地 Ollama，工具调用、浏览器自动化、飞书/Teams 消息收发也都由你在配置文件里说了算。对于经常接触内部文档、客户资料的人，这个特性意味着数据不出本机，安全性直接高了一个档次。
这篇博文不是官方文档的复读，也不是照着仓库 README 念一遍。我会把我实际部署过程中踩过的坑、试错后的取舍、以及那些"文档里没写但你迟早会遇到"的问题，按一条完整的踩坑链路整理出来。适合谁看？适合准备在 Windows、Mac、Linux 甚至 NAS 上跑 OpenClaw，并希望接上 DeepSeek、千问或者本地 Ollama 模型的人。不管你是第一次听说"龙虾"，还是已经装到一半卡在报错上，这篇文章应该都能给你一点参考。
2. 部署前的环境准备：不要把第一步走成最后一步
2.1 硬件门槛：到底需要什么配置
OpenClaw 本身是一个控制编排框架，真正吃资源的是它调用的本地大模型。如果你完全没有显卡，又非要跑 27B 的千问，那体验会非常痛苦。我的建议是分三种情况看：
- 纯 CPU 环境：只适合跑 7B 以下的量化模型，或者干脆把 OpenClaw 当成一个"中转大脑"，模型请求转发到远程 API。
- 有 8GB 以上显存的消费级显卡：可以跑 Q4 量化的 7B~14B 模型，DeepSeek-R1-Distill-Qwen-7B、Qwen2.5-7B 这类都比较顺畅。
- 内存 32GB 以上、显存 16GB 以上：可以尝试 27B~32B 级别的模型，但推理延迟会明显升高，Agent 的响应速度会变成瓶颈。
实测下来，OpenClaw 本身的常驻内存占用其实不高，编译后的核心进程大概 300~500MB。它真正的问题是会话恢复：当多轮对话历史很长，且你同时挂了浏览器操作、飞书机器人、Teams 等多个 channel 时，内存会涨得很快。所以如果你的办公电脑只有 16GB 内存，建议在配置文件里限制对话历史轮数，或者只开两个 channel，否则很容易触发下文要说的 session 锁问题。
2.2 运行时选择：Docker、二进制还是源码
OpenClaw 官方目前提供三种部署姿势：源码运行、Docker Compose 部署、以及各个平台的一键安装脚本。我的建议是，办公电脑上优先用 Docker，NAS 上也优先用 Docker，只有你自己要改核心代码才选源码。
Docker 方案的最大优势是隔离环境和一条命令回滚。OpenClaw 的依赖关系比较复杂，它同时涉及 Node 子进程、Python 工具脚本、浏览器自动化组件，直接装在宿主机上一旦版本冲突，排错非常痛苦。我见过有人在 Windows 上装了 Python 3.12 和 Node 22，结果 OpenClaw 内部某个依赖还停留在旧的 API 上，跑起来全是诡异报错，最后把系统搞乱了。用 Docker 镜像的话，这些依赖全锁在容器里，宿主只需要一个 Docker 引擎就行。
如果你执意要用源码跑，请务必注意：安装依赖时不要用npm install一把梭，因为项目里有一部分 Python 侧的依赖是独立管理的，需要单独处理。很多人卡在启动阶段，不是代码问题，而是这两套依赖只装了一半。
2.3 本地模型选型：DeepSeek、千问还是 Minimax H3
OpenClaw 本身不绑定模型，你可以把它理解成一套"大脑插槽"：只要模型支持 OpenAI 兼容的接口，就能接进来。热词里有 DeepSeek、千问、Minimax H3，我分别说下我的实际感受。
- DeepSeek 系列：如果走本地部署，推荐 DeepSeek-R1-Distill-Qwen-7B，指令遵循能力在 Agent 场景里表现不错，工具调用的 JSON 输出比较稳定。如果你有云端 API 的预算，也可以把 DeepSeek 的官方 API 作为 provider 配进 OpenClaw，本地只负责流程控制，这样延迟会低很多。
- 千问（Qwen）系列：Qwen2.5-7B-Instruct 在我这边的表现是"最听话"的，多轮对话不容易跑偏，尤其是让龙虾去操作浏览器时，它给出的步骤更符合直觉。本地显存够的话，Qwen2.5-14B 会更稳，但为了这么个 Agent 把显存吃满，是否划算你要自己掂量。
- Minimax H3：属于比较新的模型，很多人问怎么在 OpenClaw 里接。它通常走的是在线 API，配置方式跟 OpenAI provider 类似，填入 API Key 和 base_url 就行。我不建议在本地强行部署 H3 系列的原始权重，参数规模太大，家用环境扛不住，除非你有专门的 GPU 服务器。
3. 安装 OpenClaw 的三种路径与踩坑记录
3.1 Windows 办公电脑：别用 PowerShell 硬跑
在 Windows 上安装 OpenClaw，最省事的是用 WSL2 装 Docker Desktop，然后在 WSL 里跑容器。直接在本机 PowerShell 里跑官方安装脚本不是不行，但会遇到两个问题：一是 Windows 的路径分隔符会让某些 Node 脚本报错，二是浏览器自动化组件在 Windows 桌面环境中权限不够稳定，经常出现"页面打不开但进程还在"的情况。
我的操作路径是这样的：
- 安装 WSL2，Ubuntu 22.04，分配 8GB 内存。
- 在 WSL 内安装 Docker Engine，而不是 Docker Desktop（因为办公电脑上 Desktop 的许可证和资源占用都麻烦一些）。
- 克隆 OpenClaw 仓库到 WSL 的
~/openclaw目录。 - 复制模板配置文件，修改模型 provider 和 channel 配置。
- 执行
docker-compose up -d启动。
启动后不要急着关终端，第一次启动要拉镜像、初始化 SQLite 数据库、启动浏览器自动化服务，整个过程在普通网络环境下可能需要十几分钟。我当时以为卡死了，差点 Ctrl+C，实际上只要日志在动就没问题。
3.2 Linux 服务器 / NAS：飞牛、群晖都能装
Linux 部署是最顺的，基本就是 Docker 一条路。热词里有人问"飞牛安装 openclaw"，实际上飞牛 OS 是基于 Debian 的 NAS 系统，只要它的套件中心支持 Docker，就能照常跑容器。唯一要注意的是端口映射：OpenClaw 默认管理端口不要跟 NAS 已有的 Web 服务冲突，我习惯把管理端口映射到 8765，然后通过反向代理走域名访问。
群晖、威联通也是同理。这些 NAS 的 Docker 管理界面虽然方便，但环境变量配置往往要一个字段一个字段填，容易漏。我建议绕过 GUI，直接在 SSH 里用docker compose文件启动，这样配置可以版本化管理，换机器迁移也方便。
3.3 一键脚本到底能不能用
官方提供了一键安装脚本，这个脚本在干净的 Linux 或 macOS 上确实好用。但在 Windows 上运行，它本质上是调用一堆依赖到用户目录，出了问题极难定位。另一个坑是：脚本默认会安装最新版 Node 和 Python，如果你机器上已经有其他项目依赖的旧版本，全局升级后那批项目就挂了。
所以我给个偏保守的建议：部署环境越干净，越用脚本；影响范围越大，越用 Docker。办公电脑上千万不要图省事跑一键脚本。
4. 把大脑接进来：模型 Provider 配置的完整思路
4.1 OpenAI 兼容接口是万能钥匙
OpenClaw 支持多种模型后端，但我在实际配置时发现一条规律：几乎所有模型都能通过 OpenAI 兼容接口接进来。无论是官方 API，还是一些开源模型框架提供的本地 mock 接口，只要给我一个base_url和api_key，OpenClaw 就能用。
配置结构大致是这样：
llm: provider: "openai-compatible" model: "qwen2.5-7b-instruct" api_key: "ollama" base_url: "http://host.docker.internal:11434/v1" temperature: 0.7 max_tokens: 4096这里有个关键细节：如果你用 Ollama 作为后端，api_key随便填一个非空值就行，Ollama 不校验 key。base_url一定要用容器访问宿主机的特殊域名，在 Docker Desktop 环境下是host.docker.internal，在纯 Linux 容器里可能要改成宿主机 IP。很多人配置完模型调用报连接失败，十有八九是这个地址写错了。
4.2 在线 API 与本地模型的混合使用
我在生产环境里更喜欢"混合路由"：简单任务走本地 7B 模型省时间，复杂任务转发到云端模型。OpenClaw 支持配置多个 provider，并在 agent 级别指定模型。比如让"龙虾"在处理内部文档摘要时用本地千问，在生成代码时用云端 DeepSeek。
做法是在config.yaml里定义多个 LLM 条目，然后在 agent 配置里引用：
agents: default: llm: local-qwen code: llm: cloud-deepseek这个模式特别适合办公场景：本地模型负责不敏感且重复性的操作，云端模型负责真正需要推理的任务。一来控制成本，二来避免把敏感数据全部送到外部 API。
4.3 千问接入配置里最容易错的两个字段
热词里专门有"openclaw 配置千问"，说明这里坑不少。我复盘下来，常见错误就两个：
model字段写成了不带-Instruct的简写。OpenClaw 会把这个字符串原样传给 Ollama，而 Ollama 上的模型 tag 通常是qwen2.5:7b-instruct，所以model: qwen2.5-7b-instruct并不等于 Ollama 的 tag，很可能报 model not found。严格对应的话，写成qwen2.5:7b-instruct或者干脆qwen2.5加任务参数。- 上下文长度设置不当。千问的 7B 模型默认上下文可能只有 8K，但 OpenClaw 的会话会叠加系统提示词、工具定义和对话历史，很快就把上下文撑爆。建议在配置里显式设置
num_ctx: 8192，同时在 OpenClaw 侧限制轮数。
5. Agent 与 Channel：让龙虾知道往哪儿爬
5.1 channel 到底是什么
很多人在问"openclaw agent 怎么选择 channel"，说明这一块确实是理解分水岭。在 OpenClaw 里，channel 指的是 Agent 的"进出口"，也就是消息从哪进来、结果往哪输出。它可以是命令行终端、HTTP API、飞书机器人、Teams Bot、Discord、Telegram，甚至是一个定时触发器。
选 channel 没有绝对标准，我一般按这个逻辑：
- 自己调试用命令行或 Web UI。
- 给团队用，走飞书或 Teams，这样大家不用装额外工具。
- 做自动化任务，用 HTTP 接口或定时触发，让龙虾自己按编排流程干活。
5.2 把龙虾接入飞书、Teams 的实操
接入飞书时，我踩过的坑是"事件订阅地址"必须公网可达。OpenClaw 跑在办公电脑上没有公网 IP，飞书后台会要求一个 HTTPS 回调地址。解决办法是：在飞书开放平台创建一个自建应用，然后把回调地址指向你内网穿透出来的域名，并且在 OpenClaw 配置里开启飞书 channel。
配置核心字段大概是：
channels: feishu: enabled: true app_id: "cli_xxxx" app_secret: "xxxx" encrypt_key: "xxxx" verification_token: "xxxx"Teams 的接入跟飞书大同小异，只是要在 Azure 门户注册应用、配置 Bot、拿到 App ID 和 Client Secret。如果你公司在用 Microsoft 365，Teams channel 的代价是要有一个能创建 Bot 的账号权限，普通用户自己去搞会卡在 API 权限审批上。
5.3 飞书输出容易被截断的根因
热词里专门有一条"openclaw 在飞书输出容易被截断"，这个问题我遇到过，而且非常烦。现象是：Agent 生成的长回复超过一定长度后，飞书那边只有前半段，后面戛然而止，没有任何报错。
排查链路是这样的：先抓 OpenClaw 侧的日志，看是否完整生成了回复。如果日志是完整的，说明问题出在飞书消息接口的 45 秒超时或消息长度限制上。飞书消息接口对单条文本长度有上限，OpenClaw 默认没做拆分，一条超长消息直接发过去，飞书只保留前半段。
解决办法有两个方向：第一，在 OpenClaw 配置里把max_output_size调低，让 Agent 分段产出；第二，给飞书 channel 加一个"分片发送"的中间层，把长消息按固定长度切成多条。前者的副作用是 Agent 可能觉得表达不完整，后者的实现稍微复杂但效果最稳。我在团队里用的就是后者的思路，切分长度设为 3600 字节，实测没有再出现截断。
5.4 其他 channel 的互通技巧
OpenClaw 的 channel 之间不是孤立的。我经常做一件事：在飞书里给龙虾发一句"把刚才的搜索整理一份发到 Teams 群"，这就需要配置里把两个 channel 同时启用，并且给每个 channel 一个唯一的 agent 入口。如果你的 channel 选错了，Agent 会找不到"从哪来"，直接回复一个"会话不存在"。
还有一个点：当多个用户同时调用同一 channel 时，OpenClaw 会根据发送者 ID 建立不同的 session。这个 session 机制就和下面要讲的大坑直接相关。
6. 会话锁与启动失败：那串 60000ms 报错的前因后果
6.1 报错在什么场景下出现
"agent failed before reply: session file locked (timeout 60000ms)" 这句话，我在本地部署的第二天就见到了，而且是在最不该出问题的时候——我在两个终端里同时打开同一个 agent 的会话，一个是用 Web UI 聊天，另一个是命令行发指令。
后来我发现，报错的原因是 OpenClaw 为每个 session 维护一个独立的 JSONL 会话文件，文件用独占锁的方式控制读写。当两个进程同时尝试写同一个 session 文件时，后到的进程会等待锁释放，默认等 60000 毫秒。如果 60 秒内前一个进程没有释放锁，就直接抛出这个错误。
更隐蔽的场景是：上一个对话还没有完全跑完，比如 Agent 还在等模型响应，你又发了第二条消息。由于模型推理比较慢，session 文件一直处于锁定状态，第二条消息等不到锁就直接失败了。
6.2 排查链路与修复方案
我复盘了一下，完整的排查链路应该按这个顺序走：
- 看进程列表里是否有多个 openclaw 实例在跑。不同终端分别用
lerun或npm start启动，就会有多个实例抢占同一个 session 目录。 - 看
~/.openclaw/sessions/目录下对应的.lock文件是否存在。如果文件还在但进程已经不在了，叫是上次异常退出留下的僵尸锁。 - 确认是否同一个 session 同时被两个 channel 使用。飞书和 Web UI 的 session key 如果都指向同一 agent，就会在同一文件上撞锁。
修复方案分三步：
- 先杀掉所有 OpenClaw 进程，把 sessions 目录里的
.lock文件删掉，相当于把闸门重置。 - 修改配置，确保 session 文件的路径按用户维度区分，不要所有 channel 共用一个 session 文件。
- 把锁超时时间调大，比如从 60000ms 改成 300000ms，至少能避免模型推理慢导致的假死。但这只是缓兵之计，根本解法还是保证同一个 session 同一时间只有一个调用者。
这个问题的本质是 OpenClaw 默认的 session 并发模型比较保守：宁可拒绝，也不写坏文件。理解了这一点，你就知道为什么网上有人建议"一个 agent 只挂一个 channel，一个时刻只处理一条消息"。
6.3 其他启动失败的常见诱因
除了会话锁，我安装时还遇到过：
- 端口被占用。OpenClaw 的默认端口如果已经被其他服务占掉，启动后管理界面打不开，但进程状态看起来正常。务必检查
netstat -tlnp。 - 数据库目录没有写权限。装在 NAS 上时最容易遇到，因为共享目录权限默认只读。这个报错通常发生在初始化数据库阶段，日志里会冒出 Permission denied。
- 浏览器子进程无法启动。OpenClaw 的电脑操作能力依赖无头浏览器，在 Docker 里缺少
--privileged或 GPU 加速库时，浏览器起不来，Agent 执行工具调用就会一直卡在 pending。
7. OpenClaw、Dify 和 Workbuddy：同台竞技之后我的选择
7.1 三者定位并不相同
OpenClaw 最近经常被人拿来跟 Dify、Workbuddy 比较。我的看法是，它们完全不是一类东西。Dify 是偏向"流程编排"的 LLM 应用平台，你可以在上面拖拽出知识库问答、工作流、Agent 甚至 RAG 管道，它更像是一个"应用开发平台"。Workbuddy 则更偏向消息助手和 CRM 场景，主打的是跟团队协作工具的深度集成。而 OpenClaw 更像个"个人数字替身"：它能直接操作浏览器、命令行、文件系统，在本地跟你的电脑环境进行真实交互，而不仅仅是处理和生成文本。
用我自己的话说：Dify 适合做对外服务的应用，Workbuddy 适合做团队内消息驱动的任务协作，OpenClaw 适合做"把我的电脑变成可编程的机器人"。
7.2 同场实测的一些体会
我在同一台机器上部署过 Dify 和 OpenClaw，后者在"自主执行"方面明显更鲁棒。Dify 的 Agent 节点逻辑上依赖 Dify 自身的流程控制，一旦某个工具调用超时，整个流程就卡在设计好的节点上，很难旁路。OpenClaw 的 Agent 则有更强的即时决策能力，在同一个任务里，它可以自己决定先调用浏览器还是先读取文件，展现出来更像一个在干活的人。
Workbuddy 我也简单试过。它在接入 Teams 和邮件方面做得比较顺手，但它的定位决定了它不会帮你操作本机软件。如果只是需要"群聊里自动回复、整理周报"，Workbuddy 上手更快；如果要"自动打开浏览器查资料、填表单、跑脚本"，OpenClaw 更合适。
7.3 我的选择逻辑
现在我的办公电脑上装的是 OpenClaw，原因是它把"本地模型"和"本地操作"这两件事融合得最好。Dify 很好，但它的强项不在"接管电脑"，而且 Dify 的本地部署资源占用也不小。Workbuddy 不适合我，因为我不需要一个额外的消息聚合中心。
反过来，如果你是在做企业内部知识库、客服问答，我建议你优先看 Dify；如果你公司已经重度使用 Teams，并且你需要的是一个"能聊天的助手"，那么 Workbuddy 可以给你一个更低的起点。选型不要看热度，要看你的任务到底发生在哪个边界里。
8. 一些让本地部署更舒服的调优细节
8.1 给 Agent 加独立的模型上下文预算
OpenClaw 的会话上下文是共享的，如果不做限制，早期一个长任务会把上下文占满，后面的工具调用就没有空间了。我的习惯是在每个 agent 的配置里设置独立的上下文轮数，默认不要超过 20 轮。对于需要长文档分析的任务，单独建一个analysisagent，把轮数放宽到 50，但同时只允许它访问特定目录，避免它乱动文件。
8.2 定时任务与手动触发的混合
如果你想让龙虾每天上午九点自动汇总一份报告，可以配一个 cron 类型的 channel：
channels: schedule: enabled: true jobs: - name: daily-report cron: "0 9 * * *" agent: reporter input: "生成昨天的项目进展摘要"这样就不需要人盯着发消息。但注意：定时任务开始的时候一定要确保没有其他会话锁在使用同一个 agent，否则就会触发前面说的 60000ms 报错。我通常让定时任务使用独立 agent 身份，从源头避免碰撞。
8.3 日志级别与控制台输出
OpenClaw 默认日志在终端里刷得又密又快，重要错误容易被淹没。建议把日志写入文件，并设置成 info 级别。排查会话锁问题时，日志里的session locked出现时间能帮你判断是谁在抢占锁。我习惯只保留最近七天的日志，定期清理，避免日志文件把磁盘憋爆。
8.4 升级与回滚策略
本地部署的一个隐形风险是升级后配置格式不兼容。我在升级之前都会把config.yaml和 sessions 目录整个打包备份。官方发新版本后，不要急着在生产环境升，先在测试容器里升一次，确认配置项没有破坏再动线上。这个习惯帮我躲过了至少两次配置字段改名引发的"启动即失败"事故。
写在最后的一点个人体会
OpenClaw 这类本地部署的 Agent 框架，最大的门槛其实不在安装，而在于把"模型调用、消息通道、本机操作、会话管理"这四件事的联动逻辑理清楚。很多人被那个 60000ms 的会话锁报错劝退，但只要理解了 session 文件锁的设计意图，它就不再是玄学。
我现在的办公流程里，OpenClaw 负责每天定时抓取行业资讯、整理会议纪要、自动汇总飞书群里的待办，偶尔还帮我跑一些浏览器脚本。它没有传说中那么"智能"，但胜在完全可控——模型在本地，数据在本地，触发规则也在本地。如果你也打算在办公电脑上部署一个龙虾，建议从最小配置起步：先接一个本地模型、一个命令行 channel、一个飞书机器人，跑通之后再逐步加能力。每加一层，都先把该层的日志和会话机制弄清楚。这样下来，你得到的不仅是一个能跑的 AI Agent，更是一条你自己完全能 debug 的链路。
