Рефакторинг агентного узла: чему учит сравнение LLM

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

Идея сравнить несколько LLM на такой задаче полезна именно практичностью. Модель просят не написать игрушечный пример, а предложить, как распутать реальный узел LangGraph-агента. Затем разные модели оценивают предложения друг друга, а результат анализируется несколькими способами. Это хороший сценарий для команды, которая уже использует AI-инструменты в разработке, но не хочет превращать архитектурные решения в голосование самых уверенных автодополнений.

Почему god node опасен в агентных системах

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

Основные симптомы такого узла:

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

Для LLM такая задача выглядит соблазнительно: можно предложить разбиение на классы, выделить стратегии, добавить роутеры, состояния и интерфейсы. Но красивое описание ещё не означает, что рефакторинг действительно снизит связанность.

Что стоит оценивать в ответах моделей

При сравнении моделей важно смотреть не только на то, насколько предложение звучит архитектурно. Хороший план реорганизации должен быть проверяемым. Если модель предлагает «разбить на модули», но не объясняет, какие инварианты остаются в каждом модуле и как мигрировать без остановки разработки, пользы мало.

Практичные критерии оценки выглядят так:

Границы ответственности

Предложение должно отделять принятие решений от исполнения. Например, один слой может готовить контекст и нормализовать состояние, другой — выбирать маршрут, третий — вызывать инструменты или LLM, четвёртый — записывать результат. Чем яснее границы, тем проще покрыть их тестами и менять независимо.

Сохранение поведения

Рефакторинг god node опасен тем, что ломает редкие ветки. План должен предусматривать characterization tests: сначала фиксируем текущее поведение на реальных сценариях, а уже потом меняем структуру. Если модель сразу переписывает всё «как правильно», это риск.

Пошаговая миграция

Для production-агента лучше инкрементальный подход: вынести одну группу условий, добавить адаптер, переключить один маршрут, сравнить результаты, затем двигаться дальше. Полная замена узла за один PR может выглядеть эффектно, но усложняет ревью и rollback.

Работа с состоянием

В LangGraph и похожих фреймворках состояние — центральный контракт. Хороший ответ должен явно учитывать, какие поля читаются, какие изменяются, где появляются side effects и что происходит при ошибке. Если модель предлагает новые абстракции, но размывает контракт состояния, технический долг просто переезжает в другое место.

Наблюдаемость

После разбиения узла важно не потерять трассировку. Нужны понятные события, correlation id, логирование решений маршрутизатора и метрики ошибок по новым компонентам. Иначе команда получит более «чистый» код, но менее понятную эксплуатацию.

Почему взаимная оценка моделей не заменяет инженерное ревью

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

Для инженерной практики это означает, что LLM можно использовать как набор независимых reviewers, но финальное решение должно проходить через локальные ограничения проекта:

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

Иными словами, модель может предложить варианты, но она не знает цену сопровождения в вашей команде, если эту цену явно не описать в задаче.

Как применить такой подход в своей кодовой базе

Если в проекте есть крупный узел агентного графа, можно провести похожую проверку без сложной исследовательской инфраструктуры.

Выберите один проблемный узел и подготовьте минимальный контекст: код, схему состояния, список маршрутов, известные боли.
Попросите несколько моделей предложить план рефакторинга, но запретите писать финальный код до согласования архитектуры.
Попросите каждую модель критиковать не свой ответ, а ответы других моделей по заранее заданным критериям.
Сведите предложения в таблицу: границы, миграция, тесты, риски, сложность внедрения.
Выберите не самый красивый вариант, а тот, который можно безопасно внедрить маленькими PR.
Перед изменениями зафиксируйте текущее поведение тестами и логами на реальных сценариях.

Такой процесс не делает LLM архитектором, но превращает её из генератора патчей в инструмент для проектного анализа. Это особенно полезно для homelab- и backend-проектов, где агентная логика часто растёт быстрее, чем документация.

Главный вывод

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

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