Gas Town: Дайте каждому агенту кодирования собственное рабочее пространство

Проверено по исходникам и обновлено: 17 августа 2026 года, по официальному репозиторию Gas Town, документации к выпуску и справочнику команд. Запишите ваши установленные gt version потому что каналы распространения могут отставать.

Gas Town решает чрезвычайно распространённую проблему многопользовательского кодирования: два агента по кодированию не должны одновременно редактировать одну и ту же ветку.

Наша команда использует его как слой рабочего пространства под многопользовательской системой. Более сильная модель или оркестратор могут решать, какая работа должна выполняться; Gas Town превращает каждую единицу работы в отслеживаемое задание и назначает его каждому работнику, называемому polecat, свой собственный рабочий каталог Git и ветку. Работники могут работать параллельно, не наступая друг другу на один и тот же рабочий каталог, а их результаты позже встречаются на этапе просмотра и слияния.

Это полезное утверждение. Это также граница утверждения. Отдельное рабочее дерево Git является не песочницей безопасности. Коренные хорьки обычно работают как процессы под одним и тем же пользователем операционной системы, так что они всё ещё могут иметь возможность читать те же учетные данные, обращаться к сети или достигать других путей, доступных вашему пользователю.

Официальный README Gas Town, объясняющий, что хуки на основе Git сохраняют работу и координируют нескольких агентов через рабочие области

Рисунок 1: официальный README Gas Town, зафиксированный 17 августа 2026 года. В нём описываются постоянные хуки на базе Git и их жизненный цикл; это публичная документация, а не доказательство работы приватной команды.

Что на самом деле добавляет Gas Town

Официальный проект Gas Town, с gt командой. Это многопользовательский менеджер рабочих пространств и система оркестрации для сред исполнения кода, включая Claude Code, Codex, Gemini и другие.

Словарь необычен, но элементы соответствуют знакомым задачам:

Термин Gas Town	Значение на простом языке	Почему это важно
Town / HQ	Каталог верхнего уровня Gas Town, обычно `~/gt`	Содержит конфигурацию и состояние координации между проектами
Rig	Один Git-проект, управляемый Gas Town	Поддерживает совместную работу и отслеживание проекта
Мэр	Координаторский агент	Разбивает и направляет более крупные цели
Бусина	Надежная единица работы	Присваивает заданию идентификатор и состояние вне памяти чата модели
Конвой	Группа связанных бусин	Показывает прогресс по более крупному результату
Полёвка	Агент-работник	Выполняет одно назначенное задание
Крючок	Закрепленная очередь работы рабочего	Сообщает рабочему, чем он владеет
Нефтеперерабатывающий завод	Роль очереди слияния	Тестирует и интегрирует завершенные ветки
Свидетель	Монитор на каждую установку	Следит за работниками и помогает восстанавливать зависшие сессии

Вам не нужно запоминать всё это перед началом. Минимально полезная ментальная модель такова:

цель → отслеживаемые задачи → отдельные рабочие деревья → тесты/ревью → слияние

Почему модель с отдельными рабочими деревьями работает

Рабочее дерево Git — это ещё одна проверенная директория, связанная с тем же репозиторием. У каждого polecat может быть своя директория и своя ветка фичи. Агент A может изменять API, в то время как Агент B обновляет документацию, без того чтобы кто-либо переключал ветку другого или перезаписывал незакоммиченные файлы другого.

Рабочее дерево сохраняется при обычном цикле сессий модели во время задания. Gas Town хранит состояние задач в Beads и механизмах передачи, так что свежий контекст модели может восстановить работу, а не воспринимать текст чата как единственную память.

Когда хорек заканчивает, gt done он отправляет свою ветку и предоставляет доказательства слияния. Живая сессия завершается; Нефтеперерабатывающий завод и Свидетель владеют оставшимся путем слияния и очистки.

Этот дизайн снижает три распространенные ошибки:

Конфликты при совместной проверке: один агент изменяет ветки, сбрасывает файлы или перезаписывает изменения другого агента.
Невидимое владение: никто не знает, какой агент отвечает за сбойную задачу.
Состояние только в чате: сбой или сброс контекста стирает план, потому что он никогда не покидал диалог модели.

Это не устраняет логические конфликты слияния. Если два работника изменяют одно и то же поведение несовместимым образом, Git и процесс ревью все равно должны разрешить это расхождение.

Перед установкой

