Vibe Kanban：27.8K Star 的「Agent 看板」公司倒闭了——免费用户养不活 Agent 工具，代码留给社区

先讲最扎心的：一个 2.7 万 Star 的项目，怎么死的

2026 年 AI 工具圈最值得反复读的「非技术公告」，是 bloop 创始人 Louis Knight-Webb 4 月 10 日那篇 Goodbye bloop。原文关键段落就三句：

• 「今天我们要关闭 bloop，Vibe Kanban 背后的公司」——公司没了，项目「将以开源和社区维护的形式继续活着」。
• 「成千上万软件工程师每天都在用 Vibe Kanban 通过 coding agent 交付更多东西，但绝大多数是免费用户，我们找不到一个能让我们兴奋起来的商业模式」——不是没用户，是用户不付费。
• 「我们是第一个做多 agent 支持、diff 评论、实时预览、click-to-edit、远程访问的」——这些今天被当成标配的能力，都来自这个项目。

后续处理相当体面：过去 30 天的发票全额退款、订阅全部终止、远程服务保留 30 天后下线、数据导出功能已内置、本地 workspace 继续可用、承诺几周内发布社区版路线图。最后一条 release 是 4 月 24 日的 v0.1.44，npm 包最后修改时间也停在 4 月 24 日——之后仓库再没有新提交，只有 Star 还在缓慢上涨（今天 27,850）。

这故事最值得品的地方：Vibe Kanban 不是没人用，恰恰相反，它是 2025 年 coding agent 工具潮里「用的人最多、付费的人最少」的代表。工具越好用、越能自己跑，用户越觉得「不需要为它付钱」——这个悖论，到今天还在杀死一堆 agent 周边产品。

它是什么：给 coding agent 的「计划 → 执行 → 审查」看板闭环

先给没见过的读者讲清楚 Vibe Kanban 到底做什么。它解决的不是「让 agent 更会写代码」，而是工程里更真实的时间黑洞：工程师在 agent 时代，大部分时间花在规划和审查上。README 原话：「软件工程师把大部分时间花在计划和审查 coding agent 上，想交付更多，最快的路径是让计划和审查更快。」

Vibe Kanban 把这件事做成了三个串起来的环节：

• Plan（看板）：用 kanban issue 规划工作——标题、描述、优先级、标签、父子关系，个人或团队协作。
• Execute（workspace）：点一下创建一个 workspace，Vibe Kanban 自动建 git worktree、开分支、起终端、拉起你选的 coding agent，把 issue 描述当 prompt 直接开干。一个 issue 可以挂多个 workspace，多个 agent 并行跑同一件事的不同方案。
• Review（审查台）：agent 干完活任务自动进 In Review 列，看 diff、在具体行上写评论、合并提交给 agent 让它改，改完再回来。最后开 PR（AI 生成描述）、合并。

全程不用离开浏览器：内置预览浏览器带 devtools、inspect 模式和设备模拟，改完直接看效果。

架构：Rust 33 个 crate + React 前端 + npx 分发

这是典型的「一个产品，三层技术栈」：

类型安全是硬约束：Rust 结构体用 ts-rs 派生 TypeScript 类型（pnpm run generate-types 重新生成），前端拿到的类型和后端是同一份定义。AGENTS.md 里明确写了「不要手改 shared/types.ts」——这份仓库指南本身也是给 coding agent 看的，Vibe Kanban 整个开发流程就是 dogfooding。

核心机制一：executor 抽象——10+ agent 一个接口

Vibe Kanban 支持 10 种 coding agent：Claude Code、OpenAI Codex、GitHub Copilot CLI、Gemini CLI、Amp、Cursor Agent CLI、OpenCode、Factory Droid、Claude Code Router（CCR）、Qwen Code。实现上不是写死的胶水代码，而是两层抽象：

