给本地 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 出什么，它一无所知。

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

我曾经把个人助理的每一层都自己实现：Lark WebSocket、卡片、Agent Loop、Goal Runtime、记忆、定时任务、多模型 fallback、工具审批和多云 VPS 运维。

这样做最大的收益是理解了边界，最大的代价也是边界——一旦通用 Agent 能力持续扩张，维护一个个人助手就会逐渐变成维护一个框架。

更合理的方向是：

成熟 Agent 负责通用助理能力
标准 MCP 负责专业工具
服务端策略负责最终安全边界

但“成熟”和“轻量”不能只看项目介绍。这篇文章使用同一组需求评估 2026 年几类主流选择。

我的真实需求

这不是通用 Agent 排行榜。目标环境是一台低资源 VPS，主要服务一个人：

• 通过 Lark 私聊和群聊使用；
• 处理问答、翻译、摘要、Idea、纪要和博客；
• 保存少量长期偏好与会话历史；
• 支持定时提醒和主动推送；
• 通过 MCP 接入 GitHub、知识库和多云运维；
• 模型不可用时，核心运维控制面仍然可查询；
• 重启、备份、恢复和发布等动作必须人工批准；
• 使用远程模型，不在小 VPS 上运行本地大模型。

基于这些约束，我把候选分成两类：

成品助理：Hermes Agent / OpenClaw / nanobot
开发框架：OpenAI Agents SDK / PydanticAI / Agno / LangGraph

成品助理的优势是少造渠道、记忆和调度；框架的优势是运行时可控，但应用外壳仍要自己写。

先定义“成熟”

一个仓库更新频繁、Star 很多，不等于适合长期运行。我更关心：

1. 配置和升级有没有稳定入口；
2. 会话和任务能否在重启后恢复；
3. 渠道是否处理去重、重连和用户隔离；
4. MCP 是否支持过滤、超时和失败降级；
5. 高风险工具是否有确定性权限边界；
6. 日志、健康检查、备份和回滚是否可操作；
7. 安全修复是否持续发布；
8. 能否关闭不需要的工具，而不是默认把整台主机交给模型。

个人助理生态仍然变化很快。这里的“成熟”是相对成熟，不等于 systemd、SQLite 或 Ansible 那样经过多年稳定周期。