第11章：Kanban —— 用看板编排 AI Agent 项目

Skills 封装能力。Spec 写合约。Ralph Loop 循环到对。gstack 角色覆盖。Goal Workflow 流水线串联。autoresearch 全自动闭环。这些方法论解决的都是"一个 Agent 怎么做事"。

真实场景从来不是一个 Agent。是多个 Agent 同时跑在不同的 worktree 里，多张卡片分布在多块板子上，你不盯就没人在盯。

Kanban 管的就是这个局面。管 Agent。

11.1 为什么是 Kanban

Kanban 不是新东西。丰田 1950 年代用看板管生产线——大野耐一发明了"拉动式生产"：下游消耗完，上游才补，不囤货，不过载。David Anderson 2010 年把看板带入软件工程——可视化工作流、限制 WIP、管理流动。现在进入第三次迁移：从管人变成管 Agent。

为什么是现在？瓶颈变了。

传统开发者的瓶颈在写。AI 时代开发者的瓶颈在管。你面前不再是一个编辑器——是四个终端窗口，每个窗口里一个 Agent 在你没看见的地方做着决定。Karpathy 在 No Priors 播客里说过，自己编写代码的比例从 80% 降到了零，时间花在"向 Agent 下达宏观指令、审查输出、决定哪些要返工"上。

Kanban 的三个核心原理恰好匹配 Agent 场景：

• 可视化工作流。 Agent 正在做什么、做完了什么、卡在什么上面——一张板子全看到。
• 限制并行度。 同时跑 10 个 Agent 制造的不是加速，是文件冲突和 token 账单。WIP 限制把并行数控制在可管理的范围。
• 拉式流动。 Agent 做完一个，自己从就绪队列拉下一个。不用逐张 dispatch。

11.2 三个看板工具

2025 到 2026 年，社区出现了几个专门为 AI Agent 设计的看板。kanbots、Vibe Kanban、kanban-code，三个产品，三种设计路线。

11.2.1 kanbots：每张卡片一个 Agent

GitHub 仓库：leodavinci1/kanbots，341 Stars，MIT 协议，最新版本 v1.2.0（2026 年 5 月）。

核心理念一句话：一张卡片 = 一个 Agent 运行实例。

安装。 macOS 一行命令：

curl -fsSL https://kanbots.dev/install-mac.sh | bash

脚本自动下载 .dmg、拷贝到 /Applications、清除 quarantine 标记。Linux 用 .AppImage（chmod +x 后运行）或 .tar.xz。Windows 用 .exe 安装程序（SmartScreen 警告点"更多信息 → 仍然运行"）。源码构建需要 Node 20+、pnpm 10+、git，pnpm install && pnpm desktop。无需账号——纯本地运行。

macOS 手动安装注意：由于未代码签名，macOS 14 及以前右键 → 打开即可，macOS 15（Tahoe）需 xattr -dr com.apple.quarantine "/Applications/kanbots.app"。

前置条件。 需安装 Claude Code CLI（claude）或 Codex CLI（codex），至少一个在当前 PATH 中。which claude 确认可解析。如果终端能找到但应用启动后 Dispatch 失败——桌面启动器用的 PATH 和终端不同，从同一终端启动或把 CLI 路径加到 shell rc 后重新登录。

首次运行。 应用打开到工作区选择器。选择任意包含 git 仓库的文件夹（必须是 git clone 的，不是 zip 下载的）。kanbots 检测仓库：git rev-parse --show-toplevel → 如果检测到 origin 远端自动建议 GitHub 模式，否则回退到本地模式。两种模式随时可切换。

首次打开在项目根目录下生成 .kanbots/ 目录：

.kanbots/
├── db.sqlite              ← 所有数据（issues、runs、threads、providers）
├── db.sqlite-wal          ← WAL 日志
├── db.sqlite-shm          ← 共享内存
├── config.json            ← 工作区模式 + 默认配置
├── worktrees/             ← 每次 agent run 一个独立 git worktree
├── attachments/           ← 拖入聊天或卡片的文件
├── mcp-runtime/           ← 传给 Claude 的临时 MCP 配置
└── promote/               ← 晋升 worktree 提交时的暂存区

db.sqlite 是除源码外的单一真值来源。.kanbots/ 应加入 .gitignore——应用首次会提示。

看板创建卡片。 点击右上角 + New task。五种模板：Bug fix、Feature、Refactor、Review、Spike。

三种启动方式：

