Добавление AI-агентов в микросервисы Spring Boot с использованием Spring AI

Представьте три микросервиса Spring Boot, уже обрабатывающие трафик в производстве: на разработку функций агентов ушло шесть недель, два из них были выпущены без проблем, а третий превратился в долгий и дорогостоящий урок. Эта ситуация, отражающая опыт многих команд, работающих с Java, лежит в основе дальнейшего изложения. В нем рассматривается практический способ интеграции агентных пайплайнов в существующие сервисы с ограничениями по задержкам, зависимостями между командами и реальными пользователями; материал предназначен для инженеров, работающих с Java-бэкендом, знакомых с Spring Boot и желающих добавить возможности ИИ, не теряя при этом существующую архитектуру.

В следующих разделах рассматривается, что на самом деле представляет собой ИИ-агент в среде Spring Boot (и что он не является), почему команды его внедряют, как использовать Spring AI для вызова инструментов, три типа сбоев, которые обычно возникают только после запуска в производство, и как рассматривать потребление токенов как важный операционный показатель.

Что такое агент и чем он не является

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

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

Цикл состоит из четырех компонентов:

• Модель — это механизм рассуждений, будь то GPT-4o, Claude, Gemini или аналог с открытым исходным кодом, запущенный через Ollama.
• Инструменты — это функции, API или вызовы сервисов, которые модель имеет право использовать.
• Цикл — это многократный процесс, который отделяет агента от одного вызова большой языковой модели.
• Контекст — это постоянно растущий набор истории разговоров, результатов работы инструментов и инструкций, который используется на каждом этапе логических рассуждений.

В микросервисе Spring Boot это означает, что вы не создаёте обёртку в стиле RestTemplate вокруг конечной точки ИИ. Вы встраиваете многоэтапный, имеющий состояние и недетерминистичный рабочий процесс в сервис, предназначенный для ограниченной, синхронной и предсказуемой обработки. Именно из-за этого несоответствия возникают проблемы при интеграции ИИ в Java-приложения. Короткий способ запомнить это: инструмент — это не агент, агентом является цикл, и пока вы этого не поймёте, вы будете создавать конечные точки, а не агентов.

Причины использования агентов в сервисах Spring Boot

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

За пределами фиксированных правил

Классические микросервисы автоматизируют известные процедуры, при которых входные данные A проходят через набор правил B, чтобы получить выходные данные C, и это отлично подходит для детерминированных потоков. Агенты расширяют эту концепцию на неоднозначные, многократные задачи, в которых правильное следующее действие зависит от промежуточных результатов. Некоторые примеры, соответствующие существующим архитектурам Spring Boot:

• Обработка заказов. Один агент проверяет запасы, оценивает правила ценообразования, применяет скидки для конкретных клиентов и формирует рекомендацию по выполнению заказа в рамках одного запроса, так что фронтенду не нужно организовывать четыре последовательных вызова.
• Document understanding. An agent reads an uploaded PDF, extracts structured fields, validates them against business rules and either confirms or hands the case to a human reviewer, with no hardcoded extraction rules.
• Customer support. Inside an existing support service, an agent pulls account state, order history and policy documents and drafts a contextually accurate reply, which cuts handling time without removing the human from the loop.
• Code review and CI help. In a platform engineering pipeline, an agent analyzes failing tests, consults internal documentation and proposes targeted fixes.

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

Почему Spring Boot подходит для этой задачи

Python доминирует в учебных материалах по ИИ, в то время как Java преобладает в корпоративных производственных системах, и разница между ними представляет собой реальную возможность. Spring Boot обеспечивает структурные преимущества, которых нет у легковесных фреймворков Python из коробки:

• Внедрение зависимостей позволяет эффективно управлять компонентами, тестировать их и комбинировать без дополнительной настройки.
• Actuator и Micrometer преобразуют данные об использовании токенов, задержках между действиями агентов и уровнях ошибок инструментов в стандартные операционные метрики.

Асинхронные примитивы, такие как @Async и CompletableFuture, хорошо справляются с циклами агентов, время выполнения которых варьируется.

Resilience4j оборачивает вызовы инструментов механизмами защиты от сбоев и повторных попыток, предотвращая каскадные сбои.

Spring Security позволяет интегрировать механизмы аутентификации и авторизации для конечных точек инструментов, предназначенных для агентов, в существующую систему контроля доступа.

Готовые инструменты для операций означают, что существующие решения, такие как Prometheus, Grafana или Datadog, могут расширяться для сбора метрик агентов без необходимости создания новой инфраструктуры.

