第35篇：看板工作通道——分工流水线

这篇讲的是 Hermes Agent 里的“看板工作通道”（Worker Lane）——你可以把它想象成一条工厂流水线，每个工位（通道）负责一类活儿，看板系统负责把任务派给合适的工位，并盯着每项任务从“待办”走到“完成”。

先理解三个角色

• 看板（Kanban）：总调度台，记录每张任务卡片的真实状态（待办→进行中→阻塞/完成/归档）。
• 工作通道（Worker Lane）：一个“工种”，比如“写代码的”“做研究的”“审代码的”。它只负责干活，不拥有状态——干完必须向看板汇报。
• 审查员（Reviewer）：真人（或代理），负责把关“代码改完了”和“任务真完成了”之间的那道门。

第1步：给任务分配“工种”

每个任务卡片上有个 assignee 字段，相当于“派给谁”。看板调度器看到这个字段，就会去找对应的通道。

• 如果 assignee 是 Hermes 配置文件的名字（比如 coder、researcher），调度器会自动启动 hermes -p coder chat -q <提示词> 来干活。
• 如果 assignee 是外部工具（比如 Codex CLI），目前需要插件来注册，还不是一条铺好的路，需要自己写集成代码。

任务找不到对应通道时，不会被乱执行，而是留在“待办”状态并打上 skipped_nonspawnable 标记，等管理员来修。

第2步：工位怎么“开工”？

调度器会在任务的专属工作目录里启动工人，并塞给它一堆环境变量，告诉它“你是谁、在哪个板、任务ID是多少”。比如：

HERMES_KANBAN_TASK=task_123
HERMES_KANBAN_BOARD=my_board
HERMES_KANBAN_WORKSPACE=/path/to/workspace
HERMES_PROFILE=coder

工人拿到这些信息，就知道该干什么了。

第3步：干完怎么“交差”？

每个任务必须且只能有一个结局，三选一：

结局	调用工具	状态变成
成功	kanban_complete(summary="...")	done
需要人工介入	kanban_block(reason="...")	blocked
进程退出但没汇报	（无）	crashed / gave_up / timed_out

最关键的约定：如果任务是“改代码”这类需要人审的，工人应该用 kanban_block 而不是 kanban_complete，并且在 reason 前面加上 review-required: 前缀。这样看板界面就会把这行标成“待审查”。

审查员看完后，如果通过就执行 kanban_unblock，任务会重新派给工人做后续；如果要求修改，就留个评论，下一轮工人会看到。

第4步：看日志和审计

每项任务的所有输出都存在 <board根目录>/logs/<任务ID>.log 里。想看历史：

hermes kanban runs <task_id>      # 看所有尝试记录
hermes kanban tail <task_id>      # 实时跟踪日志

第5步：调度器帮你兜底

• 工人假死：超过15分钟没心跳且进程真的死了，任务会被回收重派。
• 工人崩溃：连续失败次数超限，任务自动进入“阻塞”状态等人处理。
• 超时：超过最大运行时间，自动标记 timed_out。

这些你都不用自己写，调度器全包了。

小总结

工作通道 = 一个身份（assignee）+ 一个启动方式（spawn）+ 一个结束约定（terminator）。你只需要定义好配置文件，剩下的调度、重试、审计，看板系统都帮你管好了。

下篇预告：第36篇——看板审查流程：如何让“人工把关”变得高效又省心。