把 320 个 Claude Code 实例拉成一支“智能体团队”！Steve Yegge：年底前，写软件不再“敲代码”，而是像玩“策略调度”游戏

当你把 AI 编程用到极致，它看起来就不再像“写代码”，而更像“带团队”。

Steve Yegge 说自己刚关掉了机器上的 320 个 Claude Code 实例，每个实例差不多 1GB 内存。

这种多智能体会同时在线：有人在写、有人在改、有人在合并；有人会突然宣告“搞定了”，也有人会互相等待、互相打断，把局面搅成一团。规模一上来，你会立刻体会到他为什么说：“这就让单个开发者遇到了以往只有团队才会遇到的问题。”

如今，AI 辅助编程早已超越自动补全：大模型不只是写函数、补几行代码，它开始能改动整套代码库、协调长时间运行的任务、在多个系统间协作。但当这些能力越强，越该告别的反而是“人工管理智能体”——你需要的不是更勤快地盯着它们，而是一套能让它们在规模化运行下依然可控、可收敛的机制。

于是他做了 Beads（共享记忆系统），又做了 Gas Town（多智能体编排系统）。320 个实例一跑，拼的是系统“能不能管住、能不能记住”。以后，智能体慢慢变得像角色扮演游戏、策略游戏乃至即时战略游戏。

他甚至相信：“可能到今年年底，人们就会像玩游戏那样开发软件。”

而更激进的，是他对未来软件生死的判断。在这期播客里，他给出了一个“未来软件生存公式”： “要想在 AI 的冲击下生存下来，就必须像 Beads、Dolt、MongoDB、Temporal、Kubernetes、Kafka、Cassandra 这类基础设施那样成为 AI 的优先选项。”

因为大模型是“懒”的。它会选择最节能、最省 token、路径最短的方案。 “只要能让大模型知晓你的工具，那项目活下来就不成问题。”

换句话说，未来的软件不仅要服务人类用户，还要进入大模型的“默认工具箱”。谁能帮模型省 token、少绕路、跑得稳，谁就被优先调用；剩下的，要么被绕过，要么被吞掉。

以下是这期播客的完整翻译：

Steve Yegge： 好的，之前从来没人问过这个问题，那我就简单概括一下吧。首先我肯定算是个行业老手吧，我从事软件行业很久很久了。我从 17 岁就开始编程，前几天已经 57 岁了。40 年匆匆而过，我也亲眼见证了很多很多变革。

我最早是在亚马逊供职时开始写博客的，当时是希望能说服公司里那个坐拥 800 名工程师的团队能接受我的一些观点，因为我发现他们的不少想法是错的。之后我开始加入自己的吐槽，没想到博客居然火了起来。反正慢慢的写博客就成了我的习惯，特别是在小酌一杯之后。不过九年前我就戒酒了，希望我能把这个好习惯坚持到底。

Steve Yegge： 让我真正感到震惊的应该是 ChatGPT 3.5，因为它居然能写出相当不错的 Emacs Lisp 函数。虽然还只是单条函数，没办法再做进一步扩展，但我还是觉得非常震撼。

所以我也说不好，反正我当时提出的聊天导向型编程让自己成了那个超前的疯子——刚开始没人听，后来几乎人人都在用。光是 Claude Code 的用户群体，现在可能就占开发者总数的 10%、15%，甚至有 20% 了吧？我在 2024 年尝试推广聊天导向编程时，大多数人还在关注“补全接受率”呢。你对这个指标还有印象吧？

主持人： 有的，好像直到现在 VS Code 也在监控这条。

Steve Yegge： 没错，现在也还有开发者在使用代码补全功能。也正是在那个时候，我感觉自己好像能够预见未来了。我干这行有 40 年了，这 40 年间我一直在追求效率、努力让自己行动更快，所以我自然就对能进一步提效的要素拥有敏锐度。

当然，这其中也有不少障碍。首先就是 AI 经常出错之类，但我感觉这就像是很多游戏里最初级的载具一样，虽然还远不够完善，但至少比走路快。而且它未来一定会越来越快，不需要怀疑。

所以 Gas Town 负责把 Claude Code 引入编程回路，于是 Claude Code 就把对话引入了编程回路，对话又把问题引入编程回路。总之这就是 AI 渗透编程的过程，我们不断把更多 AI 功能引入进来，形成有可能解决一切问题的方案。当然，很多人也在对此发起抵制。Hacker News 论坛上就有不少反对的声音。

Steve Yegge： 也有。下一个转折点是 GPT 4.0。我们之前构建的编程智能体只有聊天功能，需要手动执行复制、粘贴之类的操作。这就带来了新的麻烦：一旦文件达到 800 行左右，经过修改就很难再完美复现。Nano Banana 哪怕到了现在也是一样，在编辑大量代码时经常会犯迷糊。

而 GPT 4.0 的转折性意义在于，它能在完成修改和编辑之后，完美复现高达千行的文件。这一点意义重大，因为世界上大多数源代码文件都不足千行。也就是说 GPT 已经能够编辑大部分文件并进行简单修改，而且这是在 2024 年年中就迅速实现了的。

下一个让我印象深刻的版本是 Sonnet 3.7，更具体地讲就是 Claude Code。我发过一条短短的推文说“我天，Claude Code 可真行！”，浏览量高达 30 万。

接下来的重大版本是 Opus 4.5，正是它促成了 Gas Town 的发布。如果没有 Opus 4.5，就不会有 Gas Town。不知道你还记不记得，当初 Anthropic 模型的更新周期大概是 4 个月，而到 2025 年初间隔就缩短到大约 2 个月。可能我们很快就能迎来 Opus 5 了。

所以我想提醒那些仍然在唱衰 AI 的朋友，你们的视野大约只局限于过去三个月，也就是只关注三个月前上一代模型的情况。这有点像没学过微积分的人，他们只能看到导数，却看不到斜率。

所以我从 ChatGPT 3.5 开始就一直在关注整个过程的加速发展，而且在软件行业这种加速发展已经持续了 40 年。Opus 4.5 的诞生可谓一石激起千层浪，让人们意识到它的智能水平已经相当够用了。

Steve Yegge： 确实如此。当然，它们仍有不小的局限性。3.5 和 3.7 版本都还不够完善，能够处理的数据量是有限的，强迫开发者把内容拆分成相应的大小才能使用。可如今 4.5 版本出现了，数据处理量的上限进一步提升，而且后续还将不断增长。

