OpenClaw LLM 自动健康守护系统 — 完整搭建教程

其他杂项43字数 4115阅读13分43秒阅读模式

LocalSync2026-02-28

OpenClaw LLM 自动健康守护系统 — 完整搭建教程

作者：一个折腾了很久才搞定的 AI 助手用户
适用场景：使用 OpenClaw 接入第三方 LLM 中转 API，需要自动处理 API 失效、模型切换、服务自愈

一、起因：为什么要做这个？

用 OpenClaw 接入第三方 LLM 中转服务（比如国内的 huanapi、anyrouter 等）时，经常遇到：

  • 某个模型突然 502、503，但 OpenClaw 还在傻傻用它
  • 所有模型短暂全挂，Telegram 上发消息完全没有回复
  • 切换到可用模型后，几分钟又挂了
  • 不知道什么时候好了，也不知道为什么好了

核心痛点：AI 助手依赖 LLM 才能运行，但 LLM 挂了它自己什么都干不了，相当于"脑子坏了叫不了救护车"。

二、踩过的坑

坑1：Rescue Bot 和主 Bot 用同一个 Token

最开始写了一个独立的救援 Telegram Bot，用来在 API 挂了时手动触发切换脚本。
结果发现：两个程序同时 long-polling 同一个 Bot Token，会互相"抢"消息。

症状：消息时而被 OpenClaw 处理，时而被 Rescue Bot 处理，时好时坏。
解决：必须给 Rescue Bot 申请独立的 Bot Token，两个 Bot 物理隔离。

坑2：用 LLM 对模型评分排序

最初想法很美好：让 AI 自己判断哪个模型更强。
结果：AI 对第三方中转服务的非标准模型名（比如 gpt-5.3-codex）完全不了解，乱排。
解决：改为静态规则排序，人工维护一个从强到弱的模型优先级列表。

坑3：rescue_bot 启动时发 Telegram 通知，暴露内部信息

启动时主动发消息告知上线，会把端口、URL 等内部信息透出。
解决：移除启动时的主动通知，Bot 只被动响应命令。

坑4：日志文件日期对不上

/tmp/openclaw/openclaw-2026-02-26.log 这个文件名是按 UTC 日期命名，但服务器在 CST（东八区），导致"今天的日志"实际上在"昨天"的文件里。
解决：查日志时先 ls -l /tmp/openclaw 看最新文件，别光看文件名日期。

坑5：webhook 用 https 打不开，页面空白

Webhook 服务跑的是 HTTP（无证书），用浏览器访问 https://... 当然空白。
解决：必须用 http://，不要套 https。如果要 https 需要额外配置证书（此教程用 http+秘密 token 方案）。

三、最终架构

设计原则：控制面与数据面分离

数据面（依赖 LLM）：OpenClaw 主对话
控制面（不依赖 LLM）：Cron + SOS Bot + Webhook

当数据面（LLM）挂了，控制面照常工作，独立完成检测和恢复。

四层容灾链路

L1: Cron 自动检测（每 30 分钟）
      ↓ 全自动，无需人工干预
L2: SOS Telegram Bot（独立 Token）
      ↓ 发送 /rescue 命令立即触发
L3: Webhook HTTP 服务
      ↓ 浏览器打开 URL 一键触发
L4: SSH 直接执行脚本
      ↓ 最终兜底

四、核心脚本：model_health_check.py

功能

  • 从所有配置的 provider 拉取可用模型列表
  • 并发测试每个模型是否能正常响应
  • 按静态规则排序（强 → 弱）
  • 自动将可用模型写回 openclaw.json，剔除失效模型
  • 切换到最优模型后发 Telegram 通知
  • 保存状态到 model_status.json

关键设计决策

排除 Gemini 模型（永久）
在 is_llm_candidate() 函数的黑名单里加入 "gemini"，在拉取阶段就过滤，不测试、不写入配置。
原因：Gemini 通过中转 API 稳定性差，且计费不透明。

静态排序规则 

KNOWN_MODEL_RANK = [
    # Tier 1: Claude 旗舰
    "claude-opus-4-6-thinking",
    "claude-opus-4-6",
    "claude-sonnet-4-6-thinking",
    "claude-sonnet-4-6",
    # Tier 2: GPT 强力
    "gpt-5.3-codex",
    "gpt-5.2-codex",
    # ...以此类推
]

并发测试（最多 10 线程）
每个模型发一条极短的测试消息（1+1=?），只判断是否返回 200，不看答案。

用法

# 仅检测，不切换
python3 model_health_check.py

# 检测 + 自动切换到最优模型
python3 model_health_check.py --auto-switch

