Gastown и Beads: мультиагентная оркестрация для разработки ПО

Введение

В январе 2026 года Стив Йегге (Steve Yegge), известный по работе в Google и Amazon, выпустил два инструмента, определяющих новый подход к разработке программного обеспечения с помощью AI-агентов: Gastown — систему оркестрации 20–30 параллельных AI-агентов, и Beads — Git-backed систему памяти и трекинга задач, специально спроектированную для агентов. Вместе они представляют собой одну из первых попыток перейти от парадигмы «один разработчик — один AI-ассистент» к парадигме «фабрики агентов», где человек выступает архитектором и менеджером, а десятки агентов параллельно выполняют реализацию.

“Do not use Gas Town if you do not juggle at least five Claude Codes at once, daily.” ¹

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

Beads: система памяти для AI-агентов

Проблема: амнезия агентов

Центральная проблема, которую решает Beads, — потеря контекста между сессиями. Агенты кодирования (Claude Code, Cursor, Copilot) работают в рамках ограниченного контекстного окна и теряют память при перезапуске сессии — примерно каждые 10 минут². Йегге описывает это как «проблему 50 первых свиданий»: агент просыпается без воспоминаний о вчерашней работе³.

При попытке обойти проблему через markdown-файлы с планами Йегге обнаружил 605 разлагающихся plan-файлов — агенты рекурсивно создавали новые планы, теряя контекст предыдущих¹. Beads решает эту проблему, предоставляя структурированное, запрашиваемое хранилище задач вместо неструктурированного текста.

Архитектура

Beads — это легковесный трекер задач, написанный на Go (~15 000 строк), с тремя ключевыми компонентами⁴:

1. SQLite-база (.beads/beads.db) — для быстрых локальных запросов и индексации
2. JSONL-файл (issues.jsonl) — Git-tracked формат для совместной работы и merge-friendly изменений
3. Двусторонний sync-демон — автоматическая синхронизация между базой и Git

Хранение в JSONL обеспечивает естественную совместимость с Git: параллельные записи добавляют новые строки, которые Git обрабатывает без конфликтов⁵.

Хранилище Dolt

В качестве бэкенда Beads использует Dolt — версионированную SQL-базу данных (лицензия Apache 2.0)⁶. Dolt предоставляет:

• Cell-level merge resolution (разрешение конфликтов на уровне ячеек, а не строк файла)
• Нативное ветвление, независимое от Git
• Полноценные SQL-запросы с историей версий
• Поддержку многопользовательской записи в серверном режиме

Сервер Dolt запускается локально на порту 3307, данные хранятся в ~/.dolt-data/. Каждая мутация генерирует коммит в Dolt, что требует агрессивной компактификации истории⁶.

Ключевые особенности

Коллизионно-устойчивые идентификаторы. Beads использует хеш-based ID (например, bd-a1b2, bd-f14c) вместо последовательных номеров. Это предотвращает конфликты при параллельном создании задач несколькими агентами на разных ветках⁴.

Иерархическая организация задач. Поддерживаются вложенные структуры: эпики → задачи → подзадачи. Вложенные ID вида bd-a3f8.1.1 позволяют моделировать произвольную сложность проекта³.

Четыре типа зависимостей: blocking (блокирует), related (связано), provenance (происхождение), а также duplicates, supersedes, replies_to⁴.

Оптимизация для агентов. Команда bd ready --json возвращает только разблокированные задачи в JSON-формате — инструмент берёт на себя логику графа зависимостей, экономя токены агента⁵.

Семантическое затухание памяти. Старые закрытые задачи автоматически суммаризируются с помощью LLM для экономии контекстного окна³.

Команды и workflow

Базовый цикл работы агента с Beads⁴⁵:

bd ready --json          # Получить разблокированные задачи
bd update <id> --claim   # Атомарно забрать задачу
# ... выполнение работы ...
bd create "Title" --deps discovered-from:<parent-id>  # Зафиксировать находки
bd close <id> --reason "Done"   # Закрыть задачу
bd dolt push             # Синхронизировать

Другие важные команды:

