1. 为什么选择“24/7 值守”而不是“临时开启”——部署思路的差别1.1 私人助理的本质是长期任务不是问答窗口很多人第一次接触这类工具时容易把它理解成一个“更聪明的聊天框”打开网页、输入问题、拿到回答完事。但“私人 AI 助理”的真实价值恰恰藏在那些不需要你盯着的时刻里。举个例子我想让它每天上午九点前汇总我订阅的几个行业资讯整理成一条五百字的简报发到我常用的通讯软件里再让它每周五下午整理本周会议待办、抓取某个网页上变动后的价格。这类任务的特点是运行时间是固定的运行环境却不固定。我得保证网页能打开、依赖的浏览器进程不被杀、模型接口调用不会因为网络抖动而中断。如果每次只是临时起意跑一下脚本那它就不是“助理”而是“计算器”。所以我一开始就明确了目标用部署的思路而不是“运行”的思路来对待 OpenClaw。我需要的是一套常驻的服务进程它要有独立的数据目录、可配置的环境变量、自动重启的兜底机制以及从外网访问时的安全边界。换句话说我要把它当成一个“小服务器”来养而不是一个“小程序”来开。1.2 在开始部署前确认的三个预期在写任何配置之前先聊三个容易被忽略的预期它们会直接决定你选哪种部署方案。第一你有多少“愿意给它留”的资源OpenClaw 本身不是一个重负载的大模型推理程序它更多是负责编排和调用。真正消耗资源的是它操控的浏览器实例、内存里维护的上下文以及偶尔并行执行的任务队列。按我的经验单实例日常运行2 核 CPU 加 4GB 内存是底线如果你还要让它同时控制多个浏览器标签页内存最好放到 8GB。选方案前先看看手头的机器是不是够这个数。第二你希望助理的数据存在哪里对话历史、登录凭证、浏览器会话文件、定时任务清单这些都是实际落盘的东西。放在个人开发机里隐私性最好放在云主机上访问更稳定但前提是你信任云服务商对数据的隔离策略放在 NAS 上则要考虑内网访问的便利性和外网接入方式的合规性。第三你的使用是“高频交互”还是“低频值守”如果只是偶尔打开面板看一下推送结果那局域网内跑一个实例绰绰有余如果出差在外也希望随时能通过手机端回话、远程调整任务那就得考虑外部访问链路。这个判断直接影响后面三个方案的取舍。2. 部署方案之一开发机上的轻量 Docker 实例快速验证2.1 适合这个方案的场景判断第一种方案我把它定位成“验证期方案”。适合刚接触 OpenClaw、想先跑通基础流程的开发者。我自己第一次部署也走的是这条路在平时开发用的那台 Linux 工作站上用 Docker 把服务拉起来然后花一个晚上验证邮箱接入、网页抓取、定时推送这三件事能不能跑通。这个方案最大的优点是动作快、回滚容易。出问题了直接删容器重建数据目录单独挂载不会污染系统环境。缺点也明显开发机不是 7×24 小夜班岗位晚上关机会直接掐断定时任务而且开发机上大量无关进程占资源长期跑容易和构建任务抢内存。所以它只适合验证不适合作为最终形态。2.2 初始化数据目录与 compose 配置Docker 部署的核心是数据持久化这一点我反复强调。OpenClaw 的所有运行时状态都写在某个身份目录里包括登录过的网站会话、任务调度的数据库、日志文件。如果图省事没有挂目录容器一删相当于给助理做了个“无麻醉失忆手术”一切从零开始。我会在主机上建立一个干净的项目目录专门放配置与数据mkdir -p ~/openclaw/{data,config} cd ~/openclaw touch .env然后写一份最精简的docker-compose.ymlservices: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: # 这里刻意绑定本地回环地址先不对外开放 - 127.0.0.1:8000:8000 environment: - TZAsia/Shanghai - CLAW_MODEL_PROVIDERopenai_compatible - CLAW_MODEL_NAME你的模型名称 - CLAW_LLM_API_KEY${LLM_API_KEY} volumes: - ./data:/home extra_hosts: - host.docker.internal:host-gateway这里有几个值得说明的细节。restart: unless-stopped是 Docker 自带的守护策略只要不是手动停掉容器进程异常退出后 Docker 都会重新拉起这比裸跑进程要可靠得多。端口特意绑定127.0.0.1是为了让本地验证阶段的服务只在本机可见——这一步可以避免后续误开公网导致面板裸奔。./data:/home是关键挂载。OpenClaw 默认把用户态的数据放在容器内的/home目录把它映射到宿主机上才能保证升级镜像、重建容器后身份和对话记录还在。TZ环境变量也别省定时任务调度和日志时间显示都依赖它后面排错时有你感谢它的地方。2.3 首次启动与连接验证启动前先准备环境变量文件echo LLM_API_KEYsk-你自己的密钥 .env然后执行docker compose up -d docker compose logs -f openclaw看到日志里出现服务启动成功的标志后在浏览器里打开http://127.0.0.1:8000会进入初始设置流程。第一次会要求确认模型接入参数和身份信息填好后我建议不要急着配复杂任务先丢一句最基础的指令让它搜索某个公开网页然后总结返回结果。这一步验证的不只是模型联网能力更重要的是让你确认浏览器自动化模块有没有正常工作。很多坑都会在这里暴露后面第五节我会细说。验证通过后可以给它安排一条简单的定时任务比如每天早上八点播报天气然后关掉电脑屏幕等到第二天看结果。能顺利完成这一步说明方案一已经达标。2.4 这个方案最容易忽略的细节开发机方案有几个藏得很深的坑我一个个踩过写出来避免你重复。首先是 Docker 的日志膨胀问题。OpenClaw 跑久了容器日志会变得非常大尤其是调试阶段大量打印请求头。建议在 compose 里加上日志轮转配置logging: driver: json-file options: max-size: 20m max-file: 5其次是内存杀进程的隐患。开发机上动不动跑编译任务资源紧张时系统会优先清理内存占用大的进程。Docker 容器本身不设内存限制的话可能出现服务假死、面板无响应的状况。我建议在 compose 里给服务画一条内存红线deploy: resources: limits: memory: 4g最后如果你所在网络访问模型接口存在波动需要在环境变量里调大超时时间。默认超时对国内网络环境不太友好我一般会把重试次数设为 3、超时时间加到 120 秒。具体参数名可能随版本变化以官方文档的说明为准。3. 部署方案之二云主机上的全时运行实例生产级3.1 为什么会选择云主机上的独立机器本地开发机验证完毕后我开始认真考虑让它真正 7×24 小时履职。最直接的想法是买一台便宜的云主机把整套环境搬到上面。这个选择的核心逻辑是“独立运行环境”带来的确定性云主机不会因为我自己电脑重启而中断网络带宽比家庭宽带上行更稳定而且它天然拥有一个固定的公网地址后续接入外部服务、回调通知都方便。但也有代价数据不在自己手里每年要掏一笔租用费用以及需要自己把控系统的安全基线。具体选什么配置我按前面提的资源预期来定2 核 CPU、4GB 内存起步硬盘 40GB 就够用带宽按 3 到 5M 计。这样的机器跑一个单实例 OpenClaw 完全够用费用也压得住。如果你的任务里包含大量网页访问、截图处理建议把内存上调到 8GB。3.2 用 systemd 托管容器交出重启的控制权有人会说Docker 的restart: unless-stopped不是已经能自动重启了吗为什么还要上 systemd我的体会是这两者守护的层次不一样。Docker 的 restart 策略照顾的是容器内部进程崩溃systemd 照顾的是“整台机器开始启动后我的服务到底有没有跟着起来”。云主机重启的场景并不罕见内核更新、计划内维护、意外断电恢复。如果 Docker 服务本身没起来或者容器依赖的网络接口还没就绪那restart策略也无能为力。用 systemd 把容器服务声明成开机自启项等于把“助理恢复运行”这件事变成操作系统层面的职责。我在/etc/systemd/system/openclaw.service里这样写[Unit] DescriptionOpenClaw AI Assistant Service Requiresdocker.service Afterdocker.service network-online.target [Service] Typeoneshot RemainAfterExityes WorkingDirectory/opt/openclaw ExecStart/usr/bin/docker compose up -d ExecStop/usr/bin/docker compose down TimeoutStartSec120 [Install] WantedBymulti-user.target写好后执行sudo systemctl daemon-reload sudo systemctl enable openclaw.service sudo systemctl start openclaw.service这个单元有几个细节值得说。Typeoneshot配合RemainAfterExityes是一种比较稳妥的写法docker compose up -d命令本身会立即返回并不会一直占据前台设置RemainAfterExit是为了让 systemd 认为服务一直处于活动状态这样用systemctl status查看时不会出现“明明在跑却显示死掉”的怪象。Afternetwork-online.target则确保网络服务准备好后再启动容器避免容器起来后因为网络未就绪而反复崩溃。3.3 HTTPS 与外部访问接入域名的注意事项云主机部署的下一步是解决外部访问问题。我不建议直接把容器的端口映射到云主机公网上裸奔也不建议用容器内部自带的 HTTP 服务直接面对公网。更稳妥的做法是让 OpenClaw 只监听在云主机内网地址或回环地址上前面再放一层反向网关也就是 Nginx 或 Caddy 这类工具由它负责终止 TLS、加上访问鉴权再转发到本机端口。我实际用的是 Caddy简单直接。在/etc/caddy/Caddyfile里配置一个站点assistant.example.com { reverse_proxy 127.0.0.1:8000 basicauth { assistant 你的密码哈希 } }如果你手头没有域名也可以用 IP 直连但那样就得自签证书或者忍受明文传输。我的建议是既然都上云主机长期跑了花几十块钱注册一个域名用 Caddy 自动申请证书体验差距非常大。访问层面至少要有 Basic Auth 这一层有条件的话再配合访问 IP 白名单。云主机控制台的安全组里我只放行 80 和 443 端口其余端口一律关闭容器的映射端口保持在127.0.0.1:8000不对外暴露。这一套组合下来助理有了一个 HTTPS 入口我出门用手机打开面板至少不会一进页面就瞟到明文传输的警告。3.4 备份与升级如何避免一场事故说句不好听的云主机上跑服务“数据丢了”是迟早会遇到的课题。OpenClaw 的./data目录里存着会话记录、浏览器登录态、定时任务配置任何一个丢失都挺肉疼。我从一开始就写了一个简单的定时备份脚本放到 cron 里每天执行#!/bin/bash BACKUP_DIR/backup/openclaw mkdir -p $BACKUP_DIR tar czf $BACKUP_DIR/openclaw-$(date %F).tar.gz -C /opt/openclaw data find $BACKUP_DIR -type f -name *.tar.gz -mtime 7 -delete备份策略没什么高深的关键是“有自动”这三个字。人总会忘记手动备份但 cron 不会。备份文件保留 7 天滚动如果磁盘富余可以延长到 30 天。升级这件事我多说两句。OpenClaw 的镜像迭代很快每次升级前先看变更说明升级前手动打一次快照或完整备份。升级命令本身很常规cd /opt/openclaw docker compose pull docker compose up -d但升级后务必检查两件事一是数据目录结构有没有变化二是环境变量名有没有被改名。我遇到过一次升级后任务调度表读不出来就是因为新版本改了数据库文件路径旧数据目录没有自动迁移。后来我养成了习惯任何一次升级后先执行一条简单指令确认对话记录还在再让它跑任务。4. 部署方案之三NAS 或家庭服务器的私有化运行数据留在本地4.1 困扰数据归属问题把助理部署到云主机上当然省心但有个问题会像一根刺一样卡在喉咙里我的所有对话记录、浏览历史、日程数据都放在一台不是自己掌控的机器上。哪怕云服务商再怎么说隔离策略心理上总是有疙瘩。于是我开始研究第三种方案利用家里的 NAS 或自建的迷你服务器来跑。这个方案的核心诉求只有一个——数据不出门。助理的模型等外部接口调用输出还是要经过网络但任务记录、会话凭证、定时调度这些核心资产全部落在自家硬盘上。对数据敏感程度比较高、或者单纯想折腾自托管的人来说这是最有吸引力的路线。4.2 NAS 部署中的目录规划与 URL 暴露策略在 NAS 上部署 OpenClaw跟前面两种方案在容器层面没有本质区别依然是 Docker Compose。但有几个 NAS 特有的事项必须处理妥当。第一是目录规划。NAS 的存储通常是共享目录和 Docker 的数据卷做好隔离非常重要。我会把 OpenClaw 的数据单独放到一个独立共享目录下比如/volume1/docker/openclaw权限收紧不要让其他普通用户可以访问到。如果 NAS 支持快照功能记得把该目录纳入快照计划这比远程备份更简单直给。第二是端口暴露策略。NAS 一般就在家庭内网里面板只需要内网设备能访问就行。不要让 NAS 上的容器端口直接映射到公网。我自己的设置是容器端口保持8000NAS 上设置端口转发时只转发到内网地址公网访问一律通过前面说的带鉴权反向网关来完成没有网关就干脆不开放公网访问。其实对绝大多数“私人助理”的使用场景来说公网访问并没有想象中那么必需。我在家就用内网 IP 打开面板出门的时候用远程连接软件先回到家庭网络环境再访问面板效果完全够用还少了一层被扫描的风险。4.3 内网自动化与定时任务调整NAS 上的持续运行要额外考虑两件事停电恢复和资源分配。大部分家用 NAS 支持 UPS 配合自动关机但容器服务的恢复顺序依然要设计好。比如你的 NAS 上可能同时跑着下载服务、媒体服务、监控服务重启后资源分配容易打架。我的做法是把 OpenClaw 的容器 CPU 和内存上限在 compose 里声明清楚别让它和媒体转码抢资源。同时确认容器随 Docker 服务启动的机制NAS 的 Docker 套件一般都有“开机启动容器”的选项手动确认勾上即可。定时任务的时间跨度也要适应家用网络的实际情况。家里宽带有夜间断线或光猫重拨的现象非常常见OpenClaw 凌晨的定时任务有可能赶上网断掉那几分钟。如果某个任务特别重要可以在任务描述里加上“执行失败后等待十分钟重试”这样的约束能提高不少成功率。4.4 和其它设备进行配合家庭部署方案真正有意思的地方是它能和家里其他设备联动。NAS 上如果跑了其他自动化工具只要是在同一内网里就可以把 OpenClaw 的 HTTP 能力暴露给它们使用。举一个最简单的例子我家里有一台智能家居的自动化小主机它可以发 HTTP 请求。我在 OpenClaw 里设置了一个自定义入口专门接收这台小主机发来的传感器状态变化。这样一来助理不只是被动回答问题的聊天窗口而是成了整个家庭自动化信息的汇聚点。虽然这已经超出了最基础部署的范畴但我觉得这才是“私人助理”在家庭环境应有的样子它活在你的内网里和你的设备说话而不只是你手机里另一个聊天应用。5. 三个方案踩过一遍后的共同注意事项与排错5.1 容器重启后助理对话记录不见了这个坑我几乎可以断定每个新手都会遇到。表现是docker compose restart之后打开面板发现身份信息没了、对话历史清空了仿佛换了一台新机器。原因几乎都是数据卷没挂对。OpenClaw 运行时的数据并不是全部存在容器默认的数据目录里不同的版本可能存放路径不同。建议在部署完成后先到容器里确认一下真正写到磁盘的路径是什么docker exec -it openclaw ls -la /home因为不同镜像版本对数据目录的规划不一样有的版本把数据放在/home有的可能放在自定义路径。最靠谱的做法是把整个用户态目录挂载出来比如/home并且在升级镜像前先 grep 一下新镜像的文档避免路径迁移导致旧数据变成“孤儿数据”。5.2 夜里的定时任务差了几小时时区问题的排查第二个高频问题是定时任务时间不对。比如设置每天早上八点推送结果九点才执行。绝大多数情况下是容器的时区没有设置容器内部默认用了 UTC 时间比东八区慢了八小时。解决方式就是在 compose 的环境变量里显式设置environment: - TZAsia/Shanghai但要注意光设置 TZ 环境变量不一定会把时间相关的库全都覆盖到位。如果设置了 TZ 后依然偏差可以在启动容器时把主机的时区文件也挂载进去或者进入到容器里检查一下/etc/localtime是否为东八区。我自己的项目里两种措施都上了保证万无一失。5.3 引擎调用失败与重试策略OpenClaw 本身依赖外部大模型的接口能力。如果你所在的网络环境访问该接口不稳定会看到任务执行报错、返回空结果甚至进程超时。这事儿的排查思路是这样的先判断是网络问题还是配置问题方法也简单在容器里单独 curl 一下对应接口地址看能不能通、响应时间多少。如果确认网络没问题那就是调用参数问题了。重试次数、超时时间、并发数这些参数不同版本有不同默认值。按我的经验把超时时间调大到 120 秒、重试次数设成 3能覆盖绝大多数瞬时抖动的情况。另外同一个时间点不要堆叠太多并发任务会挤爆接口频控我一般会把任务加重试说明“如果失败请间隔五分钟后重试”。5.4 面板地址暴露到公网如何处理这个问题排在“最危险排行”里毫无争议。很多人在云主机上部署完后直接把容器端口映射到0.0.0.0然后用http://公网IP:8000来访问。一旦你这个面板没有做身份认证它就会暴露在公网扫描之下用不了多久就会被陌生请求塞满。处理办法我在方案二里已经写过套一个带鉴权的反向网关加上 IP 白名单端口只放行 443。如果一定要直接暴露端口至少设置一层强密码的 Basic Auth并开启面板自带的邀请码或令牌认证。这里没有“过度防护”这一说毕竟助理手里有你的邮箱读取权限、日历权限、甚至浏览器会话泄露的后果远比丢一台服务器严重。5.5 升级镜像的前后自查升级本身不难难的是升级之后的老配置兼容问题。我列了一个自查清单供参考升级前确认数据目录完整备份rc 版本变更多少环境变量名是否有变化。升级后立即执行一条最简单的指令验证链路检查日志有无关于数据库迁移或目录迁移的警告确认浏览器自动化模块是否还是旧版行为。观察期不要一升级就塞大量复杂任务先让它跑 24 小时看稳定性再逐步恢复原有任务计划。这套流程看起来繁琐但能挡住大多数升级事故。我自己有一次升级后没有检查数据库迁移提示结果日志刷屏报错排查了半天才发现是旧数据目录里的锁文件没释放。降级容易数据弄乱了才麻烦。6. 方案选型建议根据自己的习惯决定6.1 三者的取舍表三种方案各说了一大篇最后落一张取舍表可能更直观维度开发机 Docker云主机生产部署NAS 私有化部署上手速度最快半小时可跑通中等需要域名和网关中等依赖 NAS 环境持续在线差关机即停最好设备专门值守好NAS 电费成本低数据归属本地开发机第三方机房完全本地外网访问不方便方便HTTPS 整套需要额外穿透链路成本无额外成本按年租用电费 硬件折旧适合人群初次体验、功能验证重度使用、随时随地访问数据敏感、内网联动这张表不是非黑即白的选择题更像是帮你定位自己在哪个坐标上。我个人见过的最常见路径是先用方案一验证功能然后升级到方案二提升可用性运行稳定后再把数据迁移回方案三把敏感部分留在家里、把对外入口放在云上。6.2 我个人的使用心得与建议折腾了这么一大圈我最终的形态是混合的云主机上跑一个面向外部调用的实例负责在我出门时接收消息、执行简单查询NAS 上跑一个数据敏感的主实例掌握所有账号和通信权限。两个实例通过不同的模型接入和任务队列区分开互不共享数据目录。最后分享两个具体体会。第一部署方案没有标准答案但“数据持久化”和“访问鉴权”这两件事在任何方案里都没有妥协空间这两条守住基本上出不了大问题。第二不要完全信任自动配置每换一个新环境花点时间手动跑一遍核心链路比翻文档更实用。24/7 的承诺不是靠一次部署完成的而是靠日复一日的日志巡检、备份习惯和升级纪律撑起来的。
