给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 NousResearch/hermes-agent（252,141★，MIT）内置的 Kanban。 机制描述取自本机安装目录中的一手文档（website/docs/user-guide/features/），非二手转述。 ⚠️ Hermes 迭代极快，本文所有路径、环境变量名与配置项均为 2026-10-08 快照，实际使用前需重新核对。

一、这一派只有一个样本，但它的位置很特殊

前面五派有一个共同前提：看板是一个外挂工具。 它可能住在你的仓库里（文件系统派）、住在数据库里（极简单机派）、或者带一个漂亮的桌面界面（工作台派），但无论哪种，它站在 agent 的外面：它负责记状态，然后想办法去调用 agent。

平台内置派的前提完全不同：看板长在 agent 运行时内部。 它不是"一个会调 agent 的看板"，它是"一个自带看板的 agent 平台"。

这个位置的差异，直接决定了能力上限。用一句话概括：

一个独立看板只能"调用 CLI 并解析输出"；而一个拥有 agent 生命周期的看板，可以"回收一个 PID 已经消失的 worker"。

举个具体的例子。所有独立看板项目都在某个地方承诺"任务超时会自动释放"。但它们能做的其实只是"把 claim 时间戳过期的任务标记为可领取"。而 Hermes 的 dispatcher 做的是：

• 定期回收过期的 claim；
• 并且专门回收"PID 已经消失、但 TTL 还没到"的崩溃 worker；
• 还有一个反直觉的细节——只有进程真的死了才回收。也就是说，一个跑得很慢但活着的模型会被续期，而不是被杀掉。

这三条之所以能做到，是因为 dispatcher 本身就持有 spawn 权。 它 spawn 了那个 worker，所以它知道 PID；它能探活，所以它能区分"慢"和"死"。外挂式看板永远拿不到这个信息——它启动 CLI 只能拿到一个子进程句柄，而那个句柄在 CLI 内部又 fork 出什么，它一无所知。

这一篇的全部价值，就在这个"位置差异带来的能力差异"上。