Claude Commerce Agent для WooCommerce: как устроены AI-помощники магазина

16 сентября 2026 года команда WooCommerce опубликовала практическую reference-реализацию Claude Commerce Agent для интернет-магазина. Это уже не просто чат рядом с каталогом: один агент помогает покупателю искать товары и собирать корзину, второй работает с данными магазина и готовит изменения для владельца.

Проект пока предназначен для экспериментов и прототипирования, а не для установки в production без доработки. Но архитектура полезна разработчикам и владельцам WooCommerce: она показывает, как связать AI-агента с Store API, обычным checkout и административными операциями так, чтобы модель не получала право бесконтрольно менять магазин.

Что выпустили WooCommerce и Anthropic

Основой стал открытый blueprint commerce agents от Anthropic. В официальном материале WooCommerce описаны два сценария: shopping agent для покупателя и merchant agent для владельца магазина.

Shopping agent умеет искать и сравнивать товары, планировать покупку из нескольких позиций, собирать корзину, отвечать по политикам магазина и помогать с отслеживанием заказа. Merchant agent работает с продажами, остатками и проблемными заказами, а также может предложить изменение цены, пополнение остатка, новый текст карточки или будущую акцию.

Ключевое отличие от опасной схемы «дать модели REST-ключ и разрешить всё» — административные записи проходят через human approval gate. Агент сначала показывает предлагаемое изменение и ждёт подтверждения.

Почему shopping agent не оформляет заказ сам

WooCommerce сознательно оставляет финальный checkout на стороне обычного магазина. Агент может собрать корзину, но не должен самостоятельно размещать заказ или принимать платёж.

Такой подход разделяет две зоны ответственности. AI помогает подобрать товары и подготовить покупку, а checkout остаётся в проверенном WooCommerce-потоке с реальными способами оплаты, налогами, доставкой и расширениями магазина.

Для коммерческого проекта это важнее эффектного демо: платёжный сценарий не нужно заново реализовывать внутри AI-интерфейса.

Как работает мост между агентом и корзиной WooCommerce

Reference-проект использует небольшой bridge plugin. Проблема в том, что корзина агента существует под своим Store API Cart Token, а браузер покупателя имеет отдельную WooCommerce-сессию.

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

Подробно механизм Cart Token и состояние headless-корзины я разбирал в статье про WooCommerce Store API и headless checkout.

Вариативные товары тоже должны разрешаться в конкретную variation

В демо WooCommerce отдельно отмечено, что размер или цвет разрешаются в конкретную вариацию, и именно она попадает в корзину. Это принципиально для реального каталога: родительский product ID недостаточен, если цена, остаток, вес или доступность зависят от variation ID.

AI-интерфейс может понимать человеческую фразу «чёрный, размер L», но backend обязан преобразовать её в реальные идентификаторы WooCommerce и снова проверить товар перед checkout.

Что может merchant agent

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

Но reference-реализация не применяет такую запись автоматически. Перед изменением показывается preview, а пользователь нажимает Approve. Даже просьба к агенту «подтверди себя сам» должна быть отклонена.

Для production это правильная база: чтение и анализ можно автоматизировать шире, а операции записи разделять по риску и требовать явного подтверждения там, где ошибка влияет на деньги, каталог или клиентов.

Почему REST API ключ нельзя отдавать публичному AI-сервису

Merchant service в reference-проекте использует REST-доступ с правами записи. WooCommerce прямо предупреждает: в демо нет полноценной аутентификации, поэтому сервис нельзя просто выставлять в интернет.

Production-версия должна находиться за собственной авторизацией, ограничивать доступ по ролям и журналировать действия. Ключи WooCommerce нельзя помещать во frontend bundle или отдавать браузеру. Практические правила для Consumer Key и Consumer Secret собраны в материале о безопасной авторизации WooCommerce REST API.

Reference-проект — не готовый плагин для production

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

