核心概述
Gastown是一个基于gt(Gas Town)CLI和Claude Code构建的多智能体代码编排框架,专为非琐碎开发任务设计。系统通过"Mayor"主代理协调多个"Polecat"工作代理并行执行多文件修改、功能开发、重构和Bug修复等任务。
核心用法
用户通过自然语言与Mayor交互(gt mayor attach交互式或gt mayor mail非交互式),Mayor自动将任务拆分为Beads(工作项),创建Convoy(任务队列),并派遣Polecat代理执行。每个Polecat遵循mol-polecat-work公式的9步标准化生命周期:加载上下文→分支设置→预检测试→实现→自审→运行测试→清理工作区→准备评审→提交退出。Refinery代理负责合并回主分支,用户无需直接操作Git。
显著优点
- 并行化效率:多代理同时处理不同任务模块,突破单会话瓶颈
- 标准化流程:9步强制工作流确保代码质量、测试覆盖和自审机制
- 状态持久化:基于Git的Beads系统和tmux会话保证工作可恢复、可追踪
- 自然语言驱动:无需编写复杂脚本,描述需求即可启动完整工作流
潜在局限
- 环境依赖复杂:需同时配置
gt、bd、claude三个CLI、tmux 3.0+、Go 1.23+及复杂符号链接设置 - 学习曲线陡峭:Rig、Bead、Convoy、Polecat、Formula等概念体系需时间理解
- 调试不透明:代理在tmux后台运行,问题定位依赖
tmux capture-pane等间接手段 - 公式解析脆弱:
gt sling与bd cook的搜索路径不一致,需手动符号链接修复 - Claude Code锁定:深度绑定Anthropic生态,无法迁移至其他模型
适合人群
- 中大型代码库维护者(需频繁跨文件修改)
- 追求CI/CD式本地开发标准的团队
- 熟悉tmux/Go生态、愿意投入基础设施建设的资深开发者
- 需要将复杂任务分解为可并行子任务的项目
常规风险
- 代理失控风险:Polecat拥有分支创建、代码提交、推送权限,错误指令可能导致仓库污染
- 状态同步问题:多个代理并行修改可能引发合并冲突,依赖Refinery的仲裁机制
- tmux会话残留:Claude Code会话可能冻结,需手动清理僵尸进程
- 配置漂移:符号链接或公式路径配置错误会导致代理跳过标准工作流进入"raw bead"模式,丧失质量门禁
- 成本累积:多代理并行调用Claude Code API可能产生较高Token消耗