Часть 2. GOAP, или Как заставить LLM отвечать за базар

Представьте: ИИ-агент в банке отказал клиенту в кредите. Клиент жалуется, приходит аудитор и задаёт один вопрос: «Почему?» Агент на цепочке промптов отвечает: «Модель так решила». Для демо это сойдёт, для банка — приговор. Главная проблема корпоративного ИИ-агента — не работа, а объяснение аудитору, почему он принял решение. Python-фреймворки долго решали это логированием и трассировкой: поведение строится на цепочке промптов, и разобраться в причинах сложно. Графовые подходы вроде LangGraph улучшают ситуацию, представляя агентов как узлы графа, но Java пошла иначе — через детерминированное планирование.

Embabel — проект Рода Джонсона, создателя Spring. Версия 1.0 (GA) вышла в 2026 году. Он не заменяет Spring AI, а строится поверх него — как Spring MVC поверх Servlet API. В основе GOAP (Goal-Oriented Action Planning) из игрового ИИ. Агент получает типизированные действия с предусловиями и эффектами. Планировщик — детерминированный код, а не вызов LLM — ищет последовательность к цели. Если что-то меняется, путь пересчитывается, а не падает. LLM генерирует контент и рассуждения, но не маршрутизацию. Это снижает риск невоспроизводимого поведения, но не отменяет трассировку: прозрачность для аудитора требует логирования предусловий и эффектов на каждом шаге. Ограничение: GOAP эффективен в замкнутых пространствах; при большом числе действий A* может столкнуться с экспоненциальной сложностью. Это инструмент с чёткими границами применимости, а не серебряная пуля. Ключевая идея в другом: решение о маршрутизации принимает код, который можно прочитать, проверить и воспроизвести, а не вероятностная модель, чей вывод меняется от формулировки промпта.

ADK for Java 1.0.0 от Google вышла 30 марта 2026 года. Она берёт на себя оркестрацию агентов, инструменты и управление контекстом: Google Maps grounding, UrlContextTool, выполнение кода в изолированных контейнерах, плагины, event compaction, Human-in-the-Loop, протокол Agent2Agent, сессии в Vertex AI и Firestore. Если Embabel — мозг, то ADK — руки, ноги и нервная система. Вместе они закрывают разрыв между «агент думает» и «агент делает» — именно там чаще всего ломаются демо.

Релиз Koog 1.0 от JetBrains состоялся в мае 2026 года на конференции KotlinConf. Главное обещание — год без ломающих изменений в стабильных модулях. Это Kotlin-нативный фреймворк с Java-интеропом, поэтому для Java-команд порог выше. Зато есть структурированные, наблюдаемые процессы, OpenTelemetry, локальный LiteRT на Android и кэширование промптов Anthropic.

Deeplearning4j (DL4J) — зрелая JVM-библиотека, но не единственная. Есть Deep Java Library от AWS (PyTorch, TensorFlow, ONNX), ONNX Runtime Java от Microsoft, Tribuo от Oracle и Smile. DL4J включает ND4J, SameDiff и импорт моделей из Keras/TensorFlow/ONNX, но активность сообщества снизилась; для новых проектов часто советуют DJL + ONNX Runtime.

Что объединяет эти проекты? Ставка на инженерную предсказуемость: строгая типизация, зрелый CI/CD, управление зависимостями, наблюдаемость. То, за что enterprise выбирает Java и чего не хватает ИИ-агентам за пределами демо. Когда агент работает в контуре с SLA, аудитом и комплаенсом, «магия модели» перестаёт быть достоинством и становится риском. Банк не может позволить себе агента, который сегодня одобряет кредит, а завтра — нет, по причинам, которые никто не в состоянии объяснить.

Почему Python всё ещё кажется главным? Python доминирует в исследованиях, обучении моделей и прототипах, где важна гибкость. Java выигрывает в интеграции ИИ в enterprise-системы, где модель уже обучена, а её нужно встроить в транзакционный контур. Это не противостояние, а разделение труда. Java не пытается обогнать Python в обучении моделей — она делает то, что умеет лучше всего: превращает ИИ в надёжный компонент. Вопрос не «Java или Python?», а «Где заканчивается исследование и начинается продакшен?» И судя по темпам, с которыми Java-экосистема набирает инструменты для агентов, ответ на этот вопрос становится всё более очевидным.