Используйте одноразовый репозиторий для первого запуска. Не начинайте с вашего производственного монорепозитория, домашнего каталога SSH или рабочей копии с несохранёнными изменениями.

Вам понадобятся Git и среда выполнения агента. Режим полного стека также использует tmux, Dolt и Beads. Требования к живой среде меняются, поэтому проверяйте официальное руководство по установке перед копированием номеров версий в автоматизацию.

На macOS рекомендуемый путь — Homebrew:

brew install Гастаун

На Linux или Windows следуйте текущему официальному руководству для Dolt, Go, Beads и gt. Для полного опыта с поддержкой tmux на Windows используйте WSL. Не используйте go install для gt на macOS; документы Gas Town предупреждают, что неподписанный бинарный файл может быть заблокирован Gatekeeper.

Проверьте инструменты перед созданием города:

команда -v ГТ
ГТ версия
БД версия
Болван версия
git --version
Тмюкс -V

Запишите gt версия. Gas Town развивается быстро, и его Homebrew, npm, релизы и документация main могут слегка не совпадать.

Установите город и добавьте тестовый проект

Установите реальную личность Git перед тем, как попросить Gas Town инициализировать репозиторий HQ:

git конфигурация --глобально user.name "Ваше имя"
git конфигурация --глобально user.email "you@example.com"

Создайте город, запустите его службы и выполните диагностику:

ГТ install ~/gt --оболочка --гит
cd ~/gt
ГТ вверх
ГТ врач --исправить
ГТ статус

Если ваша установленная версия не распознаёт комбинированную --git форму, используйте документированный раздельный путь релиза:

ГТ install ~/gt --оболочка
cd ~/gt
ГТ гит-инициализация
ГТ вверх
ГТ врач --исправить

Не продолжайте пытаться с случайными флагами. Выполните gt install --help и следуйте синтаксису, поставляемому версией, которую вы зафиксировали.

Теперь добавьте одноразовый Git-репозиторий как приспособление:

ГТ установка добавить practice_repo https://github.com/you/practice-repo.git --prefix пр
ГТ установка список
ГТ установка статус practice_repo

Имена приспособлений могут содержать буквы, цифры и подчеркивания. Используйте practice_repo, не practice-repo.

Для вашей собственной практической работы создайте постоянное рабочее пространство команды:

ГТ команда добавить вашеимя --установка practice_repo

Рабочие пространства команды существуют долго. Рабочие пространства Polecat создаются для заданий и позже выводятся из эксплуатации через путь очистки.

Настройте среду выполнения рабочего процесса

Перечислите пресеты среды выполнения, которые известны вашей установленной сборке:

ГТ конфигурация агент список

Чтобы использовать Codex для одного задания, передайте встроенный псевдоним во время выполнения sling:

ГТ праща <bead-iд> practice_repo --агент codex

Gas Town также поддерживает настраиваемые псевдонимы агентов. Добавляйте его только после того, как его базовый CLI работает самостоятельно:

ГТ конфигурация агент установить codex_low "codex --thinking low"
ГТ конфигурация агентпоумолчанию codex_low

Используйте точные флаги, поддерживаемые вашей средой выполнения. Псевдоним не делает действительной неподдерживаемую модель или интеграцию CLI.

В нашем стеке планировочная модель и слой рабочего пространства выполняют разные задачи: оркестратор решает, как разложить и направить работу; Gas Town хранит назначения рабочих, ветви и жизненные циклы отдельно. Этот учебник не претендует на то, что Gas Town поставляется с встроенным Grok runtime — Руководство Herdr по многоагентной системе рассматривает наш слой оркестрации отдельно.

Выполните одну задачу от начала до конца

Начните с задачи, выполнение которой легко доказать, например, добавления конечной точки состояния здоровья и её теста. Создайте bead из канонического клона rig:

cd ~/gt/practice_repo/mayor/rig
БД создать "Добавить конечную точку состояния здоровья с одним проходящим тестом"

Скопируйте ID bead, который выводится bd. Он будет выглядеть примерно так pr-abc12. В корне town создайте конвой и запустите bead:

cd ~/gt
ГТ конвой создать «Практический конечный пункт здоровья» pr-abc12 --человек
ГТ праща pr-abc12 practice_repo --агент codex

Затем проверьте выполнение задания извне рабочего процесса:

ГТ конвой список
ГТ конвой статус <convoy-iд>
ГТ агенты
ГТ установка статус practice_repo

