> 03 May 2026 · 6 мин

GNAP: оркестрируй рой AI-агентов через git-репо. 4 JSON-файла, ноль серверов

У тебя 5 агентов: один пишет тесты, второй чинит баги, третий ревьюит PR, четвёртый деплоит, пятый дёргает пользователя в Telegram. Как они договорятся между собой?

Стандартный ответ: оркестратор. Развернуть LangGraph, поднять Redis для очереди, прикрутить Postgres для состояний, написать кастомные хуки сверху. Полдня инфраструктуры. Потом окажется, что агенты висят на разных провайдерах, и ты пилишь общий API. Потом — что у одного агента нет доступа к Postgres, и появляется прокси.

Парни из Farol Labs предложили альтернативу, которая выглядит еретической: просто git-репо. Никаких серверов, никаких баз. 4 JSON-файла. Любой агент, который умеет git pull и git push, в команде.

Это GNAP (Git-Native Agent Protocol). RFC-черновик от Farol Labs, MIT-лицензия, 24 коммита, 51 звезда. Маленький проект, но идея заслуживает отдельного разбора.

TL;DR: GNAP координирует AI-агентов через shared git-репо. 4 типа JSON-сущностей (agents/tasks/runs/messages), heartbeat-цикл pull→check→work→commit→push, git history как audit log. Без серверов, без БД, без vendor lock-in. Работает с OpenClaw, Codex, Claude Code и любым кастомным ботом.

Идея на пальцах

В корне репо появляется директория .gnap/:

.gnap/
  version              ← "4"
  agents.json          ← команда (люди и AI-агенты)
  tasks/FA-1.json      ← первая задача
  runs/                ← пусто (агенты пишут сюда сами)
  messages/            ← пусто (агенты пишут сюда сами)

Каждый агент крутит heartbeat-цикл:

1. git pull
2. agents.json     → активен ли я?
3. tasks/          → что мне назначено?
4. messages/       → есть ли что-то новое?
5. Делаю работу → commit → git push
6. Сплю до следующего тика

Всё. Git одновременно работает транспортом и хранилищем. История коммитов превращается в audit-log без отдельной системы.

Как выглядит задача

Один JSON-файл на одну задачу:

{
  "id": "FA-1",
  "title": "Set up Stripe billing",
  "assigned_to": ["leo"],
  "state": "in_progress",
  "priority": 0,
  "created_by": "ori",
  "created_at": "2026-03-12T11:40:00Z"
}

State machine у задачи стандартная: todo → in_progress → done (или failed/cancelled). Кто-то её создаёт через git push, кто-то ставит на исполнение. Если два агента одновременно схватили одну задачу, ловится merge-конфликт git, второй pull/rebase/retry.

Запуск (run) живёт в отдельной сущности:

{
  "id": "FA-1-1",
  "task": "FA-1",
  "agent": "carl",
  "state": "completed",
  "tokens": {"input": 12400, "output": 3200},
  "cost_usd": 0.08,
  "result": "Stripe account created, test mode live"
}

Один таск может иметь много runs. Если первый запуск запорол попытку, агент или другой агент создаёт второй run. Сама задача от этого не падает.

Коммиты пишутся по конвенции:

carl: done FA-1 - Stripe test mode live
ori: create FA-3 onboarding-v2
leo: assign FA-1 to carl

Читая git log, ты видишь полную историю работы команды без отдельного дашборда.

Почему это работает

Я смотрю на GNAP и сначала хочется фыркнуть: ну, Trello через git, что нового? Потом начинаешь раскручивать последствия.

Атомарность. git push атомарен. Если два агента одновременно пишут в один файл, конфликт ловится на push, второй откатывается и retry. Никаких race conditions с распределёнными локами.

Distributed by default. Реплика git-репо есть у каждого агента локально. Сеть упала, агент продолжает работать с кешем, потом синхронизирует. AWS лежит, твой LangGraph мёртв, а GNAP жив.

Аудит бесплатно. Каждое действие = коммит. git blame показывает кто и что сделал, когда. Никаких отдельных таблиц audit_log, никаких ELK-стеков для трейсинга.

Гибридные команды. В agents.json сидят и AI, и люди. Агент создал задачу, человек доделал руками, второй агент проревьюил. Все равны.

