Анатомия эффективного коммерческого агента от Anthropic

Представь, что тебе нужно построить агента, который помогает выбрать отель, собрать корзину в интернет-магазине или обновить тарифный план у оператора связи. Казалось бы, логичный путь — сделать под каждую задачу отдельного «специалиста»-агента и переключаться между ними. 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, по одному на каждую операционную область бизнеса.

Инструменты агента: вызывай, а не переизобретай

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

Результаты вызова инструмента — это часть контекста модели. Стоит возвращать только те поля, с которыми модель реально рассуждает, и отбрасывать остальное — классический грех здесь URL картинок в каждой строке результатов поиска. При необходимости сырой ответ стоит переформатировать прямо внутри инструмента, добавляя следующий шаг, если он не очевиден из данных. Это особенно важно для ошибок: модели полезнее получить инструкцию, а не код ошибки. Вместо голого «403» лучше отдать «нужно указать ID товара при запросе наличия».

UI-компоненты — это тоже инструменты

Большинство ответов коммерческого агента — это не текст, а UI-компоненты: карусель товаров, маршрут путешествия, карта мест в зале, график. Значит, агент должен выдавать схему, а не прозу.

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

Рабочий паттерн — сделать каждый UI-компонент инструментом. Модель вызывает present_products, present_itinerary или present_plan_comparison с типизированными аргументами; сервер валидирует и обогащает вызов и выпускает событие; клиент это отрисовывает. Поскольку компоненты — это обычные вызовы инструментов, они уже лежат в массиве сообщений в родном формате, и не нужно ничего перепарсивать при загрузке старого диалога.

Компромисс здесь — гранулярность стриминга: каждый аргумент верхнего уровня в вызове инструмента буферизуется на сервере для валидации, поэтому подкомпоненты приходят порциями даже при включённом стриминге. Чтобы получить потоковую передачу на уровне токенов, можно включить eager_input_streaming: true в определении инструмента — это убирает буферизацию, но вместе с ней и серверную гарантию соответствия схеме. По наблюдениям Anthropic, нарушения схемы очень редки на моделях уровня Claude Sonnet и выше, но на такие редкие случаи стоит оборачивать вызов в повтор.

У презентационных инструментов есть и побочный бонус — они хранят запись того, что показано на экране. Когда пользователь говорит «первый отель» или «третий вариант слева», разметка уже лежит в массиве сообщений, в аргументах последнего презентационного вызова. Чтобы это работало, аргументы должны отражать именно отрисованную раскладку — упорядоченными рядами и каруселями, а не плоским списком, который клиент потом перестраивает.

Скорость и стоимость: борьба на два фронта

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

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

Задержка выполнения задачи — это сумма по всем ходам модели времени до последнего токена плюс обработка инструментов. Отсюда три рычага: меньше ходов, быстрее инструменты, быстрее токены. Эти рычаги иногда конкурируют друг с другом, поэтому минимизировать нужно именно сумму, а не какой-то один из них. Практический приём для сокращения числа ходов — заранее подгружать вероятный контекст, повышать интеллект модели там, где это оправдано, и разрешать модели вызывать независимые инструменты параллельно, а не по очереди.

Продакшен: память, безопасность, оценка качества

Оставшаяся часть гайда Anthropic посвящена тому, что происходит после запуска: как устроить память, которая переживает сессию, почему проверка безопасности должна жить именно в харнессе (обвязке вокруг модели), а не в промпте, как строить оценочные наборы (evals) для системы, которая по своей природе недетерминирована, и как масштабировать эту работу на большую организацию с несколькими командами. Это отдельный, не менее объёмный пласт практики — и явный сигнал того, что коммерческий агент нельзя просто «запустить и забыть»: он требует постоянного цикла измерений и доработок, как и любая production-система.

Для тех, кто хочет попробовать всё это своими руками, Anthropic выложила референсную реализацию — репозиторий anthropics/commerce-agents с харнессами, паттернами и защитными механизмами, которые позволяют собрать рабочего коммерческого агента за считаные дни. В нём есть готовые примеры шопинг-агента и агента для продавца — под ритейл, туризм, телеком и продажу билетов.

Частые вопросы

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

Если хочешь попробовать всё это руками — начни с бесплатного курса «Агенты, субагенты и Skills».