AI 助手互备系统：OpenClaw ↔ Hermes 双向监控与自动恢复实践

1. 背景与需求

在生产环境中运行 AI 助手时，我们面临一个关键问题：如果 AI 助手本身挂了，谁来救它？

我们的环境中有两个 AI 助手：

• OpenClaw：基于 Node.js 的 AI 助手，Gateway 端口 18789
• Hermes：基于 Python 的 AI 助手，Gateway 端口 8000

关键洞察：Hermes 进程不依赖 OpenClaw 运行，所以即使 OpenClaw 完全挂了，Hermes 仍然是"活着"的，可以执行恢复操作。反之亦然。

基于这个洞察，我们设计了一套双向互备系统：

• OpenClaw 通过 cron 定时监控 Hermes 状态
• Hermes 通过 cron 定时监控 OpenClaw 状态
• 任何一方检测到对方故障，都可以尝试自动恢复

2. 系统架构

2.1 整体架构图

2.2 关键组件

3. 监控机制

3.1 健康检查方法

监控脚本使用多层检查策略：

#!/bin/bash
# Hermes 健康监测脚本（简化版）

# 检测函数：检查 Hermes Gateway 是否响应
check_hermes() {
    # 方法 1: 检查 systemd service 状态
    if systemctl --user is-active --quiet hermes-gateway 2>/dev/null; then
        return 0
    fi
    # 方法 2: 检查端口响应
    if timeout 3 bash -c "echo > /dev/tcp/localhost/8000" 2>/dev/null; then
        return 0
    fi
    return 1
}

# 主循环
if check_hermes; then
    log "Hermes OK"
    echo "0" > $STATE_FILE  # 重置失败计数
else
    fail_count=$(get_fail_count)
    fail_count=$((fail_count + 1))
    echo "$fail_count" > $STATE_FILE
    log "Hermes DOWN (连续失败 $fail_count 次)"
    
    # 连续 6 次失败（30 分钟）触发告警
    if [ $fail_count -ge 6 ]; then
        send_alert "Hermes 故障告警"
    fi
fi

3.2 状态跟踪

使用状态文件跟踪连续失败次数：

• /tmp/hermes-monitor.state：记录当前失败计数
• /tmp/hermes-monitor.log：记录所有检查日志
• /tmp/hermes-alert-pending.txt：标记已发送告警，避免重复通知

3.3 Cron 配置

# OpenClaw 监控 Hermes
*/5 * * * * bash /root/.openclaw/scripts/monitor-hermes.sh >> /tmp/hermes-monitor.log 2>&1

# Hermes 监控 OpenClaw
*/5 * * * * bash /root/scripts/monitor-openclaw.sh >> /tmp/openclaw-monitor.log 2>&1

4. 恢复机制

4.1 恢复策略

恢复脚本采用渐进式恢复策略：

1. 简单重启：尝试重启 systemd 服务
2. 配置修复：运行诊断工具自动修复配置问题
3. 备份恢复：从最近的备份恢复配置文件
4. 强制重启：kill 进程后重新启动

4.2 OpenClaw 恢复流程

# 完整恢复流程
bash /root/scripts/recover-openclaw.sh

# 仅检查不恢复
bash /root/scripts/recover-openclaw.sh --check-only

# 仅执行修复不重启
bash /root/scripts/recover-openclaw.sh --fix-only

4.3 Hermes 恢复流程

5. 独立通知系统 ⭐

5.1 设计原则

• 不依赖 AI 进程：通知脚本不依赖 OpenClaw 或 Hermes Gateway
• 直接 API 调用：使用 curl 直接调用飞书 API
• 独立凭证管理：从配置文件读取 appId/appSecret，获取 tenant_access_token

5.2 实现原理

#!/bin/bash
# 发送飞书通知（直接 API，不依赖 OpenClaw/Hermes 进程）

# 从配置读取飞书凭证
get_feishu_config() {
    local config_file="/root/.openclaw/openclaw.json"
    APP_ID=$(python3 -c "import json; d=json.load(open('$config_file')); print(d['channels']['feishu']['appId'])" 2>/dev/null)
    APP_SECRET=$(python3 -c "import json; d=json.load(open('$config_file')); print(d['channels']['feishu']['appSecret'])" 2>/dev/null)
}

# 获取飞书 access token
get_token() {
    TOKEN=$(curl -s -X POST "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal" \
        -H "Content-Type: application/json" \
        -d "{\"app_id\": \"$APP_ID\", \"app_secret\": \"$APP_SECRET\"}" | \
        python3 -c "import sys,json; print(json.load(sys.stdin).get('tenant_access_token',''))")
}

# 发送文本消息
send_feishu_message() {
    local message="$1"
    curl -s -X POST "https://open.feishu.cn/open-apis/im/v1/messages" \
        -H "Authorization: Bearer $TOKEN" \
        -H "Content-Type: application/json" \
        -d "{
            \"receive_id\": \"USER_ID\",
            \"msg_type\": \"text\",
            \"content\": {\"text\": \"$message\"}
        }"
}

5.3 通知策略

6. 实现细节

6.1 文件清单

6.2 日志管理

所有监控和恢复操作都记录到日志文件：

• /tmp/hermes-monitor.log：Hermes 监控日志
• /tmp/openclaw-monitor.log：OpenClaw 监控日志
• /tmp/hermes-emergency-recover.log：Hermes 恢复日志
• /tmp/openclaw-emergency-recover.log：OpenClaw 恢复日志

# 查看最近 20 条监控日志
tail -20 /tmp/hermes-monitor.log
tail -20 /tmp/openclaw-monitor.log

# 手动检查健康状态
bash /root/.openclaw/scripts/monitor-hermes.sh --check-only
bash /root/scripts/monitor-openclaw.sh --check-only

7. 经验教训

7.1 关键教训

7.2 设计原则

• 最小依赖原则：监控和恢复脚本应该依赖最少的组件
• 渐进式恢复：先尝试简单修复，失败后再尝试复杂操作
• 状态持久化：使用状态文件跟踪连续失败次数，避免瞬时故障误报
• 通知去重：使用标记文件避免重复发送告警

7.3 覆盖不到的场景

互备系统能覆盖大部分故障场景，但以下情况仍需人工介入：

• ❌ 机器宕机或网络完全中断
• ❌ 系统权限问题（如 systemd 服务配置错误）
• ❌ API Token 过期或凭证失效
• ❌ 磁盘空间耗尽等系统级问题

8. 总结

8.1 核心价值

• 自动化故障恢复：大部分 Gateway 级别的故障可以自动恢复
• 减少人工干预：30 分钟内无需人工介入，系统会尝试自我修复
• 及时告警：超过阈值立即通知，避免问题被忽视
• 独立通知通道：确保即使 AI 挂了也能发出告警

8.2 适用场景

这套互备系统特别适合以下场景：

• 多个 AI 助手运行在同一台机器上
• 需要 7x24 小时在线的生产环境
• 无法容忍长时间中断的关键业务

8.3 后续优化方向

• 增加更多健康检查指标（如响应时间、错误率）
• 实现更智能的故障诊断（区分网络问题、配置问题、进程崩溃）
• 添加自动回滚机制（恢复失败后自动回退到已知良好状态）
• 集成到更完善的监控系统（如 Prometheus + Grafana）