Gas Town — 多智能体工作区管理器
通过 git 持久化工作状态，在 20-30 个 AI 编码代理之间协调复杂任务，支持 Claude Code、GitHub Copilot 等。
证据显示：README 和 SECURITY.md 提到代理在 tmux 会话中运行，共享文件系统访问，可执行 shell 命令，但未提供权限最小化的具体机制。用户确认方面，有 `--human` 标志和 `gt convoy create --human`，但未明确所有高风险操作需用户确认。数据流透明度：有 `gt feed` 和 `gt peek` 监控，但未详细说明数据流向。敏感数据处理：未提及凭据管理或加密。依赖安全：go.mod 列出大量依赖，但未提供漏洞扫描或版本固定策略。外部影响：代理可推送 git 和运行 shell，但未明确限制。回滚：有 git 和 beads 持久化，但未明确回滚机制。来源归属：有 SECURITY.md 和发布说明，但未验证发布者。扣分原因：缺乏具体实现细节，多为断言。
证据显示：README 和 CI 工作流一致，但未发现内部矛盾。依赖可用性：go.mod 列出依赖，CI 安装 Dolt 和 ICU，但未提供依赖可用性保证。失败消息：有 `gt doctor --fix` 和错误处理，但未提供详细失败消息示例。扣分原因：未提供失败消息的具体示例。
证据显示：README 描述了多种场景（Mayor、Minimal Mode、Docker），并提供了运行时配置。能力边界：有 `gt config` 和预设，但未明确限制。触发精度：有 `gt sling` 和 `gt convoy` 等命令，但未明确触发条件。环境适配：支持多平台和 Docker，但未提供所有环境的详细配置。扣分原因：部分描述不完整。
证据显示：README 结构清晰，有安装说明、示例和 FAQ（部分）。命名稳定性：有 `gt` 和 `bd` 命令，但未提供版本历史。已知限制：SECURITY.md 提到实验性，但未列出具体限制。许可证：MIT 许可证明确。版本变更：未提供 CHANGELOG。维护责任：有 SECURITY.md 和 CI，但未明确维护者。扣分原因：缺少版本历史和变更日志。
证据显示：输出可用性：有 `gt feed` 和 `gt convoy list` 等输出。边际价值：解决了多代理协调问题，但未提供对比数据。成本效益：未提供性能或资源消耗数据。扣分原因：缺乏量化评估。
证据显示：README 和 CI 工作流可追溯，但未提供测试结果。跨源验证：有 CI 和测试文件，但未提供外部验证。事实与推断分离：README 区分了概念和命令，但未明确区分。扣分原因：缺乏测试结果和外部验证。
- 代理具有广泛的权限（文件系统、shell、git 推送），应在隔离环境中运行。
- 依赖众多且未提供漏洞扫描，建议定期检查依赖安全。
- 未提供明确的回滚机制，操作前应备份重要数据。
这个 Agent 能做什么，适合哪些场景？
Gas Town 是一个多智能体工作区管理器，为 Claude Code、GitHub Copilot、Codex 等 AI 编码代理提供持久的工作跟踪和跨代理协调。它解决了代理因重启而丢失上下文、手动协调混乱、难以扩展到 4-10 个以上代理的痛点。核心架构包括 Mayor（AI 协调器）、Town（工作区）、Rigs（项目容器）、Crews（个人工作区）、Polecats（工作代理）、Hooks（基于 git worktree 的持久存储）、Convoys（工作跟踪单元）和 Beads（git 支持的 issue 跟踪）。项目使用 Go 编写，通过 CLI（`gt`）和 Beads CLI（`bd`）提供命令，支持原生安装和 Docker 部署。监控通过 Witness、Deacon 和 Dogs 三级体系实现，并包含 Refinery 合并队列、调度器、Seance 会话发现、Wasteland 联邦网络等功能。
Gas Town 通过 gt CLI 提供工作区初始化（gt install）、项目管理（gt rig add）、代理管理（gt sling、gt agents）、工作跟踪（gt convoy）和监控（gt feed、gt mayor attach）等命令。它利用 git hooks 和 worktree 存储代理工作状态，确保重启后仍可恢复。代理完成后通过 gt done 提交工作，Refinery 使用 Bors 风格合并队列批量合并。gt escalate 用于升级阻塞问题。Seance 通过 .events.jsonl 日志发现和查询先前会话。Wasteland 集成通过 DoltHub 进行跨城镇工作协调。
- 希望协调多个 AI 编码代理处理同一代码库中不同任务的开发团队
- 需要代理重启后保留工作上下文的个人开发者
- 希望在 20-50 个代理规模下监控代理健康并处理卡住代理的团队
- 希望为重复流程（如发布）定义可复用模板（formulas）的组织
- 希望跨多个项目或团队进行工作协作的分布式团队
这个 Agent 有哪些优点和局限？
- 通过 git hooks 实现持久工作状态，代理重启后上下文不丢失
- 支持多种 AI 代理运行时（Claude Code、Codex、GitHub Copilot 等），具有预设和自定义配置
- 提供内置监控、问题升级和合并队列，适合大规模代理编排
- 设置复杂，需要多个前提条件（Git、Go、Beads、tmux、Dolt、ICU4C 等）
- 原生 Windows 支持有限，完整功能需要 WSL
- 依赖具体 CLI 工具和版本，更新可能带来兼容性问题
如何安装或部署这个 Agent？
原生安装（macOS / Linux / Windows）：安装 Git 2.20+、Go 1.26.2+、Beads (bd) 0.57.0+、tmux 3.0+，以及 Dolt。macOS 可通过 brew install gastown 安装；Linux 和 Windows 使用 go install github.com/steveyegge/gastown/cmd/gt@latest 和 go install github.com/steveyegge/beads/cmd/bd@latest。然后运行 gt install ~/gt --shell --git 初始化工作区，gt up 启动服务，gt doctor --fix 验证。Docker：设置环境变量 GIT_USER、GIT_EMAIL、FOLDER，然后 docker compose build、docker compose up -d。
如何使用这个 Agent？
使用 gt mayor attach 启动 Mayor 会话，告诉它要构建什么。Mayor 会创建 convoy 分配工作。具体示例：gt convoy create "Feature X" gt-abc12 gt-def34 --notify --human 创建 convoy，gt sling gt-abc12 myproject 分配任务，gt convoy list 跟踪进度，gt feed 监控活动。对于重复流程，使用 bd cook release --var version=1.2.0。
这个 Agent 与同类方案有什么区别？
与传统的人工协调或简单的代理封装相比，Gas Town 通过持久化存储、自动化合并和监控体系提供更全面的解决方案。