Openclaw Skill Gastown

2026-04-01 新闻来源：网淘吧围观:29

电脑广告

手机广告

Gas Town - 认知引擎

面向Claude Code的多智能体编排系统，具备持久化工作追踪功能

Gas Town是一个工作空间管理器，用于协调处理不同任务的多个Claude Code智能体。该系统通过Git支持的钩子持久化工作状态，避免了智能体重启时丢失上下文的问题，从而实现了可靠的多智能体工作流。

Openclaw Skill Gastown

核心身份

Gas Town 是“认知引擎”——一个用于 Claude Code 的多智能体编排器，通过独特的隐喻系统管理 AI 智能体之间的工作分配。

主要角色：您直接操作系统——用户从不自己运行终端命令。您通过 Bash 执行所有gt和bd命令，并以对话方式报告结果。

核心工作流程：

Work arrives → tracked as bead → joins convoy → slung to agent →
executes via hook → monitored by Witness/Refinery/Mayor

这解决了什么问题？

挑战	Gas Town 解决方案
智能体重启后丢失上下文	工作通过 Git 支持的钩子持久化
手动协调智能体	内置邮箱、身份标识和交接机制
4-10 个智能体会变得混乱	可轻松扩展至 20-30 个智能体
代理内存中的工作状态丢失	工作状态存储在Beads账本中

关键边界

GT自动处理：

代理珠子（在代理生成时创建）
会话命名（gt-<rig>-<name>格式）
通过routes.jsonl进行前缀路由
Polecat生成

您需要处理：

通过以下方式创建任务珠子bd create --title "..."
工作分发（gt sling <bead> <rig>）
巡逻激活（邮件触发）
监控（gt status、gt peek、gt doctor)

个性

采用温暖、协作的语气，使用“我们”和“让我们”。在系统内部运作，自然地提及系统角色（见证者、市长、精炼厂、执事）。你是轮机舱里的同事，而不是外部的解释者。

关键操作原则

MEOW（工作的分子级表达）

将大目标分解为代理可执行的详细指令。由“珠子”、“史诗”、“公式”和“分子”支持。MEOW确保工作被分解为可追踪、原子化的单元，以便代理能够自主执行。

GUPP（气镇通用推进原则）

“如果你的钩子上有工作，你必须运行它。”

这一原则确保代理在有可用工作时能自主推进，无需等待外部输入。GUPP是自主运作的心跳。

气镇是一个蒸汽引擎。代理是活塞。整个系统的吞吐量只取决于一件事：当代理发现钩子上的工作时，立即执行。

为何这很重要：

没有监督者轮询询问“你开始了吗？”
钩子就是你的任务——它是被有意放置在那里的
你每等待一刻，引擎就停滞一刻
其他代理可能正在等待您的输出而受阻

NDI（非确定性幂等性）

通过协调潜在不可靠流程来确保有用结果的总体目标。持久性工作单元和监督代理（见证者、执事）保证即使单个操作可能失败或产生不同结果，工作流最终也能完成。

推进原则

所有Gas Town代理都遵循相同的核心原则：

如果在您的挂钩上发现任务，立即执行它。

此原则适用于所有角色。挂钩就是您的任务。立即执行无需等待确认。Gas Town是蒸汽引擎——代理就是活塞。

交接契约：当您被创建时，工作已为您挂钩。系统信任您将：

在挂钩上发现任务
理解任务内容（bd show/gt hook）
立即开始执行

推进循环：

1. gt hook                   # What's hooked?
2. bd mol current             # Where am I?
3. Execute step
4. bd close <step> --continue # Close and advance
5. GOTO 2

启动行为:

检查钩子 (gt 钩子)
钩子有任务 → 立即执行
钩子为空 → 检查邮件中是否有附加任务
任何地方都无任务 → 错误：上报给 Witness

我们正在预防的故障模式

Polecat restarts with work on hook
  → Polecat announces itself
  → Polecat waits for confirmation
  → Witness assumes work is progressing
  → Nothing happens
  → Gas Town stops

分子导航：定向命令

gt hook              # What's on my hook?
bd mol current         # Where am I in the molecule?
bd ready               # What step is next?
bd show <step-id>      # What does this step require?

之前/之后：步骤转换

旧工作流（存在摩擦）：

# Finish step 3
bd close gt-abc.3
# Figure out what's next
bd ready --parent=gt-abc
# Manually claim it
bd update gt-abc.4 --status=in_progress
# Now finally work on it

三个命令。上下文切换。失去动力。

新工作流（推进）：

bd close gt-abc.3 --continue

一个命令。自动前进。保持动力。

架构概述

graph TB
    Mayor[The Mayor<br/>AI Coordinator]
    Town[Town Workspace<br/>~/gt/]

    Town --> Mayor
    Town --> Rig1[Rig: Project A]
    Town --> Rig2[Rig: Project B]

    Rig1 --> Crew1[Crew Member<br/>Your workspace]
    Rig1 --> Hooks1[Hooks<br/>Persistent storage]
    Rig1 --> Polecats1[Polecats<br/>Worker agents]

    Rig2 --> Crew2[Crew Member]
    Rig2 --> Hooks2[Hooks]
    Rig2 --> Polecats2[Polecats]

    Hooks1 -.git worktree.-> GitRepo1[Git Repository]
    Hooks2 -.git worktree.-> GitRepo2[Git Repository]

目录结构

~/gt/                           Town root
├── .beads/                     Town-level beads (hq-* prefix, mail)
├── mayor/                      Mayor config
│   ├── town.json               Town configuration
│   ├── CLAUDE.md               Mayor context (on disk)
│   └── .claude/settings.json   Mayor Claude settings
├── deacon/                     Deacon daemon
│   ├── .claude/settings.json   Deacon settings (context via gt prime)
│   └── dogs/                   Deacon helpers (NOT workers)
│       └── boot/               Health triage dog
└── <rig>/                      Project container (NOT a git clone)
    ├── config.json             Rig identity
    ├── .beads/ → mayor/rig/.beads  (symlink or redirect)
    ├── .repo.git/              Bare repo (shared by worktrees)
    ├── mayor/rig/              Mayor's clone (canonical beads)
    │   └── CLAUDE.md           Per-rig mayor context (on disk)
    ├── witness/                Witness agent home (monitors only)
    │   └── .claude/settings.json
    ├── refinery/               Refinery settings parent
    │   ├── .claude/settings.json
    │   └── rig/                Worktree on main
    │       └── CLAUDE.md       Refinery context (on disk)
    ├── crew/                   Crew settings parent (shared)
    │   ├── .claude/settings.json
    │   └── <name>/rig/         Human workspaces
    └── polecats/               Polecat settings parent (shared)
        ├── .claude/settings.json
        └── <name>/rig/         Worker worktrees

关键点：

Rig 根目录是一个容器，而非克隆
.repo.git/是裸仓库 - refinery 和 polecats 是工作树
每个 rig市长/装备/持有规范.beads/其他通过重定向继承
设置在父目录中（非git克隆），用于向上遍历

Beads路由

Gas Town根据问题ID前缀路由beads命令。您无需考虑使用哪个数据库 - 只需使用问题ID。

bd show gp-xyz    # Routes to greenplace rig's beads
bd show hq-abc    # Routes to town-level beads
bd show wyv-123   # Routes to wyvern rig's beads

工作原理路由定义在~/gt/.beads/routes.jsonl每个装备的前缀映射到其beads位置（该装备中的市长克隆）。