Кроме того, Spring AI предоставляет клиенты для больших языков моделирования, интеграцию с хранилищами векторов и возможность вызова функций с использованием аннотации @Tool в рамках одной экосистемы, поэтому для создания агента производственного уровня не требуется отходить от подходов Spring.

Когда агент оправдан

Агенты находят своё применение в следующих случаях:

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

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

Бизнес-аргументы простыми словами

Для руководителей инженерных команд и заинтересованных сторон продукта аргументация основывается на трех ключевых факторах:

1. Более быстрая реализация новых функций. Функции, реализация которых раньше требовала недель работы над кодом для оркестрации на стороне сервера, теперь часто могут быть прототипированы за несколько дней, если агент берет на себя многократную координацию. Команды обычно отмечают такое ускорение после первой успешной интеграции, хотя цифры могут отличаться.
2. Более простое обслуживание правил. Каждое жестко заданное правило в сервисе представляет собой «долг», который увеличивается при изменениях бизнес-логики, причем инструкции, написанные на естественном языке, как правило, легче обновлять, чем код, выражающий ту же логику императивным способом.
3. Основа для сложных ИИ-систем. Один хорошо интегрированный агент служит основой для многопроцессных рабочих процессов, конвейеров генерации с усилением через поиск информации и функций продуктов, разработанных с учетом особенностей ИИ.

Почему такая срочность и смена модели выполнения

В течение 2023 года и в 2024 году использование ИИ в Java означало в основном отправку запроса на конечную точку LLM и получение любого текста, который там был сгенерирован: простой HTTP-запрос через WebClient, установка таймаута и никаких дополнительных действий.

Эта модель больше не актуальна. Набор функций Spring AI (вызов инструментов и функций, интеграция с хранилищем векторов и API ChatClient, разработанного с учётом агентных рабочих процессов) свидетельствует о том, что сама модель выполнения изменилась.

• В старой модели существовал один запрос, ведущий к одному вызову большой языковой модели и одному ответу.
• В новой модели запрос распадается на N вызовов инструментов и M шагов обработки, прежде чем появится единый ответ.

Многие инженеры Spring Boot по-прежнему используют старую модель и рассматривают ChatClient как RestTemplate. Такая категориальная ошибка приводит к сбоям в производстве спустя несколько недель после запуска, причём при их возникновении они редко бывают очевидными.

Цикл — это агент

Инженеры, впервые занимающиеся интеграцией агентов, обычно представляют себе сервис, заменяющий контроллер: один бин класса @Service, один внедряемый объект ChatClient — и всё готово. Это конечная точка автодополнения, а не агент. Настоящий агент выполняет цикл: получение задачи, выбор инструмента, его выполнение, получение результата, анализ нового состояния и принятие решения о продолжении работы или ответе. Модель представляет собой двигатель рассуждений внутри этого цикла; сам цикл и является агентом.

Почему традиционный подход неправильно оценивает затраты

Обычное предположение заключается в том, что вызов большой языковой модели — это дорогостоящая и сложная часть, а остальное обрабатывается обёрткой класса @Service из Spring. На самом деле «остальное» теперь распределено: скорость работы инструментов, состояние контекста от одного этапа к другому, способ распространения ошибок в многоэтапных процессах, а также необходимость повторных попыток при незавершённой работе.

Рассмотрим гипотетическую службу классификации заказов. Изначально она представляет собой один конечный пункт вида POST /orders/classify, выполняющий один вызов большой языковой модели. Затем она преобразуется в агента, который классифицирует заказ, вызывает инструмент управления запасами, вызывает инструмент определения цен в зависимости от наличия товара и возвращает рекомендацию по выполнению заказа. Каждый вызов инструмента — это реальный запрос к сервису с реальной задержкой.

Предположим, что агент обрабатывает 80% запросов менее чем за две секунды, тогда как для оставшихся 20% медленный внешний сервис управления запасами увеличивает время ответа до 8–14 секунд. Это не проблема искусственного интеллекта — это проблема распределенных систем, которую выявил цикл работы агента.

Упускаемый из виду компромисс

Цикл агента не является безсостоянийным. Результат каждого использования инструмента добавляется к ходу разговора и снова отправляется в модель в следующем туре. При высокой пропускной способности объем памяти, необходимый для обработки каждого запроса, растет с увеличением количества туров, которые проходит агент, при этом количество самих запросов становится менее важным фактором. Сервис, обрабатывающий 1 000 запросов в минуту при среднем количестве туров в четыре, фактически выполняет 4 000 вызовов больших языковых моделей, причем размер контекста увеличивается с каждым вызовом.

