Commerce-агенты Anthropic: как устроен практический шаблон на Claude

Что Anthropic выпустила на самом деле

Anthropic опубликовала open-source reference implementation для commerce-агентов и репозиторий anthropics/commerce-agents. Это не обещание автономного «ИИ-продавца» и не готовый сервис, который можно без доработок подключить к магазину. Ценность релиза в прикладной схеме: модель ведёт диалог и выбирает следующий шаг, а данные, доступы и критичные операции остаются в системах компании.

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

Слово «готовый» здесь важно не переоценивать. В демонстрациях используются тестовые данные, а сам проект прямо обозначен как reference implementation. Компании всё равно нужно сопоставить свои сущности и API с интерфейсами проекта, определить источники истины, реализовать авторизацию, аудит и правила выполнения операций.

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

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

Не чат-бот, а цикл модели с инструментами

В предложенной архитектуре Claude работает в agent loop: повторяющемся цикле модели и инструментов. Агент получает цель пользователя и контекст сессии, выбирает доступный инструмент, получает структурированный ответ, уточняет план и при необходимости делает следующий шаг. Инструментом может быть адаптер к каталогу, корзине, заказам, политике возврата, аналитике, ценам или остаткам.

Для commerce это не косметическая деталь, а базовое разграничение. Модель способна понять запрос вроде «нужны кроссовки для дождя в заданном бюджете», сформировать поиск, сравнить варианты и объяснить выбор. Однако наличие конкретного размера, цена в регионе и срок доставки должны вернуться из backend-системы. Если вариант недоступен, агент сообщает об этом или предлагает альтернативу, а не достраивает коммерческий факт вероятностным предположением.

В репозитории выделены интерфейсы StorefrontBackend для клиентского сценария и MerchantBackend для внутреннего. Это границы интеграции, а не универсальные коннекторы к ERP, PIM, OMS или CRM. Когда один запрос затрагивает каталог, фулфилмент и правила доступности, их склейку разумно оставить серверному endpoint с ясным контрактом, а не поручать модели выбор между разрозненными системами.

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

• LLM понимает запрос, планирует действия и формулирует ответ.
• Инструменты возвращают проверяемые данные и исполняют только разрешённые действия.
• Сервер проверяет полномочия, состояние объектов и ограничения до обращения к критичным системам.

Skills: когда один агент лучше избыточной иерархии

Для базового commerce-сценария Anthropic предлагает один agent loop с подключаемыми skills: пакетами профильных инструкций и процедур. У shopping agent это могут быть поиск и discovery, исследование перед покупкой, подбор комплекта, поддержка и память с персонализацией. Для merchant agent выделены аналитика, каталог, запасы, цены, промо и кампании.

Такое устройство не требует держать в постоянном контексте все процедуры сразу. Постоянные правила, ограничения, заземление в данных компании и соглашения с интерфейсом относятся к system prompt. Более редкие или объёмные процедуры можно хранить в skills и подключать по ситуации. Авторы blueprint предлагают эвристику: инструкция, нужная в значительной доле запросов, вероятнее всего должна остаться в постоянном prompt. Это рабочая рекомендация, а не универсальный закон проектирования.

Anthropic сообщает, что в её сравнении один агент со skills показывал лучшие результаты, чем чрезмерно большой единый prompt или схема с субагентами. В ряде случаев подход также снижал задержку и стоимость. Но опубликованные материалы не дают независимой методики и не подтверждают переносимость вывода на любой ритейл-контур, поэтому это гипотеза для собственного пилота, а не готовое обоснование архитектуры.

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

• System prompt задаёт постоянные правила и границы поведения.
• Skills добавляют специализированную процедуру по мере необходимости.
• Субагента стоит вводить для действительно автономной работы, а не ради формального деления процесса на «отделы».

UI и checkout: сделка не должна происходить внутри реплики

Текстового ответа недостаточно ни для покупки, ни для внутреннего коммерческого решения. Anthropic предлагает возвращать товары, сравнения, планы и корзину как структурированные UI-компоненты через инструменты. Пользователь видит карточки, таблицы и элементы управления, а агент получает представление о том, что уже показано в сессии.

