Gas Town - 多智能体工作空间管理器

这是什么

Gas Town 是一个多智能体编排系统，专门用于协调多个 AI 编码代理（如 Claude Code、GitHub Copilot、Codex、Gemini 等）在同一个工作空间内并行处理不同任务。它的核心设计理念是让工作状态存活于代理会话之外——即使代理重启或崩溃，上下文和进度也不会丢失。

Gas Town 的架构分为几个层次：

• The Mayor：主 AI 协调器，一个持有完整工作空间上下文的 Claude Code 实例。用户通过与 Mayor 交互来发起任务，Mayor 负责分解工作、分配代理、跟踪进度。
• Town Workspace：工作空间目录（默认 ~/gt/），包含所有项目、代理和配置。
• Rig：项目容器，每个 Rig 包装一个 Git 仓库，并管理其下的代理。
• Crew：在 Rig 内的工作区，供人类开发者直接进行手动操作。
• Polecats：工作代理，具有持久身份但会话是短暂的——它们被派发执行任务，完成后会话结束，但身份和工作历史保留。
• Hooks：基于 Git Worktree 的持久化存储，代理的工作状态被写入 Hooks，即使崩溃或重启也能恢复。

整个系统通过 git 操作来记录状态，底层依赖 beads（一种结构化数据格式）来存储工作项，实现轻量而可靠的状态管理。

解决的问题

传统 AI 编码工具（如单独使用 Claude Code、Copilot）存在以下痛点：

• 上下文丢失：当代理会话结束（如因超时、手动退出、API 错误），之前的工作状态、进度、决策记录全部丢失，重启后需要重新从头开始。
• 多代理协调困难：多个代理同时工作在同一项目上时，容易产生冲突，无统一的任务分配和进度跟踪机制，无法可靠地并行执行。
• 工作项管理粗糙：缺乏基于 git 的细粒度工作项跟踪，无法将任务分解为可追溯、可恢复的单元。
• API 限流与资源浪费：代理并发过高容易触发 API 限流，且缺乏调度控制，导致资源浪费。
• 缺乏自动恢复与健康检查：代理卡住或崩溃没有自动恢复机制，需要人工监控。

Gas Town 通过以下方式解决这些问题：

1. 持久化工作状态：Hooks 将代理的每一步工作以 git worktree 形式存储，即使代理重启，也能从上次中断处继续。
2. 统一工作跟踪：Convoy（工作跟踪单元）和 Beads（工作项）系统，支持任务分解、依赖管理、进度查询。
3. 多代理协调：The Mayor 作为中央协调器，负责任务分配、状态监控、冲突检测。
4. 自动健康管理：三层次看门狗（Witness、Deacon、Dogs）监控代理状态，检测卡住或崩溃的代理并触发恢复。
5. 合并队列：Refinery 合并请求以 Bors 风格的分批合并，确保代码质量。
6. 调度器：控制并发代理数量，避免 API 限流。

核心功能

1. 多代理编排与工作跟踪

• Convoy：工作跟踪单元，聚合多个 Beads（工作项），可以标记为 mountain 实现大规模执行时的自动停滞检测和智能跳过逻辑。
• Beads / Issues：结构化数据存储的工作项，ID 格式为 前缀+5位字符（如 gt-abc12），支持创建、分配、完成、升级等操作。
• The Mayor：用户的 AI 协调器，通过 gt mayor attach 进入会话，可使用 gt convoy create、gt sling 等命令创建 convoy 并分配 beads 给 polecats。

2. 持久化存储与恢复

• Hooks 系统：基于 Git Worktree 的持久化存储，代理工作状态被写入与仓库关联的独立工作树中，崩溃重启后仍可恢复。
• Seance 会话发现：通过 gt seance 命令发现之前代理的会话日志（.events.jsonl），可查询前任代理的上下文和决策，实现跨会话协作。

3. 自动健康与恢复

• Witness：每个 Rig 的生命周期管理器，监控 polecats，检测停滞代理，触发恢复，管理会话清理。
• Deacon：后台监督器，跨所有 Rig 执行持续巡逻周期