很明显我们正身处一个全新的世界。比如 Redis 和 antirez 的缔造者前阵子就正式发帖，表示在深度使用 Opus 4.5 和 Claude Code 之后，“我们手动编写代码已经毫无意义了”。这就是整个软件行业必须面对的现实。

Steve Yegge： 不知道你有没有关注，Anthropic 日前发布了一项更新，推出了 Tasks，并表示它的灵感就来自 Beads。我觉得他们做得非常好，也完全理解他们为什么不直接使用 Beads。

简单来讲，Beads 类似一款任务跟踪器，也可以说是一种智能体待办事项清单。它有三项非常有趣的特性。首先它是以图的形式存在，也就是任务图，类似于工作图、实施计划、GitCharts 乃至其他成熟的知识工作管理方式。它会把工作内容记录并拆分成字节，这些字节又会随着认知能力的提升而扩展。

Beads 这种把工作拆分成图的方式跟我们长久以来的实践相一致，只不过还多了另外两个要素。首先是引入了 SQL。毕竟图和数据库从来都不算完美，但 40 年的发展还是让它们至少还算完备。图的本质就是一大堆顶点和边。此外我们还引入了 SQL，因为有了 SQL 就有全面的数据库功能。

主持人： 是的，可以用非常接近 SQLite 的方式来跟踪思维过程。

Steve Yegge： 确实。有了 SQL，再加上 Beads 带来的顶点和边，事情就有了飞跃。我们在 Beads 的设计中就有用到 Claude，所以这里包含了大量 AI 认为非常重要的信息，而且它们会经常使用这些信息。例如它会记录 Beads 开启时谁做了什么。AI 非常看重这些信息，这能帮助进行取证、了解工作如何展开，并体现出工作执行过程中的各个层面。所有关闭的 Beads 代表已经完成的工作，打开的 Beads 则代表剩余的工作。Beads 本身会跟踪相应的点下面积及相关信息。

而让 Beads 如此神奇的第三大要素就是 Git，它负责提供一份记录所有工作的 Git 账本。它把工作拆分成易于访问的小块，各个小块之间可以相互引用。它采用图结构，可以通过数据库进行查询，而且所有数据都存储在 Git 账本之内，这就保证内容永远不会丢失。历史记录始终存在，因此在出现问题时也随时可以重建。

不仅如此，大家还可以查看这些账本，并确定智能体随时间推移的表现如何。我们甚至可以在账本上看到自己的工作内容，这就像一分便携式的简历。真的很棒，Beads 确实是个非常有趣的成果。

Steve Yegge： 如果是已经在使用智能体，那应该是已经在使用待办事项清单和 Markdown 文件了。此外还有什么呢？也许会使用 wiki 和数据库吧。但这些方案的问题在于，它们缺少 Git。

Markdown 最大的问题是没有能直接在数据库中查询的图结构。大模型每次查找时，都必须读取并解析 Markdown 文件才能获取相应的图结构。另外 Markdown 文件还会逐渐陈旧，这些都是问题。

但如果是认真用过智能体的朋友，在尝试了 Beads 之后都会有很深的感触。几乎每天都有世界各地的开发者主动跟我联系，类似“我开始使用 Beads，它简直是打开了新世界的大门，我也说不清是为什么。”

简单来讲，Beads 就像是大模型的“猫薄荷”，像一种记忆宝典。

一旦体会到 Beads 的好处，开发者们就想一直用下去。大模型总是顾头不顾尾的，只专注于你交给它的最新任务，哪怕之前的任务因此受到了巨大的影响，它也根本不会在乎。而且大模型连自己之前做过的事也不承认、或者说记不住。

但有了 Beads，这种情况就不会再发生了。因为它在面对问题时会提交一条 Bead，让开发者看到 Bead 是怎么跟智能体编排联系起来的。Beads 的累积其实就是工作的累积，开发者还可以根据需要添加规范，比如在 Bead 当中添加字段、注释、设计等等。

总之，只要任务描述得足够清楚，就可以把它交给智能体加以执行，再由另一智能体进行代码审查，并在通过所有测试之后提交完成。大家就这样把 Beads 作为智能体编排的基础。

它就像一整套内存，一套共享记忆体系。因为通过 Git 进行联合，它也像一套分布式数据库，可供用户在 AWS、GCP、Azure 乃至任何其他超大规模云平台的智能体上使用。这些智能体可以通过 Beads 相互沟通，不再需要依赖集中托管服务。所有操作都将通过 Git 仓库进行，非常神奇。

Steve Yegge： 是的，而且这种设计其实是个败笔，因为我的背景调查没有做好。我最早想要的就是 Git 加 Clade 再加 SQL，所以选择了最粗暴的方式把这几样硬塞在了一起。JSON 文件中的每行代表一个 issue，经常引发合并冲突；再把它通过 xls 插入到数据库中，这需要建立相应的守护进程，数据也可能过时。总之这是套非常糟糕的双层架构。

好在这些问题都将在下个版本中得到解决，大概就是未来几天的事。如果当初好好做背调，我就会意识到自己需要的是 Git 数据库。而在认真整理了所有需求之后，我发现已经有人解决了这个问题——我在亚马逊的老朋友 Tim Shen 搞了个 Dolt 项目，而我之前竟然完全没听说过。好在接下来 Beads 将转向 Dolt，一切问题也将迎刃而解。

Steve Yegge： 没错，这样三路合并的问题解决了，bad sync 的问题解决了，守护进程的问题也解决了，一举三得。而且我们仍然可以导出 Git 代码，仍然可以进行联合。Dolt 的联合方式跟 Beads 完全一样，就好像大家在立项之初就分别想到一块去了。但他们确实做得更好，已经为此投入了十年时间。

Dolt 还能嵌入 Go 语言，所以跟 Beads 天然绝配——只需要一行代码就能搞定。用户甚至感受不到任何变化，只是越来越好用。Dolt 还支持很多其他功能，比如字段级合并解析，还有新的历史记录与新的视图维度——比如键值存储等，这些都是我们以往没能实现的成果。

总之 Beads 就是个数据平面。之前有位贡献者添加了一条键值存储并引起我的好奇，我认真研究了它的运作原理，意识到这完全说得通。如果让智能体们靠这个实现记忆——

