Агент смотрит десять товаров из сотни, потому что инструмент отдаёт «до 15 результатов», а в таблице для модели — обрезка. Авторы уже рассказывали, как собрали AI-менеджера маркетплейсов на регулярках, а потом пересадили его на агента и тут же обложили жесткими ограничениями: восемь шагов на ход, узкие инструменты с лимитами, урезанные данные, запись в кабинет только после согласия владельца.
Попытки построить собственное ядро AI-агента с жесткими ограничениями ведут к операционному тупику и переходу на готовые фреймворки. Точные финансовые потери разработчики не раскрывают, но сам масштаб инженерного тупика хорошо виден по кодовой базе, которую пришлось полностью переписывать после неудачных тестов. Разработка собственного движка требует постоянных инвестиций в поддержку инфраструктуры циклов выполнения, обработку ошибок, сериализацию состояния и управление контекстом. Когда команда пишет велосипед для оркестрации вызовов вместо использования готовых инструментов, она фактически сжигает бюджет на решение инфраструктурных задач, которые уже решены в профильных библиотеках.
Скрытые издержки кастомной разработки кроются не только в часах инженеров, потраченных на написание инфраструктурного кода, но и в стоимости его дальнейшего сопровождения. Каждое обновление API внешних сервисов — будь то изменения в схемах маркетплейсов или новые требования к безопасности — заставляет переписывать обёртки, кастомные парсеры и логику обработки шагов. В результате поддержка собственного ядра начинает съедать ресурсы команды, которые должны идти на продуктовую логику и бизнес-метрики. Инженерный отдел оказывается заложником собственной кодовой базы, где исправление одной ошибки в цикле агента рождает три новых сбоя в смежных модулях.
Иллюзия высоких оценок в тестах
Сначала тесты показывали формальный успех: модель-судья ставила ответу оценку от 1 до 5 и видела данные, на которых агент отвечал.
Агент обошёл старый разбор фраз у семи должностей из девяти, менеджер маркетплейсов набрал 4,28.
А потом разработчики стали читать сами разговоры, и картина стала другой. Агент отвечал уверенно, но поверхностно, а судья такой ответ не ловил, потому что данные, которые видел агент, с выводом сходились. Ограничения в виде лимита в восемь шагов били по длинным задачам вроде разбора падения ниши, где агенту банально не хватало инструкций для глубокого анализа.
Переход на готовые фреймворки
Собственное ядро давало полный контроль над логикой и шагами агента, защищая от непредсказуемого поведения стандартных фреймворков, пока разработчики не уперлись в тупик поддержки собственных циклов. Экономика перехода на готовые решения становится очевидной, как только компания начинает считать совокупную стоимость владения кастомным движком. Поддержание собственной инфраструктуры вызовов, написание кастомных валидаторов ответов и отладка состояний агента требуют сотен часов квалифицированного труда разработчиков, чья стоимость на рынке высока.
поэтому мы удалили своё ядро целиком и перевели ход агента на Pydantic AI.
Как сообщили авторы проекта, через четыре дня после запуска они полностью удалили своего агента. Коммит получился такой: 582 строки удалено, 121 добавлена. Вместо десятков обёрток над отдельными методами Wildberries у агента появился инструмент wb_help — официальная справка по ним.
Сколько еще команд потратят недели на написание кастомных циклов обработки шагов, прежде чем признают экономическую нецелесообразность поддержки собственного кода?
Почему это важно
Зачем инженерам упорно собирать собственное ядро для AI-агентов, если иллюзия полного контроля мгновенно разбивается о суровую практику? Создатели AI-менеджера маркетплейсов попытались застраховаться от сюрпризов готовых библиотек жесткими лимитами, обрезав данные инструментами и ограничив ход восемью шагами. Автономная система бодро отчитывалась модели-судье с высшими баллами, но на поверку выдавала совершенно поверхностные ответы на длинных задачах. Лимит в восемь шагов гарантировал абсолютную безопасность системы от ошибок — заодно избавив ее и от всякой полезной аналитики.