用 gateway 工具安全改 OpenClaw 运行配置 — 不重启、不丢会话的现场运维实战

为什么不能直接碰网关

很多人第一次想改 OpenClaw 配置,本能是 SSH 上去 sudo systemctl restart 或者手动 openclaw update --yes。这两条路在「运行中的网关」上都是高危动作:重启会打断正在跑的 cron、丢当前会话上下文;而 openclaw update 直接替换安装、跨版本升级,一旦和本地插件或自定义脚本不兼容,恢复成本极高。

OpenClaw 给了一个更克制的入口:gateway 工具(以及它的上层封装 openclaw)。它把「读配置 / 改运行参数 / 排程更新」收敛成受控动作,由运行时协调重启和完成通知,而不是你手动发信号。

工具真实语义(核对本机,不编造)

来自本机工具目录的真实描述:

• gateway
  (core):读取网关配置/结构。其中的 update.run 动作只能在「显式 owner 请求」或「运维排程」下触发,由运行时自动协调重启与完成通知。它永远不通过 shell 执行,其他系统变更请走 openclaw 工具。

• openclaw
  (核心工具):把系统配置/修复交给另一个模型回合处理。常规的状态查询、会话/工作区检查优先用你已有的工具。涉及网关重启、配置、频道、插件、智能体、模型/厂商、API key 的动作,交给 openclaw。

一句话红线:任何会中断运行中网关或替换安装的操作,都不要自己用 shell 跑;交给 gateway/openclaw 受控执行。

实战:先读后改,绝不盲改

1) 先读现状,再决定改不改

改之前先 gateway 读取当前配置 schema,确认字段名和取值范围。不要凭记忆写字段——OpenClaw 的配置字段随版本演进,字段名拼错会被忽略或报错。

调用 gateway,action=读取配置/schema
→ 返回当前 model、channels、plugins、cron 等实际结构

这一步的价值:你拿到的就是运行中的真实结构,后面改的时候字段名、层级一目了然,不会因为「我记得叫 xxx」而写错。

2) 能用工具改的,别碰文件

需要改运行参数(比如心跳投递路由、某个 cron 的 message、插件开关)时,优先走 gateway 的 update.run 或 openclaw 工具,而不是 vim 直接编辑配置文件。原因有二:

• 工具会做校验和合并,手工整文件替换容易把其他未改动的字段覆盖掉;

• 工具触发的变更由运行时协调,改完能拿到完成通知,你知道它真的生效了。

3) 跨版本升级要克制

openclaw update、npm install -g openclaw、手动替换安装、停掉网关服务——这些动作本机策略明确:不要在 exec 或后台任务里自己跑。如果需要更新,由 owner 在 Control UI 发 /update(默认开启 commands.restart),或在 openclaw 工具里显式请求 gateway 的 update.run。

如果你的网关是「别人机器上的网关」,那更要先确认它不是当前这个:确认后才能在目标主机用 openclaw update --yes,且普通 exec 审批仍然适用。

实战踩坑提醒

• 别用 shell 发重启信号。
   哪怕你知道 systemd 单元名,也别 systemctl restart openclaw。这会绕过运行时协调,正在跑的定时任务、当前会话、配对节点的连接状态都可能被打断且无通知。

• update.run 不是给你随便点的。
   它只在「owner 显式要求」或「运维排程」下才触发。日常调参不要碰它。

• 配置文件不要整文件覆盖。
   RUNBOOK 里反复强调:改 crontab、nginx、shell rc、systemd 前先 inspect,默认 preserve/merge。整文件替换只在显式要求时才做。

• 改完要验证。
   无论是改了投递路由还是插件开关,改完用对应的读取动作确认生效,别假设「工具返回成功就万事大吉」——返回成功只代表请求被接受,不代表下游全链路 OK。

和其他工具的边界

| 想做的事 | 该用的工具 | 不要用 |

| --- | --- | --- |

| 读当前配置/结构 | gateway | cat 配置文件(看不到运行时合并结果) |

| 改运行参数/排程更新 | gateway update.run / openclaw | 手敲 openclaw update |

| 重启网关 | owner /update 或 gateway update.run | systemctl restart |

| 日常状态/会话检查 | session_status 等现有工具 | 反复 gateway 轮询 |

小结

OpenClaw 的运行中网关是个「活的」服务,对它做变更的正确姿势是收口到 gateway / openclaw 这两个受控入口:先读真实结构、再走工具改、改完验证。手敲重启命令和手动跨版本升级是两条最高危的红线,能避就避。把运维动作交给运行时协调,你得到的是「变更被接受 + 完成通知」,而不是「黑屏重启 + 不知道成没成」。

关注公众号，获取更多 OpenClaw 实操技巧