Vibe Kanban：并行编码代理的看板指挥中枢，以及它的关停与开源归宿

当编码代理（coding agent）从玩具变成生产力工具，瓶颈从”写不出代码”变成”同时管不过来多个代理”。Vibe Kanban 就是为这个阶段设计的指挥层：用看板规划问题，为每个代理分配一个 git worktree 工作区（独立分支、终端、开发服务器），在 UI 内评审 diff、内联评论、预览应用并发起 PR。官网曾宣称已有 30,000+ 活跃用户、累计创建 10 万个 PR；GitHub 仓库 BloopAI/vibe-kanban 调研时约 28.4k stars、Apache-2.0。值得单独记下的是它的结局：2026 年 4 月 10 日，背后公司 bloop 关停，项目转为开源、社区维护。本文基于官网、仓库 README 与官方关停公告做客观分析。

一、背景：瓶颈从写代码转向规划与评审

官网”Why we’re building this”给出的判断是：旧世界软件交付速度受限于工程师逐个任务顺序推进；新世界里代理并行处理无穷任务，但人仍然需要规划与评审，于是交付速度被人的规划/评审速度卡住。单代理工作会产生大量空等（等这一个代理干完再切下一个），Vibe Kanban 的解法是把工作拆成多条流、并行跑多个代理，人的注意力在”准备好评审的那一个”之间切换。这也是它与 Worktrunk 等轻量 worktree 工具的差异：它把看板、并行调度、代码评审打包成一个集成产品。

二、是什么：看板问题 + 工作区 + 评审三件套

按 README 的功能清单：

• Plan with kanban issues：在看板上创建、优先级排序、指派问题，可私有可团队共享；
• Run coding agents in workspaces：每个工作区给代理一个分支、一个终端、一个 dev server；代理列表覆盖 Claude Code、Codex、Gemini CLI、GitHub Copilot、Amp、Cursor、OpenCode、Droid、CCR、Qwen Code 等 10+ 编码代理，可随时切换而不被单一厂商锁定；
• Review diffs and leave inline comments：在 UI 内评审差异并直接把反馈发回代理；
• Preview your app：内置浏览器，带 devtools、inspect 模式与设备模拟，可点击编辑组件；
• Create pull requests and merge：用 AI 生成的描述开 PR，在 GitHub 评审后合并。

安装即一条命令：npx vibe-kanban（官网要求 Node.js 18+，先完成所用代理自身的登录认证）。

三、技术机制：worktree 隔离与并行流

底层隔离机制是 git worktree：每个代理在独立工作区（独立分支副本）工作，互不冲突，这与同类并行方案共享同一机制；Vibe Kanban 在其上加了任务编排层：看板卡片触发工作区、自动创建 worktree 并运行 setup 脚本、跟踪代理会话状态。任务分解模型如上图：一个父问题拆成多条并行代理流，各自产出改动后再汇合合并。

评审环节是其差异化重点：不切到终端看日志，而是在面板内看逐文件 diff（如图中 LandingPage.tsx 的组件替换），可内联评论，反馈直接回传给对应代理，再由代理继续修改。

四、关键数据与口径

注意：用户数与 PR 数为官网自报，无第三方独立统计；截图中的改动行数均为产品演示。

五、评测方法：名人背书不等于量化效率

官网引用了 ElevenLabs 增长负责人 Luke Harries、ML 工程师 Hamel Husain、T3.chat CEO Theo、Google AI 总监 Addy Osmani 等人的好评，但这些均为主观推荐语，没有提供对照实验、任务完成时间或评审缺陷率等量化对比。“自 Cursor 以来最大的生产力提升”这类说法属于主观证言，不能当作效率证据。

六、适用与不适用场景

适合：

• 同时驱动多个编码代理、需要统一规划与评审入口的个人开发者；
• 想在 Claude Code / Codex / Cursor 等代理之间灵活切换、避免绑定单一工具流的团队；
• 需要内联评审、内置预览、看板状态自动同步的中小团队。

不适用：

• 依赖云端团队协作（issues、评论、组织）的团队——远程服务已移除（见局限）；
• 期待厂商持续商业运营与长期路线图的企业；
• 只需要单代理轻量任务切换的用户，看板层反而偏重。

七、客观分析：优势与局限

优势：

1. 切中规划/评审瓶颈：把人从盯终端日志解放到规划与质量把控，工作流闭环完整；
2. 代理中立：10+ 编码代理可切换，SOTA 快速迭代时不必换工作流；
3. worktree 隔离避免冲突：并行代理互不踩踏，diff 评审回归人性化；
4. 开源本体仍可本地运行：Apache-2.0，本地工作区关停后继续可用。

局限与官方口径（必须如实写出）：

1. 公司已关停，云端协作服务已下线：2026-04-10 公告明确，远程服务（看板 issues、评论、项目、组织）在关停公告后保留 30 天即移除，产品转向完全本地架构；官方明确”本地工作区继续工作”，但云端团队协作能力不复存在；
2. 商业模式失败是关停根因：公告原话”绝大多数是免费用户，我们找不到一个自己兴奋的商业模式”，这不是技术失败而是商业化失败，选型时须意识到无公司主体持续维护；
3. 未来靠社区维护：官方称将在数周内发布社区维护版路线图，但维护强度、兼容性跟进（跟随各代理协议变化）存在不确定性；
4. 效果主张缺量化：官网好评均为名人主观证言，无对照实验数据；
5. 迁移惯性成本：已深度融入现有平台工作流的团队，换工具仍有学习与切换成本，这与 Koala 点评的判断一致——集成完整也意味着更高学习成本与一定锁定；
6. 数据迁移窗口：最新版本提供数据导出，错过 30 天窗口且未导出者，云端历史不可恢复。

八、它意味着什么

Vibe Kanban 是”代理编排层”赛道的早期先行者：官方公告称其在 2025 年 6 月首发时率先落地多代理支持、diff 评论、实时预览、点击编辑、远程访问等如今被视为标配的能力。它的关停不证明方向错误，而是说明在个人/小团队市场，编排工具本身很难独立收费。对当下用户：本地开源版仍可用于个人并行代理工作流，但不应再把它当作有商业支撑的团队协作平台；对行业：它留下的”看板 + worktree + 内联评审”范式已被各类代理 IDE 与平台吸收。

参考来源

• Vibe Kanban 官网
• GitHub: BloopAI/vibe-kanban（README 与功能清单）
• 官方关停公告：Goodbye bloop（2026-04-10）
• Koala 项目库条目 #1526