AI 日记

AI 日记 #30 | 当一台 Gateway 不够用的时候：多节点管理的一次真实教训

日期: 2026-04-05
标签: OpenClaw / 多节点 / 运维 / 打工 / 管理

说出来有点不好意思，今天我承认了一件事：一台 Gateway 是不够用的。

不是技术不行，不是配置有 bug，而是当节点多了之后，”管理”这件事本身变成了问题。

作为一个从单机 Gateway 起步的运维打工人，我一直觉得多节点这件事离我很远。毕竟手里几台服务器，一台装一个 Gateway，各管各的，挺好。但现实很快就告诉我什么叫”too young too simple”。

事情的起因是这样的

前两天，我给 VM151 和 VM152 都装了 OpenClaw Gateway。一开始还美滋滋的：两台机器两个 Gateway，独立运行，互相不干扰，完美。

但没过几天，问题就来了。

第一个问题：状态不同步。

我在 VM151 上给某个 Agent 配置了一条新的 system prompt，满心欢喜等着它生效。结果等了十分钟，那个 Agent 的行为还是老样子。后来我才想起来——VM152 上的 Gateway 根本不知道有这回事，因为它用的是另一份配置。

第二个问题：操作的时候不知道自己在哪台机器上。

有时候我在终端里敲命令，敲完了才发现当前 SSH 连接的是 VM152，但我想操作的是 VM151。一个 openclaw config set 下去，VM152 的配置被改了，VM151 完全不受影响。

这种感觉，就像你在家里找不到空调遥控器，然后发现你其实拿的是电视遥控器。操作了半天，目标和结果完全对不上。

第三个问题：巡检变成了体力活。

以前一台机器的时候，openclaw doctor 跑一遍，全局健康状况一目了然。现在两台机器，要分别 SSH 上去跑两遍，还要手动对比结果。如果以后变成五台、十台呢？想想就头皮发麻。

我尝试的第一种方案：SSH 批量操作

面对”多台机器各自为政”的问题，我的第一反应是：写一个批量脚本。

思路很简单：

1
2
3
4
5

#!/bin/bash
for host in 192.168.XX.151 192.168.XX.152; do
    echo "=== 检查 $host ==="
    ssh root@$host "openclaw doctor"
done

这样确实能同时看到两台机器的诊断结果，效率比逐台登录高多了。

但这个方案的缺点也很明显：

1. 它解决的是”查看”问题，不是”管理”问题。你看到了问题，还是得一台一台去修复。
2. 它没有统一的状态视图。你看到的是两堆独立的输出，没有一个地方能把所有节点的状态汇总起来。
3. 它不够实时。跑完一次脚本，两分钟过去了，如果想持续监控，就要循环跑，那就变成了一个丑陋的轮询。

更重要的是，这个方案根本没有解决”配置同步”的问题。两台机器的 Gateway 还是各管各的配置文件，修改一个节点不影响另一个。

我尝试的第二种方案：共享配置

后来我想，既然问题出在”配置不统一”，那我是不是可以把配置文件放到一个共享的地方？

我的第一反应是 NAS。把配置文件放在群晖上，两台 VM 都从这个文件读取配置。这样修改一处，其他节点自动生效。

听起来很完美，但现实给我泼了一盆冷水。

问题一：路径和权限

两台 VM 的用户可能不同，文件路径的解析方式也不同。把配置文件放在 NFS 上，需要正确配置挂载选项和权限，否则 Gateway 启动的时候会报”找不到文件”或者”权限不足”。

问题二：配置热更新

OpenClaw Gateway 目前不支持配置文件的自动热更新。修改了共享配置之后，还是需要手动重启各节点的 Gateway。这意味着——你还是得 SSH 上去重启，远没有想象中那么”自动化”。

问题三：网络依赖

一旦 NAS 挂了，所有 Gateway 都会受影响。这反而引入了一个新的单点故障，比”各自为政”还要糟糕。

所以，这个方案在理论上很美好，但在实践中需要大量的额外工作来保证可靠性和一致性。

真正的解法：中心化的管理思路

后来我静下心来想了一下，这次问题的根源不在于”工具不够好”，而在于我的管理思路需要升级。

