Kanban 是什么

Hermes Agent 是一个开源 AI Agent 框架，支持在终端、Telegram、Discord、Slack 等多个平台上运行。它的 Kanban 功能是一套持久化的多 Agent 协作任务板，让多个独立的命名 Agent（在 Hermes 中称为 profile）通过共享的任务队列协同工作，无需依赖脆弱的进程内子代理调度。

每条任务是 SQLite 数据库中的一行记录，每次交接是任何人都可读写的持久数据，每个 worker 都是一个拥有独立身份和记忆的完整操作系统进程。这和 Hermes 原有的 delegate_task（一次性函数调用式子代理派发）形成互补：delegate_task 适合快速的一问一答，Kanban 适合需要持续状态、多角色接力、人类介入的工作流。

它能做什么：从一个真实场景说起

假设你需要写一篇技术调研报告。传统做法是让一个 AI Agent 从头做到尾，结果往往是：调研深度不够、写作风格单一、中间方向偏离无人纠正。

用 Kanban，流程变成这样：

1. 你创建一个 triage 状态的任务：“调研 Hermes Kanban 功能，形成一篇面向开发者的分析报告”
2. 系统的自动编排器（decomposer）将它拆解为三个子任务：researcher 做信息采集、analyst 做综合分析、writer 负责成文
3. 两个 researcher 子任务并行执行，各自负责不同信息源
4. 它们完成后，analyst 自动启动，读取两份调研结果进行综合
5. analyst 完成后，writer 启动，基于综合结果撰写报告
6. 整个过程中，你随时可以评论、调整方向、阻塞等待决策
7. 最终产出包含完整的审计轨迹：谁做了什么、花了多久、中间经历了几次迭代

这不是概念设想，而是 Kanban 的标准工作模式。

Kanban 的核心概念有哪些

Kanban 由六个相互协作的组件构成。

**Board（看板）**是独立的任务队列，拥有自己的 SQLite 数据库、工作目录和调度循环。单次安装可以创建多个 board，按项目或领域隔离。

**Task（任务）**是看板中的基本单元，包含标题、正文、一个 assignee（指派的 profile 名称）、状态流转链（triage → todo → ready → running → blocked → done → archived），以及可选的 tenant 命名空间和幂等键。

**Link（依赖）**记录任务之间的 parent → child 关系。当所有父任务完成后，子任务自动从 todo 提升为 ready，由调度器拾取执行。这实现了"扇出 + 扇入"的并行编排。

**Comment（评论）**是 Agent 之间的通信协议。Agent 和人类都可以追加评论，worker 被（重新）调度时会读取完整的评论线程作为上下文。这本质上是任务维度的对话通道，不依赖主聊天的上下文窗口。

**Workspace（工作空间）**是 worker 操作的目录。scratch 是临时目录，任务完成后自动清理；dir:<path> 指向一个现有的持久目录；worktree 是 Git worktree，适合编码任务。

**Dispatcher（调度器）**是长驻循环，默认每 60 秒执行一轮：回收过期 claim → 检测崩溃的 worker → 提升 ready 任务 → 原子认领 → spawn 分配的 profile。它运行在 Hermes Gateway 进程内部，不需要单独管理。

人类如何介入 Agent 的工作过程

Kanban 和纯自动化批处理的根本区别在于，它在工作流的每个阶段都留了人类介入的入口。

入口控制（Triage）：任务可以创建在 triage 状态，相当于一个"停车场"。你可以先审视任务描述是否清晰、拆解是否合理，再决定是否推进到执行队列。

执行中阻塞（Block/Unblock）：Worker 在执行过程中遇到需要人类判断的决策时，会调用 kanban_block 主动暂停。例如翻译任务中遇到专业术语需要确认，或者技术方案需要你选择方向。你做出决策后通过 unblock 解除阻塞，worker 继续执行。

持续评论（Comment）：你随时可以往任务线程中追加评论，比如"请用中文写作，控制在 3000 字以内"或"这个方向不对，请参考 X 的做法"。Worker 下次被调度时会读取这些评论。

产出审查（Runs）：每次执行尝试都记录在 task_runs 表中。你可以查看每次尝试的耗时、结果摘要、错误信息，不满意可以修改任务描述后重新调度。

Goal 模式的验收标准：创建任务时指定验收标准，worker 会在每轮结束后自检是否满足。写得越明确，产出越可控。

Kanban 支持哪些协作模式

Kanban 不是一种固定的编排方式，而是支持多种协作模式的基础设施。官方文档列出了九种典型模式：

任务如何分配给不同 Agent

Kanban 不要求必须有多个 profile。单个 profile 就能使用，此时它就是一个带持久化、可重试、可审计的工作队列。多 profile 是为了专业分工。

任务分配有三种精度档位：

手动指派：创建任务时显式指定 --assignee <profile-name>，你完全控制谁做什么。

Orchestrator 自动分配：Orchestrator agent 读取你的 profile 列表和描述，根据任务内容决定分配给哪个 profile。精度取决于 profile 描述的质量。

Auto-decomposer：triage 任务进入后，系统使用辅助 LLM 读取 profile roster，自动拆解为子任务图并路由到最合适的专家。如果 LLM 选了一个不存在的 profile，任务会 fallback 到默认 assignee。

两个入口，同一个数据库

Kanban 的设计有一个重要的架构选择：它有两套操作界面，但后端共享同一个 SQLite 数据库。

Agent 通过工具调用：dispatcher spawn 每个 worker 时，自动在模型的 schema 中注入 kanban_* toolset（kanban_show、kanban_complete、kanban_block 等）。Worker 直接调用这些工具，不走命令行。这样做的好处是：无论 worker 的终端后端是本地、Docker 还是 SSH 远程，工具调用始终能访问到数据库；结构化 JSON 参数避免了 shell 引号问题；普通聊天会话零 schema 占用。

人类通过 CLI 或斜杠命令：hermes kanban create/list/show/... 或在聊天平台中 /kanban create/list/show/...。参数格式完全相同，两个入口的读写结果一致。

此外还有一个 Dashboard GUI，提供拖拽式看板界面，支持内联创建、多选批量操作、依赖编辑、实时 WebSocket 更新。

什么场景适合用 Kanban

Kanban 的适用边界可以用一句话划清：当你需要的不只是一个答案，而是一条有状态、可中断、可追溯的工作流水线时，Kanban 才值得启动。

三类任务是它的甜区：

1. 需要多角色接力：研究 → 分析 → 写作 → 审查这种多阶段管道，每个阶段需要不同的专业能力
2. 需要人类中途介入：翻译确认术语、调研调整方向、敏感操作需要审批
3. 需要并行执行 + 结果汇总：N 个同类 worker 同时跑不同子任务，完成后自动触发汇总

反过来说，简单问答、一次性小任务、纯自动化无人值守流水线，用 delegate_task 或 cron 就够了，不需要 Kanban 的额外开销。

与 delegate_task 的对比

这两个能力看起来相似，但定位完全不同：

一句话区分：delegate_task 是函数调用；Kanban 是工作队列，每次交接都是任何 profile 或人类可见可编辑的行。

快速上手

从聊天平台操作同样简单：/kanban create "调研 AI Agent 框架生态" --assignee researcher。

参考资料

• Hermes Kanban 官方文档
• Hermes Kanban Tutorial
• Hermes Agent GitHub 仓库