多 Agent on CAO ZUOHUA

给本地 Agent 造一块看板（五）：自主编排派——三个最接近目标的项目

Thu, 08 Oct 2026 21:05:00 +0800

给本地 Agent 造一块看板（五）：自主编排派——三个最接近目标的项目

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。本篇覆盖 cline/kanban、saltbo/agent-kanban、BradGroux/veritas-kanban。元数据于 2026-10-08 经 GitHub API 一手核验；机制描述取自各仓库 README 与架构文档原文。

一、为什么这一派要单独成篇

前面三派各自缺一大块：文件系统派缺守护进程与验收；任务图派只解决调度决策；极简单机派几乎没碰 C5–C7。

这一派不同。这三个项目都明确主张同一件事：把人从执行环路里拿出去。

cline/kanban 的措辞是"更适合并行跑大量 agent 并审查 diff 的 IDE 替代品"；
saltbo/agent-kanban 的标语直接是 “Don’t babysit your agent. Take human out of the loop.”；
veritas-kanban 则是"local-first 的任务管理看板 + 可选的 AI agent 编排层"。

而它们的覆盖度也确实更高——其中 veritas-kanban 是本系列唯一一个同时具备"配额预算"与"产出评分"的项目，这直接推翻了早期调研"C6/C7 完全空白"的判断（详见总览篇第二节）。

需要坦白一件事：这三个项目在前几轮检索里全部被漏掉了。 漏掉的原因很简单——检索词一直围绕 kanban 打转，而这三个项目的自我描述分别是"IDE replacement"、“mission-control board”、“task management board with agent orchestration”，名字或描述里根本没有那个词。

这本身就是一条方法论结论：当你要找的是"机制"时，用"名字"检索会系统性地漏掉最好的答案。 所以本篇开头先把这个教训摆出来。

二、三个项目逐个看

2.1 `cline/kanban`（1,353★，Apache-2.0，TypeScript，标注 Research Preview）

它的关键词是"链"。

用法极简：在任意 git 仓库根目录跑 npx kanban，它会自动探测你本机已安装的 CLI agent，然后在浏览器里起一个本地 Web 服务。无需账号、无需配置。

给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野

Thu, 08 Oct 2026 20:55:00 +0800

给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。本篇覆盖 iOfficeAI/AionUi、DanWahlin/ai-agent-board、smtg-ai/claude-squad、Nimbalyst/nimbalyst、langwatch/kanban-code。元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派是最"像产品"的一批

如果说前面几派是"给工程师用的工具"，这一派就是"给人用的产品"：有像样的界面、有自动探测、有向导、有通知、有移动端。

它们的共同强项高度一致：

C1 看板呈现：拖拽、实时流式输出、diff 查看器、行内评论，体验是全系列最好的；
C4 异构 agent 驱动：启动时自动探测本机已装了哪些 CLI，这是本派最实用的一项能力；
C5 执行隔离：worktree 隔离几乎是标配，且往往配了自动清理。

它们的共同软肋也高度一致：C2/C3（自主领取与扫描）与 C6/C7（验收与额度）基本不在射程内。

而这一切背后有一个更本质的差别，本篇的主要论点就围绕它展开。

二、核心分野：派单模型 vs 认领模型

先把这个区别讲清楚，因为它解释了本派为什么"功能很多，却依然不能无人值守"。

	派单模型	认领模型
谁决定任务归属	一个中心 Agent（Leader）	空闲的 agent 自己
任务有没有"在列上等人来抢"的状态	没有	有
agent 是长期存活还是被唤起	被 Leader 唤起	常驻，自行轮询
新增一个 agent 的成本	要改 Leader 的分配逻辑	几乎是零
与"吃满免费额度"的契合度	低（Leader 决定谁干活）	高（谁有额度谁来接）

这个区别对本场景是决定性的。 因为本场景的动机是"让多个 agent 长时间持续运行、吃满各家免费额度"——这要求系统能根据 agent 的可用性动态分配任务，而不是由一个 Leader 预先分好。认领模型天然适合这件事；派单模型天然不适合。

给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

Thu, 08 Oct 2026 20:45:00 +0800

