Как работают ИИ агенты в корпоративных системах

Большинство пилотных ИИ-проектов на предприятиях проваливаются. Публикация исследователей IBM Research на HuggingFace объясняет, почему так происходит и как это исправить. Ключевая идея: сама по себе большая языковая модель не справляется с корпоративными задачами, потому что рабочие процессы предприятий динамичны, долгоиграющи, опутаны сотнями API и баз данных, а ещё ограничены регуляторными политиками. Модели нужен «навигатор», агентная логика, набор программных примитивов, которые сужают контекст и направляют модель точно по маршруту задачи.

Что понадобится

• Понимание задачи: конкретный корпоративный процесс, который вы хотите автоматизировать (разбор легаси-кода, тестирование, мониторинг инцидентов)
• Инструмент статического анализа кода: библиотека, которая разбирает исходный код на структурные элементы без его запуска (для COBOL и Java подойдут специализированные парсеры)
• Граф знаний (knowledge graph, структура «сущность и связь», где каждый микросервис, база данных и метрика связаны между собой): можно построить в Neo4j или аналогичной графовой базе данных
• Доступ к языковой модели: в примерах IBM используются Mistral Medium 250B и Devstral 24B, но логика применима к любой модели, включая открытые
• Агентный фреймворк: оболочка, в которой работает ИИ-агент (LangGraph, CrewAI или собственная разработка)
• Время: от нескольких дней на прототип одного агента до нескольких недель на интеграцию в рабочий процесс

Пошаговая инструкция

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

2. Постройте предварительно индексированное представление данных. Вместо того чтобы каждый раз скармливать модели весь исходный код или всю документацию, прогоните статический анализ и сохраните результат в структурированной базе. В примере IBM для разбора COBOL-приложений (до миллиона строк кода и тысячи программ) статический анализ создаёт схему из сотен взаимосвязанных таблиц. Модель обращается уже к готовым структурам, а не к «сырому» коду.

3. Сформируйте граф знаний для контекста. Для задач мониторинга и реагирования на инциденты IBM определяет граф, где сущности включают микросервисы, сервисы баз данных, промежуточное ПО и телеметрию. В граф встраивают «племенные знания», экспертизу, которая обычно живёт только в головах инженеров.

4. Соберите агента с логикой навигации. Агентная логика встраивается между пользовательским запросом и языковой моделью. Она сужает контекстное пространство: модель получает не миллион строк, а выжимку, релевантную конкретному вопросу.

# Псевдо-архитектура агента с логикой навигации user_query → agent_logic(static_analysis + knowledge_graph) → reduced_context → LLM → validated_response

1. Добавьте суб-агентов для итеративного улучшения. В примере IBM с генерацией тестов (инструмент Aster) суб-агенты отвечают за расширение покрытия кода и исправление ошибок компиляции. Каждый суб-агент решает узкую задачу, а не пытается «понять всё».

2. Измерьте результат по трём метрикам: качество, стоимость, доверие. Без замеров вы не отличите рабочего агента от дорогой игрушки. IBM фиксирует покрытие кода (line, branch, method coverage), потребление токенов и рейтинги разработчиков.

Четыре сценария, где это уже работает

Исследователи IBM проверили агентную логику на четырёх задачах корпоративного цикла разработки ПО.

Понимание легаси-кода (COBOL/PL/1). Агент App Insights в составе IBM watsonx Code Assistant for Z использует статический анализ и предындексированную базу. Результат на системах до миллиона строк кода: точность понимания приложений на уровне чуть выше базовой модели при потреблении токенов примерно в 30 раз ниже.

Генерация тестов (Aster). Библиотека Aster генерирует юнит-тесты, интеграционные, API и тесты на изменения. По данным публикации, на 75 и более Java-приложениях IBM CIO (до 560 классов и 67 тысяч строк кода) с моделью Devstral 24B покрытие выросло на 20 до 45 процентов. Потребление токенов ниже до 15 раз по сравнению с ведущими ИИ-агентами для написания кода.

Реагирование на инциденты. Граф знаний плюс библиотеки наблюдаемости (observability, возможность видеть, что происходит внутри работающей системы) позволяют агенту проактивно находить проблемы до того, как они превратятся в аварии.

Автоматизация комплаенса. Модернизация соответствия нормативным требованиям для критически важных сред, задача, где ошибка стоит дорого, а ручная работа занимает месяцы.

Что делать с этим прямо сейчас, по ролям

Разработчику. Если вы работаете с легаси-системами (COBOL, PL/1, старые Java-монолиты), начните с построения статического анализа и индексированной базы структур. Это снизит расход токенов и повысит точность ответов модели. Из доступных в РФ моделей для экспериментов подойдут YandexGPT и GigaChat, а для кода можно использовать открытые модели вроде Devstral.

Маркетологу и менеджеру продукта. ИИ-агенты для бизнеса перестают быть демо-проектами и выходят на уровень предпродакшена. Если ваша компания обсуждает внедрение ИИ, покажите команде эту архитектуру: агентная логика плюс граф знаний, конкретный рецепт, а не абстрактное «внедрите ИИ».

Предпринимателю в РФ и СНГ. IBM watsonx Code Assistant for Z, продукт для крупного энтерпрайза, в России напрямую недоступен. Но сама архитектура, статический анализ плюс граф знаний плюс языковая модель, воспроизводима на любом стеке. Если у вас есть легаси-код и дорогие инженеры, которые тратят дни на его разбор, это ваша точка экономии.

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

По материалам HuggingFace