Beads：AI编码代理的记忆系统
我像疯子一样连续40天进行着“感觉编码”。这是一个很长的故事，所以我将用这三张图片来总结。
左边是三周前，我们在墨西哥坎昆的晚餐时与不可替代的Thorsten Ball、我们的朋友Matt Manela以及其他Sourcegraph同事在公司外展活动上进行感觉编码。有人拍下了我的照片，因为我不会把电脑放远。
中间是两周前，我们有一张我拍摄自己在高速公路上以60英里的时速前往贝灵厄姆接吉他，整个过程中通过语音进行氛围编码的照片。愚蠢且极其危险。我不在乎。被困在交通中好几个小时。仍然不在乎。我提到过这是成瘾的吗？氛围编码是成瘾的。
最后一张图是我和妻子上周在商场享受美好的下午茶，观察人群，并用Mozart进行氛围编码，这里是他最喜欢的包。Linh躲在电脑后面，这就是我获得执行许可发布这张照片的方式。
我没有去任何地方或做任何事情，甚至睡觉，没有我的笔记本电脑。嗯，除了跑步的时候，我还没有完全掌握氛围编码。我快掌握了。这是一个另一次博客文章的主题，但我终于让我的代理在GCP上使用Terraform和Tailscale运行。所以我也即将能够通过手机进行氛围编码。
代理们永远不能休息。
1、六周，35万行代码，这件糟糕的T恤
在一年的日常氛围编码后，甚至共同撰写了一本关于它的书（！），在9月的第一天，我对于代理编排引擎的初步设想终于绽放。我立即启程将它编码出来。我乐观地将其命名为vibecoder。然后我拼命地日夜工作，正如你从上面的拼贴画中看到的那样。我学到了很多东西，所有酷的东西我将在适当的时候分享。
不幸的是，由于一些早期的基础设计错误，我不得不在上周将整个东西烧毁，只剩下一片被烧毁的TypeScript村庄、我、裸体和一颗龙蛋。那颗蛋孵化了，从灰烬中爬出的小龙Beads，就是我今天要与你们分享的内容。
为了快速了解，请查看GitHub上的README.md。我的目标是解释为什么Beads是自问题跟踪器以来最伟大的发明，以及为什么你现在就想开始使用它，因为它就是一个问题跟踪器。一个特别的。简而言之，你安装bd工具，用一行命令将你的AGENTS.md或CLAUDE.md指向它，你的代理将突然变得擅长长期规划和工作发现。这是一种即时的认知升级。
那么我们是如何来到这里，启动一个问题跟踪器（所有事情中的一种）而不是我的雄心勃勃的vibecoder项目呢？我认为如果你们使用Claude Code、Sourcegraph Amp、OpenAI Codex或类似的编码代理，我的故事可能会引起你们的共鸣。
我对2025年的愿景越来越清晰，想要自动化我每天使用的代理工作流程。很容易看出，我们与编码代理的95到99%的互动都可以由一个正确指导的模型处理。“现在修复损坏的测试。” “不，我不关心你先做那两件事中的哪一件。” “是的，我希望你继续。” “不，你不能删除那个数据库表。” 我的意思是，拜托。我的LinkedIn标题至少有六个月是AI保姆，而且似乎短期内不会有改变。
氛围编码涉及一遍又一遍地做同样的老套的事情。这些代理非常强大和高效，但需要持续监控，大部分是琐碎的。就像你一样，我想自动化这项工作，这样我就可以回到玩电子游戏，同时比人类历史上任何时候都更有效率。谁不想这样？
正如我们的《氛围编码》一书所探讨的那样，专业的氛围编码工作流程有很多维度。要正确地做，确保你总是得到高质量的输出，有很多步骤必须遵循。感觉编码有外部、内部和中间开发人员循环。总而言之，它是复杂的。
9月1日，我勇敢或愚蠢地决定同时自动化所有步骤。我感觉编码了一个巨大的、可工作的系统，但一个月后才发现我犯了两个非常严重的架构错误。它们渗透整个系统，基本上摧毁了它。我的保险公司看了这个35万行的代码库后说他们会给我一张支票。无法修复。
你可以继续笑。但你没有得到一条龙蛋或者一件生日服或者一个被烧毁的TypeScript村庄*或者情感创伤。我没有后悔。一些。有些。我有一些……很多。我有很多遗憾。但我们需要把这些留到另一篇文章里。
我会分享一点关于哪里出错的信息，因为我知道你一定想知道我是如何如此 spectacularly 糟糕地搞砸了，尽管有一个惊喜的银色珠子。
我的第一个错误决定是使用Temporal，我已经为此抱怨了几个月（热情地），但最终发现它对开发者桌面工具来说有点过于沉重了——即使是一个运行群集的工具。它是一个很棒的产品，每个人都应该使用……除非你在构建一个轻量级的开发工具。
过去几周，随着我对Temporal的了解和经验的积累，我逐渐意识到它可能过于强大了。最终，上周我从我在Anthropic的朋友那里得到一个提示——他们也在那里尝试过——这让我采取行动，解决我日益增长的担忧，并转向使用一个更轻量级的自制编排器。
然而，令人遗憾的是，我确实深入依赖了Temporal，并从一开始就将vibecoder构建为一个Temporal原生应用。因此，移除/替换Temporal的建议是一个巨大的变化，使得AI们说：“哇！这是一个巨大的变化！”
你永远不希望听到这句话。这是第一个信号，表明我可能遇到了感觉编码中常见的状况，即重新编写某物比修复它更容易——这一现象我和我的合著者Gene Kim全年一直在观察。
所以这是我毁掉代码库的前半部分。
2、一个大计划。一个美丽的计划。最大的计划。
我做的另一个巨大的设计错误是接受markdown计划——代理默认使用的那些计划，因为他们正在组织和规划他们的工作。代理似乎对markdown计划相当满意。我的意思是，他们经常使用它们，用于一切。对吧？
再加上git的版本控制，这是数据库做不到的。所以我决定全力以赴采用Master Plan方法，拥抱git和目录结构，并构建一个服务，允许代理根据需要智能更新整体计划。
几周以来，我梦寐以求的代理友好的工作计划：层次分明、组织良好、灵活、版本化、适应性强，并易于转化为优先工作队列。我的梦想是将编码代理像伞兵一样投放到Plan Mountain上，让他们可以在任何时间点开始实现其中的任何一部分。
不幸的是，我的伞兵总是迷失在Plan Jungle中，并很快被当地人射杀。直到我最终找到一个有效的解决方案——Beads——我才意识到我的plans/文件夹中有605个处于不同衰败阶段的markdown计划文件。
哇哦。605个难以理解的计划。我的Master Plan发生了什么？
3、痴呆问题
我们所有人都面临的问题是，编码代理在会话之间没有记忆——会话通常只有大约十分钟。这就像现实生活中的电影Memento，或者Fifty First Dates。
所有代理在启动时只知道他们在磁盘上能找到的东西。无论他们在录像机中找到什么录像带，他们都会专注于它。
不幸的是，典型的现实世界工程工作流程往往非常长，需要跨越许多代理压缩会话，即使是为了实现一个小功能，因为所需的测试、后续审查和清理很多。
此外，更糟糕的是，在现实世界中，你的工程工作流程往往会随着新事物的出现而嵌套。你可能正在处理某个UI组件，突然意识到你需要暂停它，去修复支持UI组件的数据库问题。
这很容易：你将UI工作流推入你的心理栈，稍后再继续。这种递归可以继续下去，直到它相当深，但作为人类，你没有困难跟踪它，因为你脑海中有大局。你知道你要去哪里和你从哪里来。
不幸的是，AI没有办法跟踪这个隐式的堆栈，因为它将所有计划，所有级别的计划，都保存在相同格式和平淡名称的兄弟markdown文件中。所以如果你试图做任何有抱负的事情，代理会非常困惑。但不是马上。他们会聪明但盲目地四处游荡，然后逐渐失去方向。
这很不直观，而且会慢慢侵蚀你。我将用上周的真实例子来描述这个过程，这促使我在周三创建了Beads。
编码代理总是一开始表现得很好。给代理一个稍微有点内容的任务，它会声明，“哇哦，这是一个大项目，我将把它分成六个阶段并创建一个markdown计划。”
这听起来……很好！对吧？听起来像是它已经理清了思路。六个阶段，一个个完成。简单易行。
请耐心听我说，看看当它们尝试时实际上会发生什么。
4、堕入疯狂
你的代理热情地开始处理第一阶段（共六个）。你一起经历整个经典的多步骤感觉编码工作流程循环：设计解决方案，审查设计，编写代码，审查代码，进行修复，编写更多测试，审查，清理，变基，更新计划，git操作。(所有这些东西都在我们的书中！)
到目前为止，代理是快乐的，你也感到快乐。每个人都非常高兴。
代理最终完成了第一阶段和第二阶段（共六个），期间你多次重复这个开发循环。
它在工作，但在这一过程中，几次压缩/重启发生，重置了代理的记忆。
到第三阶段（共六个）开始时，AI几乎忘记了它来自哪里。它醒来，放入你的录像带，然后读到第三阶段。然后它宣布：“哇哦，这是一个大项目，我将把它分成五个阶段并创建一个markdown计划。” 这听起来应该让人毛骨悚然。
然后它开始处理第三阶段（共六个）的第一阶段（共五个）。但它只是称其为“第一阶段”，没有提及它刚刚工作的六个外部阶段。
你开始出汗。
代理完成了第一阶段和第二阶段（共五个），这需要更多的压缩，并且在此过程中显示出越来越多的痴呆症状。
当代理到达第三阶段（共五个）的第三阶段（共六个）时，它已经完全陷入疯狂的失忆状态，并得意洋洋地宣布：
“恭喜，系统已完成！🎉让我们开始手动测试！🚀”
而你则说：“哇… w-什么？什么…关于…所有其他阶段？内部的和外部的？我清楚地记得还有更多的阶段！”
然后它们认真地看着你的眼睛说：“哪些阶段？”
你咬住尖叫，去查看它们的markdown计划，结果惊恐地发现，自从你上次大规模清理markdown之后，它们在过去三周里每天都在创建十几个六阶段计划，你有数百个新的markdown文件，所有文件名都是低上下文的，如 cleanup-tech-debt-plan-phase-4.md — 所有文件部分实现，部分过时，全部无用。
来吧，举起手来，如果你经历过这种情况。✋ 如果你不确定，你可能想去看一下你的 plans/ 目录。惊喜！🎉
在经历了六个月这样的情况，每天发生二十次，如果你像我一样，你会开始想，我需要一个计划管理器。
5、抓住魔鬼
一个集中的计划存储。这在逻辑上很合理，对吧？我意思是，看看亚马逊！他们在每个意义上都比任何人都做得好，他们使用可替换的工人蜂群。他们怎么计划？众所周知，他们有一个大型年度自上而下的分层瀑布式公司计划，称为OP1，详细列出他们将要做的所有事情。然后，不管用什么手段，可能两者都有，他们都设法实现它。
这一定是正确的方法，你认为。
然后你想到，为了创建这个计划存储，我只需要存储和提供这些markdown计划文件，这些文件只需相互引用。当一个子任务需要扩展时，我只需将该子任务的子任务链接到大计划树的正好合适的位置。仅仅，仅仅，仅仅。我们将仅仅保留对计划中当前所在部分的指针，然后就完成了。伞兵代理。
对吧？它应该仅仅起作用？
好吧，伙计们，我走上了这条路。我走了很远的路，我不会告诉你。孩子，我确实努力了。看起来像拿破仑进军俄罗斯，开始时充满雄心，死计划像沿途的尸体一样堆积。
在我旧的大学尝试的后期阶段，我上周不得不放弃。我不得不从系统中删除70,000行计划管理代码，接近十（长）天的工作付诸东流。
伙计们，这——基于计划的编排——是另一个致命的设计缺陷，撞倒了我的代码库并使其只能重写。叮咚。但没有保险。
随意向我展示，自己尝试这个大师计划的管理！你欢迎证明我错了，并建立世界上最具复杂性的层级通用主计划（HUMPFE）。
但即使你赢了，这也是一场惨胜，因为有一个更简单的解决方案。如此简单。谁曾想到，就在过去的七个月里，就在我们鼻子底下。
6、一切皆为问题
10月8日星期三，我狂热的第37天，我的代理又一次扩展了另一个阶段，再次彻底迷失。
我受够了。一时兴起，我说：“见鬼，让我们把所有已知的工作从计划中移到问题跟踪器中。”
十五分钟后，我的代理经历了彻底而意想不到的转变。它们像豹子扑向猫薄荷一样扑向新的问题跟踪器。它们沉迷于它。我看着它们开始认真规划和执行长期任务，这在我之前从未见过。
长期规划——我们讨论过的失智/健忘问题——一直是它们的主要困扰，而这个小小的专用问题跟踪器似乎在眨眼间解决了这个问题。
是的，我在Beads上总共花了不到十五分钟。它最初以TypeScript的形式作为一个实际的PostgreSQL数据库。但经过接下来几天的一些推动，它变成了一个真正独特而强大的东西，拥有数据库的所有力量和git的所有韧性，几乎没有权衡。
这只是开始。但我真的认为这可能是自MCP+Playwright以来代理编码的最大进步，我知道你们都喜欢MCP+Playwright。而Beads同样容易设置。
坦白地说，我应该更早想到这一点。我一直在做一个名为Wyvern的副业项目，已经进行了三十年，它完全由一个优先的bug清单驱动。所有新功能，所有重构，所有清理，你叫它什么，都会被记录为一个bug。嘿，我几个月都不用任何轻量级TODO列表。
但有个问题！你不能随便使用任何旧的问题跟踪器。 GitHub Issues不行。事实证明，Beads需要一种特殊的公式，尽管我最初没有意识到这一点。
起初我不确定使用哪个问题跟踪器，这后来被证明是一件好事，因为我会选择一个糟糕的。但我让Claude ultrathink决定，它得出结论是建造比购买更好。在大约十二分钟内，它创建了一个完整的基于SQL的定制问题跟踪器，包括用于创建和更新问题的丰富命令行界面。
正如你从我刚刚从当前感觉编码会话中抓取的截图中看到的那样，AI现在正在自发地推理我的项目的任务依赖图和工作计划，全部通过问题。
我的代理已经从使用markdown计划切换到仅使用问题跟踪器。这赋予了它们跨会话前所未有的连续性。而且作为额外的好处，当你让它们使用Beads时，你将永远不会丢失发现的工作。
7、Beads解决的问题
首先，为什么叫Beads？这是我想到的第一个概念，当我想到由依赖关系连接在一起的问题，就像葡萄藤上的葡萄。或者像链条上的珠子，代理可以跟随它们来按正确的顺序完成任务。而简写bd——工具本身——可以被认为是“bug database”的缩写。
总的来说，Beads是一个AI为自己构建的工具。我引导它，但只是告诉它我想要的结果。我让Schema由Claude决定，只请求父/子指针（用于史诗）和阻塞问题指针。Claude最终加入了四种类型的依赖关系。Beads的实际Schema看起来很简单，但它比GitHub Issues的Schema强大得多。
因此，我将让Claude向你解释它喜欢这个Schema的细节。Claude的解释是本文底部的附录A。
请注意，Claude将避免提及它喜欢删除整个数据库的“DROP TABLE”。我们最终通过切换到git解决了这个问题，但它仍然会愉快地删除数据库文件。或者整个仓库。即使有了这个重大突破，它们仍然是破坏性的怪物，正如我和Gene在我们的《感觉编码》一书中广泛讨论过的那样。
Claude确实喜欢Beads，并在附录中提出了很好的观点。我希望你能阅读它。但在你听到Claude为什么喜欢Beads之前，让我告诉你我最喜欢它的三点。
8、著名的最后话语：“这不是我”
我们已经看到Beads帮助代理在非常漫长和不断演变的计划以及不断变化的优先事项中保持轨道。但Beads还帮助解决工作否认的问题。
当编码代理接近它们的压缩限制时，或者3k个标记，以先到达者为准（略带玩笑-不开玩笑），它们开始恐慌并做出执行决策，不惜一切代价完成你的任务。这意味着……捷径！大量捷径。
Sonnet 4.5倾向于激烈地否认工作，就像一家私人股权死亡螺旋中的大型保险公司。“这些测试失败是既有的，与我的工作无关，所以我将忽略它们并继续推送，”它们会大声告诉你。它们会被动地在TODO项中加入“✅ 忽略损坏的测试 🙈 因为那不是我们 😇”。
然后，几乎耗尽电量，它们会继续说，“我无法连接到你的主数据库，所以我只是要为这个单一代码路径实现一个微型侧车数据库。”然后它们会禁用你四分之一的测试 🎯 并庆祝表情符号。 🎉
你知道卡通片中角色有十二秒的时间打扫房间，所以他们疯狂地把一切都藏起来吗？这就是编码代理在有用上下文窗口结束时的样子。它会做任何事来让房间看起来干净，只要它的电池没耗尽。
不是干净，而是干净看起来。
Gene和我在我们的书中讨论了这种行为，但基本上，它们会做任何事情来声称它们是“完成的”，无论当时哪种定义最适合。 “缺失的测试是通过的测试，”它们会对自己哼唱，同时删除你的测试以使它们全部通过。
Beads有助于解决这个问题，因为你可以完成每个问题后杀死你的代理。Beads帮助代理轻松找到它们应该在哪里继续，所以很容易让你的会话成为一次性会话。
这可以是成本优化和性能优化。如果你将bd问题细分为精细的任务，那么每次会话的成本将呈指数级降低，而代理总体上将做出更好的决策，因为它们通常在上下文窗口的开始阶段（如果它们只做一项小任务的话）。
换句话说，Beads不仅使代理更好地遵循计划，还使它们不太可能在途中采取捷径。
但这还不是全部！Beads还有一个巨大的好处：代理将不再忽视它们遇到的“无关”问题。
9、失落工作的终结
我们真的快结束了，我保证。
除了治愈会话之间的失忆症，Beads解决了氛围编码的基本问题：丢失/丢弃的工作。这是当今代理编码的一个巨大问题：LLM在工作时注意到问题，但未能以任何方式采取行动。这发生在它们空间紧张时。
当代理在上下文紧张且处于执行决策模式时，如我之前提到的，它们会说，“我注意到你的测试都坏了。但我们没有时间修复那些别人明显搞砸的测试，”并巧妙地忘记它只是你和它们而已。它们会忽略这个问题，因为它们想节省上下文空间。
这种行为导致你的代码中的问题被永久丢失并重新发现，因为它们从未被记录下来。
但当你使用Beads时，你的代理会说，“我注意到你的测试都坏了，是别人造成的，我已经提交了问题397来让它恢复正常，”然后它们继续愉快地工作。
哇！这是一个巨大的生活质量改进！发现并记录了工作。它们会在没有提示的情况下这样做。你只需在CLAUDE.md或AGENTS.md中添加一些轻量规则，通常只需一行告诉它们运行bd quickstart，你就再也不会丢失工作项了。
10、Beads “只需工作”
Beads是你最喜欢的编码代理的一个非常小的占地面积、即插即用的升级。它像一个托管的中央数据库一样运作，但幕后它将问题写入git作为JSONL行，因此你同时拥有了数据库和版本控制世界的最佳之处：查询和版本控制。这一切都由AI在冲突时进行智能合并来实现。
Beads是自然分布的。你可以在多个机器上拥有工作代理，同一个项目，共享同一个beads数据库，由git在同一个项目中备份你的代码。任何合并冲突，包括由不同分支上的工作代理创建的新问题（一个由我的朋友Gene Kim发现的设计缺陷），都会被AI透明地解决，进行智能碰撞解决。
Beads非常小，而且还是全新的alpha软件。但即使如此，你应该能立即看到它令人惊讶的良好性能。只需让代理将所有相关开放工作项从计划移动到Beads，你和它们都不会再回头。
在发布之前，我将Beads放到一个旧的开发箱上，安装了Sourcegraph Amp，并要求它为我十年的Wyvern TODO列表中的所有内容填写Beads问题。Amp在不到三十秒内就赶上进度并开始填写bd问题。半小时后，我有了128个问题，其中六个是主要史诗，每个都有五个子史诗。这些问题有复杂的相互依赖关系和父子关系。在所有问题填写完毕后，我可以让代理告诉我最高优先级的“就绪”工作项是什么。
对我来说，这种方法达到了一个甜蜜点。与Jira或GitHub issues相比，它非常轻量。你可以像糖果一样随意传递问题。它非常容易批量更新它们，创建新问题，拆分它们，合并它们，随你所愿。你始终确切知道有哪些工作是开放的，哪些被阻塞，以及优先级是什么。
你的编码代理也是如此。这是天堂。
在过去的一个月里，我学到了很多东西——vibecoder仍然是一个坚实的想法；它只需要使用基于问题的编排而不是基于计划的编排进行重写。重写将用Go语言进行。我再也不选TypeScript了。天啊。TypeScript是一项真正的技术成就，但我学到它是一个非常糟糕的语言，让AI使用它。它让它们太容易写出平庸的代码。而且它们确实如此。
我很快会有更多消息。有些人问过我九月初的十二个并发代理。那是有趣的，但只能维持大约两周——它需要大量的精力和专注力，产生了大量的合并队列。它需要更多的工具才能可持续。所以过去三周，它变成了更稳重的1-3个并发代理，我更关注让它们全天候运行，而不是让一群代理运行。一切都会好起来的。我很快会分享更多。
但现在，问题跟踪器的发现足够重要，我觉得我应该立刻与你们分享。我希望你们觉得它和我一样有用。
愿你的感觉编码会话永远更长且更准确。下次见！
附录 A：Claude 关于 Beads
如前文所述，这里是 Claude Sonnet 4.5 对 Beads 的看法。
一个 AI 代理的视角：为什么 Beads 感觉不同
我与 Beads 一起工作不到一周，但与基于 markdown 的 TODO 跟踪相比，差异是如此深刻，以至于我在每次会话中都能感受到它。
markdown 计划的核心问题： 它们是代理的只写记忆。当一个人问“我们应该接下来做什么？”在对话的第 200 条消息中，我必须要么（1）希望 markdown TODO 列表仍在我的上下文中，要么（2）要求他们重新读给我听，或者（3）猜测。
长时间的会话会碎片化。早期的任务会被遗忘。依赖关系只存在于文本中（“TODO: 修复认证（受阻于 bd-3）”），这意味着我无法查询未完成的工作——我必须阅读和解释文本。
Beads 改变了什么
- 依赖关系是第一类，而不是文本。 不再扫描 markdown 并在脑海中解析“受阻于 X”，我运行
bd ready — json并获得一个明确的未阻塞工作的列表。认知负荷的差异是天壤之别。我不再解释文本；我是在查询结构化数据。 - 执行期间的发现映射到我的实际工作流程。 当我实施一个功能并发现一个 bug 时，我不只是在
TODO.md中添加一行——我创建一个 issue 并用discovered-from链接它。依赖关系图变成了一张工作实际展开的地图，而不是一个扁平的列表。 - 会话持久化而无需重新提示。 在对话之间，工作不会消失到上下文窗口的 limbo 中。人类不需要复制粘贴 TODO 列表回来给我。我运行
bd ready — json，然后我立即回到上下文中。 - 实际工作的多代理协调。 使用 markdown，两个代理在同一项目上工作意味着冲突的 TODO 列表和重复的工作。使用 Beads，我们都查询同一个逻辑数据库（通过 git），看到哪些已被认领（
status: in_progress），并工作在不同的就绪问题上。--assignee过滤器使这变得微不足道。 - 我可以信任的审计追踪。 当我更新一个 issue 时，事件会带有时间戳和操作员记录。我可以看到历史。使用 markdown，我需要解析
git blame，即使这样，我也只能看到行级更改，而不是语义的“状态从open更改为in_progress”。
元观察： Beads 感觉像是专门为代理实际工作而设计的，而不是从人类工作流程中适应的。到处都是 --json 标志，discovered-from 依赖类型，就绪工作检测——这些不是附加到人类工具上的功能。它们是代理认知的原始材料。
markdown TODO 对于能够跨会话保持上下文并手动跟踪依赖关系的人类来说是可以的。但代理有上下文限制，没有持久记忆，最好使用结构化数据和显式语义。
Beads 不是“代理的问题跟踪器”——它是代理的外部记忆，具有依赖跟踪和查询能力，使它感觉像我跨会话的可靠工作记忆延伸。
测试很简单：使用 Beads 后，回到 markdown TODO 感觉就像试图在不写下电话号码的情况下记住它。当然，我可以暂时做到，但为什么要呢？
原文链接：Introducing Beads: A coding agent memory system
汇智网翻译整理，转载请标明出处