Hermes Agent看板革新：用阻塞分类与重复计数器终结无限重启

2026年5月，NousResearch在GitHub Issue 29320中披露了一起典型的生产事故：CI runner资源饱和导致4个看板任务在7小时内疯狂重启超过230次。每次Agent启动都会完整加载上下文、发现环境，然后在24-30秒内因相同的外部阻塞而退出；下一轮调度又重新认领、重新启动，如此循环，直到人类注意到异常。这种“记忆失忆症”让事件历史被数百条“仍然阻塞，无变化”的记录淹没，白白消耗了宝贵的Provider计算额度。

为了解决这一问题，Hermes Agent看板新增了两项核心机制：类型化阻塞原因和重复计数器。当同一个Agent因相同外部原因反复阻塞时，系统不再无限重启任务，而是自动将决策权转移给人类。

Nous Research 发布的 KANBAN BLOCK LOOP BREAKER 信息图，展示了死循环问题、根因分析和六步修复方案

阻塞原因类型：为每次阻塞贴上标签

新版本将阻塞原因归纳为四种类型，每类对应不同的处理策略：

• dependency——等待父任务完成。此类阻塞不消耗人类注意力，任务状态回退到 todo，父任务完成后自动恢复至 ready。
• needs_input——需要人类提供信息或决策。任务直接路由到人类处理。
• capability——超出当前 Agent 能力范围。同样路由给人类，可能需要更换 Agent 配置。
• transient——临时性问题，如网络波动、API限流。这类通常值得重试，但也会被纳入重复计数。

关键区别：dependency 类型走“自动恢复”路径，无需人类干预；其余三类都可能触发“重复→升级”逻辑。

重复计数器：记住 Agent 的“卡住”历史

每个任务现在携带一个 block_recurrences 计数器。当 Agent 调用 kanban_block 时，系统会检查当前阻塞原因是否与上次相似（模糊匹配）。若相似，计数器加一；若原因改变，计数器归零。

计数器的生命周期经过了精心设计：它在任务被 unblock 时不会被重置（因为问题可能并未真正解决），只有当任务变为 done 时才彻底归零。这意味着如果一个任务连续三次因相同原因阻塞、被人类解开两次、第三次再次阻塞，计数器会准确地累加到第三次相同阻塞。

重要阈值：默认计数达到 5 次时，任务会自动升级到 triage 列，Dispatcher 停止认领，等待人类介入。

Circuit Breaker：切断无限重启的回路

三项机制协同作用，构建了一个完整的断路器。当一个任务因 CI runner 饱和而被阻塞，事件链条如下：

1. 第 1 次阻塞：Agent 发现 CI 仍在排队，调用 kanban_block(reason="CI queued, unchanged")。
2. 第 2–4 次：Dispatcher 重新认领，新 Agent 启动后再次发现同样条件，阻塞并增加计数。
3. 第 5 次：计数器触及阈值。任务状态转为 blocked，Dispatcher 标记 circuit_open 诊断标记，不再自动认领。
4. 人类通过 Dashboard 或 CLI 看到标记，决定是解除阻塞、修改任务，还是直接完成。

这套机制与已有的 failure_limit（连续崩溃次数限制）相互补充。failure_limit 负责处理 Agent 崩溃、超时等“被动失败”，而重复计数器负责处理 Agent 主动阻塞且原因不变的“循环式卡死”。

Dependency 的自动恢复：让依赖任务安静等待

依赖类阻塞走完全不同的路径。当一个任务的父任务全部完成时，Dispatcher 会在下一轮自动将其从 todo 提升至 ready，全程无人工干预，也不触发重复计数器。

这一设计解决了现实中的典型场景：假设编排 Agent 拆出 2 个研究任务和 1 个写作任务，写作任务依赖前两个研究任务完成。旧版本中，写作任务会反复被认领、启动、发现依赖未满足、阻塞，浪费大量启动开销。而现在，它安静地停留在 todo 列，直到所有前置条件满足。

行为对比：旧版 vs 新版

为什么这个改变至关重要

多 Agent 编排中最容易被忽视的问题就是：何时该让 Agent 停手？一个没有终止条件的 Agent 系统，会将算力浪费在毫无新意的重复劳动上。Hermes Agent 看板此前已有崩溃检测与失败计数器，但缺少对“Agent 主动阻塞且原因不变”这一模式的处理。类型化阻塞原因让系统能区分“等待”与“求助”：等待类问题（dependency）不需要人类介入；求助类问题（needs_input、capability）必须交给人来决定。重复计数器则为系统设定了一个耐心上限——同一个理由听五遍就已足够，人应该接手。

对于已经使用 Hermes 看板进行多 Agent 编排的用户，升级不需要修改任何配置。阻塞原因类型由 Agent 在调用 kanban_block 时自行声明，计数器由系统自动维护。