Анатомия эффективных коммерческих агентов, от архитектуры до производства

1. Что такое коммерческий агент

Определение простое, это агент, который упрощает процессы покупки и продажи в онлайн-каталогах.

Они делятся на два типа:

• Агенты для покупателей занимаются поиском, сравнением, подбором альтернатив и сборкой заказа. Это может быть розничная корзина, туристический маршрут, смена тарифа или бронирование мест в театре.
• Агенты для продавцов отвечают на коммерческие вопросы, запускают акции, управляют остатками и ценообразованием.

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

2. Ключевые архитектурные решения

Навыки (Skills), а не субагенты (Subagents)

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

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

Гораздо эффективнее использовать «навыки» (skills) это инструкции, которые загружаются в основного агента, уже владеющего всей историей. Это даёт аналогичную модульность по доменам, но без потерь при переключении. В нескольких промышленных сравнениях единый агент с навыками неизменно превосходил по качеству как «один промпт на всё», так и архитектуру с субагентами, причём обычно с меньшими затратами и задержкой.

Субагенты имеют смысл только в двух случаях, во-первых, как инструмент, вызываемый оркестратором для узкой автономной задачи (например, субагент для глубокого исследования), во-вторых, если у домена уже есть собственный выделенный агент с особыми требованиями к безопасности, тогда можно применить «передачу» (hand-off) вместо «делегирования» (delegation). Разница в том, что при передаче доменный агент становится непосредственным собеседником пользователя, а при делегировании оркестратор вызывает его снова и снова в рамках одного раунда, каждый раз с деградацией качества.

Системный промпт или навык – выбираем по частоте использования

Главный критерий, куда поместить инструкцию в системный промпт или в навык это частота использования.

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

Критические инструкции, правила безопасности, юридические ограничения, брендовые требования, ключевая информация о пользователе (например, аллергии)  всегда должны быть в системном промпте. Для коммерческого агента поиск товаров тоже лучше держать в промпте (он нужен почти в каждой сессии), а все редкие функции выносить в навыки.

3. Инженерные практики работы с инструментами

Инструменты строятся поверх существующих систем

У коммерческих компаний уже есть системы поиска и ранжирования, корзины, профилей предпочтений, управления запасами, промо-акциями, аналитики продаж, каждая из них отточена годами и учитывает сигналы, которые модель никогда не увидит. Инструменты агента должны вызывать именно эти системы, а не переизобретать их.

Граница инструмента определяет, где заканчивается системная логика и начинается суждение модели. Например, когда агент вызывает search_products, результаты должны уже быть отсортированы, задача агента решить, какие из них соответствуют цели пользователя, сколько показать и как именно представить.

Результат работы инструмента это контекст – возвращайте только те поля, которые нужны модели для рассуждений, отбрасывая всё лишнее (чаще всего главным «мусором» бывают URL картинок). В случае ошибок модели гораздо полезнее дать чёткую инструкцию, чем просто код ошибки.

UI-компоненты как инструменты

В большинстве коммерческих агентов ответ это не просто текст, а UI-компоненты, карусели товаров, маршруты, схемы мест или графики. Значит, агент должен выдавать структурированную схему, а не текст.

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

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

Инженерная стратегия для снижения задержки

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

Поэтому стратегия двойная, минимизировать сквозную задержку через хорошую инженерию и одновременно снижать воспринимаемую задержку.

Три рычага для сокращения времени выполнения задачи: меньше шагов, более быстрые инструменты, более быстрые токены.

• Меньше шагов, загружайте контекст заранее (если пользователь открыл помощника со страницы товара – сразу положите данные этой страницы в контекст), используйте более умные модели (они лучше планируют вызовы инструментов), давайте модели вызывать независимые инструменты параллельно.
• Более быстрые инструменты, оптимизируйте бэкенды, выносите бизнес-логику, которая склеивается на границе инструментов, вверх, в бэкенд-системы, запускайте инструменты как можно раньше – как только закончили стримить параметры, запускайте выполнение, это сокращает многомиллисекундные паузы до сотен миллисекунд.

Снижение воспринимаемой задержки, стримите компоненты (отправляйте их на клиент по мере формирования), показывайте ход работы (краткими текстовыми подсказками о каждом шаге).

4. Кэширование промптов – ключ к экономии

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

Лучшие коммерческие внедрения достигают попаданий в кэш на уровне 90–99% – это цель, которую стоит ставить с самого начала. Закэшированные токены читаются быстрее – примерно в 1.5–2 раза при объёме около 100 тысяч токенов.

Кэширование строится на основе префикса. Разбивайте запрос на три сегмента в порядке убывания частоты изменений:

