Торговые агенты на Claude: код открыт под Apache 2.0

Anthropic 10 сентября открыла код двух торговых агентов на Claude. Каждый описан один раз, через промпт, навыки, контракты инструментов и гейты (проверки, которые стоят перед вызовом инструмента), и без изменений запускается на трёх платформах: Messages API, Claude Agent SDK и Managed Agents. От бизнеса требуется реализовать один интерфейс к своим системам, а всё, что меняет реальный мир, агент только готовит, но не выполняет.

Репозиторий commerce-agents на Github служит рабочим кодом к набору шаблонов для торговых агентов. В своём описании Anthropic говорит, что у корпоративных клиентов вроде Shopify и Priceline такие агенты уже работают: покупатель на обычном языке ищет, сравнивает и покупает. Партнёрами, которые помогают внедрять шаблоны у клиентов и продавцов, компания называет Accenture, Mastercard и Visa.

Два агента, два интерфейса

Покупательский агент бизнес встраивает в своё приложение для клиентов. Агент ищет и сравнивает товары, планирует покупку из нескольких позиций, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что рассказал о себе покупатель. Пять его сценариев лежат навыками в shopping-agent/skills/. Чтобы подключить его к магазину, разработчик реализует StorefrontBackend поверх каталога, корзины, заказов и правил.

Агент продавца работает на сотрудников и ведёт бэк-офис. Он объясняет, как идут продажи, поддерживает карточки товаров, реагирует на алерты по остаткам и заказам, ставит цены и акции и пишет черновики кампаний. По описанию Anthropic, он, например, замечает товар, который закончится раньше, чем стартует промоакция, а цены и скидки предлагает по истории продаж самого магазина. Его пять сценариев лежат в merchant-agent/skills/, а подключается он через MerchantBackend к аналитике, каталогу, складу, ценам и кампаниям.

Ни одной настоящей компании в репозитории нет. Все бренды, товары и люди выдуманы, единственная компания называется ACME.

Код разложен на семь Python-пакетов. Общее для обеих ролей вынесено в commerce-common: конфигурация, память, навыки, привязка ответов к данным, слой отображения, события. У каждого агента свой пакет ядра с типами, промптом, контрактами инструментов, гейтами и исполнителем, плюс по пакету на Messages API и на Agent SDK. Для Managed Agents вместо пакета лежат манифест и MCP-сервер, а у агента продавца ещё и дайджест по расписанию.

Что агент не делает

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

У агента продавца любая запись превращается в подготовленное изменение. Применяет его интерфейс одобрения на стороне хоста, и только после того, как человек согласился. В консольной версии на Agent SDK одобрение выглядит буквально как вопрос y/N перед каждым изменением.

Защиту в репозитории делят на два слоя. Изоляция недоверенного текста, проверки происхождения данных, лимиты, валидация памяти и гейт одобрения у агента продавца работают внутри самого вызова инструмента, поэтому действуют на всех трёх платформах. Привязка ответов к данным, бюджеты на анализ и извлечение памяти реализованы в рантайме, так что их набор зависит от пути запуска. Каждое правило с модулем и путями описано в docs/safety.md, там же сказано, что деплойменту стоит добавить первым. Anthropic формулирует цель ограничителей так: цены и товары в ответах должны браться из реального каталога, а манипулятивных допродаж агент избегает.

Бизнес-правила, авторизация и соответствие требованиям остаются за деплойментом. В демо аутентификации нет, а MCP-серверы слушают только loopback.

Три способа запуска

Эталонный цикл написан на Messages API, и все примеры в репозитории представляют собой хост-приложения вокруг него. Хост создаёт ShoppingAgent с бэкендом, папкой навыков и конфигом с названием магазина и стримит ход через stream_turn. Наружу идут события text_delta, tool_call, ui, cart_update (у агента продавца вместо него change_update) и turn_complete. Память после хода извлекает update_memory, и только на этом пути. Идентификатор сессии хосты из примеров принимают в заголовке X-Session-Id.