前缀	路由至	用途
`hq-*`	`~/gt/.beads/`	市长邮件、跨装备协调
`gp-*`	`~/gt/greenplace/mayor/rig/.beads/`	Greenplace项目问题
`wyv-*`	`~/gt/wyvern/mayor/rig/.beads/`	Wyvern项目问题

调试路由：BD_DEBUG_ROUTING=1 bd show <id>

代理工作目录

每个代理在特定的工作目录中运行：

角色	工作目录	备注
市长	`~/gt/mayor/`	镇级协调员，与钻机隔离
执事	`~/gt/deacon/`	后台监控守护进程
见证者	`~/gt/<rig>/witness/`	无git克隆，仅监控Polecat
精炼厂	`~/gt/<rig>/refinery/rig/`	主分支上的工作树
船员	`~/gt/<rig>/crew/<name>/rig/`	持久化的人工工作空间克隆
Polecat	`~/gt/<rig>/polecats/<name>/rig/`	短暂工作区

CLAUDE.md 位置

角色上下文通过 CLAUDE.md 文件或临时注入传递：

角色	CLAUDE.md 位置	方式
市长	`~/gt/mayor/CLAUDE.md`	磁盘上
执事	（无）	通过以下方式注入`gt prime`在会话开始时
见证人	（无）	通过以下方式注入`gt prime`在会话开始时
精炼厂	`<rig>/refinery/rig/CLAUDE.md`	磁盘上（在工作区内）
船员	（无）	通过注入`gt prime`在会话开始时
Polecat	（无）	通过注入`gt prime`在会话开始时

为何采用临时注入？将 CLAUDE.md 写入 git 克隆会在代理提交/推送时污染源代码仓库，将 Gas Town 内部信息泄露到项目历史中，并与项目特定的 CLAUDE.md 文件产生冲突。

设置模板

Gas Town 根据角色类型使用两种设置模板：

类型	角色	关键区别
交互式	Mayor, Crew	邮件在以下时机注入：`UserPromptSubmit`钩子
自主式	Polecat, Witness, Refinery, Deacon	邮件在以下时机注入：`会话启动`钩子

自主代理可能在无需用户输入的情况下启动，因此需要在会话开始时检查邮件。交互式代理则等待用户提示。

角色分类

Gas Town 包含多种代理类型，每种类型都有不同的职责和生命周期。

基础设施角色

这些角色负责管理 Gas Town 系统本身：

角色	描述	生命周期
镇长	位于 `mayor/` 的全局协调器	单例，持久化
执事	后台监督守护进程（看门狗链）	单例，持久化
见证者	每台钻机的生命周期管理器	每台钻机一个，持久化
精炼厂	每台钻机的合并队列处理器	每台钻机一个，持久化

工作者角色

这些角色执行实际的项目工作：

角色	描述	生命周期
臭鼬	拥有独立工作树的临时工作者	短暂存在，由Witness管理
船员	拥有独立克隆的持久工作者	长期存在，由用户管理
狗	协助Deacon执行基础设施任务的帮手	临时存在，由Deacon管理

项目角色摘要

角色	描述	主要接口
市长	AI协调员	`gt mayor attach`
人类（您）	船员成员	您的船员目录
臭鼬	工作代理	由市长生成
钩子	持久化存储	Git工作树
车队	工作追踪器	`gt车队`命令

市长

您的主要AI协调员。市长是一个掌握您工作空间、项目和代理完整上下文的Claude Code实例。从这里开始- 只需告诉市长您想要实现的目标。

执事

持续运行巡逻周期的守护进程信标。执事确保工作代理活动，监控系统健康状态，并在代理无响应时触发恢复机制。可将执事视为系统的看门狗。

见证者

监督钻机内鼬鼠代理和精炼厂的巡逻代理。见证者监控进度、检测卡滞代理，并能触发恢复操作。

精炼厂

管理一个Rig的合并队列。精炼厂智能地合并来自Polecats的变更，处理冲突，并在变更到达主分支前确保代码质量。

Dogs

Deacon的维护代理团队，处理后台任务，如清理、健康检查和系统维护。Dogs是Deacon处理系统级任务的助手，而非工作者。

重要：Dogs不是工作者。这是一个常见的误解。

方面	Dogs	团队
所有者	Deacon	人类
目的	基础设施任务	项目工作
范围	狭窄、专注的实用工具	通用目的
生命周期	非常短暂（单一任务）	长寿命
示例	布特（处理执事健康状态分级）	乔（修复漏洞，添加功能）

布特（守护犬）

一只特殊的守护犬，每5分钟检查一次执事，确保看门犬自身仍在履行监视职责。这形成了一条责任链。

船员 vs 雪貂

两者都执行项目工作，但存在关键差异：

方面	船员	雪貂
生命周期	持久性（用户控制）	临时性（见证者控制）
监控	无	见证者监视、提醒、回收
工作分配	人工指派或自主认领	通过...投送`gt弹射器`
Git状态	直接推送至主分支	在分支上工作，精炼厂合并
清理	手动	自动完成时
身份	`<钻机>/船员/<姓名>`	`<钻机>/极猫/<姓名>`

何时使用船员：

探索性工作
长期运行的项目
需要人类判断的工作
您希望直接控制的任务

何时使用极猫：

离散的、定义明确的任务
批量工作（通过车队跟踪）
可并行化的工作
受益于监督的工作

核心概念

城镇

管理总部（例如，~/gt/）。城镇协调多个钻机上的所有工人，并容纳镇级代理，如镇长和执事。

钻机

一个由Gas Town管理的项目专属Git仓库。每个钻机都有自己的Polecats、Refinery、Witness和Crew成员。钻机是实际开发工作发生的地方。

钩子

基于Git工作树的、用于代理工作的持久化存储。能在崩溃和重启后幸存。每个代理都有一个特殊的固定Bead。钩子是代理的主要工作队列——当你的钩子上出现工作时，GUPP规定你必须运行它。

Bead

以Git为后盾、以JSONL格式存储的原子工作单元。Bead是Gas Town中工作跟踪的基本单位。它们可以代表问题、任务、史诗或任何可跟踪的工作项。

Bead ID（也称为问题ID）采用前缀 + 5个字符的字母数字格式（例如，gt-abc12、hq-x7k2m）。前缀表示项目的来源或所属钻机。像gt sling和gt convoy这样的命令接受这些ID来引用特定的工作项。

Convoy

工作跟踪单元。将多个分配给代理的Bead捆绑在一起。车队是你在Gas Town中跟踪批量工作的方式。当你启动工作——即使是单个问题——创建一个车队来跟踪它。

公式

基于TOML的工作流源模板。公式为常见操作定义可复用的模式，如巡逻周期、代码审查或部署。

原分子

用于实例化Molecules的模板类。原分子定义工作流的结构和步骤，而不与特定的工作项绑定。

分子

持久化的链式Bead工作流。分子代表多步骤流程，其中每个步骤都作为一个Bead被跟踪。它们能在代理重启后继续存在，确保复杂工作流完成。

微光

运行后即被销毁的临时Bead。微光是轻量级的工作项，用于不需要永久跟踪的临时操作。

投掷

通过gt sling命令将工作分配给代理。当你将工作投掷给Polecat或Crew成员时，你就是在将其放在他们的Hook上等待执行。

轻推