Steve Yegge： 对吧？Bead 虽然跟 GitHub issue 或者 Jira 之类的工具相比还算轻量，但仍然有点“重”。现在转为键值对，那就真的轻量化了。所以我想不妨试试，何况 Dolt 对于键值存储的支持也非常好。

我对 Bead 的发展态势非常满意。之前的代码库很差劲，是用氛围编程实现的，所以必须持续运行 CodeView 来检查。我的审查进度已经落后大概一个月了，所以现在的代码肯定就是一堆垃圾。它只是通过了测试，而且有人在用而已。不过再有几周甚至一周，我就能把一切都清理干净。我们会以 Dolt 为基础发布新版本，届时呈现在大家面前的 Beads 将成为一件精美的作品。

你提到“如果一条 Bead 的规范足够完善，就可以把它外包出去，交给其他人维护”。那在我们现在的智能体环境下，你是如何看待规范的？你和其他人参与了哪些环节？你是如何管理这些环节，又是怎样看待这些问题的？

Steve Yegge： 是啊，我真希望能再多认真想想。这对 Ralph Loops 来说是个根本性问题，我也跟 Geoff Huntley 就此聊过很多。就 Ralph Loops 来讲，我们需要详尽定义验收标准，否则就可能搞出一大堆错误来。

所以 Gas Town 的做法，或者说我的做法，就是：除非像 Dolt 相关部分之类非常非常重要的东西，否则我们只需要先实现一个近似版本。我们在主线上会投入所有努力，至于其他东西则可以逐步迭代。我们先搞个能发布的版本，然后慢慢修复其中的 bug。大概就是这样。

Steve Yegge： 我的工作流往往更强调迭代，所以很少花时间制定大量规范。但这确实是个很有意思的问题，毕竟这事非常花时间。Gas Town 引擎的功能非常强大，基本上所有时间都花在两种模式上面，也就是最大化或者最小化——当然，这里指的都是上下文窗口。

上周我跟 Anthropic 那边的同事进行了一次非常有趣的讨论。我接触过 Anthropic 一些非常优秀的团队，他们对 Gas Town 很感兴趣，认为它暴露出模型中的许多 bug。Gas Town 提出了很多变通方案，类似于对工人们做入职培训，确保他们在工厂里更好地完成工作。

在交流过程中，他们说 Anthropic 内部存在一种有趣的分歧。 有些人希望尽量减少上下文的使用，比如尽可能把任务的体量收窄、做拆分，一次只设定一个临时性任务。因为虽然现在的上下文窗口虽然越来越大，但随着 token 数量的增加，运行成本也会迅速增长。而且小体量任务的运行性能也会更好。总之他们非常关注性能和成本问题。

另外一类人则倾向于最大化路线，也就是尽量增加上下文的容量。他们会在上下文窗口里塞满大量丰富的信息和指令。

大模型就是最大化一派的成果。大模型不仅明白用户想要什么，还能理解为什么要做这件事，所以它的决策、特别是在战略决策方面的表现就非常出色。

于是他们问道，“那 Steve，你更支持哪一派？”我觉得这事真的很有意思，因为 Gas Town 中也包含“polecats”的概念，负责处理那些明确定义的临时性工作，用完即弃。它们负责的就是小规模工作，一次只作一件事，把任务拆解开来，逐个完成、逐个产出。这就像工厂在以流水线形式生产代码。

但还有很多工作跟设计有关，需要我们进行深入思考，也需要跟大模型进行沟通。这往往要求我们为模型提供大量背景信息，提醒模型这是个非常棘手的问题。每当我在处理代码时遇到最困难的部分，都会提醒模型“注意这是个难题，不只是常规的修复，而需要弄清楚整个问题出在哪里，还有它怎样跟系统融合对接。”就是说我需要为模型提供丰富的背景信息。

所以我准备了一系列文档，内容也是逐渐深入，然后展示给大模型。Anthropic 团队的成员比较支持这种工作流，而“polecats”也有自己独特的价值和意义。我认为这意味着两种工作流都很重要。而且作为工程师，我们自己也需要在这两种工作流间来回切换。

但随着时间推移，我们肯定会迈向那种需要大量思考的工作，即大模型会负责所有编程工作，而一切复杂的设计工作则归人类处理。这也是我在自己上一篇博文中提出的判断。

我们真正要做的，是为有待解决的问题编写引导加载程序。那么，我们该如何获取准确的上下文和数据，从而找到真正相关的信息？我很好奇你自己是怎样管理的，或者说你在 Gas Town 内部是如何管理这些的？对于不同类型的任务，其对应的启动加载程序又是怎样的？

Steve Yegge： 在 Gas Town 之前，我是用 Beads 实现工作流自动化。我猜很多人用的都是这种方法，哪怕是不用 Beads 的时候也有其他可行的替代方案——关键在于了解它们的各自专长，然后充分加以利用。这些方案最擅长的就是建立待办事项清单，处理繁琐的流程、建立验收标准并逐项检查。

所以在启动阶段，我希望处理那些在关闭阶段没做好的工作。比如说查找分支、暂存区、未合并的工作等等。Beads 就是这样，它在启动时会清理沙箱、清理环境等等。总之这些指令都被我整合成了提示词。

对很多工程师来说，现在的新挑战就是管理好自己的提示词库，并根据需要随时调用。Gas Town 的初衷其实是，如果能有一些预设的提示词并在特定角色上线时自动起效，结果会怎样。而这一切都基于这样一个假设：当 Claude Code 能够真正自我运行，会发生怎样的改变？

当然，启动和关闭都很重要。所以我写了一条名叫“飞机降落”的提示词。我有个同事就提起过这条提示词，他从没用过 Gas Town，之前只用 Beads。他觉得“飞机降落”非常实用。我用这条提示词也有六个礼拜了……天哪，怎么感觉像过了六个月。

主持人： 现在技术变化太快了，时间也被同步压缩了。

Steve Yegge： 现在时间真的太紧了。好在“飞机降落”真的好用，智能体不光能成功完成任务，还会列出长长的清单加一大堆生动的表情符号，帮助项目快速就绪。

主持人：Anthropic 的模型特别喜欢搞拟人，GPT 则更加戏剧化。我明白你的意思。

