想象一下：你把一个大任务拆成 5 张卡片，5 个 agent 并行开工。每个人都按时交活了，但合到一起你发现——同一个设计问题出现了两种答案，一个文件被反复改出冲突，而代码质量更是没人把关，因为根本没有“评审”这个环节。这正是 kanban 多 agent 协作最痛的地方。2026 年 8 月 10 日合并的一批 PR（#83412、#83423、#83424、#83428）给 Hermes kanban 补上了第一等的评审生命周期，还顺手加了三条防混乱的护栏。这篇文章带你完整走一遍：从提交评审到评审者打回，再到“一个问题只有一个决策者”和“冲突热点标记”。

评审闭环：实现者 → 评审泳道 → 三种判决

现在 kanban 卡片有了正式的评审阶段。实现者干完活，用 kanban_request_review 提交评审：

kanban_request_review(
  task_id="T-42",
  summary="实现了导出功能，并用 3 个样例文件验证通过",
  reviewer="code-reviewer"    # 可选
)

summary 必填——描述做了什么、怎么验证的，评审者要靠它建立上下文；reviewer 可选；提交内容会自动脱敏。卡片随即进入 review 泳道，由评审者 profile 领取，评审者会自动加载 sdlc-review 技能，并给出三种判决：

判决	动作	含义
通过	kanban_complete	验收标准满足，任务收尾
打回	kanban_comment + kanban_request_changes(reason=...)	有可修正的缺陷，卡片回到原实现者
升级	kanban_block	需要人来决策，或外部前置条件未满足

来源信息（provenance）会被保留：卡片被打回、实现者改完再提交评审时，只要没指定新的 reviewer，就会路由回同一个评审者，不会随机换人，评审上下文是连续的。

评审视角轮换：第 1 轮冷读，第 2 轮跑起来，第 3 轮对合同

sdlc-review 技能还有一个很实用的设计：每一轮评审换一个视角，而不是重复同一套检查。轮次怎么算？就是历史 changes_requested 的次数加一（第 1 轮 = 0 次打回，第 2 轮 = 1 次，以此类推）：

• 第 1 轮 Artifact（产物）：先不看实现者的总结，冷读 diff 或交付物，形成独立判断，再对照总结找不一致；
• 第 2 轮 Execution（执行）：checkout 出来用 terminal 实际跑一遍，构建、测试、复现声称的行为，逐个验证；
• 第 3 轮起 Contract（合同）：回到卡片原始的验收标准逐条核对，同时确认上一轮 request_changes 提出的每一条都真的落地了。

用 delegate_task 临时并行派多个评审时同理：给每个评审不同的 brief（一个只看 diff、一个看全上下文、一个跑起来验证），而不是发一模一样的任务——一样的 brief 只会得到高度相关的重复结论，不同的视角才能覆盖更多缺陷类型。

护栏一：决策所有权——一个问题只能有一个决策者

并行协作最常见的翻车方式是“分裂脑”：两个 worker 各自独立想出了同一个设计问题的不同答案。KANBAN_GUIDANCE 里新增的决策所有权契约直接堵住这条路：

• 设计决策属于 orchestrator，必须在分发任务之前定好；
• 任何两张子树卡片都不得各自决定同一个问题；
• 每张子卡片的 body 里必须写明它依赖的决策——因为 worker 看不到兄弟卡片的上下文。

文档里的例子很形象：一张 exporter 卡片、一张 importer 卡片，不能各自“发明”文件格式——orchestrator 先定好格式，写进两张卡片的 body，两个 worker 各按各的写，最后合起来才不会打架。

护栏二：冲突热点——标记，而不是叠罗汉

并行改同一个文件，冲突在所难免。新约定是：worker 发现自己要改的文件反复被兄弟卡片改出冲突时，用 kanban_comment 以 hotspot: 开头留言（比如 hotspot: src/config.py — 三张卡都在改这个文件），并在完成元数据里带上这个标记；orchestrator 看到同一路径被标记 2 次以上，就先创建一张“拆分”卡片，把这块烫手山芋单独拆出去，再继续派其他活。已经发生的冲突，则交给 merge-reconciler 去仲裁。

小结

这一整套东西让 kanban 从“派活—收活”变成了完整的开发闭环：有评审、有轮换视角、有决策归属、有冲突预警。适合的场景很明确——多个 agent 并行协作、需要质量把关的代码仓库；单个 agent 干小活用不上这么重的流程。想了解 kanban 的完整命令面，可以看 hermes-kanban 命令参考；想知道多 agent 场景下还有哪些协作约定，可以看我们写过的 AGENTS.md 目录链。