PIM с ИИ-агентом: карточки на маркетплейсах создаются сами

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Агент поверх API и MCP снимает ручную рутину с карточек товаров — PIM из справочника превращается в исполнителя задач, но автономность клиенты принимают только после проверки в чате.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Справочник, который начал работать руками

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

Звучит как очередная обёртка над LLM. На деле интереснее другое: команда дошла до этого с четвёртой попытки, а первые три были обычной автоматизацией отдельных кусков работы. И ещё один момент, который мало кто обсуждает вслух. Автономность клиенты включают не сразу. Сначала они гоняют агента в режиме чата, проверяют, не наврал ли он с характеристиками и категориями, и только потом разрешают ему работать без присмотра.

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

Что такое PIM и почему она буксовала

PIM (product information management) — система управления данными о товарах. Задача простая на словах: собрать данные, обработать, отдать дальше. Карточка пылесоса на маркетплейсе по-хорошему должна быть результатом выгрузки из PIM, а не ручного заполнения в личном кабинете продавца. Список моторных масел с допуском RN17 — тоже вопрос к PIM.

Аналогия из соседней области: CRM относится к процессам с участием клиентов так же, как PIM относится к процессам с участием товаров. Только CRM внедряют все, а PIM — нишевая история, до которой доходят каталоги от нескольких тысяч SKU.

У описанной системы возможностей хватало. Сбор прайсов поставщиков в разных форматах, интеграции с Ozon, Wildberries, «Мерлионом» (бренды «Ситилинк» и «Позитроника»), модуль для «Битрикса», API. Каталоги в несколько миллионов товаров, доступ к библиотеке на 100 млн карточек и алгоритмы для работы с ними.

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

Это типичная ловушка зрелого B2B-продукта. Функций много, а время сотрудника клиента не экономится пропорционально их количеству.

Что именно построили

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

Архитектура, если разложить по полкам:

• чат на JavaScript — фронт, через который ставится задача;
• веб-сервер ASP.NET MVC со встроенным MCP-сервером;
• отдельный agent runner на Kestrel, который эту задачу исполняет.

MCP — протокол поверх JSON-RPC. Простая штука по сути: сервер принимает и отдаёт JSON определённой структуры. Агенты вроде Claude Code понимают и обычные API, но под MCP они оптимизированы, поэтому интеграция получается предсказуемее.

Под капотом — вызовы API, запуск Python-скриптов, которые дёргают C-библиотеки. Никакой мистики. Агент решает, какой инструмент вызвать и с какими параметрами, а дальше работает обычный код.

Было и стало

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

Четыре попытки: почему только сейчас

ИИ-функции в продукт пытались встроить лет пять. И каждый раз упирались в потолок модели.

Сначала модели справлялись только с генерацией описаний товаров по известным характеристикам. Всё остальное разваливалось. Классический пример: в спецификации указана версия Bluetooth, а модель не делает вывод, что товар умеет подключаться по беспроводной связи. Для человека это очевидно, для модели пять лет назад — нет.

Потом такие выводы освоили дорогие модели. А в этом году — относительно дешёвые: GPT-6 Luna с этой задачей справляется нормально. Это важнее, чем кажется. Пока нужный уровень рассуждений стоит дорого, автоматизация не окупается на потоке карточек.

Третьей точечной задачей стало распределение новых товаров по дереву категорий каталога. Полезно, но стратегии всё равно не было. Набор отдельных функций без общей идеи.

Перелом произошёл не в модели, а в инструментах вокруг неё. Claude Code появился в общем доступе в мае 2025 года, активное использование началось в декабре. Ещё полгода ушло, чтобы пройти путь от «пишем код с помощью агента» до «агент сам работает над задачами клиентов». Мысль очевидная, но в голову шла долго.

И, кстати, про код. Автор с 20-летним опытом признаёт, что в программировании агент уже лучше него. Это тема отдельного разговора, но она объясняет, почему барьер входа в такие проекты упал.

Прототип, который всё решил

Точкой отсчёта стал вечерний эксперимент. Агенту дали задачу присвоить коды ТНВЭД — товарной номенклатуры внешнеэкономической деятельности, без них не обходится импорт и декларирование.

Результат: 100 тысяч товаров за час работы.

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

Но вот что важно: если дать Claude Code просто список товаров и поставить задачу без инструментов, он её не решит. Прототип как раз давал агенту эффективные методы поиска данных о товарах и фильтрации кодов. Отсюда вывод, который стоит выписать на доску любому, кто планирует похожий проект.

Инструменты — половина успеха.

