Додавання AI-агентів до мікросервісів Spring Boot за допомогою Spring AI

Уявіть трьох мікросервісів Spring Boot, які вже обробляють трафік у продакшені: шість тижнів роботи над додаванням до них функцій агентів, два з яких були успішно впроваджені, а третій перетворився на довгий та дорогий урок. Цей сценарій, який відображає досвід багатьох команд, що працюють з Java, формує основу для подальшого опису. Це практичний огляд інтеграції агентних пайплайнів у існуючі сервіси, які мають обмеження щодо затримок, залежні команди та справжніх користувачів; матеріал написаний для інженерів бекенду, які знають Spring Boot та хочуть отримати можливості ШІ, не відмовляючись від своєї архітектури.

У наступних розділах розглядається, що насправді є ШІ-агентом у середовищі Spring Boot (і чим він не є), чому команди його впроваджують, як реалізувати виклик інструментів за допомогою Spring AI, три способи збою, які зазвичай з’являються лише після запуску, та як розглядати споживання токенів як ключовий оперативний показник.

Що таке агент, а що — ні

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

Агент — це не просто розумний виклик API. Це цикл міркувань: мовна модель отримує завдання, вибирає інструменти для виконання, отримує результати, аналізує все, що тепер знає, і або повертає остаточну відповідь, або починає наступний етап роботи.

Цей цикл складається з чотирьох елементів:

• Модель — це двигун міркувань, чи то GPT-4o, Claude, Gemini, чи альтернатива з відкритим кодом, яка працює через Ollama.
• Інструменти — це функції, API чи виклики сервісів, які модель може використовувати.

Цикл — це багаторазовий процес, який відокремлює агента від одного виклику LLM.

Контекст — це постійно зростаюча купа історії розмов, результатів роботи інструментів та інструкцій, які надходять на кожен крок міркувань.

У мікросервісі Spring Boot це означає, що ви не створюєте обгортку у стилі RestTemplate навколо кінцевої точки ШІ. Ви вбудовуєте багатокроковий, становий та недетерміністичний робочий процес у сервіс, призначений для обмеженої, синхронної та прогнозованої роботи. Саме ця неузгодженість стає причиною проблем у більшості інтеграцій ШІ з Java. Короткий спосіб запам’ятати це: інструмент — це не агент, агентом є цикл, і поки ви цього не зрозумієте, ви будете створювати кінцеві точки, а не агентів.

Причини використання агентів у сервісах Spring Boot

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

Поза межами фіксованих правил

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

• Обробка замовлень. Один агент перевіряє наявність товарів, оцінює правила ціноутворення, застосовує знижки для конкретних клієнтів та формує рекомендації щодо виконання замовлення в одному запиті, тож фронтенд не мусить координувати чотири послідовні виклики.
• Розуміння документів. Агент читає завантажений PDF, витягує структуровані поля, перевіряє їх згідно з бізнес-правилами та або підтверджує результати, або передає справу людському рецензенту, без використання жорстко закодованих правил витягування даних.
• Підтримка клієнтів. У рамках існуючої служби підтримки агент отримує інформацію про статус рахунку, історію замовлень та документи політики, щоб скласти відповідь, точну з точки зору контексту, що скорочує час обробки без виключення людини з процесу.
• Перегляд коду та допомога у CI. У процесі розробки платформи агент аналізує невдалих тестів, звертається до внутрішньої документації та пропонує цілеспрямовані виправлення.

У кожному з цих випадків значенням не є просто „AI“. Йдеться про заміну крихкої, вручну написаної логіки оркестрації на шар міркувань, який адаптується до отриманих даних, замість того щоб зламатися, коли вхідні дані виходять за межі передбачуваного сценарію.

Чому Spring Boot підходить для цієї роботи

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

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

Асинхронні примітиви, такі як @Async та CompletableFuture, ефективно справляються з циклами агентів, тривалість виконання яких змінюється.

Resilience4j обгортає виклики інструментів за допомогою механізмів аварійного вимкнення та повторних спроб, запобігаючи каскадним збоям.

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

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

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

