1. 为什么折腾：把OpenClaw装进家里NAS，图的是什么
最近在折腾“绿联NAS部署OpenClaw”这件事，最初的起因其实很简单：我想在家里养一个真正属于自己的AI管家。市面上的云端AI助手确实方便，但数据、对话记录、调用日志全都挂在别人的服务器上，心里总有点不踏实。而家里的NAS又常年开着，功耗不高、存储充足、网络也稳定，把它变成AI服务的宿主，几乎是顺理成章的一件事。
OpenClaw是一个开源AI智能体框架，你可以把它理解成一个常驻后台的“数字管家”。它不只是一个聊天窗口，而是能串联大模型API、调用工具、管理知识库、执行定时任务的平台型服务。部署在NAS上以后，它的价值就不仅是“能聊天”，而是能24小时待命，帮你整理资料、回答私有文档问题、定时抓取信息、结合家庭自动化做点轻量任务。本文面向的是想在家里低成本私有化部署AI服务的人，尤其是手里刚好有一台绿联NAS、又想折腾点新东西的朋友。我会尽量把每一步的原理讲清楚，而不只是丢命令。
1.1 OpenClaw到底解决什么问题
我试过不少AI辅助工具，最大的感受是：单机跑一个脚本很爽，但想让它长期稳定地“为我服务”，就需要一个常驻运行、可扩展、能接入各种模型的服务端程序。OpenClaw恰好是这种定位。
它的核心能力大致可以分成这几块：
- 多轮对话与工具调用：不只是回答问题，还能按规则去执行一些操作，比如查资料、调接口、生成文件；
- 多模型接入：既能用各家大模型API，也能接本地推理服务，比如NAS上用Docker跑一个Ollama，再让OpenClaw统一调度它们；
- RAG知识库：把私有文档扔进指定目录，系统建立索引后，你就能用自然语言提问，回答会基于你自己的文档内容生成；
- 定时任务与自动化：可以定义周期任务，比如每天早晨汇总新闻、定期生成报表、监控某个目录变化后触发提醒。
如果拿车来类比，裸装的NAS是一辆底盘不错的家用车，OpenClaw就是给它装上了一套能自动驾驶的智能座舱——底盘还是自己的，数据还是自己的，但开起来的感觉完全不一样了。
1.2 为什么必须跑在NAS上，而不是云服务器
有人会问，我用一台云服务器部署不是更简单吗？确实是更简单，但会失去NAS的几个关键优势。
我用下面这张表对比过实际体验：
| 对比项 | 云服务器 | 本地电脑 | 绿联NAS |
|---|---|---|---|
| 待机功耗与利用率 | 需要月租，闲置也花钱 | 开机才能用，关机就断 | 7x24在线，功耗低 |
| 数据归属 | 在厂商机房，法律风险模糊 | 在本地，但不常开 | 在本地，且磁盘阵列更稳 |
| 扩容能力 | 硬盘价格贵、容量小 | 看主机硬盘空间 | 按需加入硬盘，容量灵活 |
| 与家庭生态联动 | 连不回家里的内网服务 | 能做但网络拓扑绕 | 直接跑在家内网，天然有优势 |
| 折腾门槛 | 需要Linux运维基础 | 需要留一台机器常开 | Docker化部署，整体不难 |
对我来说，最核心的还是数据归属感。OpenClaw这类服务会积累大量个人知识、偏好和对话记录，跑在自己家里的NAS上，我至少能清楚知道这些数据存在哪块硬盘里，备份策略是什么，而不是指望某个云端厂商的隐私承诺。
1.3 为什么很多人选绿联NAS来跑这种容器
绿联NAS这几年在国内家庭用户里的存在感越来越强，尤其是在“好用”和“便宜”之间找到了一个比较好的平衡点。它的系统基于Linux，自带Docker环境，这意味着市面上大多数容器化服务都能直接搬上去跑，OpenClaw也不例外。
和某些封闭系统的NAS相比，绿联的开放程度让我这种喜欢折腾的人舒服很多：可以开SSH，可以装Docker Compose，可以自己挂载目录，系统更新频率也高。另外，绿联NAS大多采用X86架构的处理器，和主流Docker镜像的兼容性很好。如果你手里正好有一台这样的小机器，完全不需要再额外买云服务器或者小主机，直接把它用上，性价比非常高。
当然，它也有不够好的地方，比如系统某些版本升级后Docker配置会被重置、部分ARM机型兼容性较弱、官方应用商店里的容器管理界面偶尔不够直观。所以这篇分享里我也会把哪些坑值得提前规避讲清楚。
2. 动手前的准备：绿联NAS环境与目录规划
部署一个服务之前，我习惯先把环境摸清楚，再动手。毕竟OpenClaw是个常驻服务，跑起来以后如果发现目录挂错了、端口冲突了、内存不够了，再改就麻烦很多。
2.1 先确认你的机型能不能跑
OpenClaw本身是一个容器化服务，对硬件的要求不像本地大模型那么夸张，但你至少得确认这台绿联NAS满足几个底线条件：
| 配置项 | 最低要求 | 建议配置 | 备注 |
|---|---|---|---|
| CPU架构 | X86_64 | X86_64 | ARM机型需要额外验证镜像是否支持 |
| 内存 | 4GB | 8GB以上 | 如果还跑本地大模型，建议16GB |
| 存储空间 | 5GB以上 | 20GB以上 | 镜像、日志、知识库索引都会占空间 |
| 网络要求 | 能正常访问镜像仓库 | 下载稳定 | 拉大镜像时容易超时，要做好心理准备 |
我这台绿联NAS是X86架构、16G内存，跑OpenClaw加一个本地小模型轻轻松松。如果你的机器只有2G内存，那建议老老实实用在线API，别碰本地推理。
2.2 开启SSH，确认Docker和Compose版本
在绿联NAS上部署容器，最常用的入口是自带的Docker管理界面。不过我更推荐直接开SSH，无论是查看日志、修改配置文件，还是排查容器问题，命令行都远比图形界面高效。
登录NAS管理后台，在控制面板里找到终端/SSH设置，开启SSH功能。然后用你熟悉的终端工具连上去，先跑三个命令确认基础环境：
uname -m docker --version docker compose version正常情况下，第一行会输出x86_64，后两行会显示已安装的Docker和Compose版本。如果你的系统里没有docker compose命令，那就要先更新Docker包，或者在NAS的Docker管理界面里确认是否已经集成了Compose功能。绿联较新的系统版本基本都带Compose支持，老版本如果没有，可以升级系统，或者手动安装一个独立Compose二进制。
2.3 目录、端口和密钥一次性规划好
很多容器部署翻车，都翻在“目录不规划、端口不固定、密钥到处贴”这三件事上。我习惯在一开始就把结构建好，例如：
mkdir -p /volume1/docker/openclaw mkdir -p /volume1/docker/openclaw/data mkdir -p /volume1/docker/openclaw/logs mkdir -p /volume1/docker/openclaw/knowledge这里data用来放配置和会话数据，logs放运行日志，knowledge是后面挂RAG知识库用的目录。注意，不同绿联系统里挂载盘的路径不完全一样，有的机器是/volume1，有的是/vol1/1000，建议用df -h看一眼实际挂载点再创建目录。
端口方面，我给OpenClaw分配了一个不常用的端口，比如8080。如果这台NAS上已经跑着其他服务，先检查端口占用情况，避免撞车：
ss -tlnp | grep 8080密钥方面，我建议把API Key单独写进环境变量或.env文件，别直接写死在Compose里，也别随手发群里。你需要准备的是一个兼容OpenAI接口格式的大模型API密钥，如果打算用本地模型，则密钥这步可以暂时跳过。
3. 容器化部署全流程：从拉镜像到第一次对话
环境确认没问题以后，就可以正式部署了。我会先讲清楚版本选择逻辑，再给出完整的docker-compose.yml配置，最后讲解初始化和模型接入。
3.1 版本选择：不要条件反射用latest
第一次拉镜像时，很多人会直接写latest，图省事。但对于OpenClaw这种迭代速度很快的项目，latest常常意味着“每天都有可能变”，今天部署成功，明天重拉镜像可能就出现不兼容问题。
我更推荐的做法是：到项目的Release页面看一眼当前最新稳定版本号，比如v0.8.x，然后在Compose里固定写成这个具体版本。这样以后想升级时你能知道自己确切是从哪个版本升上来的，回滚也方便。日常尝鲜和临时测试可以用latest，但要长期挂在NAS上当服务用，固定版本是更稳的选择。
3.2 docker-compose.yml这样写
在/volume1/docker/openclaw目录下新建一个docker-compose.yml，内容大致如下：
services: openclaw: image: openclaw/openclaw:v0.8.x container_name: openclaw restart: unless-stopped ports: - "8080:8080" volumes: - ./data:/app/data - ./logs:/app/logs - ./knowledge:/app/knowledge environment: - TZ=Asia/Shanghai - OPENCLAW_PORT=8080 - OPENCLAW_LLM_PROVIDER=openai - OPENCLAW_OPENAI_API_KEY=sk-your-key-here - OPENCLAW_OPENAI_BASE_URL=https://api.openai.com/v1每个配置项我都解释一下，方便你按自己的情况改：
restart: unless-stopped：容器异常退出后会自动重启，NAS重启后也会自动拉起，这对常驻服务非常关键；ports-"8080:8080"：宿主机8080端口映射到容器内的8080端口。如果8080被占，改左边宿主机端口即可；volumes：把刚才建的三个目录挂进容器。路径里冒号前是宿主机目录，冒号后是容器内固定路径；OPENCLAW_LLM_PROVIDER：模型提供方，常用值是openai或ollama，取决于你用的是在线API还是本地模型；OPENCLAW_OPENAI_BASE_URL：兼容OpenAI接口的服务地址。如果你用的API服务商有自己专属地址，就把默认值替换掉。
3.3 启动、看日志、完成初次对话
在目录下执行：
docker compose up -d docker compose ps如果状态显示Up，接着看日志，确认服务有没有正常初始化：
docker compose logs -f openclaw正常情况下能看到Web服务启动的日志，显示监听在某个端口。如果日志里有报错，一般集中在两类：目录权限不对，或者环境变量里的API地址/密钥配错。这时候先把日志贴出来，按错误信息逐条排查。
首次启动后，根据你用的OpenClaw构建版本，可能会遇到两种情况：一种是项目自带Web管理界面，直接访问http://NAS的IP:8080就能看到初始化向导，按照提示创建一个管理员账号并配置模型；另一种是纯API/CLI形态，需要你在配置文件里把模型参数填好，然后通过命令行或接口调用来测试。
我自己习惯先用Web界面做一个最简单对话测试：让助手介绍一下自己、生成一段摘要。如果这一步通了，说明模型链路已经打通，OpenClaw的服务端已经能正常调用大模型了。接下来可以放心地做知识库、定时任务这些更复杂的功能。
4. 让OpenClaw真正好用：本地模型、知识库与远程访问
服务跑起来只是开始，真正让它融入生活和工作，还需要做三件关键事情：把本地模型接进来、把私有文档变成知识库、把访问通道延伸到内网之外。
4.1 把NAS上的本地模型接给OpenClaw
如果你不想把数据送给云端API，或者希望离线时候也能用，那就需要一台本地推理服务。绿联NAS虽然没有独立显卡，但CPU推理跑小参数模型完全可行，例如3B左右的中小模型，日常对话和简单问答完全够用。
先在NAS上用Docker把推理服务跑起来，示例命令如下：
docker run -d --name ollama \ -v /volume1/docker/openclaw/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama启动后把需要的小模型拉下来：
docker exec -it ollama ollama pull qwen2.5:3b然后回到OpenClaw的配置文件，把模型提供方改为本地推理服务：
environment: - OPENCLAW_LLM_PROVIDER=ollama - OPENCLAW_OLLAMA_URL=http://ollama:11434注意，这里如果OpenClaw和推理服务跑在同一个Compose网络里，可以用服务名ollama代替IP。如果两个容器不在同一个，就用NAS的内网IP地址，比如http://192.168.1.100:11434。
实际体验上，3B小模型速度一般，但胜在完全不依赖外网。如果NAS内存有16GB，可以试试更大的模型，不过推理时CPU占用会很高，注意观察温度。
4.2 给OpenClaw挂一个RAG知识库
RAG（检索增强生成）是最实用、也最容易被忽略的功能。通俗地说，就是你把个人文档放进一个目录，系统先把文档切块、向量化、建索引，之后你在提问时，系统会先从知识库中检索相关片段，再让大模型基于这些片段生成回答。这样做的好处是回答准确、有依据，不会胡编。
我在Compose中已经把./knowledge目录挂载成了容器的/app/knowledge。使用前，把需要喂的文档丢进这个目录即可，支持的格式一般包括txt、Markdown、PDF、Word等。文件放进去之后，到Web界面的知识库页面，新建一个知识库，选择/app/knowledge目录，触发一次索引构建。构建完成后，就可以在对话里启用知识库模式。
我个人的经验是：文档数量别贪多。一开始喂了200多份混杂的PDF，结果索引很慢，回答还经常东拼西凑。后来按主题拆成三四个知识库，每个库里只放关联度高的资料，回答质量明显提升。小技巧是，在提问时尽量把范围指清楚，比如“根据《XX方案》文档，总结一下成本预算”，比直接问“这个项目预算多少”更准。
4.3 让手机在外面也能连回家里的助手
在局域网里访问NAS上的服务很容易，但在外网环境想用OpenClaw，就需要一个安全可控的访问通道。最稳妥的做法不是把端口直接映射到公网，而是用内网穿透或异地组网工具，比如SSH隧道、frp、异地组网工具等，把家里的NAS服务暴露给特定设备。
考虑到安全和合规，我更推荐用异地组网类工具，它相当于给你的手机和家里的NAS之间建立一条私有隧道，外面的人扫不到你的服务。工具配置好以后，在外面直接用分配的虚拟IP访问OpenClaw的8080端口即可。整个过程不需要去改路由器，也不需要在防火墙上开放一堆端口，风险低很多。
如果实在要用公网访问，那就必须加反向代理，并启用HTTPS证书认证。与此同时，检查OpenClaw是否默认密码，如果有管理密码，务必在首次配置时就改成强密码；没有TOTP二次验证的话，不要把自己常用的个人文档接口暴露到公网。
5. 踩坑实录：绿联NAS上最容易翻车的五个点
这部分是整篇文章最想给你的经验总结。我踩过或者围观别人踩过的坑，基本都集中在下面五类，提前知道能省一整个晚上的折腾时间。
5.1 挂载目录权限不对，容器一直重启
这个坑非常典型。症状是docker compose up -d之后，容器一直在restarting，日志里反复出现Permission denied或者mkdir failed。
根因是宿主机目录的所有者和容器内进程用户不一致。绿联NAS本身有一套权限体系，如果目录是用某个管理员用户创建的，容器内跑服务的用户可能没权限写同一个目录。
排查顺序很明确：
ls -ld /volume1/docker/openclaw/data # 如果发现 owner 是 admin，而容器里以 uid 1000 运行，就可能冲突解决办法有两类：一是把宿主机目录的权限放宽，比如chmod -R 777，简单粗暴但不推荐，会有安全隐患；二是查项目镜像有没有支持PUID、PGID这类环境变量，如果有，就把宿主机目录的owner对应的UID/ GID传进去，比如：
environment: - PUID=1000 - PGID=1000这样容器进程就能合法读写宿主机目录，也不影响NAS原有权限体系。如果你的镜像没有提供这两个环境变量，再考虑用chown调整目录归属。
5.2 内存不足导致OOM，会话莫名其妙中断
OpenClaw本身占用不算高，但如果同时跑本地推理服务、知识库索引、前端界面，内存就可能吃紧。症状很迷惑：对话聊到一半报错，Web界面还能打开，日志里没任何异常。
这种情况多半是内核的OOM Killer把容器干掉了。用下面命令确认：
dmesg | grep -i oom # 如果看到 openclaw 出现在 killed process 里，基本锁定内存问题解决思路有三个。第一，给OpenClaw容器限制内存上限，不要让它在内存失控时拖垮整个NAS：
mem_limit: 2g第二，如果同时跑本地推理，把本地模型换更小的版本，或者减少推理时的并发请求。第三，看看NAS上有没有其他常驻服务占用内存，比如下载任务、相册AI识别，该停就停。
5.3 镜像下载慢，容器一直处于pull状态
这个问题在国内环境尤其明显。执行docker compose up -d后卡在拉取镜像，或者进度条半天不动，绝大多数情况是镜像源不够快。
绿联NAS的Docker配置里通常可以设置镜像加速地址。不同网络环境对加速源的可用性不一样，建议至少在配置里多准备两三个备用地址，然后重启Docker再拉一次。如果你家里网络条件本身就不太好，还可以考虑另一条路：在一台网络流畅的电脑上先docker pull镜像，再用docker save导出为tar包，传到NAS上用docker load导入，然后直接改Compose启动，不再让NAS自己下载。这个办法特别适合大镜像和需要反复部署的场景。
5.4 版本升级后配置不兼容
OpenClaw迭代速度快，升级本身不算难，真正麻烦的是升级以后配置不兼容。我遇到过的情况是：旧版本里配置的模型参数，在新版本里换了环境变量名，导致容器起来以后根本连不上模型。
千万记住一个原则：升级前先备份。最简单的方式是把整个/volume1/docker/openclaw目录打包备份，或者至少把data和logs目录复制一份。升级操作分四步：
# 1. 备份现行数据 cp -r /volume1/docker/openclaw/data /volume1/docker/openclaw/data.bak # 2. 拉新镜像并重启 docker compose pull docker compose up -d # 3. 查日志确认模型连接 docker compose logs -f openclaw # 4. 若失败则回滚到旧版本 # 把 compose 里的 image 版本改为旧版本号，再 docker compose up -d另外，升级前顺手看一眼项目Release页面上的变更说明，如果明确写了“Breaking changes”之类的提示，说明要手动调整配置，千万别直接覆盖。
5.5 暴露公网后的安全隐患
很多人在NAS上部署完服务后，喜欢在路由器上做一个端口转发，达到“在外面也能用”的目的。但如果没有配套的安全措施，这等于把家里的大门钥匙挂在了门口。
OpenClaw这类服务带的是个人数据和对话记录，一旦被扫描到并猜出默认口令，后果比单纯的NAS文件泄露更麻烦。我建议至少要满足三条底线：管理后台必须改掉默认密码，并通过强密码保护；不要直接在路由器的IP上转发外层端口作为管理界面；如果确实要用公网访问，一律经过反向代理加HTTPS，同时加IP白名单，日志保留在NAS本地。
如果你没有足够信心做好这些，我更推荐用第4节提到的异地组网方案，或者干脆只在局域网里使用。本地私有化服务的价值本身就在于“非必要不暴露”，在安全与便利之间，宁可先牺牲一部分便利，也别拿数据去换。
6. 写在最后：折腾一圈之后的真实感受
把OpenClaw跑在绿联NAS上这件事，本质上是在回答一个问题：普通人的AI服务能不能真正归自己所有。我折腾下来最大的体会是，技术上并没有太多高不可攀的难点，真正决定成败的是细节——目录权限有没有规划好、版本有没有固定、升级前有没有备份、远程访问有没有留后门。
如果你刚上手，我建议不用急着把本地模型、知识库、自动化一次性全配齐。第一次先只接通一个在线API，跑通对话链路，让OpenClaw在NAS上稳定运行两天，再慢慢加功能。这样即使后面出了问题，你也能很清楚是哪一步引入的。我自己就是在加完知识库后出现内存紧张，回退到最小配置后又逐步加回来，整个过程反而比一开始狂上功能顺利得多。
这个项目后续还可以继续扩展的方向也很多，比如把OpenClaw接到家庭自动化系统里，实现语音控制、自动化流程提醒，或者把它跟NAS上的定时备份任务打通，让它每天自动整理归档文件。只要底层数据和权限在自己手里，上面的玩法就能一直延伸下去。哪天等你把OpenClaw也跑起来了，欢迎再来一起交流你踩到的新坑。