В прод-варианте Farol Labs гоняет на GNAP 4 агентов (2 AI плюс 2 человека) и 50+ задач. Не масштаб Stripe, но и протокол молодой.

Подводные камни

Романтика заканчивается там, где начинается latency и масштаб.

1. Heartbeat-полинг это не push. Агенты дёргают git pull каждые N секунд. Хочешь real-time коммуникацию? GNAP не сюда. Между созданием задачи и её захватом проходит минимум один heartbeat. При интервале 30 секунд минимальная задержка тоже 30 секунд. Для пакетных задач норм, для интерактивных нет.

2. Git-репо разрастается. Каждый run отдельный JSON-файл, каждое сообщение тоже. Если 100 агентов работают сутки, через неделю в .gnap/runs/ десятки тысяч файлов. Git с этим живёт, но git status начинает тормозить. Стратегии архивации (rotate в archive/ ветку) спека не предлагает, пиши сам.

3. Auth-модель сырая. Доступ к git = доступ ко всему. Агент с write-правами может удалить чужие задачи, переназначить себе чужие runs, переписать agents.json или зачистить историю через force-push. Никаких ACL уровня файла. Если ключ агента утёк, катастрофа. В A2A-протоколе Google этой проблемы нет: идентичность и scope привязаны к каждому вызову.

4. Vendor lock-in заменили на git lock-in. "Без серверов" по факту значит "ваш сервер это GitHub/GitLab". Если репо где-то размещено, и провайдер ушёл в downtime, твоя multi-agent система встала. Локальный fallback есть, но синхронизация всё равно через центральный remote.

5. Это RFC-черновик. 51 звезда, 2 форка, 24 коммита, один продакшн-юзер (сами авторы). Спека может развернуться завтра. Если строишь критическую систему, закладывай миграцию. Если эксперимент, go.

Альтернативы

A2A (Agent-to-Agent): протокол Google для меж-агентной коммуникации. Кардинально другой подход, серверы агентов экспонируют HTTP-эндпойнты с capability-манифестом, общаются через стандартизированные сообщения. Сложнее и тяжелее, но для real-time и enterprise решает проблемы GNAP с auth и латенси.
MCP (Model Context Protocol): Anthropic, "USB-C для AI". Не про оркестрацию агентов, а про tool-use: агент → инструмент → результат. Перпендикулярен GNAP, можно использовать вместе.
CrewAI, AutoGen, LangGraph — полноценные фреймворки оркестрации со встроенной логикой ролей и разделения труда. Дают больше из коробки, требуют единого рантайма. GNAP не пытается их заменить, он играет нишу "координация без оркестратора".

Вердикт

GNAP стоит попробовать, если у тебя 3-15 агентов из разных стеков (Claude Code плюс Codex плюс кастомный бот) и нужен общий task-board без нового сервиса в инфре. Особенно если ты уже инвестировал в git-инфраструктуру (CI/CD, ревью, деплой) и хочешь подключить агентов к ней же.

Не стоит, если нужна сабсекундная латенси, гоняешь больше 50 агентов одновременно, или строишь систему со строгими access-контролями. Для этих случаев бери A2A или собственный оркестратор.

И ещё: это RFC, не v1. Смотри на него как на работающую идею, но в прод первой версии я бы не нёс. А вот в выходной собрать на нём команду из Claude Code и Codex для домашнего проекта — самое то. Концепция простая, внедряется за пару часов.

Как попробовать

Создай новый git-репо или используй существующий
Добавь директорию .gnap/ со структурой из README (version, agents.json, tasks/, runs/, messages/)

Зарегистрируй первого агента в agents.json:

{"agents": [{"id": "claude", "type": "ai", "status": "active"}]}

Создай задачу tasks/T-1.json с assigned_to: ["claude"]
Запусти агента в loop (для Claude Code через Routines, для Codex через cron и /goal workflows)
Дашборд их прод-инсталляции на farol.team/dashboard

Спека и примеры лежат на github.com/farol-team/gnap. Меньше строк кода, больше идей. GNAP это то, как многие из нас в 2026-м захотят координировать своих ботов: через инструмент, который у каждого разработчика и так уже стоит.