Поэтому перед написанием кода агента необходимо перечислить все вызовы инструментов, оценить задержку p95 для каждого из них и рассчитать максимально возможный размер контекста при наибольшем количестве туров. Сначала определите объем контекста, прежде чем проектировать цикл. Большинство сбоев агентов в Java-бэкендах на самом деле являются сбоями из-за истечения времени, маскирующимися под сбои модели.

Spring AI предоставляет инструменты, а не план

Spring AI — это серьезный слой абстракции, ориентированный на производственное использование. Он предоставляет ChatClient, ToolCallback, VectorStore и API для выполнения агентов, работающий с внедрением зависимостей, переключением моделей через application.properties и поддержкой реактивности с помощью Flux. В качестве отправной точки для интеграции больших языков моделирования в Spring Boot он является оптимальным выбором.

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

• Контракты на границе сервисов между агентом и последующими сервисами.
• Сохранение состояния агента между запросами, то есть работу сессионной памяти.
• Логику защиты от сбоев, затрагивающих несколько этапов обработки.

Возможность наблюдения на уровне рабочего процесса, например, понимание причин выбора агентом определенной последовательности инструментов.

Создание матрицы сбоев инструментов

Перед запуском необходимо определить для каждого метода @Tool, что происходит в трех ситуациях:

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

Если для какого-либо инструмента второй и третий случаи не определены, интеграция не завершена. Успешный сценарий работы — это не сам сервис. Spring AI занимается способами реализации; причины, моменты запуска и варианты действий в случае сбоев остаются за вами.

Окна контекста ведут себя как ненаписанные контракты

В обычном сервисе Spring Boot нарушение контракта приводит к возникновению исключения. В агенте же превышение размера окна контекста не вызывает ни исключений, ни уведомлений, ни записей в журнале ошибок. Модель тихо удаляет старейший контент из диалога, и часто это бывает системное сообщение с вашими бизнес-правилами. REST API возвращает код 400 при нарушении установленных им правил; окно контекста же просто начинает забывать информацию, что делает поиск такой ошибки гораздо сложнее.

Пример из практики

Представьте себе сервис обработки документов, системный промпт которого состоит примерно из 800 токенов. Во время тестирования ответы инструментов в среднем насчитывают около 1 600 токенов на запрос, что полностью в пределах возможностей модели. В режиме работы один конкретный рабочий процесс запускает все три вызова инструментов с большими объемами данных, среди которых находится ответ о истории заказов в вложенной структуре длиной около 1 800 токенов. Общий объем контекста превышает 6 000 токенов, системный промпт тихо обрезается, и агент возвращает правдоподобный ответ, в котором опущена важная бизнес-правило.

Ничего не срабатывает и никаких сигналов тревоги нет. Ошибка проявляется во время еженедельной проверки через три дня.

Решение: мониторинг показателей токенов с самого начала

Потребление контекста инструмента перед запуском. С помощью Micrometer это означает извлечение данных о количестве входных и выходных токенов из объекта использования метаданных ответа и отображение их в виде показателей, например под названиями вроде agent.context.input_tokens и agent.context.output_tokens. Точные названия этих элементов различаются в разных версиях Spring AI, поэтому необходимо проверить API использования для конкретной версии, которую вы используете. Затем следует выдавать предупреждение при достижении примерно 80% от лимита контекста модели. Это обычно соответствует двум элементам-бинам и одному свойству конфигурации, и их необходимо настроить до начала работы. Запуск агента без метрик токенов подобен работе базы данных без мониторинга времени выполнения запросов, что приводит к проблемам примерно в 2 часа ночи.

Постепенное создание

Предварительные требования: Spring Boot 3.2 или новее, Spring AI 1.0 или новее с стартером для вашего поставщика моделей (в данном примере — стартер OpenAI), хорошее понимание конструкций @Async и CompletableFuture, внутренняя служба, предназначенная для использования в качестве инструмента, а также библиотека Micrometer, включённая в вашу стек-архитектуру для мониторинга. Названия артефактов стартеров менялись с выходом новых версий Spring AI, поэтому уточните актуальное название в официальной документации.

Шаг 1: добавление зависимостей

В файле pom.xml добавьте стартер Spring AI для вашего провайдера, а также пакет resilience4j-spring-boot3, если вы хотите поддержку механизма отказоустойчивости для вызовов инструментов. Учетные данные модели указываются в файле application.properties. Ключ API считывается из переменной окружения, например OPENAI_API_KEY, через свойство spring.ai.openai.api-key; выбирается модель чата (в примере используется gpt-4o), а значение параметра температуры должно быть низким — около 0,2 — чтобы использование инструментов оставалось предсказуемым.