Коли агент є доцільним

Агенти здобувають своє місце тоді, коли:

• У процесі виконання потрібні рішення, засновані на інформації, виявленій під час виконання, а не на інформації, відомій на момент надходження запиту.
• Чинна реалізація змушує фронтенд чи сервіс-оркестратор координувати кілька викликів бекенду, і агент міг би взяти на себе цю координацію на сервері.
• Вхідні дані — це природна мова змінної структури, при цьому класифікація, вилучення, узагальнення чи маршрутизація здійснюються на основі змісту, а не схеми.
• Чинна система працює некоректно, але не падає, і агент міг би бути розроблений для виявлення невизначеності, замість того щоб мовчки повертати найімовірнішу неправильну відповідь.

Вони є недоречними, коли робочий процес є повністю детермінованим, вхідні дані структуровані, а логіка, заснована на правилах, є підтримуваною. Агенти додають складності, і їх використання варте уваги лише тоді, коли альтернатива є гіршою.

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

Для керівників інженерних команд та зацікавлених сторін у продукті аргумент ґрунтується на трьох основних аспектах:

1. Швидша реалізація нових функцій. Функції, для розробки яких раніше були потрібні тижні роботи над кодом для оркестрації на бекенді, часто можна прототипувати за кілька днів, якщо агент бере на себе багатоетапну координацію. Команди зазвичай фіксують таке прискорення після першої успішної інтеграції, хоча ці цифри можуть відрізнятися.
2. Більш ефективне технічне обслуговування правил. Кожне жорстко закодоване правило в сервісі є „боргом“, який зростає при змінах бізнес-логіки, а інструкції, написані природною мовою, зазвичай легше оновлювати, ніж код, який імперативно виражає ту саму логіку.
3. Основа для складних AI-систем. Один добре інтегрований агент є фундаментом для багатоагентних робочих процесів, конвеєрів генерації з підтримкою пошуку та функцій продуктів, створених спеціально для AI.

Чому така терміновість та зміна моделі виконання?

Протягом 2023 та у 2024 році використання AI в Java означало переважно лише надсилання запиту до кінцевої точки LLM та отримання будь-якого тексту у відповідь: звичайний HTTP через WebClient, таймаут та жодних подальших дій.

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

• У старій моделі один запит призводив до одного виклику LLM та однієї відповіді.
• У новій моделі запит розгалужується на N викликів інструментів та M кроків міркувань, перш ніж з’явиться єдина відповідь.

Багато інженерів Spring Boot досі використовують стару модель та ставляться до ChatClient як до RestTemplate. Ця категорійна помилка спричиняє проблеми в продакшені через кілька тижнів після запуску, і вони рідко є очевидними, коли виникають.

Цикл — це агент

Інженери, які вперше працюють з інтеграцією агентів, зазвичай уявляють собі сервіс, який замінює контролер: один об’єкт типу @Service, один інжектований об’єкт ChatClient — і все готово. Це лише кінцева точка автодоповнення, а не агент. Справжній агент виконує цикл: отримує завдання, обирає інструмент, виконує його, отримує результат, аналізує новий стан та вирішує, чи продовжувати роботу чи відповідати. Модель — це механізм міркувань усередині цього циклу; сам цикл і є агентом.

Чому звичайний підхід неправильно оцінює витрати

Поширеною припущенням є те, що виклик LLM є дорогим та складним етапом, а решту обробляє обгортка типу Spring @Service. Насправді „решта“ тепер є розподіленою: наскільки повільні інструменти, який стан містить контекст з однієї інтеракції в іншу, як поширюються помилки у багатоетапних процесах, та необхідність повторних спроб, щоб впоратися з незавершеною роботою.

Розгляньмо гіпотетичний сервіс класифікації замовлень. Спочатку він складається з одного кінцевого точки POST /orders/classify, яка здійснює один виклик LLM. Потім його переробляють на агента, який класифікує замовлення, викликає інструмент керування запасами, викликає інструмент формування цін залежно від наявності товару та повертає рекомендацію щодо виконання замовлення. Кожен виклик інструменту — це справжній виклик сервісу з реальною затримкою.