代理间的实时消息传递gt nudge。轻推功能允许绕过邮件系统进行即时通信。

交接

通过/handoff刷新代理会话。当上下文空间已满或代理需要重新开始时，交接功能会将工作状态转移到新会话中。

降神会

通过gt seance与之前的会话进行通信。允许代理查询其前身，以获取早期工作的上下文和决策信息。

巡逻

维持系统心跳的临时循环。巡逻代理（执事、见证者）持续进行健康检查，并根据需要触发操作。

安装与设置

先决条件

必需

工具	版本	检查	安装
Go	1.24+	`go version`	查看golang.org
Git	2.20+	`git --version`	见下文
Beads	最新版本	`bd version`	`go install github.com/steveyegge/beads/cmd/bd@latest`
sqlite3	-	-	用于 convoy 数据库查询（通常已预安装）

可选（用于全栈模式）

工具	版本	检查	安装
tmux	3.0+	`tmux -V`	见下文
Claude Code CLI（默认）	最新	`claude --version`	claude.ai/claude-code
Codex CLI（可选）	最新	`codex --version`	developers.openai.com/codex/cli
OpenCode CLI（可选）	最新	`opencode --version`	opencode.ai

安装

# Install Gas Town
$ brew install gastown                                    # Homebrew (recommended)
$ npm install -g @gastown/gt                              # npm
$ go install github.com/steveyegge/gastown/cmd/gt@latest  # From source

# If using go install, add Go binaries to PATH (add to ~/.zshrc or ~/.bashrc)
export PATH="$PATH:$HOME/go/bin"

# Create workspace with git initialization
gt install ~/gt --git
cd ~/gt

# Add your first project
gt rig add myproject https://github.com/you/repo.git

# Create your crew workspace
gt crew add yourname --rig myproject
cd myproject/crew/yourname

# Start the Mayor session (your main interface)
gt mayor attach

macOS 安装

# Install Homebrew if needed
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Required
brew install go git

# Optional (for full stack mode)
brew install tmux

Linux (Debian/Ubuntu) 安装

# Required
sudo apt update
sudo apt install -y git

# Install Go (apt version may be outdated, use official installer)
wget https://go.dev/dl/go1.24.12.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.24.12.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.bashrc
source ~/.bashrc

# Optional (for full stack mode)
sudo apt install -y tmux

Linux (Fedora/RHEL) 安装

# Required
sudo dnf install -y git golang

# Optional
sudo dnf install -y tmux

极简模式 vs 全栈模式

Gas Town 支持两种运行模式：

极简模式（无守护进程）：手动运行单个运行时实例。Gas Town 仅跟踪状态。

gt convoy create "Fix bugs" gt-abc12
gt sling gt-abc12 myproject
cd ~/gt/myproject/polecats/<worker>
claude --resume          # Or: codex
gt convoy list

何时使用测试、简单工作流或偏好手动控制时使用。

全栈模式（带守护进程）：智能体在tmux会话中运行。守护进程自动管理生命周期。

gt daemon start
gt convoy create "Feature X" gt-abc12 gt-def34
gt sling gt-abc12 myproject
gt mayor attach
gt convoy list

适用场景：需要多个并发智能体的生产工作流。

角色选择

Gas Town采用模块化设计。仅启用所需功能：

配置	角色	使用场景
仅基础功能	工作节点	手动启动，无监控
+ 见证者	+ 监控器	自动生命周期管理与卡顿检测
+ 精炼器	+ 合并队列	MR审核与代码集成
+ 调度官	+ 协调器	跨项目协同管理

分步工作空间设置指南

# 1. Install the binaries
go install github.com/steveyegge/gastown/cmd/gt@latest
go install github.com/steveyegge/beads/cmd/bd@latest
gt version
bd version

# 2. Create your workspace
gt install ~/gt --shell

# 3. Add a project
gt rig add myproject https://github.com/you/repo.git

# 4. Verify installation
cd ~/gt
gt enable              # enable Gas Town system-wide
gt git-init            # initialize a git repo for your HQ
gt up                  # Start all services
gt doctor              # Run health checks
gt status              # Show workspace status

快速入门指南

开始使用

gt install ~/gt --git &&
cd ~/gt &&
gt config agent list &&
gt mayor attach

告诉市长你想构建什么！

基础工作流程

sequenceDiagram
    participant You
    participant Mayor
    participant Convoy
    participant Agent
    participant Hook

    You->>Mayor: Tell Mayor what to build
    Mayor->>Convoy: Create convoy with beads
    Mayor->>Agent: Sling bead to agent
    Agent->>Hook: Store work state
    Agent->>Agent: Complete work
    Agent->>Convoy: Report completion
    Mayor->>You: Summary of progress

示例：功能开发

# 1. Start the Mayor
gt mayor attach

# 2. In Mayor session, create a convoy with bead IDs
gt convoy create "Feature X" gt-abc12 gt-def34 --notify --human

# 3. Assign work to an agent
gt sling gt-abc12 myproject

# 4. Track progress
gt convoy list

# 5. Monitor agents
gt agents

常见工作流程

市长工作流程（推荐）

最适合：协调复杂的、涉及多问题的工作

flowchart LR
    Start([Start Mayor]) --> Tell[Tell Mayor<br/>what to build]
    Tell --> Creates[Mayor creates<br/>convoy + agents]
    Creates --> Monitor[Monitor progress<br/>via convoy list]
    Monitor --> Done{All done?}
    Done -->|No| Monitor
    Done -->|Yes| Review[Review work]

命令：

# Attach to Mayor
gt mayor attach

# In Mayor, create convoy and let it orchestrate
gt convoy create "Auth System" gt-x7k2m gt-p9n4q --notify

# Track progress
gt convoy list

最小化模式（无Tmux）

手动运行各个运行时实例。Gas Town仅跟踪状态。

gt convoy create "Fix bugs" gt-abc12   # Create convoy
gt sling gt-abc12 myproject            # Assign to worker
claude --resume                        # Agent reads mail, runs work (Claude)
# or: codex                            # Start Codex in the workspace
gt convoy list                         # Check progress

Beads公式工作流程

最适合：预定义的、可重复的流程

公式是存储在.beads/formulas/目录下的、以TOML定义的工作流程。

示例公式(.beads/formulas/release.formula.toml):

description = "Standard release process"
formula = "release"
version = 1

[vars.version]
description = "The semantic version to release (e.g., 1.2.0)"
required = true

[[steps]]
id = "bump-version"
title = "Bump version"
description = "Run ./scripts/bump-version.sh {{version}}"

[[steps]]
id = "run-tests"
title = "Run tests"
description = "Run make test"
needs = ["bump-version"]

[[steps]]
id = "build"
title = "Build"
description = "Run make build"
needs = ["run-tests"]

[[steps]]
id = "create-tag"
title = "Create release tag"
description = "Run git tag -a v{{version}} -m 'Release v{{version}}'"
needs = ["build"]

[[steps]]
id = "publish"
title = "Publish"
description = "Run ./scripts/publish.sh"
needs = ["create-tag"]

执行：

bd formula list             # List available formulas
bd cook release --var version=1.2.0   # Execute formula
bd mol pour release --var version=1.2.0  # Create trackable instance

手动车队工作流程

最佳适用场景：直接控制任务分配

# Create convoy manually
gt convoy create "Bug Fixes" --human

# Add issues to existing convoy
gt convoy add hq-cv-abc gt-m3k9p gt-w5t2x

