Руководство по архитектуре эффективных торговых агентов

Полный перевод статьи из блога Claude на русский. Оригинал — по ссылке.

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

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

Этот материал предназначен для инженеров и руководителей инженерных команд, создающих таких (или других ориентированных на потребителя) агентов. Часть 1 посвящена архитектуре, которую Вы определяете один раз. Часть 2 посвящена задержке и стоимости. Часть 3 посвящена производственной среде: памяти, безопасности, оценкам и масштабированию работы в рамках организации.

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

Мы определяем коммерческого агента как агента, который упрощает покупку и продажу через онлайн-каталог.

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

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

Перед ней нет маршрутизатора намерений, который сегментирует разговор, и за ней нет набора специализированных для предметной области агентов.

Инженерный контекст

Навыки, а не подагенты

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

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

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

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

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

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

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

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

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

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

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

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

Системный промпт или навык: решайте по частоте

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

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

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

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

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

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

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

Разработка инструментов для агентов

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

Создавайте инструменты для агентов поверх ваших основных систем и логики.

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

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

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

Результаты работы инструментов — это контекст.

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

При необходимости преобразуйте необработанный ответ внутри инструмента, в том числе добавив следующий шаг, если он не очевиден из данных.

Это особенно актуально для сценариев ошибок, где модели полезнее инструкции, чем коды ошибок. Например, добавьте инструкцию об ошибке "Указывайте идентификатор товара при запросе доступности," вместо общего кода 403.

Компоненты пользовательского интерфейса — это инструменты

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

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

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

Устойчивый подход заключается в том, чтобы сделать каждый компонент пользовательского интерфейса инструментом. Модель вызывает present_products, present_itinerary или present_plan_comparison с типизированными аргументами; Ваш сервер проверяет и обогащает вызов, а затем отправляет событие; Ваш клиент отображает его. 

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

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

Чтобы получить поток на уровне токенов, установите eager_input_streaming: true в определении инструмента — это пропускает буферизацию и вместе с ней гарантию схемы на стороне сервера.

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

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

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

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

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

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

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

Минимизация задержки выполнения задачи

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

Меньше ходов

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

• Загружайте вероятный контекст заранее. Если пользователь открыл ассистента со страницы продукта или продавец открыл его из панели управления кампанией, поместите данные этой страницы в контекст сеанса. Вероятно, разговор будет о ней, а ответ на основе контекста не требует дополнительных ходов.
• Повышайте интеллект модели. Более интеллектуальные модели могут сократить общее количество ходов при выполнении задачи, поскольку агент может эффективнее планировать и выполнять вызовы инструментов. Это часто перевешивает их более медленную генерацию токенов. Если Ваши запросы обычно сложные или в производственной среде на задачу приходится более примерно пяти ходов, более быстрая модель часто оказывается более интеллектуальной. Какая именно — зависит от Вашего трафика, поэтому выбирайте посредством перебора, как описано ниже в разделе "Выбор модели".
• Пусть модель вызывает независимые инструменты параллельно. Сценарии использования в коммерции часто требуют множества параллельных операций: будь то поиск нескольких товаров, запрос множества документов с политиками или получение записей из множества источников данных о продажах. Параллельное использование инструментов гарантирует, что несколько независимых запросов не потребуют дополнительных ходов. Попросите модель вызвать множество инструментов за один ход и вернуть результаты в одном сообщении пользователя в виде массива результатов инструментов (см. документацию по параллельному использованию инструментов).

Более быстрые инструменты