给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。本篇覆盖 NousResearch/hermes-agent（252,141★，MIT）内置的 Kanban。机制描述取自本机安装目录中的一手文档（website/docs/user-guide/features/），非二手转述。 ⚠️ Hermes 迭代极快，本文所有路径、环境变量名与配置项均为 2026-10-08 快照，实际使用前需重新核对。

一、这一派只有一个样本，但它的位置很特殊

前面五派有一个共同前提：看板是一个外挂工具。 它可能住在你的仓库里（文件系统派）、住在数据库里（极简单机派）、或者带一个漂亮的桌面界面（工作台派），但无论哪种，它站在 agent 的外面：它负责记状态，然后想办法去调用 agent。

平台内置派的前提完全不同：看板长在 agent 运行时内部。 它不是"一个会调 agent 的看板"，它是"一个自带看板的 agent 平台"。

这个位置的差异，直接决定了能力上限。用一句话概括：

一个独立看板只能"调用 CLI 并解析输出"；而一个拥有 agent 生命周期的看板，可以"回收一个 PID 已经消失的 worker"。

举个具体的例子。所有独立看板项目都在某个地方承诺"任务超时会自动释放"。但它们能做的其实只是"把 claim 时间戳过期的任务标记为可领取"。而 Hermes 的 dispatcher 做的是：

定期回收过期的 claim；
并且专门回收"PID 已经消失、但 TTL 还没到"的崩溃 worker；
还有一个反直觉的细节——只有进程真的死了才回收。也就是说，一个跑得很慢但活着的模型会被续期，而不是被杀掉。

这三条之所以能做到，是因为 dispatcher 本身就持有 spawn 权。 它 spawn 了那个 worker，所以它知道 PID；它能探活，所以它能区分"慢"和"死"。外挂式看板永远拿不到这个信息——它启动 CLI 只能拿到一个子进程句柄，而那个句柄在 CLI 内部又 fork 出什么，它一无所知。

这一篇的全部价值，就在这个"位置差异带来的能力差异"上。

给本地 Agent 造一块看板（八）：日落的教训与横向对照

Thu, 08 Oct 2026 20:35:00 +0800

给本地 Agent 造一块看板（八）：日落的教训与横向对照

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖 20 个开源任务看板 / 编排项目。本篇分四部分：日落复盘、横向矩阵、跨项目启发、选型与缺口。元数据于 2026-10-08 经 GitHub API 一手核验。

第一部分：一次有意识的商业止损

1.1 事实

先把事实摆清楚，全部来自一手核验。

项	值
仓库	`BloopAI/vibe-kanban`
★	28,292
许可证	Apache-2.0
语言	Rust
仓库体量	约 102 MB
创建	2025-06-14
最近 push	2026-09-19
未关 issue	544
状态	README 顶部原文：“Vibe Kanban is sunsetting."，并链向关停公告

README 顶部的原文是一句加粗的 <strong>Vibe Kanban is sunsetting.</strong>，后面跟着一个指向官方博客关停公告的链接。

它是全系列里星数第二高的项目。 一个 28,292★ 的项目，在创建不到两年后主动关停。

1.2 它解决的是什么问题

要理解它为什么死，先要看准它做的是什么事。它自己的 Overview 写得很清楚：

In a world where software engineers spend most of their time planning and reviewing coding agents, the most impactful way to ship more is to get faster at planning and review. … Use kanban issues to plan work… When you’re ready to begin, create workspaces where coding agents can execute.

多 Agent on CAO ZUOHUA

给本地 Agent 造一块看板（五）：自主编排派——三个最接近目标的项目

给本地 Agent 造一块看板（五）：自主编排派——三个最接近目标的项目

一、为什么这一派要单独成篇

二、三个项目逐个看

2.1 cline/kanban（1,353★，Apache-2.0，TypeScript，标注 Research Preview）

给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野

给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野

一、这一派是最"像产品"的一批

二、核心分野：派单模型 vs 认领模型

给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

一、这一派只有一个样本，但它的位置很特殊

给本地 Agent 造一块看板（八）：日落的教训与横向对照

给本地 Agent 造一块看板（八）：日落的教训与横向对照

第一部分：一次有意识的商业止损

1.1 事实

1.2 它解决的是什么问题

2.1 `cline/kanban`（1,353★，Apache-2.0，TypeScript，标注 Research Preview）