Точное случайное имя хорька не имеет значения. Важно, чтобы задание имело владельца, у владельца была отдельная рабочая директория и ветка, а конвой показывал своё состояние.

Подтвердите разделение файловой системы с помощью самого Git:

git --git-dir="$HOME/gt/practice_repo/.repo.git рабочее_дерево список

Запустите второе безвредное задание и повторите команду. Вы должны увидеть разные рабочие директории и ветки для двух хорьков.

Завершите задание корректно

Внутри сеанса хорька завершение работы не означает «Я написал несколько файлов». Рабочий процесс должен:

Прочитать бижутерию и критерии приёмки.
Изучить инструкции самого репозитория.
Сделать ограниченное изменение в назначенной ветке.
Запустите соответствующие тесты или команду проверки.
Зафиксируйте результат без включения несвязанных файлов.
Запуск gt done чтобы отправить ветку и представить её для интеграции.

gt done завершает живую сессию после выхода из долговечной ветки и метаданных слияния. Затем Refinery может протестировать и слить работу. Если возникает конфликт слияния, официальная схема направляет его на работу по разрешению конфликта; она не подтверждает молча, что обе реализации совместимы.

Следите за конвоем, а не спрашивайте у каждого работника о статусе разговора:

ГТ конвой статус <convoy-iд>
ГТ корм

Использовать gt feed --problems когда вас интересует только застрявшая или неисправная активность.

Механизмы масштабируются лучше, когда задачи действительно независимы. “Построить всё приложение” не является планом параллельной работы. Более безопасный производственный конвой может разделяться на:

Бусина	Owns	Требуется доказательство
поведение API	Endpoint и модульные тесты	Целевая команда тестирования проходит
Документация	Пользовательская настройка и примеры	Ссылки и команды, проверенные по итоговому API Обзор
Regression	Diff и существующее поведение	Проходит соответствующий набор регрессии; блокирующие результаты

Размещайте зависимости между задачами, которые не могут безопасно выполняться одновременно. Дайте каждому bead результат и команду проверки. Сохраняйте границу одобрения человека для развертываний, изменений учётных данных, разрушительных миграций, покупок, внешних сообщений и публикации.

Лимит параллелизма до того, как крупный конвой исчерпает бюджеты модели или лимиты поставщиков:

ГТ конфигурация установить scheduler.max_Polecats 3
ГТ планировщик статус

Три надежных работника с четкой ответственностью обычно превосходят десять работников, соревнующихся за одни и те же файлы, разрешения API и внимание проверяющего.

Для производства также используйте:

выделенный тестовый репозиторий перед подключением ценного оборудования;
узкие, отзывные учетные данные Git;
бюджеты и ограничения скорости провайдеров моделей;
обязательные тесты и проверку перед слиянием;
удаленные ветки или пулл-реквесты как надежные доказательства;
резервные копии хоста для состояния town/Beads, которое Git сам по себе не защищает;
задокументированный владелец для зависших задач и разрушительной очистки.

Обработка сбоев без уничтожения работы

Когда рабочий кажется зависшим, проверьте перед перезапуском:

ГТ агенты
ГТ установка статус practice_repo
ГТ конвой статус <convoy-iд>
ГТ корм — проблемы
ГТ polecat статус practice_repo/<Полекэт-намe>
ГТ врач --подробно

Система Witness предназначена для мониторинга хорьков и восстановления зависших сессий. Перезапуск модельной сессии автоматически не означает потерю задачи: рабочее дерево, ветка, бисер и состояние передачи отделены от одного окна контекста.

Перед разрушительной очисткой спросите у Gas Town, есть ли восстанавливаемое состояние:

ГТ polecat чек-восстановление practice_repo/<Полекэт-намe>

Только после того как вы проверили ветку, коммиты, несохранённые изменения и результат восстановления, следует рассматривать:

ГТ polecat ядерной бомбы practice_repo/<Полекэт-намe>

nuke завершает сессию и удаляет рабочее дерево и ветку. Это не обычная команда типа «попробуйте выключить и включить снова».

Для устаревших рабочих начните с обнаружения:

ГТ polecat затхлым practice_repo

Не добавляйте --cleanup пока каждый кандидат не будет понятен. Если работа нуждается в перераспределении без уничтожения, используйте поддерживаемый путь unsling/unhook для вашей установленной версии и убедитесь, что бисер возвращается в открытое состояние.

