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

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

给本地 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）可以各自在分支上改任务，再合并回来。
无守护进程、无数据库、无端口。 它不需要"起来"，它本来就在那儿。

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

Markdown on CAO ZUOHUA

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

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

一、这一派的共同信念