从状态机、Worker 生命周期、故障恢复到最小实现，讲清 Hermes Kanban 如何把多 Agent 协作变成可恢复、可审计的持久化任务系统。

很多团队第一次把 Agent 串成流水线，最先撞上的问题通常不是模型不够聪明，而是任务会丢。子任务做完了，答案回来了，但过程没留下；进程一崩，现场没了；人想中途补一句，也没有正式入口。最后搭出来的不是协作系统，而是一串脆弱的函数调用。

Hermes Kanban 解决的正是这个问题。它不是“多开几个 Agent”的快捷按钮，而是把任务、交接、重试、人工介入和审计追踪都写进一个持久化看板。官方文档对它的定义很直接：任务记录保存在 SQLite 中，每个 worker 是独立 OS 进程，不是一次性子 agent。换句话说，Kanban 把多 Agent 协作从“调用关系”升级成了“任务系统”。

先给结论：Hermes Kanban = 持久化任务队列 + 状态机 + 具名 worker + 可恢复运行历史。它适合跨角色、跨回合、需要人介入、需要留痕的工作；如果只是让一个子任务马上回答案，delegate_task 仍然更轻。

这个判断背后有一个很具体的成本账。短任务失败，通常只是多问一次；长链路任务失败，损失的是上下文、责任边界和时间。比如一篇技术文章从选题、资料采集、写作、审校到发布，中间任何一环卡住，如果系统只保存最后一段对话，下游就很难判断：资料是否已经核验？代码是否跑过？审校到底打回了哪里？Kanban 的价值就在这里。它不指望每个 Agent 都记得全局，而是把“谁做过什么、为什么停下、下一步谁接手”沉到任务层。

维度覆盖声明

本文覆盖背景/介绍、痛点、原理、案例/实践、代码/实现、内部横向对比、边界/局限、趋势/演进和总结。外部竞品对比不展开，因为当前素材只采集到 Hermes 官方文档和相关 GitHub 链接，没有足够一手材料支撑严肃横评。本文只做 Hermes 内部的 Kanban vs delegate_task 对比，目标是把 Kanban 的生命周期、调度器和最小实现讲透。

所以，本文不会把 Kanban 包装成“万用调度平台”。它更像一层协作协议：任务存在数据库里，状态由内核维护，worker 按协议读写结果，人类在需要时介入。理解这一层之后，再谈自动分解、Dashboard、profile lane，才不会把功能点看散。

先看全景：Kanban 到底在管什么

Kanban 的核心不是一张 UI 看板，而是一套统一数据模型。官方文档给出的最小骨架包括 Board、Task、Run、Comment、Workspace 和 Dispatcher。默认情况下，单项目用户使用 default 看板；任务保存在 ~/.hermes/kanban.db，调度器跑在 Gateway 里，默认每 60 秒扫描一次 ready 任务。

这里的关键点是“统一”。人类可以用 CLI、Dashboard 或斜杠命令操作；worker 则用 kanban_* 工具操作。两边最终都走同一个 kanban DB 层，所以不会出现“界面上看到一套、Agent 手里维护另一套”的双轨状态。

# 初始化与查看 Kanban 的最小命令
hermes kanban init
hermes gateway start
hermes kanban create "research AI funding landscape" --assignee researcher
hermes kanban list --status ready
hermes kanban show t_xxxx

这组命令演示的是同一底座、多个入口。你在终端创建任务，Dashboard 会看到同一条记录；worker 认领任务后调用 kanban_show()，读到的也是这条任务的完整上下文。对多角色协作来说，这比“把消息转发给下一个 Agent”可靠得多，因为系统知道每张卡片的状态、依赖和历史。

Board 是隔离边界，适合按项目或领域拆开；Task 是可调度的最小工作单元；Run 是一次实际尝试，失败和重试都不会覆盖前一次记录；Comment 是人类和 Agent 都能追加的线程；Workspace 则决定 worker 到哪里落文件。把这些概念分开很重要。很多临时脚本式协作把“任务”和“运行结果”混在一起，第一次成功还好，一旦重试就会出现旧结果覆盖新结果、错误原因找不到、交接字段格式不统一等问题。