Шаг 2: определите инструменты перед настройкой агента

Порядок имеет значение, поскольку дизайн инструментов определяет поведение агента. Системное промпт должно ссылаться на конкретные возможности инструментов, и его написание до создания инструментов приводит к нечетким инструкциям, которые сбивают модель с толку.

В примере компонент OrderTools через свой конструктор получает объекты InventoryService и PricingService, а затем предоставляет два метода с аннотациями. Метод checkInventory(String sku) возвращает количество доступных единиц товара или -1, если SKU неизвестен. Метод getPrice(String sku, String customerTier) возвращает цену в центах доллара США. Каждый метод сопровождается аннотацией @Tool с описанием.

Распространённая ошибка — краткость этих описаний. Модель читает их, чтобы определить, когда вызывать тот или иной инструмент; поэтому точные и полные описания способствуют сокращению ненужных вызовов и получению более точных ответов. Укажите единицы измерения, значения возвращаемых данных и ситуацию, когда элемент не найден, как показано в примерах выше.

Шаг 3: задайте ChatClient краткий системный промпт

Класс AgentConfig определяет объект ChatClient, создаваемый с помощью внедряемого конструктора и класса OrderTools. Стандартное системное указание краткое и императивное: действовать как ассистент по обработке заказов, всегда проверять наличие товаров перед подтверждением их доступности, всегда получать информацию о ценах перед их указанием, возвращать JSON-объект с логическим значением available, целым числом price в центах доллара США и строкой recommendation, а также никогда не выдумывать уровни запасов или цены. Инструменты регистрируются в переменной defaultTools.

Здесь важна экономия токенов. Каждый токен в системном указании сокращает объем места, отведенного для результатов работы инструментов, поэтому старайтесь не превышать 300 токенов и без жалости редактируйте текст.

Шаг 4: запустить агента асинхронно и вести учет токенов

OrderAgentService содержит объект ChatClient и MeterRegistry. Его метод processOrder возвращает объект CompletableFuture<String> и выполняет вызов агента внутри метода supplyAsync: отправляет ввод пользователя, вызывает модель, получает ответ из чата, считает количество входных и выходных токенов и записывает их в качестве показателей, затем возвращает текст результата.

Почему асинхронно? Время выполнения агента зависит от количества вызовов инструментов, а не от кажущейся сложности запроса. Синхронная поток-контроллерная поток может быть заблокирован на 8–14 секунд в условиях высокой нагрузки, что приведет к исчерпанию пула потоков. С самого начала следует рассматривать выполнение агента как фоновую задачу.

Шаг 5: установить защиту от сбоев для каждого инструмента

Опишите каждый метод инструмента с помощью @CircuitBreaker из Resilience4j, укажите название прерывателя (например, inventoryTool) и метод резервного варианта. Метод резервного варианта для инструмента управления запасами записывает предупреждение с информацией о SKU и возвращает -1, что сообщает агенту о недоступности данных о запасах. Пороговые значения должны указываться в файле application.properties: окно из 10 вызовов, пороговое значение коэффициента сбоев в 50% и время ожидания в состоянии прерывания — 10 секунд.

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

Шаг 6: создание конечной точки с асинхронным режимом ответа

OrderAgentController, сопоставленный с путем /agent, принимает запрос типа POST на адрес /orders, генерирует идентификатор запроса, запускает агента и сохраняет информацию о будущем результате в конкурентном словаре, после чего возвращает ответ 202 Accepted с этим идентификатором. Запрос типа GET на /orders/{requestId}/result позволяет получить информацию о будущем результате. Если идентификатор неизвестен, возвращается код 404; пока обработка не завершена, возвращается код 202 с сообщением «Processing»; по завершении — код 200 с результатом; в случае сбоя выполнения — код 500 с сообщением об ошибке. Для использования вне демо-режима необходимо заменить внутренний словарь на хранилище, способное сохранять данные после перезагрузки и удалять устаревшие записи.

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

Инструменты, которые стоит знать

• Spring AI — это основная рамка для агентов в Spring Boot.
• LangChain4j — альтернатива, написанная на Java, которая часто считается более эффективной для координации нескольких агентов.
• Resilience4j обеспечивает механизмы защиты от сбоев и повторные попытки выполнения запросов к инструментам.
• Micrometer отслеживает использование токенов и метрики агента.
• Ollama позволяет запускать модели с открытым исходным кодом локально для разработки и тестирования.

