Spring AI и Bedrock AgentCore: Java-агент в проде с одной аннотацией и двумя эндпоинтами

Если у вас enterprise-команда на Java, то история с агентами обычно выглядит так: на Python кто-то собрал демку, она всем понравилась, а потом выясняется, что в ваш CI/CD, мониторинг и модель доступа она не вписывается. AWS в новом разборе предлагает другой путь: не менять стек, а подключить агентов через Spring AI и Bedrock AgentCore.

Чем агент отличается от вызова модели

Обычный chat completion генерирует текст, но не решает, что делать дальше, не лезет во внешние системы и не помнит вчерашний разговор. Агент объединяет три вещи: планирование (разбить цель на шаги и пересмотреть план по ходу), инструменты (API, базы данных, интерпретатор кода) и память (внутри сессии и между сессиями).

RAG-приложение здесь не агент: поиск у него есть, а цикла планирования нет. Агент работает в цикле, пока не выполнит задачу или не решит, что продолжать нельзя.

Как это выглядит в коде

AgentCore — управляемая платформа AWS, которая не привязана к фреймворку или модели. Рантайм требует от вашего сервиса всего два эндпоинта: POST /invocations для запросов (JSON или потоковый SSE) и GET /ping для проверки здоровья. Если задача долгая, сервис должен отвечать HealthyBusy, иначе рантайм может его масштабировать вниз.

Spring AI AgentCore SDK прячет этот контракт за аннотацией @AgentCoreInvocation: она сама создаёт оба эндпоинта, сериализует JSON и оформляет SSE. Тот же сервис может отдавать REST для React-интерфейса, так что отдельный бэкенд под агента не нужен.

Инструменты подключаются так же по-спринговски. Метод помечаете @Tool с описанием, регистрируете в ChatClient через defaultTools, и модель сама решает, когда его вызвать. Для структурированного ответа просите Java record, а для документов прикрепляете файл к пользовательскому сообщению. Память подключается через advisors: перехватчики добавляют контекст в промпт до обращения к модели. Фрагмент про память в исходном тексте обрывается, так что детали смотрите в оригинале.

От одного агента к нескольким

Второй пример — система обработки документов с пятью специалистами: юрист, ипотека, страхование, налоги и общий агент. Классификатор определяет тип документа и передаёт его нужному специалисту. Тот возвращает структурированный JSON с оценкой уверенности. Затем правила на SpEL из application.yml решают, что делать: отправить ALERT, заблокировать или отправить документ на ручную проверку.

Здесь три паттерна: роутер (только диспетчеризация, без доменной логики), оценщик (бизнес-правила поверх ответов) и параллельный fan-out. Последний в базовом решении не реализован: пакетная обработка идёт последовательно. Если добавить fan-out, время анализа будет определяться самым медленным агентом, а не суммой всех вызовов.

Ограничения

Первое: это материал AWS, и заточен он под экосистему AWS. Bedrock Converse API, AgentCore, Graviton и Terraform-модули — всё в одной связке. Переносимость на другие облака в статье не обсуждается.

Второе: структурный вывод в Java record проверяли на Claude Sonnet 4.5. Spring AI добавляет схему в промпт и парсит ответ, но модель иногда возвращает данные не по схеме. Для строгости нужен провайдер с нативным контролем схемы или валидация с повторным запросом.

Третье: при многоаргументных вызовах инструментов авторы советуют собирать ответ блокирующим call(), а потом нарезать на чанки, чтобы аргументы привязывались надёжно. Это снижает пользу от настоящего стриминга.

Что делать

Если у вас Java-стек и вы уже в AWS, начните с туристического ассистента: один агент, инструменты и память. Проверьте, как ведёт себя ваша модель на структурированном выводе, и только потом добавляйте роутер и правила. Требования строгие: JDK 21, Spring Boot 4.1 с Spring AI 2.0, Terraform 1.5+ и Docker с Buildx для ARM64-образа. Заранее убедитесь, что ваш проект выдержит такой апгрейд.