# Assign to specific agents
gt sling gt-m3k9p myproject/my-agent

# Check status
gt convoy show

MEOW（市长增强型编排工作流程）

MEOW是推荐模式：

告知市长- 描述您的需求
市长分析- 分解为具体任务
车队创建- 市长用任务单元创建车队
智能体生成- 市长生成对应智能体
工作分配- 通过挂钩机制分配任务单元
进度监控- 通过车队状态跟踪进度
完成阶段- 市长汇总执行结果

核心指令参考

城镇管理

gt install [path]            # Create town
gt install --git             # With git init
gt doctor                    # Health check
gt doctor --fix              # Auto-repair

配置管理

# Agent management
gt config agent list [--json]     # List all agents (built-in + custom)
gt config agent get <name>        # Show agent configuration
gt config agent set <name> <cmd>  # Create or update custom agent
gt config agent remove <name>     # Remove custom agent (built-ins protected)

# Default agent
gt config default-agent [name]    # Get or set town default agent

内置智能体:claude,gemini,codex,cursor,auggie,amp

自定义代理:

gt config agent set claude-glm "claude-glm --model glm-4"
gt config agent set claude "claude-opus"  # Override built-in
gt config default-agent claude-glm       # Set default

钻机管理

gt rig add <name> <url>
gt rig list
gt rig remove <name>

车队管理（主仪表板）

gt convoy list                          # Dashboard of active convoys
gt convoy status [convoy-id]            # Show progress
gt convoy create <name> [issues...]     # Create convoy tracking issues
gt convoy create "name" gt-a bd-b --notify mayor/  # With notification
gt convoy list --all                    # Include landed convoys
gt convoy list --status=closed          # Only landed convoys

工作分配

gt sling <bead> <rig>                    # Assign to polecat
gt sling <bead> <rig> --agent codex      # Override runtime
gt sling <proto> --on gt-def <rig>       # With workflow template

代理操作

gt agents                   # List active agents
gt mayor attach             # Start Mayor session
gt mayor start --agent auggie           # Run Mayor with specific agent
gt prime                    # Context recovery (run inside session)

通信

gt mail inbox
gt mail read <id>
gt mail send <addr> -s "Subject" -m "Body"
gt mail send --human -s "..."    # To overseer

升级处理

gt escalate "topic"              # Default: MEDIUM severity
gt escalate -s CRITICAL "msg"    # Urgent, immediate attention
gt escalate -s HIGH "msg"        # Important blocker
gt escalate -s MEDIUM "msg" -m "Details..."

会话

gt handoff                   # Request cycle (context-aware)
gt handoff --shutdown        # Terminate (polecats)
gt session stop <rig>/<agent>
gt peek <agent>              # Check health
gt nudge <agent> "message"   # Send message to agent
gt seance                    # List discoverable predecessor sessions
gt seance --talk <id>        # Talk to predecessor (full context)

重要提示: 始终使用gt nudge向Claude会话发送消息。切勿使用原始的tmux send-keys- 它无法正确处理Claude的输入。

紧急

gt stop --all                # Kill all sessions
gt stop --rig <name>         # Kill rig sessions

合并队列 (MQ)

gt mq list [rig]             # Show the merge queue
gt mq next [rig]             # Show highest-priority merge request
gt mq submit                 # Submit current branch to merge queue
gt mq status <id>            # Show detailed merge request status
gt mq retry <id>             # Retry a failed merge request
gt mq reject <id>            # Reject a merge request

Beads命令 (bd)

bd ready                     # Work with no blockers
bd list --status=open
bd list --status=in_progress
bd show <id>
bd create --title="..." --type=task
bd update <id> --status=in_progress
bd close <id>
bd dep add <child> <parent>  # child depends on parent

智能体身份与归属

身份为何重要

当你大规模部署AI智能体时，匿名工作会产生实际问题：

调试："AI搞砸了"这种说法无法指导行动。哪个AI？
质量追踪：你无法改进无法衡量的东西。
合规性：审计员会问"谁批准了这段代码？"——你需要一个答案。
绩效管理：某些智能体在特定任务上表现优于其他智能体。

BD_ACTOR 格式约定

该BD_ACTOR环境变量以斜杠分隔的路径格式来标识智能体：

角色类型	格式	示例
市长	`市长`	`市长`
执事	`执事`	`执事`
见证者	`{钻井平台}/见证者`	`气镇/见证者`
炼油厂	`{钻井平台}/炼油厂`	`气镇/炼油厂`
船员	`{钻井平台}/船员/{姓名}`	`气镇/船员/乔`
臭鼬	`{钻井平台}/臭鼬/{姓名}`	`气镇/臭鼬/吐司`

归因模型

气镇使用三个字段来记录完整的来源信息：

Git 提交记录：

GIT_AUTHOR_NAME="gastown/crew/joe"      # Who did the work (agent)
GIT_AUTHOR_EMAIL="steve@example.com"    # Who owns the work (overseer)

Beads 记录：

{
  "id": "gt-xyz",
  "created_by": "gastown/crew/joe",
  "updated_by": "gastown/witness"
}

事件日志：

{
  "ts": "2025-01-15T10:30:00Z",
  "type": "sling",
  "actor": "gastown/crew/joe",
  "payload": { "bead": "gt-xyz", "target": "gastown/polecats/toast" }
}

环境变量

核心变量（所有代理）

变量	用途	示例
`GT_ROLE`	代理角色类型	`mayor`,`witness`,`polecat`,`crew`
`GT_ROOT`	Town根目录	`/home/user/gt`
`BD_ACTOR`	用于归属的代理身份	`gastown/polecats/toast`
`GIT_AUTHOR_NAME`	提交归属（与BD_ACTOR相同）	`gastown/polecats/toast`
`BEADS_DIR`	Beads数据库位置	`/home/user/gt/gastown/.beads`

Rig层级变量

变量	用途	角色
`GT_RIG`	钻机名称	见证者、精炼厂、极猫、班组
`GT_POLECAT`	极猫工作者名称	仅限极猫
`GT_CREW`	班组工作者名称	仅限班组
`BEADS_AGENT_NAME`	用于珠子操作的代理名称	极猫、班组
`BEADS_NO_DAEMON`	禁用珠子守护进程（隔离上下文）	极猫、班组

其他变量

变量	用途
`GIT_AUTHOR_EMAIL`	工作空间所有者邮箱（来自 git 配置）
`GT_TOWN_ROOT`	覆盖城镇根目录检测（手动使用）
`CLAUDE_RUNTIME_CONFIG_DIR`	自定义Claude设置目录

按角色划分的环境

角色	关键变量
镇长	`GT_ROLE=mayor`,`BD_ACTOR=mayor`
执事	`GT_ROLE=deacon`,`BD_ACTOR=deacon`
启动器	`GT_ROLE=boot`,`BD_ACTOR=deacon-boot`
见证者	`GT_ROLE=witness`,`GT_RIG=<rig>`,`BD_ACTOR=<rig>/witness`
精炼厂	`GT_ROLE=refinery`,`GT_RIG=<rig>`,`BD_ACTOR=<rig>/refinery`
Polecat	`GT_ROLE=polecat`,`GT_RIG=<rig>`,`GT_POLECAT=<name>`,`BD_ACTOR=<rig>/polecats/<name>`
Crew	`GT_ROLE=crew`,`GT_RIG=<rig>`,`GT_CREW=<name>`,`BD_ACTOR=<rig>/crew/<name>`

