beads：给编码智能体装上带依赖关系的持久记忆

它解决的不是「记性差」，而是「上下文断裂」

编码智能体在长任务里经常忘记之前做了什么，尤其是任务跨越多个文件、多次对话时。常见做法是把计划写进 markdown 文件，但 markdown 是扁平的，任务之间的依赖关系只能靠人工维护，一旦智能体修改了某个任务，其他相关任务不会自动更新。beads 用图结构替代平面清单，每个任务是一个节点，任务之间用「阻塞」「相关」「父级」等边连接。这样智能体可以查询「哪些任务没有未解决的阻塞项」，而不是靠猜测。它服务的对象是使用 Codex、Claude Code、Cursor 等工具的开发者，尤其是那些让多个智能体并行工作的场景。

底层是 Dolt，不是 SQLite

beads 把 Dolt 作为存储引擎，这一点决定了它的很多特性。Dolt 是一个带版本控制的 SQL 数据库，支持单元格级别的合并、原生分支以及通过 remote 同步。这意味着 beads 的数据可以像 git 一样推送和拉取，多个智能体在不同机器上工作时，可以通过 bd dolt push 和 bd dolt pull 交换数据。哈希 ID 如 bd-a1b2 是全局唯一的，所以不同分支上的任务不会因为 ID 冲突而合并失败。文档强调「零冲突」，这在实际多智能体协作中是个实质优势，因为传统自增 ID 在分布式环境下需要协调机制。不过，这也意味着你需要在项目中额外管理一个数据库目录，而不是简单的文本文件。

核心命令：从创建到关闭的完整流程

beads 的命令行接口设计得很直接，围绕任务生命周期展开。bd create "Title" -p 0 创建一个 P0 任务，bd ready 列出所有没有开放阻塞项的任务，bd update <id> --claim 原子性地认领任务，bd close 标记完成。bd dep add <child> <parent> 用来建立任务间的依赖关系。bd prime 会打印当前工作流上下文和持久记忆，bd remember "insight" 则存储一条项目记忆，供后续 bd prime 注入。这些命令的输出默认是 JSON，方便智能体解析。安装方面，macOS 和 Linux 可以用 brew install beads，Node.js 用户可以用 npm install -g @beads/bd。初始化项目只需在项目根目录运行 bd init，它会自动创建或更新 AGENTS.md，让智能体发现 beads 工作流。

智能体集成：setup 与 onboard 两条路径

beads 针对不同智能体客户端提供了 bd setup 子命令，比如 bd setup codex、bd setup claude、bd setup factory，它会安装对应的 skill、hooks 或 AGENTS.md 配置。如果客户端不在支持列表里，可以用 bd onboard 生成一段提示文本，手动粘贴到智能体读取的指令文件中。文档还给出了一个最小 AGENTS.md 片段，告诉智能体运行哪些命令。这种设计降低了接入门槛，但有个隐藏成本：如果你已经有一套自定义的 AGENTS.md，bd init 默认会更新它，除非你显式传入 --skip-agents 或 --stealth。这可能导致你的现有指令被覆盖，需要仔细审查生成的改动。

存储模式与协作角色：嵌入式和服务器模式的取舍

beads 支持两种存储模式。默认的嵌入式模式让 Dolt 在进程内运行，数据存放在 .beads/embeddeddolt/，只允许单写入者，文档推荐大多数用户使用这种模式。服务器模式通过 bd init --server 连接外部 dolt sql-server，支持多个并发写入者。对于个人项目或单智能体场景，嵌入式模式足够；但如果你计划让多个智能体同时写入同一个项目，就必须切换到服务器模式，这需要额外部署和维护一个 Dolt 服务。另外，beads 区分贡献者和维护者角色。贡献者模式 bd init --contributor 会把规划问题路由到单独的仓库，避免实验性工作混入 PR；维护者则通过 SSH URL 或 HTTPS 凭据自动检测。这个设计考虑到了开源协作的实际场景，但如果你用 GitHub HTTPS 且没有配置凭据，需要手动设置 git config beads.role maintainer。

压缩与消息：上下文窗口的省钱之道

智能体的上下文窗口是有限资源，beads 的压缩功能试图缓解这个问题。文档称之为「语义记忆衰减」，它会总结已关闭的旧任务，以节省上下文空间。具体实现细节没有公开，但可以推测它保留任务的关键信息，比如标题、状态和依赖关系，而丢弃详细的审计日志。另外，beads 支持消息类型的 issue，带线程、临时生命周期和邮件委派功能。这意味着除了任务跟踪，它还能充当智能体之间的通信层。不过，这些功能在 README 中只是一笔带过，实际效果需要查阅完整文档才能确认。如果你需要复杂的消息路由或邮件集成，可能得自己评估是否满足需求。

升级与维护：不是换个二进制那么简单

beads 的升级流程比普通 CLI 工具复杂。文档明确警告「替换二进制并不总是全部」，建议先同步远程数据库，用 bd export --all 备份，再升级二进制，然后运行 bd info --whats-new、bd hooks install 和 bd version。如果升级跨越了远程数据库的 schema 迁移，恰好一个指定克隆需要运行 bd migrate 和 bd dolt push，其他克隆则安装新二进制并运行 bd bootstrap。这个流程对单机用户来说有点繁琐，但对多机协作是必要的，因为 schema 不一致会导致同步失败。安全方面，安装脚本会校验发布 checksums.txt 中的校验和，macOS 上默认保留下载签名，本地重新签名需要显式设置 BEADS_INSTALL_RESIGN_MACOS=1。这些细节表明 beads 重视供应链安全，但也增加了维护负担。

替代方案与适用边界

与 beads 最接近的替代方案是 GitHub Issues 或 GitLab Issues 配合 markdown 文档。区别在于，传统 issue 跟踪器是集中式的，依赖网络服务，而 beads 是本地优先的，数据存储在项目目录中，可以离线使用。另一个区别是依赖图：GitHub Issues 支持任务列表和父子关系，但无法表达复杂的阻塞网络，也没有内建的智能体记忆注入功能。如果你只是需要一个简单的待办清单，beads 可能过重；但如果你需要智能体自动发现「哪些任务可以开始」，beads 的 bd ready 命令提供了现成的答案。它的边界在于，它不是通用的项目管理工具，而是专门为编码智能体设计的，所以不适合非技术团队使用。

编辑结论

beads 适合那些需要让编码智能体在长周期任务中保持上下文、且愿意接受一套新工作流的团队。它不适合只想在现有 markdown 清单上做小修补的人，因为引入 Dolt 和哈希 ID 意味着学习成本与迁移代价。采用前先验证三件事：确认你的智能体客户端能通过 bd setup 或 bd onboard 正确接入，评估单写入者嵌入式模式是否满足你的并发需求，以及检查升级流程中 schema 迁移对远程数据库的影响。如果这些都能接受，beads 提供的依赖感知图模型确实比平面清单更接近智能体实际的工作方式。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes