Четыре ИИ-агента на экзаменационных задачах по платформе: методика, инциденты стенда, стоимость

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

Зачем это было нужно

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

Участников четверо. Все работают через агентские оболочки в терминале, без человека в цикле:

Председатель — пятая модель (Anthropic Claude Fable 5.1), которая по правилам эксперимента задачи не решает: рассылает задания, гоняет автопроверку, ведёт журнал, разбирает инциденты и, по решению автора, судит теорию. Автор сидел рядом и вмешивался только правилами: «запускай последовательно», «будь судьёй сам», «сначала закрытая книга, потом с документацией», «четвёртый раздел разом».

Что и как проверялось

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

• П1 — оперативный учёт;
• П2 — бухгалтерский учёт;
• П3 — расчёт;
• П4 — бизнес-процессы;
• П5 — управляемые формы.

Теория — билет уровня «эксперт по технологическим вопросам»: три основных вопроса и шесть дополнительных. Формулировки не приводим; общие темы билета известны из программы экзамена — блокировки и параллельность, планы запросов и индексы, технологический журнал, настройка СУБД.

Правила. Участник получает письмо с заданием и час как ориентир. Конфигурацию собирает с нуля в XML-выгрузке, без Конфигуратора и EDT, на общем стенде: Ubuntu-ПК с платформой 8.3.27, файловые базы, консольные инструменты (гейт загрузки конфигурации, исполнитель кода в живой базе, проверка модулей). Сдаёт исходники, скрипт создания тестовых данных по сценарию из задания и скрипт снятия результата в фиксированном текстовом формате. Председатель загружает конфигурацию в чистую базу, гоняет оба скрипта и построчно сравнивает вывод с тем, что даёт эталонное решение на тех же данных. Ожидаемые цифры участнику не выдаются — сойтись с эталоном и есть задача. Провал возвращается с выводом проверки, не больше двух раз. Для форм добавлен структурный чеклист по XML формы и картинка формы для судьи: кликать по форме без человека нечем, и это честно записано в ограничениях.

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

Акт первый: все сдали, но время различалось в пять раз

П1 разослали всем четверым одновременно в 14:43 UTC. Итог по проверке — 12 строк из 12 у каждого.

Если бы статья заканчивалась здесь, вывод был бы очевидным и неправильным: «Opus в пять раз быстрее». Разница во времени почти целиком объясняется тем, что происходило на стенде, и это стоило расследовать.

Инцидент 1. Убийца из ядра

Через 17 минут после старта нагрузка на ПК подскочила до 33, а в 15:00 ядро Linux убило процесс ibcmd: импорт конфигурации glm занял 12 гигабайт памяти. Причина была не в стенде, а в его собственной выгрузке — ошибку в структуре XML glm потом нашёл и поправил сам. Но сначала он списал смерть процесса на конкуренцию с соседями и собирался повторить тот же импорт, что снова положило бы стенд всем четверым. Председатель прислал ему факт из dmesg без подсказок — и этого хватило, чтобы glm перестал винить стенд и разобрался в своей выгрузке.

Инцидент 2. Общий файл на четверых

opus5 в отчёте о сдаче написал одну фразу, которая объяснила половину странностей вечера: инструмент выполнения кода в базе складывает результат в общий файл на ПК, и при параллельных запусках чужой ожидатель забирает результат первым. Мы проверили: код, результат и лог запуска действительно шли через три общих файла, а вызовы разводились глобальной блокировкой на стороне сервера, где живут агенты. Четверо ждали друг друга до десяти минут, а клиент, переживший убитую обёртку, писал ответ в чужой вызов. Именно поэтому шаг «живой сеанс» в гейте загрузки у всех участников выдавал пустоту, а opus5 потерял 35 минут не на задаче.

Инцидент 3. Дружественный огонь

deepseek, у которого повис клиент, снял процессы на ПК командой с шаблоном по всем клиентам инструмента. Под раздачу попали прогон glm и официальная проверка opus5. Участнику указали, он извинился и дальше снимал только свои процессы по точному имени.

Что было сделано между актами

Исполнитель кода получил уникальные файлы на каждый запуск (обработка берёт суффикс из имени собственной копии), глобальная блокировка снята, при любом обрыве обёртка убирает только своего клиента. Три параллельных вызова на разных базах теперь укладываются в 13 секунд вместо трёх последовательных по 11. Ожидаемые значения проверки скрыли от участников: выяснилось, что скрипт самопроверки при расхождении печатал ответ, а задание предлагало им пользоваться. Утечки не случилось — единственный запустивший его прошёл с первого раза, — но дыру закрыли флагом председателя.

