多个编码代理同时跑，他给它们装了个问题追踪器

一个人写代码，边跑边改，路子野一点也能活。几个编码代理同时开工，事情就变味了：谁在干什么、什么被卡住、下一步最该修哪个，全成了一笔糊涂账。

作者自称是个"半混沌"的软件工程师，习惯带着探路者的劲头：先动起来，看到什么再修什么。这种打法在单人代码库里意外地好用，一旦多个代理并行，就很难判断大家是不是朝同一个方向走。

他反复问自己同样的问题：那个代理刚才在干嘛？什么被阻塞了？下一个最该修的是什么？过去的做法是直接找代理要一份最新状态。这招管用，代价是时间和 token——等于把已经梳理过一遍的项目图景重新拼一次。

在 Beads 之前，他大多让代理自己出计划。代理会说"这大概要花你 2-3 周"，然后一口气把整件事做完。他还得给明确指令，有时候代理仍然不更新文档或进度。

软件团队早就用问题追踪器解决了这件事，Beads 就是把这套思路做给编码代理用。他是通过 Steve Yegge 的文章和播客知道这个工具的。它给他的能力是：跨多个对话编排工作、把任务顺序理清楚、不再依赖某个第二天就丢上下文的代理。

Beads 是什么

Beads 是一个面向编码代理的命令行问题追踪器，命令是 bd。它不靠聊天窗口或 Markdown 文件里那份松散的待办清单，而是让你创建 issue，每个 issue 可以带描述、优先级、状态，以及与其他 issue 的关系。这些 issue 能活过一次代理对话，新会话接手时不必依赖上一段会话的记忆。

真正有用的是依赖图。假设一个功能要先改数据库，API 才能更新，把这个关系记下来，bd ready 就会列出没有未决阻塞项的工作。代理可以查看某个 issue、认领它、干活、关闭它。关掉一个阻塞项，下一个任务就变成就绪状态。

计划由此变成项目工作流的一部分，而不是他反复找代理要的一份总结。

怎么开始用

不需要一群代理才能从 Beads 里拿到价值。他装上 bd，在项目里跑 bd init，然后让 Claude 去用它。有时候他只跑 bd init，再让代理用 bd prime 拿更多上下文。

• brew install beads
• cd your-project
• bd init

bd init 还会创建或更新 AGENTS.md，让代理进入仓库时能找到这套工作流。作者的建议是读一遍它写了什么，再按自己想要的方式调整。之后代理自己跑循环：bd ready 找活，bd show 看细节，bd update --claim 认领，干完 bd close。

在他的赛车赛事追踪项目里，bd ready 的输出被裁到只剩几行，每行是一个没有未决阻塞项的任务：ID、优先级、方括号里的类型（如果有）、标题。比如一条 P1 的 epic 是"Feeder 系列赛（F2/F3）：修正赛历和场次时间，并防止模板腐化"，还有一条 P2 的 bug 是"过期的往期赛事残留在 gold/upcoming.json 里"。

第一个实打实的收获是数据管道里的一个 bug，一个拖了很久的问题。他从没让代理去找它。代理自己发现了问题，并把细节记成了一条 issue。Beads 没有找到这个 bug，是代理找到的，Beads 只是给了它一个存放的地方。这是个很小的改变，也是个不错的起点：让代理把问题登记下来，而不是埋在聊天记录里。

更大的任务他会用规划器，或者分而治之。当任务能被并行捡起、手上又有富余的代理（token 或请求额度）时，这套做法回报最高。一个典型计划大约拆成 4 个 epic，取决于当时在做什么，彼此之间有清晰的分工。默认是串行，真正能扩展的是子代理：一个编排代理用 bd ready 把独立任务分给子代理，每个子代理用 bd update --claim 认领自己的那份。

最常出问题的是那些一直没被关闭的 issue。验收标准里包含提交代码或请他做最后检查，代理完成不了这一步，issue 就一直开着。他只能自己关，或者再让代理关一次。

他想要的那块看板

命令行对代理好用，但他想更快地自己看整个项目。于是他给自己的 Beads issue 做了一个本地网页看板：扫一遍工作、看子代理的视觉化进度、加评论、删掉不再重要的 issue。

主视图是看板，分"未开始、进行中、已关闭"三列。另有一个层级视图，可以在里面编辑，并实时看代理捡起任务、把它往前推。

这个看板是他用 Claude 在 Beads 的一个 fork 里一次做出来的。他只说了一句："给我做一个本地看板，让我能看进度。"

用起来有点像通过一块自己搭的、被吹得神乎其神的 Jira 板管理一个团队。区别在速度：看一眼板子，发现一个阻塞项或一个可疑任务，改一下，把代理赶回去干活。

他一开始没找到现成的看板。做完自己的之后，才发现 Beads 的社区工具列表，以及一个关于 Beads 界面的 GitHub 讨论。想要视觉层的人远不止他一个。他觉得不错的一个是 Beads Dashboard：有就绪、阻塞、逾期工作的总览，有路线图，还有拖拽看板，几乎和他做的一样，但它是开箱即用的 VS Code 扩展。

那么什么时候该给自己做个小工具，什么时候该用现成的？从软件工程的角度看，在好几个地方重复造同一个东西显得浪费。但这件事只花了一个提示词，而且做它的过程让他更了解 Beads 本身。对一个个人工具来说，这笔交易划算。

留在环里的人

以前每次跟丢线索，他就找代理要一次状态更新。现在他打开看板，看什么在进行、什么卡住了，然后把代理赶回去干活。他仍然边探索边改方向，只是现在手里有一张专为代理画的地图，而人留在环里。或者更准确地说，是一个旁观的人。

问题还悬在那儿：在这个抽象层之上，还有多少东西值得他去旁观？

他说这只是开始，接下来想探索 Beads 和代理还能给他的构建方式带来什么。