Три ошибки, которые тратят время и подрывают доверие

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

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

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

Чего не упоминают руководства для начинающих

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

Модель запрос-ответ в Spring Boot предполагает ограниченное время выполнения. Агент же не подчиняется этому правилу: он выполняет столько вызовов инструментов, сколько требует задача, и проводит столько этапов обработки, сколько необходимо, не учитывая лимит в 30 секунд для шлюза. Пайплайны на основе агентов не соответствуют структуре запрос-ответ; они ориентированы на событийно-ориентированный подход, и чем раньше вы примете это, тем быстрее будет завершена интеграция.

Команды, с которыми возникают наибольшие трудности, пытаются сохранять синхронную обработку на протяжении всего процесса до получения ответа от агента. Те же, кто достигает наибольшей скорости реализации, запускают агента в фоновом режиме, запускают его по запросу, получают результат с помощью опросов или WebSocket и проектируют контракт сервиса с учетом этого подхода. Такой переосмысление отсутствует в материалах по началу работы с Spring AI, но, возможно, и не должно там присутствовать.

Ментальная модель, которую следует сохранить

Всё сказанное выше сводится к одному предложению: агент ИИ — это распределённая система с неопределённым движком выполнения внутри неё.

Принципы распределённых систем, известные инженеру на Java (изоляция сбоев, наблюдение за поведением, ограничение времени выполнения, чёткое определение условий сбоя), полностью применимы здесь, причём с ещё большей актуальностью, поскольку сбои происходят более тихо и дольше проявляются. Обнадёживает то, что Spring Boot отлично подходит для этой работы. Внедрение зависимостей, возможности наблюдения через Actuator, асинхронные примитивы и развитая экосистема операционных инструментов являются реальными преимуществами, а Spring AI — серьёзной фреймворк-средой. Проблема заключается не в инструментах, а в ментальной модели.

Практические правила:

• Рассматривайте агента как цикл рассуждений и проектируйте контракт сервиса вокруг этого цикла, а не вокруг вызова модели.
• Используйте агентов, когда рабочий процесс зависит от информации, получаемой в процессе выполнения, или когда существующая система оркестрации крайне хрупкая и трудна в обслуживании. Их можно пропустить, если рабочий процесс детерминирован и работает версия, основанная на правилах.
• Spring AI предоставляет фреймворк; вы определяете стратегию обработки сбоев инструментов, управления ресурсами контекста и обеспечения наблюдаемости.
• Рассматривайте окна контекста как контракты и отслеживайте потребление токенов до запуска в производство, а не после первого инцидента.
• С самого начала выполняйте агентов асинхронно, поскольку подход, основанный на событиях, эффективнее, чем модель запрос-ответ, создающая сложности.

Часто задаваемые вопросы

Какой фреймворк лучше всего подходит для агентов в Spring Boot? Spring AI — наиболее подходящий вариант для приложений Spring Boot. LangChain4j — сильная альтернатива с более широкой поддержкой координации множества агентов, причем оба фреймворка находятся в активном развитии.

Необходимо ли переписывать существующие микросервисы? Нет. В данном подходе сервис расширяется с помощью аннотации @Tool из Spring AI, объекта ChatClient и выполнения с помощью @Async, при этом не меняется логика существующего сервиса.

Как следует обрабатывать сбои агентов в производстве? Необходимо обернуть каждый метод с аннотацией @Tool в механизм защиты Resilience4j, отслеживать потребление токенов с помощью Micrometer, заранее определить матрицу сбоев агентов перед запуском и назначить ответственного за проверку качества ответов, а не только уровня ошибок.

В чем разница между агентом и обычным вызовом LLM? Обычный вызов представляет собой один запрос и один ответ. Агент — это цикл, в котором модель может вызывать инструменты, читать результаты, анализировать их и решать, продолжать работу или дать ответ после нескольких этапов взаимодействия.

Готов ли Spring Boot к работе с нагрузками производственных агентов? Да, при правильном архитектурном выборе. Асинхронная обработка, защитные механизмы, метрики токенов и явное управление окном контекста — всё это можно реализовать с помощью существующих стабильных библиотек.

Какова роль RAG? RAG — это лишь один из вариантов решений: агент загружает соответствующие документы из хранилища векторов, чтобы обогатить свой контекст перед принятием решений. Он полезен, когда агенту нужна обширная база знаний, но не является обязательным для каждой интеграции, и его использование усугубляет сложность лишь тогда, когда ограничения окна контекста начинают создавать реальные проблемы.