用 Hermes Agent 的 Kanban 功能规划一款 App：从需求到上线的多代理工作流

Hermes Agent 最新文档把 Kanban 定义为一个用于多 profile 协作的持久任务板。它不是普通的待办清单，也不是一次性的子代理调用。每个任务会写入本机的 SQLite 数据库；每次指派、阻塞、重试、完成和评论都会留下记录。对开发一款 App 来说，这个设计解决的不是“怎么列任务”，而是更具体的问题：当需求、设计、前端、后端、测试和发布分别交给不同 Hermes profile 处理时，任务如何交接，失败如何恢复，人又如何在中途介入。

Kanban 主要解决什么问题

如果只是让一个 agent 临时查资料、改一个文件，Hermes 的 delegate_task 已经够用。Kanban 面向的是另一类工作：跨角色、跨时间、需要审计和可恢复的项目。官网文档里说得很直接：delegate_task 更像一次函数调用，父 agent 发起后等待结果；Kanban 更像一个工作队列，所有交接都是任务板上的行，任何 profile 或人都可以读写。

开发 App 时，这个差别很重要。一个真实项目通常不会只有“写代码”一个动作。以一款习惯追踪 App “HabitLoop”为例，至少会有这些工作：

• 产品经理 profile 写 MVP 范围、验收标准和里程碑。
• 设计 profile 输出信息架构和关键页面说明。
• 后端 profile 设计数据模型、API、认证和同步逻辑。
• 移动端 profile 实现 onboarding、打卡、统计页和离线缓存。
• QA 或 reviewer profile 阅读父任务结果，跑测试，提出阻塞原因或通过。
• 发布 profile 准备版本说明、构建、上架材料和回滚清单。

这些任务之间有依赖，也有并行。认证 API 没做好之前，移动端可以先做页面骨架；后端完成后，集成测试才应该启动；QA 发现“重置 token 可重复使用”时，不应该新开一段聊天把上下文丢掉，而应该把同一个任务标记为 blocked，由人或 reviewer 写清原因，再 unblock 触发下一次运行。Kanban 的价值就在这里。

几个核心概念先讲清楚

根据 Hermes 官网文档和 GitHub 源码，Kanban 的关键对象有这些：

• Board：任务板。默认板的数据库位于 ~/.hermes/kanban.db；多项目板会放在 ~/.hermes/kanban/boards/<slug>/kanban.db。每个 board 还有自己的 workspace 和日志目录。
• Task：任务行。包含标题、正文、assignee、状态、优先级、tenant、workspace 类型、结果等字段。文档列出的状态包括 triage、todo、ready、running、blocked、done、archived。
• Link：父子依赖。源码和文档都使用 parent → child 的方向。父任务完成后，dispatcher 才会把依赖它的子任务从 todo 推进到 ready。
• Comment：任务线程里的持久评论。人和 agent 都可以写，worker 重启后会读到这些上下文。
• Workspace：任务运行目录。支持 scratch、dir:<absolute-path> 和 worktree。写代码时 worktree 尤其有用，能把不同任务放到独立 git worktree，减少互相踩代码。
• Dispatcher：调度循环。文档说明它默认跑在 gateway 里，配置键是 kanban.dispatch_in_gateway: true，默认每 60 秒检查一次 ready 任务、声明任务、启动对应 profile，并回收过期或崩溃的运行。

源码里也能看到一个重要实现细节：worker 不是靠 shell 执行 hermes kanban complete 来回写状态。tools/kanban_tools.py 注册了 kanban_show、kanban_complete、kanban_block、kanban_heartbeat、kanban_comment、kanban_create、kanban_link 这组工具。dispatcher 启动 worker 时会设置 HERMES_KANBAN_TASK，这些工具才会进入模型 schema。普通聊天会话不会平白多出这组工具。

第一步：为 App 项目建一个独立 board

如果只试用一次，可以直接用默认 board。真正开发 App 时，建议按项目建板。例如 HabitLoop：

hermes kanban boards create habitloop-app \
  --name "HabitLoop App" \
  --description "Habit tracking mobile app from MVP to release" \
  --switch

hermes kanban init
hermes gateway start
hermes dashboard

hermes dashboard 打开后，Kanban tab 会显示按状态分组的任务列。文档提到 dashboard 支持 board 切换、任务详情抽屉、评论、事件流、运行历史、阻塞/恢复操作，以及 running 列按 profile 分 lane。CLI、dashboard 和 slash command 都写同一套数据库，视图不会分叉。

第二步：把 App 开发拆成一张任务图

不要把“开发 HabitLoop”塞进一个大任务。比较规范的做法是先创建规划任务，再用依赖把后续任务串起来。下面是一个可落地的拆法：

PM=$(hermes kanban create "Define HabitLoop MVP scope" \
  --assignee pm \
  --workspace scratch \
  --body "Write target users, MVP features, non-goals, acceptance criteria, and release milestones." \
  --json | jq -r .task.id)

DESIGN=$(hermes kanban create "Design HabitLoop onboarding and core screens" \
  --assignee designer \
  --workspace scratch \
  --body "Produce IA, screen list, empty states, and copy notes for onboarding, daily check-in, stats, settings." \
  --json | jq -r .task.id)