• bd list — просмотр всех задач
• bd blocked — задачи, ожидающие других
• bd dep tree — визуализация графа зависимостей
• bd doctor — диагностика и автоисправление
• bd cleanup — очистка устаревших данных

“The plane has NOT landed until git push succeeds — never end a session with unpushed work.” ⁷

Установка

# Варианты установки
brew install beads              # macOS
npm install -g @beads/bd        # npm
go install github.com/steveyegge/beads/cmd/bd@latest

# Инициализация в проекте
bd init
bd onboard
bd setup claude                 # Интеграция с Claude Code

Лучшие практики

На основе статьи «Beads Best Practices»⁸:

1. Запускать bd doctor ежедневно — автоматическая диагностика и исправление проблем
2. Держать рабочий набор до 200 задач — при превышении ~500 issues.jsonl файлы начинают превышать лимит в ~25k токенов
3. Часто перезапускать агентов — Beads служит памятью между короткими сессиями; частые перезапуски экономят деньги и улучшают качество модели
4. Планировать вне Beads — сначала план (до 5 итераций), потом импорт в эпики и задачи
5. Фиксировать задачи для работы > 2 минут — всё, что дольше, заслуживает bead
6. Использовать короткие префиксы (bd-, vc-) для читаемости

Ограничения Beads

• Нет кросс-проектных ссылок — каждая база изолирована⁴
• Нет автоматических конвертеров из GitHub Issues, Jira или Linear⁴
• Команда bd edit требует интерактивного ввода — агенты должны использовать bd update с флагами⁷
• Конфликты при merge всё ещё случаются, улучшения выходят еженедельно⁸
• Агенты остаются деструктивными и могут удалить целую базу данных, требуя осторожности¹

Gastown: фабрика AI-агентов

Концепция

Gastown — не очередной AI-ассистент для кодирования. Это система оркестрации, координирующая 20–30 параллельных AI-агентов (преимущественно Claude Code, но также Cursor, Gemini, Codex), работающих одновременно над разными задачами в рамках одной кодовой базы¹.

Стив Клабник описывает суть просто: «У вас есть рабочее пространство. Каждый проект имеет баг-трекер. Gas Town позволяет поручить AI-агентам автономно разбирать эти баги»⁹. Архитектура заимствует проверенные идеи из Erlang — деревья супервизоров, почтовые ящики, crash recovery⁹.

Архитектура: стек MEOW

MEOW (Molecular Expression of Work) — иерархия единиц работы¹:

Роли агентов

Gastown определяет семь специализированных ролей¹¹⁰:

Структура workspace

Town — центральная директория (например, ~/gt/), содержащая все проекты¹.

Rig — контейнер проекта, оборачивающий Git-репозиторий:

• Bare repo (.repo.git/)
• Каноническая база Beads (mayor/rig/.beads/)
• Директории агентов (witness/, refinery/, crew/, polecats/)

Hook — Git worktree для персистентного хранения, переживающего crash’и агентов¹.

Convoy — группировка связанных beads в логические пакеты доставки¹⁰.

Принцип GUPP

“Gastown Universal Propulsion Principle: If there is work on your hook, YOU MUST RUN IT.” ¹

Это центральный операционный принцип: агенты проверяют персистентные почтовые ящики (Beads) и автоматически продолжают работу между сессиями. Это обеспечивает недетерминированную идемпотентность (NDI) — путь агентов может варьироваться, но результаты сходятся, потому что workflow персистентны, а критерии приёмки явно определены¹.

Merge-очередь: Refinery

Refinery использует Bors-style bisecting queue¹¹⁰:

1. Группирует merge-запросы от завершённых polecats
2. Запускает верификацию и тесты на пакете
3. При неудаче: бинарный bisect пакета на две половины
4. Когда в пакете остаётся один PR: возвращает автору на исправление
5. Polecats никогда не пушат напрямую в main

Трёхуровневый watchdog

Мониторинг здоровья системы организован в три уровня¹:

1. Witness (per-rig) — мониторит polecats, детектит зависших агентов, запускает recovery
2. Deacon (town-level) — запускает patrol-циклы, диспатчит Dogs для обслуживания
3. Dogs — инфраструктурные рабочие; специальный Dog проверяет Deacon каждые 5 минут