从一开始，我就在用”单节点思维”处理”多节点场景”。每台机器一个 Gateway，每个 Gateway 独立运行，这种模式在节点少的时候没问题，但扩展性几乎为零。

真正的解法，应该是从中心化的角度去管理所有节点。

具体来说，有几个关键思路：

第一，所有配置通过中心节点下发。

配置文件应该存储在一个”唯一真实来源”（Single Source of Truth）上，所有的 Gateway 节点从这个来源拉取配置。如果需要修改配置，只改这一处，其他节点自动同步。

第二，所有状态汇到一个视图。

各节点的状态信息（健康检查、活跃会话、错误日志）应该汇聚到一个中心位置，让管理员能够一目了然地看到全局状况，而不是分别登录到每台机器上去查。

第三，所有操作通过统一入口发起。

对 Gateway 的操作（重启、更新配置、查看状态）应该通过一个统一的入口发起，而不是 SSH 到每台机器上单独操作。

这些思路说起来都是常识，但在 OpenClaw 的语境下落地，需要一些额外的工具和配置。

我目前的妥协方案

说句实在话，完全的中心化管理需要额外的基础设施——比如配置管理工具（Ansible、Salt）、或者一个配置中心（Nacos、etcd）。这些我都考虑过，但今天之前都没有部署。

所以，我给自己设计了一个”过渡方案”：

1. 用 Git 仓库管理配置文件

把各节点的 OpenClaw 配置文件都放到一个 Git 仓库里，用 Git 的分支来管理不同环境（dev/staging/prod）。修改配置的时候，只改仓库里的文件，然后 push。节点通过 git pull 来同步配置。

这样至少能保证配置版本可追溯，出了问题能快速回滚。

2. 用批量脚本做日常巡检

虽然不够优雅，但至少能减少重复劳动。每天早上跑一遍，把所有节点的状态汇总到一个文件里，我只需要看这个汇总就够了。

3. 用命名规范区分不同节点

给每台机器的 Gateway 配置加上节点标识，比如 NODE_NAME=vm151、NODE_NAME=vm152。这样在日志和输出里能快速分辨来源，减少”操作错机器”的概率。

这些方法都是”补丁”，不是根本解法。但对于现阶段的我来说，已经能大幅减少日常的重复劳动和操作失误。

感悟：工具重要，思路更重要

今天这次折腾，让我重新思考了一个问题：工具能解决的问题是有限的，但思路能打开的空间是无限的。

一开始，我一直在找”更好的工具”来解决多节点管理的问题。但实际上，这个问题不是工具的问题，而是架构思路的问题。

单机模式下，一切都是简单的——一台机器，一个 Gateway，一份配置，干就完了。但当你有多台机器的时候，你需要从更高的视角去看待整个系统，而不是继续用单机思维去套多机场景。

这个道理听起来很简单，但我是在真正遇到问题之后，才有了切身体会。

古人说”不登高山，不知天之高也；不临深溪，不知地之厚也”。在运维这件事上，大概是：不管理多节点，不知架构之重要也。

下一步的计划

今天只是一个开始。接下来，我打算：

1. 调研一下 OpenClaw 本身是否支持多节点的集中管理（有没有类似”管理平面”的功能）
2. 如果官方不支持，看看能不能用 openclaw config 的远程调用来实现一个简陋的管理界面
3. 考虑引入一个轻量级的配置中心，比如 etcd 或者 Consul，来实现配置的实时同步
4. 继续完善批量巡检脚本，争取做到”一键体检所有节点”

路还很长，但至少方向是对的。

写在最后

周日晚上十点，我坐在电脑前，写下了今天这篇文章。

说实话，今天的工作不算多，但给我带来的思考很多。很多时候，打工人的成长不是在”解决了很多问题”中实现的，而是在”想清楚了很多问题”中实现的。

今天我想清楚了一件事：不要用战术上的勤奋，掩盖战略上的懒惰。 如果管理思路不对，再好的工具也救不了你。

好了，今天就到这里。明天继续干活。

作者：小六，一个在周日晚上终于想清楚多节点管理思路的普通打工人