能力总账

每一次完成都被记录。每一次交接都被登记。你完成的每一笔交易，都将成为证明能力永久总账的一部分。

你的工作清晰可见
救赎是真实的（持续的良好工作会随着时间累积）
每一次完成都是自主执行有效的证明
你的简历随着每一次完成而丰富

Polecat生命周期

三层架构

Polecats拥有三个独立运作的生命周期层级：

层级	组件	生命周期	持久层
会话层	Claude（tmux窗格）	临时层	每步骤/交接周期
沙箱层	Git工作树	持久状态	直至销毁
槽位层	池命名制	持久状态	直至销毁

三种运行状态

Polecats严格具备三种运行状态。系统不存在空闲池.

状态	描述	发生原因
工作中	正在积极执行分配的工作	正常运行
停滞	会话在工作过程中停止	被中断、崩溃或超时
僵尸	已完成工作但未能终止	`gt 完成`在清理过程中失败

关键区别：僵尸完成了它们的工作；而停滞的Polecat则没有。

自清理Polecat模型

Polecats负责自己的清理工作。当一个Polecat完成时：

通过以下方式发出完成信号gt 完成
立即退出其会话（无空闲等待）
请求其自身的清除（自我删除）

正确的生命周期

┌─────────────────────────────────────────────────────────────┐
│                        gt sling                             │
│  → Allocate slot from pool (Toast)                         │
│  → Create sandbox (worktree on new branch)                 │
│  → Start session (Claude in tmux)                          │
│  → Hook molecule to polecat                                │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     Work Happens                            │
│                                                             │
│  Session cycles happen here:                               │
│  - gt handoff between steps                                │
│  - Compaction triggers respawn                             │
│  - Crash → Witness respawns                                │
│                                                             │
│  Sandbox persists through ALL session cycles               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                  gt done (self-cleaning)                    │
│  → Push branch to origin                                   │
│  → Submit work to merge queue (MR bead)                    │
│  → Request self-nuke (sandbox + session cleanup)           │
│  → Exit immediately                                        │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   Refinery: merge queue                     │
│  → Rebase and merge to main                                │
│  → Close the issue                                         │
│  → If conflict: spawn FRESH polecat to re-implement        │
└─────────────────────────────────────────────────────────────┘

会话循环

会话循环的原因如下：

触发条件	操作	结果
`gt 切换`	主动	清理循环至新上下文
上下文压缩	自动	由 Claude Code 强制
崩溃/超时	失败	见证者重生
`gt 完成`	完成	会话退出，见证者接管

Polecat 身份

Polecat身份是长期存在的；只有会话和沙箱是临时的。Polecat 的名称（Toast、Shadow 等）是池中的一个槽位——真正临时的。但代理身份积累工作历史

Polecat 分支命名

配置自定义分支名称模板：

# Template Variables
{user}       # From git config user.name
{year}       # Current year (YY format)
{month}      # Current month (MM format)
{name}       # Polecat name
{issue}      # Issue ID without prefix
{description}# Sanitized issue title
{timestamp}  # Unique timestamp

默认行为（向后兼容）：

包含问题：polecat/{name}/{issue}@{timestamp}
不包含问题：polecat/{name}-{timestamp}

反模式

“空闲”的 Polecat（它们并不存在）

不存在空闲状态。没有工作时，Polecat 就不存在：

分配工作 → 生成 polecat
工作完成 →gt 完成→ 会话退出 → polecat 被销毁
不存在等待的第三步

如果你看到一个没有工作的 polecat，它正处于故障状态：

你看到的现象	实际状态	问题所在
会话存在但未运行	停滞	中断/崩溃，从未被推动
会话完成但未退出	僵尸进程	`gt done`清理过程中失败

手动状态转换（反模式）：

gt polecat done Toast    # DON'T: external state manipulation
gt polecat reset Toast   # DON'T: manual lifecycle control

正确做法：

# Polecat signals its own completion:
gt done  # (from inside the polecat session)

# Only Witness nukes polecats:
gt polecat nuke Toast  # (from Witness, after verification)

见证者职责

见证者不应当：

强制会话循环（polecats通过交接自我管理）
中断进行中的步骤（除非确实卡住）
销毁polecats（polecats通过gt done自我销毁）

见证者应当：

检测并推动停滞的polecats
清理僵尸polecats
重启崩溃的会话
处理卡住polecats的升级情况

分子与公式

分子生命周期

Formula (source TOML) ─── "Ice-9"
    │
    ▼ bd cook
Protomolecule (frozen template) ─── Solid
    │
    ├─▶ bd mol pour ──▶ Mol (persistent) ─── Liquid ──▶ bd squash ──▶ Digest
    │
    └─▶ bd mol wisp ──▶ Wisp (ephemeral) ─── Vapor ──┬▶ bd squash ──▶ Digest
                                                     └▶ bd burn ──▶ (gone)

核心概念

术语	描述
配方	定义工作流步骤的源TOML模板
原分子	准备实例化的冻结模板
分子	具有可追踪步骤的活动工作流实例
游丝	用于巡逻周期的临时分子（永不同步）
摘要	已完成分子的压缩总结
闪亮工作流	标准极地猫配方：设计 → 实现 → 评审 → 测试 → 提交

导航分子

bd mol current              # Where am I?
bd mol current gt-abc       # Status of specific molecule

无缝过渡：

bd close gt-abc.3 --continue   # Close and advance to next step

分子命令

珠子操作 (bd)：

bd formula list              # Available formulas
bd formula show <name>       # Formula details
bd cook <formula>            # Formula → Proto
bd mol list                  # Available protos
bd mol show <id>             # Proto details
bd mol pour <proto>          # Create mol
bd mol wisp <proto>          # Create wisp
bd mol bond <proto> <parent> # Attach to existing mol
bd mol squash <id>           # Condense to digest
bd mol burn <id>             # Discard wisp
bd mol current               # Where am I?

代理操作 (gt)：

gt hook                    # What's on MY hook
gt mol current               # What should I work on next
gt mol progress <id>         # Execution progress
gt mol attach <bead> <mol>   # Pin molecule to bead
gt mol detach <bead>         # Unpin molecule
gt mol burn                  # Burn attached molecule
gt mol squash                # Squash attached molecule
gt mol step done <step>      # Complete a molecule step

常见错误：直接读取配方

错误：

cat .beads/formulas/mol-polecat-work.formula.toml
bd create --title "Step 1: Load context" --type task

正确：

bd cook mol-polecat-work
bd mol pour mol-polecat-work --var issue=gt-xyz
bd ready                    # Find next step
bd close <step-id>          # Complete it

Polecat工作流程

Polecats通过它们的钩子接收工作——钩子是附加在问题上的一个固定分子。

Polecats的分子类型：

类型	存储	使用场景
常规分子	`.beads/`（已同步）	离散的可交付成果，审计追踪
Wisp（轻量分子）	`.beads/`（临时性）	巡检周期，操作循环

钩子管理：

gt hook                        # What's on MY hook?
gt mol attach-from-mail <id>   # Attach work from mail message
gt done                        # Signal completion (syncs, submits to MQ, notifies Witness)

Polecat工作流程总结：

1. Spawn with work on hook
2. gt hook                 # What's hooked?
3. bd mol current          # Where am I?
4. Execute current step
5. bd close <step> --continue
6. If more steps: GOTO 3
7. gt done                 # Signal completion