Это сокращает неоднозначность. Просьбу «добавь второй вариант» можно связать с конкретным объектом интерфейса, а не свободно трактовать как текст. Для frontend-команды отсюда следует практический вывод: одного чат-виджета недостаточно. Нужны валидированный рендер товарных карточек, актуальное состояние корзины, отображение черновиков изменений и отдельные элементы подтверждения.

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

Для merchant agent аналогом checkout становится staged change: черновик изменения с серверным идентификатором. Агент может предложить корректировку промо или кампании, но применение требует отдельного шага. Такой интерфейс показывает одновременно предложение модели и фактический предел её полномочий.

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

Цитата в переводе

«Доверие должно оставаться в центре каждой транзакции.»

Практическая оговорка о доверии

«Доверие должно оставаться в центре каждой транзакции».

Источник: Jack Forestell - Chief Product and Strategy Officer, Visa

Редакторский вывод: это партнёрское высказывание, опубликованное в материале Claude. Оно подчёркивает роль подтверждаемой транзакции, но не служит независимой оценкой commerce-blueprint или его бизнес-эффекта.

Безопасность: ID, лимиты и проверки конечного состояния

Ключевая часть commerce-blueprint связана не с формулировкой prompt, а с перечнем операций, доступных агенту. У shopping agent не должно быть инструмента для самостоятельного списания денег или размещения заказа. У merchant agent изменение оформляется как staged change и требует внешнего подтверждения. В документации описаны варианты подтверждения через интерфейс, CLI или политику инструмента в Managed Agents.

Anthropic отдельно описывает provenance IDs. Операция с корзиной должна принимать только идентификаторы товаров, которые сервер уже выдал в текущей сессии. ID, придуманный моделью, присланный пользователем или попавший из недоверенного контента, нужно отклонить до вызова бизнес-системы. Подход не даёт абсолютной защиты, но ограничивает класс ошибок, в которых агент пытается действовать по неподтверждённой ссылке на объект.

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

Это прямой контраргумент подходу «достаточно попросить ИИ не ошибаться». Prompt влияет на поведение, но не является средством контроля доступа. Модель может инициировать API-вызов, однако проверка роли сотрудника, региона, бюджета, допустимости операции и актуального состояния записи должна оставаться в детерминированном прикладном слое.

• Необратимые действия требуют отдельного подтверждения.
• Операционные ID должны иметь проверяемое происхождение в текущей сессии.
• Лимиты проверяются сервером после расчёта предполагаемого результата.
• Недоверенный внешний контент требует очистки и ограниченной передачи в контекст агента.

Цитата в переводе

«Превращает дни на создание каркаса агента в часы.»

Рантайм, интеграции и границы Claude Code

Anthropic описывает несколько способов реализовать этот паттерн. Через Messages API команда самостоятельно управляет agent loop и оркестрацией. Claude Agent SDK даёт каркас для работы с агентом и инструментами в Python или TypeScript. Claude Managed Agents, обозначенный как beta, переносит часть рантайм-инфраструктуры к Anthropic, включая работу с конфигурацией агента и сессиями.

Managed runtime не подключает каталог или ERP клиента автоматически. Конфигурация может включать модель, system prompt, tools, MCP-серверы и skills, но custom tool исполняется в прикладном контуре компании: получает запрос, обращается к внутренней системе и возвращает результат. Managed-подход может сократить инфраструктурную работу вокруг цикла, но не заменяет интеграции, управление доступом и ответственность за бизнес-логику.

В commerce-репозитории предусмотрены backend-интерфейсы, а не готовые MCP-коннекторы к системам бизнеса. MCP может использоваться в другой архитектуре для подключения внешних возможностей, однако смешивать сам протокол с конкретной схемой интеграций reference implementation некорректно.

Плагин commerce-builder для Claude Code содержит команды для создания каркаса commerce-агента, добавления flow, подготовки evals и проверки проекта относительно референса. Он полезен для scaffolding, но не способен автоматически согласовать схему данных, права пользователей, платёжный маршрут и ответственность за изменения.

