Многоагентный конвейер разработки — архетип доставки софта

Это архетип доставки софта: самая зрелая цепочка, которую мы поставляем, построенная на движке процессов Forge . Это одна форма из нескольких — тот же движок водит команды ресёрча, контента и операций. Эта страница описывает именно форму SDLC; остальные см. в работах, которые команды передают .

Как работает конвейер

Когда вы ставите на задачу GitHub метку forge-pipeline, кондуктор Forge создаёт ChatSession с ключом triggeredBy=pipeline:<issueID>:<role> и запускает первую роль. Каждая роль — полноценный прогон агента: системный промпт, вызовы инструментов, журнал сообщений — который заканчивается типизированной передачей для следующей роли.

Что делает каждый агент

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

Агент-архитектор — берёт спецификацию PM и проектирует техническое решение: границы компонентов, контракты API, модели данных, точки интеграции. Ссылается на конкретные файлы репозитория.

Агент-разработчик — реализует по архитектуре. Пишет код, тесты и, если нужно, миграцию. Коммитит в ветку конвейера (forge/pipeline/<номер-задачи>).

QA-агент — прогоняет набор тестов. Проверяет граничные случаи, перечисленные PM. Смотрит изменения, значимые для безопасности. Сообщает результат с воспроизводимыми логами.

Ревьюер кода — читает дифф против исходных критериев PM и проекта архитектора. Оставляет комментарии, запрашивает правки или подтверждает. При подтверждении открывает PR.

Контракт передачи

Каждый агент возвращает обёрнутую маркерами JSON-структуру, которую следующая роль получает как структурированный контекст:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "type": "PMToArchitectHandoff",
  "issue_id": 142,
  "scope_groups": [
    { "id": "auth-flow", "summary": "...", "constraints": [...] }
  ],
  "acceptance_criteria": [
    "User can log in with email + password",
    "Failed login shows error within 300ms"
  ]
}

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

Маршрутизация комментариев

Пока конвейер работает, каждый комментарий к задаче GitHub (или к появившемуся PR) направляется текущей активной роли. Кондуктор находит sessionId задачи, добавляет комментарий сообщением пользователя и ставит в очередь ход одной роли — без полной цепочки передач, просто уточнение активному агенту.

Это значит, что заинтересованные лица могут разговаривать с активной ролью прямо посреди конвейера. Попросить PM уточнить требование. Сказать разработчику взять другую библиотеку. Оспорить покрытие у QA-агента. Диалог продолжается на месте, а страница задачи работает живой консолью.

Архитектура

Хук ReleaseFinaliser кондуктора срабатывает после каждого хода. Он проверяет turn.PipelineID, извлекает передачу, находит следующую включённую роль через roles.GetOrderedEnabledRoles(cfg) и ставит в очередь следующий ход. Роли настраиваются на организацию — любую ненужную можно отключить или переставить.

Что вы получаете

Всё перечисленное уже работает в продакшене.

• Маршрутизация webhook и машина состояний с привязкой к сессии
• Смена нескольких ролей с типизированными передачами
• Маршрутизация комментариев на задачах и pull request
• Создание PR с полным аудиторским следом конвейера
• Круги ревью и правок — цикл ревьюер→разработчик с настраиваемым лимитом
• Агенты-персонажи — роли, карточки из десяти характеристик, опыт, память
• Режим соревнования — две команды на одном брифе, выбор победителя
• Реестр своих ролей — операторы определяют собственные места в цикле
• Атрибуция рантайма по каждому ходу (Lambda / k8s / GHA видно в интерфейсе)
• Редактор умолчаний конфигурации ролей организации

Полный смоук-тест (issue-pipeline-full-smoke.sh) прогоняет PM→архитектор→разработчик→QA→ревьюер→PR целиком и входит в предмёржевый гейт. Прогоны режима соревнования проверяются скриптом compete-variance-study.sh.

Попробовать

1. Установите GitHub App Forge на свой репозиторий.
2. Заведите любую задачу и поставьте метку forge-pipeline.
3. Следите за комментариями — каждая роль объявляет себя и пишет о ходе работы.
4. Отревьюйте PR, когда он появится.