多 Agent 编排 on CAO ZUOHUA

Anthropic 的看板不在看板里

Thu, 08 Oct 2026 22:10:00 +0800

Anthropic 的看板不在看板里

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

三条先行结论

事是真的，形态是假的。 Anthropic 确实有一套让人和 agent 一起接活、认领、交付、复核的机制，而且已经在全员规模上跑了大半年。但公开材料里没有任何一处把这件事描述成看板。
最像看板的那套东西，是用文件实现的。 它的共享任务列表、消息邮箱、并发防冲突，全部落在本机文件系统上——~/.claude/tasks/ 加一堆 JSON 文件加文件锁。跟我在系列第二篇里拆的 kanban-md 几乎是同构的。
它主动放弃了无人值守。 这是最反直觉的一点，也是最值得带走的一点：Anthropic 做了自动领取（self-claim）、做了原子防冲突（file lock）、做了依赖自动解除，然后在最关键的入口上写下一句「非交互模式下不会创建 teammate」。它把「人」当成设计的一部分，而不是需要消除的瓶颈。

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

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

名称	是什么	面向谁	时间
Claude Tag	Slack 里的常驻 Claude，一个频道一个身份，多人共享	客户（Team / Enterprise）	2026-06-23 发布
Claude Code Agent Teams	多 session 协同机制，含共享任务列表与文件邮箱	开发者，实验特性	2026-02-05 预告，文档 2026-10-02 更新
《Building effective human-agent teams》	组织方法论，讲角色、验证与注意力预算	公众	2026-06-24

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

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

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

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

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

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

给本地 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

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

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

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

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

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

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

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

一、这一派放弃了看板

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

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

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

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

graph LR T1["T1 接口定稿 ✅"] --> T2["T2 实现服务端"] T1 --> T3["T3 写部署文档"] T2 --> T4["T4 跑基准测试"] T2 --> T5["T5 前端联调"] style T1 fill:#d1e7dd style T3 fill:#fff3cd style T4 fill:#f8d7da

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