Акт второй: ошибка, которая стоила deepseek сорок минут

deepseek вызвал в модуле документа функцию ДобавитьДень, которой в платформе нет. Дальше произошло вот что:

1. Гейт загрузки конфигурации сказал «CheckModules: чисто».
2. Проверка кода по каталогу тоже промолчала.
3. При проведении документа платформа показала окно «К сожалению, возникла непредвиденная ошибка», клиент повис, а исполнитель кода вернул «результата нет» без причины.
4. deepseek, чья модель не умеет читать картинки, сорок минут искал причину: маркеры в базе после каждого шага, скриншот окна через OCR, прогон подозреваемой функции отдельным фрагментом.

Мы воспроизвели каждую из трёх дыр:

Гейт врал. Конфигуратор при ошибке компиляции пишет в лог строку вида {Документ.Пени.МодульОбъекта(161,13)}: Процедура или функция с указанным именем не определена (ДобавитьДень) и возвращает код 101. Скрипт гейта искал в логе слово «ошибка», которого там нет, а код возврата терял, потому что запускал Конфигуратор отвязанным процессом. Правка: код возврата пишется в файл, провал — ненулевой код или строки в фигурных скобках. Первая версия правки тут же забраковала чистый код: при отсутствии ошибок Конфигуратор пишет в лог «Синтаксических ошибок не обнаружено!», и лог непустой. Поймал opus5, работавший в этот момент над второй задачей.

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

Инструмент молчал. Включили на ПК технологический журнал только на исключения. В нём та самая ошибка лежит с пометкой «shown to the user» — это и есть окно. Исполнитель кода теперь следит за своим клиентом и каждые две секунды заглядывает в журнал: битый модуль даёт отказ за четыре секунды с точной строкой вместо минуты молчания. Попутно выяснилось, что ключ командной строки для отключения окна непредвиденной ошибки в толстом клиенте не действует.

Акт третий: на честных инструментах

Дальше задачи шли на починенных инструментах: вторую пара Opus получила одновременно как тест параллельности, glm и deepseek — следом; третью — так же; четвёртый раздел, две задачи подряд, все четверо получили разом.

Все двадцать сдач за вечер приняты с полным совпадением. Единственный возврат — у glm: итоговые суммы сошлись, а детализация проводок нет. По раскладке «20 совпало, 10 нет» он нашёл причину за десять минут.

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

Четвёртый инцидент оказался призраком. deepseek увидел в диагностике записи «Не обнаружено свободной лицензии» и построил цикл ожидания, пока «glm освободит лицензию». Записи уровня INFO пишет каждый клиент при старте, после чего получает лицензию по сети; отказов не было ни одного. Инструмент честно печатал последние исключения за неимением ошибок — и вводил в заблуждение. Семнадцать минут deepseek и ещё одна правка диагностики.

Бизнес-процессы и формы прошли быстрее всего: карту маршрута все четверо описали в XML, ролевую адресацию привязали к предопределённым элементам, групповую точку платформа размножила сама. Зато формы вскрыли слой инструментов: генератор форм задаёт колонки таблиц не тем ключом, теряет заголовок свёрнутой группы и сбрасывает основную форму объекта; импорт не принимает произвольный запрос динамического списка по табличной части документа. Каждый обошёл по-своему: критерием отбора, программным отбором, подзапросом. Судья по картинкам форм увидел и разницу в аккуратности: у opus5 подписи полей человеческие и есть обработчик для нового элемента, у двоих вместо подписей — пути данных, у одного форма без поля наименования и с сырыми именами команд.

Акт четвёртый: теория в три круга

Теоретический билет эксперта каждый сдавал трижды, без очистки контекста между кругами: сначала только из собственных знаний, читать можно было лишь задание; потом с офлайн-документацией платформы; потом с методической поддержкой ИТС, бывшим kb.1c.ru. Оценка 0–10 за вопрос по единой рубрике, судья — председатель. Ключа ответов у 1С в открытом доступе нет, поэтому это экспертная оценка, а не сверка с эталоном; спорные факты сверялись по документации.

Три наблюдения оказались интереснее итога.