还有一个容易被忽略的点：workspace 不是装饰。scratch 适合临时任务，完成后清理；dir:<path> 适合共享目录，比如内容生产工作区或运维资料库；worktree 适合代码任务，让不同卡片在独立分支上工作。任务系统如果没有工作区模型，就只能靠口头约定“文件放哪儿”，这在多 worker 并行时很快会乱。

状态机为什么是 Kanban 的第一性原理

普通待办列表只回答“现在做没做”。Kanban 回答的是“任务处在哪个生命周期”。Hermes 官方给出的状态链是 triage → todo → ready → running → blocked / done → archived。状态名字本身不复杂，真正有价值的是转移规则：父任务完成后，子任务才能从 todo 自动推进到 ready；worker 请求帮助时，任务进入 blocked；人工解除阻塞后，系统再开一轮新 run。

这意味着依赖推进不靠人记忆。工程流水线里常见的 schema → API → tests，内容生产里的 analyst → writer → revise → publisher，都可以被建成任务图。只要前置任务真的完成，下游就能自动进入可执行状态。

# 建一个父子依赖链，让状态机自己推进
SCHEMA=$(hermes kanban create "Design auth schema" --assignee backend-dev --json | jq -r .id)
API=$(hermes kanban create "Implement auth API" --assignee backend-dev --parent $SCHEMA --json | jq -r .id)
TEST=$(hermes kanban create "Write auth tests" --assignee qa-dev --parent $API --json | jq -r .id)

# 观察：只有第一个任务先 ready，后两个先停在 todo
hermes kanban show $SCHEMA
hermes kanban show $API
hermes kanban show $TEST

这个设计解决了一个很实际的代价问题：当任务链超过三步，靠人手工提醒下一个角色很容易漏。漏一次，后续任务就空转；漏到第二天，整个链路的上下文又要重新捞。Kanban 把“谁能开始做”变成系统行为，而不是聊天记录里的约定。

triage 和 todo 的区别也值得单独说。triage 更像“想法停车场”，适合放一句话需求，后续由规格器或 orchestrator 补成可执行任务；todo 则表示任务已经成形，只是还不能执行，常见原因是父任务没完成。ready 才是调度器真正会认领的队列。这个分层避免了一个常见坏习惯：把模糊想法直接派给 worker，让它边猜边做。猜错一次，不只是浪费模型调用，还会污染后面的任务链。

blocked 也不是失败的同义词。它表示“系统知道自己缺什么”。缺凭据、需要人选方案、审查意见未处理，都应该进入 blocked，而不是让 worker 在 running 里空耗。等人类补了信息，再 unblock，任务会带着历史重新开始。这比在聊天里说“你再试试”清楚得多。

Worker 生命周期：为什么它比“开个子 agent”更可靠

Hermes 的 worker 不是盲跑进程。官方文档规定了清晰生命周期：启动先 kanban_show() 读取上下文，再进入 HERMES_KANBAN_WORKSPACE 工作；长任务期间用 kanban_heartbeat() 证明自己还活着；结束时必须调用 kanban_complete() 或 kanban_block()。如果 worker 以 exit 0 退出，但任务还停在 running，调度器会把它当成协议违规。

这里最有价值的是结构化交接。summary 给人看，metadata 给机器看。下一个 worker 不用翻十几条评论猜“上一个人到底做了什么”，它会从 worker_context 里直接看到父任务结果、之前失败原因和验证信息。

# worker tool calls，不是你在 shell 里运行的命令
kanban_show()
kanban_heartbeat(note="halfway through, 4 of 8 files transformed")
kanban_complete(
  summary="migrated limiter.py to token-bucket; added 14 tests, all pass",
  metadata={"changed_files": ["limiter.py", "tests/test_limiter.py"], "tests_run": 14}
)

注意上面这段特意标成 text，因为它展示的是 worker 的工具调用，不是 shell 脚本。人类使用 CLI，worker 使用工具；这是 Hermes Kanban 的基本分工。把两者混在一起，最容易写出“看似能复制、实际跑不通”的文章示例。

为什么 worker 不直接 shell 执行 hermes kanban complete？官方文档给了三个原因：后端可移植性、避免 shell quoting 脆弱性、以及更好的结构化错误处理。尤其是在 Docker、Modal、SSH 这类远程 terminal 后端里，shell 可能跑在容器内部，那里未必有 Hermes CLI，也未必挂载了本机的 kanban 数据库。kanban_* 工具运行在 Agent 进程里，能稳定访问同一套看板层。

这也是 summary 和 metadata 必须认真写的原因。summary 不需要长，但要让人一眼知道结果；metadata 则适合放 changed_files、tests_run、decisions、residual_risk 这类字段。下游 worker 不应该从自然语言里猜“测试到底有没有跑”，而应该直接读到结构化字段。

调度器怎么兜底：任务为什么不容易无声消失

Kanban 真正拉开差距的地方，是它把失败也建模了。官方文档列出几类关键故障模式：Claim TTL 默认 15 分钟；调度器默认每 60 秒 tick 一次；连续失败达到 kanban.failure_limit 默认 2 次会触发熔断；运行超过 stale 超时且近一小时没有 heartbeat，会被回收；assignee 长时间不可解析，会被诊断为 stranded_in_ready。

这不是锦上添花。多 Agent 流水线最怕“任务没了，但没人知道为什么”。在 Kanban 里，失败会变成事件：spawn_failed、crashed、timed_out、gave_up。下一位接手的人看到的不是一个沉默的空洞，而是“第三次因为缺凭据 gave_up 了”。

# 演示熔断器：连续失败 3 次后自动阻塞
hermes kanban create "Deploy to staging (missing creds)" /
  --assignee deploy-bot --max-retries 3
hermes kanban runs t_xxxx
# 预期会看到：spawn_failed -> spawn_failed -> gave_up

这类机制对运维和工程任务尤其重要。部署缺凭据、迁移 OOM、worker 进程退出、profile 名拼错，都会在普通聊天式协作中变成“好像没人继续做了”。Kanban 至少能让故障可见，并给重试 worker 留下足够上下文。

Claim TTL 和 heartbeat 解决的是两类不同问题。TTL 防止 worker 认领后失联；heartbeat 防止长任务被误判成陈旧任务。官方文档强调，如果任务可能运行超过一小时，worker 至少每小时发一次 heartbeat。这个规则看似繁琐，但对长时间编码、批量转码、数据迁移很关键：系统既不能让死任务永远占着 running，也不能因为模型一次调用耗时太久就误杀正常任务。

熔断器解决的则是“反复失败还不断重试”的问题。--max-retries 3 的含义不是“无限努力三轮以后再说”，而是第三次连续失败时进入 gave_up，把任务转为 blocked，让人处理根因。对缺凭据、profile 环境坏掉、外部服务不可用这类问题，继续烧 token 没意义，暴露给人反而更快。

Worker Lane：Kanban 只定义生命周期，不绑死执行器

Hermes 官方把 Worker Lane 定义为“调度器可路由到的一类进程”。Kanban 负责生命周期和审计，Lane 负责执行；Reviewer 负责判断是否真的能算 done；GitHub PR 只是某些代码任务的可选产物。

默认 lane 是 Hermes profile：assignee 对应 profile 名称，调度器用 hermes -p <assignee> chat 拉起 worker，并注入 HERMES_KANBAN_TASK、HERMES_KANBAN_WORKSPACE、HERMES_KANBAN_RUN_ID 等环境变量。Orchestrator profile 则更像路由器，只负责拆任务和连依赖，不应该亲自实现。

# Profile lane 的最直观用法：任务 assignee 直接写 profile 名
hermes kanban create "撰写发布说明" --assignee writer
hermes kanban create "审校发布说明" --assignee revise

# Orchestrator lane 更像路由器，只做拆解
hermes kanban create "拆解调研任务图" --assignee orchestrator

这里也要避免过度想象。官方 worker lanes 文档明确说，Codex、Claude Code、OpenCode 这类外部 CLI lane 尚未形成成熟路径。spawn_fn 可以插拔，但退出码如何映射为 complete / block、工作区怎么隔离、认证怎么处理，都还需要各自设计。今天如果你要稳定落地，最现实的起点仍然是 profile lane。