• Spec first——在新 worktree 上跑 /spec 生成验收标准，等你 approve 再实现
• Create & dispatch——马上派 Agent 在新 worktree 上开发
• Queue for later——卡片留在 Backlog，以后手动 dispatch

每次 dispatch 可选 Agent CLI（默认 claude (auto)，可切 Codex）、模型、努力级别。本地模式卡片存为 local_issues 行；GitHub 模式卡片创建为真实 GitHub Issue。

Agent 运行流程。 打开卡片 → 点 Dispatch → 选 Agent 身份和模型 → 确认。kanbots 在 .kanbots/worktrees/issue-<n>-<runId>/ 下创建隔离 worktree，从默认分支切出，启动 CLI。详情面板实时流式显示每个 tool_use 和 tool_result。Agent 遇到决策点——"三个方案选哪个？"——弹出选项卡片，你选后 Agent 继续。

Agent 跑完：Branch preview（一键启动 worktree 的 dev server，打开浏览器看效果）、Promote commit（把 worktree 的提交 rebase 到你的分支）、Open draft PR（仅 GitHub 模式——推送并创建草稿 PR）、Discard（删除 worktree 和分支）。

每个 worktree 预装 pre-push hook，Agent 不能主动推送远程。晋升永远是手动操作。和第 10 章的 Harness Engineering 原理一致：权限边界在系统层强制执行，不在 Agent 的 prompt 里。

常见故障。 "Dispatch failed: claude not found"——桌面启动器 PATH 和终端 PATH 不同，从同一终端启动或把 claude 安装目录加到 ~/.zshrc。端口 8474 被占用时设 KANBOTS_DISPATCHER_PORT=<port> 环境变量后重启。

Autopilot 模式。 kanbots 把 Dispatch 从单次点击变成循环。

feature-dev 模式：设定人物角色列表（persona roster），最多四个并行槽位。Agent 们轮转上场，在父 Issue 范围内自主拆分子任务、分派执行。设定成本预算上限，Agent 们在这个预算内自己跑。

qa 模式：自动运行你配置的检查命令（typecheck、test、lint、build、e2e），可选启动 dev server 监控，哪个检查挂了自动开一个修复 Agent 去修。

两种模式写入 autopilot_sessions 表。你能看到每轮循环历史、每个子 Agent 的运行记录，一个按钮停掉整棵树。

Autopilot 和第 4 章 Ralph Loop 机制相同：Agent 循环执行直到完成。区别是 Ralph Loop 单 Agent 串行，Autopilot 多 Agent 并行——每个 Agent 一个泳道，同时游。

MCP 集成。 kanbots 附带 MCP server（@kanbots/mcp）。Cursor、Claude Desktop 或者任何 MCP 兼容工具都能直接操作看板——读取卡片、创建卡片、触发 Dispatch。Agent 能写代码，也能管自己的看板。一层递归：Agent A 在看板上管着 Agent B、C、D 的卡片流转。

本地优先。 数据存 SQLite。.kanbots/ 目录自包含——一个文件夹搬走，整个项目状态跟着走。完全离线可用。也支持切到 GitHub Issues 模式，驱动真实 GitHub Issues，状态流转自动同步 status:* 标签。

11.2.2 Vibe Kanban：Agent 的工作台

官网：vibekanban.com。由 BloopAI 团队开发。定位：组织并行 Agent 工作流，从零到 Pull Request。GitHub 上 2.6 万颗星。

安装。 一行命令：

npx vibe-kanban

浏览器自动打开 Web UI。首次运行选择 Agent、IDE、通知偏好后可跳过登录（"More options → I understand, continue without signing in"）。跳过登录禁用看板、Issue 管理和团队功能，但单人 Workspace 全部可用。登录（GitHub 或 Google）自动创建个人组织和一个初始项目。

核心抽象：Workspace。 和 kanbots 的"一张卡片一个 Agent"不同，Vibe Kanban 的核心单元是 Workspace——给编码 Agent 准备的独立工作空间。一个 Issue 可有多个 Workspace。

每个 Workspace 配置：仓库（支持多仓库）、分支、prompt、模型、努力级别、plan 模式。配置完成 Agent 立即在 Workspace 里按 prompt 开始执行。Workspace 底层创建 git worktree 隔离代码变更。也可不关联 Issue——纯当快速代码问答用。

Issue 系统。 Issue 代表一个 bug、功能或待完成的工作。最少需要标题和描述，可选优先级、标签、父子 Issue 链接。点击"New Issue"创建，右侧面板展示草稿和已选 Issue 的详情。

完整流程。 Plan → Run → Review → Preview → Ship：

1. Plan。 看板上创建 Issue，排优先级，分配父子依赖。
2. Run。 为 Issue 创建 Workspace，配置 Agent、分支、prompt，Agent 在隔离 worktree 里执行开发任务。
3. Review。 点击"Open Workspace"进入完整视图。Diffs 和浏览器预览通过浮动按钮切换。直接在 UI 里看 diff 并批注——批注意见直接发给 Agent，不切终端。
4. Preview。 内置浏览器预览 Agent 的改动效果。
5. Ship。 Workspace 完成后合并：创建 GitHub PR 或本地合并 workspace 分支。

Agent 支持。 用户选择 Agent，Workspace 里可单独配置模型、努力级别、plan 模式。支持并行 Agent 执行——多个 Workspace 同时跑不同的 Agent。支持 10+ 种编码 Agent：Claude Code、Codex、Gemini CLI、GitHub Copilot、Amp、Cursor、OpenCode、Droid、CCR、Qwen Code。

团队功能。 需要登录。支持共享项目和 Issue、多人协作 Review。由于 Vibe Kanban 是 Web 应用（有自托管 Docker 部署方案），团队数据由后端统一管理。

和 kanbots 的关键差异：

• kanbots 是本地单机 Electron 应用——SQLite + 本地 Agent 执行 + 无需网络。Vibe Kanban 是Web 协作平台——后端、数据库、用户体系、自托管 Docker 部署。
• kanbots 的 Agent 运行是"点 Dispatch 跑一个"——偏 Agent 自主循环。Vibe Kanban 是"在 Workspace 里持续交互"——Review 内嵌在 UI 中，偏人机协同。
• kanbots 数据完全在本地。Vibe Kanban 有完整的云后端和团队协作能力。

Sunsetting。 Vibe Kanban 已宣布逐步关闭。官网上挂着公告："Vibe Kanban is sunsetting. The project will continue as open source and community maintained."，主要原因是开发者团队找不到合适的商业模式，主要用户都是免费用户。从产品角度看，做 Agent 协作工具的 SaaS 商业模式仍在摸索期——开发者倾向开源免费工具，企业市场仍在观望 Agent 成熟度。夹在中间的 SaaS 产品找不到舒适的定价锚点。

但 Vibe Kanban 的设计不会过时。它的 Workspace 抽象——"给 Agent 一个独立分支、一个终端、一个可预览的 dev server、一个 review loop"——是 Agent 协作工具的理念标杆。之后出现的同类工具，开源或商业，大概率沿这条路走。

我个人试用了 Vibe Kanban，产品简洁。好在它开源了，靠社区维护，希望这个产品能活下去。

11.2.3 kanban-code：Agent 控制面板

GitHub 仓库：langwatch/kanban-code，193 Stars，AGPL-3.0 协议，最新版本 v0.1.28（2026 年 5 月）。

原生 macOS（SwiftUI）和 Windows（Tauri）双端应用。定位最偏"个人开发者日常驾驶舱"——六列看板，每张卡片自动关联 Claude 会话、git worktree、tmux 终端和 GitHub PR。卡片基于真实活动信号自动横移——Claude 开始工作 → 入 In Progress，PR 已开 → 入 In Review，PR 合入 → 入 Done。不用手动拖。

安装。 macOS 从 GitHub Releases 下载 .app 文件（未公证，需右键 → 打开）。首次启动运行 onboarding 向导，自动检测依赖（Claude Code CLI、tmux、gh CLI、mutagen、Amphetamine——全是可选的渐进式增强）。

源码构建：git clone 仓库，make run-app（macOS）。Windows 进入 windows/ 目录：npm install && npm run tauri dev（开发模式）或 npm run tauri build（生产 .exe）。

跨平台 CLI 自动安装在 ~/.local/bin/kanban（app 首次启动或 make install-cli）。常用命令：kanban list（按列列出卡片，-c 过滤列，--json 输出）、kanban status（概览：卡片数、终端数、token 消耗、成本）、kanban show <card>（详情：会话、tmux、PR、transcript）、kanban send <card> <message>（向卡片的 tmux 会话发 prompt）、kanban interrupt <card>（发 Escape 停止助手）、kanban transcript <card>（最近对话记录）。卡片引用支持 ID、ID 前缀、名称、tmux 会话名或 session ID。全部命令支持 --json——为主 Agent 编排子 Agent 设计。

配置存 ~/.kanban-code/settings.json（人工可读、可版本控制）。协调数据存 ~/.kanban-code/links.json（关联 session、worktree、tmux、PR）。

tmux 终端嵌入。 每个 Claude 任务跑在独立 tmux 会话中。kanban-code 管理 tmux 生命周期——启动 Claude 时自动创建会话，重连时自动 attach，归档时自动 kill。卡片内嵌原生终端模拟器（SwiftTerm，支持真彩色、Unicode、鼠标、滚回）。终端状态跨卡片保持——切卡片不丢终端内容。也能 tmux attach 到外部终端操作。

Session 发现与搜索。 自动扫描 ~/.claude/projects/ 发现全部 Claude 会话——正在跑的、历史的、在终端手动启动的。BM25 全文搜索跨全部会话历史，带新近度加权。能从任意历史点 fork 出一个新会话——带上全部上下文，并行做新任务。Checkpoint 回滚到任意对话节点。

Git Worktree 集成。 每张卡片自动创建 git worktree。GitHub Issue 用 issue-123 命名 worktree，手动任务自动生成名称。发现后台孤立的 worktree 提示清理。

远程执行。 通过 SSH + Mutagen 把 Claude Code 卸载到远程机器——本地编辑，远程编译，双向文件同步。UI 显示 Mutagen 同步状态。远程机器离线自动回退到本地执行。

Push 通知。 通过 Pushover 发到手机和 Apple Watch。Agent 的响应摘要直接推到手腕上。智能去重——Stop 事件合并，62 秒内同内容去重。

防休眠。 集成 Amphetamine——Agent 在跑时不让 Mac 睡。Agent 都空闲时自动退出。

11.2.4 三者对比

三个工具指向同一个方向：模型能力上去了，Agent 管理层自然要跟上。Harness 管 Agent 的安全和可控性（纵向）。Kanban 管 Agent 的调度和协作（横向）。组合起来才是完整的 AgentOps。

Hermes 以及一些其他的 Agent 最近也增加了 kanban 的功能，也有 kanban Skill，不过没发展起来。

11.3 从个人工具到团队平台

三个工具覆盖了 AI Agent 项目的三个管理阶段：

第一阶段：个人提效。 你一个人，一块看板，几个 Agent。目标是让自己从瓶颈变调度中心。kanbots 和 kanban-code 都面向这个阶段——本地工具，不需要服务端，不需要协作功能。把个人 Agent 的管理问题解决了，再考虑推广到团队。

第二阶段：团队协作。 共享看板，每个人分配自己的 Agent 做子任务。Review 分布式进行。需要权限管理、代码所有权、CI/CD 集成。Vibe Kanban 瞄准这个阶段——虽然它关闭了，但需求不会消失。目前这个阶段主要由 GitHub Issues + kanbots GitHub 模式 + kanban-code PR 追踪拼凑出一套折中方案。

第三阶段：人机混合团队。 Agent 不只是执行者——还做规划和决策建议。人的角色从执行退到监督、从分配任务退到设定方向。这个阶段目前没有人做成熟的商业化产品，但 kanbots 的 Autopilot + MCP 集成已经展现了雏形。

绝大多数团队目前在第一步和第二步之间。先用 kanbots 或 kanban-code 个人跑起来，理解 Agent 的工作节奏，建立卡片规范和 review 习惯。模式内化之后，工具反而不那么重要了——核心心智模型永远一样：可视化工作流、限制并行度、拉式流动。

11.4 本章小结

Kanban Agent 方法论是 AI 时代软件开发的"驾驶舱"。前九章教开车，第 10 章看引擎盖下面，这一章讲仪表盘——你坐在哪、看什么、怎么同时指挥多辆车。

这几个 AI 模式下的 kanban 工具还是很有用的，很方便管理项目任务进度，尤其对那些先前就使用 kanban 的团队来说就更方便了。

三个工具代表三种设计哲学。kanbots 是本地 Agent 调度器——一张卡片一个 Agent，Autopilot 自主循环，MCP 让 Agent 管自己的看板。Vibe Kanban 是团队 Agent 工作台——Workspace 抽象，从 Plan 到 Ship 全流程覆盖，虽然关闭了但设计理念会留下来。kanban-code 是 Agent 控制面板——tmux 终端嵌入、Pushover 通知、远程执行，个人开发者日常驾驶舱。

三个工具都指向同一个趋势：当一个人的 Agent 从一台变成四台、五台、十台，单靠终端切换和记忆是管不住的——需要系统级的工作流编排。第 10 章的 Harness Engineering 管 Agent 的安全和可控性，本章的 Kanban 管 Agent 的调度和协作。一个是纵向控制，一个是横向协调。组合在一起才是完整的 AgentOps。