GitLab запускает оркестрацию агентов: команда /goal ведёт задачу до зелёного CI

GitLab пытается убрать ожидание между этапами разработки. На конференции Transcend компания объявила о трёх новых возможностях оркестрации агентов в Duo Agent Platform: целевые потоки (goal-driven flows), интеграция GitLab for Slack и Custom Flows. Для целевых потоков нужны GitLab 19.3 и Duo CLI 9.17.0 или новее. Аргумент GitLab простой: ИИ ускорил написание кода, но не доставку. Агент выдаёт исправление за минуты, а потом оно неделями ждёт подписи ревьюера, разбора алертов пайплайна, триажа результатов сканирования и очередного ручного промпта.

Цель вместо шагов: как работает /goal

Целевые потоки дают агенту финишную черту, а не следующее действие. Разработчик описывает задачу и критерий готовности, а поток работает, пока не дойдёт до результата. Ревью, тесты, проверки безопасности и согласования идут как одна связанная цепочка, без остановок между шагами.

Запуск выглядит так: `/goal Fix the checkout timeout. Continue until tests pass and CI is green.` Команда работает в Duo CLI, в headless-режиме через `duo run --goal` и в Agentic Chat. Вторая форма важна для автоматизации: её можно вызвать из скриптов и пайплайнов без интерактивной сессии.

Отдельная деталь касается контроля качества. На каждом шаге работу сверяет с целью отдельная модель, то есть агент не оценивает себя сам. Прогон можно остановить или перенаправить в любой момент.

Slack и Custom Flows: старт там, где просят

GitLab for Slack решает проблему входной точки. Большинство задач рождается в обсуждении, а не в трекере. Достаточно упомянуть @GitLab в канале или треде и написать, например, «fix the failing pipeline»: запустится поток, а Duo будет стримить прогресс прямо в тред. Тот же бот отвечает на вопросы о кодовой базе и превращает переписку в issue. Поток исполняется под теми же identity и политиками, что и любой другой в GitLab, так что управление доступом остаётся на стороне платформы, а не чата.

Custom Flows закрывают третий сценарий: команда сама описывает многошаговую последовательность агентов и привязывает её к событиям GitLab, таким как упоминание, назначение или пайплайн. Потоки выполняются в CI/CD. Пример от GitLab: самовосстанавливающийся пайплайн анализирует упавший тест, генерирует исправление, коммитит его и уведомляет команду. На чувствительных шагах можно поставить контрольные точки с участием человека.

Всё это работает в одной модели управления: identity, политики и цепочка доказательств (evidence chain) общие для всех потоков. Для компаний с аудитом это, пожалуй, главный довод в пользу платформенного подхода против россыпи внешних агентов. Расширять набор можно через AI Catalog, подключая внешних агентов и инструменты через MCP-клиент и MCP-сервер. Базовые агенты и потоки уже покрывают этапы от планирования до анализа в интерфейсе GitLab, IDE и Duo CLI.

Доступность и первые шаги

По условиям запуска:

• целевые потоки: GitLab.com, Self-Managed и Dedicated, тарифы Premium и Ultimate;
• минимальные версии: GitLab 19.3 и Duo CLI 9.17.0;
• Custom Flows: уже в общем доступе (GA);
• MCP-сервер и GitLab for Slack: GA ожидается позже в этом месяце;
• оплата: GitLab Credits, которые входят в подписку Premium или Ultimate.

Начинать разумно с малого. Сначала проверьте версии GitLab и Duo CLI, включите Duo Agent Platform и прогоните `/goal` на узкой задаче с однозначным критерием готовности, например на падающем тесте с воспроизводимой ошибкой. Формулировка цели решает почти всё: «зелёный CI» проверяется машиной, «улучшить код» нет. Затем перенесите повторяющийся ручной процесс в Custom Flow, оставив человеческие контрольные точки на мерже и работе с секретами. Подключение к Slack имеет смысл планировать после GA, когда интеграция выйдет из раннего доступа.

Главный вопрос остаётся открытым: насколько надёжно модель-проверяющий отличает действительно выполненную цель от формально зелёного пайплайна. Это стоит измерять на собственных репозиториях до того, как потоки получат право двигать код дальше ревью.