你花 20 分钟给 Claude Code 讲解重构计划。第二天让它接着昨天的活继续干，结果它完全忘记了昨天你们讨论了什么、做了什么决策、遇到了什么坑，你不得不重新解释一遍。
为了解决这个问题，Steve Yegge 开发了 beads。
beads 是用 Go 开发的"AI Agent 工作记忆系统"，在 GitHub 已有 25.7k star 了。它把任务存为 .beads/ 目录下的 JSONL 文件，借助 Git 做版本控制、分支与合并，并采用依赖感知的图结构管理任务之间的关系，让 agent 能够处理长周期任务而不丢失上下文。
上手体验
安装很简单，使用 x-cmd 一行命令就能搞定：
x install beads
装完后在项目仓库中，运行命令进行配置：
cd your-project
bd init # 初始化数据库
bd setup claude # 给 Claude Code 装 hook 和 skill
完成配置后，你就可以像平时使用 claude code 一样自然地进行开发了——不同的是，现在 beads 会在后台默默帮你记录上下文、追踪变更，让每一次对话和操作都有迹可循，大幅提升协作与复盘效率。
beads 不是 issue tracker
很多人第一次听说 beads，会以为它是一个"命令行版 GitHub Issues"——给开发者用的任务管理工具。
这是最大的误解。beads 的目标用户不是人类程序员，而是 AI 编程 Agent。它的存在意义是：让一个每次会话都要"重新唤醒"的 AI，能够跨会话、跨天、跨分支地记住"项目现在做到哪了"。
那这个"记忆"存在哪里？答案是 Dolt——一个"Git + MySQL"的混合体。
这个选型很关键：beads 既能像数据库一样快速查询（"现在哪些任务能开始做？"），又能像 Git 一样分支、合并、审计（"上周那个改法是谁做的？"）。一个工具同时满足"AI 的实时查询"和"人类的版本回溯"。
为什么 Markdown 计划文件不行
很多开发者试过让 Agent 把计划写在 plan.md 里。但跑几次就会发现四个致命问题：
- 没有依赖追踪：Agent 只能按顺序执行，插入新任务不知道往哪放
- 多 Agent 冲突：两个 Agent 都改
plan.md，后写的覆盖先写的 - 上下文污染：文件越长，越占上下文窗口，真正有用的对话反而塞不进去
- 不可追溯：
plan.md只有最终状态，没有"谁改的"
这些问题的根源是：plan.md 是个文件，而 Agent 协作需要的是数据库——文件没有事务、没有结构化查询、版本控制语义弱。
四个核心机制
机制一：哈希 ID（多 Agent 不撞车）
beads 给每个任务分配去中心化的哈希 ID（bd-a1b2），不是数据库自增——每个 Agent 自己生成自己的 hash 空间。两个 Agent 并行写，零冲突。
机制二：数据库事务（原子操作）
bd update bd-a1b2 --claim 的锁定是原子的——数据库事务保证"要么你锁成功，要么你锁失败"，没有"两个人同时做同一件事"的窗口。
对比 plan.md：两个 Agent 都写下"我要做 A"，最后都去做 A，重复劳动。
机制三：层级 ID（Epic → Task → Sub-task）
ID 自带层级：bd-a3f8.1.1 就是 a3f8 这个 Epic 下第 1 个 Task 的第 1 个子任务。分解大型功能时不用额外写文档，ID 本身就在表达。
机制四：Compaction 机制（"记忆衰退"）
上下文窗口是有限的——Agent 不能把"三个月前的所有对话"都记住。beads 的做法是自动摘要压缩旧任务，释放上下文空间。
这和人类的遗忘曲线很像：细节会淡忘，但结论会留下——三个月前那个 bug 修复的具体改法可能忘了，但"这个项目用 DDD 分层"这种结论性知识值得保留。beads 给了一个专门的命令来存这种"长期结论"，下一节会看到。
三种模式对应三种场景
考虑到不同的协作场景（有些记忆属于"项目公共资产"，有些属于"个人工作区"，有些属于"分离的 PR"），beads 给出了三种模式：
- 默认模式：
.beads/跟代码一起提交，团队所有 AI 共享同一份记忆 - Stealth 模式：
bd init --stealth，个人探索不污染 git log - Contributor 模式：
bd init --contributor，fork 开源项目做贡献时，规划不进 PR
传奇程序员 Steve Yegge
beads 的作者 Steve Yegge 是前 Amazon 工程师（参与 Mechanical Turk 早期工作）、前 Google 高级工程师（写过那篇著名的 "Execution in the Kingdom of Nouns"）。他对"软件工程师如何工作"这件事有二十年的观察——他自己也是高强度开发者。
他对 AI 编程的判断是：AI 不会取代工程师，但会取代"不会用 AI 的工程师"。
你现在的 AI 编程 Agent 是怎么"记住"项目状态的？评论区说说你踩过的坑。