Половина, а не приятный бонус. Модель без правильно собранных инструментов превращается в генератор правдоподобных ответов, которые потом кто-то разгребает руками.

Чем это отличается от предшественников

Первое поколение ИИ в товарных системах — генерация текстов. Дали характеристики, получили описание. Полезно, но узко.

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

Третье — копилоты внутри интерфейса. Подсказывают, предлагают, но не действуют. По сути ускоряют клики.

То, что показали здесь, — четвёртая ступень. Агент получает задачу на естественном языке, сам решает, где искать данные, сам вызывает нужные API и сам доводит дело до выгрузки на маркетплейс. Человек проверяет итог, а не процесс.

И вот ещё отличие, которое легко упустить. Агент встроен в PIM, а не приделан сбоку. У него есть доступ к библиотеке на 100 млн карточек и к интеграциям с площадками. Внешний универсальный бот таким не располагает.

Кому это нужно и как применить

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

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

Третий — компании с внешнеэкономической деятельностью, где подбор кодов ТНВЭД висит на одном специалисте.

Практический порядок внедрения выглядит так:

1. Возьмите один узкий процесс, где результат легко проверить. Не весь каталог, а одну категорию.
2. Соберите инструменты под задачу: где агент берёт данные, чем фильтрует, куда пишет. Это самая трудоёмкая часть.
3. Погоняйте в чате на исторических данных, где ответ известен. Сравните с ручной работой.
4. Только после сходимости включайте автономный режим на новых товарах.

Шаг три не пропускайте. Соблазн большой — технически запустить агента в автономе несложно. Но именно на проверке в чате клиенты и принимают решение о доверии, и это правильный фильтр.

Где подвох

Автономность — не кнопка, а степень. Даже в описанной системе агент стартует в диалоге с человеком, и это не ограничение разработки, а нормальное поведение заказчика.

Дальше. Качество зависит от инструментов сильнее, чем от модели. Плохо описанные методы поиска и фильтрации — и вы получаете красивые карточки с неверными характеристиками. На маркетплейсе такое возвращается блокировками и снижением позиций, а не просто недовольством.

Третье. Стоимость работы агента — переменная. Токены, обращения к API, повторные попытки. На потоке в десятки тысяч SKU это нужно считать заранее, иначе экономика проекта поплывёт.

Четвёртое. Привязка к платформе. Агент живёт внутри конкретной PIM и опирается на её MCP-сервер и интеграции. Перенести эту логику в другую систему — отдельный проект.

Пятое. Ответственность за карточку никуда не делась. Если товар ушёл на площадку с неверным кодом ТНВЭД или категорией, разбираться будет бизнес, а не модель. Расхождения в десятые доли процента — хороший результат, но не ноль.

Брать или подождать: вердикт за 30 секунд

Брать, если у вас поток однотипных карточек, есть исторические данные для сверки и человек, который сможет оценить результат. Тогда первый пилот окупается на снятии рутины.

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

Не брать как волшебную кнопку. Покупаете не автономию, а инструмент, которому ещё предстоит доказать адекватность на ваших товарах.

Вердикт

Это заметный шаг для класса PIM. Система справочников превратилась в исполнителя задач, и произошло это не из-за прыжка в качестве модели, а из-за связки «агент + инструменты + MCP». Четвёртая попытка сработала потому, что изменился не интеллект модели в вакууме, а инфраструктура вокруг него.

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

FAQ

Агент сам придумывает характеристики товара?

Он ищет информацию в интернете и работает с данными внутри системы. Библиотека на 100 млн карточек и интеграции с площадками — его источник. Выдумывание характеристик — риск, который снимается проверкой на исторических данных.

Нужно ли уметь программировать, чтобы это использовать?

Пользователю — нет. Он пишет задачу в чат и прикладывает файл. Настройка инструментов под процессы — работа разработчика или интегратора.

Это работает только с Ozon?

Нет. В системе есть интеграции с Ozon, Wildberries, «Мерлионом» (бренды «Ситилинк» и «Позитроника»), плюс модуль для «Битрикса» и API. Сценарий с Ozon просто показан как пример.

Насколько точно агент присваивает коды ТНВЭД?

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

Можно ли сразу включить автономный режим?

Технически — да. Практически клиенты сначала тестируют агента в чате, оценивают адекватность и только потом доверяют ему самостоятельную работу.

Что важнее — модель или инструменты?

Инструменты как минимум не менее важны. Без методов поиска данных и фильтрации кодов агент задачу не решает даже на сильной модели.

Что делать на этой неделе

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