夜雨聆风
今年早些时候，知名工程师史蒂夫·耶格在Medium发布一篇爆款文章，介绍开源工具Gas Town。这款工具可让开发者在同一代码库上并行调度20至30个AI编码智能体。就在上周，Every科技咨询主管迈克·泰勒抢先体验了多智能体工程的下一代产品：Gas City。
该项目由前谷歌开发者工具资深专家克里斯·塞尔斯（曾将Flutter推广至300万开发者）与前Block技术主管朱利安·克努特森，在耶格授权下重构为工具套件。泰勒与二十多位工程师、CTO在纽约一场研讨会上试用了该项目，塞尔斯与克努特森远程参会。
一句话总结：Gas City理念前沿，契合软件开发趋势，但尚未成熟可用。
什么是Gas City
如今，并行运行多个编码智能体已是开发者的基础能力。想让它们真正发挥价值，必须有协调系统来分配任务、互相审核、避免分支冲突——而这一点目前尚无完美方案。像Gas City这样的“软件工厂”正是解决方案之一：一套编排系统，为小型智能体团队分配任务、调度工作、判定完成状态。
塞尔斯与克努特森正用Gas City开发Gas City本身：克努特森位于亚特兰大的服务器运行约100个智能体，每日合并约50个拉取请求，相当于一个小型团队的产出；每日消耗约10亿个Token，约等于维基百科英文语料库总量的1/5。
亮点：三大核心理念
即便不使用这套工具，其借鉴自软件工程的三大思路也值得学习：
明暗工厂模式：人与智能体交互的环节（规划、设计、评审）保持可见，为“明”；智能体独立完成明确任务的环节在后台运行，为“暗”。随着对智能体信任度提升，可将更多流程转入“暗工厂”。
一主多从架构：多智能体工程的未来很可能是：一个长期存在、可直接对话的主管智能体（Gas City称之为“市长”），将任务派发给匿名、一次性的工作智能体（“鼬猫”）。后者完成单一任务即关闭，避免上下文混乱或互相干扰。你无需管理上百个智能体，只需与“市长”对话即可。
代码评审多模型会诊：将同一段代码同时交给Claude、Codex、Kimi评审，从多角度排查问题。三个不同模型比单一模型运行三次能发现更多不同类型Bug。
不足：仍待完善
在Gas City中，每个任务都会启动一个全新的智能体会话，它不记得之前的步骤，因此智能体会浪费周期重新读取其他智能体已经产生的上下文，并且会错失单个会话本可以捕捉到的关联。成本也是一个挑战：一个六步骤的任务可能花费六个Claude会话的成本，这很快就会累积起来。该工具包仍然感觉像实验品——即使有指导老师的支持，一整屋经验丰富的工程师也花了整整一天才让它运行起来。
驱动该系统的任务跟踪器Beads是优先为智能体构建的。它在命令行上运行，而不是可视化仪表板，这对智能体来说没问题，但对人类来说更难，因为人类希望能一目了然地看到所有信息。因此，在生产环境中使用Gas City的团队通常会将其与Jira或Linear搭配使用，这就需要在两个地方放置任务。
此外，Gas City建立在这样一个假设之上：AI模型需要扶着才能保持在正轨上。但现在模型已经足够优秀，以至于Gas City中那些为了保持模型不偏离轨道而构建的部分，例如捕捉错误的审查循环、防止智能体中途偏离任务的检查点，现在基本上已不再需要。最后，Gas City故意使用不常见的词来指代不同的输入、参与者和工作流程，称任务为"珠子"，工作智能体为"臭鼬"，处理步骤为"精炼厂"，因此对于一个刚接触该技术的新团队来说，可能会感到困惑。
结论
迈克·泰勒（科技咨询主管）：吸收理念，暂不使用工具。
如果你已并行运行超过10个Claude Code会话并频繁阅读源码，Gas City值得一看，它提供了一套高并发编排的可行思路。对其他开发者而言，借鉴理念即可，耐心等待成熟方案。
几周前发布的OpenAI Symphony是更易用、更适合企业的同类产品：通过一套规则，将你现有的Linear面板直接转为智能体工作面板，更贴合现有工程师工作流，无需像Gas City那样大幅改变习惯。
关注智核pro，更早了解AI
