Spring AI 2.0.0: как убрать Python-сервис из AI-функций
В июне 2026 года у команд, которые держат бэкенд на Spring Boot, появился рабочий вариант не заводить отдельный Python-сервис для каждой «умной» функции. 12 июня вышел Spring AI 2.0.0 GA — релиз, ориентированный на Spring Boot 4, с глубокой интеграцией протокола MCP (Model Context Protocol). Если раньше добавление AI-агента означало второй стек: свой деплой, свой контур безопасности, свои дежурства, — то теперь часть этой логики можно держать прямо в JVM-процессе. Не вместо Python, а там, где это снижает операционные издержки. Статья Tech Lead из FinTech Сергея Прощаева на Habr разбирает, как это работает на практике и где подход пока ломается. Для руководителя разработки или техлида, который оценивает архитектуру, это повод пересмотреть, какие AI-функции действительно требуют отдельного сервиса, а какие можно интегрировать в существующий стек.
Что изменилось: от Python-сервиса к единому протоколу
Главная проблема, которую решает связка Spring AI + MCP, не в том, что на Java «нельзя позвать модель». HTTP-клиент есть, и вызвать OpenAI можно было и три года назад. Проблема архитектурная. Чтобы AI-агент приносил пользу, он должен не разговаривать, а действовать: ходить в базу, дёргать внутренние сервисы, проверять лимиты, инициировать платёж. Вся эта логика у enterprise уже написана — на Java, с транзакциями, ролями, аудитом.
Раньше было два пути, и оба дорогие. Первый — открыть AI-сервису пачку внутренних HTTP-эндпоинтов, что создаёт новую поверхность атаки. Второй — дублировать кусок бизнес-логики во втором стеке, что означает двойное сопровождение. Автор статьи приводит пример из своей практики: маленькая функция с LLM в FinTech-продукте приехала отдельным сервисом на Python — свой деплой, свой контур безопасности, свой стек наблюдаемости, свои дежурства. Функция была на три экрана кода, а сопровождение — как у полноценного сервиса.
Spring AI 2.0.0 меняет это через протокол MCP. MCP — это единый протокол, через который LLM может вызывать инструменты, написанные на Java, без необходимости открывать HTTP-эндпоинты или дублировать логику. Слой принятия решений остаётся за LLM, а слой исполнения — то, что реально дёргает сервисы, базы и платёжные шлюзы, — теперь можно держать в Java без второго технологического стека.
Почему это меняет стоимость и риски для бизнеса
Для компании, у которой в продукте Spring Boot, каждое решение «завести Python-сервис» — это не просто выбор языка. Это операционные последствия:
- Деплой и инфраструктура. Python-сервис требует отдельного конвейера сборки, отдельного мониторинга, отдельного управления секретами. Если в компании всё зарегулировано (FinTech, госсектор, телеком), согласование второго стека может занять недели.
- Безопасность. Открытие HTTP-эндпоинтов для AI-агента — это новая поверхность атаки. Каждый эндпоинт нужно аудировать, покрывать тестами безопасности, контролировать доступ.
- Кадры. Поддержка Python-сервиса означает либо наём Python-разработчика, либо требование к Java-команде знать второй язык. В любом случае — рост фонда оплаты труда или простои.
- Сопровождение. Функция на три экрана кода, которая требует дежурств как у полноценного сервиса, — это неэффективное использование ресурсов команды.
Spring AI + MCP позволяет держать AI-агента в том же JVM-процессе, что и основной бэкенд. Это не отказ от Python, а появившийся выбор: для функций, где не нужна отдельная инфраструктура, можно не заводить второй стек.
Что проверить перед внедрением: четыре вопроса команде
Прежде чем принимать решение об интеграции Spring AI + MCP в существующий проект, стоит проверить четыре вещи. Они определят, получите ли вы снижение операционных издержек или новую головную боль.
| Что меняется | Почему важно бизнесу | Что проверить |
|---|---|---|
| AI-агент работает в том же JVM-процессе | Нет отдельного деплоя, безопасности, дежурств | Не приведёт ли это к падению основного сервиса при сбое AI-компонента? |
| MCP заменяет HTTP-эндпоинты для вызова инструментов | Снижается поверхность атаки | Поддерживает ли ваша инфраструктура мониторинг MCP-вызовов? |
| Слой исполнения на Java, слой решений — на LLM | Не нужно дублировать бизнес-логику | Готовы ли вы к тому, что LLM может выбрать неверный инструмент? |
| Spring AI 2.0.0 ориентирован на Spring Boot 4 | Нужно обновление основного фреймворка | Когда команда планирует миграцию на Spring Boot 4? |
Где подход пока ломается: риски и неопределённости
Автор статьи честно говорит, что подход не универсален. Вот что стоит учитывать.
Зависимость от LLM. Логика принятия решений и выбор инструментов остаются за LLM. Если модель ошибается в выборе — вызывает не тот сервис, не ту базу, — последствия могут быть серьёзными. В FinTech-продукте такая ошибка может означать некорректный платёж или утечку данных. Механизмов гарантии правильности выбора инструмента на уровне протокола пока нет.
Зрелость экосистемы. Spring AI 2.0.0 — это GA-релиз, но экосистема вокруг MCP в Java всё ещё моложе, чем LangChain и LlamaIndex в Python. Это значит, что примеров из интернета меньше, сообщество меньше, и при возникновении нестандартной проблемы найти готовое решение может быть сложнее.
Безопасность внутри процесса. Когда AI-агент работает в том же JVM-процессе, что и основной сервис, он имеет доступ ко всему, к чему имеет доступ процесс. Если LLM-компонент будет скомпрометирован, злоумышленник получит доступ к бизнес-логике без необходимости пробивать внешний HTTP-эндпоинт. Автор упоминает риски безопасности, но не детализирует их — это область, которую команде нужно прорабатывать самостоятельно.
Зависимость от версий. Spring AI 2.0.0 ориентирован на Spring Boot 4. Если ваша команда ещё не планирует миграцию на Spring Boot 4, использование новой версии Spring AI может быть затруднено или потребовать дополнительных усилий по совместимости.
Что сделать на этой неделе: практический чек-лист
Для руководителя разработки или техлида, который хочет оценить применимость подхода, вот пять конкретных шагов.
- Выберите одну функцию, которая сейчас реализована через отдельный Python-сервис или через HTTP-вызов к LLM. Лучше всего подходит функция, которая не требует высокой гарантии правильности выбора инструмента — например, рекомендательная система или генерация отчётов, а не обработка платежей.
- Проверьте версию Spring Boot в вашем проекте. Если это Spring Boot 3 или ниже, оцените дорожную карту миграции на Spring Boot 4. Без неё использование Spring AI 2.0.0 может быть преждевременным.
- Соберите метрики текущего решения: сколько времени занимает деплой Python-сервиса, сколько человеко-часов уходит на сопровождение, как часто происходят инциденты. Это даст базу для сравнения после внедрения.
- Проведите архитектурное ревью с командой безопасности. Обсудите, какие риски возникают при размещении AI-агента в том же JVM-процессе, и какие меры изоляции можно применить (например, отдельный ClassLoader или ограничение доступа к чувствительным данным на уровне кода).
- Соберите прототип на выбранной функции. Используйте Spring AI 2.0.0 и MCP для вызова одного-двух инструментов из существующей бизнес-логики. Оцените, сколько времени заняла интеграция, и сравните с затратами на поддержку текущего решения.
Источники
Генерация изображения
- Модель:
flux-schnell - Провайдер:
replicate