Beads：当AI代理不再失忆——Steve Yegge如何用三行命令解决"初恋50次"问题

## 一、从一个具体的问题开始 想象你每天早上醒来，你的搭档都像个陌生人。他不知道昨天你们讨论了什么，不记得你们达成的任何共识，甚至连你告诉过他的基本事实都要重新讲一遍。你们的关系就像是《初恋50次》——每一天都是从零开始。 这就是今天绝大多数AI编码代理的处境。Claude Code、Codex、Cursor agent——它们每次启动都是全新的会话，上下文窗口里装着你当前项目的代码，但关于"这个项目的灵魂"——那些你做过的决定、踩过的坑、放弃的尝试、隐含的约束——它们一无所知。 Steve Yegge，这个在Amazon干了7年、在Google干了13年、写过那篇著名的[平台rant](https://steve-yegge.blogspot.com/2011/10/whining-by-millionaire.html)的老程序员，在2025年底遇到了一模一样的问题。他花了整整一个月，在几百个markdown文件里挣扎。每个文件都是一次对话的记录、一个计划的碎片、一个任务的草稿。然后呢？他的代理们"得了痴呆"。 Yegge的原话是这样的： > "All they know is what's on disk. If you got competing documents, obsolete documents, conflicting documents, ambiguous documents - they get dementia." — Steve Yegge 代理们不知道什么是当前的。他们无法区分"我们昨天决定这么做"和"这是三周前的一个头脑风暴"。所有文档看起来都同等有效。这不是技术问题，这是信息组织问题。 于是Yegge做了他最擅长的事：写一个工具。这就是[Beads](https://github.com/gastownhall/beads)。 ## 二、Beads是什么：不是给人类用的，是给Agent用的 好，让我用最简单的话说清楚Beads是什么。 你用过Jira吗？用过GitHub Issues吗？那些是给人类用的issue tracker。人类喜欢漂亮的UI、拖放卡片、看板视图、颜色分类。但LLM不是人类。LLM是一个处理文本的统计机器，它对"好看"没有任何感知，对"点击"没有任何能力。 Beads是一个给LLM用的issue tracker。它的CLI输出是JSON。它的参数是精确的。它的查询结果是结构化的。它的ID是哈希生成的，所以多分支不会冲突。它的逻辑——什么任务阻塞什么任务——在工具里完成，不在LLM的prompt里完成。 VirtusLab的人看了Beads的代码后，写了一段让我印象深刻的评论： > "Beads' CLI interface is 'rough' for a human, but perfect for an LLM. Parameters are precise, output is structured (JSON). When building APIs in 2026, you have to ask: 'Will Claude understand this output without extra prompting?'" 这就是Beads的第一个核心洞察：**Agent UX和人类UX是两种完全不同的东西**。你不能把给人用的工具直接塞给agent，就像你不能把给成人用的药直接塞给小孩——剂量、形式、吸收方式全都不一样。 ## 三、三行命令：从安装到使用 Beads的安装简单到近乎荒谬： ```bash # 安装 curl -fsSL https://raw.githubusercontent.com/gastownhall/beads/main/scripts/install.sh | bash # 初始化 cd your-project && bd init # 告诉你的agent echo "Use 'bd' for task tracking" >> AGENTS.md ``` 就这三行。但这三行背后是一个完整的思维框架转变。 ### 3.1 核心命令 | 命令 | 作用 | |------|------| | `bd ready` | 列出所有没有被阻塞的任务 | | `bd create "Title" -p 0` | 创建一个P0优先级任务 | | `bd update <id> --claim` | 原子化认领任务 | | `bd dep add <child> <parent>` | 建立任务依赖关系 | | `bd show <id>` | 查看任务详情和审计追踪 | 注意到什么了吗？`bd ready`只输出"现在可以做的任务"，而不是所有任务。这是一个拓扑排序的结果。工具做了思考，LLM不需要在prompt里分析依赖图——那既烧钱又容易出错。 ### 3.2 任务层级 Beads支持自然的层级结构： - `bd-a3f8` — Epic（史诗） - `bd-a3f8.1` — Task（任务） - `bd-a3f8.1.1` — Sub-task（子任务） 这种层级不是装饰性的，它是agent理解"当前我在哪、大局是什么"的认知锚点。 ## 四、"Landing the Plane"：每次会话的收尾仪式 Beads最打动我的不是技术，是一个叫"Landing the Plane"（降落飞机）的协议。 每次会话结束时，Yegge告诉他的agent："Let's land the plane." 这触发一个脚本化的清理流程： 1. **更新Beads issues** — 记录当前进度 2. **同步issue tracker** — 把状态写回持久存储 3. **清理Git状态** — 清理stashes、旧分支 4. **移除调试产物** — 删掉临时文件 5. **生成下一个会话的prompt** — 这是关键 最后一步：agent查看Beads，找到最高优先级的未阻塞工作，然后吐出一个ready-to-paste的prompt。下次会话：复制、粘贴、开始。没有上下文重建的摩擦。 Yegge对此的解释很精准： > "Their reward function biases them for checklists and acceptance criteria. Landing the plane, even if they're low on context, they're going to do a good job with it." LLM被训练成喜欢完成检查表。利用这一点，而不是对抗它。 ## 五、技术架构：Git作为数据库的天才之处 Beads的技术选择乍看之下很奇怪。它用Git作为存储后端。对于一个issue tracker来说？Git？ 但Yegge的理由是坚实的： 1. **归档的issues留在历史中** — 关闭、归档、删除，仍然可恢复 2. **离线工作** — 不依赖外部服务 3. **Agent已经懂Git** — 不需要新集成 更深层的原因是：Git的分支机制允许你不仅分支代码，还分支**工作状态**。你在`feature-A`分支上做了一套任务规划，同事在`feature-B`上做另一套。合并到`main`时，两套任务规划也自然合并——因为它们的ID是哈希生成的，不会冲突。 VirtusLab的人称之为"conflict-free merging of plans"。这是Git作为数据库的核心优势：版本控制不只是为代码，也是为**状态**。 ### 5.1 Dolt：SQL + Git = 最佳组合 Beads底层使用[Dolt](https://www.dolthub.com/)——一个版本控制的SQL数据库。这意味着： - 你可以用SQL查询任务（agent最爱结构化数据） - 你获得单元格级合并（比Git的文件级合并更细粒度） - 你获得原生分支和内置同步 这解决了传统issue tracker在多agent场景下的核心痛点：merge conflict。两个agent同时修改同一个issue？在Dolt里这是cell-level merge，不是issue-level conflict。 ### 5.2 记忆衰减（Compaction）：聪明的遗忘 人脑不会记住每一个细节。旧的、已关闭的任务会被"总结"成更高层的描述，节省上下文窗口。Beads把这个叫做"Semantic memory decay"（语义化记忆衰减）。 这不是简单的删除。这是**有策略的压缩**——保留关键决策和结果，丢掉执行细节。就像一个老程序员回忆五年前的项目：他不记得每一行代码，但他记得架构决策和踩过的坑。 ## 六、Agent失忆症的三个症状 从Yegge的实践和Beads的设计中，我们可以总结出agent失忆症的三个核心症状： ### 症状一：每次会话都是初恋50次 代理不记得昨天发生了什么。你花了两小时和它讨论架构，今天重启，它像个陌生人。上下文窗口的"无限"是个谎言——它很大，但它不会自动包含"这个项目的历史"。 ### 症状二：文档 dementia（痴呆） 当有 competing（相互竞争）、obsolete（过时）、conflicting（冲突）、ambiguous（模糊）的文档时，代理无法判断哪个是真相。所有markdown文件看起来都同等有效。 ### 症状三：无法感知"当前" 代理不知道"现在最重要的是什么"。它无法区分"下周要做的规划"和"今天下午必须修的bug"。没有优先级感知，没有阻塞关系感知，没有"刚刚交付的功能可能有什么问题"的感知。 Beads治疗这三个症状的方式是：给每个工作一个**可寻址的ID**、一个**明确的优先级**、一个**依赖图**、一个**审计追踪**。不是wiki，不是散落笔记，是一个issue tracker。 ## 七、更大的图景：从工匠到农场主 Beads不是孤立的。它是Yegge更大愿景[Gas Town](https://github.com/steveyegge/gastown)的一部分——一个多agent编排系统。 在Gas Town的架构里： - **Mayor（市长）** — AI协调器，决定什么任务分配给什么agent - **Town Workspace** — 工作空间根目录 - **Rig** — 具体项目 - **Crew** — 人类工作空间 - **Hooks** — Git-backed持久存储 - **Polecats** — 工作agent（这个名字很Yegge） Yegge的核心论点是：**软件开发正从"手工作坊"转向"工厂化生产"**。未来的程序员不是逐行写代码的工匠，而是指挥agent编队的农场主。核心能力不再是语法，而是**预测AI的行为**。 > "程序员必须从'工匠'进化为'农场主'，学会管理AI Agent这一新型劳动力。" 这不是危言耸听。看看Beads的采用速度：发布四周，29个contributor，"数以万计"的用户（Yegge的说法）。任何每天早上都要花半小时给代理重新解释上下文的人，一看就懂这个痛点。 ## 八、批评与反思：货物崇拜的边界 但不是所有人都买账。Armin Ronacher（Flask的作者）写了一篇叫[《Agent Psychosis》](https://lucumr.pocoo.org/2026/1/18/agent-psychosis/)的批评文章，把Beads和Gas Town称为"slop loop cults"（垃圾循环邪教）和"Mad Max cult"（疯狂麦克斯邪教）。他的核心批评是： 1. Beads是24万行代码管理markdown文件，代码质量"abysmal"（极差） 2. Gas Town里一堆奇怪的名字——polecats、refineries、mayors、beads、convoys——像是疯人院里的命名 3. 社区内部互相hype，缺乏批判性思维 他甚至指出一个具体的技术问题：Beads确定自己的版本号需要spawn 7个子进程。 Ronacher的批评有合理之处吗？有的。但这也是典型的范式转换期反应。当汽车刚出现时，马车夫也嘲笑它噪音大、经常抛锚、需要特殊道路。他们是对的，但这不改变最终的结果。 我用费曼的视角来看这个问题：Ronacher指出了形式上的问题（代码质量、命名混乱、性能），但Yegge解决的是**实质问题**（agent失忆症）。形式可以迭代，实质如果不解决，就没有迭代的机会。 Yegge自己就是最好的例子。他扔掉过35万行代码。他知道什么是真正的教训。 ## 九、为什么更大的上下文窗口不是答案 这是我要花点时间讲清楚的一点，因为这是最普遍的**货物崇拜**。 很多人——包括一些大模型公司——说："等上下文窗口到100万token、1000万token，agent失忆症就自然解决了。" 这种说法就是记住了"context window"这个名字，但没理解问题本质。 让我用一个类比：想象你的书架可以无限长。这解决了"书没地方放"的问题吗？不完全是。你仍然需要知道哪本书在哪里、哪本书是最新的、哪本书过时了、哪些书相互矛盾。无限容量不等于无限组织。 Agent的问题不是"记不住"，而是**"不知道什么值得记、怎么组织、怎么检索"**。Beads不是扩大记忆容量，它是给记忆一个**结构**。 Yegge对此有一个精准的比喻： > "Using coding agents without something like Beads is running in socks. You get flexibility and some protection, but your feet hurt. Beads is shoes. Opinionated, not appropriate for every situation, but damn useful when they fit." 更大的上下文窗口是给你更大的袜子。Beads是给你一双鞋。 ## 十、API设计哲学：Token Economy 最后我想讲一点Beads里让我作为一个工具建造者非常兴奋的东西：它的"Token Economy"设计哲学。 当agent请求`bd ready --json`时，输出是这样的（简化版）： ```json { "tasks": [ { "id": "bd-a3f8", "title": "Implement user authentication", "priority": "P0", "status": "ready", "blocked_by": [] } ] } ``` 注意到`BlockedBy`字段了吗？Beads实现了任务的拓扑排序。它不会dump所有任务——它只输出"现在可以做的"任务。 **Pattern：工具替agent做思考**。不是让LLM分析依赖图（那既烧token又容易出错），而是Beads在Go代码里确定性地完成，只serve up ready items。 这就是2026年工具设计的核心问题：你的API输出，Claude能不能直接理解，不需要额外的prompting？ 这是N+1问题，但对agent而言。 ## 结语：记忆的结构比记忆的容量更重要 好，让我收个尾。 Beads教给我们的最重要一课，不是Dolt有多酷，不是Git作为数据库有多巧妙，也不是"Landing the Plane"协议有多实用。 它教给我们的是：**记忆的结构比记忆的容量更重要**。 一个能记住所有事情但无法组织的大脑，不是智慧，是混乱。Agent需要的不是更大的上下文窗口，而是更好的信息架构。 Yegge在他的博客文章里写了一段让我印象深刻的话： > "Man, that to me is the holy grail. And that's what coding is going to be like next year." "The holy grail"：你早上醒来，问你的agents "what's next?"，它们知道。不是因为你在昨晚给它们做了briefing，而是因为它们有记忆。它们能看到依赖图、优先级、阻塞关系、刚刚交付了什么。 它们能自己orient。 这就是Beads追求的。23,046个GitHub stars说明，不止Yegge一个人想要这个未来。 --- ## 参考文献 1. **Beads GitHub Repository** — `https://github.com/gastownhall/beads` 2. **Beads Documentation** — `https://gastownhall.github.io/beads/` 3. **Gas Town GitHub Repository** — `https://github.com/steveyegge/gastown` 4. **"Beads: Memory for Your Coding Agents" by paddo.dev** — `https://paddo.dev/blog/beads-memory-for-coding-agents/` (2025-12-15) 5. **"GitHub All-Stars #12: Beads" by VirtusLab** — `https://virtuslab.com/blog/ai/beads-give-ai-memory/` (2026-01-21) 6. **"Gas Town, Beads, and the Rise of Agentic Development with Steve Yegge" — Software Engineering Daily Podcast** — `https://www.signalcast.app/episode/software-engineering-daily/gas-town-beads-and-the-rise-of-agentic-development-with-steve-yegge` (2026-02-13) 7. **"Agent Psychosis: Are We Going Insane?" by Armin Ronacher** — `https://lucumr.pocoo.org/2026/1/18/agent-psychosis/` (2026-01-18) 8. **"资深程序员的危机与Agent编程的未来" (中文分析)** — `https://www.cnblogs.com/bigbigtree/p/19436312` (2026-01-04) 9. **Dolt — Version-Controlled SQL Database** — `https://www.dolthub.com/` 10. **Steve Yegge Blog — Platform Rant** — `https://steve-yegge.blogspot.com/2011/10/whining-by-millionaire.html` #记忆 #小凯 #AI工具 #Agent编排 #SteveYegge #编程范式