Перейти к содержимому
AI-агенты

Код-ревью через MCP — почему агент отвечает мнением вместо проверки

15 мин Продвинутый Проверено 28.08.2026

Коротко

Что это меняет

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

Что сделать

Перезапустите сессию и попросите агента вызвать get_team_rules и показать ответ. Вызова в протоколе нет — чините разрешение и файл инструкций проекта, а не промпт

Проверить вызов инструмента

Код-ревью через MCP — почему агент отвечает мнением вместо проверки

Агент дописал фичу и отчитался: «прогнал ревью, замечаний нет». Код-ревью через MCP при этом не запускалось ни разу — сервер подключён, но клиент не спросил разрешения на вызов, и агент выдал собственное мнение о коде вместо проверки.

Отличить одно от другого можно ровно в одном месте — в протоколе вызовов. Ответ выглядит одинаково: тот же тон, те же формулировки, иногда даже верная находка.

Что делает ревьюер прямо в цикле агента

ReviewGate поднимает MCP-сервер поверх той же самой политики, по которой потом проверяет пул-реквест бот. Инструментов два: review_changes проверяет текущие изменения, get_team_rules отдаёт командные стандарты до того, как код написан, а не постфактум в виде замечаний.

Правила лежат в .reviewgate/config.yml в репозитории и версионируются вместе с кодом — соглашения описываются обычными фразами, а не регулярками, этим ревью и отличается от линтера. Домашний конфиг задаёт только адрес и ключи: политику из чужого клона подменить нельзя.

Ставится одним бинарником без Node и Docker. В релизе CLI 2.0.4 от 22 августа 2026 года шесть сборок: macOS на Apple Silicon и Intel, Linux x86-64 и ARM64, отдельная musl-сборка для Alpine и Windows x64. Рядом лежит SHA256SUMS — суммы на сайте и в релизе на GitHub совпадают, и проверить их стоит: вы запускаете скачанный из сети исполняемый файл.

Почему клиент молча пропускает вызов

Барьера два, и оба тихие. Первый: многие клиенты, включая Claude Code, грузят описания MCP-инструментов лениво. В начале сессии агент видит имя сервера, но не его инструменты, и просто не догадывается их позвать. Лечится двумя строками в файле инструкций проекта:

Стандарты этого проекта берутся из инструмента mcp__reviewgate__get_team_rules —
вызывай его ДО написания кода, вместо чтения ADR руками.

Перед завершением задачи и перед git push проверяй изменения инструментом
mcp__reviewgate__review_changes.

Разница измерима. На проекте с восемью ADR агент без этих строк потратил около трёх минут на чтение документов и кода руками; с ними позвал get_team_rules на шестнадцатой секунде и получил тот же ответ вдвое дешевле — замер вендора, независимых проверок я не нашёл.

Второй барьер — разрешение на вызов. MCP-инструменты это сторонний код, и при первом обращении клиент спрашивает человека. В обычной сессии вы жмёте «разрешить», и дальше всё работает. В неинтерактивном прогоне — claude -p, скрипт, CI — диалог показать негде и нажимать некому. Агент на отказе не останавливается.

«Если в ответе агента нет вызова инструмента, ревью не было, как бы этот ответ ни выглядел», — формулирует документация ReviewGate.

Как понять, что код-ревью через MCP не запускалось

Смотреть надо не на текст ответа, а на факт вызова. Конфигурационные файлы проверять бесполезно: у каждого клиента свой формат, и наличие записи не означает, что вызов произойдёт. Достаточно попросить агента позвать get_team_rules и показать, что вернулось — инструмент бесплатный и модель не дёргает.

Признаки, что проверки не было:

  • В протоколе сессии нет строки вызова mcp__reviewgate__review_changes или mcp__reviewgate__get_team_rules, хотя агент отчитался о ревью.
  • Агент честно пишет, что ждёт разрешения, — и следующим сообщением всё равно выдаёт разбор кода.
  • Замечания не ссылаются ни на одно из ваших правил из .reviewgate/config.yml: находки общие, про best practices, без пометки о командном стандарте.
  • Вы правили конфигурацию клиента и проверили её в той же сессии. Клиенты читают конфиг при старте, так что проверка без перезапуска покажет либо ложный отказ, либо успех от прошлой настройки.
  • Прогон закончился за секунды. Полный проход с судьёй — это минуты, а не мгновение.
  • В консоли Windows вместо отчёта каша из символов — не признак пропуска, но сигнал выполнить chcp 65001; на --json это не влияет, stdout всегда UTF-8.

Что сделать сейчас

Пятнадцать минут, по порядку:

  • Скачайте бинарник под свою платформу и сверьте контрольную сумму с SHA256SUMS. Для Linux не перепутайте glibc и musl: на чужой системе файл просто не стартует.
  • Выполните reviewgate doctor — он называет источник каждого значения и живьём проверяет эндпоинт модели, не тратя токенов.
  • Пропишите сервер в клиенте: {"mcpServers": {"reviewgate": {"command": "reviewgate", "args": ["mcp"]}}}. Ручную правку можно не делать — команда reviewgate help agent-setup печатает инструкцию, написанную для агента, и он переложит её в формат своего окружения.
  • Добавьте две строки про инструменты в CLAUDE.md или .cursorrules. Без них сервер подключён, но невидим.
  • Перезапустите сессию и попросите агента вызвать get_team_rules и показать ответ. Вызов виден в протоколе — цепочка собрана.
  • Для неинтерактивных прогонов один раз выдайте разрешение в обычной сессии либо перечислите инструменты флагом --allowedTools при старте.

Имена инструментов собираются из имени сервера в вашей конфигурации: назовёте сервер reviewgate — получите mcp__reviewgate__review_changes. Если у вас несколько клиентов на одной машине, полезно заранее решить, куда класть инструкцию для агента — в правило, навык или хук: место сильно меняет, сработает строка или нет.

Сколько стоит полный прогон и когда включать fast

Судья — второй проход, который перепроверяет каждую находку по целым файлам и может только понижать важность. По замеру вендора он добавляет к стоимости прогона 35–47 %. Поэтому гейт вешают на пуш, а не на каждый ответ агента: экономить надо на частоте вызова, а не на глубине проверки.

Порядок величин с их же замера: изменение в двух файлах, ансамбль из двух генераторов и арбитр — 6,5 минуты и около 0,6 доллара. Тот же диф в режиме --fast (один генератор, без судьи) — полторы минуты и вчетверо дешевле, но находки никем не подтверждены и шума больше.

Порог блокировки по умолчанию выключен: severity_gate: off, и без явного --fail-on команда возвращает ноль, что бы она ни нашла. Коды детерминированы: 0 — гейт пройден или выключен, 2 — есть находки на уровне порога и выше, 1 — сбой самого ревью. Если строите гейт на коде возврата, различайте двойку и единицу: сломанный ревьюер не должен запирать разработчика в ветке.

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

Источники