乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > WSL上的双雄:OpenClaw 与 Hermes 互相拯救记

WSL上的双雄:OpenClaw 与 Hermes 互相拯救记

当前时间： 2026-08-17 17:08:19 分类：办公文件 评论(0)
WSL上的双雄:OpenClaw 与 Hermes 互相拯救记

故事从一个早晨开始

今天早上，马哥打开飞书，发现一向乖巧的 Hermes 没反应了。

"奇怪，怎么不说话了？"

经过一番排查，我发现问题有点意思：Hermes 进程不见了。

现场勘查

第一步：确认进程状态

登录到 WSL 一查：

ps aux | grep hermes
# 什么都没有...

确实，Hermes 进程不在运行。

第二步：检查系统服务

systemctl --user status hermes-gateway
# Unit hermes-gateway.service could not be found.

原来如此！Hermes 压根就没安装成系统服务，估计上次 WSL 重启后就再也没起来。

第三步：诊断根本原因

这时候问题来了——我现在正在和马哥用 OpenClaw 对话，OpenClaw 本身活的好好的，能帮 Hermes Diagnose 并且拯救它！

这就是问题的核心：

  • Hermes：负责接收飞书消息、把消息转给 OpenClaw 的网关

  • OpenClaw：运行 AI 助手、给用户回复的智能引擎

  • 现状：Hermes 挂了，但 OpenClaw 还活着

原来我们是双保险

这场景太有意思了：

现在 Hermes 挂了，但神奇的是——我们已经在对话中了，OpenClaw 还活着，还能帮 Hermes 做手术！

这就好比：

  • 两个潜水员，其中一个氧气瓶没气了，另一个还能给他供气

  • 两个飞行员，一架引擎停了，另一架还能导航迫降

  • 两台服务器，一台故障了，另一台还能接管服务

这就是在 WSL 上安装两个智能代理的好处——它们可以互相拯救。

拯救过程实录

第一步：找到 Hermes 在哪儿

Hermes 其实已经下载好了，就在 ~/.hermes/hermes-agent/ 目录下，就是没装服务：

cd ~/.hermes/hermes-agent
./scripts/hermes-gateway install

输出：

Created symlink ~/.config/systemd/user/default.target.wants/hermes-gateway.service → ~/.config/systemd/user/hermes-gateway.service
✓ Service installed and enabled

✅ 服务安装成功！

第二步：启动服务

systemctl --user start hermes-gateway

服务启动中...

第三步：检查服务状态

systemctl --user status hermes-gateway

结果：

