https://blog.cpdd.fyi/tags/kanban/Recent content in Kanban on Zampo BlogHugozh-cnWed, 13 May 2026 15:36:00 +0800https://blog.cpdd.fyi/posts/hermes-kanban-hardcore-guide/Wed, 13 May 2026 15:36:00 +0800https://blog.cpdd.fyi/posts/hermes-kanban-hardcore-guide/<p>你把任务卡创建好了，researcher、writer、coder 也都分配了。</p> <p>然后什么都没发生。</p> <p>这不是 bug。恰恰相反，这是 Hermes Kanban 最容易被误解、也最值得讲清楚的地方：<strong>创建 card，不等于启动 worker。</strong></p> <p>很多人把多 Agent 系统想得太像“开几个聊天窗口”。一个负责调研，一个负责写稿，一个负责代码，大家各干各的。听起来很美，真跑起来就会发现：谁先干？谁等谁？谁审核？交付物放哪？失败了谁接？</p> <p>靠聊天记录和几个 Markdown 文件也能凑合跑。但只要任务链稍微长一点，协作就开始变脆。</p> <p>Hermes Kanban 解决的不是“让 Agent 更聪明”。它解决的是另一个更工程的问题：</p> <p><strong>把 Agent 的工作，放进一条可追踪、可审核、可恢复的流水线里。</strong></p> <p>这篇不讲概念安利，只讲怎么用。</p> <p><img src="https://blog.cpdd.fyi/images/hermes-kanban-hardcore-guide/cover.svg" alt="Hermes Kanban 看板与命令主视觉"></p> <h2 id="先记住一句话kanban-是任务系统不是魔法按钮">先记住一句话：Kanban 是任务系统，不是魔法按钮</h2> <p>Hermes Kanban 是一块持久化的任务板。你可以用它创建任务、分配 assignee、声明 parent/child 依赖、绑定 workspace、记录 comment、阻塞等待审核、完成后给下游传 handoff。</p> <p>它适合管这种任务：</p> <ul> <li>一个任务需要多个 profile 接力，比如 researcher → writer → default；</li> <li>下游必须等上游交付后才能开始；</li> <li>交付物必须有路径、有验证、有审核记录；</li> <li>任务失败后不能靠人翻聊天记录猜状态；</li> <li>你希望 worker 不只是“答一句”，而是按岗位技能执行。</li> </ul> <p>它不适合管这种任务：</p> <ul> <li>你只是问一句命令怎么写；</li> <li>任务几分钟就能完成，没有上下游；</li> <li>没有明确交付物，也不需要审核；</li> <li>你还没把需求想清楚，只是随手丢一个念头。</li> </ul> <p>这也是为什么 Hermes Kanban 的六列看板很重要。它不是装饰，它是任务生命周期。</p> <p><img src="https://blog.cpdd.fyi/images/hermes-kanban-hardcore-guide/inline-01.svg" alt="Hermes Kanban 六列看板示意"></p> <p>六列可以这样理解：</p> <table> <thead> <tr> <th>列</th> <th>含义</th> <th>你该做什么</th> </tr> </thead> <tbody> <tr> <td>Triage</td> <td>原始想法，还不是可执行任务</td> <td>点 Specify，或用 <code>hermes kanban specify</code> 补成任务简报</td> </tr> <tr> <td>Todo</td> <td>任务已创建，但依赖未满足或还没分配</td> <td>等 parent 完成，或补 assignee</td> </tr> <tr> <td>Ready</td> <td>已经可执行，等 dispatcher 或人工 claim</td> <td>检查 gateway/dispatcher 是否在跑</td> </tr> <tr> <td>In Progress</td> <td>worker 已 claim，正在执行</td> <td>看 heartbeat、runs、log</td> </tr> <tr> <td>Blocked</td> <td>等审核、等补料、或断路器触发</td> <td>看 block reason，决定 unblock 还是打回</td> </tr> <tr> <td>Done</td> <td>任务完成</td> <td>看 summary 和 metadata，给下游消费</td> </tr> </tbody> </table> <p>不要小看这六列。多 Agent 协作最大的问题，不是 Agent 不会做事，而是状态没人管。</p>https://blog.cpdd.fyi/posts/agent-task-panel-evolution/Wed, 13 May 2026 12:25:00 +0800https://blog.cpdd.fyi/posts/agent-task-panel-evolution/<p>你创建了 5 张 Agent 任务卡，以为系统会自动开干。</p> <p>结果过了十分钟，什么也没发生。</p> <p>不是模型不行，也不是任务拆得不够细。问题更尴尬：<strong>卡片创建，不等于任务执行。</strong></p> <p>这就是我这两天把文案线从 <code>TASK_BOARD.md + inbox/active/done</code> 文件流迁到 Hermes Kanban 时，最直接的体感。</p> <p>以前我们用 Markdown 看板管 researcher、writer、coder。任务从 inbox 移到 active，再从 active 移到 done。听起来很朴素，也确实能跑。但一旦任务变多，问题马上冒出来：状态同步靠人记，交付物路径靠人写，谁能开始、谁在等审核、谁依赖谁，经常要翻半天聊天记录。</p> <p>换成 Kanban 以后，事情并没有神奇地全自动。恰恰相反，我更清楚地看到一个事实：</p> <p><strong>Agent 越会干活，越需要一套严肃的任务面板。</strong></p> <p>多 Agent 的难点，已经不只是“让它写代码”。而是它写完之后，谁来审？失败之后，谁来接？上游没交齐素材，下游凭什么开工？任务卡完成了，交付物有没有真的落盘？</p> <p>这才是 2026 年 Agent 工具真正开始分化的地方。</p> <p><img src="https://blog.cpdd.fyi/images/agent-task-panel-evolution/cover.png" alt="Agent 任务面板主视觉"></p> <h2 id="瓶颈换地方了">瓶颈换地方了</h2> <p>Vibe Kanban 的 README 里有一句话很准：<code>Your Engineering Bottleneck Has Shifted</code>。</p> <p>过去，工程瓶颈在编码速度。</p> <p>你有一个需求，开发者理解、写代码、调试、提 PR。AI 编码工具出现后，很多环节被加速了。Claude Code、Codex、Cursor Agent、Gemini CLI 这类工具，已经能承担相当一部分实现工作。</p> <p>但加速之后，新的瓶颈露出来了。</p> <p>不是没人写代码，而是没人稳定地规划、分发、审查、合并、回滚。</p> <p>这也是为什么 Vibe Kanban 这种工具会火。它不是又一个聊天框，而是把编码 Agent 放进任务面板里：一个 issue 可以启动一个 agent workspace，配 git worktree、终端、预览和 diff review。人不再守着一个对话框等回答，而是像管理一组实习生一样管理 Agent。</p>