Grite: трекер задач внутри Git для AI-агентов

Проблема координации AI-агентов

Запустите двух AI-агентов в одном репозитории — первым сломается не код, а координация. Агент A начинает рефакторинг auth. Агент B, работая параллельно, не знает об этом и делает то же самое. Ни один не помнит, что делал в прошлом сеансе, потому что каждый стартует с пустым контекстом. Обычные решения хуже проблемы: файл состояния в репозитории загрязняет каждый diff и создаёт конфликты при слиянии, а внешний трекер задач требует API-токенов, лимитов и зависимостей от сети.

Поэтому я создал Grite — трекер задач, который живёт внутри вашего Git-репозитория как append-only журнал событий с детерминированным CRDT-слиянием. Два писателя никогда не конфликтуют. Ни сервера. Ни базы данных. Ни конфликтов слияния. Просто Git.

Основная идея: задачи — это события, Git-ссылки — журнал

Grite не хранит задачи как файлы в рабочем дереве. Он хранит их как append-only журнал упреждающей записи внутри Git-ссылки refs/grite/wal. Каждое действие — создание, комментарий, изменение метки — это одно неизменяемое событие в формате CBOR, добавленное в журнал. Ваше рабочее дерево остаётся абсолютно чистым. Единственный файл, который Grite когда-либо записывает, — это AGENTS.md, и это сделано намеренно, чтобы агенты автоматически обнаруживали инструмент.

Поскольку состояние живёт в Git-ссылке, оно путешествует с вашим кодом. Оно ветвится, когда вы ветвитесь. Оно сливается, когда вы сливаете. Оно синхронизируется, когда вы делаете git push. Если вы можете отправить изменения на удалённый репозиторий, вы можете синхронизировать задачи. Никаких новых учётных записей, инфраструктуры или протоколов.

Как это работает

Три уровня, чётко разделённые.

Git WAL — источник истины

События добавляются как блоки CBOR, каждый идентифицируется адресуемым по содержимому EventId, который является хешем BLAKE2b от тела события. Адресация по содержимому делает журнал устойчивым к подделке: измените один байт события — и его ID перестанет совпадать, что разорвёт цепочку. Подпись опциональна (Ed25519 на событие), так что можно доказать, какой актор что создал.

Материализованное представление — кэш для запросов

Это встроенное key-value хранилище sled, которое проецирует журнал событий в текущее состояние задач. Это кэш, к которому вы обращаетесь. Он перестраивается из WAL при старте и обновляется инкрементально. Удалить его безопасно — он просто воспроизведёт журнал. Проекция использует семантику CRDT: Last-Write-Wins для скалярных полей и коммутативные множества для меток. В этом весь трюк бесконфликтного многопользовательского редактирования: два агента редактируют одну задачу на двух машинах, оба изменения выживают при слиянии, и результат идентичен независимо от порядка слияния.

CLI и опциональный демон — интерфейс

Демон держит sled-представление тёплым и сериализует запись, разрешая параллельное чтение, но он опционален для корректности. CLI работает автономно и автоматически запускает демон только когда это нужно.

Производительность

Цифры, которые важны, когда агент выполняет сотни запросов за сеанс:

• Создание задачи: ~5 мс (одно событие)
• Список из 1000 задач: ~10 мс (запрос sled)
• Полная перестройка из 10 000 событий: ~500 мс (воспроизведение всего WAL)
• Перестройка из снимка: ~50 мс (переход к снимку, воспроизведение дельты)

Полная перестройка WAL имеет сложность O(n), поэтому существуют периодические снимки: они сокращают холодную перестройку после клонирования с воспроизведения всего до воспроизведения дельты. Каждый актор получает свою изолированную sled-базу, так что нагрузка от одного агента не блокирует другого.

Использование

Путь человека выглядит как обычный трекер, но с Git-семантикой:

cd ваш-проект
grite init  # создаёт AGENTS.md для обнаружения агентами
grite issue create --title "Исправить гонку в WAL" --body "Периодический сбой при высокой конкурентности."
grite issue list
grite issue update <id> --label bug --label concurrency
grite issue link <issue-a> blocks <issue-b>
grite sync  # git fetch + CRDT merge, затем push

Путь агента — где дизайн окупается. Агент захватывает блокировку, чтобы второй агент выбрал другую работу, затем записывает изученное как долговременную задачу-память, которую следующий сеанс сможет прочитать:

# Агент загружается, синхронизируется и берёт задачу
grite sync --pull
grite issue list --label "agent:todo" --json
grite issue update <id> --label "agent:in-progress"
grite lock acquire src/parser.rs --ttl 1800
# Агент сохраняет знание для своего будущего я
grite issue create --title "Крайний случай парсера: пустые структуры" --body "Парсер падает на struct {}; нужно обработать." --label memory
grite issue close <id>
grite sync --push

Каждая команда поддерживает --json, так что агенты парсят вывод вместо скрапинга. Распределённая блокировка имеет TTL-аренду, поэтому упавший агент не держит ресурс вечно. Извлечение контекста работает на tree-sitter для 10 языков (Rust, Python, TypeScript, JavaScript, Go, Java, C, C++, Ruby, Elixir), так что агент может создать задачу с реальным контекстом символов вместо расплывчатой заметки.

Где Grite не подходит

Честность — это главное, так что вот где Grite — неправильный инструмент.

• Терминал и Git. Нет веб-интерфейса, канбан-доски, @-упоминаний, email-дайджеста. Если ваша команда живёт в браузерном трекере с дашбордами и нетехническими стейкхолдерами, Grite покажется примитивным. Он создан для людей и агентов, которые уже живут в терминале.
• Локальный для репозитория. Кросс-репозиторные задачи, общеорганизационный бэклог из десятков сервисов или публичный баг-трекер, где внешние пользователи создают отчёты — не для Grite. Ваши задачи ограничены репозиторием, который они описывают.
• Детерминированное, а не умное слияние. Last-Write-Wins означает, что если два агента установили конфликтующие заголовки, один выигрывает по временной метке. Это корректно и бесконфликтно, но это не человеческое суждение. Для полей, где вы хотите, чтобы человек согласовывал правки, автоматическое слияние не подходит.
• Требуется Git 2.38+. Демон опционален, но зависимость от Git — нет.

Выводы

1. Состояние координации для параллельных агентов должно быть рядом с кодом, а не на сервере. Git-ссылки дают синхронизацию, историю и офлайн бесплатно.
2. Append-only журнал событий + перестраиваемый кэш — чистое разделение: журнал — истина, sled-представление — одноразовая скорость.
3. CRDT Last-Write-Wins превращает «два агента редактируют одну задачу» из конфликта слияния в не-событие. Это детерминированно (что нужно для воспроизводимости) и глупо (что нужно там, где всё ещё нужен человек).

Код, модель данных и тестовые векторы хеширования здесь: https://github.com/neul-labs/grite

Если вы запускаете больше одного AI-агента против одного репозитория, мне интересно, как вы координируете их сегодня. Попробуйте, issues приветствуются.