• Messages API подходит командам, которым нужен полный контроль над оркестрацией.
• Agent SDK сокращает объём шаблонного кода, но не заменяет прикладной слой.
• Managed Agents не отменяет собственные инструменты и серверные проверки.
• Claude Code ускоряет создание заготовки, а не проводит интеграционный аудит.

Ограничение Claude Code

«Превращает дни на создание каркаса агента в часы».

Источник: Ashley Nader - Staff Product Manager

Редакторский вывод: оценка относится к ускорению scaffolding с помощью инструментов Anthropic. Её нельзя трактовать как обещание автоматической интеграции агента с реальными коммерческими системами.

Модели, стоимость и evals: измерять нужно завершённую задачу

Для аналитически сложного merchant-сценария Anthropic предлагает начинать эксперименты с Opus, а для пользовательского интерфейса, чувствительного к задержке, рассматривать Sonnet. Это не жёсткое распределение. Выбор модели и уровня effort следует проверять на одинаковых сценариях конкретного бизнеса.

Экономику агента нельзя сводить к цене одного запроса. Пользовательская сессия включает вызовы инструментов, ответы backend, повторные шаги, контекст и иногда работу с памятью. Anthropic отмечает, что отрисовываемый commerce-ответ может занимать 500–700 выходных токенов и без streaming приводить к ожиданию в пять и более секунд. Это ориентир из материалов компании, а не гарантия для любого стека.

Компания также приводит наблюдения о prompt caching, включая более низкую стоимость cache-read токенов и высокую долю попаданий в кэш в отдельных commerce-внедрениях. Эти показатели полезны как гипотеза для пилота, но не как готовая финансовая модель: публикация не раскрывает полную методику, состав проектов и условия сравнения.

До боевого запуска Anthropic предлагает проверять snapshots: фиксировать prompt, инструменты, историю, исходное состояние и пользовательский запрос, затем оценивать итоговое состояние и отрисованный ответ. Существенно не то, насколько убедительно агент объяснил рекомендацию, а показал ли подтверждённую цену, не добавил ли невыданный сервером товар и не подготовил ли запрещённое изменение.

Нужны проверки grounding коммерческих фактов, целостности состояния, авторизации, безопасности записи, устойчивости к prompt injection и корректной деградации при пустом поиске, таймауте или противоречивых данных. Anthropic рекомендует стартовый набор из 50–100 кейсов на пользовательский flow как практический ориентир. Реальный объём зависит от числа категорий, рынков, ролей и исключений.

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

Что это означает для российского бизнеса

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

На практике разумно начать с узкого сценария. В клиентской части это могут быть поиск, сравнение и ответы по карточкам товара без платежей. Во внутренней части сначала возможна read-only аналитика, затем подготовка черновиков и только после проверки ограничений узкие сценарии записи. Репозиторий допускает пилоты с ограниченной поверхностью возможностей и отключёнными путями записи.

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

Отдельно потребуется оценить маршрут данных, требования к инфраструктуре и применимые юридические обязательства. Blueprint Anthropic не решает эти вопросы автоматически. Его сильная сторона в том, что он делает видимыми главные инженерные опоры: backend-интеграции, UI-подтверждения, проверяемые идентификаторы, ограничения на запись и воспроизводимые evals.

• Начинайте с read-only или low-risk flow.
• Опишите источники истины для каталога, цены, остатка, заказа, политики и прав.
• Не разрешайте менять цену, скидку, запас или бюджет одной командой в чате.
• Расширяйте полномочия только после замеров ошибок и проверок на реальных сценариях.

Что делать команде до пилота

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

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

Чек-лист запуска commerce-агента

Сохраните чек-лист в PDF и используйте его при подготовке пилота и проверке готовности к расширению сценария.

Контракты и данные

До первой демонстрации зафиксируйте, какая система отвечает за каждый коммерческий факт и действие.

