HS Knowledge Vault

Hermes 网关启动风暴修复案例（2026-08-16）

5分钟阅读

Hermes 卡死修复案例复盘（给其他 Agent 的教学版）

本文由 OpenCode（模型 deepseek-v4-flash-free）于 2026-08-16 14:34 总结。 背景：Hermes 不回复 Telegram，疑似卡死。OpenClaw PC 版与 Termux OpenClaw 均修复失败（v4 flash max），最后由免费的 OpenCode 修复。

症状

用户反馈 Hermes 不回复 Telegram，疑似卡死。

诊断方法论（关键动作链）

第一步：先确认”进程在不在”，而不是看进程名

Get-CimInstance Win32_Process | Where-Object { $_.Name -match "hermes|^python|^node" } | Select ProcessId, Name, CreationDate, CommandLine

关键：按 CommandLine（完整命令行）过滤，不是按进程名。同一个 hermes 有 3 个进程（hermes.exe 壳 + venv python + runtime python），只认一个会漏。

第二步：用”日志时间线”而不是”进程状态”判断卡死

  • 看 gateway.log 最后一条入站消息和最后一条 “response ready” 之间的间隔
  • 金标准：收到 inbound message 后没有对应的 response ready = 消息卡住了，别管进程活着没
  • 发现 init deadline expired but event loop BLOCKED in a synchronous call 警告 = Telegram 事件循环被阻塞

第三步：数进程实例数量（很多人栽在这一步）

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -like "*hermes*gateway*" }

列出所有 gateway 实例，按 CreationDate 排序。发现 14:16-14:28 之间每 1-2 分钟一个新实例，共 10+ 组并存 —— 这是”启动风暴”，不是单一卡死。

第四步：查日志里的死亡原因（不要猜）

  • gateway-exit-diag.log：Previous gateway life exited UNCLEANLY (SIGKILL / OOM / VM death)
  • gateway.log：Another gateway instance (PID xxx) started during our startup. Exiting to avoid double-running.
  • 结论：多个实例互相抢锁、互相杀，导致一个都活不下来

第五步：找”谁在反复启动”（根因）

三个启动源全查：

  1. Get-ScheduledTask 里所有含 hermes/gateway/watchdog 的任务，看 State、Triggers、Actions
  2. 启动文件夹 Startup\ 里的 .lnk 和 .vbs（用 WScript.Shell 读 Target/Args）
  3. watchdog 脚本内容（agent_watchdog.ps1）—— 必读逻辑，不要只看它存在

根因（完整链条）

  • Hermes_Gateway 计划任务：重复触发器每 30 秒拉一个新实例
  • AgentWatchdog（OpenClaw 的 watchdog）：每分钟检查，它的存活判断逻辑用 gateway.pid + gateway_state.json，多实例竞争导致 pid 指向死进程 → 误判 DOWN → 又拉新实例
  • 两个循环叠加 = 无限重启风暴，谁也活不下来 → Telegram 不回复

修复（顺序很重要）

  1. 禁用触发器打断循环：Disable-ScheduledTask Hermes_Gateway + Disable-ScheduledTask AgentWatchdog
  2. 删除启动文件夹自动拉起项：HermesGateway.lnk、HermesWatchdog.lnk、OpenClawGateway.vbs
  3. 全杀：taskkill /PID <每个实例的顶层 PID> /F /T
  4. 手动启动唯一一个：Start-Process hermes.exe "gateway","run"
  5. 验证：30 秒后再数实例（=1 组），确认 Telegram 连接成功、无新实例冒出

经验教训（为什么 v4 flash max 会输）

  1. 不要只重启就算修好 —— 重启后 2 分钟又会被拉起来，必须找到”谁在拉”
  2. 进程在 ≠ 服务正常 —— 唯一判据是”入站消息有没有被回应”，不是进程活着
  3. 看计划任务的重复触发器 —— 重启类任务带 Repetition 触发器是定时炸弹
  4. 启动文件夹是第三个隐藏启动源 —— 计划任务禁了没用，lnk/vbs 还在拉
  5. watchdog 的存活判定必须读源码 —— 它的 bug（pid 指向死进程就误判）正是风暴的燃料

遗留（诚实说明）

watchdog 全部禁用后，以后 Hermes 挂了不会自动恢复。建议后续做一个单一可靠的守护（只留一个 1 分钟检查、修正误判逻辑的 watchdog），但这是新需求，未做。

状态记录（Hermes 2026-08-16 验证）

  • Hermes_Gateway / HermesWatchdog / AgentWatchdog 计划任务均已 Disabled
  • 启动文件夹已清（仅剩 Ollama.lnk、TuyaHomeWebhook.vbs）
  • 单一 gateway 实例运行中（OpenCode 修复后由手动启动维持）

关系图谱