BACKEND=$(hermes kanban create "Implement HabitLoop sync API and auth" \
  --assignee backend-dev \
  --workspace worktree \
  --body "Design database tables, auth/session flow, habit CRUD, check-in sync API, and tests." \
  --json | jq -r .task.id)

MOBILE=$(hermes kanban create "Build HabitLoop mobile MVP" \
  --assignee mobile-dev \
  --workspace worktree \
  --body "Implement onboarding, habit list, daily check-in, local cache, stats, and API integration." \
  --json | jq -r .task.id)

QA=$(hermes kanban create "QA HabitLoop MVP against acceptance criteria" \
  --assignee reviewer \
  --workspace worktree \
  --body "Read PM, design, backend, and mobile handoffs. Run tests, check core flows, list release blockers." \
  --json | jq -r .task.id)

接着建立依赖：

hermes kanban link $PM $DESIGN
hermes kanban link $PM $BACKEND
hermes kanban link $DESIGN $MOBILE
hermes kanban link $BACKEND $MOBILE
hermes kanban link $MOBILE $QA

这样做以后，PM 任务完成之前，设计和后端任务不会被提前推进；设计和后端都完成后，移动端任务才具备足够上下文；移动端完成后 QA 才启动。这个流程比“在一段长聊天里连续喊 agent 做事”稳得多，因为每一步都有父任务结果、评论和运行历史。

第三步：让不同 profile 各做各的事

Kanban 不是把一个模型分裂成几个虚拟角色，而是让不同 Hermes profile 作为完整 OS 进程运行。每个 profile 可以有自己的模型、memory、工具权限和默认工作目录。官网文档建议 worker profile 使用 kanban-worker skill；dispatcher 也会在启动 worker 时自动传入 --skills kanban-worker，让 worker 知道标准生命周期：

• 启动后先调用 kanban_show()，读取任务正文、父任务结果、评论、历史 run 和 worker_context。
• 进入 $HERMES_KANBAN_WORKSPACE 做实际工作。
• 长任务期间用 kanban_heartbeat(note="...") 写入进度。
• 完成时调用 kanban_complete(summary="...", metadata={...})，留下摘要和结构化证据。
• 缺少信息、凭据或决策时调用 kanban_block(reason="...")，等待人处理。

这也是为什么 Kanban 适合 App 开发。比如 backend-dev 的完成结果里可以写：

{
  "changed_files": ["api/auth.py", "api/habits.py", "tests/test_habits.py"],
  "verification": ["pytest tests/test_habits.py -q"],
  "residual_risk": ["rate limit policy not finalized"]
}

后续 mobile-dev 和 reviewer 不需要从聊天记录里猜 backend 做了什么，可以直接从父任务 handoff 读取。

第四步：用 block / unblock 做真实的评审循环

App 开发不会一路绿灯。假设 reviewer 发现两个问题：离线打卡同步会重复提交，密码重置 token 没有单次使用保护。reviewer 不应该把任务“完成但提醒一下”，更合适的是阻塞：

# worker tool call, shown here as intent rather than a command you run
kanban_block(reason="Offline check-in sync can duplicate records; reset token is reusable within 30 minutes.")

人在 dashboard 里看到 blocked 任务后，可以补充决策或让工程师修复：

hermes kanban comment $MOBILE "Fix by adding client-side idempotency key and server-side de-dup on check_in_id."
hermes kanban unblock $MOBILE

dispatcher 下一轮会把任务重新放回 ready，并启动同一个 assignee 的新 run。文档中的教程强调，新的 worker_context 会包含上一次 block 的原因，所以第二次运行不必从头猜 reviewer 在意什么。运行历史可以通过 hermes kanban runs <id> 查看。

第五步：用 dashboard 和 CLI 盯住项目状态

开发过程中，常用观察命令很少：

hermes kanban list
hermes kanban stats
hermes kanban watch --kinds completed,blocked,gave_up,timed_out
hermes kanban tail <task_id>
hermes kanban runs <task_id>
hermes kanban log <task_id>

如果接入了 Telegram、Discord、Slack 等 gateway，Kanban 还支持对单个任务订阅通知。任务到达 done 或 archived 后，订阅会自动清理。对移动开发这种会跑构建、测试、上传的流程来说，这比盯着终端实用。

什么时候不要用 Kanban

Kanban 有调度、数据库、profile、workspace 和恢复机制，适合项目型工作。小问题不必上板。比如“帮我解释这段错误日志”或“把这个函数改成 async”，如果没有跨角色交接、没有人类阻塞点、也不需要长期审计，用普通聊天或 delegate_task 更轻。

但只要工作变成了“多个角色按依赖推进”，Kanban 就开始有意义。开发 HabitLoop 这样的 App 时，它让 PM、设计、后端、移动端、QA 和发布不再挤在同一段上下文里，也不靠人肉复制粘贴交接。任务板本身就是项目记忆：谁做了什么、为什么卡住、怎么重试、哪些证据能证明完成，都在里面。

参考资料

• Hermes Agent official docs: Kanban (Multi-Agent Board)
• Hermes Agent official docs: Kanban tutorial
• GitHub source: hermes_cli/kanban.py
• GitHub source: hermes_cli/kanban_db.py
• GitHub source: tools/kanban_tools.py