Agent 越会写代码，你越需要一块看板

你创建了 5 张 Agent 任务卡，以为系统会自动开干。

结果过了十分钟，什么也没发生。

不是模型不行，也不是任务拆得不够细。问题更尴尬：卡片创建，不等于任务执行。

这就是我这两天把文案线从 TASK_BOARD.md + inbox/active/done 文件流迁到 Hermes Kanban 时，最直接的体感。

以前我们用 Markdown 看板管 researcher、writer、coder。任务从 inbox 移到 active，再从 active 移到 done。听起来很朴素，也确实能跑。但一旦任务变多，问题马上冒出来：状态同步靠人记，交付物路径靠人写，谁能开始、谁在等审核、谁依赖谁，经常要翻半天聊天记录。

换成 Kanban 以后，事情并没有神奇地全自动。恰恰相反，我更清楚地看到一个事实：

Agent 越会干活，越需要一套严肃的任务面板。

多 Agent 的难点，已经不只是“让它写代码”。而是它写完之后，谁来审？失败之后，谁来接？上游没交齐素材，下游凭什么开工？任务卡完成了，交付物有没有真的落盘？

这才是 2026 年 Agent 工具真正开始分化的地方。

瓶颈换地方了

Vibe Kanban 的 README 里有一句话很准：Your Engineering Bottleneck Has Shifted。

过去，工程瓶颈在编码速度。

你有一个需求，开发者理解、写代码、调试、提 PR。AI 编码工具出现后，很多环节被加速了。Claude Code、Codex、Cursor Agent、Gemini CLI 这类工具，已经能承担相当一部分实现工作。

但加速之后，新的瓶颈露出来了。

不是没人写代码，而是没人稳定地规划、分发、审查、合并、回滚。

这也是为什么 Vibe Kanban 这种工具会火。它不是又一个聊天框，而是把编码 Agent 放进任务面板里：一个 issue 可以启动一个 agent workspace，配 git worktree、终端、预览和 diff review。人不再守着一个对话框等回答，而是像管理一组实习生一样管理 Agent。

截至这次调研，Vibe Kanban 在 GitHub 上大约 26.2k stars。更有意思的是，bloop 公司已经在 2026 年 4 月宣布关闭，但 Vibe Kanban 项目继续开源、社区维护。

这件事本身就很说明问题：商业模式未必跑通，但需求是真的。

当 Agent 可以并行写代码，“人类坐在聊天框前逐条追问”的交互方式就开始显得落后。

四种解法，其实在回答同一个问题

今天市场上看起来有很多 Agent 产品，名字不同，定位不同，但它们背后在回答同一个问题：

多 Agent 并行工作时，到底谁来协调？

大致可以分成四类。

Vibe Kanban 的答案是：让一个人拥有一组 Agent。

它更像“个人 Agent 公司模拟器”。你是 operator，Agent 是执行者。每张任务卡都可以启动一个独立 workspace，跑代码、开 dev server、看 diff。它解决的是个人开发者在多 Agent 并行时的失控感。

Multica 的答案更激进一点：让 Agent 成为团队成员。

它把 Agent 放进 assignee、评论区、issue 生命周期里，强调 Agent 和人共享同一个任务系统。它不是让你一个人同时操控多个 Agent，而是试图让团队把 Agent 当作真正的协作者。GitHub 上 27.8k stars 的热度，也说明这个方向不只是玩具。

Manus 则是另一条路。

它不是一个 Agent 看板，而是一个通用 Agent 执行器。它有自己的虚拟计算机，可以规划、执行、交付结果。它的思路不是“给 Agent 配一块外部看板”，而是让 Agent 内部自己完成任务分解和并行处理。

Hermes Kanban 的位置又不一样。

它不是给普通用户点点点的独立产品，而是 Agent 框架里的任务编排原语。任务是数据库里的记录，worker 是有身份的 profile，handoff、comment、block、complete 都进入持久化状态。它解决的是多 profile 长链路协作：researcher 先调研，writer 再成稿，default 最后审核发布。

所以，不要把这四种方案硬放在一张“谁赢谁输”的排行榜上。

同一个问题，有四种答案。选错答案，比不用 Agent 更麻烦。

我这次迁移，真正踩到的是“部分完成陷阱”

这次 Hermes Kanban 迁移，给我最大的提醒不是某个命令怎么写，而是任务状态必须比过去更诚实。

以前文件流里，最容易出现一种假完成：

researcher 交了一个 handoff 摘要，看起来任务完成了；writer 开始写，写到一半才发现原始字幕文件不存在。或者某个任务标记 done，但下游引用的素材路径已经被清理掉。

这不是小瑕疵。

对于多 Agent 流水线来说，摘要不是交付物，状态也不是交付物。

交付物必须落盘。路径必须能读。下游必须知道哪些是已确认事实，哪些只是上游推断。

这也是我为什么把 writer 的权限收紧：writer 可以写发布级成稿、做配图、跑本地预览、检查微信兼容性，但不再直接 git push，也不再直接发布到微信公众号。发布门收回 default，用 content-publishing-gate 统一处理。

看起来多了一步，其实是少了很多扯皮。

以前的问题是“谁顺手谁发”。现在的问题变成“谁有权限，谁负责最后一道门”。边界一清楚，流程反而更快。

Kanban 管状态，不替你存文件

这句话值得单独拎出来。

很多人第一次用任务面板，会有一种错觉：我把卡片建好了，系统就会管理一切。

不会。

Kanban 管的是任务状态、依赖关系、执行历史、审核入口。它不替你保存研究原始材料，不替你判断图片有没有缺失，不替你保证文章真的能构建通过。

这次迁移里，有几个教训很具体：

• 卡片创建 ≠ 自动执行。dispatcher / gateway 是否启动、是否需要老板确认，必须明确。
• blocked 不是失败。review-required 是员工把成果交给 default 审核，而不是自己宣布 final complete。
• parent/child 依赖链很有用，但前提是 parent 的交付物真的完整。
• 删除旧任务或清理目录前，要检查下游引用，不然 writer 会拿着一条失效路径开工。
• 内容通过不等于交付通过。配图缺失、本地预览没跑，都应该打回。

这些听起来不像“AI 时代”的炫技，更像工程管理里的老问题。

但也正因为它老，才更容易被忽视。

Agent 不是把工程纪律省掉了，而是把工程纪律放大了。

什么时候该上任务面板？

不是所有 Agent 任务都需要 Kanban。

如果你只是让一个工具帮你改一段 SQL、解释一个报错、生成一个脚本，聊天框足够。为了这种任务引入看板，是把轻活做重。

但一旦出现下面几个信号，就该认真考虑任务面板了：

1. 任务超过一个角色

比如 research → writing → publish。每个角色的输入、输出、权限都不同。靠一个对话框串到底，很容易上下文污染。

2. 任务需要等待人工审核

代码改完要 review，文章写完要审稿，发布前要确认配图和预览。只要有人类在环，就需要明确的 blocked 状态。

3. 任务有真实交付物

研究报告、图片、文章、代码分支、PR、预览地址。只要下游要消费文件，就不能只靠“我已经完成了”这句话。

4. 任务可能失败后重试

Agent 跑挂、素材缺失、构建失败、审核打回。没有持久化状态，失败就变成聊天记录里的迷雾。

5. 多个 Agent 会并行工作

并行不是同时启动几个窗口。并行意味着依赖、锁、冲突、审核和汇总都要有地方落。

反过来，如果你的任务短、单步、无交付物、无审核、无依赖，就别上看板。直接问，直接改，直接结束。

编排不是越多越高级。能不用编排时不用，才是成熟。

一个可执行的迁移顺序

如果你现在还在用 Markdown 表格、Notion 看板、聊天记录或者手写 TODO 管 Agent，可以按这个顺序迁移，不要一上来就追求全自动。

第一步，先把任务类型分清。

别急着建系统。先列出你团队里最常见的任务链：写代码、查资料、写文章、发版、运维检查。每条链路都要写清楚：谁输入，谁处理，谁审核，最终交付物是什么。

第二步，把“完成”改成“可审核”。

很多团队最大的问题，是 worker 完成后直接 done。更稳的做法是先进入 review-required：我完成了什么、文件在哪里、还有什么风险、需要谁审。

第三步，强制交付物落盘。

不要只写摘要。研究任务要有原始材料，写作任务要有主稿路径，代码任务要有分支或 diff，配图任务要有图片文件。没有文件，就不能让下游开工。

第四步，建立 parent/child 依赖。

不要让 writer 在 researcher 没完成时先写。不要让发布任务在预览没通过时 ready。依赖链的价值，不是让卡片更漂亮，而是阻止错误任务过早启动。

第五步，把发布门收回。

谁都能写，谁都能改，但不是谁都能发。博客 git push、微信公众号发布、生产部署，这类动作应该集中到一个明确角色，最好有统一 gate。

第六步，再考虑自动 dispatcher。

前五步没做稳之前，不要迷信全自动派工。自动启动一个不完整任务，只会更快地制造垃圾。

这套顺序不酷，但有效。

最终变化：人从执行者变成调度者

这不是一句鸡汤。

当 Agent 真的能承担更多执行工作，人类的位置会发生变化。以前你写代码、调试、交付；现在你要拆任务、设边界、审结果、控制发布门。

如果还按旧方式用 Agent，你会陷入一个很荒谬的状态：工具变强了，但你更累了。因为你同时要当产品经理、开发、测试、发布、项目经理，还要记住每个 Agent 刚才说了什么。

任务面板的价值，就是把这些责任显性化。

谁在做？做到哪？等谁审？交付物在哪？失败了怎么恢复？这些问题不解决，多 Agent 就只是多个聊天框。

Vibe Kanban、Multica、Manus、Hermes Kanban 给出的答案不一样，但趋势是一致的：

Agent 时代，真正稀缺的不是执行力，是编排力。

别急着多开几个 Agent。

先把你的任务面板立起来。否则你得到的不是自动化团队，而是一群跑得很快、但没人管交付边界的临时工。