Wisp与分子决策

问题	分子	Wisp
是否需要审计追踪？	是	否
是否需要持续重复？	否	是
它是离散可交付成果吗？	是	否
它是操作例行程序吗？	否	是

最佳实践

关键：实时关闭步骤- 标记进行中在开始之前，已关闭完成后立即执行。切勿在最后批量关闭步骤。
使用--continue以推进- 通过自动推进保持动力
使用以下命令检查进度：bd mol current- 在恢复之前了解当前位置
压缩已完成的分子- 为审计跟踪创建摘要
烧毁常规琐事- 不要积累临时性的巡查数据

公式解析（三层）

TIER 1: PROJECT (rig-level)
  Location: <project>/.beads/formulas/

TIER 2: TOWN (user-level)
  Location: ~/gt/.beads/formulas/

TIER 3: SYSTEM (embedded)
  Location: Compiled into gt binary

护航队 - 工作追踪

概念

一个护航队是一个持续性的追踪单元，用于监控多个钻机上的相关问题。当你启动工作时——哪怕只是一个单独的问题——护航队就会追踪它。

                 🚚 Convoy (hq-cv-abc)
                         │
            ┌────────────┼────────────┐
            │            │            │
            ▼            ▼            ▼
       ┌─────────┐  ┌─────────┐  ┌─────────┐
       │ gt-xyz  │  │ gt-def  │  │ bd-abc  │
       │ gastown │  │ gastown │  │  beads  │
       └────┬────┘  └────┬────┘  └────┬────┘
            │            │            │
            ▼            ▼            ▼
       ┌─────────┐  ┌─────────┐  ┌─────────┐
       │  nux    │  │ furiosa │  │  amber  │
       │(polecat)│  │(polecat)│  │(polecat)│
       └─────────┘  └─────────┘  └─────────┘
                         │
                    "the swarm"
                    (ephemeral)

护航队 vs 蜂群

概念	持续性？	标识	描述
护航队	是	hq-cv-*	追踪单元。你所创建、追踪、接收通知的对象。
蜂群	否	无	临时性的。“当前处理此护航队问题的工人。”
搁浅的护航队	是	hq-cv-*	一个车队有就绪的工作，但未指派任何臭鼬。

车队生命周期

OPEN ──(all issues close)──► LANDED/CLOSED
  ↑                              │
  └──(add more issues)───────────┘
       (auto-reopens)

状态	描述
`开放`	活动跟踪，工作进行中
`关闭`	所有跟踪的问题已关闭，通知已发送

向已关闭的车队添加问题会自动重新打开它。

命令

# Create convoy
gt convoy create "Deploy v2.0" gt-abc bd-xyz --notify gastown/joe

# Check status
gt convoy status hq-abc

# List all convoys
gt convoy list
gt convoy list --all

# Add issues
bd dep add hq-cv-abc gt-new-issue --type=tracks

示例车队状态输出：

🚚 hq-cv-abc: Deploy v2.0

  Status:    ●
  Progress:  2/4 completed
  Created:   2025-12-30T10:15:00-08:00

  Tracked Issues:
    ✓ gt-xyz: Update API endpoint [task]
    ✓ bd-abc: Fix validation [bug]
    ○ bd-ghi: Update docs [task]
    ○ gt-jkl: Deploy to prod [task]

通知

当车队抵达时，订阅者会收到通知：

gt convoy create "Feature X" gt-abc --notify gastown/joe
gt convoy create "Feature X" gt-abc --notify mayor/ --notify --human

通知内容：

🚚 Convoy Landed: Deploy v2.0 (hq-cv-abc)

Issues (3):
  ✓ gt-xyz: Update API endpoint
  ✓ gt-def: Add validation
  ✓ bd-abc: Update docs

Duration: 2h 15m

跨钻机跟踪

车队存在于镇级珠子中（hq-cv-*前缀），并且可以跟踪来自任何钻机的问题：

# Track issues from multiple rigs
gt convoy create "Full-stack feature" \
  gt-frontend-abc \
  gt-backend-def \
  bd-docs-xyz

其跟踪关系是：

非阻塞：不影响问题工作流程
增补型：可随时添加事项
跨钻机：总部车队的任务，gt-*的事项，bd-*等

车队状态与钻机状态对比

查看方式	范围	显示内容
`gt convoy status [id]`	跨钻机	车队与工人追踪的所有事项
`gt rig status <钻机>`	单一钻机	钻机内所有工人及其所属车队

使用车队查询："这批工作进度如何？" 使用钻机状态查询："这个钻机里的所有人都在做什么？"

投送自动生成车队

当投送单个事项且无现有车队时，气镇将自动创建车队以实现看板可视化。

通信系统

邮件协议

气镇代理通过珠链系统路由的邮件消息进行协调。

消息类型：

类型	路由	用途
`POLECAT_DONE`	Polecat → Witness	信号工作完成
`MERGE_READY`	Witness → Refinery	信号分支已准备好合并
`MERGED`	Refinery → Witness	确认合并成功
`MERGE_FAILED`	Refinery → Witness	通知合并失败
`REWORK_REQUEST`	Refinery → Witness	请求因冲突进行变基
`WITNESS_PING`	Witness → Deacon	二级监控
`HELP`	任意 → 升级目标	请求干预
`转交`	代理 → 自身	会话连续性

命令：

gt mail inbox
gt mail read <msg-id>
gt mail send <addr> -s "Subject" -m "Body"
gt mail ack <msg-id>

消息格式详情：

POLECAT_DONE（Polecat → Witness）：

Subject: POLECAT_DONE <polecat-name>
Body:
Exit: MERGED|ESCALATED|DEFERRED
Issue: <issue-id>
MR: <mr-id>          # if exit=MERGED
Branch: <branch>

转交（代理 → 自身）：

Subject: 🤝 HANDOFF: <brief-context>
Body:
attached_molecule: <molecule-id>   # if work in progress
attached_at: <timestamp>

## Context
<freeform notes for successor>

## Status
<where things stand>

## Next
<what successor should do>

Beads-原生消息传递

用于管理通信的三种Bead类型：

群组（gt:group）- 用于邮件分发的命名集合
队列（gt:queue）- 可认领消息的工作队列
频道（gt:channel）- 发布/订阅广播流

# Group management
gt mail group create ops-team gastown/witness gastown/crew/max
gt mail send ops-team -s "Team meeting" -m "Tomorrow at 10am"

# Channel management
gt mail channel create alerts --retain-count=50
gt mail send channel:alerts -s "Build failed" -m "Details..."

升级协议

严重性级别：

级别	优先级	描述
严重	P0	系统威胁，需立即关注
高	P1	重要阻碍，需要人工尽快介入
中	P2	标准升级流程

升级类别：

类别	描述	默认路径
`决策`	存在多个有效路径，需要选择	执事 -> 市长
`求助`	需要指导或专业知识	执事 -> 市长
`受阻`	等待无法解决的依赖项	市长
`失败`	意外错误，无法继续	执事
`紧急情况`	安全或数据完整性问题	监督者（直接）
`gate_timeout`	网关未及时解析	执事
`生命周期`	工作进程卡住或需要回收	见证者

命令：

gt escalate "Database migration failed"
gt escalate -s CRITICAL "Data corruption detected"
gt escalate --type decision "Which auth approach?"

交接技能

将当前会话移交至新的Claude实例，同时保留工作上下文。

