Агенты LLM

Инфляция архитектурных слоёв.

1. Проблема: «Бредящий LLM» и попытки его обуздать

Когда мы даем LLM (Large Language Model) задачу «напиши код», она действует как стохастический попугай — генерирует наиболее вероятную последовательность токенов. В сложных, многосвязных системах эта вероятность приводит к "галлюцинациям" ии.

Индустрия, столкнувшись с этим, пошла по пути бюрократизации кода:

1. Агент 1 пишет код, но регулярно бредит.
2. Чтобы исправить ошибки, создают Агента 2 (Ревьюера), который проверяет код Агента 1. Ревьюер тоже может ошибаться.
3. Чтобы управлять спором, создают Агента 3 (Менеджера/Оркестратора), который решает, кого слушать.
4. Чтобы Агент 3 не забыл контекст, подключают векторную базу данных (RAG), что создает еще один слой абстракции.
5. ...

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

2. Математический подход: Управляющий код + LLM как заплатка

Принцип разделения ответственности (Separation of Concerns), .

Математически это можно представить так:

• Управляющий код (Инвариант): Это детерминированная функция fдет(x). Она строга, предсказуема и доказуема (насколько это возможно в программировании). Это каркас, скелет системы. Её работа описывается булевой алгеброй и классической логикой.
• LLM (Вариативная часть): Это функция fвер(x), которая возвращает результат с некоторой вероятностью ошибки Perr​. Она идеальна для задач, где нет строгой формализации: написание шаблонного кода, парсинг человеческого текста, генерация описаний.

Идеальная архитектура (с точки зрения вашей логики):
Структура жестко задана управляющим кодом. LLM вставляется в строго определенные слоты (интерфейсы), где его задача — заполнить конкретный, узкий участок.
LLM не управляет процессом, а лишь выполняет функцию преобразования данных. Если LLM «сбредит», управляющий код поймает это на этапе валидации, не запуская рой других агентов.

3. Причины хайпа

Почему индустрия строит «фабрики агентов»?

1. Иллюзия универсальности (No-Code/Low-Code эффект): Агентские фреймворки продают идею «просто скажи, что тебе нужно». Бизнес хочет верить, что программисты больше не нужны. Создание жесткого управляющего кода требует программиста. Создание роя агентов требует только промпт-инженера. Это дешевле на старте (но дороже в поддержке).
2. Страх упустить контекст: Разработчики боятся, что жесткий код «задушит» гибкость LLM. Им кажется, что если дать LLM свободу (в виде агента), он сможет решить любую нестандартную ситуацию. На практике он создает еще больше нестандартных ситуаций.
3. Маркетинг: Термины «Multi-Agent Systems», «Оркестрация», «Автономные агенты» звучат гораздо дороже и инновационнее, чем «Вызов функции».

4. Вывод: Синтез подходов

Будущее (и настоящее, для сложных систем) именно за гибридным подходом:

• Управляющий код — это мозжечок системы. Он отвечает за баланс, ритм, базовые рефлексы (транзакции, безопасность, типы данных).
• LLM/Агенты — это кора головного мозга, отвечающая за распознавание образов и генерацию контента.

Хайп на «агентских скиллах» — это текущая попытка заставить кору головного мозга выполнять функции мозжечка. Это работает в демо-режиме, но падает в продакшене. Математически строгий подход победит, потому что он единственный обеспечивает контролируемость и масштабируемость системы.

Выгоднее писать управляющий типобезопасный код, который простым кодом заполнят агенты - сама структура кода будет отсекать агентам лишние степени свободы.