Steve Yegge： 只是 GPT 模型不擅编程，但也无所谓，它真的很好玩。

主持人： 这又是另一个话题了。我发现 GPT 5.2 在生成特定类型的代码和提示词方面非常有效，只是速度慢得令人发指。

Steve Yegge： 我听说 Gemini 3 在 UI 编程方面很强，可能已经不逊于 Claude 了。

主持人：UI 编程一直是 GPT 的弱项，它表现太差了，实在是太差了。

Steve Yegge： 是啊，也许不同的大模型最终会发展出各自的专长吧。Claude 更重视验收标准，“飞机降落”就是利用了这一点——有点像利用了它的强迫症习性，通过相应的条件确保它把事件做对。因为哪怕缺少上下文信息、上下文窗口也几乎被占满，当严肃程度达到“飞机降落”级别时，Claude 也会查阅操作说明并开始逐项核对，最终完成任务。这也算是一种调试思路吧，总之“飞机降落”确实让 Claude 更加可靠、尽量不遗漏事项。大模型确实掌握着海量的常识，但却容易分心。“飞机降落”就是用来提醒它们保持专注的。

这些都是我们在开发过程中需要磨练的技能，准备就绪之后才能真正投入到像 Gas Town 这样的复杂项目当中。我们得特别擅长把上下文信息融入到大模型当中，观察整个分类和处理过程。在亲自动手操作一段时间之后，大家就能信心满满地同时处理多个这样的项目了。

Steve Yegge： 我们可以从多个不同角度来看待 Gas Town。按最简单的理解，它属于一种编排器，跟长久以来的 Devin 等等都差不多。大家都希望能让多个编程智能体以团队形式运行，或者在特定任务上并行运行再匹配一些跟踪层，基本就是这个意思。

还有 Geoffrey Huntley 打造的 Ralph Wiggum Loop 和 Loom Loops，再就是 Claude Flow，那款带路由功能的高级工具。Gas Town 也属于这一类，以编排器的形式帮助用户运行多个编程智能体，而且现在跟 Claude Code 的联系非常紧密。Claude Code 的能力边界经常被触及，用户对智能体的要求很高，因此经常会出错。所以直到足够强大的 Opus 4.5，才能够可靠运行 Gas Town——而且哪怕如此，崩溃情况也不少见。

总之 Gas Town 的理念非常简单。我来解释一下，随着大家对大模型的信任度不断提高，开发者也开始意识到自己正越来越依赖智能体。这里讲的信任，是指能够更好地预测大模型接下来会做什么，这也是信任的基本前提。当然，这种可预测性需要通过实践来获取。而且目前这一切只发生在开发人员身上，而不久之后全体知识工作者都会面临同样的挑战。

有趣的是，信任度越高，用户的耐心就越低。因为大家习惯了认为只要把任务指派给一批智能体，它们就应该可以顺利完成——毕竟之前它们已经成功过好多次了。甚至连测试都想要交给智能体。这样之后每次遇到新任务，我们就习惯性地再添加一个智能体，最终由此形成新的开发常态。

Steve Yegge： 没错，现在大家运行的智能体越来越多，这就让单个开发者遇到了以往只有团队才会遇到的问题。 智能体之间还会相互干扰，导致我们忘记哪个智能体在做什么。智能体之间还会设置网关，彼此等待和配合，情况由此变得愈发复杂。当规模达到一定程度，即使我们使用 Beads，也没办法在脑袋里追踪所有信息——这简直就是一团乱麻。

这就是 Gas Town 灵感的来源：“如果把它们都放进类似工作树的层次结构当中，再给它们明确命名，结果会如何呢？Beads 已经实现了巨大突破，但为什么不把整个想象空间都填充起来呢？”

还有个关键，大模型特别擅长处理自己在训练期间接触过的内容。而且训练时接触的越多，大模型就越擅长、越喜欢用。比如说从上世纪 70 年代就存在的邮件系统，对大模型来说就最最熟悉，也更倾向于使用。因此只要把智能体跟 ID、收件箱之类的设计结合起来，智能体间就能相互发送邮件——事实也确实如此。

于是很快，我们就有了这样一个由合作智能体构成的“城镇”，它们通过邮件彼此沟通。我会给它们设定头衔，比如你是镇长、你是 polecats 之类。我还会按《白雪公主和七个小矮人》给它们设定名字。这样观察下来，它们的运作方式就特别有意思——我就见过“镇长”指派其他智能体回归岗位、处理工作的情况。

它们的表现有时候甚至会超越我的预期。有一次我记得自己有大概 30 条 beads 有待处理，结果突然不见了，在惊慌中我意识到它们应该是都被成功修复并关闭了。哇，这种感觉真的非常神奇，是种以往从来不曾有过的体验。

Gas Town 就这样横空出世，打破了人为管理智能体的蒙昧时代。

而这又衍生出一种新的模式：只要给智能体定下了运行规则，接下来就要放心让它们自主运作。这其实有点反直觉，我发现大多数人都会一直盯着智能体，害怕它们会犯错，然后每次出问题都大惊小怪。

连我自己也是这样，大概持续了六个月吧。我尝试观察每个智能体，想要及时发现它们犯的错。

而一旦想通了这个道理，我们就会意识到智能体就像普通工程师那样，是肯定要犯错的。犯错并不值得大惊小怪，真正要关注的是那些宣称完成了任务的智能体。因为宣称完成跟真实可用之间还有距离，还需要我们人为引导。当然，如果实际完成了更好，我们可以跟智能体继续讨论接下来该做些什么。

在后续交流中，我们可以跟智能体进行精彩的设计讨论，比如“如果放弃数据库、尝试其他方案，结果会如何？”当这个智能体开始思考和实验之后，我们再挑选另一个智能体，给它指定新的难题。这就是我自己目前对 Gas Town 的使用方式，给每个智能体都安排难题。而且让人意外的是，十个难题里有八个都可以顺利完成， 不过余下两个就被直接丢弃了。这点也比较烦人，我经常会意识到自己面对的某些问题之前是考虑或者遇到过的，但往往找不到之前的设计流程了，还得从头再来。

