Бот для рассмотрения pull-запросов с открытым исходным кодом: LangGraph, Node.js и GitHub Webhooks

Запросы на внесение изменений накапливаются практически в каждой команде. Обычно только старшие инженеры замечают тонкие проблемы: запросы типа N+1, жестко закодированные секреты, крайние случаи, которые никто не рассмотрел. К тому же они самые занятые сотрудники, поэтому ревью проводятся в спешке или откладываются, но в любом случае что-то всё равно пройдет.

Инструменты для ревью в области коммерческого ИИ как правило имеют закрытый исходный код или являются дорогими, часто и то, и другое одновременно. Альтернативой может быть бот, который небольшая команда может запустить в своих собственных репозиториях, без отправки кода в «черный ящик». Приведенная ниже концепция — это бот с открытым исходным кодом, который отслеживает новые запросы на внесение изменений в GitHub, рассматривает каждый из них с помощью многоэтапного агента LangGraph и публикует конкретные замечания на уровне строк в виде комментариев к запросу.

Что происходит при открытии PR

1. Webhook GitHub передает событие.
2. Через Octokit API GitHub загружает различия между версиями кода.

Агент LangGraph пошагово анализирует код на предмет проблем безопасности, производительности и архитектурных недостатков.

Бот публикует комментарий к pull-реквесту с рекомендациями, указывающими на конкретные строки кода.

Результаты анализа сохраняются в базе данных, поэтому со временем накапливается история проверок.

Именно пошаговый подход является ключевым. Одно запрос к ИИ с просьбой «проанализировать этот код» обычно даёт расплывчатые, общие замечания. Разделение задачи на проверку безопасности, производительности и архитектуры позволяет получить более точные результаты, поскольку каждый этап имеет чёткую задачу.

Технологическая стек

База данных PostgreSQL для хранения истории ревью Интеграция с GitHub Octokit Webhooks Express middleware с проверкой подписи

Технологическая стек остается близким к тому, что уже используют большинство команд на Node.js. Целью не было продемонстрировать новую фреймворковую среду — важнее было создать что-то, что команда может разместить и в чем сможет быть уверена.

Поток и структура

Пайплайн работает следующим образом: от открытого PR через проверенный webhook в агента, а затем обратно в виде комментария:

GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Каждая проверка в потоке LangGraph представляет собой отдельный узел. Команда может тестировать, настраивать или отключать отдельные проверки, не влияя на остальные, что полезно, когда людям важны только результаты проверок безопасности, а не мнения по архитектуре для каждого PR.

Два фрагмента кода, которые стоит показать

Во-первых, проверка подписи webhook. Без неё любой, кто узнает URL webhook, может отправлять фальшивые события и запускать ложные проверки:

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

Он крошечный, но его пропуск — распространённая ошибка в инструментах, работающих с webhook’ами.

Во-вторых, структура LangGraph состоит из отдельных узлов, а не из одного большого запроса:

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

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

Что сработало

• Разделение проверки на отдельные этапы по безопасности, производительности и архитектуре обеспечило гораздо более четкие и конкретные отзывы по сравнению с объединенным запросом. Это стало самым значительным улучшением качества во всем проекте.
• Проверка подписей webhook с самого начала означала, что безопасность была частью дизайна, а не чем-то, что добавлялось позже.
• Хранение истории проверок в PostgreSQL, даже в упрощенном виде, позволило позже выявить определенные закономерности, например, какие типы проблем постоянно возникали в различных PR-запросах.

Что оставалось сложным

• Ложные положительные результаты — неизбежная часть процесса. Системы анализа на основе больших языковых моделей иногда выделяют то, что на самом деле не является проблемой, и документация должна открыто об этом сообщать. Доверие важнее, чем впечатляющий список функций.
• Расходы растут по мере использования. Три вызова большой языковой модели на каждую заявку на ревью дают более точные результаты, чем один вызов, но они стоят дороже и занимают больше времени. Небольшой команде необходимо найти баланс между качеством анализа и финансовыми возможностями.
• Чтобы комментарии выглядели так, будто их написал человек, потребовалось больше итераций с использованием промптов, чем для разработки логики LangGraph. Комментарии должны быть краткими, конкретными и сопровождаться номером строки, ведь никто не будет читать пятипараграфное эссе ИИ в треде заявки на ревью.

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

Попробовать локально

Репозиторий легко запустить. Клонируйте его, установите зависимости и запустите разработческий сервер:

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

В документе README описан полный процесс настройки, переменные среды и способы подключения webhook от GitHub. Отзывы о ложных срабатываниях или идеи по улучшению работы LangGraph — именно такие сообщения больше всего помогают.