gascity
Steve Yegge 开源的多智能体代码编排 SDK,通过 city.toml 配置替代硬编码角色,支持 tmux/Kubernetes 等多运行时
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
Steve Yegge 开源的多智能体代码编排 SDK,通过 city.toml 配置替代硬编码角色,支持 tmux/Kubernetes 等多运行时
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
当一个人能在 10 分钟内用配置文件搭起一个多智能体协作的开发流水线,而不需要写一行 Go 代码——这意味着什么?
如果你在 2000 年代中期混迹编程社区,不可能没听过 Steve Yegge。他是 Google 早期的"编译器二把刀"(原文幽默自称),也是博客界最会写长文的程序员之一——他那篇《大教堂与 Bazaar》的姊妹篇《代码之舞》至今仍被反复传阅。
2025 年前后,Yegge 启动了一个名为 Gas Town 的项目——一个用 Go 构建的多智能体代码工作流编排系统。它的核心思路是:让多个 AI Agent 像工厂流水线一样协作,有人分解任务,有人执行,有人审查,有人整合。
Gas Town 证明了多智能体编排是真实可用的。但问题在于——它所有的"角色"(Mayor、Deacon、Polecat 等)都是硬编码在 Go 代码里的。要改一个行为?得改源码。要加一个新角色?得在代码里注册。要把这个系统迁移到别的项目?几乎不可能。
Gas Town 的教训催生了 Gas City——一个从 Gas Town 中提炼出的编排构建工具包(Orchestration-Builder SDK)。核心理念只有一条:ZERO 硬编码角色。 Gas City 的二进制本身不包含任何预设角色,所有角色行为完全由配置文件驱动。
图1:Gas City 项目 Logo
图2:Gas City 深色模式 Logo
图3:Blacksmith 赞助标识
Gas City 的架构由五个原始原语和四个派生机制组成,文档称之为"九大积木"。
1. Session(会话)
Session 是单个 Agent 的运行实例,默认跑在 tmux 分屏里。Session 被设计为可丢弃的(disposable)——Agent 进程可以崩溃、重启、替换,但工作不会丢失,因为所有工作状态都存在 Beads Store 里,不在进程内存中。这让 Controller 可以在 Agent 挂掉后无缝重启,而用户感知不到中断。
2. Beads Store(珠子存储)
Beads Store 是整个系统的记忆中枢,类似 Issue Tracker,但完全结构化、可查询。Work Item 被称为"珠子"(Bead),每个 Bead 有唯一 ID、状态、优先级、生命周期。使用 Dolt(一个 Git 风格的 SQL 数据库)作为后端,支持分支、合并、历史追溯——相当于把版本控制的思维带入了任务管理。
3. Event Bus(事件总线)
所有 Session 的操作都会产生事件(启动、输出、错误、超时等),事件总线负责收集、分发、订阅。这是实现监控、健康巡逻(Health Patrol)、自动恢复的基础设施。
4. Config(配置)
整个系统通过 city.toml 声明式配置——声明有哪些角色、哪些 Session、哪些 Bead 存储方式、哪些触发规则。配置即系统,修改配置即修改行为。
5. Prompt Templates(提示词模板)
每个角色(Agent)的行为通过提示词模板定义,支持变量插值、条件分支、上下文注入。同一套 Session 框架,换一套 Prompt 就变成另一个角色。
Dispatch(分发)——如何把一个 Work Item 路由到正确的 Agent?支持优先级、标签、负载均衡等多种策略。Formulas(公式)——把复杂的多步骤任务封装为可复用的配方,类似 Makefile 但面向 AI Agent 工作流。Messaging(消息)——Session 之间传递信息,支持点对点和广播模式。Health Patrol(健康巡逻)——监控所有 Session 状态,自动挂起空闲 Agent、自动恢复崩溃的 Agent。
Gas City 引入了三个核心组织概念:
City 是顶层部署单元,本质是一个目录,包含 city.toml 配置文件、.gc/ 运行时状态目录、.beads/ 工作存储目录。创建城市只需 gc init ~/my-city,一条命令完成初始化和 Controller 启动。
Rig 是注册到城市中的外部项目(通常是 Git 仓库)。每个 Rig 有独立的 Bead 命名空间,逻辑上隔离,但共享底层存储。gc rig add ~/hello-world 把本地项目接入编排系统。
Bead 是最小工作单元,类比 Git Commit + Issue 的混合体。每个 Bead 有完整的生命周期:创建 → 分发 → 执行 → 审查 → 合并,支持原子操作和条件触发。
图4:Gas City 架构概览——City、Rig、Bead 如何协同工作
Gas City 是一个 Go 项目,依赖极其丰富,展示了现代 Go 后端工程的全景:
代码规模上,cmd/gc/ 目录下有超过 600 个 .go 文件,涵盖完整的 CLI 实现(Agent 管理、Session 控制、Pack 发布、Doctor 健康检查等),加上 internal/ 下 80+ 子模块,总计 Go 代码超过 30 万行(含测试)。
测试覆盖率极高,目录结构中有大量 _test.go 文件,甚至有 chaos testing 相关的测试(session_lifecycle_chaos_test.go)。
安装只需一行 Homebrew 命令:brew install gastownhall/tap/gc。gc init 初始化城市,gc rig add 接入项目,gc sling claude "任务描述" 分发工作。
整个工具链的设计语言非常成熟:doctor 自检(gc doctor 检查依赖完整性)、pack 注册中心(gc pack registry 管理可复用编排包)、trace 追踪(完整的执行链路记录)。
gc 别名冲突是已知问题)。Gas City 代表了一个重要的趋势:从"用一个 Agent 解决一个问题"演进到"用多个 Agent 协作解决复杂问题"。Steve Yegge 的实践证明了:
Gas City 目前被 Blacksmith 赞助,在 Gas Town 的基础上集成了 T3 Code UI 和 DoltLite Backing Beads Store。它的目标不是取代 Claude Code 或 Copilot,而是成为多 Agent 协作场景下的基础设施层——让开发团队可以在它之上构建自己的智能体编排系统。