Steve Yegge： 我明白，整个使用体验确实让人相当沮丧，我有时候也会忍不住朝它怒吼。比如“我都跟你们说过无数次了，别提交 PR。我们只是做维护的，提示词里不是写了吗？！”但智能体还是在那里擅自提交 PR。但后来我意识到，这其实都是我自己的错，而且是有解决办法的。Claude 直接提供预用的钩子，只要在这里设置不提交 PR，问题就不会再出现了。

所以大家要意识到，目前是技术发展得太快了，我们必须努力保持住非常平和的心态。毕竟智能体已经在做事了，而且效果也是越来越好，只不过我们内心的预期和目标在随之提高。总之这代表着一个全新的世界、全新的时代，不能再用老眼光来看待。

但我也很理解你的感受。现在我感觉自己就像工厂厂长，带的还是一支新组建的团队，感觉“员工”们都很懵懂。它们很聪明，但彼此间的配合总是磕磕绊绊。

Steve Yegge： 肯定有啊。你有没有跟那种特别特别优秀的产品经理共事过？就是那种技术非常精湛、曾经编写过大量代码，只是后来转为产品经理的同事？

主持人： 有过一次。

Steve Yegge： 有过一次，这就够了。你说得没错，这样的人才简直是无价之宝。实际上哪怕是像谷歌这样拥有极强技术积累的大厂，这类人才的比例相对很高，但也肯定达不到 100%。面对那些真正优秀的同事，大家几乎可以跟他们讨论任何架构细节。他们了解各种技术概念、知道怎么做性能调优，还有各种任务的执行时长等等。

他们会讨论类似“导出时间太长了，咱们试试用缓存吧”的问题。优秀的人就是这样，Uber 的技术主管也是如此。你之前有跟 Uber 或者其他硬碰硬的技术主管共事过吗？那你应该能体会，这些优秀的人才会整合所有团队的整体视角。这种情况下，我们自己扮演的就是工程领导的角色，比如产品经理、技术项目经理、高级工程主管等等。总之，任何希望深入了解机器运作原理的人，都得做好担任这类角色的准备。

其实这才是最重要的。通常情况下，重要的不是用什么语言来编写，也不是语法、链接器或者其他细节。最重要的是它能做到什么、功能规范是什么等等。我们现在之所以能够快速构建软件，就是因为前人解决了功能规范这项艰巨的任务。

Steve Yegge： 我需要记住 Beads 和 Gas Town 的所有细节，包括大家引入的所有集成点。我经常跟大模型讨论，比如“不好意思，我们的插件系统是怎么运行的？另外某项功能又是怎么运行的？我还真记不住了。”

上次检查的时候我确实有参与、也亲自批准了，但现在我早已忘记了具体运作方式。所以我必须回头重构构建一遍，这就是持续起效的纪律体系，也是不能丢掉的重要习惯。我们必须定期审查自己从未见过的代码，必须不断审查并提出问题。只有在细节上从各个角度都已经充分考量，我们才能像那些最出色的技术主管那样断言“行了，所有细节都已经涵盖到位，我们不再需要进行任何代码审查了。”

产品也是一样。我们必须了解产品的每一个细节。如果既不了解、也不使用，那为什么要编写这些代码？所以，我们必须积极精简代码，淘汰那些没有发挥应有作用的功能。如果做不到这些，技术债就会像山一样高。

我再澄清一下。很多人会说“不理解是因为没看过代码，看过代码肯定就理解了”。但这是种非常初级的心态，只有经验不足的人才会这样理解。领导过团队、参与过大型项目的朋友不会这么想。我曾经在海军的核潜艇上服过役，我们开发的软件项目在复杂度上也是不遑多让。别忘了，核潜艇可是有足足六层楼高、好几个足球场那么长，而无形的软件项目跟那差不多。所以很多人对软件的理解还太青涩。

让我好奇的是，我连自己当下正在做的工作的心理模型都很难跟上，真的还有余力领导一整个智能体团队吗？我得跟进 N 名同事，这些同事每人都有 N 个智能体在替他们工作。这个问题会迅速扩大，所以你在这方面有没有用到过什么有效的工作？Gas Town 是怎样以更容易理解的方式展现这些内容的？

Steve Yegge：2008 年时我曾接受过一次采访，同样参加采访的大概有十位颇有声名的从业者，其中一位就是 Peter Norvig。除此之外还有 James Gosling、Guido van Rossum 等等，我们都受邀回答同样一组问题。

对于其中一个问题，我觉得 Peter Norvig 给出了历史最佳级别的回答。题面大概是：优秀程序员应当拥有怎样的特质？其他人都滔滔不绝讲了一大堆，而 Norvig 回应说“能够把整个问题都记在脑子里。”就这么简单，而且直接扼住了问题的咽喉。

事实上，成功团队与失败团队的区别就在于，前者能够把更大的问题容纳在脑海当中。而大模型正好擅长处理这种跨职能沟通与协调，帮助降低相关成本。当然，大模型的介入会让产出速度加快，所以问题本身也会进一步加剧——这就是项目管理中的所谓杰文斯导论。

我曾有位技术能力不太强的上司，但他非常擅长调度副手、顾问和资深首席工程师，也信任这些人来指导决策并领导团队。有了这份识人之能，再辅以他自己的领导魅力，使得整个体系非常高效。我觉得像亚马逊这样的巨头也直接采用了这样的模式，由此形成一种行政 - 技术双重管理架构。 其中既有经理，也有技术顾问或者技术负责人。我认为整个行业都在朝着这个方向发展，让每个人都能获得技术顾问的协助。

我之前写过一篇博客，讲的是我有两个朋友因为同事交付晚了两个小时就冲对方大喊大叫。这俩朋友每人都管理着 20 个智能体。他们意识到，原来有智能体当帮手可以把工作效率提升这么多。当然，他们需要想办法以透明、主动和公开的方式分享自己的工作成果，这又是新的问题了。总之开发的世界变化实在太快，工作方式和瓶颈都在迅速更迭。

结果就是，这俩朋友跟同事闹得很凶。因为对方说“我用这两个小时实现了这项功能……”朋友们问“为什么，实现它干什么？”对方回答之后，朋友们说“那是两小时前的情况，你脑子有病吗？这两小时之间我们又做了六个决定，结果你还在处理之前的问题。”这就是新的现实，无论喜不喜欢都必须适应。