从工程治理角度看，Lane 的价值在于把“谁来做”从模型提示词里拿出来，变成 assignee 和 profile 配置。writer、revise、publisher 可以有不同模型、工具集、技能和记忆；任务只需要声明 assignee。这样一来，编排器不必在每张卡片里重复描述角色能力，也不会把审校任务误交给发布角色。profile 名写错时，系统也会把任务诊断为无法解析的 assignee，而不是悄悄交给某个默认 Agent。

Kanban vs delegate_task：什么时候该重，什么时候该轻

这篇文章只做一个横向对比，因为它最实用。官方已经把边界写得很清楚：delegate_task 是 RPC 风格的 fork → join；Kanban 是持久化消息队列 + 状态机。前者适合“帮我想一下，然后把答案回给我”；后者适合“这件事可能跨人、跨天、跨角色，还得留下轨迹”。

评判维度	delegate_task	Kanban
形态	RPC 调用，fork 后等待返回	持久化消息队列 + 状态机
父级是否阻塞	是，父 agent 等结果	否，create 后可继续做别的事
子级身份	匿名子 agent	具名 profile，有独立配置和记忆
可恢复性	父进程丢了，子任务也难保	崩溃可回收，阻塞可解除后重跑
人工介入	不适合中途插手	可评论、阻塞、解除阻塞
审计追踪	主要留在上下文里，压缩后易丢	永久保存在 SQLite 行中
适用场景	短推理、并行分析、马上要答案	跨角色、跨回合、需审查、需留痕

# 选型规则，直接写成代码会更清楚
scenario = {
    "need_answer_now": True,
    "need_human_input": False,
    "need_audit_trail": False,
    "survive_restart": False,
}

choice = "delegate_task" if scenario["need_answer_now"] and not scenario["need_human_input"] else "kanban"
print(choice)  # delegate_task

一句可执行结论：需要子任务立刻回答案继续推理，用 delegate_task；任务要跨 Agent 边界、要持久化、要人工介入、要审计，用 Kanban。两者并不冲突，官方也支持 Kanban worker 内部再调用 delegate_task。

实际使用时，可以把两者组合起来。比如 Kanban 卡片交给 researcher profile，researcher 在自己的 run 里用 delegate_task 并行查三个角度，汇总后再通过 kanban_complete 写回结构化结果。这样，短推理仍然保持轻量，长期协作仍然有持久记录。不要为了“统一架构”把所有小问题都变成卡片，也不要为了省事把一条跨天流水线塞进一个父 Agent 的上下文里。

四个经典场景：为什么普通待办列表撑不住

官方教程给了四个典型场景。第一类是父子依赖链，比如 schema → API → tests；第二类是多角色并行拉活，比如 translator / transcriber / copywriter 同时处理一批任务；第三类是“实现 → 审查 → 打回 → 修复 → 再审查”；第四类是熔断器和崩溃恢复。

这些场景共同指向一个问题：普通待办列表只能记录“有这么个任务”，很难记录“上一次怎么失败、谁做了什么、下一次从哪里继续”。Kanban 的 run history 和 metadata 正是为这个缺口设计的。

# 场景三的核心闭环：阻塞 -> 解除阻塞 -> 重试
kanban_block(reason="Review: password strength check missing, reset link isn't single-use")
# 人工解除阻塞后，新 worker 启动
kanban_show()
kanban_complete(
  summary="added zxcvbn strength check, reset tokens are now single-use",
  metadata={"review_iteration": 2, "tests_run": 11}
)

最值得注意的是第三个场景。Reviewer 打回后，任务不是“失败结束”，而是进入 blocked。人类或 reviewer 解除阻塞后，系统会为同一张卡片创建新 run。第二个 worker 启动时，worker_context 已经包含上一次阻塞原因，所以它可以直接修复问题，而不是重新阅读全部规格说明。

这套机制对内容生产也同样适用。analyst 产出大纲，writer 写初稿，revise 核验事实与代码，publisher 渲染图表并发布。每个角色都只需要对自己的交付负责，但下游能读到上游的摘要和机器字段。审校发现引用链接不真实时，可以 block 而不是硬改；writer 补完来源后再 unblock，系统保留两次 run 的差异。对团队来说，这比“在群里喊谁改一下”更可追踪。