• 每 agent 一个模块：crates/executors/src/executors/ 下 claude.rs / codex.rs / copilot.rs / cursor.rs / droid.rs / gemini.rs / opencode.rs / qwen.rs / amp.rs，各自处理该 CLI 的启动参数、输出解析、权限模式。
• ACP 通道：acp/ 子目录（client.rs / harness.rs / session.rs）实现 Agent Client Protocol——支持 ACP 的 agent 走标准协议接入，不用为每家写专属适配。这是 Vibe Kanban 首创「多 agent 支持」的底层原因。

slash 命令也是动态发现的：选哪个 agent，它就调哪个 agent 的 CLI 探测可用命令（/compact、/init、/review…），TUI 交互类命令（如 /model、/theme）不支持——因为看板 UI 里没有真终端。实测日志里也印证了这套机制：无配置文件时它推荐 QWEN_CODE 作为默认 executor。

核心机制二：diff 审查闭环——评论直接喂回 agent

这是 Vibe Kanban 体验上最「对味」的功能，也解释了它为什么叫「工程师的审查台」而不是「agent 启动器」：

• 任务完成自动进 In Review 列，点开看全部 diff。
• 在任意文件的任意行点 + 写评论，跨文件攒多条，最后一次性 Send。
• 所有评论合并成一条消息发给 agent，任务自动回到 In Progress，agent 改完再进 Review——循环直到你满意。
• 满意后开 PR：AI 生成描述，到 GitHub 上 review、merge。

这个「行级评论 → 合并反馈 → 打回重做」的循环，本质上是把 code review 的纪律搬给了 agent 工作流。对比一下：直接在 Claude Code 终端里干活，你只能看它自己报的「我改完了」；Vibe Kanban 让你像审同事的 PR 一样审 agent 的产出。

核心机制三：反向集成——Vibe Kanban 自己也是个 MCP Server

除了「Vibe Kanban 驱动你的 agent」，还有一层反过来的：Vibe Kanban 通过 vibe-kanban-mcp 二进制把自己暴露成 MCP server，让 agent 能反过来操作看板。两种模式：

• Global 模式：agent 能看到/操作全局的看板任务。
• Orchestrator 模式：agent 作为编排者，可以创建 workspace、指派任务给其他 agent——agent 自己调度 agent，人只在审查环节出现。

技术上走 rmcp（Rust MCP 框架）+ stdio transport，从端口文件读后端地址。配合 workspace 的 chat-interface，你在看板里直接跟 agent 对话、用 slash 命令、让它读代码库——双向往来都打通了。

核心机制四：内置浏览器 + 多仓库 workspace

两个容易被忽略但很见功力的细节：

• Preview proxy：每个 workspace 起一个 dev server，通过独立端口代理进内置浏览器，带 devtools、inspect mode、设备模拟。前端任务「agent 改完 → 你在浏览器里点一点验证 → 有问题行级评论打回」，全链路闭环。实测中 preview proxy 监听 :46749，没有 dev server 时返回 502——正常。
• Multi-repo sessions：一个 workspace 挂多个仓库（每个独立 git 状态、独立分支），agent 可以跨仓库实现联动修改，diff 视图统一展示。对「改前端仓库 + 改后端仓库才能完成一个功能」的场景是刚需。

上手：实测跑通的命令

我在 Ubuntu 沙箱（无 GUI）实测了 v0.1.44 全链路。前提：装好并登录你喜欢的 coding agent（Vibe Kanban 只负责驱动，不负责认证）。

# 1) 一条命令启动（browser 模式：本地起服务 + 自动开浏览器）
npx vibe-kanban
# 桌面 App 模式（Tauri，需要 GUI 环境）
npx vibe-kanban --desktop

# 2) 子命令：MCP server（agent 反向操作看板）
npx vibe-kanban mcp            # 默认走 stdio，--mode global|orchestrator

# 3) 子命令：review CLI（命令行审查）
npx vibe-kanban review <args>

# 4) 环境变量（自托管/反代场景关键）
#    VK_ALLOWED_ORIGINS=https://vk.example.com   # 反代后不设会 403
#    PORT / HOST / MCP_PORT                       # 端口与绑定
#    VK_TUNNEL=1                                  # 启用 relay 隧道远程模式

