Posts

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