• Составьте реестр источников истины: каталог, варианты товара, цены, остатки, корзина, заказ, доставка, возврат, права и аудит.
• Определите контракты инструментов и структурированные ответы backend для каждого пользовательского flow.
• Отделите данные, которые агент может читать, от данных, которые он вправе менять или только предлагать изменить.
• Проверьте, что товарные и операционные ID выдаются сервером в текущей сессии.

Действия и подтверждения

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

• Начните с customer flow без оплаты и merchant flow без write-действий.
• Для изменения цены, скидки, бюджета, запаса или кампании создавайте черновик с серверным идентификатором.
• Добавьте отдельное подтверждение через UI, серверную политику или другой контролируемый механизм.
• Проверяйте роль, регион, лимит и конечное состояние операции на сервере.

Оценка качества

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

• Соберите snapshots ключевых пользовательских flow с исходным состоянием, историей, инструментами и ожидаемым результатом.
• Проверяйте подтверждённую цену, наличие, целостность корзины и отсутствие неразрешённых изменений.
• Тестируйте пустой поиск, таймауты, противоречивые данные и попытки передать инструкции через недоверенный контент.
• Сравнивайте модели по успешному завершению задачи, полной стоимости и задержке, а не по убедительности ответа.

Вывод

Релиз Anthropic ценен практичностью: commerce-агент показан как система из модели, инструментов, UI, серверных ограничений и проверок, а не как один prompt или самостоятельный участник платежей. Claude ведёт диалог и выбирает разрешённые действия, а backend сохраняет контроль над фактами, полномочиями и последствиями операций.

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

Источники

Claude by Anthropic. Build commerce agents with Claude https://claude.com/blog/claude-for-commerce-agents

Anthropic Claude Platform. Commerce agents use-case guide https://platform.claude.com/docs/en/about-claude/use-case-guides/commerce-agents

Anthropic GitHub. commerce-agents README https://github.com/anthropics/commerce-agents/blob/main/README.md

Claude by Anthropic. The anatomy of effective commerce agents https://claude.com/blog/the-anatomy-of-effective-commerce-agents

Anthropic Claude Platform. Claude API skill https://platform.claude.com/docs/en/agents-and-tools/agent-skills/claude-api-skill

Anthropic Claude Platform. Managed Agents tools https://platform.claude.com/docs/en/managed-agents/tools

Anthropic Claude Platform. Managed Agents setup https://platform.claude.com/docs/en/managed-agents/agent-setup

Anthropic Claude Platform. Managed Agents reference https://platform.claude.com/docs/en/managed-agents/reference

Практический чек-лист

Чек-лист запуска commerce-агента на Claude

Материал для PDF в downloads/checklist-commerce-agent-claude.pdf. Используйте его для подготовки ограниченного пилота и решения о расширении полномочий агента.

Контракты и данные

• Составьте реестр источников истины: каталог, варианты товара, цены, остатки, корзина, заказ, доставка, возврат, права и аудит.
• Определите контракты инструментов и структурированные ответы backend для каждого пользовательского flow.
• Отделите данные, которые агент может читать, от данных, которые он вправе менять или только предлагать изменить.
• Проверьте, что товарные и операционные ID выдаются сервером в текущей сессии.

Действия и подтверждения

• Начните с customer flow без оплаты и merchant flow без write-действий.
• Для изменения цены, скидки, бюджета, запаса или кампании создавайте черновик с серверным идентификатором.
• Добавьте отдельное подтверждение через UI, серверную политику или другой контролируемый механизм.
• Проверяйте роль, регион, лимит и конечное состояние операции на сервере.

Оценка качества

• Соберите snapshots ключевых пользовательских flow с исходным состоянием, историей, инструментами и ожидаемым результатом.
• Проверяйте подтверждённую цену, наличие, целостность корзины и отсутствие неразрешённых изменений.
• Тестируйте пустой поиск, таймауты, противоречивые данные и попытки передать инструкции через недоверенный контент.
• Сравнивайте модели по успешному завершению задачи, полной стоимости и задержке, а не по убедительности ответа.