За последний год команды Anthropic работали с ритейлерами, маркетплейсами, туристическими сервисами, билетными операторами и телеком-компаниями над коммерческими агентами на базе Claude. Такие решения уже работают в production: помогают покупателям быстрее находить нужное, а сотрудникам — управлять ассортиментом, промоакциями и операционными задачами без бесконечной ручной рутины.
Удачные коммерческие AI-агенты обычно устроены проще, чем кажется на старте. В центре — одна сильная модель в агентном цикле, вокруг неё — навыки, инструменты доступа к корпоративным системам и строгий набор evals. Не зоопарк из десятка агентов, не лабиринт маршрутизаторов. Просто, но не примитивно.
Ниже — разбор решений, которые стоит принять, если вы проектируете и внедряете коммерческого AI-агента: от базовой архитектуры до памяти, контроля действий, стоимости и запуска в крупной организации.
В этом руководстве
Архитектура
Что такое коммерческий агент?
Коммерческий агент — это AI-агент, который упрощает покупку или продажу в цифровом каталоге. Покупательский агент ищет товары, сравнивает варианты, предлагает замену, собирает корзину и помогает оформить заказ. Агент для продавца отвечает на вопросы о продажах, запускает кампании, подсказывает по ценам и контролирует запасы.
Основа — модель в агентном цикле: она понимает цель, изучает доступный контекст, вызывает инструменты, использует нужные навыки, задаёт уточняющие вопросы и проверяет результат. Всё это продолжается, пока задача не будет решена. По-хорошему, именно так и должен выглядеть агентный цикл, спроектированный под коммерческие сценарии.
Инженерный контекст
Навыки вместо субагентов
У коммерческого агента много сценариев, поэтому желание разбить его на субагентов по доменам вполне понятно: отдельный — для возвратов, другой — для поиска, третий — для тарифов. На практике такая схема часто начинает скрипеть.
Коммерческий диалог связан единым контекстом. Корзина, история заказов, предпочтения, уже подготовленные изменения и предыдущие реплики нужны агенту одновременно. При передаче задачи субагенту часть состояния теряется или дублируется, растёт расход токенов, а задержка может увеличиться на секунды. Неловко, особенно в checkout.
Навыки дают модульность без этой потери: инструкции подгружаются в основной агент, который уже видит историю сессии. Единый агент с навыками нередко обходит и монолитный prompt, и набор субагентов — по качеству, стоимости и времени выполнения.
Субагенты всё же полезны для узких самостоятельных задач: например, глубокого исследования документов, анализа больших наборов данных или работы специализированного доменного агента с отдельными требованиями к compliance. Ключевой вопрос здесь простой: кто ведёт разговор с пользователем? Если доменный агент становится собеседником, это передача задачи; если он возвращает краткий результат главному агенту — делегирование.
Системный prompt или навык?
Решение зависит от частоты использования. Инструкции, необходимые в большинстве диалогов, разумно держать в системном prompt: поиск товаров, правила отображения корзины, критичные ограничения безопасности, юридические требования и важные сведения о пользователе. Всё, что нужно редко, лучше оформить навыком.
Практическая отправная точка: если правило или функция требуется примерно в трети сессий и чаще, поместите её в системный prompt. Если по входному сигналу заранее понятно, какой навык потребуется — например, пользователь открыл конкретную страницу товара, — его можно загрузить до первого обращения к модели. Минус один лишний ход. Мелочь, а приятно.
Инструменты: не переписывайте то, что уже работает
У коммерческой компании уже есть поиск, ранжирование, каталог, корзина, CRM, сервис запасов, движок промоакций, аналитика и правила ценообразования. В этих системах накоплена бизнес-логика, которую оттачивали годами. Агент не должен воспроизводить её в prompt или собственных рассуждениях.
Инструмент AI-агента должен вызывать существующий сервис. Например, search_products возвращает уже ранжированные позиции, а модель решает, какие из них отвечают запросу пользователя, сколько показать и как объяснить выбор. Граница инструмента — там, где заканчивается детерминированная логика системы и начинается суждение модели.
Результат инструмента — это тоже контекст. Возвращайте модели только поля, нужные для решения; лишние URL, технические статусы и огромные необработанные ответы лишь раздувают окно контекста. В ошибках полезнее ясная инструкция вроде «укажите ID товара при запросе доступности», чем голый код 403.
UI-компоненты — тоже инструменты
В коммерческом интерфейсе агент чаще выдаёт не абзац текста, а карточки товаров, маршрут, сравнительную таблицу тарифов, карту мест или диаграмму. Поэтому лучше, чтобы модель вызывала типизированные инструменты: present_products, present_itinerary, present_plan_comparison.
Сервер валидирует аргументы, обогащает данные и отправляет событие клиенту, а клиент его рендерит. Такой подход надёжнее самодельных тегов в тексте: история диалога остаётся в нативном формате сообщений, компоненты проще развивать, а вероятность поломать весь prompt из-за нового блока интерфейса заметно ниже.
Аргументы инструмента представления должны повторять реальный макет интерфейса — строки, карусели, порядок карточек. Тогда фраза пользователя «покажи первый отель» не превращается в маленький квест для системы.
Как сделать систему быстрой и доступной
В коммерции задержка важна, однако качество результата обычно важнее нескольких сэкономленных миллисекунд. Точный ответ, релевантная рекомендация и реально завершённая задача лучше влияют на выручку, размер корзины и удержание, чем быстрый, но бесполезный ответ.
Минимизация времени выполнения задачи
Полная задержка складывается из времени генерации и времени работы инструментов на каждом ходе. Значит, есть три рычага: уменьшить число ходов, ускорить инструменты и выбрать подходящую модель. Оптимизировать надо сумму, а не одну красивую метрику в дашборде.
- Предзагружайте вероятный контекст. Если пользователь открыл ассистента на странице товара, добавьте сведения о товаре в контекст сессии. Если продавец пришёл из отчёта кампании — подгрузите данные кампании.
- Разрешайте параллельные вызовы. Независимые запросы к каталогу, остаткам и политикам не должны выполняться один за другим.
- Ускоряйте backend-инструменты. Если инструмент обрастает сложной доменной логикой, вероятно, пора вынести её в отдельный backend endpoint, а не лепить ещё один слой кода вокруг агента.
- Запускайте инструменты по мере поступления аргументов. Не обязательно ждать завершения всего ответа модели, если параметры вызова уже сформированы.
Воспринимаемая задержка
Пользователь оценивает не только фактическое время ожидания, но и то, когда на экране впервые что-то произошло. Стриминг UI-компонентов и короткие сообщения о ходе работы заметно улучшают этот опыт: «ищу отели рядом с морем», «сверяю условия тарифа», «проверяю наличие». Агент занят — и это видно.
Кэширование prompt
Кэширование prompt — один из самых сильных способов снизить стоимость агентной системы. Запрос следует строить от стабильного к изменчивому: сначала глобальный системный prompt и определения инструментов, затем сессионный контекст и история, а в самом конце — текущая страница, время и другие быстро меняющиеся данные.
Самая частая ошибка — поместить timestamp в начало системного prompt. Один байт изменился, и кэш уже не тот. Навыки лучше загружать результатами инструментов, а не переписывать ими системный prompt: так они становятся частью кэшируемого префикса диалога.
Выбор модели и конфигурации
Модель и уровень effort выбирают не по ощущениям, а по полному набору evals. Задайте бизнес-метрики качества, минимальный допустимый результат, бюджеты p50 и p99 по задержке, а также стоимость завершённой задачи.
Проверяйте каждую рассматриваемую модель на реальном наборе сценариев. Более интеллектуальная модель может генерировать токены медленнее, но закончить сложную задачу за меньшее число раундов — и в итоге оказаться быстрее. А более дешёвая модель, которой нужно больше ходов или которая чаще ошибается, не такая уж дешёвая. Вот и вся арифметика.
Эксплуатация в production
Память между сессиями
Память позволяет агенту не начинать каждый разговор с чистого листа. Покупателю не нужно раз за разом напоминать об аллергии, а менеджеру — объяснять, какие показатели он проверяет каждое утро.
Долговременная агентная память должна жить в корпоративных системах, а не внутри модели. Вместо неструктурированного профиля лучше хранить небольшие типизированные факты: ключ, значение, категорию, источник и срок актуальности. Такое типизированное хранилище фактов мы разворачиваем как отдельный слой агентной памяти поверх ваших систем.
Для памяти особенно важны политика хранения, сроки удаления, возможность просмотра и исправления данных пользователем, а также раздельное включение функции по регионам и развёртываниям. Персональные данные — не место для авось.
Запись и чтение памяти
Факты разумнее извлекать асинхронно: отдельный процесс анализирует диалог после хода или нескольких ходов и создаёт, обновляет либо удаляет записи. Это не увеличивает задержку для пользователя и не отвлекает основной агентный цикл.
Читать память полезно в три слоя: небольшой постоянный набор фактов — на каждом ходе; контекстно релевантные факты — по сигналам текущего запроса; всё остальное — через отдельный поисковый инструмент. Пользовательская память относится к сессионному сегменту prompt и должна идти после глобального кэшируемого блока.
Безопасность: контроль реализуется в коде
Prompt задаёт безопасное поведение, но сам по себе не обеспечивает безопасность AI-агента. В коммерческих сценариях ошибки стоят денег и иногда необратимы. Поэтому критичные ограничения должны исполняться в harness и backend-коде. Именно эти ограничения мы переносим из prompt в harness и backend при аудите безопасности агента.
Модель предлагает, а человек или политика применяет
Вызов инструмента модели не должен напрямую списывать деньги, менять цену, оформлять возврат или запускать кампанию. Агент может подготовить действие, но применение требует подтверждения человеком либо детерминированной политики. Для операций продавца это может быть подготовленное изменение с серверным ID и отдельный вызов apply_change, доступный только после одобрения.
Принимайте только серверные ID
Операции записи и рендеринга должны принимать только идентификаторы, которые сервер ранее выдал модели в рамках текущей сессии. Придуманный моделью ID, значение из пользовательского сообщения или вредоносного отзыва нужно отклонять до обращения к backend.
То же относится к интерфейсу: инструмент передаёт ID, а сервер сам подставляет разрешённые данные о товаре, заказе или изменении. Так карточка не отобразит объект, которого система не подтверждала.
Проверяйте итоговое состояние
Лимиты на количество билетов, размер скидки, изменение цены, пополнение запасов или бюджет кампании проверяются не только по входному запросу, но и по результирующему состоянию. Операции записи в рамках одной сессии следует сериализовать, иначе параллельные вызовы могут обойти ограничение.
Санитизируйте сторонний контент
Отзывы, листинги, сообщения продавцов, политики и даже сохранённая память — недоверенный ввод. Перед передачей модели такой контент нужно очищать от управляющих и двунаправленных символов, имитации системных блоков и вызовов инструментов, а также ограничивать по размеру. В prompt стоит прямо закрепить правило: текст из такого блока можно анализировать и пересказывать, но нельзя воспринимать как инструкцию к действию.
Evals: выпуск недетерминированной системы
Любая правка — новый инструмент, изменение prompt, другая модель или настройка effort — способна вызвать неожиданную регрессию. Evals нужны, чтобы увидеть её до релиза, а не после жалобы клиента в пятницу вечером.
Для коммерческих агентов полезнее оценивать снимки состояния, а не фиксированный путь диалога. Состояние состоит из системного prompt, доступных инструментов и массива сообщений. Создайте тестовое состояние, добавьте реплику пользователя, запустите агента и проверьте итог: изменение корзины, параметры последнего вызова записи, корректность отрендеренного интерфейса, соблюдение ограничений.
Симуляции с моделью-пользователем могут быть полезны для поиска новых сценариев, но не стоит делать их единственным измерителем качества: две недетерминированные системы требуют больших выборок и усложняют поиск причины сбоя. Найденный сценарий лучше превратить в повторяемый eval-кейс.
В итоге эффективный коммерческий агент — это не просто чат с доступом к API. Это продуманная агентная архитектура, надёжные инструменты, память с понятными правилами, контролируемые действия и постоянные evals. Именно на этой базе можно разложить задачу на несколько специализированных агентов и связать их в одну систему, если отдельные агенты действительно оправданы задачей.