Эта страница представляет собой аудиторную имитационную тренировку: несколько агентов распределяют между собой работу над одной задачей разработки, а все созданные ими варианты правок направляются в автоматизированные тесты и шлюз приёмки. В историческую базовую версию попадают только те правки, которые соответствуют исполняемым критериям приёмки; непригодные правки блокируются и возвращаются с воспроизводимой обратной связью. Цель не в том, чтобы агенты «наспорили» правильное решение, а в том, чтобы замкнуть инженерный цикл «совместная разработка — автоматическая приёмка — наследование истории».
Цели тренировки
- Понять распределение задач при совместной разработке несколькими агентами, сведение вариантов правок и роль шлюза приёмки в блокировании непригодных правок.
- На практике заменить субъективное согласование исполняемыми тестами и критериями приёмки и увидеть, какие варианты попадают в базовую версию, а какие требуют повторной попытки.
- Сравнить вопросы повышенной сложности: воспроизводимость правил приёмки, практическая применимость обратной связи, риски ложного и пропущенного блокирования, гранулярность декомпозиции и затраты на совместную работу.
Распределение ролей и базовый порядок работы
Учебную группу можно разделить на агента планирования/декомпозиции, агента реализации, агента генерации тестов и агента проверки/координации. По одной задаче допускается несколько вариантов правок, а окончательное решение принимает шлюз.
- Декомпозиция задачи: разбить цель на независимо проверяемые подзадачи, например «валидация интерфейса — исправление алгоритма — регрессионные тесты».
- Параллельная реализация: несколько агентов реализации предлагают свои патчи, а агент тестирования создаёт граничные случаи.
- Автоматическая приёмка: запускаются автоматические тесты, статическая проверка и проверка контрактов, а шлюз приёмки выносит решение на основе исполняемых критериев.
- Наследование истории: принятые правки включаются в историческую базовую версию и становятся основой для дальнейшей работы агентов; отклонённые правки сохраняют причины сбоя и информацию для воспроизведения, чтобы их можно было доработать.
Критерии шлюза приёмки
Критерии шлюза должны быть исполняемыми, а не сводиться к «выглядит правильно». В первую очередь блокируются правки, которые не соответствуют интерфейсному контракту, вносят регрессии, не покрывают граничные условия или нарушают требования к качеству. Полезная обратная связь должна включать как минимум: сбойный тест, журнал, шаги воспроизведения, ожидаемое поведение и соответствующие ограничения.
Наследование истории и наблюдения повышенной сложности
После попадания принятых правок в базовую версию последующим агентам не нужно начинать с нуля; отклонённые правки становятся доступными для поиска негативными примерами, что помогает не повторять ошибок. При оценке таких систем совместной работы особое внимание следует уделять воспроизводимости правил приёмки, практической применимости обратной связи, а также разным рискам ложного и пропущенного блокирования. Слишком мелкая декомпозиция повышает затраты на сведение и приёмку, а слишком крупная приводит к тому, что варианты правок перекрывают друг друга; надёжнее разбивать работу по границам «независимой проверяемости».
Тренировка: совместная работа нескольких агентов и шлюз приёмкиНа этой схеме тренировки показано, как патчи-кандидаты, параллельно создаваемые ролями планирования и декомпозиции, реализации, генерации тестов и проверки с координацией, направляются в автоматизированные тесты и на решение шлюза приёмки. Правки, соответствующие исполняемым критериям, включаются в историческую базовую версию и наследуются последующими агентами; отклонённые правки сохраняют сбойный тест, журнал и шаги воспроизведения и используются как доступные для поиска негативные примеры при повторных попытках, тем самым заменяя субъективное согласование воспроизводимыми доказательствами.