На Agent SDK промпт, навыки и инструменты те же, но цикл крутит SDK. Данные для привязки ответов хост подгружает заранее, а после хода ничего не выполняется, поэтому извлечения памяти здесь нет. Проверить покупательского агента можно одной командой: python shopping-agent/runtime-agent-sdk/main.py --once "a two-person tent under $250".

Третий вариант, Managed Agents, разворачивает хостовую версию агента с теми же навыками и контрактами, которая ходит в ваш MCP-сервер. Деплой делает scripts/deploy_managed_agent.sh, без флага --live он работает вхолостую.

Рантаймы принимают любой клиент anthropic через параметр client=, а версии на SDK берут платформу из окружения CLI. В docs/deployment.md описаны GCP Vertex AI, AWS Bedrock, Microsoft Foundry и шлюзы.

Отдельно в README объяснено, как убедиться, что работает кэширование промпта. Нужно смотреть cache_read_input_tokens в событии turn_complete или в строке, которую каждый вызов модели пишет в лог рантайма. Ноль на втором ходе означает, что префикс промпта изменился.

Пилот из двух методов

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

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

Если у бизнеса какой-то системы нет совсем, например корзины на реферальной витрине или отслеживания заказов, её выключает переключатель enable_*. Он убирает связанные инструменты, строки промпта и правило привязки к данным на всех путях запуска, а зависящие от системы сценарии откладываются в skills/_staged/. У агента продавца такие же переключатели есть для правки карточек, склада, цен и кампаний.

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

Готовых MCP-коннекторов в репозитории нет, оба агента ходят в системы бизнеса через интерфейсы бэкенда. Там, где источником истины служит официальный коннектор, интегрироваться предлагают с ним: это хранилища аналитики (Snowflake, BigQuery, Databricks, Amplitude), финансы (Stripe, Square, PayPal, QuickBooks) и доставка результатов (Slack, Google Drive, Gmail). Собственный MCP-сервер торговой платформы для каталога, корзины или чекаута вызывается из метода бэкенда на сервере. На Managed Agents манифест монтирует его рядом с сервером роли, и проверки происхождения данных всё равно стоят перед каждой записью.

Свой сценарий добавляется как папка с SKILL.md внутри одной из папок skills/, отраслевой интерфейс как PresentationExtension. Имя бренда, имя ассистента и тон задаются полями brand_name, assistant_name и brand_voice. Для сборки с нуля есть плагин commerce-builder для Claude Code: /scaffold-commerce-agent расспрашивает о стеке, пересказывает план и собирает проект, /add-commerce-flow и /author-commerce-evals продолжают работу, а /review-commerce-agent разбирает уже существующего агента. Склонированный репозиторий плагин читает как эталон.

Четыре витрины ACME

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

• ритейл: поиск, сравнение, планы покупок, корзина, чекаут и память на встроенных компонентах; в портале продавца дайджест, подготовленные пополнения склада и исправления карточек, плюс аналитический делегат поверх SQL-представления;
• путешествия: инвентарь с привязкой к датам и расширение present_itinerary для маршрута; у продавца календарь загрузки и изменения тарифов в окне дат;
• телеком: контекст аккаунта, матрица тарифов и раскрытие сборов, которое пишет сервер, а не модель; у продавца изменения цен с указанием затронутых линий и защищённые регулируемые сборы;
• билеты: брони с таймером, листы ожидания, передача билетов, схема зала и полная цена со всеми сборами; у продавца темп продаж по событию, снятие броней, которое добавляет реальную вместимость, и изменения цен без потери сборов.

Для запуска нужны Python 3.11+ и Node 22. После клонирования, установки зависимостей и ключа в .env команда python scripts/run_demo.py retail поднимает API на порту 8000 и витрину на 3000. Флаг --merchant вместо витрины запускает портал продавца, --all запускает оба. Витрины путешествий, телекома и билетов слушают порты 3001, 3002 и 3003, их порталы 3101, 3102 и 3103, у ритейла портал на 3100. В README каждого примера есть раздел Try: реплики, которые прогоняет scripts/smoke_chat.py, и отдельные запросы с описанием того, как выглядит хороший ответ.

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

Код открыт под Apache 2.0. Anthropic называет его эталонной реализацией: репозиторий не поддерживается и контрибуций не принимает.