Gas Town：面向 2026 年的 AI 编程代理编排系统

核心问题： 在 AI 编程时代，当我们在开发环境中同时运行数十个 Claude Code 或类似的 AI 编码代理时，如何避免混乱，确保它们高效协作而不是互相干扰？

回答： Gas Town 是一个全新的 IDE 概念，它不仅仅是一个代码编辑器，更是一个专为 2026 年设计的 AI 代理编排器。它通过类似于 Kubernetes 的架构，解决了管理大量并发 AI 实例时的“Yak Shaving”（繁琐琐事）难题，让你能像管理一支超级智能开发团队一样，专注于核心创意与架构。

什么是 Gas Town？

如果你是资深开发者，你可能已经体验过使用 Claude Code 或其他 AI 编码助手（如 Codex, Gemini CLI, Amazon Q Developer CLI 等）的强大能力。然而，当你试图同时运行 10 个、20 个甚至 30 个这样的实例来加速开发时，混乱随之而来：任务进度难以追踪，上下文容易丢失，代码合并变成噩梦。

Gas Town 应运而生。它的核心目标是解决这些管理上的琐事，让你能够专注于“你的 Claude Codes 正在做什么”，而不是“如何让它们运行”。

这不仅仅是个人效率工具的升级，这是一种新的工作流范式。正如作者在之前的文章《Revenge of the Junior Developer》中所预测的，未来的编程不再是单打独斗，而是将多个 AI 代理像骆驼一样捆绑成战车。Gas Town 正是这个战车的驾驶舱，它让同时使用 20-30 个代理变得可持续且高效。

Figure 2: The 8 Stages of Dev Evolution To AI
图片来源：Nano Banana via Medium

为什么你需要 Gas Town？不仅仅是“代理的 Kubernetes”

核心问题： 现有的 AI 编码工具缺少了什么关键环节，以至于我们需要构建像 Gas Town 这样复杂的系统？

回答： 现有工具只是孤立的“代理实例”，而缺少统一的编排层。目前行业只是在盲目模仿 Claude Code 的 CLI 形式，而 Gas Town 提供了大规模并行工作的底层架构。

在当前的行业状态下，大多数公司和开发者都在追逐 2025 年的 CLI 形式，生产各种外观雷同的克隆产品。这就像一群小孩子在踢足球，只盯着眼前的球，而没有思考比赛的整体战术。Gas Town 则是下一阶段的产物——它关注的是 AI 工作流和“代理的 Kubernetes”。

作者将 Gas Town 描述为一个“自持机器”，它必须具备自我维持的能力，因此引入了许多组件。虽然这看起来很复杂（有人说像 Kubernetes 和 Temporal 生出了一个并不好看的孩子），但它是必要的。Gas Town 的复杂性源于它需要处理真实世界中大规模 AI 协作带来的所有边缘情况。

它甚至能够解决一些学术界认为 LLM 无法解决的难题，例如 MAKER 问题（汉诺塔问题的变种）。通过生成百万步的“Wisp”（一种临时工作流），Gas Town 可以轻松处理超出常规 LLM 上下文限制的复杂任务，证明了其编排能力的强大。

危险地带：Gas Town 的适用性与门槛

核心问题： Gas Town 适合现在的你使用吗？或者说，你准备好迎接这种混乱而高效的开发模式了吗？

回答： 除非你已经是 AI 编程的高阶玩家，处于“同时手忙脚乱管理 10 个以上代理”的阶段，否则 Gas Town 并不适合你。它复杂、昂贵、处于早期阶段，且需要你接受“Vibe Coding”的哲学。

在深入技术细节之前，我们需要明确 Gas Town 并不适用于所有人。以下是几个关键的限制因素：

1. 极高的操作门槛

你需要评估自己在 AI 辅助编程进化图中的位置：

  • Stage 1-5：如果你还在使用 IDE 侧边栏的单个代理，或者刚开始尝试 CLI 单代理模式，Gas Town 对你来说太早了。
  • Stage 6-7：如果你已经开始习惯使用 3-5 个并行实例，甚至尝试手工管理 10 个以上的代理，你可能已经准备好尝试 Gas Town。
  • Stage 8：这是 Gas Town 的目标用户——那些正在构建自己编排器的人。

Gas Town 就像一个由超级智能黑猩猩组成的工业工厂。如果你不是经验丰富的“驯兽师”，它们可能会瞬间摧毁你的代码库、工作环境甚至你的客户。这种混乱是其特征，而非缺陷。

2. 高昂的成本

