第一次把 OpenClaw 在 NAS 上跑通、并让飞书机器人回我第一句话的时候我盯着通知栏看了两三分钟。OpenClaw 这类能操作电脑、能调度工具、能接入多种消息平台的智能体大多数人默认装在 Windows 或 Mac 上跑而我的选择是放在家里绿联 NAS 的 Docker 容器里等于给它找了一个 24 小时不下班的工位也把“飞书聊条消息就能让 AI 干活”这条路彻底打通了。这篇文章完整还原这次的部署过程包括为什么选 NAS、镜像怎么拉、模型怎么配、飞书机器人怎么接以及那些最容易让人卡一整天的暗坑。想让 OpenClaw 常驻又不想一直开着电脑的人可以直接照下面的步骤操作。1. 为什么是 NAS先想清楚 OpenClaw 该住哪儿1.1 三种运行环境的真实对比在正式拉镜像之前我把 OpenClaw 放在笔记本、云服务器和本地台式机上都试了一圈。大部分教程默认你在自己电脑上跑但真正用起来位置选错会让你后续所有优化都白费。运行位置在线状态额外成本适合状态主要痛点Windows/Mac 本机睡眠、重启就中断无新增成本临时体验屏幕常亮、锁屏后任务容易中断云服务器全天在线每月数十到数百元对外提供公网服务成本高数据安全全凭云厂商信任NAS 容器全天在线几乎可以忽略长期运行的个人助理硬件性能有限网络链路需要额外处理我会把 OpenClaw 最终落在 NAS 上最重要的原因是“在线”和“隐私”这两个词被同时满足。智能体对我来说不是需要时手动打开的软件而是随时待命的人出门前在飞书给它发条消息说明一件事它在我到公司之前就该把需要整理的东西处理完。云服务器虽然也能做到全天在线但为一个随时可能闲下来的个人助理付月租还让对话记录、文件访问记录全部离开本地说实话心理上很不过关。NAS 正好同时满足这两点数据在自家柜子里不关机长期电费几乎可以忽略。1.2 OpenClaw 放进 NAS 后到底是个什么形态很多朋友第一次听说 OpenClaw 跑在 NAS 上会以为 NAS 在本地“思考模型”。这个理解说对了一半。OpenClaw 本身是一个 Node.js 写的智能体框架负责任务调度、工具调用、消息通道这一类“大脑皮层”工作真正负责语义理解的大模型可以走云端 API也可以走 NAS 本地跑的 Ollama/Qwen。NAS 在这里扮演的角色更像一个不肯关机的值班室把 OpenClaw 进程包在 Docker 容器里固定好配置让它持续跟飞书保持连接。如果你手上是 J4105、3865U 这一档的低功耗 NAS也不用一上来就打退堂鼓。OpenClaw 靠的更多是外网 API 的计算能力NAS 本地主要跑任务调度和消息通路。我在一台 J4125 CPU 的机器上跑过OpenClaw 容器稳定占用内存大约在 300MB 到 500MBCPU 平时只有零星跳动。真正吃资源的只有本地模型容器一个 Qwen2.5-3B 的量化模型大概需要 2-3GB 内存。所以我的结论是只要能装 DockerNAS 都可以跑 OpenClaw如果内存 16GB 以内本地模型那一步可以放弃安心走云端 API。Docker 部署的完整动作我现在拆开说。2. Docker 部署第一步版本、镜像和目录规划2.1 OpenClaw 的依赖和基本启动逻辑启动前的物料比较重要。OpenClaw 用 Node.js 写成如果你不用 Docker直接在 NAS shell 里npx openclaw跑Node.js 版本建议不低于 16/18我用的是 18.17.0。Ubuntu 系的 NAS 也可以直接装 Node.js 来跑但在裸机里跑最大的问题是配置目录没法定住一旦 NAS 重启node_modules 丢一个包就够你折腾半天。所以本文默认走 Docker 路线这部分内容无论你的 NAS 是群晖、绿联还是飞牛都适用。Docker 路线的行为链很简单拉镜像、映射数据、写配置、启动容器。难点集中在网络和配置而不是命令本身。我建议你先把数据目录规划好在 NAS 上建两个目录一个放配置和会话数据一个放日志。这样之后升级镜像、迁移到另一台 NAS、或者导出备份的时候都只用关心这两个目录。目录规划混乱是后续所有排障的隐形炸弹特别是 OpenClaw 这类配置密集的项目我宁愿一开始多花十分钟建目录也不愿后面被配置文件搞得焦头烂额。2.2 我落地的 docker-compose 配置这里分享一份我在绿联 NAS 上验证过的 compose 文件群晖 Container Manager 和飞牛 fnOS 的 Docker 应用也支持直接导入services: openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - 127.0.0.1:3000:3000 environment: - TZAsia/Shanghai - OPENCLAW_TZAsia/Shanghai volumes: - ./openclaw-data:/root/.openclaw - ./openclaw-logs:/var/log/openclaw ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./ollama-models:/root/.ollama ports: - 127.0.0.1:11434:11434几个细节解释一下。端口绑定 127.0.0.1 而不是 0.0.0.0意思是只有 NAS 本机里的容器能访问管理端口局域网内其他设备接触不到这个端口。我个人对端口暴露的态度一直是能少开就少开个人助理这种东西数据太敏感不值得为了手机远程管理多开一个 3000 端口承担风险。restart: unless-stopped也是必选项NAS 重启后容器会自动恢复否则“24 小时值班”严格来说是句空话。如果你在群晖上部署路径要写完整例如/volume1/docker/openclaw-data:/root/.openclaw因为群晖不同存储池的前缀格式不一样。绿联和飞牛则可以在文件管理器里先建好目录再把路径填到 compose 里。第一次运行时不用把工具链配完先把这个容器跑起来确认日志里出现健康输出再做其他扩展。2.3 三家 NAS 平台的 Docker 入口差异按你手上 NAS 品牌来入口不太一样群晖 DSM 7.2 以上用 Container Manager创建项目时导入 docker-compose.yml 即可。默认镜像源容易超时详见 2.4 节。绿联 NAS 的系统应用中心里有 Docker 应用UGOS Pro 支持项目模式同样可以直接导入 compose。飞牛 fnOS 更接近原生 Debian自带 Docker Compose用 SSH 进命令行操作反而最顺没有图形界面也能跑。所以这篇文章的操作步骤对这三种平台是通用的差别只在“在哪个页面导入 compose”。如果你用的是其他品牌的 NAS只要底层支持 Docker 和 docker-compose流程是一样的。唯一要注意的是部分 NAS 的 Docker 套件内置 Compose 版本比较老不支持version: 3.3这种声明直接把 version 行删掉即可新版 Compose 已经不太读这个字段。如果你不想用 compose单独在 Docker UI 里创建 openclaw 容器也完全可以核心是那几个 volume 和端口参数填对。2.4 Container Manager 拉取镜像失败的解决搜索热度里出现得最频繁的坑是群晖 Container Manager 无法下载镜像。故障现象一般两种搜索镜像一直转圈或者拉取到一半超时、EOF。根因基本都是 NAS 访问 Docker Hub 和 GHCR 的网络链路不稳解决思路不是反复重试而是给 Docker 配置镜像加速或者换一个可访问的镜像源。我在 2.2 的配置里用了docker.io而非ghcr.io这就是一个规避动作。很多开源项目默认发布到 ghcr.io而国内网络环境访问它经常失败。在 Docker 的daemon.json里配置 registry-mirrors 是更通用的做法常见路径是/etc/docker/daemon.json群晖也可以在 Container Manager 设置里找到 Registry 镜像配置写入如下结构{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.net ] }加完以后重启 Docker再去拉镜像。这里要明确一点镜像加速地址的可用性变化很快不能守着同一个地址用一年配置完发现拉不动就换新的别在失效地址上反复刷。如果这块实在拉不到 OpenClaw 镜像还有一个治本思路先在能访问的环境里把镜像 pull 下来导出成 tar 再导入 NAS 的 Docker同样能解决问题。我在实际操作里就靠这个办法跳过好几次 ghcr 的拦路虎。3. 给 OpenClaw 接大脑云端 Claude 和本地 Qwen2.5-3B3.1 模型配置入口和 Claude 模式OpenClaw 启动前必做的配置就是模型连接不然它只是个空壳。模型配置一般集中在配置文件里逻辑清晰provider 决定你走哪种协议name 决定具体模型apiKey 对应密钥。推荐的流程是第一次启动后用 CLI 生成默认配置再在编辑器里改字段避免因为 JSON 格式错一个逗号导致整个进程起不来。如果你使用 Claude 官方 API核心配置结构大概是{ model: { provider: anthropic, name: claude-sonnet-4-5, apiKey: sk-ant-xxxx } }这套对想尽快完整体验的人来说是最省事的不需要在 NAS 上装任何模型服务只要 NAS 能访问外网API 请求就能发出。日常对话足够流畅但注意 API 费用是按 token 算的个人助理这种场景虽然单次调用不贵累计下来还是要留意。我在刚开始跑的时候没看账单月底对着飞书机器人一长串对话记录算了一下成本才开始认真考虑本地模型。3.2 把 qwen2.5:3b 关联给 OpenClaw如果你不想把每一条对话都送到外部 API那么本地模型是绕不开的。NAS 上跑本地模型最常用的方案是 Ollama然后给 OpenClaw 配置一个 OpenAI 兼容的接口。先在 ollama 容器里拉模型docker exec -it ollama ollama pull qwen2.5:3b然后在 OpenClaw 配置里把 provider 切换成 OpenAI 兼容模式{ model: { provider: openai-compatible, name: qwen2.5:3b, baseUrl: http://127.0.0.1:11434/v1, apiKey: ollama } }注意两点。第一是baseUrl必须带/v1Ollama 的 OpenAI 兼容接口暴露在/v1路径下你只填http://127.0.0.1:11434OpenClaw 拼接路由时就会报 404。第二是apiKey随便填一个非空字符串Ollama 本身不校验密钥但 OpenClaw 的客户端库要求这个字段不能空着。这里也得给你打一针预防针3B 参数级别的本地模型能跑通“识别意图、调工具、回消息”但和 Claude 这类大模型的差距在长链路任务上非常明显。拿我自己试过的场景为例让它去飞书里找一份表格再总结qwen2.5:3b 在中途丢上下文是家常便饭工具调用的参数也可能偶尔变形。所以我实际把本地模型定位成“云端 API 临时不可用时的兜底”主力还是云端大模型。想纯本地建议内存 32GB 以上的 NAS 直接上 7B 或 14B 量化模型推理速度才能接近可用。3.3 模型协议冲突时怎么办配置模型最常见的云里雾里问题是“我明明按文档配了 anthropic 的 baseUrl为什么不生效”或者“openai-compatible 模式里工具调用异常”。这类问题通常和参数名不够标准有关。我的排查经验是先开日志再改配置OpenClaw 的日志会把每次模型请求的 HTTP 状态和错误体完整打出来看是模型名不存在、baseUrl 多了空格还是 apiKey 校验失败。第二步检查版本。OpenClaw 迭代很快很多表面上的玄学故障其实来自某个依赖版本回退把它升到稳定版后反而安静了。4. 飞书机器人接入从开放平台到长连接配置4.1 创建飞书应用和机器人OpenClaw 接入飞书本质上是把飞书当成一个人机交互通道用户在飞书里向机器人发消息飞书把事件推给 OpenClawOpenClaw 处理完再以机器人身份回复。标准做法是先创建企业自建应用。登录飞书开放平台开发者后台创建应用名称随意我起的是“值班助理”。添加“机器人”能力然后在“权限管理”开通三块权限读取用户发给机器人的单聊消息、以机器人身份发送消息、获取用户基本信息。不同版本界面可能叫法不一关键词是im:message和im:message:send_as_bot这一串。这一步的坑不在创建而在发布。飞书应用的权限默认没有真正生效你需要提交一个版本并在后台发布确认版本状态变成“可用”机器人才真正在飞书里能够应答。只创建 app 是不作数的这点和很多只做内部工具的开发者直觉差距比较大。4.2 用长连接模式避免公网暴露飞书事件订阅支持两种模式。一种是 HTTP 回调需要你有一个公网 HTTPS 地址飞书才会把事件 POST 给应用另一种是长连接飞书开放平台主动和你的应用建立一条 WebSocket 通道。部署在 NAS 上的服务选长连接是天然的优解不需要公网端口映射、不需要内网穿透、不需要 HTTPS 证书三层麻烦全部消失。在 OpenClaw 的 channels 配置里的写法是这样{ channels: { feishu: { appId: cli_xxxxx, appSecret: 你的应用密钥, mode: long-connection } } }appId和appSecret都在飞书开放平台“凭证与基础信息”页面里appSecret自己要保管好。配置生效后OpenClaw 的日志会打印一条类似“feishu connection established”的信息。看到这条日志后不要立刻信心满满去飞书里给机器人发一句“你好”打个照面。对于 OpenClaw 本体的运行日志就是它的轨迹消息进没进来、出去没出去每一行都能看到。4.3 收到“成功”消息也躲不开两个细节第一个是权限缓存。飞书权限发布后有一小段生效延迟刚开通权限就测试经常收到“机器人未启用”或直接无响应。我的个人习惯是发布后等一两分钟再把飞书客户端里的会话窗口关闭重开让客户端重新拉取应用信息。第二个是群聊过滤。OpenClaw 默认往往只处理单聊和 机器人的消息把它丢进一个群但不 它消息很可能被框架过滤。这个不是通道坏了是消息过滤规则。去配置里找atOnly或mentionOnly之类的开关按需改。很多部署者卡在“飞书发消息没反应”这个看似绝望的问题上一半是权限没生效一半是没 机器人。5. 部署期最容易让人上头的一整排坑5.1 Windows companion 的“无法安全验证”与 WSL 状态如果你在 Windows 上使用 OpenClaw 的 companion 组件可能会看到一个特别唬人的提示“无法安全验证 SL2 环境。请在 PowerShell 中运行wsl --status解决报告的问题。”我第一次看到时以为是镜像校验坏了实际上它是在说 Windows 子系统WSL环境不满足 OpenClaw 对 WSL2 的验证要求。在 PowerShell 里执行wsl --status确认当前版本是 WSL2。如果显示 WSL1用wsl --set-version 发行版名 2升级。如果 Windows 的 WSL 内核太老wsl --update拉取新内核基本能解决。这个报错跟 OpenClaw 本体没有关系只要 WSL 恢复让 companion 重新连接即可。按本文路线把 OpenClaw 跑在 NAS 里的用户可以跳过这段因为在 Linux 环境没有这个组件。5.2 OpenClaw 报 TLS 证书无法验证的问题OpenClaw 由 Node.js 编写而 Node.js 对自签名证书和私有 CA 环境非常敏感。在公司内网、NAS 开了自定义证书或反向代理 HTTPS 到 OpenClaw 时很容易看到UNABLE_TO_VERIFY_LEAF_SIGNATURE。这个错误的意思是SSL 证书链的叶子证书无法被验证并不是 OpenClaw 坏了。我的排查按照三个顺序来。先拿curl验证目标地址的证书是否有效再校准系统时间证书链对时间非常敏感最后确认是自签证书的话把 CA 证书加入系统信任区而不是随手关校验。自己私下排查时可以用NODE_TLS_REJECT_UNAUTHORIZED0临时跑一次绝对不要用于公网和生产环境等于彻底关掉加密校验。实际上连接本地 Ollama 我干脆走 127.0.0.1 的明文 HTTP直接绕开整个证书问题。5.3 群晖 Container Manager 无法下载镜像的三类根因超时和 EOF 之外还有两个高频根因容易被忽略。第一磁盘空间不足。Container Manager 拉镜像时不会提前检查分区剩余容量而是在解压镜像层时报no space left on device。搜镜像的时候一直转圈容易让人误判成网络问题。建议看下 Docker root 所在分区的剩余空间如果低于 10%优先清理无用镜像或者把 Docker 根目录迁移到大容量卷。第二DNS 解析问题。NAS 的 DNS 设置如果有问题Docker Hub 域名解析会失败拉镜像有时十分钟没进度。在 SSH 里执行nslookup registry-1.docker.io解析不通或返回异常 IP就换公共 DNS 并重启 Docker。很多“玄学拉镜像失败”的案例到这一步基本都能找到病根。6. 把 OpenClaw 当“数字同事”用了一周后的真实感受6.1 通过飞书派活的一天现在我的早晨通常从把一段语音或者会议纪要发给飞书机器人开始。我让它把纪要里的待办事项拆成任务清单再同步到 Obsidian 里晚上回家打开 Obsidian 就能看到整理好的内容。OpenClaw 在这一套链路里做的事情是收到飞书消息调用工具去读文件调用模型去理解文档再把结果存回 Obsidian最后通过飞书回执给我。整个过程无论是手机还是电脑都能触发NAS 就安静地待在柜子里执行。真实体验说两句。好的方面是它具备了长期服务的调性不用像以前一样回家打开电脑才想起还有个智能体忘了跑。另一方面别拿 demo 效果来衡量实际落地任何智能体都要花几天去调工具、练数据、适应你自己的习惯OpenClaw 也一样。它更像一个需要你把步骤交代清楚的实习生而不是全知全能的老员工。给它一个模糊任务它大概率也会回一个模糊结果这是目前所有智能体的通病。6.2 接下来我会做的两件事第一是丰富工具集。OpenClaw 支持通过 MCP 这类标准协议扩展工具我准备把日历、邮件、下载任务管理器都接进来让飞书成为所有重复性工作统一入口。第二是把备份做好。OpenClaw 的配置目录和会话历史都放在挂载卷里定时快照、一键回滚这样升级镜像或改坏配置时不会把自己坑到。数据在自己手上故障恢复完全可控。如果你也要在 NAS 上长期跑 OpenClaw我最后的建议很朴实先慢后快多读日志。第一次部署别贪心一步到位接飞书、本地模型、Obsidian 三件套先把容器跑起来保证 CLI 里能对话再逐步配置模型和通道。每一步都能定位到具体新增环节的问题才不会被报错吓得怀疑人生。回看这几天的经历大部分时间都花在镜像源、证书、飞书权限这些“外围设施”上真正的 OpenClaw 配置反而没花太久。把这些外围坑写出来希望后来的人能少走一轮弯路。