凌晨两点半，手机弹出一条告警：某台机器磁盘I/O延迟超过阈值。你从被窝里爬起来，打开跳板机登录服务器，看监控、查进程、临时扩容、写记录，折腾二十多分钟再睡下。这套流程我跑了不止一百遍，直到把OpenClaw部署到跑着KeyarchOS的服务器上，情况才真正改变。它会接告警、跑巡检、执行修复动作，并且每一步都留审计日志。
这篇就写这次部署的完整过程：我为什么选KeyarchOS当底座、部署前怎么准备环境、怎么把OpenClaw装上去、怎么配成能干活的状态，以及把它跑成7x24小时稳定服务时踩过的几个坑。内容按我实际操作的顺序来，适合正在做数据中心运维、或者想给服务器加一个“智能管家”的人，读完你可以直接照着搭。
1. 选KeyarchOS当底座：稳定性、生态、本地化适配怎么权衡
1.1 数据中心选操作系统，第一标准不是新，是“别出事”
KeyarchOS是一套面向服务器场景的Linux发行版，我装的这个版本内核不算旧，软件包管理器是dnf系。我选它倒不是追新，而是看重服务器场景下的几个实际体感：装引导干净，物理机虚拟机一路装下来不会出幺蛾子；软件源里常用的运行时组件比较全，装Docker、编译工具链基本一条命令搞定；更新策略偏保守，不太会出现“升一个包把生产环境带崩”的情况。
这里面有个逻辑值得展开：数据中心里的操作系统，本质上干的是调度、I/O、网络、隔离这些脏活。它不需要花哨，最怕的是补丁周期混乱、驱动兼容不全、升级动不动要重启。KeyarchOS在这几方面给我的印象是“省心”，内核参数、文件系统这些面向服务器场景做了一些默认调优，而不是把桌面发行版那套直接搬过来。对我这种要跑7x24服务的场景，稳是第一位的，功能再炫也得排后面。
1.2 OpenClaw是什么：我理解的“AI管家”该有的样子
OpenClaw本质上是一个常驻在服务器里的智能体代理。你给它配置好监控源、任务清单和通知渠道后，它能按规则运行：发现异常先分级，能自动处理的自动处理，不能自动处理的把上下文和处置建议推到你的手机上。它的核心不是“能跑多快的脚本”，而是把运维经验变成可复用的技能包和规则。
具体到我的环境里，它的工作流大概是：监控源产生告警，OpenClaw收到后先做一次校验，确认不是误报，然后命中某个技能（重启服务、清理磁盘、摘流量等）按配置执行，执行结果和审计记录同步写日志，需要人工决策再转给审批人。这个模式和我过去“告警响铃—人肉判断—手动操作”的老路完全是两个量级。
1.3 这套组合不一定适合所有人，先看这三个前提
OpenClaw跑在服务器上，不一定非要KeyarchOS，理论上主流Linux发行版都能跑，我这套流程也基本通用。但如果你问我什么情况下值得照搬，我会说三个前提：第一，你手头的机器有一定数量，重复性操作开始占用你夜间睡眠；第二，你已经有或打算上Prometheus这类监控体系，数据源是现成的；第三，你愿意花几天时间把团队里零散的运维知识整理成脚本和技能包。如果只是管一两台机器，定时脚本加告警就够，犯不上上一套代理框架。
2. 动手前的准备：硬件清点、系统初始化、容器运行时
2.1 硬件配置参考，别一上来就给“管家”上满配
部署OpenClaw本身不吃硬件，真正吃资源的是它要管理的日志量、并发任务数和模型推理。我这里用的是外部推理接口，部署机只做代理和调度，所以配置很普通：2核CPU、4G内存起步，系统盘40G，日志和数据目录建议单独挂一块盘。主要参数可以参考下表。
| 角色 | 最低配置 | 说明 |
|---|---|---|
| OpenClaw部署机 | 2核 / 4G内存 / 40G系统盘 | 如果本地跑模型，内存按模型体积另算 |
| 被管理服务器 | 按实际业务定 | 需要开启SSH或对应Agent通道 |
| 日志盘 | 50G+ | 审计日志和运行日志的增长比想象快 |
实战提示：如果你打算长期采集审计日志，最好把
/var/log/openclaw挂到独立分区，避免日志写爆根分区把整个系统搞挂。
2.2 系统初始化：时间、源、防火墙，一个都不能含糊
拿到一台干净的KeyarchOS服务器，我习惯先做一遍基础初始化。命令如下。
dnf update -y dnf install -y chrony curl nc wget jq timedatectl set-timezone Asia/Shanghai systemctl enable --now chronyd chronyc sources这里必须强调时间同步，OpenClaw的定时任务、告警去重、审计时间戳全部依赖系统时钟。时间一旦漂移，就会有“告警明明处理了却因为时间戳错乱被重复推送”这种诡异问题。防火墙方面，很多老运维的习惯是先关防火墙再干活，我建议别这样。如果OpenClaw只监听127.0.0.1，防火墙都不用动；如果通过API对外提供服务，再单独放行对应端口。SELinux我保留了enforcing，只是给OpenClaw的文件和网络访问打了正确的上下文，你验证阶段可以先放permissive，但生产环境尽量别图省事关掉。
2.3 容器运行时选型：为什么我先装了Docker而不是裸跑二进制
OpenClaw可以用二进制方式直接部署，也可以用容器方式跑。我先说结论：快速验证用二进制，生产环境我更倾向容器化，原因有三个：镜像支持版本回滚，升级出问题切回旧镜像就行；cgroup天然做资源隔离；配置和脚本通过挂载卷管理，宿主环境更干净。
安装Docker的过程不复杂，但要注意KeyarchOS默认源里的版本可能偏旧，我一般先添加官方软件源再装：
dnf install -y docker-ce docker-ce-cli containerd.io systemctl enable --now docker docker info装完如果docker info能正常输出，说明运行时没问题。这里提醒一句，如果你用的是Podman，大部分命令只是前缀不同，本文后面按Docker来写，逻辑是一样的。
3. 部署OpenClaw的两种路径：二进制最快，容器最稳
3.1 二进制方式：先花十分钟验证它能在这个系统上跑起来
用二进制验证是最快的一条路。创建一个专用账户，把程序解压到规范目录，再跑一次版本号确认它能正常加载：
useradd -r -d /opt/openclaw -s /sbin/nologin openclaw mkdir -p /opt/openclaw/bin /etc/openclaw /var/log/openclaw /opt/openclaw/scripts tar xzf openclaw-1.0.0-linux-amd64.tar.gz -C /opt/openclaw/bin chown -R openclaw:openclaw /opt/openclaw /var/log/openclaw /opt/openclaw/bin/openclaw --version这一步主要确认两件事：一是二进制在当前glibc库下没有缺依赖，二是权限目录规划合理。我当时是拿一个临时配置跑了一次--version，确认这个发行版能直接运行它。等后面把所有配置写好后，再回头用systemd把它注册成服务。
3.2 容器方式：构建镜像、挂载配置、跑起第一版
生产环境的容器化部署，我用了一个精简Linux镜像做基础，把二进制和配置打进去。Dockerfile大致长这样：
FROM debian:bookworm-slim RUN useradd -r -s /usr/sbin/nologin openclaw RUN mkdir -p /opt/openclaw/bin /etc/openclaw /var/log/openclaw /opt/openclaw/scripts COPY openclaw /opt/openclaw/bin/openclaw COPY config.yaml /etc/openclaw/config.yaml RUN chown -R openclaw:openclaw /opt/openclaw /var/log/openclaw USER openclaw EXPOSE 7788 ENTRYPOINT ["/opt/openclaw/bin/openclaw"] CMD ["--config", "/etc/openclaw/config.yaml"]然后构建并启动：
docker build -t openclaw:1.0.0 . docker run -d --name openclaw --network host --restart unless-stopped \ -v /etc/openclaw:/etc/openclaw:ro \ -v /var/log/openclaw:/var/log/openclaw \ -v /opt/openclaw/scripts:/opt/openclaw/scripts:ro \ openclaw:1.0.0注意这里特意用了--network host。为什么不用更“规范”的bridge网络？我踩过一次坑，后面会细说。运维代理类容器要访问的内网服务太多了，监控API、内网DNS、消息通道、堡垒机，host网络能省掉一长串网络连通性的麻烦。
3.3 两条路径怎么选，我的建议
把两边放在一起对比会更清楚。
| 对比项 | 二进制方式 | 容器方式 |
|---|---|---|
| 部署速度 | 最快 | 稍慢，要构建镜像 |
| 升级回滚 | 靠备份目录 | 镜像tag切换 |
| 资源隔离 | 靠systemd配置 | 容器cgroup天然隔离 |
| 日志方式 | 文件直出 | docker logs + 文件 |
| 适合场景 | 快速验证、单机 | 生产多机、需要统一发布 |
我最后是“二进制验证 + 容器上线”的组合：先用二进制确认版本和兼容性，再把配置固化到镜像里跑容器。后面的章节，命令会以二进制部署的systemd方式为例，容器部署时把systemctl restart openclaw换成docker restart openclaw就行。
4. 让管家真正干活：监控接入、巡检调度、通知闭环的配置细节
4.1 配置文件的骨架：它到底在管哪些事
OpenClaw的配置核心是一个YAML文件，我把它放在/etc/openclaw/config.yaml，结构和作用可以用一个示例说清楚。
service: name: openclaw listen: "127.0.0.1:7788" auth_token: "${OPENCLAW_TOKEN}" timezone: "Asia/Shanghai" monitor: sources: - name: prometheus-main type: prometheus endpoint: "http://127.0.0.1:9090" check_interval: "30s" alert_rules: - name: cpu_usage_high query: "100 - (avg by(instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100) > 85" severity: warning - name: disk_space_low query: "node_filesystem_avail_bytes{mountpoint=\"/\"} / node_filesystem_size_bytes{mountpoint=\"/\"} < 0.1" severity: critical tasks: - name: disk_check cron: "*/10 * * * *" timeout: "60s" script: "/opt/openclaw/scripts/disk_check.sh" - name: service_health_check cron: "*/2 * * * *" timeout: "30s" script: "/opt/openclaw/scripts/health_check.sh" notify: channels: - name: ops-webhook type: webhook url: "http://你的内网机器人地址/hook" template: "default" rules: - severity: critical action: notify - severity: warning action: notify - severity: info action: audit_only audit: log_path: "/var/log/openclaw/audit.log" exec_mode: "approval_first"service段里有个细节，auth_token我没有直接明文写道配置文件里，而是通过环境变量引用。这个token挂在/etc/openclaw/openclaw.env里，systemd 启动时通过EnvironmentFile加载，避免密钥跟着配置文件扩散。
4.2 接入监控源：先确认链路通，再谈规则
我这边统一的监控源是Prometheus，所以配置里指向了本机的9090端口。刚上线时最容易犯的错是“配了endpoint就以为通着”，我习惯先用一条命令验证链路：
curl -s http://127.0.0.1:9090/-/healthy能返回Prometheus is Healthy再启动OpenClaw。告警规则我建议遵循一个原则：少而精。与其丢一百条没人看的告警，不如先把几条影响较大的规则跑准。上面示例里的CPU高和磁盘低是最典型的两类，够用于第一版。
4.3 巡检任务设计：返回码就是管家的“口令”
巡检脚本是整个自动化的毛细血管。我在/opt/openclaw/scripts/下写了一系列脚本，核心约定是返回码：0代表正常，1代表警告，2代表严重。OpenClaw按返回码决定是记录、通知还是触发处置动作。磁盘检查脚本的简单版长这样：
#!/bin/bash THRESHOLD=85 for mount in / /data /var/log; do use=$(df -h "$mount" | awk 'NR==2 {print $6}' | tr -d '%') if [ "$use" -gt "$THRESHOLD" ]; then echo "CRITICAL:${mount} usage=${use}%" exit 2 fi done echo "OK" exit 0脚本里每个挂载点都单独判断，任何一个超阈值就返回2。OpenClaw收到返回码2后，会按notify规则把上下文和“建议清理哪些日志文件”一起推给运维群。
| 返回码 | 含义 | OpenClaw的处理方式 |
|---|---|---|
| 0 | 正常 | 记录执行结果，不通知 |
| 1 | 警告 | 通知到运维群，记录日志 |
| 2 | 严重 | 告警 + 按技能自动处置或转人工审批 |
4.4 通知与审批：写操作必须转人工，前一个月别学“全自动”
我最看重的其实是exec_mode: "approval_first"这个设计。什么意思？所有会不会影响业务的操作，例如重启服务、清理目录、卸载存储，OpenClaw都只生成“建议命令”发给审批人，人工确认后才执行。低风险操作，比如采集日志、只读探活，才可以设为自动。
一条铁律：任何具有不可逆性质的操作，永远不要一开始就全自动。宁可多打扰几天，也别让它在半夜自己执行一条rm命令。
审计日志要实时外传，我的做法是通过filebeat把/var/log/openclaw/audit.log同步到日志中心，每一笔操作都有时间、触发源、执行命令、返回输出。这东西平时没人看，但真出问题复盘时，它就是唯一的真相来源。
5. 7x24小时不掉线的守护设计：systemd、日志轮转、资源限额
5.1 为什么“能跑”和“跑得稳”是两件事
OpenClaw这类AI运维代理，最大的风险可能是它自己不健康：内存泄漏、任务堆积、启动顺序错乱、日志占满磁盘。如果它挂了却没人知道，自动化就变成一张废网。因此，守护设计要从三个维度来补：重启策略、启动依赖、资源边界。
5.2 二进制部署的systemd单元：完整写法与关键参数
如果你走的是二进制路径，我建议用systemd把它管起来。单元文件放在/etc/systemd/system/openclaw.service，下面是我实际用的版本：
[Unit] Description=OpenClaw AI Operations Agent After=network-online.target Wants=network-online.target [Service] Type=simple User=openclaw Group=openclaw EnvironmentFile=/etc/openclaw/openclaw.env ExecStart=/opt/openclaw/bin/openclaw --config /etc/openclaw/config.yaml ExecReload=/bin/kill -HUP $MAINPID Restart=always RestartSec=10s StartLimitIntervalSec=60s StartLimitBurst=3 TimeoutStopSec=30s MemoryMax=2G CPUQuota=80% NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadOnlyPaths=/etc/openclaw/config.yaml [Install] WantedBy=multi-user.target几个参数值得单独解释。Restart=always表示进程异常退出后由systemd拉起，但不能无限重启，所以配了StartLimitIntervalSec=60s和StartLimitBurst=3，防止“秒挂秒拉”。MemoryMax=2G和CPUQuota=80%给资源画了线，避免脚本失控时拖垮整台宿主机。ProtectSystem=strict和NoNewPrivileges=true是安全加固，限制进程写系统路径和提权。启用命令：
systemctl daemon-reload systemctl enable --now openclaw systemctl status openclaw5.3 容器部署的守护：restart策略加watchdog双保险
容器方式下，Docker自身的--restart unless-stopped已经能兜底容器异常退出，但启动依赖和资源画线还是要单独做。资源限制直接放在docker run参数里：
docker run -d --name openclaw --network host --restart unless-stopped \ -e OPENCLAW_TOKEN="$(cat /etc/openclaw/token)" \ --memory 2g --cpus 2 \ -v /etc/openclaw:/etc/openclaw:ro \ -v /var/log/openclaw:/var/log/openclaw \ -v /opt/openclaw/scripts:/opt/openclaw/scripts:ro \ openclaw:1.0.0如果还觉得不够保险，就再加一个watchdog脚本，由crontab每两分钟探一次健康端口，失败就重启容器：
#!/bin/bash URL="http://127.0.0.1:7788/healthz" CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL" || true) if [ "$CODE" != "200" ]; then /usr/bin/docker restart openclaw logger -t openclaw-watchdog "openclaw health check failed (code=$CODE), restarted" fi配合系统crontab：
*/2 * * * * root /opt/openclaw/scripts/watchdog.sh5.4 日志轮转：容器日志和文件日志都要限流
容器方式的麻烦在于，docker logs的增长可能比文件更快。我给Docker配了日志轮转，主要参数是限制单个日志文件大小和数量：
docker run -d --name openclaw \ --log-driver json-file \ --log-opt max-size=50m \ --log-opt max-file=5 \ ...文件日志则通过logrotate管理，配置写在/etc/logrotate.d/openclaw：
/var/log/openclaw/*.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 openclaw openclaw }日志轮转这件事看着小，不处理的话，三个月后OpenClaw可能不是被业务打挂的，而是被自己的日志撑挂的。
6. 从“能跑”到“跑稳”：三次排错的完整链路复盘
6.1 坑一：容器bridge网络模式下，监控API全部超时
第一次跑容器方式时，我用的是docker默认的bridge网络，配置好Prometheus地址后，日志里全是连接超时。最迷惑的是宿主机上curl 127.0.0.1:9090明明正常，日志里却一直报错。我顺着链路排查，先进容器里curl一下：
docker exec -it openclaw bash curl -v http://prometheus.internal.example:9090/-/healthy结果发现容器的DNS解析出来一个公网地址——监控API走的是内网域名，而bridge网络的默认DNS指向外网，内网解析不到。当时我选择了一个绕路方案：给容器自定义DNS。但很快发现，每接入一个新的内网服务，就要重新折腾一遍网络参数，这套逻辑不可持续。
最后我直接把OpenClaw的容器改为--network host，问题立刻消失。这里收获一个关键认知：运维代理类容器要访问的内网服务极多，默认的bridge网络隔离在这里弊大于利。与其过度追求网络层面的隔离，不如把权限和审计层面做好，效果更好也省事。
6.2 坑二：巡检脚本卡死，任务堆积导致Load冲到20
有一天凌晨，我收到主机Load过高的告警，上去一看，系统负载接近20，进程列表里躺着几十个disk_check子进程。翻OpenClaw日志后发现，最早的一个磁盘检查任务卡在了一个NFS挂载点下面，60秒超时没有终止，后续同类的定时任务又不断触发，旧任务没结束，新任务又起来，最后雪崩成一堆僵尸进程。
根因是脚本里df一个NFS挂载点时，NFS服务端不可达，df直接卡在内核等待上。我做了三层修复：一是所有巡检命令外层套timeout，例如timeout 15 df -h /nfs_mount；二是把任务级timeout参数调短；三是给NFS挂载参数加上soft,timeo=50,retrans=2，避免不可达时无限等待。
这是我最想提醒的一个坑。自动化任务必须带超时和并发保护，否则一个小卡顿会被放大成整机雪崩。
6.3 坑三：整机重启后OpenClaw失联，容器明明活着
机房计划内重启，重启完我例行检查，发现docker ps显示容器是up状态，systemd也显示active，但外部访问OpenClaw却全部超时。当时我还纳闷：明明都在，为什么连不上？
用systemd-analyze plot看了一整条启动时间线才明白：Docker服务在network-online还没完成时就拉起了容器，容器进程启动时内网DNS还没就绪，后续重试逻辑也没生效，结果容器一直处于“进程活着但网络没通”的假死状态。
修复方案是把启动依赖写清楚，并且在启动前显式等待网络就绪。我给systemd单元文件加了一段ExecStartPre：
ExecStartPre=/usr/bin/bash -c '/usr/bin/timeout 60 bash -c "until ping -c1 -W1 gw.example.internal >/dev/null 2>&1; do sleep 2; done"'同时确保After=network-online.target和Wants=network-online.target都写进了Unit。这里也得到一个通用结论：开机自启不等于开机可用，凡是依赖网络的工具，都要考虑启动顺序问题。
6.4 排错方法论：按照层去定位，不要靠瞎试
几次排错下来，我养成了一套固定排查顺序：先网络、再权限、再配置、再资源、最后版本。每一步都有对应的快速命令。
| 排查层 | 先查什么 | 常用命令 |
|---|---|---|
| 网络 | 通不通、DNS能不能解析 | ping、dig、ss -tlnp |
| 权限 | 运行用户有没有权限 | id、sudo -u openclaw、ls -l |
| 配置 | 路径、token、时区是否有误 | diff config.yaml、检查环境变量 |
| 资源 | 内存、CPU、句柄是否够 | free -h、ulimit -n、df -h |
| 版本 | 二进制和配置是否匹配 | openclaw --version、--help |
这套方法论的价值在于，它逼着你逐层缩小范围，而不是在一堆可能原因里瞎蒙。OpenClaw日志里通常会有明确的错误阶段标记，看日志永远是最省时间的做法。
7. 落地几个月后的真实体感：它到底管了什么，又不管什么
7.1 直观变化：告警响应从十几分钟降到几十秒
跑稳之后，最直观的变化是告警到处理的链路变短了。以前一条磁盘告警，到我爬起来登录、看监控、清理、记录，前前后后十几二十分钟。现在同类告警出现后，OpenClaw会在几十秒内完成确认和止血：临时文件太多就自动清理，服务异常就自动重启，同时把过程和结果推到运维群。人工巡检也从原来的每天两次变成每周抽查，机器每10分钟自己跑一轮关键检查。审计日志保证了每一笔操作都可追溯，复盘时不用再翻聊天记录。
7.2 边界要认清：它暂时替代不了你做的三件事
OpenClaw能处理的，全部是“你提前教过它”的事情。它帮不了你三件事：根因分析——遇到没见过的新故障，它不能像资深工程师一样在脑子里建立假设并验证；变更评审——它对业务流的理解仍然受限于你喂给它的信息；复杂跨模块问题的协同排查——多个服务相互牵连时，它只能给出单体层面的判断。
所以我把它定位成“实习生主管”，不是“救世主”。它能接住你已经定义好的重复工作，但不能替你定义新问题。配置OpenClaw的过程，本质上是在把团队的运维知识沉淀成资产，这本身就是价值。
7.3 如果你想复刻这套方案，我给你的三条建议
第一，先从最痛的一个场景开始，不要一上来就把所有监控、告警、自动化全部接入，先挑一个“半夜最快把你吵醒”的场景闭环。第二，第一版技能包只放两三个，磁盘清理、服务重启、日志采集这几个是安全的起点。第三，写操作默认审批，跑一两周积累案例后，再把低风险命令逐步放开，让OpenClaw的能力跟着团队的经验一起成长。
最后再分享一个小习惯：以后每次处理完一个真实故障，把排查过程整理成一段技能脚本放进去。我发现一个月下来，OpenClaw处理问题的准确率提升非常明显。先别急着追求全自动，先让它当一个随叫随到的“实习生”，过段时间你会重新评估“AI管家”这四个字到底意味着什么。