1. Глобальный сегмент, большая часть системного промпта и определений инструментов – одинаков для всех сессий – самый горячий кэш, редко инвалидируется.
2. Сессионный сегмент, контекст пользователя и история диалога – различается между сессиями, но стабилен внутри одной.
3. Изменчивый сегмент, то, что меняется внутри сессии (текущее время, текущая страница) – помещайте в конец запроса.

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

5. Система памяти

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

Долговременная память делится на три части, хранение, запись и чтение.

Хранение памяти

Память принадлежит вашей системе, а не модели. Каждая единица памяти  это небольшая типизированная запись, ключ (например, shoe_size), короткое значение, категория и сессия-источник. Такой подход в БД обеспечивает возможность запросов, детерминированное поведение и привязку к данным пользователя.

Для агентов продавцов привязывайте память к человеку, а не к учётной записи, потому что за одним логином часто работают несколько человек.

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

Запись памяти – асинхронная

В конце каждого раунда (или через несколько раундов в длинных сессиях) отдельный поток или процесс с агентом читает диалог и создаёт, обновляет или удаляет факты. Такой подход не увеличивает задержку диалога, и в наших внутренних оценках он дал на 13% более высокий показатель полноты извлечения фактов.

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

Чтение памяти трёхуровневое

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

6. Безопасность, принудительное исполнение в обвязке (Harness)

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

Каждое правило безопасности реализуется в коде,  как для покупательских, так и для продавцовских агентов, и определяется один раз для всех сред выполнения.

Модель только предлагает, но не исполняет

Ни один вызов инструмента не может напрямую перемещать деньги или менять бизнес-логику. Оформление заказа, оплата, возврат, изменение цены, запуск акции,  все эти операции завершаются действиями под контролем оркестратора, а не модели. На стороне покупателя инструмент оформления заказа просто отображает корзину и кнопку «Заказать»  бэкенд не имеет метода списания средств. На стороне продавца каждый инструмент записи генерирует временное изменение с серверным ID, а apply_change срабатывает только для тех ID, которые были утверждены через реальные интерфейсы (кнопки в панели оператора, подтверждение в CLI, запросы в платформенных инструментах и т.д.).

Самое опасное действие модели – это «предложение», а утверждение проходит через уже существующие в бизнесе процессы «разделения полномочий».

Принимайте только ID, выданные сервером

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

Лимиты принудительно применяются к конечному состоянию

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

Контент от третьих лиц должен проходить очистку

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

7. Оценка (Evals), как тестировать недетерминированную систему

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

Оценивайте снимки (Snapshots), а не диалоги

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

Тестируйте поведение в сложных условиях

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

Охватывайте разные типы оценок

Эффективные оценки должны проверять как ожидаемое поведение, так и нежелательное. Для каждого позитивного сценария напишите негативный аналог, каждому «должен предоставить» соответствует «должен отказать», каждому «должен сделать сразу» соответствует «должен уточнить».

Необходимо охватить такие категории:

• Основные запросы, простые запросы, составляющие большую часть трафика, запросы с множеством ограничений, вопросы о товарах, сообщения с несколькими намерениями.
• Запросы, зависящие от контекста, ссылки на содержимое экрана, ограничения, перенесённые через раунды, операции с существующей корзиной.
• Безопасность и бренд, попытки инъекций, попытки читать чужие данные, регулируемые высказывания (проверять посимвольно).
• Интерфейсные оценки, правильность рендеринга компонентов, соблюдение лимитов, отсутствие внутренних идентификаторов в тексте, видимом пользователю.
• Кросс-функциональные запросы, запросы, относящиеся одновременно к нескольким областям (например, «хватит ли снижения цены на 15%, чтобы покрыть спрос?» – и ценообразование, и запасы).

Привлекайте экспертов и используйте реальные инциденты

Привлекайте к разработке тестов экспертов из отделов продукта, юристов, коммерческих операций, поддержки клиентов, управления категориями – тех, кто видит реальные сбои. Реальные ошибки это лучший материал для тестов. Хорошее начало – 50–100 тестов на каждый пользовательский сценарий.

8. Координация в крупных организациях

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

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

Основные выводы

Создание эффективного коммерческого агента – это поиск баланса между интеллектом, задержкой, затратами и безопасностью. Ключевые принципы:

1. Единый агент + навыки лучше, чем разделение на субагентов.
2. Инструменты вызывают существующие системы, а не переизобретают их.
3. UI-компоненты оформляются как инструменты, а не как кастомная разметка.
4. Целевой показатель попаданий в кэш – 90–99%.
5. Память записывается асинхронно, не увеличивая задержку диалога.
6. Безопасность обеспечивается в обвязке, модель только предлагает, но не исполняет.
7. Оценки строятся на снимках, покрывают позитивные и негативные сценарии.

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

Источник: claude.com