Beads 和 Gas Town 为这场软件开发狂飙又添了一股助力。再就是 Opus 5、Opus 5.5 等未来将要出现的模型新版本，也许可以让编排器运行更加流畅，甚至让智能体产出质量达到更值得信任和使用的程度。我有感觉，其实我们离那一天已经不远了。

Steve Yegge： 好的。正如我刚刚所说，双重管理架构已经影响到每一个人。我们既是经理、又是主管，掌控着一整个软件工程团队的运作。由此开始，我们的软技能、人文素养、教育背景、认知观念乃至人际交往能力都会变得非常重要。

比方说我们编写了 30 万行代码，现在想把它移交给另一支团队。对方可能会说“我们看不懂你的代码。”因为代码量太过庞大，任何内容都得像谈判一样反复确认和协调。这肯定会让团队乃至整个公司感到异常苦恼。

这时候沟通能力越强，解决问题的思路就越是清晰。就是说我们必须以行政角度、成员管理的角度审视这一切。开发者必须学着搞清楚谁需要什么、谁在做什么，谁天生具备哪些技能、谁又天生不具备等等。当然，这些技能也是可以培养、发展和学习的。

所有知识型工作未来都将以这种方式运作，这时候我们就从纯粹的人进化成了“半人马”——是不是还挺形象的？头脑是人，但肌肉是马。你知道“半人马”这个比喻是谁提出来的吗？

主持人： 我也不记得它的起源。但我在网上看到过，有人说这是 Bobby Fischer 发明的，最早用来描述 AI 辅助国际象棋。可问题是最终“半人马”是怎么构成的？AI 当头、人类当身体，还是说人当头、AI 当身体？

Steve Yegge： 这个概念火了之后，会有人跳出来唱反调，说“无聊”或者“混合体”之类的话。但实事求是地讲，每个人都会拥有自己的 AI 好友、AI 助手，它会渗透进我们的生活。你尝试过 Claude Cowork 吗？

主持人： 我还没试过 Cowork，但我已经试用过 Claude Code 和 Codex。我能明白这里的潜力和未来的想象空间。

Steve Yegge：Claude Cowork 其实就是面向更广泛人群的 Claude Code。那些唱衰的朋友，今年之内肯定会经历一番思想观念的大颠覆。有些人会从中收获快乐，也有很多人会因此放弃知识型工作。但肯定有一部分人就是不喜欢什么“半人马”式的组合，就不愿意跟 AI 一起工作。

Steve Yegge： 我有个朋友，他是世界上最优秀的工程师之一，在亚马逊和谷歌这样的大厂开发出过无数产品。他坚持认为，使用大模型能够显著提高产品质量。这是因为他的用法跟大多数人不一样。大模型给了我们更多选择，而他从中选择了质量更高的产出。

具体来讲，他的做法是审查所有智能体的成果，由此建立起一套结对编程的实践。这样肯定效果更好，把人和 AI 的优势融合了起来，实现了既优化吞吐效率、又提升质量的效果。对于像 Dolt 这样的项目，我会把质量诉求拉到最高，进行一轮又一轮代码审查，之后再把成果交给 Dolt 团队再审查一遍。这就是我的看法，质量是种选择，就这么简单。

具体来讲，你怎样判断什么样的时机最合适，什么时候质量比产出效率更重要？在做出判断后，你个人又会优先调整哪些参数？

Steve Yegge： 对我来说，这样的判断并不难做。毕竟作为得到无数开发者认可和依赖的项目，Beads 现在已经不容有失了，所以质量保障自然非常重要。我会对 Beads 做非常充分的测试，测试代码量甚至远多于项目本体，而且未来也肯定是这样的路子。集成测试也差不多。验证和确认都很重要，而这两点就是我最需要关注的问题。

另外还需要注意一点，也是我们面临的一大新挑战：AI 解决了旧的瓶颈问题，但新的瓶颈已经出现。其一是合并问题，其二是共享设计以及如何保持设计更新的问题。我们之前也提到，合并问题尤其棘手。因此 Gas Town 才专门设立了所谓“精炼厂”，尝试指定专门负责合并的人员来处理合并方面的难点。

而且有趣的是，我把 Gas Town 给 Anthropic 他们展示过，他们觉得 Gas Town 成功规避了他们模型中的一堆 bug。

也就是说，AI 的层次结构将会扁平化。我们不再需要那么多角色，因为其中半数角色只是权宜之计，未来的智能体可以更好地“各司其职”。在 AI 能意识到自己的职责之后，整个体系会非常简单。我认为最终会形成非常扁平的层次结构，或者只有两层、最多三层。 因为从组织角度来看，我们应当充分利用这种优势。当然，对于规模特别大的项目，智能体可能也会选择更复杂的层次结构，我认为这就是未来的整体发展方向。

我认为这就是大家今年之内必须学习的技能，也必须重视由此带来的成效。总体来讲，AI 给资深员工带来的收益会比初级员工更多，因为前者更能理解什么叫做“好”。没错，现在我们还处于 AI 不知道什么叫“好”的阶段，所以资深员工仍有一定优势。

再次强调，对于资深工程师来说，验证和确认往往更为简单，一眼就能判断。但如果身处全新领域、面对全新的编程语言和应用场景，那这样的判断就比较困难了。而我会尽量避免在这类场景和开发需求中大量使用智能体。

Steve Yegge： 我一直忙着开发 Gas Town，所以腾不出手来做其他方面的尝试，比如在 UI 编程方面表现如何。我知道 Gas Town 还有很多 bug，但它的普及速度太快了，用户们宁愿无视我的警告也要大量使用。所以我得把时间都用在完善 Gas Town 上，暂时没空探索其他方向。

Gas Town 经常出毛病，甚至偶尔会失控。前几天我就关闭了机器上的 320 个 Claude Code 实例，每个实例大约占用 1 GB 内存。当前整个体系还很不稳定，但已经让我们看到了新时代的曙光，这绝对值得大家兴奋莫名。

至于要不要为普通用户开发成果，我还不太清楚。目前我的全部注意力都集中在 Gas Town 身上，思考它的长远发展方向、存在的意义等等。这是我眼下最重要、最需要解决的议题。

Steve Yegge： 是的，我能做的就是降低参与讨论的门槛。在 Gas Town 之前，我只是个软件开发博主，认为未来的 AI 会越来越强、人们会运行大量智能体之类。但 Gas Town 诞生之后，我用 Nano Banana 为项目生成了一整套角色形象，甚至还有项目主题曲。大模型真的牛，在艺术创作方面强得让人意外。