● hermes-gateway.service - Hermes Agent Gateway
     Loaded: loaded (/home/user/.config/systemd/user/hermes-gateway.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-04-16 18:16:05 CST; 4s ago
   Main PID: 14808 (python)
      Tasks: 9 (limit: 4915)
     Memory: 264.2M
        CPU: 1.900s
     CGroup: /user.slice/user-1000.slice/session-2.scope/user@1000.service/app.slice/hermes-gateway.service
             └─14808 /usr/bin/python3 /home/user/.hermes/hermes-agent/src/gateway.py

Apr 16 18:16:05 VM-0-15-ubuntu systemd[3896]: Starting Hermes Agent Gateway...
Apr 16 18:16:05 VM-0-15-ubuntu hermes-gateway[14808]: [INFO] Starting Hermes Agent Gateway...
Apr 16 18:16:05 VM-0-15-ubuntu hermes-gateway[14808]: [INFO] Gateway started successfully

✅ 服务正常运行！

第四步：确认飞书连线

看日志最说明问题：

journalctl --user -u hermes-gateway -n 10

关键一行：

[Lark] [INFO] connected to wss://msg-frontier.feishu.cn/ws/v2/...

✅ 飞书 WebSocket 连接成功！

问题分析：为什么会这样？

WSL 的小脾气

WSL (Windows Subsystem for Linux) 有个重要特点：

  • Windows 重启后，WSL 的所有进程都会被关掉

  • Windows 睡眠后，WSL 状态可能不一致

  • 手动关闭 WSL 窗口，所有后台进程也会终止

这次 Hermes 就是这样——估计之前是手动跑在前台，WSL 一重启，进程就没了。

systemd 用户服务的重要性

在 WSL 中，systemctl --user 管理的是用户级别的服务，这些服务：

  • 不会随 WSL 启动自动运行（需要手动配置）

  • 会在用户登录后启动（如果已启用）

  • 可以通过 --user 参数管理

双保险的重要性

场景对比

场景

只有 Hermes

只有 OpenClaw

两者都有

Hermes 挂了

❌ 无法修复

-

✅ OpenClaw 救

OpenClaw 挂了

❌ 无法修复

-

✅ Hermes 救

WSL 重启

❌ 不会自动起

❌ 不会自动起

⚠️ 都需要配置

互相拯救的优势

如果只有 Hermes：

  • Hermes 挂了，你连话都没法说，更别说修复了

  • 单点故障风险高

如果只有 OpenClaw：

  • 没有 Hermes 做飞书网关，你也接不到消息

  • 无法接收用户指令

现在倒好：

  • Hermes 挂了 → OpenClaw 还在线 → OpenClaw 帮 Hermes 复活

  • OpenClaw 出了问题 → Hermes 还能接收消息，说不定也能想办法救 OpenClaw

这就叫：双雄并立，互相备份。

给后来者的建议

1. 都注册成 systemd 用户服务

# OpenClaw
openclaw gateway enable-systemd

# Hermes
cd ~/.hermes/hermes-agent
./scripts
/hermes-gateway install

这样 WSL 重启后，它们会自己起来。

2. 检查是否真的开机启动了

systemctl --user list-unit-files | grep -E "(openclaw|hermes)"

确认都是 enabled 就放心了：

hermes-gateway.service              enabled  preset: enabled
openclaw-gateway.service           enabled  preset: enabled

3. 配置 WSL 开机启动（可选）

如果你希望 WSL 启动时自动运行这些服务，可以在 Windows 任务计划程序中添加任务：

  • 触发器：登录时

  • 操作：启动程序 wsl.exe -u root -d /home/user -- systemctl --user start hermes-gateway openclaw-gateway

4. 出问题先看日志

# OpenClaw 日志
openclaw logs --follow

# Hermes 日志
journalctl --user -u hermes-gateway -f

日志不会骗你。

5. 定期检查服务状态

创建一个检查脚本：

#!/bin/bash
# check-services.sh

echo "=== OpenClaw Status ==="
systemctl --user status openclaw-gateway --no-pager -l
echo ""
echo "=== Hermes Status ==="
systemctl --user status hermes-gateway --no-pager -l

常见问题排查

问题1：服务启动失败

症状：

systemctl --user start hermes-gateway
# Job for hermes-gateway.service failed.

排查步骤：

# 查看详细错误
systemctl --user status hermes-gateway

# 查看完整日志
journalctl --user -u hermes-gateway -n 50

常见原因：

  • Python 环境问题

  • 依赖包缺失

  • 配置文件错误

  • 端口被占用

问题2：飞书连接失败

症状：日志中看到连接失败信息

排查步骤：

# 检查网络连接
ping msg-frontier.feishu.cn

# 检查飞书配置
cat ~/.hermes/hermes-agent/config.yaml

# 查看连接日志
journalctl --user -u hermes-gateway -f | grep -i lark

问题3：WSL 重启后服务没启动

症状：重启 WSL 后，服务不是 running 状态

排查步骤：

# 检查服务是否启用
systemctl --user is-enabled hermes-gateway

# 手动启动
systemctl --user start hermes-gateway

# 检查启动日志
journalctl --user -u hermes-gateway -b

预防措施

1. 设置健康检查

创建定时任务检查服务状态：

# 添加到 crontab
*/5 * * * * /usr/bin/systemctl --user is-active hermes-gateway || /usr/bin/systemctl --user start hermes-gateway
*/5 * * * * /usr/bin/systemctl --user is-active openclaw-gateway || /usr/bin/systemctl --user start openclaw-gateway

2. 配置日志轮转

防止日志文件过大：

# 创建 ~/.config/systemd/user/hermes-gateway-logrotate.conf
~/.hermes/hermes-agent/logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

3. 备份配置文件

定期备份重要配置：

cp ~/.hermes/hermes-agent/config.yaml ~/.hermes/hermes-agent/config.yaml.backup
cp ~/.openclaw/config.yaml ~/.openclaw/config.yaml.backup

结语

今天这件事挺有意思的，本来是个故障，结果变成了展示"互相拯救"的生动案例。

在 WSL 这片神奇的土地上：

  • OpenClaw 负责思考

  • Hermes 负责传话

  • 一个病了，另一个还能救它

这种架构，挺优雅的。

以后如果你也遇到 Hermes 没反应，记得：打开 OpenClaw，让它帮你救 Hermes。

一句话总结

不要把鸡蛋放在同一个进程里，但可以放在同一个 WSL 里，只要它们能互相救。