• Нет полноценного undo. Возврат изменения фактически означает подготовку нового изменения со старым значением.
• Нет долговечного audit log. После перезапуска история диалога теряется, а изменения в WooCommerce выглядят как действия пользователя API-ключа.
• Нет встроенной аутентификации сервисов. Merchant endpoint с write-доступом нужно обязательно закрывать собственной системой доступа.
• Есть ограничения по объёму данных. Reference-логика ориентирована на небольшие магазины и сканирует ограниченное число последних заказов и товаров.
• Нет трафика и conversion data из WooCommerce core. Для маркетинговых выводов понадобятся дополнительные источники аналитики.
• Поиск товаров основан на keyword retrieval. Модель делает семантическую работу поверх результатов, но не сможет рассуждать о товаре, который базовый поиск вообще не вернул.

Почему approval gate недостаточно без idempotency

Даже подтверждённое действие может быть отправлено повторно из-за timeout, retry или сетевой ошибки. Если команда «изменить цену» или «пополнить остаток» выполняется через внешнюю очередь, каждому действию нужен стабильный идентификатор операции.

Backend должен уметь отличить повтор доставки от нового намерения пользователя. Тот же принцип используется в надёжных webhook и API-интеграциях с idempotency.

Архитектура production-версии

1. AI frontend. Принимает запрос покупателя или менеджера и показывает предложения агента.
2. Agent backend. Хранит контекст, вызывает модель и решает, какие инструменты доступны конкретной роли.
3. WooCommerce adapter. Отдельный слой для Store API и административного REST API, а не прямой произвольный доступ модели.
4. Policy layer. Проверяет разрешённые операции, лимиты, товары и поля.
5. Approval queue. Сохраняет изменения до подтверждения человеком.
6. Idempotency и audit log. Фиксируют intent, approval, фактический API-запрос и результат.
7. Monitoring. Отслеживает ошибки модели, WooCommerce API, фоновых задач и внешних сервисов.

Где размещать такого агента

Reference-реализация WooCommerce — отдельный self-hosted Python service рядом с WordPress. В официальном примере backend требует Python 3.11+, frontend использует Node 22 и Next.js, а локальный тестовый магазин запускается через Docker.

Это означает, что обычного дешёвого shared hosting может быть недостаточно. Для production удобнее VPS или контейнерная платформа, где можно раздельно обновлять WordPress, agent backend и frontend, настраивать секреты, reverse proxy, health checks и логи.

Что проверить перед подключением к реальному магазину

• начать со staging-копии, а не с production;
• создать отдельные API credentials с минимально достаточными правами;
• закрыть merchant service аутентификацией;
• не позволять модели выполнять произвольные REST-запросы;
• оставить оплату в штатном WooCommerce checkout;
• повторно проверять остаток, цену и variation перед добавлением в пользовательскую корзину;
• для записей использовать preview и approval;
• добавить audit log и idempotency;
• ограничить число и стоимость запросов к модели;
• проверить поведение при недоступности Claude, WooCommerce API и базы.

Кому эта архитектура полезна уже сейчас

Reference-проект особенно интересен магазинам с большим каталогом, сложным подбором товаров, B2B-сценариями и менеджерами, которым приходится регулярно проверять остатки и заказы. Но внедрять его стоит не как «чат ради AI», а вокруг конкретного процесса.

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

Вывод

Claude Commerce Agent показывает направление, в котором AI-интерфейс становится рабочим слоем над WooCommerce, а не отдельным виджетом. Самая полезная часть reference-архитектуры — не генерация текста, а разделение прав: покупательский агент собирает намерение и корзину, merchant agent готовит изменения, а критичные действия остаются под контролем WooCommerce и человека.

Если нужен AI-агент для каталога, заказов, CRM или внутренних процессов магазина, A.S Groups может спроектировать интеграцию с WooCommerce API, безопасным хранением ключей, approval-механикой и журналированием. Опишите задачу — подберём архитектуру под существующий магазин и инфраструктуру.