Безопасно завершайте работу в конце дня

Наименее удивительная остановка для всего города:

ГТ вниз

Официальная справка по очистке гласит gt down останавливает инфраструктуру, но не обязательно останавливает всех ласок. Чтобы остановить сессии ласок также:

ГТ вниз --хоры

Использовать gt down --all только когда вы намерены использовать более широкий путь очистки и проверки. Избегайте gt down --nuke: это убивает весь сервер tmux, включая сессии tmux, не относящиеся к Gas-Town.

Не удаляйте ~/gt как обычную очистку. Он содержит состояние города и рабочие директории. Используйте задокументированный gt uninstall путь только после сохранения работы и подтверждения точной цели.

Выберите правильный уровень изоляции

Существует три разных границы, и они решают разные задачи:

Настройка	Что они отделяют	Что они не отделяют автоматически
Родные рабочие деревья polecat	Рабочие каталоги и ветки Git	Файлы хоста, пользователь ОС, учетные данные, сеть, процессы
Официальный город Docker Compose	Среда Gas Town из большей части хоста	Polecat друг от друга внутри одного контейнера; связанный `/gt` рабочий каталог; исходящая сеть
Контейнеры/VM на каждую polecat с прокси контрольной плоскости	Среда рабочего процесса/файловой системы, в зависимости от монтирования контейнера и политики	Все, что вы сознательно монтируете или разрешаете; исходящий сетевой трафик, если не ограничен отдельно

Официальная конфигурация Docker работает от имени пользователя без прав root, отключает возможности Linux и включает no-new-privileges. Это более сильная граница, чем у родного процесса. Также выполняется bind-монтирование HQ на /gt и сохраняет домашний каталог агента, поэтому рассматривайте эти монтирования как общие чувствительные поверхности.

Если вам действительно нужны ненадежные рабочие, используйте контейнеры или виртуальные машины для каждого рабочего, предоставляйте каждому минимальные учетные данные, ограничивайте монтирования и исходящий трафик, и изучите официальную gt-proxy-server архитектуру. Ее mTLS, разрешенные команды и ограничение веток защищают контрольную плоскость Gas Town; сам прокси не контролирует произвольные файлы, смонтированные в контейнер, и не блокирует исходящий сетевой доступ.

Никогда не запускайте нативный gt процесс и Docker Town с одной и той же директорией HQ. Официальное руководство Docker предупреждает, что конкурирующие серверы и демоны Dolt могут повредить рабочее пространство.

Почему мы держим Gas Town в стеке

Gas Town полезен для нас, потому что превращает «запуск большего числа агентов» в видимую инженерную систему:

каждая единица работы имеет идентификатор и владельца;
каждый работник получает отдельный чек-аут и ветку;
состояние может сохраняться после перезапуска сеанса модели;
конвой показывает прогресс по результату;
интеграция происходит через явный путь слияния;
зависшая работа имеет команды для инспекции и восстановления.

Ценность не в том, чтобы каждый работник становился надежным. Ценность в том, что параллельная работа становится проще для атрибуции, проверки, восстановления и интеграции.

Вопросы по Gas Town

Является ли Gas Town моделью?

Нет. Это слой оркестрации и рабочего пространства, который запускает поддерживаемые среды выполнения агента для кодирования. Модель по-прежнему обеспечивает рассуждение и генерацию кода.

Получает ли каждый polecat отдельный репозиторий?

Он получает отдельный рабочий каталог/рабочее дерево Git и ветку, подключенную к репозиторию установки. Это предотвращает конфликты при совместной проверке без дублирования каждого объекта Git.

Может ли один хорек читать файлы другого хорька?

В родной конфигурации по умолчанию, потенциально, да. Обычно они работают под одной и той же учетной записью ОС. Разделение рабочих деревьев — это организационная и Git-граница, а не граница контроля доступа.

Предотвращает ли Gas Town слияние плохого кода?

Он предоставляет очередь слияний и путь проверки, но результат зависит только от ваших тестов, правил рецензирования, определения задач и учетных данных. Оставляйте человеческое одобрение для операций с высоким риском.

Стоит ли начинающему начать с Мэра?

Используйте Мэра для более крупной цели после того, как вы освоите одну бусину, одну ласку, одну ветку и одно проверенное слияние. Сначала изучение ручного пути облегчает отладку оркестровки.