Три плоскости данных

Seance: восстановление контекста

Механизм Seance обнаруживает предыдущие сессии агентов через .events.jsonl логи¹:

gt seance                           # Список обнаруживаемых сессий
gt seance --talk <id> -p "What did you find?"  # Вопрос к предыдущей сессии

Это использует функцию /resume Claude Code для возобновления убитых сессий.

Установка и требования

Предварительные требования¹⁰:

• Go 1.25+
• Git 2.25+ (поддержка worktree)
• Dolt 1.82.4+
• Beads CLI (bd) 0.55.4+
• tmux 3.0+ (рекомендуется)

# Установка
brew install gastown              # macOS
go install github.com/steveyegge/gastown/cmd/gt@latest

# Добавление существующего проекта
gt rig add [name] [repository-url]

# Проверка
gt doctor

Workflow

Через Mayor (рекомендуемый)¹⁰:

1. Подключиться к сессии Mayor (gt mayor attach)
2. Описать, что нужно построить
3. Mayor создаёт convoys и оркестрирует агентов автоматически

Минимальный режим:

1. Создать convoys вручную
2. Назначить beads через gt sling
3. Запускать агентов независимо

Ключевые команды:

• gt sling <bead-id> <rig> — назначить работу агенту
• gt prime — контекст восстановления при старте сессии
• gt done — push ветки, создание merge request
• gt convoy — создание пакета отслеживания
• gt doctor — диагностика workspace

Интеграция с существующими проектами

Gastown может быть подключён к проекту, который уже разрабатывается. Процесс выглядит следующим образом¹⁰¹¹:

1. Добавление rig: gt rig add [name] [repository-url] — клонирует репозиторий, создаёт shared bare repo, инициализирует базу Beads, настраивает worktrees
2. Импорт задач: Существующие задачи из GitHub Issues или другого трекера можно импортировать через JSONL-скрипты (автоматические конвертеры пока не реализованы)
3. Постепенный ввод: Можно начать с Beads отдельно от Gastown — использовать bd init в существующем репозитории для трекинга задач одним агентом, а затем масштабировать до полного Gastown

Однако следует учитывать ограничения¹²¹³:

• Система борется с монорепозиториями, смешанными конфигурациями и сложными build-системами
• Требуется настроенный CI/CD как «священная граница» — без надёжных тестов и CI агенты могут merge’ить неработающий код
• Стоимость ~$100/час при использовании Claude Opus требует cost governance⁶

Что это даёт разработчику

Beads как standalone-инструмент

Beads полезен даже без Gastown — как система памяти для одного AI-агента³⁵:

• Решает проблему амнезии: агент не теряет контекст между сессиями
• Структурирует работу: вместо markdown-файлов — запрашиваемая база с зависимостями
• Автоматизирует рутину: bd ready определяет, что делать дальше, без парсинга текста
• Git-нативность: задачи хранятся рядом с кодом, версионируются, merge’атся

Sourcegraph Amp проиндексировала 10-летний TODO в 128 issues (6 эпиков, 5 субэпиков) за менее чем 30 секунд¹.

Gastown: масштабирование

Gastown даёт возможность¹⁰¹⁴:

• Параллелизация: 20–30 агентов работают одновременно над разными задачами
• Автоматизация merge: Refinery обеспечивает стабильность main ветки
• Crash recovery: Работа переживает падения агентов благодаря Git-backed хранилищу
• Сдвиг роли: Разработчик переходит от написания кода к архитектуре и менеджменту

Экономика

Мэгги Эпплтон оценивает месячные затраты в $1 000–5 000, что конкурентоспособно при 2–3x росте производительности (сопоставимо с 10–30% зарплаты старшего разработчика)¹⁴. Однако текущие расходы завышены из-за неэффективностей и должны снижаться по мере зрелости инструментов.

DoltHub зафиксировал расход ~$100 за 60-минутную сессию с Claude Opus — примерно в 10 раз больше обычного Claude Code⁶.

Дискуссионные вопросы и противоречия

«Vibe coding» в промышленном масштабе

