📌 项目地址：gastownhall/gastown | ⭐ 15,648 颗星 | 🔧 Go | 📜 MIT
问题：AI编码代理一多就乱
我自己用Copilot改前端，让Claude Code写后端，再让Gemini生成文档。三个代理还行，但一旦加到五六个，问题就来了：
- 每个代理重启后上下文全丢，上次改到哪了没人记得。
- 代理之间互相不知道对方在做什么，容易改出冲突。
- 任务分配靠我手动发消息，代理干完活也不汇报。
Gas Town是一个Go写的工具，在GitHub上拿了15648个星标。它不解决AI模型本身的能力问题，而是给多个AI代理搭建一个带持久化记忆的协作框架。
核心思路：用Git worktree当代理的“硬盘”
大多数AI代理的工作状态只在内存里，会话结束就消失。Gas Town把每个代理的工作状态存入Git仓库的一个独立worktree里。worktree是Git的一个功能，允许同一个仓库的不同分支同时检出到不同目录。Gas Town利用这一点：
- 每个代理（Polecat）得到自己的worktree目录。
- 代理的所有产出、决策、代码变动都写入该目录，自动或手动提交到Git。
- 即使代理崩溃或机子重启，下次启动时直接从worktree恢复。
这带来的直接好处：
- 状态不会丢 —— 哪怕代理会话非正常结束，已保存的工作可以在新会话中继续。
- 并行不冲突 —— 多个代理在不同worktree上工作，互不干扰。合并回主分支时才处理冲突。
README里明确说：“Work state persists in git-backed hooks”，意思是代理的工作状态通过Hooks（实际上就是git worktree）持久化。
架构：八种组件，各司其职
Gas Town用了一整套“城镇”隐喻。理解这些概念是上手的关键。
Town（城镇）
就是你的工作区根目录，比如~/gt/。所有项目、代理、配置都在这个目录下。
Mayor（市长）
唯一的AI协调器，是一个Claude Code实例，它拥有整个Town、所有Rig、所有代理的完整上下文。所有工作从Mayor开始 —— 你告诉Mayor想做什么，Mayor负责拆解任务、分派给代理。
Rig（项目容器）
Rig包裹一个具体的Git仓库。相当于一个“项目单元”。每个Rig管理自己的仓库和在该仓库上工作的代理团队。例如：前端的Rig用fe前缀，后端的Rig用be前缀。
在一个Rig内部，有三种角色：
- Crew Member：你自己的手工工作空间。你在Rig里手动改代码时，就是在Crew Member里干活。
- Polecat（雪貂）：工人代理。它们有持久的身份（ID），但会话是临时的：为某个任务而生，任务完成会话就结束。但身份和所有工作历史永久保存在Hooks里。README说“Polecats with persistent identity but ephemeral sessions”。
- Hooks：基于git worktree的持久层。Polecat的所有工作成果都存在这里。崩溃也不丢。
Convoy（车队）
工作是批量分配的。Convoy是工作单元的分组容器，里面包含多个具体任务（Beads）。你可以把一批Beads打包成一个Convoy，分配给一个或多个Polecat。
Convoy有一个特殊标签mountain。标记为mountain的Convoy在运行时，系统会自动检测代理是不是卡住了（stall detection），并智能跳过某些任务以继续执行。README里说的是“Convoys labeled mountain get autonomous stall detection and smart skip logic for epic-scale execution”。
Beads（珠子）
最小的工作单元，类似一个issue或ticket。每个Bead有一个唯一ID，格式是前缀+5位字母数字，比如gt-abc12、hq-x7k2m。前缀表示来源（比如gt是Gas Town的通用前缀，hq可能代表某个Rig）。
命令gt sling和gt convoy都接受这些Bead ID作为参数。gt sling可能是把单个Bead交给某个代理，gt convoy是处理一组Bead。
工作流程：一个实际例子
假设我要重构用户登录模块。
- 告诉Mayor：在
~/gt/下启动Mayor（一个Claude Code实例），说“重构用户登录模块，用JWT替换session”。 - Mayor拆分任务：Mayor知道项目结构，把任务拆成多个Bead，比如：
gt-a1b2c：写JWT生成/验证库gt-d3e4f：改造登录API接口gt-g5h6i：更新测试用例
- 打包成Convoy：Mayor把这些Bead打包成一个Convoy，如果觉得任务量很大，可能加
mountain标签。 - 分派给Polecat：Mayor调用
gt convoy把整个Convoy分配给一个空闲的Polecat（或者一组Polecat）。Polecat的身份预先定义好，比如polecat-backend。 - Polecat工作：Polecat启动，发现自己被分配了Convoy。它进入对应的Rig（比如
~/gt/auth-rig），在它的Hooks（worktree）里开始实现Beads。所有代码修改、设计决策都写入worktree。如果Polecat中途崩溃（比如API限流导致断开），重启后它从Hooks读取最近的进度，接着干，不会从零开始。 - 完成与记录：每个Bead完成后，Polecat将结果（代码、commit）写入Bead系统。Mayor可以查询进度。最终所有Bead完成，Mayor会通知你审查结果。
它真正解决了什么
| 痛点 | Gas Town的解法 |
|---|---|
| 代理丢记忆 | 工作状态写入git worktree（Hooks），重启后恢复 |
| 多代理协调混乱 | Mayor统一调度，Convoy打包任务，Polecat有明确身份和任务 |
| 工作状态不可追溯 | Beads系统将每个任务的状态、结果以结构化数据记录，可以回溯 |
| 代理数量有限 | 架构设计支持20-30个代理协作（README说“Scale comfortably to 20-30 agents”） |
| 无法处理长任务 | mountain标签的Convoy自动检测卡住并跳过，防止单个任务拖死整个流程 |
适用场景与门槛
如果你同时用3个以上AI代理在一个大项目上工作，并且项目本身用Git管理，Gas Town提供了可复用的编排方案。它特别适合以下情况：
- 你有多个功能模块并行开发，每个模块由不同代理负责。
- 你想让AI代理自主完成一些长期任务（比如重构、迁移），但又不想因为代理重启而丢失进度。
- 你想追踪AI代理的工作日志，以便审查和回滚。
但门槛也很明显：
- 概念层多：Town、Rig、Crew、Polecat、Hook、Convoy、Bead……你得花时间记这些术语。
- 依赖Git worktree：你需要理解git worktree的基本操作，否则遇到问题很难排查。
- 命令驱动：所有操作必须通过
gt sling、gt convoy等命令执行，不能随意手动操作worktree（否则可能会破坏一致性）。 - 仅支持Git仓库：如果你用的不是Git（比如SVN、Fossil），或者项目还没初始化Git仓库，Gas Town没法用。
总结
Gas Town不是魔法，它用Git的可靠性给AI代理的工作状态上了“保险”，用Mayor做中央调度，用Beads做精细追踪。它把多代理协作从“手动甩锅”变成了“结构化工程”。如果你忍受过代理丢进度、多代理打架的痛，值得试试。