GitLab MCP — это MCP-сервер самого GitLab, который даёт ИИ-агенту доступ к проектам: чтение задач и обсуждений, работа с merge request, данные репозитория и CI. Схема устойчива, когда агент начинает с чтения и черновиков, а права на запись расширяются по мере чистоты его diff. Пока сервер в статусе beta, держите его на отдельном тестовом проекте.
Что отдаём агенту
GitLab публикует собственный MCP-сервер, на момент проверки в статусе beta. Инструмент регистрируется как OAuth-приложение и получает токен после согласия пользователя, поэтому права агента определяются ролью этого пользователя. Доступ включает администратор: для группы верхнего уровня на GitLab.com или на уровне инстанса при самостоятельной установке.
Стартовый пакет для агента в GitLab выглядит скромно: прочитать задачу, собрать контекст из связанных обсуждений, создать ветку по именованию команды, подготовить черновик merge request с заполненным шаблоном. Каждый шаг укладывается в черновик, который человек проверяет, а рутина, съедающая заметное время разработчика на каждой задаче, уходит агенту. Про права и проверку агентов в целом — в материале про агентов для разработки, а здесь разбираем именно связку с GitLab.
Подключение проверяйте в три захода. Сначала клиент проходит регистрацию и согласие пользователя: инструмент регистрируется как OAuth-приложение и получает токен. Затем агент читает тестовый проект: задачу, обсуждение, файл. Наконец, он пробует создать ветку, и результат сверяют с картой прав: пользователю с ролью Reporter запись должна быть отказана, а с ролью Developer доступна. Расхождение означает, что агент получил больше прав, чем задумано.
Вторая волна возможностей — комментарии в обсуждениях, разбор упавшего pipeline с предложением правки, сводка активности за неделю. Она открывается после нескольких спринтов чистой работы первой волны: журнал покажет, где агент уверен, а команда привыкнет проверять его черновики быстро.
Экономический смысл контура измеряется без сложных формул: сколько задач спринта закрыты от карточки до зелёного pipeline без ручных правок. Освободившееся время разработчики отдают задачам с сомнительными требованиями, где модель пока бессильна.
Карта прав
| Инструмент | Читает | Пишет |
|---|---|---|
| Задачи (work items) | Карточки, комментарии, метки | Комментарий-черновик по команде |
| Репозиторий | Файлы, история коммитов, diff | Ветки и коммиты в рабочей ветке |
| Merge request | Список, шаблоны, обсуждения | Черновик MR, ответы на замечания |
| CI и релизы | Статусы pipeline, логи | Перезапуск jobs, теги — только через человека |
Права агента равны правам пользователя, от имени которого пройден OAuth. Поэтому заведите для агента отдельного пользователя и дайте ему роль в проектах по минимуму: Reporter хватает для чтения, Developer открывает ветки и коммиты, Maintainer остаётся за людьми. Защищённые ветки в настройках проекта перекрывают прямой пуш в main, слияние идёт через одобрение. Второй рычаг — наборы инструментов: по документации по умолчанию включены core, merge requests, work items, repository и CI, остальные добавляются отдельно, и лишние наборы включать незачем. Сохранённые клиентом токены держите в защищённом хранилище, срок и отзыв доступа проверяйте на стороне GitLab.
Поток от задачи
- Агент получает номер задачи, читает карточку и обсуждение, формулирует короткий план.
- Создаёт ветку по шаблону команды и пишет код или правки локально в своей ветке.
- Запускает проверки, чинит падения и собирает summary: что сделано, что затронуто, что осталось.
- Открывает черновик merge request с заполненным шаблоном и ссылкой на задачу.
- Пайплайн и ревью проходят по обычным правилам команды, агент ждёт замечаний.
На каждом шаге агент пишет в журнал вызовов, что именно тронул: ветку, файлы, комментарии. При возврате задачи на доработку он читает замечания, правит ветку и обновляет summary. Цикл идёт без участия разработчика, пока замечание касается кода; когда оно касается смысла, решение возвращается человеку.
Точка, где контур чаще всего спотыкается на старте, — качество входной карточки: у задачи без критериев приёмки агент вынужден гадать об ожиданиях, и даже аккуратный diff попадает мимо. Поэтому шаблон карточки с критериями приёмки обязателен для классов задач, которые идут агенту, и значительная часть споров «так это же очевидно» исчезает ещё до появления кода.
Шаблон merge request работает как контракт: в нём поля «что изменено», «как проверено», «что осталось», ссылка на задачу. Агент заполняет все поля, а пустое поле — повод вернуть черновик до ревью по существу, ещё до того как ревьюер потратит на него время.
Проверка diff
Diff — точка, где человек тратит несколько минут и решает, жить правке или вернуться на доработку. Ревьюер смотрит три вещи: соответствие задаче, файлы за пределами заявленной области, обработку ошибок. Всё остальное — линтеры, тесты, стилистика — должно быть закрыто автоматикой до появления diff у человека. Полезная привычка команды: агент сам прикладывает к MR краткое резюме замечаний прошлого цикла и ответы на них, тогда ревьюер проверяет дельту, а всю историю с нуля перечитывать нет нужды. Вторая привычка касается масштаба: агенту выдают задачи с небольшими изменениями, пока статистика чистых закрытий устойчива. Крупные переписывания остаются людям: цена ошибочной догадки модели там сопоставима с ценой разработки.
Лучше всего подходят мелкие правки, обновление зависимостей и типовые рефакторинги: результат предсказуем, ревью быстрое. Агенту — чтение и ветки, прямой пуш закрыт. Комментарии в обсуждениях добавляйте, когда десяток задач подряд прошёл ревью.
Выбор первого класса задач задаёт темп всему внедрению: чем предсказуемее результат, тем короче путь до первого доверия к diff агента.
С каких задач начнёте делегировать GitLab-рутину агенту?
Соседние сценарии
GitHub-вариант той же механики разобран в статье про подключение репозитория GitHub к агенту. Общий каркас один: чтение сразу, запись через черновики, слияние через ревью. Различаются инструменты и привычки платформы: здесь это work items, pipeline и шаблоны MR. Конфигурации агента под разные хостинги храните раздельно, а промпт с ритуалом сдачи — общий.
- Держите описания инструментов короткими и глаголами: «создать ветку», «прочитать задачу», «открыть черновик MR».
- Лишние наборы инструментов отключайте: агент пользуется тем, что видит, а видит он только включённое.
- Раз в месяц сверяйте журнал с картой прав: любой инструмент, которым агент пользуется редко, удаляйте из набора для сокращения поверхности ошибок.
- Ведите список проектов, где агенту разрешено работать: новый проект попадает туда после проверки шаблонов и защищённых веток.
Состав работ и этапы внедрения такого контура описаны на странице про ИИ-агентов для бизнес-процессов. Откат и проверка агентов перед расширением прав раскрыты в материале про тестирование агентов.