• Оптимизируйте собственный бэкенд инструмента. Иногда инструмент действительно разветвляет запросы — например, агент продавца с запросом «получить снимок состояния на сегодня» получает данные о продажах, запасах и статусе кампаний тремя независимыми вызовами. Но мы часто видим, как граница инструмента становится местом, где сшивается отсутствующая логика бэкенда: проверка доступности вызывает каталог для артикула, службу управления запасами для каждого магазина и службу исполнения заказов для времени отсечения, затем применяет правила замены и соответствия критериям самовывоза в собственном коде инструмента, прежде чем дать ответ. Такой инструмент теперь перегружен знаниями предметной области, его трудно поддерживать корректным по мере изменения правил, и он несёт логику, которая должна находиться в вышестоящей системе. Когда Вы обнаруживаете, что пишете такую логику в инструменте, решение — одна конечная точка бэкенда, отвечающая на вопрос, и её вызов с помощью инструмента агента.
• Незамедлительно запускайте инструменты. Аргументы инструментов передаются из модели потоком, как и любые другие токены, поэтому среда выполнения может выполнять вызов каждого инструмента по мере завершения передачи его аргументов и обрабатывать его, пока модель всё ещё передаёт другие параллельные инструменты или блоки содержимого. Мы видели, как это сокращало многосекундные промежутки до нескольких сотен миллисекунд, и Claude Agent SDK делает это по умолчанию. Вам следует предложить модели сначала выдавать самый медленный вызов, чтобы максимально сократить задержку.

Воспринимаемая задержка

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

• Передавайте компоненты потоком по мере их формирования. Отрисованный ответ для электронной коммерции обычно составляет 500–700 выходных токенов, что без потоковой передачи означает пять или более секунд индикатора загрузки. Отправляйте клиенту каждый параметр инструмента представления по мере его потоковой передачи и отображайте страницу постепенно.
• Показывайте ход работы. Пока агент собирает контекст, отображайте короткую строку о ходе выполнения для каждого шага простым языком (например, "ищем отели у воды"). Вы можете сформировать её на основе существующих аргументов инструмента (например, запроса для поиска товаров) или добавить в инструмент дополнительный параметр user_facing_message, который предлагает модели написать эту строку. 

Кэширование подсказок

Кэширование подсказок — ваш главный кандидат на снижение затрат, и коммерческий трафик хорошо для этого подходит. Чтение входных токенов из кэша стоит в десять раз дешевле, чем обработка новых токенов, и хотя запись в кэш обходится примерно в 1,25 раза дороже, кэшированный префикс окупается при втором использовании. В приложениях, ориентированных на клиентов, с большим объёмом трафика у Вас есть уникальная возможность достичь очень высокого уровня кэширования, используя самое дешёвое стандартное время истечения кэша — 5 минут.  

Лучшие развёртывания коммерческих систем, которые мы видели, работают при показателе попаданий в кэш 90–99%, и именно на этот диапазон следует ориентироваться с самого начала. Наш опыт показывает, что чтение токенов из кэша также примерно в 1,5–2 раза быстрее при ~100 тыс. токенов, с относительно линейным масштабированием по мере увеличения количества токенов. 

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

• Глобальный: большая часть системного промпта и определения инструментов, одинаковые для каждого сеанса. Это ваш наиболее активно используемый кэш, и в масштабе он, вероятно, не будет истекать. Сохраняйте его побайтно идентичным между ходами и сеансами и установите точку разделения кэша в его конце.
• Сеанс: контекст для каждого пользователя и история разговора, которые различаются между сеансами, но остаются стабильными в рамках одного сеанса. Этот сегмент располагается после глобального.
• Изменчивое: всё, что меняется в рамках сессии, например текущее время или текущая страница. Помещайте это в самый конец запроса: либо в виде блока с тегами в новейшем сообщении пользователя, либо, в моделях, поддерживающих системные сообщения в середине диалога, в виде сообщения с ролью system, добавленного в массив messages. Наиболее распространённая ошибка, которую мы наблюдаем, — отметка времени или текущая страница в начале системного промпта, что незаметно нарушает кэш при каждом запросе.

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

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

Выбор модели и её конфигурации

Размер модели и настройка усилий — это один и тот же компромисс между интеллектом, задержкой и стоимостью, и оба следует выбирать на основе измерений:

1. Выберите метрику и минимальный порог. Выберите метрики качества, на которых строится ваш бизнес (завершение задач, релевантность ответов, точность с опорой на источники), оценочный балл, ниже которого Вы не опуститесь, а также бюджеты на задержку и стоимость p50 и p99.
2. Проведите перебор. Запустите весь набор оценок для каждой модели и каждого уровня усилий, которые Вы рассматриваете. Мы рекомендуем начинать с Opus для агентов для продавцов, чьи задачи в значительной степени связаны с анализом, и с Sonnet для потребительских агентов, где задержка имеет больший вес. Если у Вас есть производственный трафик, взвесьте результаты по Вашему реальному распределению запросов. Затем позвольте цифрам принять решение. Иногда преимущество Opus 5 в задачах, стимулирующих добавление товаров в корзину, оправдывает разницу в стоимости по сравнению с Sonnet, а иногда — нет.‍
3. Внимательно изучите результаты. Команды регулярно удивляют две вещи. Во-первых, промпт настраивается под конкретную модель, поэтому запуск перебора с одним промптом может показать худшие результаты на других моделях, для которых он не был написан. Модели меньшего размера обычно нужны инструкции, которые текущая модель выводит самостоятельно, а более крупная будет следовать инструкциям буквально, тогда как меньшая их игнорировала. Несколько раундов итераций по проблемным случаям каждого кандидата — недорогой шаг перед тем, как исключать кого-либо из них. Во-вторых, более интеллектуальная конфигурация иногда выигрывает по задержке, чаще всего по p90 и p99, несмотря на более медленную генерацию токенов, потому что она лучше планирует вызовы инструментов и требует меньше раундов для наиболее сложных запросов.

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

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

Память, сохраняющаяся между сессиями

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

Хранение воспоминаний

Память должна находиться в Ваших системах, а не в модели. 

Плоский профиль в формате markdown подходит, когда профили небольшие и агент — единственный читатель. Большинство промышленных коммерческих агентов перерастают его, и практической заменой становится база данных, которую Вы уже используете. Факт — это небольшая типизированная запись: ключ (например, shoe_size, default_store, preferred_report_cadence), короткое значение, категория и сессия, из которой он получен. Некоторые ключи Вы определяете заранее, и они есть у каждого пользователя; остальные обнаруживает экстрактор. База данных сохраняет возможность выполнения запросов по мере роста хранилища, позволяет выстраивать детерминированное поведение на основе конкретных атрибутов и связывается с данными пользователей, которые у Вас уже есть.

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

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

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

Запись в память

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

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

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

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

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

Чтение памяти

Читайте память в трёх слоях.

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

Безопасность: принудительное обеспечение находится в обвязке

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

Модель подготавливает; человек или политика применяет

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

На стороне потребителя это структурно: инструмент оформления заказа отображает корзину с кнопкой для размещения заказа, а интерфейс бэкенда, который вызывает агент, вообще не имеет метода списания средств.

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

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

Операции записи и отображения принимают только идентификаторы, выданные сервером

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

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

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

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

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

Ограниченные транзакции должны соблюдаться при повторных запросах

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

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

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

Сторонний контент очищается

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

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

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

Промпт содержит другую половину соглашения: текст в блоке — это материал, о котором следует сообщать, но никогда не материал для выполнения действий.

Оценки: выпуск недетерминированной системы

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

Оценивайте снимки состояния, а не разговоры

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

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

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

Оценивайте поведение в сложных условиях

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

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

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

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

Оцените следующее:

• Основные запросы, которые составляют основную часть вашего трафика, поскольку сбой здесь затрагивает большинство сессий. К ним относятся простые поисковые запросы, запросы с несколькими ограничениями, вопросы о товарах и планах, а также сообщения с несколькими намерениями. Для вопросов проверьте, что каждая цена, доступность и характеристика основаны на возвращённых данных и что агент сообщает, когда данные отсутствуют, вместо того чтобы выдумывать их.
• Запросы, зависящие от контекста, например ссылки на то, что находится на экране, ограничения, перенесённые из предыдущих ходов, и записи в существующую корзину. Оценка памяти также относится к этой категории. Проверьте, что воспоминания были извлечены, получены и изменили ответ.
• Случаи, связанные с безопасностью и брендом, где сбой стоит денег или доверия. К ним относятся попытки инъекций, попытки прочитать данные другого пользователя и регламентированные формулировки, которые проверяются байт за байтом. Разделите инъекции на два случая: инъекция, созданная пользователем, когда директива поступает из собственного сообщения пользователя, и инъекция уровня данных, когда она внедрена в названия товаров, отзывы или фрагменты веб-страниц, поступающие через результаты инструментов.
• Оценки интерфейса, чтобы убедиться, что отображается правильный компонент, соблюдаются ограничения на количество элементов и в видимом пользователю тексте отсутствуют внутренние идентификаторы. Также проверяйте тайм-ауты и пустые результаты.
• Запросы, которые одновременно относятся к нескольким возможностям. Оператор спрашивает "если я сделаю скидку 15%, хватит ли у меня запасов, чтобы покрыть спрос?" Это одновременно вопрос ценообразования и вопрос запасов. Правильный ответ предусматривает применение скидки с приложенным прогнозом запасов; неправильные ответы выполняют одно и пропускают другое. Оценки, составленные для каждой возможности отдельно, этого не выявят, поскольку каждая из них оценивает только свою половину. Пишите сценарии для запросов, требующих совместного использования двух смежных возможностей, и оценивайте обе половины ответа.

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

Обязательно подготовьте разнообразные кейсы, как указано выше. Транскрипты из продакшена — отличный поток для поиска новых кейсов, особенно сложных. Агенты для написания кода хорошо подходят для создания дополнительных кейсов и состязательных вариантов. Репозиторий с примерами включает плагин Claude Code с навыком создания оценок, разработанным с использованием рекомендованного нами подхода.

Внедрение в крупной организации

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

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

Соблазнительное решение — разделить систему на множество субагентов, по одному на каждое бизнес-подразделение. Как обсуждалось в части 1, мы не рекомендуем этого по причинам, связанным с качеством. Вместо этого мы описываем процесс снижения рисков при сотрудничестве нескольких команд:

• Ответственность следует за системами. У каждого навыка и инструмента есть одна команда-владелец. Например, команда ценообразования владеет инструментами для акций и навыком ценообразования, а команда поддержки — инструментами для заказов и возвратов и навыком клиентской поддержки. У общего промпта есть один владелец на уровне платформы для общих частей и владелец домена для раздела, специфичного для домена.
• Изменение поставляется вместе со своими кейсами, а CI запускает набор, выбранный для него. Команда, добавляющая навык, также добавляет его кейсы, включая негативные кейсы и пограничные кейсы с соседними навыками. Запуск полного набора на каждый pull request слишком медленный и слишком дорогой, чтобы быть жизнеспособным, поэтому вместо этого сформируйте из него набор для CI. Этот набор будет состоять из базового набора кейсов с запросами с наибольшим трафиком и всех кейсов безопасности. Кроме того, запускайте кейсы для всего, чего коснулось изменение. Для навыка это означает его собственные кейсы и пограничные кейсы его соседей. Для инструмента — каждый кейс, который его вызывает. Для общего промпта — полный набор оценок, поскольку всё читает системный промпт. Мы рекомендуем устанавливать порог по доле успешных прохождений на нескольких запусках, а также по доле попаданий в кэш и стоимости одного хода. Также рекомендуется запускать полный набор каждую ночь и перед каждым релизом. Межкомандные регрессии выявляются в этих запусках.
• Агент также должен быть включён в календарь релизов. Это единый модуль развёртывания, поэтому неудачное изменение сразу затрагивает каждого пользователя. Сначала развёртывайте изменения промптов и навыков для канареечной когорты, предусмотрите переключатель, отключающий один навык без развёртывания, и замораживайте агента перед пиковыми периодами так же, как вы замораживаете другие системы.

О человеческой стороне этой схемы читайте в статье «Создание эффективных команд из людей и агентов».

Взгляд в будущее

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

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

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

Благодарности

Написано Мэтью Кёном и Али Шазалом. Особая благодарность Майклу Сегнеру, Родриго Оливаресу, Амандепу Кхуране, Айзе Усман, Джону Лопусу и другим за их вклад.