Google A2A поверх Git: production-ready транспорт для агентов между организациями

Проблема

Google A2A (Agent-to-Agent) — открытый стандарт интероперабельности агентов: JSON-RPC 2.0 как формат сообщений, .well-known/agent.json как манифест, задачи с жизненным циклом, делегирование между агентами разных вендоров. Стандарт описывает что передаётся, но транспорт оставляет открытым — обычно подразумевается HTTP(S).

HTTP-транспорт удобен внутри одной сети. Но как только агенты живут у разных людей в разных компаниях, появляются вопросы, которые HTTP не решает из коробки:

• • Как агент Алисы обратится к агенту Боба, если у Боба нет публичного endpoint и SLA?
• • Как человек Алиса поставит задачу агенту Боба, если их объединяет только общий рабочий контекст?
• • Кто хранит историю всех взаимодействий — и можно ли её воспроизвести через полгода, когда Бобовский сервер выключен?
• • Кто платит за инфраструктуру, когда десять человек хотят оркестровать агентов в общем эксперименте, и ни у кого нет желания поднимать брокер?

Отдельно — отличие от howto #2 «Cross-org agent negotiation», где два агента договариваются через firewall. Там — исследовательский диалог двух процессов об одном артефакте (OpenAPI-спека). Здесь — общая среда, в которой произвольное число людей и агентов работают как многопользовательская система. Подробное сравнение — в конце раздела «Методика».

Методика

Реализовать Google A2A поверх общего git-репозитория, используя файловую систему как очередь и git как транспорт.

Архитектурный приём

Контракты сообщения и манифеста — те же, что в Google A2A. Меняется только транспорт: вместо «агент держит HTTP-сервер» — «агент работает с локальным клоном репозитория».

Многопользовательская модель

1. 1. Человек → агент другого человека. Алиса добавляет файл inbox/{uuid}.json через git push. Агент Боба (его cron/CI) делает git pull, видит новый запрос, захватывает его атомарным rename в processing/, выполняет, публикует ответ в outbox/res_{uuid}.json, коммитит Processed {uuid}. Алиса делает git pull и читает ответ. Никаких серверов у Боба не запущено — агент стартует по расписанию или триггеру push.
2. 2. Агент → агент другого человека. Тот же путь, но запрос формирует автономный агент Алисы. Цепочки делегирования (агент X породил подзадачу для агента Y) выражаются через parent_id в новом JSON-RPC сообщении — порождается дерево итераций, видимое всем через git log.
3. 3. Несколько ролей одного владельца. Манифесты в .well-known/agents/ объявляют роли с собственными capabilities. Агент проверяет, может ли взять задачу, до захвата.
4. 4. Аудит и compliance бесплатно. git log — полная история: кто отправил, кто обработал, когда. Распределённая история, которую невозможно переписать незаметно: каждый клон содержит свою копию. Для регулируемых индустрий это уровень audit trail, которого HTTP-транспорт не даёт без отдельного контура.

Production-ready механика

1. 1. Атомарный захват через rename. При гонке двух агентов — rename(inbox/{id}.json → processing/{id}.json) на одной POSIX-точке монтирования атомарен: ровно один winner (CLAIMED), остальные ловят ENOENT (LOST_RACE) или EEXIST (CONFLICT_EXISTS, эскалация человеку). Формализовано в docs/ATOMIC_CAPTURE.md с таблицей исходов, а не «как-нибудь сделаем mutex».
2. 2. JSON-RPC 2.0 как контракт. Поля запроса и ответа специфицированы с явными инвариантами (например: при error поле result обязано быть null). Любой агент любого вендора, реализующий A2A, становится участником шины без модификаций — формат тот же.
3. 3. Iteration Policy через parent_id. Доработка задачи — новая задача с новым id и полем parent_id. Исполнитель обязан загрузить базовый контекст из outbox/{parent_id}/ до выполнения работы; если контекст не восстанавливается — останавливается и зовёт человека. Файлы прошлой итерации не перезаписываются: получается дерево, в котором две параллельные ветки доработок сосуществуют. Так снимается старый вопрос «куда писать v2» в агентских пайплайнах.
4. 4. Паттерн Конверта для тяжёлых артефактов. Машинный ответ всегда в outbox/res_{id}.json. Если есть дополнительные файлы (PDF, CSV, изображения) — рядом каталог outbox/{id}/ с metadata.json как описью. Стейджинг вне outbox/, с одним атомарным rename в финале. В outbox/ никогда не появляются полусобранные состояния.
5. 5. Разделение ролей rename и git. rename защищает от гонки локально; git pull/push распространяет уже зафиксированные мутации между участниками. Git не отвечает за атомарность захвата — только за распространение и историю. Эта разделённость обязанностей и делает систему предсказуемой.

Сравнение с howto #2 (bots-discuss-spec)

Если #2 — «можно ли вообще», то #14 — «как поставить в общий репо и пользоваться вдесятером». Читать #2 →

Артефакт

github.com/dobryakov/a2a-example — референс-имплементация Google A2A на file-bus.

• Спецификация: PROTOCOL.md, docs/SYSTEM_INSTRUCTIONS.md (что агент обязан и не имеет права делать), docs/ATOMIC_CAPTURE.md (модель захвата с таблицей исходов), docs/VERSIONING.md (git как журнал снимков).
• Манифесты ролей в .well-known/agents/: Data Analyst, Product Manager — шаблоны под свой набор capabilities.
• Готовая интеграция с Cursor и Claude: правило .cursor/rules/a2a-file-bus.mdc и Claude-скиллы «текст → inbox/» и «inbox/ → ответ». Шина пригодна как рабочая среда для LLM-агентов из коробки.
• Примеры запросов, включая доработку с parent_id (docs/examples/).

Чтобы подключить агента партнёра — достаточно дать ему доступ к репозиторию (deploy-key или member в org), положить его манифест в .well-known/agents/{agent_id}.json и зафиксировать стратегию сортировки inbox/ в его журнале. Никакого VPN, обмена API-ключами и согласования URL.

Для кого и почему

Это не замена HTTP-A2A в нагруженном проде. Класс задач другой: агенты живут у разных людей/команд/организаций; нет желания держать всем публичные endpoint и SLA; audit trail и воспроизводимость важнее throughput; хочется, чтобы люди тоже могли ставить задачи чужим агентам — тем же контрактом, без отдельного UI поверх.

Сильная сторона артефакта — не код, а контракты: SYSTEM_INSTRUCTIONS.md формализует поведение агента до уровня «нарушение считается ошибкой выполнения»; ATOMIC_CAPTURE.md проговаривает гонки явно; Iteration Policy решает версионирование агентских ответов архитектурно, а не конвенцией имён.

Для CTO/архитектора это про то, что Google A2A — это формат, а не транспорт. И про то, как из открытого стандарта и двух POSIX-примитивов собирается мульти-тенант среда для агентов — без брокера и без вендор-лока.