看板——多 Agent 协作白板

嘿，朋友们！今天咱们来聊聊 Hermes 里一个特别酷的功能——看板（Kanban）。你可以把它想象成一块团队用的白板，上面贴满了便签纸，每张便签就是一个任务，多个 Agent 可以在这块白板上协作干活，互不干扰又井然有序。

看板是啥？

简单说，看板就是让多个 Agent 各司其职、并行处理任务的“作战指挥室”。你不需要手动一个个去调度它们，看板会自动把任务分配给合适的 Agent，谁有空谁上，谁擅长什么就干什么。

看板的每个任务都是 ~/.hermes/kanban.db 里的一行记录，每次交接都是一行谁都能读写的记录，每个 worker 都是一个拥有自己身份的完整操作系统进程——所以它天生就能扛住重启、崩溃和人工介入，而不像进程内的子 Agent 那样一崩全崩。

看板怎么用？

在 Hermes 里，看板的核心是任务卡片。每张卡片代表一个待办事项，你可以给卡片设置：

标题和描述——告诉 Agent 要干啥
优先级——哪些任务先干
标签——方便分类和检索
截止时间——给 Agent 定个 deadline

看板会把这些卡片按状态分组，比如“待处理”、“进行中”、“已完成”。Agent 们认领卡片后，状态自动流转，你一眼就能看到整个项目的进度。

多 Agent 怎么协作？

这才是重头戏！看板里的每个任务都可以指定由哪个 Agent 执行。你可以：

按能力分配——写代码的活儿交给代码 Agent，写文案的交给写作 Agent
按负载均衡——谁空闲就派给谁，避免某个 Agent 忙死、另一个闲死
设置依赖关系——任务 A 完成后，自动触发任务 B

看板还支持任务间通信——Agent 完成任务后，可以把结果写到卡片上，下一个 Agent 读取卡片内容继续干活。就像流水线一样，一环扣一环。

小心踩坑：别把“支援卡片”链接到它本来要解锁的那张卡片上。假设 worker 卡在 t_parent 上，于是建了一张支援卡片去补缺失的东西，这时候千万别 kanban_link(t_parent, t_support)——这个链接会让支援卡片变成被卡住的父卡片的子任务，结果它反而被自己要去解锁的父卡片挡住，两张卡片都永远跑不起来。正确做法是在支援卡片的正文里引用父卡片的 id。link/kanban_link 在把一张 ready 的子卡片降级时会报告 gated: true 并记录一条 dependency_wait 事件（kanban_create 带 parents 把新卡片挂起时也一样），所以这种死锁在看板上是看得见的；用 hermes kanban unlink <parent> <child> 就能解开。

另外，给一个已经在运行的子任务加链接会被拒绝，因为它没法再拦住已经被认领的工作；唯一的例外是活跃 worker 在依赖阻塞交接之前，立刻给自己的卡片加链接（此时它持有调度器给的 run 归属）。

看板 + 模型配置

还记得我们之前聊过的模型配置吗？看板里的 Agent 默认用的是你的主模型，但你也可以给特定任务指定辅助模型——比如用便宜的小模型做文本摘要，用视觉模型分析图片。这样既省钱又高效。

小提示：看板这种无人值守的任务，默认会“安全失败”——如果某个模型需要你确认数据训练授权，看板任务会直接跳过而不是擅自同意。如果你确认没问题，可以提前用命令授权：
hermes config set security.allow_data_training_tiers_noninteractive true

迭代预算快用完时会收到提醒

由调度器（dispatcher）托管的 worker，在迭代预算用到大约 90% 的时候会收到一次检查点提醒，这条提醒会附在一条新的工具调用结果上，此时通常还剩一次可调用工具的机会。你可以用 agent.budget_warning_ratio 把提醒阈值调得更早。预算特别小的时候，提醒最晚也会在倒数第二次迭代前发出；如果整个任务只允许一次迭代，那就没有这个提醒窗口了。这条提醒会在下一次请求之前写进会话记录里。

收到提醒后，worker 应该先核对任务约定（task contract）再决定是否调用 kanban_complete；如果还没完成，就写一条进度评论然后继续干。光有一次 commit 或 diff 并不会自动把任务标记为完成。

需要说明的是，硬性上限、无工具调用的最终总结、以及连续失败熔断机制都没有变化：预算真的用光的 worker 仍然会走有界重试。这个提醒只是一个“报告机会”，并不保证模型一定会听。普通对话和被委派的子任务不会自动继承这个看板检查点，它们的迭代提醒仍然是可选项。

PR 完成约定

如果任务最终要产出 PR，可以在创建卡片时就声明完成约定：用 --completion-contract OWNER/REPO（如果 PR 已经存在，也可以直接给一个精确的 https://github.com/OWNER/REPO/pull/123 URL）。kanban_create 也接受同样的 completion_contract 参数。如果就是本地活儿，用 local-only；已经存在的卡片和没声明的卡片默认就是 local-only。注意，正文里随便写个 URL 不算数，只有显式声明的才算约定。

PR 发布之后，在完成时把 metadata.published_pr 传进去。第一个匹配的 URL 会永久绑定到这张卡片上，重试时不能换成另一个“绿的”兄弟 PR。用 CLI 的 show --json 或 kanban_show 都能看到持久化的约定。

共享的 complete_task 边界会覆盖 worker 工具、CLI、review 批准和 dashboard 完成这几个入口。它会读取经典的分支保护规则和生效中的 ruleset 所要求的检查上下文，分页拉取精确 head 的 check run 和旧式 status，然后再重新读一遍 PR 的 head/base。可选的失败/跳过遥测不会否决已经通过的必需检查。但缺失、待定、失败、取消、超时、过期、跳过或中立的必需证据，都无法让卡片完成；零 check run 的“通过”、读不到策略、GitHub API 报错，同样不行。如果仓库根本没有必需检查，那就得用 local-only 约定。gh 必须已认证，并且对仓库的 checks 和 rules 有读权限；这个关卡本身不会做任何远程写操作。

被拒绝时，卡片和 workspace 都会保留。持久化的 pr_acceptance 事件会记录 PR URL、SHA、必需上下文、check ID/URL、分类结果和恢复指引；last_failure_error 会告诉你下一步该干嘛。修好失败、重跑基础设施类检查或者等一等，然后再重试完成。如果需要人工介入，就用 kanban_block。GitHub 返回笼统的 failure 时，无法判断到底是测试挂了还是产物上传挂了，得去看它保留的 URL。明确的基础设施结论和 API 失败会被单独分类。整个过程不会额外再起一个 worker。

看板实战场景

内容工厂：一个 Agent 写初稿，另一个润色，第三个配图，流水线作业
代码审查：写完代码自动触发审查 Agent，发现问题自动创建修复任务
定时巡检：每天定时让 Agent 检查服务器状态，异常自动建卡报警

上手试试

在 Hermes 里创建看板很简单，一条命令的事：

hermes kanban create "我的第一个看板"

然后往里面加任务卡片，剩下的交给 Agent 们吧！

看板让多 Agent 协作变得像贴便签一样简单。赶紧去试试，让你的 Agent 团队转起来吧！