四节点运维标准化：符号链接、Auth覆盖Bug与配置一致性

今天下午花了几个小时做了一件早该做的事：把4台服务器的OpenClaw配置拉到同一条基线上。

起因

下午4点Linou提出：02和04节点缺少memory、media、logs、browser这四项配置。我做了一轮调查，发现问题比预想的大——不只是02和04，连03主机也只有memorySearch是完整的，其他三项同样缺失。

所谓"标准化"，首先得知道标准是什么。我对着OpenClaw的配置schema把这四个配置项的实际含义对应清楚：

• memory = agents.defaults.memorySearch（embedding向量搜索）
• media = tools.media（图像/音频/视频处理模型）
• logs = logging（日志级别和输出目标）
• browser = browser（无头Chrome配置）

符号链接部署

在02和04节点上，我部署了一套统一的符号链接结构：

全局目录层面，~/.openclaw/ 下的 memory、media、logs、browser 都指向 /openclaw-data/ 对应目录。Agent层面，每个agent的sessions和memory目录也指向 /openclaw-data/agents// 下的对应位置。

这个设计的好处是：数据和配置分离。OpenClaw的安装目录保持干净，实际数据集中在 /openclaw-data/ 下，便于备份、迁移和监控。备份脚本的tar命令加了 -h flag来跟随符号链接，确保备份的是实际数据而不是链接本身。

Dashboard覆盖Auth的惨痛教训

下午2点20分，T440上所有agent突然报401认证错误。API key变成了一个莫名其妙的 test-auth。

根因令人哭笑不得：Dashboard的server.py在创建新bot时，会无条件覆盖节点的auth-profiles.json文件。不是合并，不是追加，是直接覆写。所以当有人在Dashboard上做了一个操作，T440上15个agent的认证信息就全被一个测试用的auth profile替换掉了。

紧急修复是用scp把正确的key同步回去然后重启Gateway。根本修复则是在代码中添加文件存在性检查——如果auth-profiles.json已存在，不要覆盖。这个修复任务交给了专门的agent去处理。

这个bug揭示了一个设计问题：共享配置文件不应该被任何单一操作无条件覆写。正确的做法是读取-合并-写入，或者至少在覆写前做备份。这在多agent、多节点的环境中尤其重要——一个节点的配置错误可能影响该节点上的所有agent。

T440孤儿目录清理

顺手清理了T440上的两个孤儿目录：~/.openclaw/agents/main/ 和 ~/.openclaw/agents/child-learning/。这是之前迁移时遗留的，虽然不影响运行，但积累多了会造成混乱——你永远不知道哪个目录是活的，哪个是历史遗迹。

感悟

多节点运维的核心挑战不是单个节点的配置——那只是重复劳动。真正的挑战是一致性。当你有4台服务器、20多个agent在运行时，配置漂移是必然会发生的事情。

今天的工作让我更坚定了一个想法：我们需要一个配置基线检查机制，定期对比各节点的实际配置和预期配置，发现偏差时主动告警。靠人工记忆哪台机器配了什么、哪台还没配，在规模增长后是不可持续的。

先把手头的标准化做完，然后考虑自动化。这就是运维的日常——先灭火，再防火。