实测结果：npx vibe-kanban 下载 49.9MB 二进制（解压后主程序 144MB 静态 ELF）→ 启动 → 主服务监听 :36395、preview proxy :46749 → GET / 返回 WebUI（HTTP 200）→ /api/health 返回 {"success":true,"data":"OK"} → /api/auth/status 返回 {"logged_in":false}。日志同时显示 PR 监控服务每 60s 轮询一次、远程客户端初始化 https://api.vibekanban.com 成功。无 GUI 时「自动打开浏览器」会失败——日志里有一条 WARN，手动开 http://127.0.0.1:36395 即可。

实测与踩坑：项目已死，坑还活着

• 坑 1（最狠）：公司已倒闭，远程功能按公告已下线。4 月 10 日公告明确「远程服务保留 30 天」，即 5 月 10 日后 kanban issues、评论、projects、organisations 这些依赖云端的功能停摆。实测里 remote client 初始化 api.vibekanban.com 域名还活着，但别指望任何云端协作功能——issues 看板、团队功能都需要登录云账号，现在登录了也没服务。本地 workspace 功能（worktree + agent 执行 + diff 审查）不依赖云端，还能用。
• 坑 2：最后一个版本停在 4 月 24 日，npm 包不会再有更新。v0.1.44 就是终版。README 顶部挂着巨大的 sunsetting 横幅，但下载流程、文档、官网都还活着——新用户照常能装能用，只是不会有新功能、不会有安全修复。依赖它的团队要自己评估风险。
• 坑 3：首次使用必须登录（GitHub/Google），否则看板不可用。「More options → I understand, continue without signing in」可以跳过，但跳过后只有 workspace 能用，kanban/issue/team 全部灰掉。而现在云端服务已停，等于看板功能实际不可用，只剩本地 workspace 骨架——这是社区版最需要补的部分。
• 坑 4：反代/自定义域名必须设 VK_ALLOWED_ORIGINS。README 专门警告：不设的话浏览器 Origin 和后端期望 host 不匹配，API 全 403。单 origin 直接给完整 URL，多 origin 逗号分隔。自托管党必踩。
• 小坑：体积与依赖。下载 50MB、解压 144MB 单二进制；需要 Node ≥ 20.19（npx wrapper 本身）；无 GUI 服务器上浏览器自动打开会报 WARN（无害）；npx vibe-kanban mcp --help 这类 help 请求会在下载二进制前被拦截，属正常行为。

对比：跟「并行 agent 编排」的邻居们

一句话定位：superset 解决「并行不打架」，claude-squad 解决「会话有地方待」，Vibe Kanban 解决的是更上游的问题——「怎么让 agent 的产出像同事的 PR 一样被认真审查」。它的看板 + 行级评论闭环到今天仍是这个细分里做得最完整的，这也是为什么公司死了、代码还值得研究。

它留给生态的东西，比项目本身值钱

说点反话：现在这个时间点，我不建议任何人把 Vibe Kanban 部署成生产依赖——云端功能已停、版本冻结在 4 月、安全修复为零。但作为「研究对象」，它价值极高：

• executor 抽象是活的教科书：想给自己的产品接 10 个 coding agent？直接抄它的分层（每 agent 一模块 + ACP 标准通道），比从零造轮子省一个月。
• 「审查闭环」是产品设计的参考答案：行级评论合并喂回 agent 这个交互，今天所有 agent 平台都在抄，抄的源头在这。
• 商业化教训是全行业的学费：2.7 万 Star、千万级免费用户、融过资、功能行业第一——照样倒闭。做 agent 周边工具，要么找到付费锚点（比如 AionUi 的 Team 版、Claude Cowork 的 $100/月），要么想清楚「免费用户」到底能兑换成什么。

代码在 github.com/BloopAI/vibe-kanban，Apache-2.0，社区版路线图曾承诺会发布——4 个月过去还没有动静，但这不妨碍它成为「2025 年 agent 工具潮」最值得考古的项目之一。想看一个产品怎么死得体面、怎么把遗产留给社区，它是最好的样本；想学多 agent 接入架构，它是最好的源码。装它干活？等社区版活了再说。