Gas City 评测：用 Go 写的多智能体编排 SDK，把 tmux 变成你的调度后台

它解决的是多代理协作的调度混乱

多智能体编码工作流里，真正难的不是单个 agent 写代码，而是几个 agent 怎么排队、怎么共享状态、怎么在失败后重试。Gas City 的定位就是把 Gas Town 项目里沉淀出来的那套编排基础设施抽出来，做成一个可配置的 SDK。它面向的读者不是刚接触 AI 编程的人，而是已经在跑多代理流程、觉得脚本拼凑撑不住的工程团队。仓库里明确写了它提供运行时提供者、工作路由、公式、订单、健康巡逻和声明式城市配置，这些词听起来抽象，但核心就一句话：你声明想要什么状态，它负责把实际运行状态拉过去。

声明式 city.toml 与控制器循环的对账机制

Gas City 的核心机制是一个控制器/监督者循环，它不断把期望状态和运行状态做对比。期望状态写在 city.toml 里，这是一个声明式配置文件，描述城市里有哪些 rig、哪些 agent、用哪个运行时。循环本身在 internal/convergence 里实现，叫 bounded iterative refinement loops，也就是有边界的迭代收敛，不是无限重试，而是设定上限的逐步逼近。这个设计比直接 spawn 进程要稳，因为每次循环都会检查实际状态，缺什么补什么，多了什么可以收掉。README 里提到 gate handling，说明循环里还有关卡机制，可能是等待某个条件满足才继续下一步。这种对账模式在 Kubernetes 里常见，但搬到多代理编码工作流里，需要自己定义什么是期望状态，什么是运行状态，Gas City 用 beads 来存这些状态。

beads 工作追踪：默认 dolt，可选纯文件

工作追踪是 Gas City 的另一个支柱。它用 beads 这个概念来管理 work、mail、convoy 和 waits，beads 是一个存储抽象层，内部有多个提供者实现。默认提供者是 bd，它依赖 dolt、bd 命令行和 flock。dolt 是一个 SQL 数据库，有 Git 式的版本控制，适合存需要历史的工作记录。但如果你不想背这三个依赖，可以在 city.toml 里写 [beads] provider = "file"，或者设置环境变量 GC_BEADS=file，这样就绕开 dolt 和 flock。这个选项很实在，因为 dolt 的 CGO 依赖是构建时最大的麻烦。不过 README 没有详细说明 file 模式的能力边界，比如是否支持并发写、是否支持 waits 的全部语义，这些只能靠文档去查。

运行时提供者：tmux 是默认也是底线

运行时提供者抽象在 internal/runtime 里，实现了 tmux、subprocess、exec、ACP、Kubernetes 和 herdr 六种。tmux 是默认会话后端，同时也是 fallback，意思是即使你选了 Kubernetes，tmux 依然会被安装和检查，因为 gc init 和 gc start 会自动检查所有 Always 依赖。这个设计有点反直觉，但 README 解释得很清楚：tmux 是默认且兜底，所以它始终必需。herdr 是一个可选的替代后端，可以按 agent、按 rig 或按城市级别启用。这种多提供者设计给了灵活性，但也意味着你要理解每种后端的差异，比如 tmux 适合本地交互式会话，Kubernetes 适合远程扩展，ACP 可能是某种 agent 通信协议。选择多了，配置复杂度也上来了。

上手路径：gc init 到 bd create 的完整流程

安装方式有两种，Homebrew 直接 brew install gascity，或者从源码构建。源码构建要求 Go 1.26.4+，还有 ICU 这个传递性 CGO 依赖，因为 dolt 底层用了 ICU。macOS 上 brew install icu4c，Linux 上 apt install libicu-dev，Makefile 会自动检测 macOS 上 keg-only 的 icu4c 路径。初始化流程是 gc init ~/bright-lights，然后 cd 进去 gc start，接着 mkdir hello-world && git init && gc rig add .，最后 bd create "Create a script that prints hello world" 提交一个任务，gc session attach mayor 进入市长会话。这个流程把城市、rig、任务、会话串起来了。rig 是作用域单位，可以理解为一个项目或一组项目的集合，rig-scoped orchestration 支持多项目设置。

