夜雨聆风故事从一个早晨开始
今天早上，马哥打开飞书，发现一向乖巧的 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 里，只要它们能互相救。
