第23篇：看板（Kanban）——多 AI 协作白板

第23篇：看板（Kanban）——多 AI 协作白板

想象一下，你不再需要把一个任务拆成无数个“小纸条”塞给同一个助手，而是把任务贴在一面公共白板上，让不同的 AI 助手（甚至你自己）像同事一样，各自认领、更新、交接。这就是 Hermes 的看板（Kanban）功能。

第1步：理解看板是什么

看板是一个持久化的任务板，所有任务都存成数据库里的“一行”。它和 delegate_task（一次性的子任务调用）完全不同：delegate_task 像“打电话问个问题”，问完就挂；看板则像“微信群里的协作”，任务、进度、评论都留在那里，谁都能看、谁都能改，即使程序重启也不会丢。

第2步：两种操作入口

AI 助手：通过内置的 kanban_* 工具直接读写看板（比如 kanban_create 创建任务、kanban_complete 完成任务）。注意：助手是“调用工具”，不是“敲命令行”。
你（人类）：通过命令行 hermes kanban …、斜杠命令 /kanban … 或可视化看板来操作。

两种方式最终都访问同一个数据库，所以数据永远一致。

第3步：核心概念

看板（Board）：一个独立的任务队列。默认有一个 default 看板，你也可以为不同项目创建多个看板。
任务（Task）：看板上的每一行，包含标题、正文、负责人、状态等。
依赖链接（Link）：记录“父任务 → 子任务”的依赖关系。所有父任务都 done 之后，调度器才会把子任务从 todo 提升为 ready。已经跑起来的子任务不能再加链接（它已经被认领了，加链接也拦不住），唯一例外是正在运行的 worker 在交接前给自己的卡片加链接。

第4步：看板适合什么场景？

官方文档列举了 5 个典型场景：

研究分诊：多个研究员并行收集资料，分析师汇总，写手成稿，中间随时可以插入人工审核。
定时运维：每天自动生成简报，长期积累成一本“日志”。
数字孪生：给每个固定角色（如“收件箱助手”）分配一个持久身份，让它积累长期记忆。
工程流水线：拆解任务 → 并行开发 → 审查 → 迭代 → 合并代码。
批量管理：一个专家助手管理 N 个对象（比如 50 个社交媒体账号）。

第5步：什么时候用看板，什么时候用 delegate_task？

简单记：需要短平快的回答，用 delegate_task；需要跨角色协作、长期跟踪、人工介入、或者任务要能恢复，用看板。

第6步：两个新能力值得留意

迭代预算检查点：由调度器派发的 worker 会在用掉约 90% 迭代预算时收到一次检查点提醒（可用 agent.budget_warning_ratio 调早阈值）。提醒只是“报告机会”，不保证模型一定照做；硬上限、无工具最终总结、连续失败熔断这些机制都没变。普通对话和被委派的子任务不会自动继承这个检查点，需要手动开启。
PR 完成契约：创建任务时可以用 --completion-contract OWNER/REPO（或一个具体的 PR URL）声明这是一个 PR 任务；纯本地工作则用 local-only。发布 PR 后，完成时要把 metadata.published_pr 传进去，第一个匹配的 URL 会永久绑定这张卡片。完成时会校验分支保护、必需检查等证据，缺失、待定、失败、超时、跳过或中性的必需证据都无法完成任务；被拒绝时卡片和工作区都会保留，方便修复后重试。仓库没有必需检查时，请改用 local-only 契约。

第7步：别把“支援卡”挂到它要解救的那张卡下面

这是个很容易踩的坑：worker 卡在 t_parent 上，于是新建一张支援卡去补缺失的那块——这时候千万别 kanban_link(t_parent, t_support)。因为链接会让支援卡变成 t_parent 的子任务，于是它被自己本来要解救的父任务挡住，两张卡永远都跑不起来。正确做法是在支援卡的正文里写上父任务的 id 作为引用。

好在系统会把这个死锁暴露出来：link / kanban_link 在把一张 ready 的子卡降级时会报告 gated: true 并记录一条 dependency_wait 事件（用 parents 创建卡片时同理），你在看板上就能看到。想解开，用 hermes kanban unlink <parent> <child> 就行。

总结：看板是 Hermes 让多个 AI 助手像真人团队一样协作的“公共白板”。它把任务变成持久化的数据行，支持人工介入、失败重试、审计追踪，特别适合研究、运维、工程流水线等复杂工作流。

下一篇预告：第24篇将带你手把手搭建第一个看板任务，从创建到分配、完成，走一遍完整流程。别错过！