# Анатомия эффективного коммерческого агента от Anthropic
Канонический URL: https://zero2claude.ru/blog/anatomy-commerce-agents
Дата: 2026-09-02
Теги: агенты, claude, api, автоматизация
Как Anthropic вместе с ритейлерами и маркетплейсами строит агентов для покупок и продаж: архитектура без саб-агентов, навыки вместо интент-роутера и инструменты как UI.
Представь, что тебе нужно построить агента, который помогает выбрать отель, собрать корзину в интернет-магазине или обновить тарифный план у оператора связи. Казалось бы, логичный путь — сделать под каждую задачу отдельного «специалиста»-агента и переключаться между ними. Anthropic год строила такие системы вместе с ритейлерами, маркетплейсами, туристическими сервисами и телеком-провайдерами — и пришла к выводу, что этот путь почти всегда проигрывает более простому решению.
Ниже — пересказ гайда Anthropic о том, как устроены агенты для покупки и продажи товаров, которые уже работают в продакшене и, по словам заказчиков, увеличивают средний чек и делают работу продавцов эффективнее.
## Что такое коммерческий агент
Anthropic определяет коммерческого агента просто: это агент, который упрощает покупку и продажу в онлайн-каталоге. Одни агенты обращены к покупателю — ищут товары, сравнивают варианты, предлагают замены и собирают заказ. Это может быть корзина в ритейле, маршрут путешествия, смена мобильного тарифа или бронирование мест на концерт. Другие агенты обращены к бизнесу — отвечают на вопросы о продажах, запускают промоакции и управляют ценами и остатками на складе.
Ключевая идея архитектуры проста: одна модель в стандартном агентном цикле — рассуждает о цели, изучает контекст, действует через инструменты, применяет процедуры через навыки, задаёт уточняющие вопросы и наблюдает результат, пока задача не выполнена. Никакого интент-роутера, который заранее сортирует разговор по темам, и никакого набора узкоспециализированных агентов позади него.
## Навыки, а не саб-агенты
Соблазн разбить коммерческого агента на кучу саб-агентов по доменам понятен — категорий и намерений слишком много. На практике это оказывается неоптимальным решением, потому что разговор о покупках — это одна плотно связанная сессия с множеством пересекающихся тем и требует общего контекста.
В архитектуре с саб-агентами оркестратор хранит корзину, отложенные изменения, предпочтения пользователя и историю диалога. Каждая передача задачи саб-агенту — это операция с потерей состояния, которая обычно снижает качество ответа саб-агента и, следом, качество всего ответа. К тому же каждая такая передача может стоить в разы больше токенов и добавляет секунды задержки. Домены редко разделяются чисто: сценарий возврата товара может требовать историю заказов, текущую корзину и каталог одновременно — и подход «саб-агент на домен» либо дублирует доступ везде, либо передаёт задачу посреди процесса.
Вместо этого модульность по доменам без «налога» на передачу дают agent skills (навыки агента): инструкции навыка подгружаются прямо в главного агента, который уже держит всю историю разговора. В сравнениях на нескольких корпоративных внедрениях один агент с навыками стабильно обходил и подход «один промпт на всё», и подход с саб-агентами по качеству — часто при этом ещё и дешевле и быстрее в пересчёте на задачу.
Саб-агенты всё же оправданы в двух случаях. Первый — когда оркестратор вызывает их как инструмент для узкой, самодостаточной задачи, которой пригодится собственное окно контекста. Типичный пример из продакшена — саб-агент для глубокого research: он ищет и читает документы, пишет и запускает код, проходит по моделям данных, натыкается на тупики — и вся эта работа остаётся внутри саб-агента, а оркестратору возвращается только компактный ответ. Второй случай — домен, у которого уже есть собственный полноценный агент. Если, например, у фармацевтического или финансового сервиса есть выделенный агент со своим контуром соответствия требованиям, правильный ход — это hand-off: этот агент берёт задачу на себя и работает с пользователем напрямую через свой собственный цикл до завершения. Разница именно в том, кто «владеет» разговором: hand-off делает доменного агента прямым собеседником пользователя, а делегирование оставляет оркестратора главным, лишь на время впуская доменного агента внутрь одного хода — с потерями качества на каждом таком обмене.
## Системный промпт или навык: решаем по частоте
Главный критерий, куда положить инструкции — в системный промпт или в навык — это частота использования. Загрузка навыка стоит модели одного дополнительного хода, поэтому всё, что нужно почти на каждом ходу, обычно уходит в системный промпт. Хороший стартовый ориентир: всё, что касается трети или более твоего трафика (по прогнозу до запуска или по наблюдениям в продакшене), идёт в системный промпт, остальное — в навыки.
Если навык предсказуем по сигналу, который у тебя уже есть — например, по странице, с которой пришёл пользователь — его стоит подгружать из харнесса до первого вызова модели, экономя лишний ход. Критические инструкции — правила безопасности и юридические ограничения, брендовые требования, важные факты о пользователе (например, аллергии) — всегда идут в системный промпт.
| Что | Где хранить |
|---|---|
| Поиск товаров (используется почти в каждой сессии) | Системный промпт |
| Правила безопасности, бренда, ключевые факты о пользователе | Системный промпт |
| Долгий хвост функций: планирование покупок, забота о клиенте, память | Навыки |
| Контекст, предсказуемый по сигналу (страница входа) | Подгружается заранее из харнесса |
В референсной реализации Anthropic промпт шопинг-агента держит основы: как понимать контекст, семантику корзины и оформления заказа, правила подачи результатов и сам поиск товаров. А навыки покрывают всё остальное: search-discovery, purchase-research, planning-goals, customer-care, memory-personalization. Агент для продавца (merchant) разбит аналогично — навыки performance-insights, catalog-listings, inventory-operations, pricing-promotions и marketing-campaigns, по одному на каждую операционную область бизнеса.
Если ты только начинаешь разбираться с агентами и инструментами Claude, посмотри бесплатный курс zero2claude — там объясняются базовые понятия вроде инструментов, промптов и агентного цикла на простых примерах.
## Инструменты агента: вызывай, а не переизобретай
У коммерческой компании почти всегда уже есть поиск и ранжирование, корзина, хранилище предпочтений и профиля, система учёта остатков, движки промоакций и кампаний, аналитика продаж — и в каждой из этих систем годами настраивалась логика, которую модель никогда не увидит напрямую. Инструменты агента должны вызывать эти системы, а не переизобретать их: граница инструмента — это место, где заканчивается логика существующих систем и начинается суждение модели. Например, когда агент вызывает `search_products`, результаты должны приходить уже отранжированными; задача агента — решить, какие из них служат цели пользователя, сколько показать и как их представить.
Результаты вызова инструмента — это часть контекста модели. Стоит возвращать только те поля, с которыми модель реально рассуждает, и отбрасывать остальное — классический грех здесь URL картинок в каждой строке результатов поиска. При необходимости сырой ответ стоит переформатировать прямо внутри инструмента, добавляя следующий шаг, если он не очевиден из данных. Это особенно важно для ошибок: модели полезнее получить инструкцию, а не код ошибки. Вместо голого «403» лучше отдать «нужно указать ID товара при запросе наличия».
## UI-компоненты — это тоже инструменты
Большинство ответов коммерческого агента — это не текст, а UI-компоненты: карусель товаров, маршрут путешествия, карта мест в зале, график. Значит, агент должен выдавать схему, а не прозу.
Некоторые команды начинают с того, что просят модель генерировать собственные теги и парсят их на клиенте. Этот подход перестаёт работать, когда поверхность растёт: модель хуже обучена на самодельной разметке, чем на вызовах инструментов, поэтому надёжность падает по мере усложнения вложенных компонентов; определения тегов живут в системном промпте, так что каждый новый компонент раздувает контекст, а каждое изменение рискует поломать что-то другое; прошлые разговоры сохраняются в формате, который читает только твой собственный парсер, из-за чего загрузка истории превращается в отдельную головную боль.
Рабочий паттерн — сделать каждый UI-компонент инструментом. Модель вызывает `present_products`, `present_itinerary` или `present_plan_comparison` с типизированными аргументами; сервер валидирует и обогащает вызов и выпускает событие; клиент это отрисовывает. Поскольку компоненты — это обычные вызовы инструментов, они уже лежат в массиве сообщений в родном формате, и не нужно ничего перепарсивать при загрузке старого диалога.
Компромисс здесь — гранулярность стриминга: каждый аргумент верхнего уровня в вызове инструмента буферизуется на сервере для валидации, поэтому подкомпоненты приходят порциями даже при включённом стриминге. Чтобы получить потоковую передачу на уровне токенов, можно включить `eager_input_streaming: true` в определении инструмента — это убирает буферизацию, но вместе с ней и серверную гарантию соответствия схеме. По наблюдениям Anthropic, нарушения схемы очень редки на моделях уровня Claude Sonnet и выше, но на такие редкие случаи стоит оборачивать вызов в повтор.
У презентационных инструментов есть и побочный бонус — они хранят запись того, что показано на экране. Когда пользователь говорит «первый отель» или «третий вариант слева», разметка уже лежит в массиве сообщений, в аргументах последнего презентационного вызова. Чтобы это работало, аргументы должны отражать именно отрисованную раскладку — упорядоченными рядами и каруселями, а не плоским списком, который клиент потом перестраивает.
## Скорость и стоимость: борьба на два фронта
Задержка (latency) важна в коммерции, и потребительские интерфейсы прощают меньше всего. Но на агентных поверхностях метрики удержания, вовлечённости и размера корзины двигает прежде всего качество результата: релевантность ответа и то, реально ли выполнена задача, оказались важнее незначительных выигрышей в скорости.
Поэтому задержку стоит атаковать сразу с двух сторон: минимизировать сквозную задержку хорошей инженерией и параллельно снижать воспринимаемую задержку — время, проведённое за наблюдением за работой агента, само по себе читается пользователем как прогресс. У каждого пользователя есть свой «бюджет терпения», и техники ниже помогают удержаться в нём без того, чтобы жертвовать интеллектом модели.
Задержка выполнения задачи — это сумма по всем ходам модели времени до последнего токена плюс обработка инструментов. Отсюда три рычага: меньше ходов, быстрее инструменты, быстрее токены. Эти рычаги иногда конкурируют друг с другом, поэтому минимизировать нужно именно сумму, а не какой-то один из них. Практический приём для сокращения числа ходов — заранее подгружать вероятный контекст, повышать интеллект модели там, где это оправдано, и разрешать модели вызывать независимые инструменты параллельно, а не по очереди.
Anthropic отдельно подчёркивает: ни одна из техник по скорости и стоимости не должна идти в ущерб «интеллекту» модели — сначала качество ответа, потом оптимизация задержки.
## Продакшен: память, безопасность, оценка качества
Оставшаяся часть гайда Anthropic посвящена тому, что происходит после запуска: как устроить память, которая переживает сессию, почему проверка безопасности должна жить именно в харнессе (обвязке вокруг модели), а не в промпте, как строить оценочные наборы (evals) для системы, которая по своей природе недетерминирована, и как масштабировать эту работу на большую организацию с несколькими командами. Это отдельный, не менее объёмный пласт практики — и явный сигнал того, что коммерческий агент нельзя просто «запустить и забыть»: он требует постоянного цикла измерений и доработок, как и любая production-система.
Для тех, кто хочет попробовать всё это своими руками, Anthropic выложила референсную реализацию — репозиторий anthropics/commerce-agents с харнессами, паттернами и защитными механизмами, которые позволяют собрать рабочего коммерческого агента за считаные дни. В нём есть готовые примеры шопинг-агента и агента для продавца — под ритейл, туризм, телеком и продажу билетов.
## Частые вопросы
Это агент, который упрощает покупку и продажу в онлайн-каталоге. Одни агенты обращены к покупателю (поиск товаров, сборка корзины, планирование поездки), другие — к бизнесу (аналитика продаж, управление ценами и остатками, промоакции).
Потому что коммерческий разговор — это одна плотно связанная сессия с пересекающимися темами. Каждая передача задачи саб-агенту теряет часть состояния (корзину, предпочтения, историю), снижает качество ответа и добавляет токены и секунды задержки. Один агент с навыками в сравнениях Anthropic на нескольких корпоративных внедрениях стабильно обходил и подход с саб-агентами, и подход «один промпт на всё».
В двух случаях: для узкой самодостаточной задачи, которой полезно отдельное окно контекста (например, саб-агент для глубокого research), и когда у домена уже есть собственный полноценный агент со своим контуром соответствия требованиям — тогда используется hand-off, и доменный агент напрямую ведёт диалог с пользователем.
По частоте использования: всё, что нужно трети или более трафика, идёт в системный промпт, остальное — в навыки. Критические правила (безопасность, бренд, ключевые факты о пользователе) всегда в системном промпте, а долгий хвост редких сценариев — в навыках.
Кастомные теги хуже отрабатываются моделью, чем нативные вызовы инструментов, раздувают системный промпт с каждым новым компонентом и создают проблемы с хранением истории диалогов. Если каждый UI-компонент — это отдельный инструмент (`present_products`, `present_itinerary` и так далее), он естественно попадает в массив сообщений в родном формате и не требует отдельного парсера.
Главный урок из гайда Anthropic звучит почти контринтуитивно: чем сложнее задача, тем сильнее тянет усложнить архитектуру — добавить роутеры, саб-агентов, отдельные промпты на каждый случай. Но на практике именно простая схема — одна модель, один агентный цикл, навыки вместо ветвлений и инструменты, которые честно вызывают уже существующие системы бизнеса — оказывается быстрее, дешевле и качественнее. Прежде чем городить сложную многоагентную систему, стоит проверить, не решает ли задачу один хорошо настроенный агент с правильным набором навыков.
Если хочешь попробовать всё это руками — начни с бесплатного курса [«Агенты, субагенты и Skills»](/learn/agents).
По мотивам статьи Anthropic «A guide to the anatomy of effective commerce agents». Пересказали по-русски для новичков.