Posts

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

本系列共八篇，用同一套评价框架横向解剖 20 个开源任务看板 / 编排项目。 所有仓库元数据（星数、许可证、最近提交时间、仓库体量、创建时间）均于 2026-10-08 通过 GitHub REST API 一手核验，不采信二手索引站与聚合博客。 本系列刻意区分「架构设计」与「工程成熟度」，对明星项目同样保留独立判断。

一、场景：一句话的需求，七层的实现难度

先把需求写清楚：

人在一块看板上发布任务 → 本机的多个 coding agent（CodeBuddy / Codex / Trae / CodeArts 之类）定时扫描看板 → 自动领取并完成 → 持续产出可复用的资料或信息 → 由此把各家的免费额度用满。

这个描述里最容易被抓住的关键词是看板。于是绝大多数调研都会从「找一个开源看板」开始——我第一轮也是这么做的，然后发现结论很别扭：看起来功能最全的几个项目，恰恰都不能自主干活；而真能自主干活的，看板又都很简陋。

问题出在提问方式。看板只是这套系统里最外面的一层壳。 把需求拆开会发现，真正决定"能不能无人值守长跑"的，是底下那几层：

#能力层验收口径（做到什么算覆盖）
C1看板呈现人可读写任务、状态可视、最好有终端或 Web UI
C2原子领取与互斥多方同时取单不丢更新；有 WIP 上限；claim 有租约、超时能回收
C3定时扫描与心跳有守护进程或周期扫描；agent 存活可判定；无任务时正确挂起而非空转
C4异构 agent 驱动能统一调起多类本地 CLI 的 headless 入口；能探测各自能力差异
C5执行隔离每任务独立工作目录（worktree / 沙箱），失败可回滚
C6产出回收与验收交付物有约定落点；有质量门；不合格能自动派生补做任务
C7额度感知调度「剩余额度 → 派给谁 → 耗尽切换或排队」的闭环
graph TB subgraph SHELL["外面这层：看得见的"] C1["C1 看板呈现<br/>拖拽、列、评论、历史"] end subgraph FRAME["中间这层：决定能不能跑"] C2["C2 原子领取 + 租约"] C3["C3 定时扫描 + 心跳"] C5["C5 执行隔离"] end subgraph CORE["里面这层：决定能不能长期跑出东西"] C4["C4 异构 Agent 驱动"] C6["C6 产出验收 + 质量门"] C7["C7 额度感知调度"] end C1 --> C2 --> C3 --> C4 C4 --> C5 --> C6 --> C7

这张分层图是本系列的评价基准。后面每篇都会用同一把尺子去量不同项目。

read more
Posts

给本地 Agent 造一块看板（二）：文件系统派——把看板塞进 Git 仓库，代价是什么？

给本地 Agent 造一块看板（二）：文件系统派——把看板塞进 Git 仓库，代价是什么？

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 antopolskiy/kanban-md、MrLesk/Backlog.md、JRGould/Kanbanito、Patrik-Stas/mdboard。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派的共同信念

文件系统派的出发点是一个很朴素的想法：既然 agent 已经能读写文件，那看板为什么不是一堆文件？

于是它们把看板的三个元素直接映射到文件系统：

graph LR B["一块看板"] --> D["一个目录"] C["一张卡片"] --> F["一个 .md 文件<br/>带 YAML frontmatter"] L["一列状态"] --> S["一个子目录<br/>或者 frontmatter 里的 status 字段"]

这个映射带来的好处是立竿见影的，而且几乎全是"agent 视角"的好处：

  • agent 零成本可读。 不需要 API、不需要 SDK、不需要鉴权，一个 Read 就能拿到任务全文。凡是能让 agent 直接读文件的地方，上下文成本就比走 HTTP + JSON 低一档。
  • 可 grep、可 diff、可 review。 任务变更走 git，天然有历史、有 blame、能回滚。
  • 可分支、可合并。 多人（或多 worktree）可以各自在分支上改任务，再合并回来。
  • 无守护进程、无数据库、无端口。 它不需要"起来"，它本来就在那儿。

但也正是这个映射，埋下了这一派最大的结构性缺陷。先把四个项目摆出来，再回来说这个缺陷。

read more
Posts

给本地 Agent 造一块看板（四）：极简单机派——一个二进制、一条命令

给本地 Agent 造一块看板（四）：极简单机派——一个二进制、一条命令

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 rgracey/kanban-mcp、nerkoman/agent-kanban、mintopia/cocopilot、AdamManuel-dev/task-kanban-mcp、SimonBlancoE/kanban-mcp。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派的共同追求：把"部署"这件事消灭掉

前两派都在解决"看板该放在哪"（仓库里 / 依赖图里）。这一派不关心这个，它的目标极其单纯：让一个人在一台机器上、用一条命令，把看板立起来。

于是它们的形态高度一致：

graph LR U["浏览器 / CLI"] --> S["一个进程"] S --> DB[("SQLite 文件")] A["本地 agent"] -->|"HTTP 或 MCP"| S

一个进程、一个 SQLite 文件、一个 HTTP 面（外加可选一个 MCP 面）。没有 Docker、没有外部数据库、没有鉴权体系。

这个追求是合理的——本系列的目标场景就是"单人单机"。但这一派的表现也最参差：它的能力上限不低（有的做到了相当完整的自动派单），可它的存活率是全系列最差的。

先把项目摆出来。

二、五个项目逐个看

2.1 rgracey/kanban-mcp（2★，无许可证，Go）—— 部署轻量度的满分答案

它是"单二进制"这个形态的教科书。

一个 Go 二进制里，SQLite + Web UI + MCP server 全部内嵌，零外部依赖，Web UI 在 :8080。功能上也有几个亮点：

read more
Posts

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

给本地 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 服务。无需账号、无需配置。

read more
Posts

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

给本地 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 认领模型

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

graph TB subgraph DISPATCH["派单模型（Leader 分配）"] L["Leader Agent"] -->|"拆解"| T1["子任务 A"] L -->|"拆解"| T2["子任务 B"] T1 --> W1["Teammate 1"] T2 --> W2["Teammate 2"] end subgraph CLAIM["认领模型（任务池）"] P["共享任务池<br/>（一张张待领的卡）"] -->|"空闲 agent 自行 claim"| A1["Agent A"] P -->|"空闲 agent 自行 claim"| A2["Agent B"] P -->|"空闲 agent 自行 claim"| A3["Agent C"] end
派单模型认领模型
谁决定任务归属一个中心 Agent（Leader）空闲的 agent 自己
任务有没有"在列上等人来抢"的状态没有有
agent 是长期存活还是被唤起被 Leader 唤起常驻，自行轮询
新增一个 agent 的成本要改 Leader 的分配逻辑几乎是零
与"吃满免费额度"的契合度低（Leader 决定谁干活）高（谁有额度谁来接）

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

read more
Posts

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

给本地 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
最近 push2026-09-19
未关 issue544
状态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.

read more