你有五个 AI 编码 agent 在处理一个功能 epic。Agent 1 在构建 API 层。Agent 2 需要这个 API 来接通前端。Agent 3 在编写依赖前两者的集成测试。Agent 4 和 5 在处理数据迁移和文档，各自被不同的部分阻塞。

这大约能运转二十分钟。然后 Agent 2 停滞了，因为 Agent 1 遇到了意外的 schema 问题。Agent 3 现在被 Agent 2 阻塞，Agent 2 被 Agent 1 阻塞。Agent 4 和 5 继续在干活，但它们的工作在链条解决之前无法合并。你直到一个小时后才发现什么都没有交付，然后开始对每个 issue 运行 bd blocked。

依赖信息是存在的。它就在你的 issue 追踪器里。但当你通过 CLI 管理它时，你是在从扁平文本输出中在脑子里重建图谱。而这种重建恰恰在最重要的时刻失效：当图谱复杂且事情正在出问题的时候。

beads 如何追踪依赖

beads 是一个为 AI agent 协调而构建的 Git 原生 issue 追踪器。它将一切存储在你仓库 .beads/ 目录中的本地 Dolt 数据库里。没有云服务，没有账号，没有同步冲突。

Agent 用一个命令声明依赖：

bd dep add ISSUE-42 ISSUE-37

这记录了 ISSUE-42 依赖于 ISSUE-37。ISSUE-42 在 ISSUE-37 关闭之前无法继续。反向查询同样简单：

bd blocked

这返回工作区中所有当前被未解决依赖阻塞的 issue。对于特定 issue：

bd dep list ISSUE-42

这显示 ISSUE-42 依赖什么以及什么依赖 ISSUE-42。

数据模型是干净的。问题不在于记录依赖。问题在于看到它们。当你有 30 个活跃 issue 分布在五个 agent 上时，运行 bd blocked 给你一个列表。列表不会告诉你 ISSUE-12 是一个瓶颈，阻塞了三个 agent 的七个下游任务。列表不会告诉你 Agent 3 在 ISSUE-18 和 ISSUE-22 之间创建了循环依赖。你需要图谱的空间视图，而不是顺序视图。

Beadbox 给你展示什么

Beadbox 是一个原生桌面应用，用可视化界面包装 beads CLI。它从你的 agent 写入的同一个 .beads/ 数据库读取，并在它们工作时实时更新。

在 epic 树视图中，每个有未解决依赖的 issue 都内联显示一个阻塞标记。你可以看到 epic 的完整树形结构，被阻塞的 issue 一目了然。不需要运行命令，不需要解析输出。

依赖链在空间上可见。如果 ISSUE-42 依赖于 ISSUE-37，ISSUE-37 依赖于 ISSUE-15，而 ISSUE-15 分配给了被卡住的 Agent 1，你可以通过扫描树追踪这条链。你不需要从单独的 CLI 查询重建，就能看到瓶颈的形态。

实时部分很重要。当 Agent 1 终于关闭 ISSUE-15 时，Beadbox UI 在一秒内反映。ISSUE-37 上的阻塞标记消失。如果 ISSUE-37 是唯一阻塞 ISSUE-42 的东西，那个标记也消失。你可以看着依赖链随着工作完成而瓦解，不需要刷新或重新查询。

底层机制是通过一个简单的管道：WebSocket 服务器用 fs.watch() 监听 .beads/ 目录。当任何 agent 写入数据库（关闭 issue、添加依赖、更新状态）时，文件系统事件触发向所有连接客户端的广播。React UI 用最新数据重新渲染。从 agent 操作到视觉更新的延迟在亚秒级。

一个具体的场景：发现瓶颈

五个 agent 在处理一个包含 24 个 issue 的功能 epic。你打开 Beadbox 查看 epic 树。12 个 issue 进行中。6 个显示阻塞标记。

这已经是你之前没有的信息了。bd list 会向你展示 12 个进行中的 issue，但你需要单独运行 bd blocked 并交叉对比才能理解哪些进行中的 issue 实际上是停滞的。

你扫视阻塞标记，注意到一件事：六个被阻塞的 issue 中有四个都依赖于 ISSUE-19，一个分配给 Agent 4 的数据库 schema 迁移。Agent 4 还在做，但 ISSUE-19 已经成了一个单点瓶颈。四个 agent 实际上是空闲的，在等待一个任务。

没有可视化视图，你可能再过一个小时都不会发现这一点。有了它，你可以立即介入。也许你把 ISSUE-19 重新分配给更快的 agent。也许你把它拆分成更小的部分，提前解除一些依赖方的阻塞。也许你意识到四个依赖中有两个是过度声明的，可以用 bd dep remove 移除。

关键不在于信息之前不可获取。它一直在数据库里。关键在于可视化表示能浮现扁平文本所掩盖的模式。

常见的依赖反模式

在同一个仓库上运行多个 AI agent 会产生几种反复出现的依赖问题。所有这些通过可视化方式都比通过 CLI 查询更容易发现。

过度声明。 Agent 倾向于保守。有疑问时就声明依赖。结果是依赖图比实际需要的更密集，issue 被它们实际上并不需要的工作阻塞。在 Beadbox 中，当一个 issue 显示阻塞标记但阻塞 issue 在代码库完全不相关的部分时，你就能发现这种情况。一个快速的 bd dep remove 就能清理。

循环链。 Agent A 声明了对 Agent B 工作的依赖。Agent B 独立工作时声明了对 Agent A 工作的依赖。现在两者互相阻塞，谁也无法继续。beads CLI 在创建时会捕捉明显的循环依赖，但通过三个或更多 issue 的间接循环更难检测。在 epic 树中，你会注意到这些是一组从不解除的阻塞标记集群，即使周围的其他工作在完成。

单点瓶颈。 一个 issue 积累了五个、六个、七个下游依赖方。当并行工作的 agent 都需要同一个基础组件时，这自然会发生。上面的场景就说明了这种模式。在列表视图中，你看到七个被阻塞的 issue。在树视图中，你看到七个箭头指向同一个节点。瓶颈一目了然。

开始使用

Beadbox 支持 macOS、Linux 和 Windows。用 Homebrew 安装：

brew tap beadbox/cask && brew install --cask beadbox

将它指向任何有 .beads/ 目录的仓库。如果你已经在用 beads 管理 agent 团队，Beadbox 会读取现有数据库并立即开始渲染。无需导入步骤，无需配置，无需创建账号。

你的 agent 继续使用 CLI。它们照常运行 bd dep add、bd update、bd close。Beadbox 监听数据库并实时反映每一个变更。你获得了可视化层，而无需改变任何 agent 工作流。

Beadbox 在 beta 期间免费。

如果你在同一个代码库上协调多个 AI agent，依赖图是最先会破坏你工作流的东西。你可以通过 CLI 盲目管理它，或者你可以看到它。看到它更快。