什么是Openclaw Skill Gastown
Openclaw Skill Gastown 是一个建立在 Gas Town（gt）与 Claude Code 之上的多智能体编码编排器，面向的不是一次性脚本或很小的改动，而是多文件协作、功能开发、重构、缺陷修复，以及需要编译、运行、测试的非平凡工程任务。它的基本思路不是让单个智能体长时间硬扛整个上下文，而是把工作拆成可追踪的任务单元，再分发给多个并行工作的智能体去推进。
这套系统的核心价值，在于把“智能体会话”与“工作状态”分开。Gas Town 通过基于 Git worktree 的持久化机制保存工作钩子和任务记录，即使某个智能体重启、切换会话或中途异常，任务本身也不会随着上下文丢失。文档里用 beads 记录工作单元，用 convoy 跟踪一组相关任务，用 polecats 指代执行具体编码工作的临时工智能体，整体更像一套工程化调度层，而不是单纯的聊天式助手。
从架构上看，它并不只是“多开几个 Claude Code 窗口”这么简单。系统内有负责总协调的 Mayor、负责后台巡检的 Deacon、按项目监控工人的 Witness，以及处理合并队列的 Refinery。不同角色分工明确：有的负责拆解和派发，有的负责监控、恢复和提醒，有的负责把各个工作分支汇总回主线。官方说明强调，随着内建的邮箱、身份、交接与路由机制加入，系统能把原本容易混乱的多智能体协作，组织成可持续运行的流程。
因此，它适合的读者并不是只想让 AI 改一两行代码的人，而是已经碰到更复杂的软件开发场景：例如一个需求要跨多个文件、多个步骤和多个分支推进，或者需要并行处理多个问题，同时又希望保留完整的状态、归因和过程可见性。Openclaw Skill Gastown 正是在这种背景下，把 Claude Code 的能力包装成一套更接近团队流水线的调度体系。
核心功能特点
- 以 Git 持久化工作状态，智能体重启或会话切换后任务不会凭记忆丢失
- 通过 beads、molecules 和 convoys 拆分并跟踪复杂任务，适合多步骤、多问题并行推进
- 用 polecats 并行执行编码工作，并由 Witness、Deacon 等角色持续监控与恢复
- 支持按项目容器和工作树组织代码环境，适合跨文件修改、分支隔离与后续合并
- 内建邮件、交接和任务投递机制，减少多智能体协作中的人工协调成本
适用场景
如果团队已经发现，单个智能体在处理较大的开发任务时容易因为上下文膨胀而失去稳定性，那么这类工具就会很有意义。比如新增一个功能时，需要先拆分设计、实现、测试、合并等步骤，还要同时修改多个文件、运行测试、观察结果并继续迭代。Gas Town 把这类工作拆成可执行的小单元后，再交给不同智能体推进，既保留了并行效率，也让每一步都能被记录和回溯。
它也适合经常进行重构和缺陷修复的项目。现实中的重构通常不是一条提示词就能完成：可能涉及多处依赖调整、跨目录修改、验证编译是否通过，以及补充测试。文档明确建议，当任务已经超出“简单脚本”范围，或者涉及多个文件编辑时，应使用这种编排模式。相比让单个会话从头跟到尾，基于 hook 的持久任务分配更适合长链路开发，特别是在中途需要 handoff、恢复或重新分派时。
另一个典型场景，是同一时间有多项工作并行推进，且希望持续掌握状态。convoy 可以把一组相关 issue 作为同一批次追踪，Mayor 负责协调，Witness 负责盯住执行中的 polecats，Refinery 则在后续处理合并队列。对于需要同时推进多个 bug、多个子任务，或者跨项目观察进度的人来说，这种组织方式比手工盯多个终端和分支更清晰，也更接近真实研发流程中的“任务面板 + 工人调度”。
最后，它还适用于那些希望把 AI 开发过程做成“有记录、可归因、可审计”的团队。Gas Town 的工作单元、角色身份和事件流都围绕持久化与追踪来设计，适合关注谁处理了什么、当前卡在什么环节、任务是否真正完成的环境。换句话说，Openclaw Skill Gastown 更像是面向复杂代码工作的调度基础设施，而不是一个只负责生成代码片段的轻量助手。