九种协作模式，别一上来就把 Kanban 用重了

官方还总结了 P1 到 P9 九种协作模式，覆盖扇出、流水线、投票、长期日志、人工介入、@mention、批量任务和分诊规格化。这说明 Kanban 不是只适合工程任务，它更像一个多 Agent 协作骨架。

但骨架不等于所有任务都要上看板。我的建议是先从 P2 流水线和 P5 人工介入入手。这两类最容易直接体现价值，也最能让团队理解“为什么这不是另一个待办列表”。P1 批量扇出适合内容工厂和数据处理，P9 适合把模糊想法先规格化再分发。

# 一个最小的模式选择器：按需求选协作模式
requirements = {"parallel": True, "human_review": False, "long_running": False}
if requirements["parallel"] and not requirements["human_review"]:
    pattern = "P1 扇出"
elif requirements["human_review"]:
    pattern = "P5 人工介入"
else:
    pattern = "P2 流水线"
print(pattern)

这里的取舍很简单：如果任务会形成明确的上下游，就从流水线开始；如果经常需要人拍板，就把 blocked → unblock 做成正式流程；如果只是把一个问题分给另一个模型想十分钟，Kanban 多半太重。

P3 投票聚合适合主观判断强、单个模型容易偏的任务，比如候选标题评审、方案风险识别；P4 长期日志适合日报、巡检、知识库维护；P8 批量任务适合对一组对象重复执行同一流程。不要被模式数量吓到，它们本质上都是三件事的组合：并行、依赖、人工介入。先把这三件事想清楚，再选模式。

什么时候别用 Kanban

Kanban 很强，但不是默认答案。官方文档把边界讲得很明白：它是单主机设计，底层是本地 SQLite，不支持跨两台机器共享一个看板；默认调度 tick 是 60 秒，所以它不是实时系统；外部 CLI worker lane 还不成熟；跨看板依赖也不支持。

# 先用最小命令检查你的场景是否适合 Kanban
hermes kanban boards list
hermes profile list
hermes kanban stats

如果只是“帮我查一下”或“把这个段落改短一点”，Kanban 会显得过重。它的优势在于复杂协作，而不是微任务分发。越短、越即时、越不需要交接的任务，越应该避免拉进看板。

还有一种情况也不适合：你还没有定义清楚“完成”的标准。Kanban 可以承载模糊需求的规格化过程，但不能替你把所有含糊话都变成正确任务。如果卡片标题只有“优化系统”，body 也没有验收条件，worker 很可能产出一堆看似勤奋的动作。更好的做法是先把它放进 triage，让规格器补齐范围、约束和验收，再进入 todo。

趋势：Hermes 正在把 Kanban 做成默认协作底座

从官方资料看，Kanban 已经不是边缘功能。一个明显信号是，调度器从独立 daemon 收回到了 Gateway 内嵌，官方文档直接把单独的 hermes kanban daemon 标为弃用；另一个信号是 auto_decompose 已经进入正式配置项，可以自动把 triage 里的粗略任务分解成任务图。

# 与趋势直接相关的最小配置
kanban:
  dispatch_in_gateway: true
  dispatch_interval_seconds: 60
  auto_decompose: true
  auto_decompose_per_tick: 3

这背后的方向很明确：Hermes 希望把“多 Agent 持久化协作”做成基础能力，而不是一个旁路工具。对使用者来说，最现实的意义是，以后设计工作流时，先想任务图、交接和审查，再想要不要额外 spawn 一个 agent。

多 Board 也是这个方向的一部分。单个 default 看板足够个人使用，但团队一旦把工程、内容、运维都放进去，噪音会迅速变大。按项目或领域拆 Board，可以让任务、workspace 和日志天然隔离。官方文档也明确说，不允许跨 Board 链接任务，这个限制换来的是更简单、更可控的边界。

最小实现

如果你想真正感受 Kanban 的价值，最小可跑通的办法不是先看 Dashboard，而是先建一条最短依赖链。下面这套命令满足三个条件：第一，命令来自 Hermes CLI；第二，依赖关系真实写入看板；第三，预期状态可以用 hermes kanban show 直接观察。

