Hermes Kanban 长跑前，需要先补进度与资源护栏
Hermes 最新值得操作者关注的痛点，不是一条 release note，而是两条关于 autonomous coding 控制回路的现场报告。Issue #22397 说，CLI agent 接到明确 Kanban 任务后，可能 30 分钟到 2 小时以上都在 read / grep / read 式检查中循环，没有 edit、test 或交付物。Issue #22406 则是相反方向的失败：当 agent 终于进入 build，CPU 可能持续 100%，让 macOS 主机不可用。PR #22467 是相关的安全基础设施：为 background skill evolution 加 pending queue，把拟议 skill 改动隔离起来，做 dedupe、容量上限、冲突检测，并避免 `.pending/` 被当作 active skills 枚举出来。
影响风险 来源3 对象operator · developer · team
Autonomy 的价值在于能从“理解”走到“行动”，而且行动时不会把宿主机拖死。这两条报告正好打中同一个可靠性问题的两端：一种是任务循环永远不提交工作，另一种是终于开始工作后消耗过多机器资源。
- Hermes issue #22397 报告清晰 Kanban coding tasks 上出现 30 分钟到 2 小时以上的重复 read / search 循环，没有文件修改、没有 test run，需要用户手动介入
- 同一报告提到观测模型包括 Kimi K2.6 via kimi-for-coding 与 MiniMax M2.7，说明问题至少部分在 task-control / stopping rules，而不只是单一 provider transport
- Hermes issue #22406 报告 current-main CLI 在 macOS 上 build 时持续 100% CPU，让机器无响应，并提出需要 nice / cpulimit 类护栏或受限 subprocess 行为
- Hermes PR #22467 在 `~/.hermes/skills/.pending/` 下加入文件型 pending queue，包含隔离、dedupe、最多 100 条、TTL、冲突检测，并从 active skill listing 中排除
- 两条 bug report 都很新，在更多复现出现前可能受环境和模型组合影响
- PR #22467 还没有接入 runtime skill-update behavior、CLI review UI、gateway integration 或 notifications
- 资源限制会改变 build 行为，团队加 sandbox 或 CPU 限制后仍要验证 test / build 可复现性