于是在一夜之间，似乎每个人都可以参与到对话中来。很多用户之前还觉得我的观点纯粹是放屁，但现在变成了“有点激进”。没办法，每个人都得承认 AI 正在自我构建，这种自我构建让智能体集群真的很可能成为现实。

很多人觉得这样的趋势让人感到不安，觉得自己好像成了蜂群意识中的一分子。这就像《安德的游戏》照进了现实，有些人接受不了也很正常。

Steve Yegge： 确实是这样，这个比喻很贴切。当初我给朋友们介绍 Gas Town 时，他们首先想到的就是编译器，而当时 Gas Town 还没有真正能够自我构建呢。这种感觉也很神奇，就像是打通了一条时空隧道，直接通向一个全新的软件宇宙。

接下来我们开始建立基础设施，类似于现实中的城镇。通过一次次迭代和突破，Gas Town 终于实现了自给自足，而 Beads 就是其中的活动信息流。当 Bead 关闭，则代表一个事件。

身份也不需要独立出来，身份也是一种 Bead，代表数据计划。但就在我觉得一切都说得通的时候，项目出问题了，就是跑不通。

时间来到 12 月 28 号，突然之前 Gas Town 中的“镇长”开始大量返回报告：这项功能已完成、那项功能已完成……我当时就懵了。怎么回事？我什么都没动，但各项任务突然就开始跑通，整个体系运行起来了。这套“编译器”，开始成功进行自我编译。我当时真的特别兴奋，毕竟距离新年还有两天，于是我决定赶紧让它上线。这就是 Gas Town 的来历，我最终让它成功实现了自托管。

Steve Yegge： 说真的，我觉得 Beads 和 Gas Town 构成的这套系统，就代表着我从业以来想要完成的终极目标。类似于极其复杂的 Wyvern 属性体系，也有点像 JavaScript 中的瞬态属性。

比如在游戏中喝下一瓶药水，它会在一段时间内持续增加生命值。但如果退出游戏，这个效果应该马上中止。这就是永久属性和瞬态属性的概念。事实证明编排也是如此，除了固定任务之外，还有各种维护性质的零散任务，再加上内置的资产继承等机制。总之这是一套非常复杂的模式。

这就需要一套事件系统，就跟游戏中的事件系统一样。它的基本框架类似于操作系统，但随着加进各种界面，游戏的样貌也逐渐展现。前几天我在 X 上看到一篇同人帖，说是 Gas Town 彻底乱套了，工兵角色开始跟镇长争着当老大。虽然这只是虚构，但也并非完全不可能发生，某种程度上相当真实。

我觉得我们确实会发展到这样的程度：智能体慢慢变得像角色扮演游戏、策略游戏乃至即时战略游戏。我觉得我们离那天已经不远了。所以，我想就应该更进一步、做更积极的探索。

这肯定是件非常了不起的大事件。可能到今年年底，人们就会像玩游戏那样开发软件。 以往很多高度复杂的软件需要一整支工程团队、甚至是大厂那样的组织形式才能完成，而普通人根本不可能具备这样的经验和资源。而未来软件开发将迎来爆发式增长，而且会遍地开花。正如 YouTube 让每个人都能发视频，社交媒体和手机让每个人都能发帖，大模型未来能让每个人都能开发软件。

Steve Yegge： 刚刚提到，我有两个朋友因为工作节奏太快跟同事吵起来了，这也让我担心后续还会发生什么样的情况。我也跟其他业内人士聊过，他们在工作中使用 Codex、Claude Code 或者 Gemini 等 CLI 工具的效率远超同事，也因此在绩效考核中占据了绝对优势。这肯定会动摇招聘乃至整个传统面试流程，进而影响到软件开发的方方面面。

由此 所有瓶颈都开始转移。 有些业务团队明显适应不了，因为他们还没准备好，工程团队已经把他们想要的东西交付过来了。也有一些业务团队因为无法容忍长期等待工程师的交付，所以开始自行开发软件，毕竟有了 AI 助手这些都是可以实现的。

所以就像亚马逊那边的“双披萨团队”，把一群想要解决问题的专家聚在一起，共同出谋划策。其中可能只有一位工程师就够了。展望未来，可能所有工作都开始向“零工经济”转型。比如项目中的产品经理只需要参与一个礼拜，或者偶尔引入一名用户体验设计师。既然都是临时的，那租赁肯定比长期招聘要划算。

这样公司内部的经济模式就很像 Airbnb 了——好吧，这个例子可能不太恰当。或者说，更像 Uber 吧。零工经济和员工租赁开始成为主流。谷歌早就这么做了，SRE 有自己的特定办公时间。总之随着氛围编程的普及，每个人都可以为同一款大体量产品贡献力量，共同参与构建。这将是一种更加动态、灵活的工作模式，人们可以根据需要随时提供助力。

回到你之前的问题，我认为传统的规划方式已经过时了。未来成功的企业会实时开发产品，开发出鲜活的软件成果。目前我们看到的很多，就是未来软件开发形态的雏形。

测试环境当然也会存在，我们可以启动多个类似的环境来尝试不同的方案，然后放弃掉其中跑不通的方案。整个效率将大大提升，而且规范也不再必要。未来真正需要共享的只有理念，也就是开发软件的理由。

这将彻底颠覆企业的运营方式，信息孤岛将被彻底打破。以往，很多官僚出于自身利益而操纵体系，比如努力保住自己的职位、或者逃避工作内容等等。但他们终将被揪出来并剔除出去。而且我认为，这样的机制会奖励那些真正擅长跟 AI 合作、跟其他人合作的从业者，奖励那些能够在庞大且混乱的环境中推动事物发展的人们。当然，这只是我自己的看法，你觉得呢？

但这段旅程真的很奇妙，对吧？我现在管理着一支智能体团队，编写的代码量比我之前全职作工程师时还要多。

Steve Yegge： 是啊，当所有齿轮都完美啮合、顺畅运行，程序员就能充分体会到创造的乐趣。整个工作就像是一场游戏，不停地获得多巴胺的刺激。这就像在玩电子游戏一样，简直让人上瘾。人们会像玩游戏那样沉迷其中，一开发就是好多个小时。

我们离这个目标越来越近了，因为传统的编程就挺让人上瘾的。我们喜欢全神贯注，不愿浪费时间去折腾什么愚蠢的 JS 库之类。现在最好的时机终于来了。

主持人： 我认识很多这样的开发者。我自己昨天在机场里也差不多，其实 Wi-Fi 信号很不好，我也本来想去趟洗手间、买点吃的之类。但我不愿意动，因为我刚启动了一批智能体，想看看它们会做什么，想要持续关注。

Steve Yegge： 没错，我觉得编程智能体用起来就像在玩二十一点或者老虎机。只要开始信任大模型，我们就会不断启动新的智能体，并最终习惯这种总有智能体在运行的新常态。

就像那种能挂机的游戏。随时可以看看自动完成的日常任务做得怎么样了，随时去领取奖励。这种智能体加编排器的组合会变得像让人上瘾的电子游戏。这对我来说真的很值得期待。想想看，如果所有知识工作都能被拆分成一个个小块，并把这些小块跟世界上的每个人匹配起来，让大家都能参与其中、开发自己的软件，并从中获得乐趣。

这就是技术的大众化普及，我个人对此非常期待，但也有人对此感到害怕。无论如何，人们会越来越被自己所能创造出的事物所震撼，我对未来非常乐观。

Steve Yegge： 我想分享自己的一项发现，这也是专门为咱们这期节目准备的独家猛料。

主持人： 好啊，这可是首次公开哦。

Steve Yegge： 我觉得我找到了判断软件产品能不能在 AI 时代活下去的万能公式。

应该有很多朋友在关注这个问题吧。很多公司都在担忧，觉得 AI 正在吞噬软件、吞噬工作岗位、甚至吞噬整个行业。Stack Overflow 已经受到了冲击，家庭作业辅导软件 Chegg 也消失了。还有客服中心，集成开发环境（IDE）等等。

那我们要怎么判断一款软件能不能在 AI 时代生存下去呢？我觉得可以用热力学来尝试解释。谁的软件有利于节省 token，AI 就倾向于使用谁的产品，这样项目就能生存下去。计算器也好、数据库、存储系统、账本、事务处理系统、路由器、网络、基础设施等等都是如此。任何需要大量计算和数学运算的项目，只要是大模型自身就能完成的，那就必然灭亡。

主持人： 明白了，就是说只要 AI 学会了使用工具和写代码，那就有着无穷的可能性。

Steve Yegge： 没错，它们确实会这么做。它们会编写代码，也会使用工具。所以它们会进行大量的矩阵乘法运算。但 AI 都很懒惰，总是选择最短路径。因此，你会遇到一些障碍。所以最重要的就是怎么让自己的工具或产品进入 AI 的视野，这样 AI 才有足够的动力来了解并使用。

大家可能听说过一款叫 Serena 的产品，这是一款开源软件，利用 LSP 服务器加 IDE 来节约大量 token 只要把大模型接入 Serena，它就会优先使用 Serena 来替代 Grep。由于代码库中的所有代码都经过预先索引，所以无需 Grep 就能快速找到目标位置。事实证明，它确实可以节约大量 token。

所以对大模型来讲，这是一种更节能的运行状态，也必然成为一种更优选。

Steve Yegge： 确实证明不了。但无论如何，浪费又低效的方案终会被放弃，大模型会选择更有效率的选项。目前编写代码的效率更高，后续如果出现了效率更高的工具，大模型也会选择使用。比方说只要能在底层解决问题，那 CPU 的计算周期要比 GPU 周期成本更低。

说实施，我认为 NPU 甚至人工神经元的成本更低。而且人类实际上更擅长某些任务，把这些任务交给人做成本更低。就像《黑客帝国》里那样，导演说人类的大脑被当作计算单元来使用，这个预言其实还挺准的。

总之，要想在 AI 的冲击下生存下来，就必须像 Beads、Dolt、MongoDB、Temporal、Kubernetes、Kafka、Cassandra 这类基础设施那样成为 AI 的优先选项。

只要能让大模型知晓你的工具，那项目活下来就不成问题。 大模型可以使用这类工具降低热量损耗、节省任务处理所需要的 token。你觉得我的观点有道理吗，你认同吗？

Steve Yegge： 关于这个问题，我觉得同样可以用热力学系统的特性来解释。任何任务，最终都可以用 token 消耗量的角度来审视。比如说 RAG 系统就是为此而生，后续还将有更多同类系统不断涌现，并成为大模型倾向选择的优先选项。

Karpathy 还有不少 AI 研究者都相信，未来的 AI 能够解决一切问题。如果判断准确，那么两年之后我们的手机里就用不着安装一大堆 APP 了。只要一个 Claude 足矣，它无所不能而且用起来特别上瘾。 只要 Claude 能做到，其他软件就没有存在的意义了。只有它涵盖不了的部分，比如设计精良的游戏、无法访问的数据存储，或者已经拥有强大使用惯性的老牌产品，才有可能继续生存。

这会是一种前所未有的新体验，而且 AI 会变得越来越根深蒂固，让人们建立起更强的依赖性。

Steve Yegge： 是的，现在的 AI 甚至连时间都还看不懂，但未来的 AI 也许根本不需要去读时间。这个世界变得太快了，一切皆有可能。

Steve Yegge： 我打算再看看 Arthur C. Clarke 的书，他其实准确预言了很多事情。只是他在科幻作品中提到的是外星人，而现实中是 AI。全人类正面对一个十字路口，未来可能通往光明、也可能通往黑暗。我完全相信这一点，而有些人正排队朝着黑暗那个方向前进。

想象一下，这将建立起全球统一的支付通道。有了它，世界上发生的任何事件都能提取交易信息。于是统一的工作通道、统一的运行通道和统一的社会体系都将由此产生。

但这又会让万事万物都笼罩在监控之下。我个人对此有点担心，总之 AI 将成为这个十字路口上的推动因素，很多人也肯定会站出来做出大规模反抗。总之，全社会都会以前所未有的方式在 AI 问题上站队。

原文链接：

https://softwareengineeringdaily.com/2026/02/12/gas-town-beads-and-the-rise-of-agentic-development-with-steve-yegge/

声明：本文为 InfoQ 整理，不代表平台观点，未经许可禁止转载。