Перейти к содержанию
среда, 23 сентября 2026 г.

ИИ Вестник

Главные новости о развитии искусственного интеллекта в России

Двенадцать дней ИИ-агента на боевом B2B-портале: четыре реальные поломки и предсказуемые ошибки

Источник: Все публикации в потоке Разработка
AI agent monitoring B2B portal dashboard, office desk, wholesale building materials, photorealistic.
Generated by Sourceful Riverflow (RouterAI)

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

С 26 августа по 8 сентября 2026 года один из разработчиков провёл необычный эксперимент: он подключил ИИ-агента к действующему B2B-порталу оптового поставщика отделочных материалов. Проект насчитывает три бренда, около полутора тысяч товарных позиций и тридцать сотрудников в офисе. Портал закрыт для клиентов-юрлиц, а обмен данными между сайтом и 1С идёт по расписанию. До внедрения портала менеджеры вручную выгружали прайсы в Excel, рассылали их клиентам и заносили заказы в учётную систему, из-за чего заказы, поступившие вечером, попадали в учёт только на следующее утро. Именно на этом фоне агент должен был продемонстрировать, на что способен в реальных условиях, а не в демонстрационных сценариях. Обмен между сайтом и 1С ломается ровно там, где стыкуются две чужие системы, и ломается тихо: никто не звонит, ничего не падает, просто где-то не та цена. Вот эта тишина и стала основной работой агента.

За двенадцать дней агент совершил 456 рабочих заходов, то есть примерно 38 в сутки. Из них 235 задач были закрыты, 105 заявок на вливание кода обработано, а 28 раз обновления выкатывались на боевой сервер. Однако эти цифры сами по себе не говорят о качестве работы: 456 заходов легко набить, если ходить кругами. Гораздо важнее, какие именно проблемы решались. Среди наиболее показательных случаев — обнуление цены из-за отсутствия данных в 1С, появление дублей заказов из-за двойного запуска ночной выгрузки, концевой пробел в номере заказа, ломающий поиск, и не собравшаяся витрина второго бренда. Каждый из этих инцидентов требовал не просто правки кода, а понимания архитектуры и бизнес-логики. Показательно, что половину поломок агенту никто не приносил: он обнаруживал их сам, без жалоб от клиентов или менеджеров.

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

Контекст эксперимента важен для понимания рынка. Большинство публикаций об ИИ-агентах, пишущих код, ограничиваются демонстрациями на чистых репозиториях или учебных задачах. Здесь же агент работал на живом проекте, где сбои в обмене данными между сайтом и 1С происходят тихо и не сразу заметны. Опыт показывает, что интеграция разнородных систем — это та область, где ИИ может принести реальную пользу, но только при условии правильно выстроенного процесса. Конкурирующие решения, такие как автономные агенты для администрирования СУБД или триажа уязвимостей, также сталкиваются с необходимостью адаптации к конкретной инфраструктуре и бизнес-правилам. Например, в других публикациях описывается агент для VACUUM/ANALYZE, запущенный на 800+ тестовых БД, и системы триажа уязвимостей, где календарный SLA уступает место оценке риска. Все они подтверждают общий тренд: автономность требует встроенных механизмов верификации.

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

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

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

Читайте также