Gas Town 非常烧钱。你需要多个 Claude Code 账户来绕过单账户的限制，并且随着你扩大规模，成本会线性增长。如果你需要担心 API 费用的去向，那么这个系统不适合你。

3. 技术栈的强依赖

  • Tmux：Gas Town 目前主要使用 Tmux 作为 UI。你必须学会 Tmux 的基本操作。
  • Beads：Gas Town 建立在 Beads 之上，这是一个基于 Git 的通用数据平面。你不能绕过 Beads 使用 Gas Town，它们是深度绑定的。

反思：接受混乱，拥抱“Vibe Coding”

在使用 Gas Town 时，你必须接受一种被称为“Vibe Coding”的工作方式。这意味着工作是流动的，像在码头把光鲜的鱼铲进木桶一样。有些鱼会掉出去，有些会逃跑，但总体上，你的吞吐量是巨大的。有些 Bug 可能会被修复 2-3 次，设计可能需要重做，但这没关系，因为你在以思维的速度疯狂向前推进。

Figure 3: Vibe Coding Chaos
图片来源：Nano Banana via Medium

架构解析：Gas Town 的七种角色

核心问题： Gas Town 是如何组织这些 AI 代理来协同工作的，它们各自扮演什么角色？

回答： 通过一套精心定义的角色体系，每个代理都有明确的职责，类似于传统软件工程中的职能分工，从市长到工人，各司其职。

Gas Town 的核心在于其角色定义。它引入了七个主要的 Agent 角色，以及你作为“监督者”的第八个角色。每个角色都有特定的职责和生命周期。

1. 核心概念：Towns 与 Rigs

  • Town（城镇）：你的总部目录（例如 ~/gt）。所有的项目 Rigs 都位于 Town 之下。Town 负责管理跨所有 Rigs 的代理。
  • Rig（钻机/项目）：每个放在 Gas Town 管理下的 Git 仓库称为一个 Rig。

2. 角色详解与应用场景

Figure 5: Gas Town's Worker Roles
图片来源：Gas Town GitHub

  • 👤 监督者：也就是你。你是老板，拥有自己的收件箱，可以向任何角色发送邮件和指令。
  • 🎩 市长：这是你最主要对话的代理。它是你的礼宾和幕僚长。大多数工作车队长都由市长启动，并在完成时接收通知。

    • 应用场景：当你有一个宏大的功能想法时，你告诉市长，市长负责将其拆解并分发给其他代理。
  • 😺 鼬鼠：Gas Town 是一个工作群集引擎。鼬鼠是每个 Rig 的临时工作代理，按需启动。它们通常成群结队地工作，生成合并请求（MR），提交给合并队列，然后在合并后完全退役。

    • 应用场景：当你需要快速修复一组类似的 Bug 或生成一批样板代码时，你可以启动一群鼬鼠并行处理。
  • 🏭 炼油厂：当大量代理同时工作时，合并队列会变成混乱的战场。炼油厂负责智能地将所有更改一个接一个地合并到主干，确保没有工作丢失。

    • 应用场景：当 10 个鼬鼠同时完成了各自的 MR，且基础分支已经发生了变化时，炼油厂负责处理复杂的 Rebase 和冲突解决。
  • 🦉 见证者：随着鼬鼠数量的增加，你需要一个专门的代理来监控它们并在它们卡住时提供帮助。

    • 应用场景：当鼬鼠因为上下文丢失而停止响应时，见证者会介入，帮助它重新提交 MR 或通知炼油厂。
  • 🐺 执事：这是守护进程信标。它运行一个名为“巡逻”的循环工作流。Gas Town 的守护进程每几分钟 ping 一次执事，问“Do your job”。执事负责将这个信号向下传播，确保 Gas Town 持续工作。
  • 🐶 猎犬：执事的私人团队。与鼬鼠不同，猎犬是 Town 级别的长期代理。它们处理维护工作（如清理过期的分支）和临时杂务。
  • 🐕 启动犬：一种特殊的猎犬，每 5 分钟被唤醒一次，专门检查执事的状态，决定是否需要给执事发送心跳、重启或置之不理。
  • 👷 船员：这是你个人使用最多的角色，仅次于市长。船员是为监督者工作的长期编码代理。你可以为它们命名，它们有持久的身份。

    • 应用场景：进行需要大量反复沟通的设计工作时，你可能会与特定的船员成员长时间协作，而不是使用一次性的鼬鼠。

MEOW 栈：Gas Town 的数据与工作流引擎