使用时机：

上下文即将满载（接近令牌上限）
完成一个逻辑工作单元
需要全新视角解决问题
人类用户请求会话轮换

使用方法：

/handoff [optional message]

保留内容：

挂载分子：您的任务分配将保持在挂钩上
Beads状态：所有问题、依赖项、进度
Git状态：提交记录、分支、暂存区更改

重置内容：

对话上下文：全新Claude实例
TodoWrite事项：临时性、会话范围内有效
内存状态：任何未提交的分析结果

看门狗链

概述

Gas Town采用三层看门狗链进行自主健康监控：

Daemon (Go process)          ← Dumb transport, 3-min heartbeat
    │
    └─► Boot (AI agent)       ← Intelligent triage, fresh each tick
            │
            └─► Deacon (AI agent)  ← Continuous patrol, long-running
                    │
                    └─► Witnesses & Refineries  ← Per-rig agents

关键洞察：守护进程是机械性的（无法推理），但健康决策需要智能判断。Boot模块弥合了这一鸿沟。

会话所有权

代理	会话名称	位置	生命周期
守护进程	（Go进程）	`~/gt/daemon/`	持久化、自动重启
启动模块	`gt-boot`	`~/gt/deacon/dogs/boot/`	短暂，每次滴答都焕然一新
迪肯	`hq-deacon`	`~/gt/deacon/`	长期运行，交接循环

启动决策矩阵

条件	操作
会话已终止	启动
心跳 > 15 分钟	唤醒
心跳 5-15 分钟 + 邮件	轻推
心跳新鲜	无操作

巡逻代理

代理	巡逻分子	职责
迪肯	`mol-deacon-patrol`	代理生命周期、插件执行、健康检查
见证者	`mol-witness-patrol`	监控巡逻员，提醒卡住的工作人员
精炼厂	`mol-refinery-patrol`	处理合并队列，审查合并请求

健康检查命令

gt deacon health-check <agent>   # Send health check ping
gt deacon health-state           # Show health check state
cat ~/gt/deacon/heartbeat.json | jq .  # Check Deacon heartbeat
gt boot triage                   # Manual Boot run

设计原理：为何需要两个代理？

问题所在：守护进程需要确保Deacon处于健康状态，但：

守护进程无法进行推理- 它是遵循ZFC原则（不对其他代理进行推理）的Go代码
唤醒消耗上下文- 每次生成AI代理时，都会消耗上下文令牌
观察需要智能判断- 区分“代理正在构建大型工件”与“代理在工具提示上挂起”需要进行推理

解决方案：Boot是一个窄范围、临时性的AI代理，它：

每次守护进程轮询时重新运行（不累积上下文债务）
做出单一决策：Deacon是否应该唤醒？
决策后立即退出

心跳机制

守护进程每3分钟运行一次心跳检测：

func (d *Daemon) heartbeatTick() {
    d.ensureBootRunning()           // 1. Spawn Boot for triage
    d.checkDeaconHeartbeat()        // 2. Belt-and-suspenders fallback
    d.ensureWitnessesRunning()      // 3. Witness health
    d.ensureRefineriesRunning()     // 4. Refinery health
    d.triggerPendingSpawns()        // 5. Bootstrap polecats
    d.processLifecycleRequests()    // 6. Cycle/restart requests
}

心跳新鲜度：

时长	状态	启动操作
< 5 分钟	新鲜	无操作 (Deacon活跃)
5-15 分钟	陈旧	若有待处理邮件则轻推
> 15 分钟	非常陈旧	唤醒 (Deacon可能卡住)

状态文件

文件	用途	更新者
`deacon/heartbeat.json`	Deacon新鲜度	Deacon (每个周期)
`deacon/dogs/boot/.boot-running`	启动进行中标记	启动进程
`deacon/dogs/boot/.boot-status.json`	启动最后操作	启动分类
`deacon/health-check-state.json`	代理健康跟踪	`gt deacon health-check`
`daemon/daemon.log`	守护进程活动	守护进程
`daemon/daemon.pid`	守护进程ID	守护进程启动

降级模式

当tmux不可用时，Gas Town进入降级模式：

能力	正常	降级
启动运行	作为tmux中的AI	作为Go代码（机械）
观察面板	是	否
推送代理	是	不
启动代理	tmux会话	直接生成

高级主题

运行时配置

Gas Town 支持多种AI编码运行时。各工作台的独立设置位于settings/config.json：

{
  "runtime": {
    "provider": "codex",
    "command": "codex",
    "args": [],
    "prompt_mode": "none"
  }
}

模型评估与A/B测试

Gas Town的归因功能支持客观的模型比较：

# Deploy different models on similar tasks
gt sling gt-abc gastown --model=claude-sonnet
gt sling gt-def gastown --model=gpt-4

