Чего ИИ-агент в 1С не может — и не сможет

Зачем эта статья

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

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

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

1. То, что видно только глазами

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

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

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

Что с этим делать. Открывать и смотреть. На Linux-сервере это означает запуск клиента под виртуальным экраном, скриншот и клики через утилиты автоматизации. Технически возможно, но:

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

Реалистичный вывод: финальную проверку интерфейса делает человек. Автоматизировать её дороже, чем открыть и посмотреть.

2. То, что создаётся только формой

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

Задача была завести виды карт лояльности программно:

Элемент = Справочники.ВидыКартЛояльности.СоздатьЭлемент();
Элемент.Наименование = "Промокод 15%";
Элемент.Записать();

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

А в форме выбора этих элементов нет.

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

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

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

3. То, что названо не так, как выглядит

Агент ищет по именам. Предметная область 1С регулярно устроена так, что имя и отображение расходятся.

Значения перечислений подбираются по синониму. На форме вы видите «Скидка (наценка) процентом» — это синоним. Внутреннее имя лежит в метаданных и может отличаться как угодно. Когда бизнес формулирует требование, он говорит синонимами. Агент ищет по именам и не находит.

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

Подчинённость не видна в списке реквизитов. Справочник карт лояльности подчинён виду карты. Обращение к виду как к реквизиту даёт «поле объекта не обнаружено». Правильно — через владельца, и второй параметр метода выборки как раз владелец. По списку реквизитов это не выводится никак.

Работающий приём: смотреть, как с объектом работает типовой код. Я нашёл ответ, прочитав типовую процедуру расчёта скидки — там видно, каким способом платформа сама ищет карту. Это надёжнее, чем гадать.

Реквизит шапки неотличим от реквизита табличной части. Продавец у чека лежит в табличной части «Товары», а не в шапке — в шапке только кассир. Если искать по выгруженному XML, имя найдётся, но по виду фрагмента невозможно понять, где оно находится: разметка одинаковая. Нужно смотреть контекст на несколько уровней вверх, чего текстовый поиск не делает.

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

4. То, чего нет, хотя должно быть

Класс ошибок, где агент строит корректную логику на несуществующем основании.

Нулевая длина кода. У справочников складов и касс длина кода нулевая — реквизита Код физически не существует. В запросе это честная ошибка «поле не найдено». А вот в объектной модели обращение к коду молча возвращает пустую строку. Код компилируется, выполняется, не падает.

Последствие у меня было такое: расширение годами отправляло во внешнюю систему поле с кодом магазина, собранное из этого реквизита. Оно всегда было пустым. Никто не замечал, потому что приёмник просто клал пустую строку в базу.

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

Агент, строя логику, разумно предполагает, что артикул — это идентификатор товара. Разумно и неверно.

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

5. То, что знает только владелец бизнеса

Самое фундаментальное ограничение, и оно не лечится ни моделью, ни документацией.

Реальный случай. Клиент со статусом «сотрудник, 15%» и персональной кампанией «30% на категорию» получил на кассе 45%. Технически всё работало правильно: внешняя система считала персональную скидку от полной цены и про статусную не знала, а форма кассира клала её поверх уже посчитанной автоматической.

Вопрос: это баг или нет?

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

Ни один агент этого не выведет. Ни из кода, ни из документации, ни из данных. Это не техническая задача.

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

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

6. То, что молча не падает

Отдельная категория, объединяющая половину предыдущих.

• LoadConfigFromFiles не компилирует и возвращает нулевой код возврата на заведомо битом модуле;
• обращение к несуществующему коду справочника возвращает пустую строку без ошибки;
• программно созданный объект записывается без обязательных реквизитов;
• после перезапуска сервера умирает демон администрирования, и команда снятия блокировки базы молча не выполняется;
• скрипт восстановления оборвался на середине — команды «выполнились», база осталась закрытой для пользователей.

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

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

Чего в этом списке нет

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

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

Ограничения сосредоточены ровно в двух местах: интерфейс и смысл. Всё, что между ними — код, данные, команды, — его территория.

Выводы

1. Агент не падает — он уверенно ошибается. Это опаснее падения, потому что не создаёт сигнала.

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

3. Программно созданный объект сверяйте с созданным вручную. Форма заполняет то, чего не заполняет код, и различие не видно ни одной программной проверкой.

4. Прежде чем строить логику на поле — проверьте, что оно существует и заполнено. Нулевая длина кода и пустой артикул выглядят одинаково: молча.

5. Что считать правильным — знает владелец бизнеса. Получайте ответ до задачи и записывайте вместе с обоснованием.

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

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

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

Платформа 8.3.27, УТ 11.5. Все случаи — с боевых баз розничной сети, ни один не является гипотетическим.