Nix 机器上的 ICU 构建坑，绕不开的 CGO

如果你用 NixOS 或 Flox，构建会直接报错 fatal error: unicode/uregex.h: No such file or directory，因为系统 include 和 lib 目录不在默认 CGO 搜索路径里。README 给的解法是手动指定 ICU 开发头文件和运行时库的 Nix store 路径，还要设置 SYS_USR_CGO_FALLBACK=0 禁用 Makefile 的 /usr/lib 回退，避免 Nix 和系统工具链混用。具体命令是 CGO_ENABLED=1 CGO_CPPFLAGS="-I$ICU_DEV/include" CGO_LDFLAGS="-L$ICU_LIB/lib" SYS_USR_CGO_FALLBACK=0 make build。这里有个细节，ICU 版本必须和 gc 二进制链接的库匹配，否则会有版本偏差，README 建议用 ldd $(which gc) | grep icu 来确认。这个坑说明 Gas City 不是那种 go build 一把过的项目，对构建环境有硬性要求。

版本与维护：rolling edge 和 dolt 的兼容底线

仓库默认分支是 main，有个 rolling 的 edge 版本，同时也有 v1.4.0 和 v1.4.1 稳定版。v1.4.1 在 2026 年 8 月发布，比 edge 还新，说明维护节奏是双轨的。文档里专门提到 managed Dolt checks 要求 Dolt 2.1.0 或更高，而且 1.86.2 之前的 Dolt 版本可能缺少上游 GC/writer deadlock 修复，那个提交是 dolthub/dolt 的 ccf7bde206，缺失会导致 dolt_backup sync 在重写负载下挂起。这意味着如果你用默认 beads 提供者，必须盯紧 Dolt 版本，不能随便升级。许可证是 MIT，商用没有法律障碍，但 dolt 本身是 Apache 2.0，bd 是独立项目，这些依赖的许可证要自己确认。

替代方案对比：Gas Town 与通用任务队列的差异

Gas City 的直接替代者是它自己的前身 Gas Town。README 专门有一篇 coming-from-gastown.md，说明两者的关系不是简单升级，而是模型转换。Gas Town 有角色、命令、插件、convoy 这些高层概念，Gas City 改成 primitive-first 模型，也就是更底层、更原子的原语。如果你已经在 Gas Town 上投入很多，直接照搬架构会失败，需要重新映射。另一个替代方向是通用任务队列，比如 Temporal 或 Celery，但那些不关心 agent 会话和 tmux 后端，它们只保证任务执行，不提供 rig 作用域和 beads 的 mail/waits 语义。Gas City 的优势是它把多代理特有的会话生命周期和等待机制内置了，劣势是绑定了自己的配置格式和运行时假设。

编辑结论

Gas City 适合已经用 Gas Town 跑过 convoy 式多代理流程、现在想要更细粒度控制权的团队，也适合愿意把 tmux 当作默认会话后端、能接受 dolt 依赖的 Go 项目。不适合只想快速调 API 的轻量用户，因为前置依赖多，tmux 强制安装，beads 默认走 dolt 和 bd，文件模式虽然存在但文档没有展开。采用前先验证三件事：你的 Go 版本是否满足 1.26.4+，系统里 ICU 开发头文件是否在 CGO 路径上（Nix 机器尤其要手动指定），以及 dolt 版本是否高于 2.1.0 且包含提交 ccf7bde206 的修复。若这些条件不满足，构建或 dolt_backup sync 都可能卡死。最终判断：Gas City 是一个把编排基础设施固化成原语的工具，它的价值在于声明式收敛循环，而不是开箱即用的傻瓜体验，适合愿意为控制权付配置成本的团队。

官方来源

1. Official README
2. Project repository
3. Release notes