Узнайте, как оркестровать изменения программного обеспечения между несколькими агентами и репозиториями, управляя передачей задач, зависимостями, контекстом и доставкой.
Ваша платформа-команда передает множество изменений в сервисе аутентификации ИИ-агентам. Через полтора часа в пяти репозиториях открывается 11 пулл-реквестов. Все наборы тестов проходят успешно. Но почему-то сервис аутентификации все равно не работает.
Агенты выполнили свою работу. Каждый «исправил» проблему, которая была ему поручена, но никто не отвечал за взаимодействие между ними. Никто не заметил, что изменения Агента А затронули код, от которого зависел Агент Б.
Агент, как и человек, знает только тот контекст, который ему предоставлен; без контекста он действует вслепую.
Здесь возникают две проблемы координации. Мультиагентная оркестрация координирует работу нескольких агентов над отдельными задачами. Оркестрация нескольких репозиториев координирует изменения, которые охватывают кодовые базы с разными интерфейсами, зависимостями и этапами доставки. Они часто пересекаются, но решение одной проблемы не означает автоматическое решение другой.
Уровень оркестрации над агентами
Первая проблема — координация самих агентов. Это задача уровня мультиагентной оркестрации, управляющего слоя над агентами-разработчиками. Один из фреймворков, который можно использовать, разделяет этот управляющий слой на три роли:
- Координатор читает кодовую базу и составляет план, вплоть до того, какие файлы может затрагивать каждая задача. Планирование требует наибольшего уровня рассуждений, поэтому для этой роли можно использовать более мощную модель.
- Исполнители берут на себя узкую задачу, что позволяет делегировать простую работу моделям, требующим меньше вычислительных ресурсов для рассуждений.
- Верификатор проверяет результаты на соответствие плану перед тем, как их рассмотрит человек.
Поскольку эти задачи пересекают границы репозиториев, оркестрация также должна учитывать вторую проблему: каждый репозиторий может иметь разные зависимости, интерфейсы и средства контроля доставки.
Ваша CI/CD система содержит многие из тех элементов контроля, которые должна обеспечивать оркестрация. Защита веток, владельцы кода, семантическое версионирование и порядок миграций были разработаны для людей, работающих параллельно. Оркестрация должна заставлять агентов наследовать эти элементы контроля, а не создавать отдельные.
Наследование этих элементов контроля сложнее, чем кажется, потому что нет двух репозиториев, которые применяли бы их одинаково. У каждого репозитория есть «ворота» (gate) — проверка, которую изменение должно пройти перед слиянием. Один репозиторий может быть монорепозиторием, содержащим множество проектов, где воротами является очередь слияния. Другой может находиться в Azure DevOps, где воротами является одобрение от определенной группы рецензентов. Воротами третьего репозитория может быть ночная сборка и человек, который дает подтверждение.
Каждый тип ворот требует собственной интеграции с CI/CD системой, которая их обеспечивает, — инструментов, созданных для продвижения изменений через эти ворота. Ни одна интеграция не может справиться со всеми тремя, поэтому план должен фиксировать, какие ворота какого репозитория обеспечивают каждое требование.
Если ошибиться с этим наследованием, это отразится на показателях доставки. Исследование DORA 2025 года по-прежнему связывает внедрение ИИ с ростом нестабильности доставки.
Изоляция важнее параллелизма
Несколько агентов наиболее полезны, когда они могут работать одновременно. Но параллельная работа безопасна только тогда, когда каждый агент изолирован в своем собственном рабочем пространстве.
Если три агента работают с одной и той же копией кода, они могут перезаписать изменения друг друга, создать конфликты или оставить кодовую базу в непредсказуемом состоянии. Вот почему изоляция должна предшествовать параллелизму.
Один из способов справиться с этим — использование Git worktrees. Worktree предоставляет каждому агенту свой собственный рабочий каталог, индекс и HEAD, при этом используя один и тот же базовый репозиторий. Каждый агент получает свою копию, поэтому изменения в одном рабочем пространстве не мешают другому.
Агент, которому приказано оставаться в своем дереве, все равно может забрести в чужое. Только права доступа ОС или «песочница» могут провести черту, которую инструкция агента не сможет пересечь.
Два правила могут помочь сделать изоляцию более надежной. Во-первых, известная база. Когда каждое рабочее дерево начинается с чистого origin/main, остаточное состояние не перетечет из предыдущего запуска. Во-вторых, один агент может редактировать файл «горячей точки» за раз. Lock-файлы и реестры внедрения зависимостей обычно являются такими точками, привлекая правки от множества разных задач, что может привести к ненужным конфликтам и необходимости очистки.
Что должна нести в себе передача задач (handoff)
Даже если каждый ИИ-агент работает в своем изолированном пространстве, агенты все равно могут потерпеть неудачу при передаче работы друг другу.
Координатор передает задачу исполнителю, который передает результат верификатору. Каждая из этих передач — это handoff. Проблема в том, что при таких передачах важная информация может теряться. Требования, ограничения, допущения или контекст могут быть переданы неясно. Этот контекст рабочего процесса должен существовать дольше, чем отдельная сессия агента.
Изоляция может помочь защитить кодовую базу от конфликтующих изменений, но она не гарантирует, что нужная информация перемещается вместе с работой. Агенты все еще могут неправильно понять друг друга, упустить важные ограничения или сделать допущения, которые не разделяет следующий агент. Исследования сбоев мультиагентных систем показали, что многие из них происходят из-за такого рода несогласованности и из-за того, как спроектирован рабочий процесс, а не обязательно из-за возможностей самой модели.
У проектных ошибок есть проектные решения. Относитесь к передаче задачи как к версионируемому артефакту, который можно проверять так же, как и код, с которым он поставляется. Полезная передача должна включать четыре поля:
Качественная передача дает следующему агенту достаточно контекста, чтобы понять, что изменилось, какие ограничения все еще действуют и как работа уже была проверена.
Но эти четыре поля часто требуют больше контекста, чем координатор может увидеть внутри одного репозитория.
Где живет контекст, когда агент завершил работу
Зависимость, которая имеет значение, обычно находится в другом репозитории — это общий SDK, с которым компилируются ваши сервисы, или схема, которую парсят ваши потребители событий. Видеть дальше одного репозитория — это разница между определением объема задачи и гаданием.
Если контекст существует только в сессии агента, он исчезает, когда сессия заканчивается. Планы, решения и история запусков должны быть записаны в надежном месте, например, в выделенной ветке Git, где их можно будет просмотреть позже и связать с коммитами, на которые они повлияли.
Инструменты тоже должны быть долговечными. Интеграция, написанная один раз для интерфейса Model Context Protocol, принадлежит вашей архитектуре, а не конфигурации одного агента. Следующий шаг — композиция, объединение всей этой изолированной работы обратно в одно целое, согласованное изменение.
Тестируйте все изменение целиком, а не только ветки
Одиннадцать пулл-реквестов могут пройти свои индивидуальные проверки и все равно привести к сбою при объединении.
Это особенно верно, когда изменение охватывает несколько репозиториев. Одно обновление может зависеть от того, что другое будет применено первым. Инфраструктурное изменение может потребоваться до того, как миграция получит доступ к секрету, а миграция может потребоваться до того, как приложение выпустит код, зависящий от новых данных или прав доступа.
Эти зависимости создают необходимый порядок действий. У композиции есть свой порядок. CI для отдельных репозиториев по умолчанию не видит этот порядок. Многорепозиторные пайплайны существуют в GitHub Actions и Azure Pipelines, но их нужно проектировать специально.
Все 11 веток должны существовать вместе как единое состояние. Интеграционный прогон — единый запуск CI для этого объединенного состояния — это этап, на котором повторно проверяются требования к интерфейсам, недоступные для проверок на уровне отдельных веток. Агенты могут собрать все это воедино, но решение о слиянии остается за человеком-ревьюером.
Увеличенные контекстные окна не снимают необходимости в такой координации. Предоставление одному агенту доступа ко всем репозиториям может сократить количество передач задач, но при этом все изменение возлагается на одного исполнителя. Если в одной части возникнет ошибка, будет сложнее изолировать или отклонить только этот фрагмент.
Даже при налаженной координации следующим узким местом часто становится проверка человеком. Десять агентов, направляющих задачи одному ревьюеру, создают очередь. Оркестрация может маршрутизировать и сводить воедино эту очередь, но она не способна заменить экспертное суждение, необходимое для ее обработки.
Начните с недавнего межрепозиторного изменения
Возьмите межрепозиторное изменение, выкаченное вашей командой в прошлом квартале, и воссоздайте план, который для него потребовался бы — вплоть до файлов, закрепленных за каждой задачей, и моментов, где он устаревает по мере продвижения ветки main. Запустите его в режиме «только для чтения»: агенты предлагают изменения, но ничего не сливается. Пробелы всплывут уже в первый час, и почти никогда — в коде, который пишут агенты. Они обнаруживаются в требованиях к интерфейсам, которые не были зафиксированы.
Запишите их. Это главное условие: процесс поставки должен быть сформулирован настолько четко, чтобы его можно было доверить системе, которая не станет уточнять, что именно вы имели в виду.
Узнайте больше об оркестрации Progress Forge
Если вы готовы перейти от изолированных задач по написанию кода с помощью ИИ к воспроизводимым инженерным процессам, Progress Forge (ранее Progress Agent Harness) создан именно для этой цели. Он оркестрирует ИИ-агентов для написания кода, которых уже использует ваша команда, через структурированные процессы со встроенным контролем, прозрачностью и проверкой человеком.
Ознакомьтесь с программой раннего доступа Progress Forge Early Access Program, чтобы узнать, как она поможет применить эти идеи на практике.
Запросить демо