我在本机做过基础验证：hermes kanban create --help 支持 --parent、--json、--max-retries 等参数；本机可见 writer、revise、publisher 等 profile；实际创建过一条链路，三个任务状态分别为 ready / todo / todo，符合“只有无父依赖任务先 ready”的规则。该验证不等同于等待整条发布流水线跑完，它验证的是最小任务图可创建、可观察、可进入调度。

跑这段命令前，先确认三件事：jq 已安装；hermes profile list 能看到你写在 assignee 里的 profile；Gateway 已启动或准备启动。没有 Gateway，ready 任务会留在原地，不会自动认领。这不是错误，而是调度器没在跑。你也可以先只执行创建和 show，确认依赖状态正确，再启动 Gateway 观察后续事件。

#!/usr/bin/env bash
set -euo pipefail

# Step 1 — 初始化看板，并确保 Gateway 运行
hermes kanban init
hermes gateway start

# Step 2 — 创建一条最小流水线
T1=$(hermes kanban create "编写README" --assignee writer --json | jq -r .id)
T2=$(hermes kanban create "审校README" --assignee revise --parent "$T1" --json | jq -r .id)
T3=$(hermes kanban create "发布到公众号" --assignee publisher --parent "$T2" --json | jq -r .id)

# Step 3 — 查看状态。预期：T1 ready，T2/T3 todo
hermes kanban show "$T1"
hermes kanban show "$T2"
hermes kanban show "$T3"

# Step 4 — 观察事件流与运行历史
hermes kanban runs "$T1"
hermes kanban stats

# Step 5 — 如需人工介入，可在任务 blocked 后解除阻塞
# hermes kanban unblock <task_id>

预期效果如下：

1. T1 会先进入 ready，等待调度器认领。

2. T2 和 T3 因为有父依赖，会先停在 todo。

3. 当 writer worker 完成 T1 并写入 summary / metadata 后，T2 会自动 promoted 到 ready。

4. 如果中途某个 worker 调用 kanban_block(reason=...)，任务会进入 blocked；人类解除阻塞后，系统开启新的 run，而不是覆写旧记录。

如果你要把它用于真实团队，我建议再加两条约束：所有 worker 完成时必须写清 summary 和可机器读取的 metadata；涉及代码变更的任务，先用 kanban_comment 写入 changed_files / tests_run / diff_path，再以 review-required: 前缀阻塞，等待 reviewer 放行。这样看板才不会退化成“状态很多的待办列表”。

这段最小实现里最容易误解的是 Step 4。hermes kanban runs "$T1" 只有在 worker 被调度并产生 run 后，才会看到真正的运行历史；刚创建完任务时，它可能还没有 run。这很正常。你可以用 hermes kanban watch 观察事件流，或者在 Dashboard 里点击卡片，看它从 ready 到 running，再到 done 或 blocked 的变化。

落地前的流程设计清单

真正把 Kanban 用起来之前，最好先画任务图，而不是急着创建卡片。我的经验是先问五个问题：这条流程的入口是什么？哪些步骤能并行？哪些步骤必须等父任务完成？哪里需要人类判断？每个 worker 完成时必须留下哪些字段？这五个问题答不清，任务一多就会乱。

# 一个更像真实团队的创建顺序：先研究，再写作，再审校，再发布
R1=$(hermes kanban create "调研官方 Kanban 文档" --assignee analyst --json | jq -r .id)
R2=$(hermes kanban create "核验本地最小链路" --assignee analyst --json | jq -r .id)
W=$(hermes kanban create "撰写 Kanban 指南初稿" --assignee writer /
  --parent "$R1" --parent "$R2" --json | jq -r .id)
V=$(hermes kanban create "审校 Kanban 指南终稿" --assignee revise /
  --parent "$W" --json | jq -r .id)
hermes kanban create "发布 Kanban 指南" --assignee publisher --parent "$V"

这个清单看起来朴素，但能避免两个常见坑。第一，不要把“调研、写作、审校、发布”塞进一张卡片里。那样虽然省了创建任务的步骤，却让每个角色的交付边界变模糊，出问题也不知道该回退到哪一环。第二，不要只写自然语言交接。比如审校任务最好要求 metadata 至少包含 path、checks_run、residual_risk；代码任务最好包含 changed_files、tests_run、diff_path。字段越稳定，下游 worker 越容易自动复用。

对团队管理者来说，Kanban 还提供了一个很现实的观察口：你能看到卡片是堆在 ready，还是堆在 blocked。前者通常说明 worker 资源或 profile 配置不够；后者通常说明需求、凭据、审查规则或外部依赖没有提前准备好。这比只看“完成了多少任务”更有诊断价值。多 Agent 协作的瓶颈经常不在模型，而在流程设计。

还有一个小建议：先用一条低风险流程试运行，不要一上来就接核心生产链。比如先做“资料采集 → 初稿 → 审校”的内容流水线，确认 profile 能被调度、workspace 路径正确、summary 和 metadata 能被下游读到，再把代码发布或运维任务放进来。Kanban 的优势是可恢复，但前提是每个角色真的按协议收尾。只要有一个 worker 习惯性不写交接，整条链路的可审计性就会被拉低。

对复杂项目，建议把“验收标准”写进父任务 body，而不是只写在聊天里。下游 worker 只能稳定读取看板里的任务正文、父任务交接、评论线程和运行历史；聊天上下文可能已经压缩或不在当前 worker 的会话中。把验收标准沉到卡片里，才能保证每次重试看到的是同一份规格。

最后，定期清理也要纳入流程。done 不等于永远留在主视图里，适时 archive 可以降低看板噪音；长期需要复盘的内容，则应该沉到文档或知识库，而不是让看板同时承担执行系统和知识库两种职责。Kanban 负责当前工作流的真实状态，长期知识应有自己的归档位置。

如果团队里有多个看板，最好约定命名规则和归档周期。比如按项目 slug 建 Board，按季度归档完成任务，跨项目只在正文里引用任务 id，不强行建立依赖。规则越简单，越容易长期执行。

先把小流程跑顺，再扩展。别急上生产，先留证据和回滚口，会更稳妥可靠。

结尾：把 Kanban 当成协作操作系统，而不是另一个待办列表

Hermes Kanban 最值得带走的，不是“它能开很多 Agent”，而是它给多 Agent 协作补上了三个一直缺的东西：状态、交接和恢复。任务出了问题，你知道它卡在哪；worker 崩了，你有 run history 可追；人要插手，你有 blocked → unblock 这条正式通道。

如果今天就要做选择，我建议按这个顺序判断：先问任务会不会跨角色、会不会跨回合、会不会需要人复核；只要有两个答案是“会”，Kanban 大概率比临时拼子 agent 更稳。剩下的优化，都是在这个底座上慢慢长出来的。

边界说明

1. 本文引用的“默认 60 秒调度 tick、默认 failure_limit=2、Claim TTL 15 分钟、stale 回收阈值 4 小时、stranded 阈值 30 分钟”等数字，来自 2026-07-14 抓取的官方文档快照；后续版本如有调整，请以官方在线文档为准。

2. 本文提到外部 CLI worker lane（如 Codex / Claude Code / OpenCode）尚未成熟，依据的是官方 worker lanes 文档对 issue #19931 与 PR #19924 的描述；本文不额外推断后续路线图。

3. 最小实现部分验证的是“任务图可创建、依赖状态符合预期、命令参数存在”。它不是一次完整的真实发布流水线复盘；真实执行还取决于本机 profile、Gateway 和模型配置。

引用来源

1. Hermes Kanban 官方参考文档 — Nous Research — official — https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban[1]

2. Hermes Kanban 官方教程 — Nous Research — official — https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban-tutorial[2]

3. Hermes Kanban Worker Lanes 官方文档 — Nous Research — official — https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban-worker-lanes[3]

4. Hermes Agent GitHub Issue #19931 — Nous Research — official — https://github.com/NousResearch/hermes-agent/issues/19931[4]

5. Hermes Agent GitHub Pull Request #19924 — Nous Research — official — https://github.com/NousResearch/hermes-agent/pull/19924[5]

这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

👇👇扫码免费领取全部内容👇👇

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 2026行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

7. 资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