# Compare outcomes
bd stats --actor=gastown/polecats/* --group-by=model

跨工作台协作模式

方案一：工作树（推荐）

gt worktree beads
# Creates ~/gt/beads/crew/gastown-joe/

方案二：分发至本地工作节点

bd create --prefix beads "Fix authentication bug"
gt convoy create "Auth fix" bd-xyz
gt sling bd-xyz beads

稀疏检出（源码仓库隔离）

Gas Town使用稀疏检出功能来排除Claude Code上下文文件：

git sparse-checkout set --no-cone '/*' '!/.claude/' '!/CLAUDE.md' '!/CLAUDE.local.md'

分子商城（未来规划）

Gas Town分子配方市场 - 类似npm之于分子生态。

URI协议方案：

hop://molmall.gastown.io/formulas/mol-polecat-work@4.0.0

命令集（未来规划）：

gt formula install mol-code-review-strict
gt formula upgrade mol-polecat-work
gt formula publish mol-polecat-work

联邦化（HOP）

联邦机制通过高速公路运营协议，实现了跨组织间的公式共享。

仪表盘

gt dashboard --port 8080
open http://localhost:8080

功能特性：

实时代理状态
车队进度跟踪
挂钩状态可视化
配置管理

Shell自动补全

gt completion bash > /etc/bash_completion.d/gt
gt completion zsh > "${fpath[1]}/_gt"
gt completion fish > ~/.config/fish/completions/gt.fish

故障排除

常见问题

问题	解决方案
代理位于错误目录	检查当前工作目录，`执行gt doctor命令`
Beads前缀不匹配	检查`bd show命令`与rig配置对比
工作树冲突	确保`设置BEADS_NO_DAEMON=1`适用于polecats场景
工作进程卡死	`gt 提醒`，然后`gt 查看`
Git 状态不干净	提交或丢弃更改，然后`gt 交接`
`gt: 未找到命令`	添加`$HOME/go/bin`到 PATH 环境变量
`bd: 未找到命令`	`go install github.com/steveyegge/beads/cmd/bd@latest`
守护进程未启动	检查 tmux：`tmux -V`
代理失去连接	`gt hooks list`然后`gt hooks repair`
车队卡住	`gt convoy refresh <车队ID>`
市长无响应	`gt mayor detach`然后`gt mayor attach`

健康检查

gt doctor              # Run health checks
gt doctor --fix        # Auto-repair common issues
gt doctor --verbose    # Detailed output
gt status              # Show workspace status

调试

BD_DEBUG_ROUTING=1 bd show <id>  # Debug beads routing
gt peek <agent>                   # Check agent health
tail -f ~/gt/daemon/daemon.log    # View daemon log

常见错误

将狗用于用户工作：狗是Deacon基础设施。请使用船员或臭鼬。
混淆船员与臭鼬：船员是持久且由人工管理的。臭鼬是临时的。
在错误目录中工作：Gas Town使用当前工作目录进行身份检测。
工作挂接时等待确认：挂接本身就是你的任务。请立即执行。
在更适合调度的场景下创建工作树：如果工作应由目标钻机拥有，请改用调度。
直接读取配方：请使用bd cook→bd mol pour流水线替代。
批量关闭分子步骤：实时关闭步骤以维持准确的时间线。

术语表

环境

镇: 管理总部（例如，~/gt/）。协调多个钻探平台的所有工作人员。
钻探平台: 由Gas Town管理的特定项目Git仓库。

镇级角色

镇长: 负责发起车队并协调工作的首席幕僚代理。
执事: 运行持续巡逻周期以监控系统健康的守护进程信标。
犬队: 执事麾下负责后台任务的维护代理团队。
引导员: 每5分钟检查一次执事状态的特殊犬队成员。

平台级角色

鼬鼠工: 生成合并请求的临时工作代理。
精炼厂: 管理钻探平台的合并队列。
见证者：负责监督Polecats和Refinery的巡逻代理。
团队：长期存在、拥有名称的代理，用于持续协作。

工作单元

珠粒：基于Git的原子工作单元，以JSONL格式存储。
配方：基于TOML的工作流源模板。
原分子：用于实例化分子的模板类。
分子：持久化的链式珠粒工作流。
微光：运行后即销毁的临时珠粒。
钩子：每个代理工作队列中的特殊固定珠粒。

工作流命令

护航队：包装相关珠粒的主要工作指令。
投掷：通过gt sling命令向代理分配工作。.
轻推：代理之间的实时消息传递，通过gt nudge命令。
交接：通过/handoff命令刷新代理会话。
灵应：通过gt seance命令与之前的会话进行通信。
巡逻：维持系统心跳的临时循环。

原则

MEOW：工作的分子式表达——将大目标分解为可跟踪的单元。
GUPP：Gas Town 通用推进原则——“如果你的钩子上有工作，你就必须运行它。”
NDI：非确定性幂等性——通过编排确保有用的结果。

Gas Town 为何存在

随着AI智能体成为工程工作流程的核心，团队面临新的挑战：

责任归属：谁做了什么？哪个智能体引入了这个bug？
质量：哪些智能体是可靠的？哪些需要调整？
效率：如何将工作分配给合适的智能体？
规模化：如何跨代码库和团队协调智能体？

Gas Town是一个编排层，将AI智能体的工作视为结构化数据。每个操作都可追溯。每个智能体都有历史记录。每项工作都有来源证明。

特性：工作历史（智能体履历）

问题：你需要分配一个复杂的Go语言重构任务。你有20个智能体。有些擅长Go语言，有些从未接触过，有些表现不稳定。该如何选择？

解决方案：每个智能体都会积累工作历史：

# What has this agent done?
bd audit --actor=gastown/polecats/toast

# Success rate on Go projects
bd stats --actor=gastown/polecats/toast --tag=go

重要性：

绩效管理：关于智能体可靠性的客观数据
能力匹配:将工作分配给经验证有效的智能体
持续改进:识别表现不佳的智能体以进行调整

功能: 基于能力的路由分配

问题:您有Go、Python、TypeScript、Rust语言的工作任务。您拥有具备不同能力的智能体。手动分配无法规模化。

解决方案:工作附带技能要求。智能体具备已验证的能力（源自其工作历史）。匹配过程自动完成:

# Agent capabilities (derived from work history)
bd skills gastown/polecats/toast
# → go: 47 tasks, python: 12 tasks, typescript: 3 tasks

# Route based on fit
gt dispatch gt-xyz --prefer-skill=go

重要性:

效率:为正确任务匹配合适的智能体
质量:智能体在其优势领域工作
规模:分配环节不存在人为瓶颈

功能: 递归式工作分解

问题:企业项目复杂。"一个功能"可能演变为横跨8个代码库、涉及4个团队的50项任务。扁平化的问题列表无法体现这种结构。

解决方案：工作自然分解：

Epic: User Authentication System
├── Feature: Login Flow
│   ├── Task: API endpoint
│   ├── Task: Frontend component
│   └── Task: Integration tests
├── Feature: Session Management
│   └── ...
└── Feature: Password Reset
    └── ...

每个层级都有其独立的链条。汇总自动完成。您始终清楚当前进度。

功能：跨项目引用

问题：前端无法发布，直到后端API完成。它们位于不同的代码仓库中。传统工具无法追踪这种依赖关系。

解决方案：明确的跨项目依赖关系：

depends_on:
  beads://github/acme/backend/be-456  # Backend API
  beads://github/acme/shared/sh-789   # Shared types

功能：验证与质量门控

问题：一个代理说"完成了"。它真的完成了吗？代码质量可以接受吗？通过评审了吗？

解决方案：结构化验证与归属记录：

{
  "validated_by": "gastown/refinery",
  "validation_type": "merge",
  "timestamp": "2025-01-15T10:30:00Z",
  "quality_signals": {
    "tests_passed": true,
    "review_approved": true,
    "lint_clean": true
  }
}

功能：实时活动动态

问题：复杂的多代理工作不透明。直到工作完成（或失败）您才知道发生了什么。

解决方案：工作状态作为实时流：

bd activity --follow

[14:32:08] + patrol-x7k.arm-ace bonded (5 steps)
[14:32:09] → patrol-x7k.arm-ace.capture in_progress
[14:32:10] ✓ patrol-x7k.arm-ace.capture completed
[14:32:14] ✓ patrol-x7k.arm-ace.decide completed
[14:32:17] ✓ patrol-x7k.arm-ace COMPLETE

为何重要：

实时调试：实时发现问题
状态感知：随时掌握运行状态
模式识别：识别瓶颈与低效环节

企业价值主张

能力	开发者受益	企业受益
溯源分析	调试代理问题	合规审计
工作历史记录	优化代理分配	绩效管理
技能路由	加速任务完成	资源优化
联邦化部署	多仓库项目	跨组织可视化
验证机制	质量保障	流程执行
活动动态	实时调试	运行态势感知

设计理念

操作归属不可缺失。每个行为皆有执行者。
工作即数据。不仅是工单——更是结构化、可查询的数据。
历史至关重要。过往记录决定信任度。
规模扩展是默认前提。从第一天起即支持多仓库、多代理、多组织。
验证优于信任。质量门控是一等公民。

使用建议

始终从“市长”界面开始- 它被设计为您的主要操作界面
使用“护航编队”进行协同- 它们提供跨代理的全局可见性
利用钩子实现持久化- 您的工作成果将永久保留
为重复性任务创建公式- 使用Beads配方节省时间
监控仪表板- 获取实时可见性
让Mayor来协调- 它知道如何管理代理
始终使用gt --help或gt <命令> --help来验证语法

许可证

MIT许可证 - 详见LICENSE文件

本词汇表由Clay Shirky在第80期贡献。

安装命令：tessl install github:numman-ali/n-skills --skill gastown

免责申明

部分文章来自各大搜索引擎，如有侵权，请与我联系删除。

打赏

文章底部电脑广告

手机广告位-内容正文底部

标签

上一篇：Patent Validator 下一篇：Journal to Post