mem0 最小部署：193MB 跑起来的 Agent 记忆层，瓶颈却不在内存

mem0 是这两年的 Agent 记忆层网红。但当你真的想把它塞进一个个人项目时，第一个问题不是"怎么用"，而是"它到底要吃多少资源"。

Anthropic 的看板不在看板里

这是《给本地 Agent 造一块看板》系列的番外。系列正文用同一套七层能力框架（C1–C7）解剖了 20 个开源看板与编排项目，本篇回到一个更上游的问题：如果这个场景真有标准答案，行业里最有钱、最懂 agent 的那家公司是怎么做的？

三条先行结论

1. 事是真的，形态是假的。 Anthropic 确实有一套让人和 agent 一起接活、认领、交付、复核的机制，而且已经在全员规模上跑了大半年。但公开材料里没有任何一处把这件事描述成看板。

2. 最像看板的那套东西，是用文件实现的。 它的共享任务列表、消息邮箱、并发防冲突，全部落在本机文件系统上——~/.claude/tasks/ 加一堆 JSON 文件加文件锁。跟我在系列第二篇里拆的 kanban-md 几乎是同构的。

3. 它主动放弃了无人值守。 这是最反直觉的一点，也是最值得带走的一点：Anthropic 做了自动领取（self-claim）、做了原子防冲突（file lock）、做了依赖自动解除，然后在最关键的入口上写下一句「非交互模式下不会创建 teammate」。它把「人」当成设计的一部分，而不是需要消除的瓶颈。

先澄清：这条说法可能混了三个东西

搜下来，容易被并成一个「Anthropic 内部看板」的，实际是三套不同层面的东西：

此外还有第四件：Anthropic 把自己内部「有多少活是 AI 干的」做成了公开指标，2026-09-17 发布。它不算看板，但它提供了理解前三个的坐标系。

我的核实原则和系列一致：一手优先，二手标注，推测剔除。下面每一条事实都给出出处，末尾附证据分级。

第一套：Claude Tag —— 把 agent 放进通讯录，而不是放进看板

Claude Tag 的官方描述里有一句很关键的话：

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

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

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

先把需求写清楚：

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

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

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

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

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

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

一、这一派的共同信念

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

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

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

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

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

给本地 Agent 造一块看板（三）：任务图派——把「下一个任务」变成一次查询

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 steveyegge/beads、eyaltoledano/claude-task-master、bmad-code-org/BMAD-METHOD。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派放弃了看板

上一篇的文件系统派，本质是「把看板换个存储介质」。任务图派的野心更大：它认为看板这个隐喻本身就是错的。

看板的说法是"一张张卡片，从左边流到右边"。这个隐喻隐含了一个假设：任务之间是独立的。它默认你拿起最左边那张卡就能做，不需要等谁。

真实的多 agent 场景里，这个假设经常不成立。“写部署文档"要等"接口定稿”，“跑基准测试"要等"数据集清洗完”。如果看板不知道这些依赖，那么 agent 取任务时就只能按创建顺序或一个优先级数字去猜——它随时可能取到一个"前置条件还没满足"的任务，然后在那里空转、报错，或者更糟：基于不存在的产物瞎编。

任务图派的回答是：别猜，把它算出来。 把依赖显式建成图，然后提供一个查询，直接返回"当前真正可以开工"的那批任务。

在上图里，绿色的 T1 已完成；黄色 T3 虽然前置已满足但依赖另一条链；红色的 T4 被 T2 阻塞。问题"我现在该做哪个"的答案，就是所有"前置全部完成"的节点集合——术语叫就绪集（ready set）。

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

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

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

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

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

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

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

先把项目摆出来。

二、五个项目逐个看

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

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

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

给本地 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 工作台派——派单模型与认领模型的分野

本系列共八篇，用同一套七层能力框架（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 长时间持续运行、吃满各家免费额度"——这要求系统能根据 agent 的可用性动态分配任务，而不是由一个 Leader 预先分好。认领模型天然适合这件事；派单模型天然不适合。

给本地 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 造一块看板（八）：日落的教训与横向对照

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

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

1.1 事实

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

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.