SberDevices раскрыла детали собственной системы ИИ-агентов для фронтенда
Инженеры SberDevices рассказали, как построили внутреннюю систему ИИ-агентов для фронтенд-разработки: сочетание агентного цикла и детерминированного workflow, парсер для сужения контекста модели и статистику ошибок от ИИ-ревьюера. Решение создано вместо внешних сервисов, чтобы не отдавать код наружу.
Первоисточник: habr.com
Инженер по инфраструктуре фронтенда SberDevices (в публикации она представляется как Аврора) описала внутреннюю систему ИИ-агентов для фронтенд-разработки. Компания не стала подключать внешние сервисы код-ревью и построила собственное решение, чтобы не открывать исходный код сторонним платформам. В материале разобраны архитектура, подход к подаче контекста модели и статистика ошибок, которую собирает ИИ-ревьюер.
Зачем SberDevices понадобились собственные ИИ-агенты
По словам автора, крупные компании при внедрении AI-агентов в разработку чаще идут своим путём и создают решение под собственные процессы. Для SberDevices это способ упростить работу фронтенд-команд и при этом сохранить контроль над кодовой базой.
Почему не подошли внешние решения
На рынке есть готовые инструменты: у GitHub — GitHub Copilot Code Review, у GitVerse — GigaCode Agent. Однако, как отмечает автор, использовать их нельзя: это внешние решения, которым не хочется открывать свой код. Именно это ограничение стало причиной разработки внутренней системы.
Два подхода: агентный цикл и детерминированный workflow
В SberDevices скомбинировали две модели работы. В агентном цикле модель получает цель и набор инструментов и сама выстраивает шаги для её достижения. В детерминированном workflow модель выполняет отдельные ограниченные задачи по заранее заданному сценарию. Сочетание позволяет гибко решать сложные задачи и при этом держать предсказуемость там, где она важна.
| Подход | Как работает | Когда применяется |
|---|---|---|
| Агентный цикл | Модель получает цель и инструменты, сама планирует шаги | Задачи, требующие гибкости и выбора действий |
| Детерминированный workflow | Модель выполняет отдельные ограниченные задачи по сценарию | Шаги с предсказуемым и повторяемым результатом |
Как устроен парсер для сужения контекста модели
Отдельное внимание в материале уделено парсеру, который сужает контекст, передаваемый модели. Вместо того чтобы отдавать агенту весь объём кода, система выделяет релевантный фрагмент — это снижает шум в запросе и делает работу модели точнее.
- Парсер сокращает объём данных, попадающих в контекст модели.
- Сужение контекста помогает агенту сосредоточиться на релевантном участке кода.
- Подход применяется как часть общей архитектуры системы агентов.
AI-ревьюер: статистика ошибок фронтендеров
В публикации приведена статистика ошибок фронтендеров, собранная ИИ-ревьюером. Это одна из тем материала: система не только помогает в работе, но и накапливает данные о типичных проблемах в коде.
Самая востребованная функция системы
Автор отмечает, что одна из функций системы оказалась самой востребованной — причём, по её формулировке, внезапно. Конкретная функция в исходном описании не раскрыта, поэтому детали стоит смотреть в полном материале на Хабре.
Итоги и планы развития
SberDevices продолжает развивать внутреннюю систему агентов для фронтенда. Опубликованный материал — это разбор уже работающего решения: от мотивации отказа от внешних сервисов до конкретных механизмов вроде парсера контекста и ИИ-ревьюера.
Почему SberDevices не использует GitHub Copilot Code Review или GigaCode Agent?
По словам автора, это внешние решения, которым не хочется открывать свой код. Поэтому компания построила внутреннюю систему агентов.
Чем агентный цикл отличается от детерминированного workflow?
В агентном цикле модель получает цель и инструменты и сама планирует шаги. В детерминированном workflow она выполняет отдельные ограниченные задачи по заданному сценарию.
Зачем нужен парсер контекста?
Он сужает объём данных, передаваемых модели, чтобы агент работал с релевантным фрагментом кода и меньше шумел в запросе.
Что собирает ИИ-ревьюер?
Он даёт статистику ошибок фронтендеров — данные о типичных проблемах в коде, которые система накапливает в процессе работы.