Йегге открыто описывает Gastown как полностью «vibecoded»:

“It is 100% vibecoded. I’ve never seen the code, and I never care to.” ¹⁴

Мэгги Эпплтон критикует это: «Gas Town itself is a stream of consciousness converted directly into code… vibe designed too» — хаотичная эволюция вместо намеренного проектирования¹⁴. Стив Клабник, напротив, видит в этом осознанный эксперимент: «Some old assumptions do not hold any longer»⁹.

Узкое горлышко смещается к дизайну

Все рецензенты сходятся: когда агенты берут на себя реализацию, дизайн и планирование становятся лимитирующим фактором¹⁴¹⁵. Эпплтон отмечает: «Gas Town churns through implementation plans so quickly that you have to do a LOT of design and planning to keep the engine fed»¹⁴. Абрахмс конкретизирует: поддержание системы снабжённой качественными задачами сложнее, чем выполнение¹⁵.

Зрелость и надёжность

DoltHub протестировал Gastown и был вынужден закрыть все четыре сгенерированных PR из-за проблем с качеством⁶. Автор отмечает: «Success likely requires building proper guard rails before deployment». Система автономно пушила ветки, создавала PR и merge’ила код — несмотря на неуспешные тесты⁶.

Безопасность

Dan Lorenc (Chainguard) поднимает критический вопрос: неконтролируемые агенты могут случайно экспонировать credentials или совершить дорогостоящие ошибки¹³. Требуется надёжное управление credential’ами, контроль доступа и строгий code review.

Локальное состояние vs. удалённое

Lorenc также критикует local-first архитектуру: «Local state is fog. Remote state is a contract» — при сбое системы локальное состояние потенциально невосстановимо¹³. Рекомендация: якорить системы агентов к PR как единицам работы, CI как границе, remote-репозиториям как авторитативному состоянию.

Порог входа

Йегге предупреждает: «If you’re not at least Stage 7, or maybe Stage 6 and very brave, then you will not be able to use Gas Town»¹. Система ориентирована на продвинутых пользователей, уже жонглирующих несколькими агентами и нуждающихся в централизованном управлении.

Экосистема и интеграции

Вокруг Gastown и Beads формируется экосистема инструментов⁴¹⁰:

• Gastown Viewer — дашборд observability в реальном времени (TUI + React web-интерфейс)
• Beads Viewer (Dicklesworthstone) — Graph-aware TUI с PageRank, critical path, Kanban, визуализацией DAG зависимостей
• Beads Rust Port — быстрая альтернатива на Rust с SQLite и JSONL-экспортом
• Neovim Plugin — интеграция с редактором
• MCP Server — Model Context Protocol для взаимодействия AI-агентов с Beads
• Gasclaw — фреймворк интеграции с Gastown
• Shinzo — безопасные удалённые мультиагентные workspace’ы
• OpenClaw — 60-секундная система шаблонов workflow

Практические рекомендации

Если вы хотите попробовать Beads standalone

1. Установить bd и инициализировать в существующем проекте
2. Настроить интеграцию с агентом (bd setup claude)
3. Создать начальные эпики и задачи из существующего TODO/backlog
4. Позволить агенту работать циклами: bd ready → выполнение → bd close
5. Запускать bd doctor ежедневно

Если вы рассматриваете Gastown

1. Оценить зрелость: убедиться, что вы уже активно используете 5+ агентов
2. Настроить CI: без надёжных тестов система будет merge’ить сломанный код
3. Бюджетировать: $100/час — реалистичная оценка при полной загрузке
4. Начать с одного rig: добавить один проект, протестировать workflow с Mayor
5. Ожидать ручного контроля: система требует «substantial manual oversight, frequent corrections» — как управление командой очень быстрых, очень джуниорных разработчиков¹⁰

Для существующих проектов

• Beads подключается тривиально: bd init в любом Git-репозитории
• Gastown требует больше подготовки, но поддерживает gt rig add для существующих репозиториев
• Критично: настроить guard rails (CI, тесты, code review) до включения автономных агентов
• Рекомендуется постепенный подход: Beads → один агент с Beads → несколько агентов → полный Gastown

Quality Metrics