Мы долго пытались обмануть вероятностную природу языковых моделей. Разработчики писали «мега-промпты» на тысячи токенов, с маниакальным упорством описывая каждое исключение, каждый краевой случай и жесткий формат JSON на выходе. Идея казалась логичной: чем точнее инструкция, тем лучше результат.
На практике этот подход быстро уперся в физику трансформеров. Когда контекст перегружен противоречивыми правилами, механизм внимания (attention) размывается. Модель начинает игнорировать инструкции из середины текста, ломает синтаксис ответа или скатывается в галлюцинации при малейшем отклонении входных данных. Монолитный промпт — это хрупкая конструкция. Любое изменение бизнес-требований заставляет переписывать его целиком, а тестирование превращается в шаманство.
Осознание этой проблемы заставило инженеров пересмотреть роль LLM в системе. Языковая модель — не всезнающий решатель задач. Это просто модуль нечеткой логики. Чтобы решать реальные задачи, этому модулю нужен жесткий детерминированный каркас. Так произошел переход от промпт-инжиниринга к агентной архитектуре и выстраиванию workflow.
От генерации к оркестрации: Tool Use
Если один промпт не справляется, задачу нужно дробить. Вместо того чтобы просить модель «проанализируй лог сервера, найди причину падения и напиши отчет», мы выстраиваем цепочку вызовов.
Но настоящий прорыв случился не с появлением цепочек (chains), а с массовым внедрением Tool Use (Function Calling). Модель получила возможность не просто генерировать текст, а прерывать генерацию, чтобы запросить данные из внешнего мира или выполнить конкретное действие.
Рассмотрим классический пример обработки инцидента. В эпоху мега-промптов мы бы пытались скормить модели сырой дамп логов и документацию в одном гигантском запросе. В агентной архитектуре процесс выглядит иначе:
- Агент получает краткую задачу: «Разберись с ошибкой 500 на сервере базы данных».
- Агент использует инструмент
execute_bash, чтобы запуститьgrepпо свежим логам. - Получив вывод (Observation), агент понимает, что упал процесс MySQL из-за нехватки памяти (OOM).
- Агент использует инструмент
query_metrics, чтобы запросить график использования RAM за последний час. - Собрав факты, агент формирует финальный ответ и предлагает применить инструмент
restart_service.
Это паттерн ReAct (Reasoning and Acting). Модель постоянно чередует внутренние рассуждения с вызовом внешних функций. Контекстное окно теперь служит не хранилищем всех знаний мира, а оперативной памятью (scratchpad), куда записываются промежуточные результаты работы инструментов.
Анатомия рабочего процесса
Агентная архитектура требует совершенно иного подхода к написанию кода. Разработчик больше не пишет текст промпта, он конструирует среду обитания агента. Эта среда состоит из нескольких слоев.
Во-первых, диспетчер состояния. Агент может зациклиться, вызывая один и тот же инструмент с ошибочными параметрами. Код должен отслеживать количество итераций, принудительно обрывать цикл и возвращать модели сообщение об ошибке формата, заставляя ее скорректировать запрос.
Во-вторых, система инструментов. Каждый инструмент (буть то поиск по кодовой базе, вызов внешнего API или SQL-клиент) должен иметь строгую JSON Schema с детальным описанием входных параметров. Модель ориентируется исключительно на эти метаданные. Если в description функции get_user_orders не указано, что user_id — это UUID, а не числовое значение, модель неизбежно передаст неверный тип данных.
В-третьих, управление памятью. Длинные цепочки размышлений быстро съедают лимит токенов. Агенту нужны механизмы компрессии контекста: сворачивание старых шагов в краткие резюме, выгрузка сырых данных во внешнее хранилище, откуда агент забирает только выжимку.
Интеграционный ад и зоопарк моделей
Сложные workflow быстро выявляют еще одну архитектурную проблему: для разных узлов системы требуются разные модели.
Мощные модели вроде Claude 3.5 Sonnet или GPT-4o обладают отличными способностями к планированию и написанию кода, но их вызов стоит дорого, а задержка ответа (latency) слишком высока для простых задач. Для промежуточных этапов — классификации входящего запроса, парсинга структурированных данных из текста или базового роутинга — логичнее использовать быстрые и дешевые модели, такие как Llama 3 или Claude 3.5 Haiku.
В этот момент архитектура превращается в зоопарк. Разные провайдеры используют разные SDK. У Anthropic свой формат описания инструментов и обработки потокового ответа. У OpenAI — свой. Переключение логики агента с одной модели на другую требует переписывания транспортного слоя, изменения парсеров и логики обработки ошибок. Разработчики тратят ресурсы на поддержку бесконечных API-оберток вместо того, чтобы развивать бизнес-логику самих агентов.
RouterAPI: Единая точка входа
Решением этой интеграционной проблемы становится виртуализация LLM-эндпоинта. Вместо того чтобы вызывать API конкретных провайдеров напрямую из кода агента, система обращается к единому шлюзу. В нашей архитектуре эту роль выполняет RouterAPI.
Суть подхода заключается в том, что весь агентный фреймворк работает поверх единого OpenAI-совместимого интерфейса. С точки зрения кода агента ничего не меняется: он использует стандартную библиотеку OpenAI (например, для Python или Node.js), отправляет привычный массив сообщений messages и список инструментов в формате tools.
RouterAPI берет на себя всю тяжелую трансляцию. Шлюз анализирует параметр model. Если запрошена модель Anthropic, RouterAPI на лету конвертирует системные промпты, преобразует OpenAI-формат инструментов в Anthropic Tool Use XML/JSON, обрабатывает запрос к upstream-серверу и транслирует специфические Server-Sent Events обратно в стандартные чанки OpenAI.
Такой подход дает радикальную гибкость. Замена "мозга" агента сводится к изменению одной строковой переменной в конфигурации. Разработчик может перенаправить запросы локальной агентой утилиты на корпоративный инстанс, на внешний шлюз резервный провайдер или на локально развернутую модель через vLLM — и ни одна строчка логики инструментария не сломается.
Шлюз также закрывает критические вопросы observability и биллинга. Когда в системе работают десятки автономных агентов, генерирующих тысячи запросов в минуту, прямой доступ к API провайдеров превращается в финансовую черную дыру. Единый шлюз обеспечивает централизованный учет токенов, балансировку нагрузки, автоматические ретраи при падении провайдера (fallback) и логирование всех вызовов инструментов для последующей отладки.
Инварианты архитектуры
Эволюция от промпта к агенту фиксирует новый инженерный статус-кво. Языковая модель перестала быть самостоятельным продуктом, который решает бизнес-проблему по щелчку пальцев. Она интегрировалась в архитектуру как специфический вычислительный примитив — процессор, работающий с естественным языком и способный к нечеткому роутингу.
Ценность системы теперь определяется не тем, насколько хитроумный текст вы передаете в API. Она определяется тем, какие инструменты вы предоставили модели, как настроили цикл обратной связи и насколько надежно ваш шлюз маршрутизирует эти потоки вычислений. Промпт лишь дает стартовый контекст, но итоговый результат определяет архитектура.
***