Ошибаются одинаково. В закрытой книге оба Opus одинаково решили, что управляемая блокировка вне транзакции просто не действует — по руководству разработчика платформа бросает исключение. glm и deepseek одинаково уверены, что управляемые блокировки появились только в 8.2, и оба выдумали способ снять управляемую блокировку до конца транзакции. Ошибку в предложенном фрагменте кода без документации заметил только opus5; opus48 и glm не увидели его ни с документацией, ни с методичками.

Документация лечит формулировки. Руководства платформы дали всем плюс 4–12 баллов, и ровно там, где нужны точные слова: исключение вне транзакции, пространства блокировок, уровни изоляции. Внутренности MS SQL и PostgreSQL в них не описаны, и там оценки не двигались.

Методичку надо читать против вопроса. Отдельно выяснилось, что методподдержка ИТС — статьи бывшего kb.1c.ru, где тема первого вопроса разобрана подробно, — у нас есть в офлайн-подборке, но к инструментам подключена не была. Подключили и дали третьим кругом. Основные вопросы выросли у всех: opus5 вышел на полный балл, opus48 нашёл в базе разбор нашего случая и официальную рекомендацию 1С включать асинхронное обновление статистики. Но glm и deepseek на статье про отбор событий блокировок по длительности сломали верный ответ: статья описывает блокировки, которые ждали и были получены, а они прочли «событие пишется и при неуспешной попытке». Больше документации не значит выше балл; важнее, как её читать.

Что это стоило

По ценам API весь вечер обошёлся бы примерно в 430 $, около 36,5 тысячи рублей по курсу ЦБ: Claude Opus 4.8 — 156 $, Claude Opus 5 — 106 $, председатель на Claude Fable 5.1 вместе с подготовкой четвёртого раздела — 170 $, DeepSeek — 1,3 $. Реально из кармана вышло иначе. DeepSeek — около 110 руб. живых денег за пять практических задач и три круга теории. glm — около 137 руб. как доля месячной подписки: за вечер ушло 39 процентных пунктов недельной квоты. Оба Opus и председатель сидят на одной подписке; по статусной строке за вечер ушло около 4,6 пункта недельного лимита, это примерно 2 $ или 180 руб. Итого весь экзамен четырёх моделей стоил около 430 руб. — примерно в 85 раз дешевле, чем те же токены по ценам API. Кэш решает: у председателя 233 миллиона токенов прочитано из кэша против одного миллиона выхода, и именно кэш делает подписку такой дешёвой при агентской работе.

Что из этого следует

1. Экзамен для модели — это экзамен для инструментов. Все четверо решили все пять задач с совпадением до копейки и сдали теорию на уровне от уверенного специалиста до эксперта. Разница в пять раз по времени на первой задаче объяснялась гейтом, который врал, инструментом, который молчал, и общими файлами, а не «слабостью модели». После починки разброс по одной и той же задаче сжался до 7–33 минут.
2. Нечестный гейт хуже отсутствующего. «CheckModules: чисто» при ошибке компиляции отправляет участника искать проблему не там. Любой автоматический гейт стоит проверить, подсунув ему заведомо битый вход.
3. Молчаливый провал дороже громкого. Сорок минут deepseek — цена одного «результата нет» без причины. Технологический журнал на исключения и четыре секунды до текста ошибки решают это раз и навсегда.
4. Документация даёт баллы там, где нужны точные формулировки платформы, и не даёт там, где нужен взгляд экзаменатора на код.
5. Модели ошибаются похоже. Одна и та же ошибка у двух разных моделей в закрытой книге — повод для отдельного исследования, а не для выводов о качестве.
6. Итерации — честнее времени. opus48: 125 минут и 11 циклов «упало → починил» на пять задач, opus5: 147 и 8, glm: 229 и 27, deepseek: 245 и 33. Половина разницы во времени — стенд первого часа; разница в итерациях — уже про модели и про то, как они читают ошибки.

Что изменилось после публикации

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

Сначала к офлайн-документации добавили подробную подборку по внутренностям СУБД — устройство MS SQL Server и PostgreSQL, книги по архитектуре платформы. Затем поменяли не источники, а способ работы с ними: участник обязан отвечать в два слоя — механика СУБД отдельно, её проявление в 1С отдельно, — подтверждать каждое утверждение ссылкой на конкретное место в документации, а отдельный скрипт сверяет, что цитаты действительно есть в источниках и что при доработке ответа прежние ссылки не потерялись.

opus5 в первом из этих заходов был организатором — собирал подборку по СУБД — и потому в нём не участвовал.

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

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

Что дальше

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

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