Припустимо, що агент виконує завдання менш ніж за дві секунди для 80% запитів, тоді як для решти 20% повільний верхній рівень сервісу керування запасами подовжує час відповіді до 8–14 секунд. Це не проблема ШІ — це проблема розподілених систем, яку виявив цикл агента.

Компроміс, який ігнорують

Цикл агента не є безстановим. Кожен результат використання інструменту додається до розмови та надсилається моделі знову на наступному кроці. При високій пропускній здатності витрати пам’яті на кожен запит зростають з кількістю кроків, які виконує агент, а кількість самих запитів стає менш важливою. Сервіс, який обробляє 1 000 запитів на хвилину при середній кількості кроків 4, фактично виконує 4 000 викликів LLM, причому розмір контексту постійно збільшується.

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

Spring AI надає інструменти, а не план

Spring AI — це серйозний шар абстракції, орієнтований на роботу в продакшені. Він пропонує ChatClient, ToolCallback, VectorStore та API для виконання агентів, який підтримує вставку залежностей, зміну моделей через application.properties та реактивну роботу за допомогою Flux. Як відправна точка для інтеграції LLM у 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, якщо бажаєте підтримки механізму circuit-breaker для викликів інструментів. Креденції моделі знаходяться у файлі application.properties. Читайте API-ключ з змінної середовища, наприклад OPENAI_API_KEY, через властивість spring.ai.openai.api-key, виберіть модель чату (у прикладі використовується gpt-4o) та тримайте значення параметра temperature на низькому рівні, близько 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 ще до того, як хоча б один агент встигне взаємодіяти з реальним користувачем. Це аналог використання складних технологій AI для створення сервісної мережі до перевірки функціоналу моноліту. Випустіть одного агента з одним набором інструментів у одному сервісі, протестуйте його та додавайте складність лише там, де це необхідно за даними. Команди, які найшвидше доходять до фази продакшну, уникають проектування платформи до того, як у них з’явиться готовий продукт.

Системна проблема: ніхто не несе відповідальності за поведінку агента. Звичайна несправність залишає запис у журналі, показник та сповіщення. Неправильна, але правдоподібна відповідь агента не залишає нічого з цього: жодних винятків, жодних сповіщень — лише відповідь, яка пройшла перевірку схеми, але не відповідає бізнес-логіці. Визначте відповідальну особу за те, що каже агент, а не лише за те, чи він відповів, та щотижня аналізуйте вибірку відповідей, а не лише показники помилок. Це скоріше організаційне рішення, ніж технічне.

Що не враховують посібники з початку роботи

За більшістю думок, найскладнішою частиною інтеграції агентів 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 Circuit Breaker, відстежуйте споживання токенів за допомогою Micrometer, визначте матрицю можливих збоїв агента перед запуском у продакшен та призначте особу, відповідальну за перевірку якості відповідей, а не лише рівня помилок.

У чому різниця між агентом та звичайним викликом LLM? Звичайний виклик передбачає один запит та одну відповідь. Агент — це цикл, у якому модель може викликати інструменти, читати результати, аналізувати їх та вирішувати, чи продовжувати роботу чи надати відповідь протягом кількох кроків.

Чи готовий Spring Boot до роботи з навантаженнями агентів у продакшені? Так, за умови правильного вибору архітектури. Асинхронна обробка, пристрої захисту від збоїв, метрики токенів та явне керування вікном контексту можна реалізувати за допомогою існуючих, стабільних бібліотек.

Де місце RAG? RAG — це лише один із шаблонів інструментів: агент отримує відповідні документи з бази даних векторів для поглиблення свого контексту перед міркуваннями. Це корисно, коли агенту потрібна велика база знань, але це не є обов’язковим для кожної інтеграції, і його використання слід вводити лише тоді, коли обмеження вікна контексту створює справжні проблеми.