Java-разработчикам теперь доступен мощный инструментарий для работы с агентными ИИ-системами: Spring AI представила проекты Agents и Bench. В новом переводе от команды Spring АйО рассмотрим, как первый обеспечивает удобную абстракцию для работы с CLI ИИ-агентами, а второй — предлагает реалистичные бенчмарки для оценки их эффективности в задачах enterprise-разработки.


Хочу представить два новых проекта, вошедших в организацию Spring AI Community на GitHub: Spring AI Agents и Spring AI Bench. Оба проекта ориентированы на использование агентных инструментов программирования — тех, которые, вероятно, уже применяются в вашей компании.

Комментарий от Михаила Поливахи

Марк не говорит об этом, но это лишь инкубационные проекты. Несмотря на то, что, скорее всего, всё с ними будет хорошо и рано или поздно они попадут в основной trunk spring-ai, имейте в виду - инкубационные проекты могут очень сильно меняться, пересматриваться и вообще уходить в закат.

Вот ссылка на GitHub организацию для таких проектов: https://github.com/spring-ai-community

К 2025 году AI агенты достигли такого уровня зрелости, что их всерьёз следует рассматривать для разработки на Java в корпоративной среде и для выполнения задач в рамках полного жизненного цикла разработки ПО. CLI-инструменты, такие как Claude Code, Gemini CLI от Google, Amazon Q Developer и помощники от OpenAI — это примеры от ведущих ИИ-лабораторий, но также существует множество решений от стартапов и в open source-сегменте. Эти агентные инструменты способны рассуждать об архитектуре, анализировать большие кодовые базы и обладают огромным потенциалом для ускорения выпуска программного обеспечения. Обычно они используются в стиле «человек в цикле», но могут быть настроены и на автономное выполнение задач до момента достижения цели.

Spring AI Agents определяет лёгкую, но мощную портативную абстракцию — AgentClient. Она служит унифицированным интерфейсом для вызова автономных CLI-агентов. Это позволяет разработчикам использовать уже доступные агентные инструменты, при этом сохраняя гибкость и избегая привязки к одному вендору.

Комментарий от Михаила Поливахи

Сноска: 

Иными словами, у Spring AI потенциально появляется инструментарий для того, чтобы из кода общаться с CLI фгентными системами, такими как

- Qwen CLI
- Gemini CLI 
- Claude Code и др.

Однако AgentClient — это лишь одна из составляющих набора инструментов, необходимых разработчику для эффективного взаимодействия с агентными системами. Spring AI Agents предоставляет следующие абстракции, которые в совокупности позволяют добиться наилучших результатов:

Goals (Цели): задачи, которые должен выполнить агент, например, увеличение покрытия тестами, маркировка задач или проверка и мердж pull-запросов.
Context (Контекст): данные и среда, в рамках которых работает агент — исходные файлы, логи, структурированные наборы данных и документация.
Tools (Инструменты): пользовательские функции, доступные модели по мере необходимости, чаще всего предоставляемые через протокол Model Context Protocol.
Judges (Оценщики): механизмы проверки результатов и оценки качества на основе заданных критериев. Могут быть детерминированными (например, показатель покрытия тестами) или использовать ИИ по шаблону LLM-as-Judge.
Sandbox (Песочница): абстракция среды, в которой агент безопасно и воспроизводимо выполняет свою работу. В текущей версии поддерживается выполнение локально и в контейнере Docker.

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

Необходимость в этом проекте возникла в ходе моего изучения существующих бенчмарков для агентных систем.

Комментарий от Михаила Поливахи

Здесь я позволю себе пояснить то, что говорит Марк, так как не все понимают, что такое SWE-bench, SWE-agent, mini-SWE-agent и т.д.

В западной индустрии некоторое время назад начали появлятся различные инструменты, которые способны, например, как только создается тикет на GitHub (или происходит другое целевое действие) - проанализировать проблему, и попытаться самостоятельно сгенерировать патч для её решения, возможно прямо отдельным PR-ом. SWE-agent и mini-SWE-agent (минимизированная версия SWE-agent) это как раз инструменты из той оперы.

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

И также в индустрии естественным образом появился набор бенчмарков, SWE-bench, который, грубо говоря, отвечает на вопрос - насколько вообще то, что делает SWE-agent/mini-SWE-agent релевантно? Насколько этот агент способен решать реальные задачи? Закономерные вопросы, не так ли.

Так вот SWE-bench это набор таких вот "типовых" задач и бенчмарков для их оценки. Исходный код можно посмотреть вот тут: https://github.com/SWE-bench/SWE-bench

Я обнаружил, что они в основном сосредоточены на Python коде и охватывают лишь один сценарий использования — создание git патча для решения конкретного тикета на GitHub. В науч��ой литературе наблюдается следующая закономерность: SWE-bench демонстрирует высокие результаты на статичном, вручную отобранном наборе задач на Python, но как только появляется новый набор задач, показатели резко падают. На SWE-bench “Verified” (то есть на задачах, которые агент уже видел и про которые он в курсе) агенты генерируют “успешные” патчи в 60–75% на статичных Python-наборах; на SWE-bench-Live — те же агенты генерируют патчи, которые можно принять, лишь в 19% случаев, то есть падение в три раза. А на SWE-bench-Java задачи на Java решаются “успешно” на уровне всего 7–10% против ~75% на Python в рамках той же серии бенчмарков, что указывает на разрыв в порядок величины. Для технических руководителей такие нестабильные показатели превращаются в нестабильные управленческие решения.

Это вовсе не означает, что агенты слабы и на самом деле не способны решать задачи по написанию кода  — это означает, что методы их оценки устарели. SWE-agent насчитывает тысячи строк Python-кода, но упрощённый mini-SWE-agent (~100 строк, простой агент с чат-памятью и одним инструментом — bash) показывает сопоставимые результаты на SWE-Bench. Оказалось, что на сегодняшний день попросту нет бенчмарков, позволяющих оценить возможности современных и будущих агентных CLI-инструментов.

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

Комментарий от Михаила Поливахи

F1 - классификационная метрика в ML. Можете подробно почитать тут https://en.wikipedia.org/wiki/F-score

Агенты для мержа pull-запросов уже обработали сотни PR-ов в кодовой базе Spring AI, генерируя структурированные репорты — оценку рисков, заметки по архитектуре и анализ обратной совместимости. Это значительно сократило время на ревью и повысило его единообразие. Простые бенчмарки покрытия кода показали, что хотя ведущие модели достигают одного и того же уровня покрытия, между ними наблюдаются различия в качестве кода и точности следования инструкциям.

Что дальше: оба проекта проходят стадию инкубации в организации Spring AI Community. Snapshot-сборки уже доступны в Maven Central. Мы также сотрудничаем с организаторами инициативы Developer Productivity AI Arena (DPAIA), созданной для решения именно тех проблем, о которых я здесь рассказал.

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

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Комментарии (0)