Steve Yegge 新作,给 AI 编程助手装「长期记忆」

用过 Claude Code、Cursor、Copilot 的同学应该都有这个感受：AI 编程助手短期能力很强，但一旦项目变大、任务变长，它就开始「失忆」。上一轮对话说的方案，下一轮就忘了；改了三个文件后，突然不知道整体进度在哪了。

这不怪 AI —— 它的上下文窗口就那么大。但 Steve Yegge（没错，就是那个写了 Google 和 Amazon 内部无数技术博客、后来创业做 Graffiti 的 Steve Yegge）觉得这个问题可以解。

他的答案叫 Beads。

Beads 是什么？

Beads 是一个面向 AI 编程 Agent 的分布式图谱 Issue 追踪器。简单说：它给 AI Agent 装了一个结构化的长期记忆系统，让 Agent 在长周期任务中不会丢失上下文。

核心思路很直接：用依赖图（Dependency Graph） 替代混乱的 Markdown 计划文件。每个任务是一个节点，任务之间的依赖关系是有向边。Agent 随时可以查询「哪些任务已经 Ready（没有未完成的阻塞）」，而不用翻找一堆 plan.md。

底层用的是 Dolt^[1] —— 一个支持版本控制的 SQL 数据库，可以做 cell-level merge、原生分支、远程同步。相当于 Git 管理代码，Dolt 管理任务数据。

GitHub 数据

• 项目地址：github.com/gastownhall/beads
• 语言：Go
• 创始人：Steve Yegge（Go Report Card 链接证实）

值得关注的 3 个点

1. 「语义衰减」机制太聪明了

Beads 有一个叫 Compaction 的功能：对已关闭的旧任务做语义摘要压缩，自动「遗忘」细节，只保留关键结论。

这本质上是在模拟人类的记忆衰减。人的大脑不会记住上周每个 bug 的修复细节，但会记住「那个模块有过并发问题」。Beads 对旧任务做的是同一件事 —— 压缩成摘要，节省上下文窗口，但核心知识不丢。

对于长期运行的 AI Agent 来说，这个设计可能比单纯的「无限记忆」更实用。

2. Hash ID 消除协作冲突

每个任务的 ID 是 bd-a1b2 这样的 hash 格式，而不是递增数字。这意味着多 Agent、多分支并行工作时，不会产生 ID 冲突。

Steve Yegge 在 Google 和 Amazon 带过大团队，他深知分布式协作的痛点。这个设计看似小，实际上为多 Agent 协作铺了路 —— 未来如果多个 AI Agent 同时改一个项目，各自维护自己的任务图谱，merge 时不会炸。

3. 零 Git 依赖的 Stealth 模式

bd init --stealth 可以在不提交任何文件到 Git 仓库的情况下使用。数据全部存在本地 Dolt 数据库里。

这对不想把 AI Agent 的任务管理工具暴露给团队其他成员的开发者来说，非常实用。你用 Beads 管理 Agent 的任务追踪，但同事看到的仓库依然是干净的。

个人启发

AI Agent 基础设施正在成为一个新赛道。

2024 年大家还在讨论「AI 能不能写代码」，2025 年变成了「AI 怎么写更好的代码」，现在 2026 年的焦点正在转向 AI Agent 的工程化基础设施：

• 上下文管理和记忆系统（Beads）
• Agent 技能/插件生态（Matt Pocock 的 Skills）
• Agent 协议和安全（MCP、Claude Code Hooks）

这些项目有一个共同点：它们不直接卖 AI 能力，而是解决「让 AI 能力持续、稳定、规模化落地」的工程问题。

从创收角度看，这其实是更健康的切入方式：

1. 不跟大模型厂商竞争 —— 你不需要训练模型，只需要做好工具层
2. 需求确定性高 —— 只要企业在用 AI 写代码，就一定有记忆管理、任务追踪的需求
3. 护城河在工程积累 —— 图谱数据结构、版本控制、冲突解决，这些都需要深厚的工程经验

Steve Yegge 选了 Dolt 作为底层，这个选择本身就很有意思。Dolt 没有走传统的 PostgreSQL 路线，而是把「版本控制」内建到数据库层。这意味着 Beads 的任务数据天然支持 branch、merge、diff —— 跟代码仓库的工作流完美对齐。

如果你在关注 AI Agent 基础设施的创业机会，Beads 值得认真研究。

项目地址：github.com/gastownhall/beads

引用链接