核心问题： Gas Town 如何持久化和追踪工作，确保即使代理崩溃任务也不会丢失？

回答： 通过名为 MEOW 的技术栈，将所有工作抽象为可持久化、可组合的分子，利用 Git 作为唯一事实来源。

Gas Town 不仅仅是脚本，它建立在作者称为 MEOW 的技术栈之上。这感觉更像是一种发现而非发明。

Figure 9: The Molecular Expression of Work (MEOW)
图片来源：Gas Town GitHub

1. Beads：原子工作单位

一切始于 Beads。Beads 是一种特殊的 issue tracker issue，具有 ID、描述、状态和受理人等信息。它们以 JSON 格式存储（每行一个 issue），并随项目仓库在 Git 中追踪。在 Gas Town 中，Town 邮件、消息传递和编排都使用 Beads。

2. Epics：自顶向下的计划

Epics 是带有子 Beads 的 Beads，子 Beads 本身也可以是 Epics。这允许你构建灵活的自顶向下的计划。默认情况下，Epics 的子任务是并行的，但你可以添加显式依赖关系来强制排序。

3. Molecules：工作流链

作者在 12 月 17 日有了这个想法，旨在将代理的工作分解为必须勾选的有序小任务。Molecules 就是由 Beads 链接而成的工作流。它们可以具有任意的形状，并且可以在运行时拼接在一起。

4. Formulas：工作流的源代码

为了更好地组合分子，作者引入了 Formulas（TOML 格式）。Formulas 是工作流的源形式，它们被“烹饪”成原分子，然后实例化为 Beads 数据库中的 Wisps 或 Molecules。

应用场景：
假设你有一个 20 步的 Beads 发布流程。过去，代理经常因为等待 GitHub Actions 或 CI 而跳过步骤。现在，你可以创建一个 Formula，定义这 20 个步骤及其依赖关系。当发布任务开始时，它会实例化为一个 Molecule，代理必须一步一步地勾选这些 Beads。如果代理在步骤 5 崩溃，重启后的新代理会自动从步骤 5 继续，而不会重头开始。

5. Wisps：临时编排 Beads

Wisps 是一种特殊的 Beads。它们存在于数据库中，有 Hash ID，行为像普通 Beads，但不会写入 JSONL 文件，因此不会持久化到 Git。在运行结束时，Wisps 会被“烧毁”（销毁）。

应用场景：
Refinery、Witness 和 Deacon 等巡逻代理为每次巡逻运行创建 Wisp 分子。这确保了工作流的事务性完成，而不会在 Git 中留下编排噪音。

驱动机制：GUPP 与非确定性幂等性

核心问题： 如何让 AI 代理在重启或崩溃后能够自动继续工作，而不是停下来等待用户输入？

回答： 通过 Gas Town 通用推进原则（GUPP）和非确定性幂等性（NDI），代理被强制执行钩子上的任务，且工作流状态持久化。

Gas Town 通用推进原则（GUPP）

GUPP 的核心很简单：如果你的钩子上有工作，你必须运行它。

在 Gas Town 中，所有代理在 Beads 中都有持久的身份。每个代理都有一个名为 Hook 的特殊 pinned Bead，这是你悬挂工作流（分子）的地方。

当你使用 gt sling 命令将工作分配给代理时，工作就会挂在它们的 Hook 上。理论上，代理在启动时应该检查 Hook 并开始工作，无需等待。

GUPP Nudge：绕过“礼貌”

然而，实际操作中，Claude Code 太过“礼貌”。它经常会等待用户输入任何内容后才检查邮件和 Hook。为了解决这个问题，Gas Town 引入了 Nudge 机制。

系统会在代理启动后 30-60 秒内发送一个 Nudge（通过 gt nudge 命令）。这模拟了用户的输入，迫使代理打破沉默，检查邮件和 Hook，并开始工作。

非确定性幂等性（NDI）

Gas Town 的运行原则被称为非确定性幂等性。它类似于 Temporal 的确定性持久重放，但实现机制完全不同。

Figure 11: Nondeterministic Idempotence
图片来源：Gas Town GitHub

由于工作被表达为 Molecules，且每个步骤都由超级智能的 AI 执行，因此工作流是持久的。

  1. 代理是持久的（Bead 身份）。
  2. Hook 是持久的。
  3. Molecule 是持久的。

即使 Claude Code 崩溃或上下文窗口耗尽，只要另一个会话为该代理角色启动，它就会立即继续那个步骤。代理可能会犯非确定性的错误，但可以利用自身的智能进行自我纠正，只要 Molecule 的验收标准定义得当。

反思： 这种机制利用了 AI 的优势（理解意图和自我纠正）来弥补其劣势（不稳定和不可预测性），这比传统的确定性工作流引擎更适合 LLM 时代。

实战体验：Convoy 队列与 Tmux 工作流

核心问题： 作为用户，我在 Gas Town 中的一天是如何度过的？我如何与这些代理交互？

回答： 你通过 Convoy（车队）追踪任务进度，在 Tmux 窗口中穿梭，向市长下达指令，由鼬鼠和船员执行。

邮件与消息系统

Gas Town 使用 Beads 构建了两层的邮件结构：

  • Rig 级别工作：项目工作（功能、修复），主要由鼬鼠和船员完成。
  • Town 级别工作：编排工作，包括巡逻和发布。

Sling：分配工作的原语

gt sling 是 Gas Town 中分配工作的基本命令。你可以告诉市长：“我们的 tmux 会话显示的 Rig 数量不对，记录下来并把它扔给鼬鼠处理。”

Convoys：车队追踪系统

所有分配的工作都会被包裹在一个 Convoy 中。Convoy 是一个特殊的 Bead，它将一堆工作打包成一个你追踪交付的单元。

Figure 14: Convoy CLI display
图片来源：Gas Town GitHub

与其看到 “issue wy-a7je4 完成了”，Convoy 让你看到一个更大的功能模块已经落地。Convoy 有一个仪表板，显示每个车队的展开树，让你可以看到其单独的跟踪问题。

应用场景：
你正在开发一个大型重构功能。你创建了一个 Convoy，告诉市长启动一支鼬鼠群去攻击它。数十个鼬鼠开始并行处理不同的文件和模块，生成 MR。Witness 监控它们，Refinery 合并它们。最终，你在仪表板上看到整个 Convoy 标记为“Landed”（已着陆），这意味着该功能已完成。

Tmux：主控制台

虽然 Gas Town 未来会有 Web UI 或 Emacs UI，但目前它主要依赖于 Tmux。Tmux 出奇地强大且易于上手。你只需要掌握几个命令：

  • C-b s：列出会话，窥视并切换。
  • C-b n/p：在组中循环到下一个/上一个工作代理（例如循环查看船员）。
  • C-b [：进入复制模式，查看历史输出。
  • C-b a：查看活动摘要。

Figure 4: Mayor tmux status line
图片来源：Gas Town GitHub

Handoff：无缝交接

Gas Town 的核心内循环是 Handoff。在任何会话中，你都可以说“let’s hand off”，代理会优雅地清理并重启会话。由于 GUPP 的存在，代理会自动继续工作。

Seance（降灵会）：
Gas Town 甚至有一个 gt seance 功能，允许当前代理直接与其前任进行对话。通过 Claude Code 的 /resume 功能，新代理可以找到上一个会话并询问：“我上一任留下的东西在哪？”这解决了会话切换时上下文丢失的问题。

对比与未来：Gas Town 与 Kubernetes 及 Temporal

核心问题： Gas Town 与现有的编排系统（如 K8s 或 Temporal）有何本质区别？

回答： K8s 关注“运行中”，Temporal 关注“确定性重放”，而 Gas Town 关注“完成”和“非确定性纠错”。

与 Kubernetes 的对比

Gas Town 看起来确实有点像 Kubernetes，但这并非刻意为之。两者都协调不可靠的工作者来实现目标。都有控制平面监视执行节点。区别在于：

  • Kubernetes 询问“它在运行吗？”，旨在保持 N 个副本存活，持续维持期望状态。Pod 是匿名的“牲畜”。
  • Gas Town 询问“它做完了吗？”，旨在完成工作，着陆车队，然后终止工作者。Polecats 是有功劳的工作者。会话是牲畜。Gas Town 的目标是达成终点状态。

Figure 16: Kubernetes/Gas Town comparison
图片来源：Gas Town GitHub

与 Temporal 的对比

Gas Town 通过完全不同的机制实现了类似 Temporal 的持久性和保证执行。它不依赖确定性的重放，而是依赖超级智能 AI 的纠错能力和持久化的工作流定义。

总结与展望

Gas Town 是作者在 2025 年底构建的第四个完整的、可运行的编排器。它虽然只有 3 周大（指 Go 版本），代码库 3 周前才诞生，包含了 75,000 行 Go 代码和 2000 次提交，但它已经展现出了惊人的潜力。

目前已实现的功能包括：

  • 自我交接和 Sling/Convoy 工作流。
  • 完整的 MEOW 栈。
  • Deacon, Witness 和 Refinery 的自动巡逻。
  • 强大的 Crew 管理机制。
  • 意外的 Tmux UI 体验。

尚未完成的功能包括：

  • 联邦：支持远程工作者和云扩展。
  • GUI：更好的用户界面（Web 或 Emacs）。
  • 插件系统：通过 Molecule 步骤扩展功能。
  • Mol Mall：分子的交易市场。

反思： 作者提到，他在这一年里四处游说，告诉大公司需要构建“代理的 Kubernetes”，但得到的只有困惑。现在，他选择自己动手构建了这个未来。正如他所言，他宁愿坐在家里创造未来，也不愿四处奔走预测未来却不被相信。Gas Town 是对现有 AI 开发工具的一次大胆挑衅，也是对未来编程方式的一次严肃探索。

Figure 17: Happy New Year!
图片来源：Gas Town GitHub

实用摘要 / 操作清单

如果你决定尝试 Gas Town，以下是你需要准备的关键步骤：

  1. 评估现状：确认你至少处于 AI 辅助编程的第 6 或第 7 阶段（能够手忙脚乱地管理 3-5 个或更多代理）。
  2. 准备账户：准备好多个 AI 服务商账户（如 Claude Code）以应对高昂的 Token 消耗。
  3. 学习 Tmux：熟悉基本的 Tmux 命令（会话切换、窗口导航）。
  4. 安装 Beads：理解并安装 Beads，作为 Gas Town 的数据平面。
  5. 配置 Gas Town：

    • 初始化你的 Town。
    • 添加你的项目 Rig。
  6. 启动角色：开始启动市长、船员和守护进程。
  7. 尝试 Sling：不要直接写代码，尝试创建 Beads 并使用 gt sling 将任务扔给鼬鼠。
  8. 监控 Convoys：在仪表板上观察任务车队的进度。

一页速览（One-page Summary）

组件 功能 关键概念
Gas Town 2026 年 AI 编程 IDE / 编排器 管理大规模 AI 代理群
MEOW 栈 数据与工作流引擎 Beads, Epics, Molecules, Formulas, Wisps
GUPP 驱动原则 钩子有工作必须运行；使用 Nudge 唤醒
Town / Rig 架构层级 Town = 总部；Rig = 项目仓库
市长 主要接口 对接用户的代理人
鼬鼠 临时工人 并行处理具体任务，做完即销毁
炼油厂 合并专家 智能处理合并队列冲突
见证者 监工 确保鼬鼠不卡顿，维持流动性
Convoy 追踪单元 包装任务组，可视化进度
NDI 执行保证 非确定性但持久可恢复的工作流

常见问答 (FAQ)

Gas Town 目前是稳定的生产级工具吗？
不是。它非常新（代码库仅几周历史），且被作者描述为“刚从河里走私出来的粗石”，充满了个人观点和即兴代码（Vibe coded）。使用它需要极高的风险承受能力。

我必须使用 Tmux 吗？
是的，目前 Tmux 是主要的用户界面。虽然未来可能会有更好的 GUI，但目前 Tmux 是与数十个代理交互的最有效方式。

Gas Town 支持除了 Claude Code 以外的其他 AI 吗？
Gas Town 的设计理念是将“Claude Code”视为一类 CLI 代理的统称。理论上，任何遵循类似接口的 AI 编码工具（如 Codex, Gemini CLI 等）都可以作为“牲畜”被 Gas Town 调用。

Gas Town 的成本是如何计算的？
成本与运行的代理数量和 Token 消耗成正比。由于 Gas Town 倾向于同时运行 20-30 个代理，成本非常高昂，通常需要多个 API 账户来避免单账户限制。

什么是“Vibe Coding”？
这是 Gas Town 推崇的一种工作哲学。与其追求完美的代码和零 Bug，不如追求极高的吞吐量。接受混乱和重复，让 AI 疯狂生成，你只负责保留好的部分。

Gas Town 与 Kubernetes 的最大区别是什么？
虽然架构相似，但目标不同。Kubernetes 旨在让服务永远运行；Gas Town 旨在让任务尽快完成。Kubernetes 是关于“存在”，Gas Town 是关于“完成”。

我可以为 Gas Town 编写自己的插件吗？
可以，Gas Town 有插件系统的基础设施。插件本质上是代理工作流中的特定步骤，可以由 Deacon 或其他角色执行。作者计划未来推出“分子市场”来分享这些插件。