Создание безопасных бэк-офисных ИИ-агентов с помощью commercetools for Builders

Один сервер MCP для каждой задачи

Commerce MCP преобразует API commercetools более чем в 100 инструментов, которые может вызывать ИИ-агент, каждый из которых имеет множество параметров и полные ответы. Эта универсальность полезна, когда разработчик изучает проект, но это неверный выбор по умолчанию для бэк-офисного агента, выполняющего одну задачу, например создание акции или составление черновика письма для клиента.

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

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

Инструменты не знают ваш проект. Описания универсальных инструментов объясняют API, а не вашу модель данных. Какие категории существуют? По каким атрибутам продуктов агент может выполнять поиск? Какой пользовательский тип он должен использовать при создании чего-либо? Без этого контекста агент либо тратит вызовы на выяснение ответов, либо угадывает.

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

Управляемые серверы MCP: сфокусированная поверхность для каждого агента

Управляемые серверы MCP — это размещенные версии Commerce MCP, которые вы настраиваете централизованно, как правило, по одному серверу на агента. Для каждого сервера вы можете:

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

Поскольку commercetools размещает сервер, она также обеспечивает соблюдение конфигурации. Учетные данные агента достигают только его сервера MCP, а не API за ним, поэтому агент не может обойти ограничения, вызывая API напрямую. Сама конфигурация доступна через API, поэтому вы можете тестировать изменения на промежуточном проекте (Staging Project) и продвигать их по конвейеру, а Platform Insights показывает, как каждый агент использует свой сервер.

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

Поручите настройку навыку

Знать, какие рычаги существуют — это простая часть. Выбор правильных инструментов, полей и описаний для одного агента в одном проекте — вот где заключается основная работа. Именно это для вас делает навык commercetools MCP, являющийся частью commercetools for Builders. Вы описываете задачу агента своими словами, и навык:

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

2. Читает реальные данные вашего проекта через подключенный Commerce MCP, вместо того чтобы строить решения на основе предположений.

3. Предлагает минимальный набор инструментов, фильтры полей и переписанные описания инструментов, а затем ожидает вашего подтверждения.

4. Создает управляемый сервер MCP.

5. Тестирует сервер с помощью слепых тестовых агентов и производит итерации на основе возникающих у них проблем.

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

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

Главный вывод: конфигурация, составленная на основе данных, — это первое приближение. Только агент без ваших проектных заметок может сказать вам, работает ли она.

Пример 1: Персональные скидочные коды для магазина велосипедов

Рассмотрим магазин, который продает шоссейные, гравийные и горные велосипеды, а также одежду и аксессуары. Маркетинговая команда хочет получить агента, который водит постоянных клиентов персональным скидочным кодом. Для каждого клиента агент должен:

1. Проанализировать прошлые заказы, чтобы понять, на чем ездит и что покупает клиент: шоссе, гравий или горы; мужской или женский ассортимент; и что они купили недавно. Тот, кто только что купил шлем, не нуждается в еще одном.

2. Найти шесть продуктов из как минимум двух категорий, которые станут хорошими рекомендациями.

3. Создать скидочный код, который применяется к трем подходящим категориям.

Вот как навык формирует конфигурацию для этого агента:

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

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

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

Главный вывод: спросите, что агент читает и что он пишет, а затем дайте ему именно это.

Пример 2: Рекомендации с учетом погодных условий из двух источников данных

Бэк-офисные агенты редко работают с единственной системой. Для нашего второго примера агент объединяет commercetools с сервисом погоды для написания персональных рекомендаций по продуктам:

1. Найти почтовый индекс клиента.

2. Запросить у сервера MCP погоды прогноз для этого местоположения.

3. Найти три продукта, соответствующих погоде.

4. Написать рекомендательное письмо.

Мы использовали mcp-weather-free, сервер MCP с открытым исходным кодом для бесплатного API Open-Meteo, наряду с управляемым сервером MCP, настроенным с помощью навыка. Любой сервер погоды MCP работает точно так же.

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

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

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

Запуск в качестве навыка в Claude Desktop

После настройки MCP-сервера рабочий процесс агента может существовать в виде локального навыка в Claude Desktop. Описанные выше шаги выполняются один раз, и член команды вызывает навык всякий раз, когда ему требуется пакет рекомендаций или кодов скидок. Человек проверяет каждый результат перед тем, как он попадет к клиенту.

Для такой схемы с участием человека в контуре управления настройте сервер в режиме аутентификации CommercetoolsIdentity. Каждый пользователь входит в систему под тем же учетным знаком, который он использует для Merchant Center, поэтому не нужно создавать или передавать учетные данные API. Инструменты, которые видит пользователь, являются результатом пересечения конфигурации сервера и его прав в Merchant Center, причем изменения прав вступают в силу без вмешательства в работу сервера.

Развертывание в качестве автономного агента

Когда рабочий процесс начинает работать стабильно, его можно перенести на автономного агента, который запускается по расписанию или реагирует на события, например, на базе Amazon Bedrock AgentCore. Изменяются три вещи:

• Аутентификация. Токены действительны в течение максимум 30 дней. Официальные SDK MCP для TypeScript и Python могут получать и обновлять их с помощью учетных данных API Client, а AgentCore Gateway может делать то же самое, если настроить MCP-сервер в качестве цели с учетными данными клиента для исходящей авторизации. В других фреймворках получайте токен самостоятельно и продумывайте механизм его обновления агентом.
• Внедрение. Относитесь к конфигурации MCP-сервера как к части агента: протестируйте ее на промежуточном проекте (staging) и перенесите через тот же конвейер.
• Наблюдаемость. Platform Insights отслеживает использование для каждого MCP-сервера, позволяя видеть, как агент использует свои инструменты в продакшене.

Руководство по началу работы охватывает настройку для каждого режима аутентификации.

Прежде чем создавать своего первого бэк-офисного агента

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

1. Четко сформулируйте одну задачу агента и определите, кто будет его запускать.

2. Предоставьте агенту собственный управляемый MCP-сервер (Managed MCP Server) только с теми инструментами, которые необходимы для этой задачи.

3. Определите, какие поля может возвращать каждый инструмент, еще до написания единого промпта.

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

Установите навык commercetools MCP и изучите другие наши навыки, руководства и инструменты в библиотеке commercetools for Builders или свяжитесь с нашей командой для получения дополнительной информации.