ИИ-агент для учётной системы «Гермес»: как мы построили платформу ИИ-агентов вокруг легаси-ERP

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

Клиент — оптовая торговля стройматериалами и электрикой. Учёт ведётся в «Гермесе», рядом стоит 1С для бухгалтерии, всё это скрещено самописными обменами и работает годами. Заменить «Гермес» — не вариант: там сидят двадцать человек, привыкшие к своим экранам, там завязаны отчёты, права, ночные регламенты. Задача была другая: не трогая систему, дать людям способ спрашивать её живым языком.

Почему один LLM без обвязки — это не платформа ИИ-агентов

Первым делом мы попробовали самое очевидное: взять языковую модель, дать ей описание таблиц «Гермеса», обучить на паре десятков примеров запросов и посмотреть, что выйдет. Вышло предсказуемо плохо. Агент модели ИИ бодро генерировал SQL, который выглядел правдоподобно, но иногда обращался к несуществующим полям, иногда путал справочник контрагентов со справочником сотрудников, а на вопрос «сколько у нас алюминиевого кабеля на складе в филиале» уверенно выдавал число, взятое, кажется, из воздуха.

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

Мы перепроектировали решение. В центре — оркестратор, вокруг него MCP-серверы под конкретные операции: остатки, движения, цены, заказы, контрагенты. Каждый сервер знает свой узкий срез схемы и умеет отвечать только на строго определённые запросы. Модель больше не пишет SQL руками — она выбирает инструмент и заполняет его параметры. Если параметр не влезает в схему — инструмент возвращает понятную ошибку, а не молчаливое «ничего не найдено».

Как устроен ИИ-агент «Гермес» под капотом

MCP-серверы мы вынесли отдельным сервисом на FastAPI. Каждый сервер — тонкая обёртка вокруг заранее написанных и провалидированных запросов к базе «Гермеса». Никакого свободного SQL от модели. Модель может попросить: «дай остатки по номенклатуре X на складе Y на дату Z» — и получит либо цифры, либо структурированный отказ, если, например, склад не существует.

Такой подход резко изменил природу ошибок. Раньше модель могла сгенерировать синтаксически корректный, но семантически бессмысленный запрос и вернуть уверенный ответ на выдуманных данных. Теперь ошибка либо ловится валидатором параметров, либо превращается в честное «такого склада нет, вот список тех, что есть». ИИ-агенты, отвечающие пользователю, стали заметно скучнее — и заметно надёжнее.

Сверху — маршрутизатор запросов. Простые вопросы вроде «остаток по артикулу» идут в лёгкий инструмент без обращения к базе знаний. Сложные, с уточняющими условиями и сравнениями периодов, попадают в отдельный сценарий с несколькими вызовами инструментов подряд. Это не декоративная оптимизация: без маршрутизации счёт за модель улетал в потолок на самых банальных запросах.

Какую модель поставить агенту

Здесь мы упёрлись в специфику клиента: данные торговли и остатков — коммерческая тайна, у части поставщиков в контрактах прямо прописано, что информация не должна покидать российский контур. Значит, зарубежные модели по API отпадают. Оставались GigaChat Pro, YandexGPT и локальные варианты вроде Cotype и T-lite.

Мы прогнали три модели на одном и том же наборе типовых запросов. GigaChat Pro лучше держал многошаговые сценарии — те, где нужно сначала уточнить склад, потом дату, потом номенклатуру. YandexGPT давал сравнимые ответы на прямых вопросах, но иногда терял контекст на третьем-четвёртом ходу диалога. T-lite в локальной установке подошёл для совсем узких сценариев, где хватало короткого промпта и одного вызова инструмента.

В итоге поставили GigaChat Pro как основную модель на диалоговый слой и оставили лёгкий вариант для маршрутизации и разбора однострочных запросов. Это дало и приемлемое качество, и предсказуемый счёт за токены. Заодно закрыли вопрос с 152-ФЗ: данные не уходят за пределы российского контура, а у клиента — договор с оператором ПДн, где всё аккуратно прописано.

Что делает ИИ-агент, когда не уверен

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

Сейчас агент честно возвращает уточняющий вопрос: «нашёл двенадцать групп с медным кабелем, назовите сечение или марку». Это скучный ответ, но правильный. Мы намеренно снизили порог самоуверенности модели — лучше лишний раз переспросить, чем выдать красивую, но неверную сводку. Кладовщики к такому режиму привыкли за пару дней: они и между собой так же переспрашивают.

Второе — все ответы, где фигурируют цифры, содержат ссылку на источник: артикул, партию, склад, дату среза. Не потому что пользователю это нужно каждый раз — большую часть времени он смотрит только на сам ответ. А потому что, когда что-то не сошлось, разбор занимает минуты, а не полдня.

Что изменилось у клиента

Через пару месяцев работы агента поменялась не столько скорость отдельного запроса, сколько сам характер работы. Менеджер по продажам больше не отвлекает кладовщика по мелочи — спрашивает у агента через чат в мессенджере. Кладовщик стал заниматься тем, ради чего его наняли, а не отвечать на «есть или нет». Руководитель отдела перестал получать сводки к концу дня и смотрит текущий срез, когда ему нужно.

По ощущениям — задачи, на которые раньше уходил час беготни между окнами, теперь закрываются за пару минут в чате. Ошибок стало заметно меньше, потому что человек не переносит цифры глазами из «Гермеса» в письмо. А сама учётная система осталась ровно такой, какой была — мы не переписали ни одной формы и не тронули ни одной хранимой процедуры.

Что мы вынесли для себя

Первое: платформа ИИ-агентов вокруг легаси-системы — это не про то, чтобы заменить интерфейс. Это про то, чтобы дать людям альтернативный способ доступа, оставив старый в неприкосновенности для тех, кому он привычен и нужен.

Второе: чем больше конкретики зашито в инструменты, тем меньше требований к модели. Хороший MCP-сервер прощает модели неточности формулировок. Плохо описанный инструмент требует умного языкового движка, который сам догадается — а это самый дорогой и самый ненадёжный способ.

Третье: доверие пользователей к ИИ-агенту растёт не с точности ответа, а с честности отказа. Агент, который иногда говорит «уточните, пожалуйста», воспринимается как коллега. Агент, который всегда отвечает уверенно, — как рулетка.

И главный вопрос, который остаётся после каждого такого проекта: где ещё в компании стоят системы, которые все ненавидят открывать глазами, но которые проще не менять? Скорее всего, это и есть следующая точка, куда стоит поставить своего ИИ-агента.