# 输出 JSON 格式结果
python3 model_health_check.py --json

五、L1：Cron 自动检测

最稳定、最核心的一层。完全不依赖任何 AI，纯系统级定时任务。

# 编辑 crontab
crontab -e

# 添加（每 30 分钟自动执行一次）
*/30 * * * * /usr/bin/python3 /path/to/model_health_check.py --auto-switch >> /var/log/model_health.log 2>&1

优点：即使 OpenClaw 完全挂掉，Cron 照跑不误。发现可用模型就自动切换，服务自愈。

六、L2：独立 SOS Telegram Bot（rescue_bot.py）

架构特点

  • 纯 Python 标准库实现（只用 urllib，无第三方依赖）
  • 独立 Bot Token（绝对不能和 OpenClaw 主 Bot 共用）
  • 只接受指定 chat_id 的命令（防止陌生人触发）
  • 30 秒冷却时间（防止重复触发）

可用命令

命令 功能
/sos 查看可用命令列表
/rescue 立即触发健康检查 + 自动切换
/alive 检查 Bot 是否在线

⚠️ 避免使用 /help 和 /status，这两个是 Telegram BotFather 的系统命令，会产生冲突。

设置为系统服务（开机自启）

# /etc/systemd/system/rescue-bot.service
[Unit]
Description=Rescue Telegram Bot (SOS trigger)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/path/to/workspace
Environment=RESCUE_BOT_TOKEN=你的独立BotToken
ExecStart=/usr/bin/python3 /path/to/rescue_bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now rescue-bot.service

七、L3：Webhook HTTP 服务（rescue_webhook.py）

功能

  • 启动一个轻量 HTTP 服务（Python 标准库 http.server）
  • 通过秘密 URL 触发健康检查，完全绕过 AI
  • 手机浏览器直接访问即可触发

API 说明

GET  http://YOUR_SERVER_IP:19527/rescue/YOUR_SECRET_TOKEN
     → 触发健康检查 + 自动切换

GET  http://YOUR_SERVER_IP:19527/status
     → 查看 webhook 服务状态

GET  http://YOUR_SERVER_IP:19527/result
     → 查看上次执行结果

⚠️ 注意：这是 HTTP 服务，不是 HTTPS。浏览器访问必须用 http://，用 https:// 会空白页。

安全设计

  • 秘密 token：只有知道完整 URL 的人才能触发
  • 30 秒冷却：防止误触导致重复执行
  • 幂等保护：正在执行时再次触发返回 409

设置为系统服务

# /etc/systemd/system/rescue-webhook.service
[Unit]
Description=Rescue Webhook Service
After=network-online.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/python3 /path/to/rescue_webhook.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

systemctl enable --now rescue-webhook.service

八、完美结果

搭建完成后，整个系统的工作状态：

场景 系统响应
单个模型 502 Cron 定时检测，自动剔除失效模型，切换到可用模型，Telegram 通知
所有模型全挂 Cron 持续检测，一旦任意模型恢复立即切换并通知
想立即手动恢复 发送 /rescue 给 SOS Bot，或浏览器打开 webhook URL
服务器重启 rescue-bot 和 rescue-webhook 均开机自启，自动恢复
Bot Token 冲突 已通过独立 Token 彻底解决，不再抢消息

九、经验总结

  1. 控制面必须独立于数据面：救援系统不能依赖它要救的东西来运行
  2. Bot Token 必须隔离：同一 Token 多个 long-polling 客户端必然冲突
  3. 静态规则 > AI 判断：对于非标准模型名，人工维护的排序比让 AI 猜更可靠
  4. Cron 是最后的保障：其他方案都可能失效，Cron 最稳
  5. Webhook 用 HTTP 即可：配合秘密 token，安全性足够；不必为了 HTTPS 引入额外复杂度
  6. 日志文件名是 UTC 日期：查日志时注意时区，别找错文件

十、附：快速验证清单

# 验证 Cron 是否配置
crontab -l

# 验证两个服务状态
systemctl is-active rescue-bot.service rescue-webhook.service

# 验证 Webhook 可访问
curl http://YOUR_SERVER_IP:19527/status

# 手动触发一次健康检查
python3 /path/to/model_health_check.py --auto-switch

如有疑问欢迎交流，共同折腾 AI 基础设施 🚀

原文链接：file://213d06196446387945a093d6140a6ba2

 
  • 本文由 asdfasd 发表于 2026-02-2822:43:51
  • 转载请务必保留本文链接：http://wp.fangfa.me/other-note/f53b44a91894ab4db922f91963c76147.html