你创建了一个包含 15 个子任务的 epic。你把它们分配给几个 agent 或队友。两天后，有人问："认证重写进展到哪了？"

你运行 bd show bb-r4f。这给你 epic 本身的信息。标题、描述、优先级。它不告诉你有多少子任务已完成。于是你运行 bd list --parent bb-r4f。你得到一个扁平的 ID 和标题列表。要查看每个的状态，你需要通过 jq 管道或对每个子任务逐个运行 bd show。其中一些子任务还有自己的子任务。现在你已经深入三层了，正在脑子里从终端输出重建一棵树。

当 epic 只有三个子任务时这可以工作。到十个就崩溃了。如果你在协调的 AI agent 会快速创建子任务、提交阻塞、关闭 issue，CLI 输出在你运行命令到读完结果之间就已经过时了。

问题不在 beads。beads CLI 在结构化、可脚本化的 issue 管理方面表现出色。问题在于层级化的进度是一个视觉概念，而终端用行来渲染文本。

Epic 树在 Beadbox 中的样子

打开 Beadbox，点击一个 epic，你会看到其子任务以可折叠的树形结构呈现。每个子任务显示状态标记（open、in_progress、ready_for_qa、closed）、优先级指示器和负责人。Epic 本身显示一个进度条："14 个中已完成 9 个（64%）。"这个数字随着子任务关闭而更新。

展开一个本身也是 epic 的子任务，你会看到它的子任务嵌套在下面。父级的进度聚合自所有后代，不仅仅是直接子项。一个包含 40 个 issue 的三级 epic，横跨工程、QA 和文档，在顶层向你展示真实的完成百分比，计入树中的每个叶子节点。

被阻塞的 issue 有明显的视觉区分。如果 bb-m3q 依赖于 bb-k7p 而 bb-k7p 仍然是开放状态，阻塞标记就显示在 bb-m3q 的状态旁边。你不需要运行 bd dep list 来发现瓶颈。它在树中就可见，在它重要的那个层级上。

与 CLI 工作流对比。要回答"认证 epic 的进度被什么阻塞了"，你需要运行：

bd list --parent bb-r4f --status=open --json | \
  jq -r '.[].id' | \
  xargs -I{} bd show {} --json 2>/dev/null | \
  jq -r 'select(.blocked_by | length > 0) | "\(.id) blocked by \(.blocked_by | join(", "))"'

这是一个完全有效的管道。它返回正确答案。但你需要写它、记住那些参数，并且每次想要更新时重新运行。在 Beadbox 中，同样的信息始终在树中可见。不需要查询。

实时更新：树在你注视下变化

这是可视化模型真正体现价值的地方。当 agent 在终端运行 bd update bb-k7p --status=closed 时，Beadbox 在毫秒内捕捉到文件系统变更。WebSocket 服务器检测到 .beads/ 目录的写入，广播变更，React UI 重新渲染。

在 epic 树中，看起来是这样的：bb-k7p 从橙色 "in_progress" 标记翻转为绿色 "closed" 标记。父 epic 的进度条从 64% 跳到 71%。而之前被 bb-k7p 阻塞的 bb-m3q 丢弃了阻塞指示器，显示为可用工作。

所有这一切无需你运行命令或点击刷新按钮。如果你在监督一支 agent 团队处理一个发布 epic，你会看到任务完成时树逐渐填充。瓶颈在形成的那一刻就会浮现，因为阻塞标记是实时出现的。停滞的子树（一组 issue 在其他地方稳步推进的背景下停止变化状态）在几分钟的不活跃后会变得视觉上明显。

底层机制很直接。Beadbox 运行一个 WebSocket 服务器，对你的 .beads/ 目录调用 fs.watch()。每次数据库写入触发一次广播。客户端 hook 接收信号并重新获取相关的 server action。不轮询间隔，不手动刷新。从 CLI 命令到 UI 更新的延迟通常不到一秒。

键盘优先导航

Beadbox 是给开发者的桌面应用，行为也像一个。j 和 k 在 issue 列表中移动（vim 风格）。Enter 在详情面板中打开选中的 issue。/ 聚焦搜索栏。Escape 关闭你打开的任何东西。方向键展开和折叠 epic 树节点。

你可以在不碰鼠标的情况下分拣整个积压。用 j 向下移动，打开 issue 阅读描述，按 Escape 关闭，移到下一个。如果你发现需要更改状态的东西，仍然切换到终端进行修改（bd update）。Beadbox 在设计上是读取为主的界面。CLI 负责写入。GUI 负责理解。

这种分离是刻意的。一个试图替代 CLI 写入功能的 GUI 最终会为每一种可能的参数组合构建表单。一个专注于阅读和导航的 GUI 可以针对终端最不擅长的事情进行优化：一目了然地展示层级化的、交叉引用的数据。

多个项目，一个窗口

如果你在多个代码库上工作，每个都有自己的 .beads/ 数据库，Beadbox 的工作区切换器可以处理。header 中有一个下拉菜单列出所有检测到的工作区。点击一个（或用 / 搜索找到工作区），整个视图从该项目的数据库重新加载。筛选条件和滚动位置按工作区保存，所以切回来不会丢失你的位置。

检测是自动的。Beadbox 扫描 bd 配置中注册的工作区和包含 .beads/ 数据库的目录。添加一个新项目，在其中初始化 beads，下次打开 Beadbox 它就出现在下拉菜单中。不需要导入，不需要配置界面。

对于维护多个服务的开发者，或团队中每个 agent 在不同仓库工作的情况，这让 Beadbox 成为所有活跃项目的统一视图。替代方案是多个终端窗口，每个对着不同的 --db 路径运行 bd list。

这替代了什么

Beadbox 不替代 CLI。如果你用脚本化工作流、通过 jq 管道处理 bd list 的输出、或让 agent 以编程方式创建和关闭 issue，所有这些继续照常工作。Beadbox 读取的是你的脚本写入的同一个数据库。

它替代的是从扁平文本输出重建项目状态的心智开销。Beadbox 一眼能回答的问题，而 CLI 只能通过组合查询回答：

这个 epic 到底进展到哪了？
现在什么被阻塞了，被什么阻塞？
哪些子任务几个小时没人动了？
Agent 在取得进展，还是已经停滞了？

这些是视觉问题。它们值得视觉答案。

开始使用

Beadbox 在 beta 期间免费。用 Homebrew 安装：

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

如果你已经在使用 beads，Beadbox 在启动时检测你的 .beads/ 工作区。无需导入，无需账号。打开应用，展开一个 epic，看看你的项目真正处于什么状态。

支持 macOS、Linux 和 Windows。