ИИ-агент в PIM: как перейти от генерации описаний к выполнению задач

Редакция APICODIK · 25.10.2026

Разбираем архитектуру PIM с ИИ-агентом: доступ к инструментам через MCP, контекст интерфейса, автономные сценарии и ограничения автоматизации.

*Редакционный черновик APICODIK. Требует проверки человеком перед публикацией.*

Добавить генератор описаний товаров и передать агенту подготовку карточек для маркетплейса — разные уровни автоматизации. В первом случае модель выполняет отдельную операцию. Во втором ей нужны доступ к данным, инструменты изменения каталога и возможность довести запрос до результата.

Автор [кейса на Хабре](https://habr.com/ru/articles/1098978/?utm_campaign=1098978&utm_source=habrahabr&utm_medium=rss) рассказывает, как его команда встроила такой подход в существующую PIM-платформу. Основное изменение произошло не в хранении товарных данных, а в способе работы с системой: вместо самостоятельной настройки последовательности действий пользователь может поручить задачу агенту. При этом интеграции и прикладная логика остались на стороне платформы.

Что изменилось для пользователя

PIM управляет информацией о товарах: собирает сведения, помогает их обрабатывать и передаёт дальше, например в карточки маркетплейсов. В описанном продукте уже были загрузка прайс-листов, поиск товарных данных, интеграции и API. Однако пользователю всё равно приходилось разбираться в настройках, писать формулы и контролировать операции.

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

Новый подход объединяет действия вокруг пользовательского поручения. Например, человек загружает файл с названиями товаров и просит создать карточки на маркетплейсе. Агент получает возможность искать недостающие сведения, обрабатывать файл и обращаться к функциям платформы. Чат здесь становится не только справочником, но и интерфейсом выполнения работы.

Почему агент не заменяет PIM

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

Это важное разделение ответственности. Как объясняет автор, интеграции содержат накопленный опыт работы с реальными данными, включая случаи, которых нет в документации внешних API. Готовая платформа также предоставляет алгоритмы обработки и структурированную товарную информацию. Агенту не нужно собирать всё это под каждую задачу.

Массовые вычисления команда тоже не переносит в контекст модели. Для обработки больших массивов агент может написать и запустить Python-код. Для таблиц и документов ему предоставлены библиотеки, в том числе pandas и openpyxl. В такой схеме модель выбирает способ решения, а обработку данных выполняют программы.

Как устроен исполнительный контур

Пользовательский чат встроен в страницы существующего веб-приложения. Сервер на ASP.NET MVC принимает запросы и связывает интерфейс с остальными компонентами. Отдельный процесс — agent runner — подготавливает окружение, запускает исполнителя и передаёт ему поручение.

Раннер также работает с файлами сессии: размещает загруженные документы и обеспечивает получение файлов, созданных агентом. Браузер не обращается к нему напрямую. По описанию автора, на момент подготовки кейса поддерживались Claude Code и OpenCode, а единый интерфейс раннера позволяет подключать других исполнителей.

Доступ к функциям PIM организован через MCP-сервер. Через него агент вызывает инструменты платформы, получает документацию и сведения о страницах. Сам агент взаимодействует с API языковой модели, выполняет запрошенные ею действия и возвращает результаты в следующий шаг диалога.

Практический смысл разделения — возможность менять исполнителя и настройки модели, не перестраивая пользовательский интерфейс и прикладные интеграции целиком.

Контекст интерфейса оказался частью инфраструктуры

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

Для представления страниц разработчики сделали собственный ViewEngine: он отдаёт более компактные данные вместо полного HTML. Документацию тоже не загружают целиком. Она организована иерархически: от описания сервиса и разделов до конкретных страниц и функций. Агент запрашивает нужные подробности по мере работы.

Такой подход в кейсе решает две задачи: ограничивает объём контекста и уменьшает количество посторонней информации. Если документации недостаточно, агент может обратиться к представлению самой страницы.

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

Автономность требует границ

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

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

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

Что можно заключить о результате

Автор сообщает, что обращений в техподдержку стало приблизительно втрое меньше. Одновременно пользователи задают агенту вопросы, с которыми раньше не обращались к сотрудникам поддержки. Это наблюдение о работе конкретного сервиса, а не доказательство универсальной экономии от ИИ.

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

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