Anthropic открыла Claude Commerce Agents: чертёж торгового агента на Claude

Anthropic 2 сентября 2026 года открыла исходники Claude Commerce Agents: двух агентов на Claude для интернет-торговли под лицензией Apache 2.0. Первый, покупательский, бизнес встраивает в своё приложение для клиентов. Второй, мерчантский, нужен сотрудникам, чтобы вести листинги, цены, остатки и кампании. В репозитории anthropics/commerce-agents лежат оба агента, четыре демонстрационные вертикали (розница, путешествия, телеком, билеты), семь pip-пакетов и плагин для Claude Code, который собирает такого агента под чужой стек.

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

Оговорка стоит в самом README: это референсная реализация, она не поддерживается и не принимает внешний вклад. В примерах нет аутентификации, MCP-серверы по умолчанию слушают loopback.

Четыре вертикали из анонсирующего видео. Скриншот: Anthropic, commerce-agents

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

README репозитория anthropics/commerce-agentsAnthropic (перевод: «Ничто не размещает заказ, не списывает деньги с карты и не меняет живой листинг: checkout отображает корзину, а завершает её хост, и каждая запись мерчанта ждёт, пока её одобрит человек»)

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Состав поставки по README репозитория. График: Tproger по данным README anthropics/commerce-agents

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

			from pathlib import Path

from shopping_agent import ShoppingAgentConfig
from shopping_agent_runtime import ShoppingAgent

agent = ShoppingAgent(backend=your_backend, skills_dir=Path("shopping-agent/skills"),
                      config=ShoppingAgentConfig(brand_name="Your Store"))
async for event in agent.stream_turn(messages, session, state):
    ...   # text_delta, tool_call, ui, cart_update (change_update on the merchant side), turn_complete
await agent.update_memory(messages, session)   # memory extraction; this path only
		

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

docs/safety.md репозитория anthropics/commerce-agentsAnthropic (перевод: «Правило, применяемое внутри вызова инструмента, действует на всех трёх путях, потому что рантайм Messages API, набор инструментов SDK и MCP-сервер выполняют инструменты через один и тот же исполнитель»)

Что именно проверяется в коде, по таблице документа:

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

Лимиты, которые проверяет код: память покупателя и размер одного ограждения. График: Tproger по данным docs/safety.md и docs/backends.md anthropics/commerce-agents

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

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

docs/safety.md репозитория anthropics/commerce-agentsAnthropic (перевод: «Когда модель нарушает одно из этих правил, ошибка остаётся в её тексте. Каждая запись, цифра и раскрытие за этим текстом всё равно прошли проверки из таблицы выше, так что сбой сводится к неверной формулировке, которую нужно исправить, и ни одно действие откатывать не надо»)

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

README репозитория anthropics/commerce-agentsAnthropic (перевод: «Каждый из них вызывает ваш сервис на стороне сервера с учётными данными, которые хост держит для сессии; модель читает только результат»)

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Кадр «From intent to a staged order» из анонсирующего видео. Скриншот: Anthropic, commerce-agents

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

			from claude_agent_sdk import ClaudeSDKClient
from shopping_agent_sdk import make_options

options, toolset = make_options()
options.env.update({"CLAUDE_CODE_USE_BEDROCK": "1", "AWS_REGION": "us-east-1"})
options.model = "us.anthropic.claude-sonnet-5"
async with ClaudeSDKClient(options=options) as client:
    ...
		

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

			git clone https://github.com/anthropics/commerce-agents.git && cd commerce-agents
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt       # the seven packages and their pinned dependencies
cp .env.example .env                  # add ANTHROPIC_API_KEY
(cd examples && npm ci)               # the eight web apps share one workspace
python scripts/run_demo.py retail     # API :8000 + storefront :3000
		

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

			claude plugin marketplace add anthropics/commerce-agents
claude plugin install commerce-builder@claude-commerce-agents
claude
/scaffold-commerce-agent a shopping assistant for our store
		

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents