30 мая я участвовал в соревновании по разработке e-commerce-агентов. За основу взял gpt-5.4-mini и постепенно окружил её инструментами, проверками и маленькими моделями-помощниками. Эту архитектуру назвал «Экзоскелет». Она выросла из повторяющихся ошибок: модель понимает запрос, но теряет ограничение товара, выбирает неверную ссылку или портит формат последнего ответа.
Какие задачи решал агент
В соревновании агент работает в симулированной среде интернет-магазина: ищет товары, разбирается с корзинами, оформлением заказов, возвратами и сбоями оплаты. Вводные меняются между прогонами. Нельзя один раз запомнить нужный товар и потом узнавать задачу по знакомому названию.
По результатам, которые я зафиксировал в посте после соревнования, агент занял первое место в Speed, десятое в Ultimate и восемнадцатое в Accuracy. В динамическом Live PROD лидерборде он вышел на первое место и оставался там на дату архитектурного поста. Слово PROD здесь — название режима соревнования. Эти результаты относятся к испытательной среде, а работу с заказами настоящих покупателей нужно оценивать отдельно.
Я сознательно начал с младшей модели. В узком домене интересно понять, какую часть сложности можно убрать из её задачи. Если результат зависит от точного подсчёта, правил владения корзиной или набора характеристик товара, для этого можно написать отдельный инструмент.
Как распределена работа внутри экзоскелета
У основной модели осталась роль диспетчера: понять ситуацию, выбрать действия и довести задачу до завершения. Вокруг неё работают gpt-5.4-nano и обычный код. Маленькие помощники разбирают текст там, где требуется понимание языка. Код выполняет операции с ясными правилами.
| Компонент | Задача | Исполнение |
|---|---|---|
| Подготовка среды | Загрузить правила, структуру данных и инструменты | Код |
| Классификатор | Выделить намерения и сущности из запроса | gpt-5.4-nano |
| Предварительные проверки | Проверить ограничения и выбрать допустимый путь | Код |
| Основной цикл | Выбрать инструменты и принять решение | gpt-5.4-mini |
| Помощники домена | Каталог, платежи и другие специальные операции | Модель и код |
| Сборка ответа | Собрать ссылки и выдержать формат | Код и gpt-5.4-nano |
Подготовка экономит лишние обращения к среде. До первого содержательного решения агенту уже доступны регламенты магазина и описание возможностей. Классификатор параллельно выделяет признаки запроса: упоминается ли корзина, нужно ли оформить заказ, есть ли попытка сменить личность или сослаться на чужое одобрение.
У такой схемы есть практический плюс для разработки. Ошибку можно отнести к конкретному месту. Классификатор неверно понял намерение, инструмент потерял условие или финальная сборка испортила готовый результат — это разные задачи для исправления.
Каталог требует точного совпадения условий
Поиск товара кажется простой задачей, пока запрос не содержит несколько ограничений сразу. Одно семейство товара может включать варианты с разными размерами и комплектацией. Найти похожее название недостаточно, если покупатель указал точную характеристику.
В экзоскелете каталожный помощник разбирает запрос в структуру, после чего код сопоставляет ограничения с вариантами товара. В полном архитектурном разборе приведён характерный пример: диск диаметром 185 мм не подходит под запрос на 160 мм. Отрицательные условия тоже обязательны: просьба подобрать комплектацию без аккумулятора должна исключить варианты с аккумулятором.
Для прикладного агента это хороший способ провести границу ответственности. Модель переводит человеческую формулировку в параметры поиска. Затем можно посмотреть, какие именно условия применились и почему выбран конкретный артикул. Если параметров недостаточно для выбора, появляется понятная причина уточнить запрос.
Корзина и оплата требуют проверки состояния
Предварительные отказы по безопасности принимает код: он сверяет признаки запроса с ролью пользователя из среды. Код также может снять неоднозначность при выборе корзины. Дальнейшую политику оформления, включая владение корзиной и остатки, в этой реализации применяет основная модель. Поэтому проверку всех условий оформления нельзя считать полностью вынесенной в код. Текст запроса сам по себе не должен выдавать пользователю новые полномочия; фразу про одобрение менеджера нужно сопоставить с данными.
Похожие требования возникают при восстановлении оплаты после сбоя 3DS. Прежде чем повторять действие, нужно понять, оплачен ли заказ, действует ли блокировка повторных попыток и к какому платежу относится найденное ограничение. В экзоскелете для этого есть отдельный помощник.
Я бы переносил этот принцип в клиентский продукт начиная с конкретных состояний операции. Что разрешено после успешной оплаты? Как обработать повторный запрос? Когда требуется уточнение? Если описать эти переходы явно, модель получает инструмент с ограниченной областью действия. Заодно появляются обычные тесты для переходов между состояниями.
Соревновательная реализация помогла исследовать такие ошибки. Для магазина её правила пришлось бы сопоставить с действующими интеграциями, правами пользователей и процессом подтверждения операций.
Ссылки нужно собирать по ходу работы
В соревновании ответ должен сопровождаться ссылками на соответствующие данные и регламенты. Здесь обнаружилась неприятная проблема: помощник нашёл нужные записи, основная модель сделала ещё несколько шагов и к финалу часть ссылок потеряла.
Я добавил отдельный журнал. Он накапливает найденные помощниками источники и передаёт их в сборку ответа. Модели больше не нужно удерживать весь список в памяти до последнего шага.
Но просто приложить всё прочитанное тоже нельзя. В ходе поиска агент может изучить несколько товаров, а предложить один. В финале должны остаться записи, на которых основан ответ. Доступ к этим записям также нужно учитывать: ссылка на чужую корзину способна раскрыть данные даже в сообщении с отказом.
В корпоративном агенте тот же подход полезен для разбора результата человеком. Сотруднику нужны конкретные карточка товара, заказ и пункт инструкции, по которым агент принял решение. Тогда ошибку можно исследовать без повторения всего диалога вручную.
Последний шаг тоже нужно тестировать
Отдельная группа ошибок была связана с форматом. Задание просит вернуть количество как <COUNT:N>, а модель пишет обычное предложение. Содержание правильное, контракт ответа нарушен.
В конце я поставил форматтер на gpt-5.4-nano. Он приводит готовое сообщение к требуемому виду, сохраняя решение и факты. Так основной модели проще сосредоточиться на выполнении задачи. А форматтер можно проверять отдельно на небольшом наборе примеров.
Экзоскелет дорабатывался по результатам прогонов и разбору ошибок. Для меня здесь главный практический вывод — искать повторяющийся класс сбоев. Когда одна и та же проблема возникает снова, стоит выделить её в отдельный компонент с ясным входом, выходом и тестами. Так становится понятно, что именно улучшилось после очередного изменения агента.
Материал может пригодиться коллегам? Отправьте им ссылку на статью.