Одна задача 1С в OpenCode и NanoBot: четыре разных исхода

Виталий передал на проверку ответы OpenCode и NanoBot на одну задачу с ТаблицаЗначений. Один ответ NanoBot получил на 57 баллов больше ответа OpenCode модели с тем же названием; в других случаях такого выигрыша не было. Разбираем цифры и ошибки, которые скрывает общий балл.

В первой статье мы проверяли, как локальные модели используют знания 1С: Синтакс-помощник, БСП и стандарты. Во второй перешли к одной рабочей задаче: объединить две таблицы значений по ключу. Там победил Qwen3.8 27B с 78/100, но его полный код всё ещё содержал ошибки платформенных вызовов.

Теперь посмотрим на ответы из другого агентского клиента, или harness, — NanoBot. Клиент ведёт разговор с моделью, передаёт ей ответы инструментов и решает, когда просить продолжение. Мы сравнили получившийся код OpenCode и NanoBot на задаче объединения таблиц.

Что было на входе

Задача осталась той же: две ТаблицаЗначений с общей колонкой Ключ, заранее неизвестные остальные колонки, все ключи и уникальные колонки в результате. Если значения одноимённой колонки конфликтуют, решает явно выбранная приоритетная таблица. Агенту предлагалось опираться на знания платформы, БСП, стандарты и LEM.

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

На проверку попали шесть решений OpenCode и пять решений NanoBot для одной задачи. От OpenCode остались журналы работы, от NanoBot — тексты ответов и их разбор. Этого достаточно, чтобы сравнить качество кода. Сравнить скорость и число обращений к LEM нельзя: для NanoBot таких записей нет. Мы также не подтвердили, что в обоих клиентах запускались одни и те же файлы моделей. Поэтому таблица ниже сопоставляет ответы моделей с одинаковыми названиями, а не результаты строго одинаковых запусков.

При проверке мы смотрели на четыре вещи: близость к рабочему BSL — 35%, качество алгоритма и кода — 30%, выполнение задания — 25%, правильное применение знаний 1С, БСП и LEM — 10%. Баллы показывают качество полученных ответов, а не результат запуска в 1С. Готового к работе решения среди них не было.

Четыре семейства — четыре разных истории

Семейство модели	OpenCode	NanoBot	Что получилось
RTX Qwen 35B	17	74	+57 баллов: структура решения стала ближе к рабочей, остались синтаксис и поиск без индекса
Qwen3.8 Flash	68	69	+1 балл: архитектура стала аккуратнее, но ошибки имён и приоритета сохранились
Qwen3.8 27B	78	26 и 54	−52 и −24: первый ответ содержал несуществующий ЕстьТип, второй оборвался без трёх вспомогательных функций
Gemma 4	12	3	−9: новый ответ закончился прежде, чем появился рабочий алгоритм

Ещё два ответа OpenCode — Qwen 122B (24) и Qwen3 Coder Next (10) — не имеют найденной пары NanoBot в этом наборе. Они учтены в рейтинге второй статьи, но не превращены здесь в мнимое попарное сравнение.

RTX Qwen 35B: самый заметный скачок

В OpenCode ответ RTX Qwen 35B набрал 17/100. Агент успел обратиться к LEM девять раз в рамках задания и завершил ответ примерно за 104 секунды, но оставил вымышленные элементы BSL: Состав, ОписаниеТипов(), Выброс Ошибка(...). Вдобавок выбрал первую общую колонку вместо заданного Ключ и неверно перенёс общие колонки для строк только из второй таблицы. Сессия уже содержала предыдущий разговор, поэтому эти 104 секунды нельзя сравнивать с неизвестным временем NanoBot.

Ответ с обозначением NanoBot RTX35B получил 74/100. Он собрал колонки и приоритет гораздо ближе к заданию. Его главный блокер почти обидный: в списке параметров процедуры оказалось Возврат Result. После исправления формы возврата работа всё равно не закончилась бы: поиск Result.Найти() повторяется для строк второй таблицы без индекса, нет проверки колонки Ключ, дубли обрабатываются непоследовательно. При больших объёмах такой поиск может перейти к O(n×m).

Разница +57 реальна для этих двух сохранённых артефактов. Но из неё нельзя заключить, что NanoBot всегда «добавляет 57 баллов» RTX модели. Нам неизвестны точные веса, сжатие и полная трасса второго запуска. Заявление в комментарии NanoBot о БСП и LEM не является доказательством вызова этих инструментов.

Flash: почти ничья при другом наборе ошибок

У Qwen3.8 Flash в OpenCode получилось 68. Идея хорошая: связать ключи через Соответствие и избегать полного перебора. Но в листинге были неправильный цикл, лишние аргументы Колонки.Добавить() и вымышленные свойства колонок.

В NanoBot модель выдала более завершённую конструкцию с небольшими вспомогательными функциями, СкопироватьКолонки() и индексным НайтиСтроки(). Балл вырос всего до 69: разные написания ИменаКолонокДополнения и ИменаКолонкиДополнения ломают выполнение, НСтр используется как шаблонизатор, а для ключа только из дополнительной таблицы снова копируются запрещённые общие колонки. BSL Language Server разобрал все 185 строк и показал лишь одно предупреждение о неиспользованной переменной. Это полезный пример границы анализатора: синтаксис может выглядеть спокойным, пока динамические имена и смысловой контракт уже нарушены.

Qwen3.8 27B: лучший исходный ответ не сохранил лидерство

Победитель OpenCode с 78/100 построил хороший контракт, проверки и схему результата; его исходный листинг целиком приведён во второй статье. Этот ответ агент завершил после просьбы «доделай». У NanoBot осталось два ответа с тем же обозначением семейства.

Один набрал 26: модель правильно наметила СкопироватьКолонки() и Соответствие, но написала несуществующий ЕстьТип, неверно проверяла результат Колонки.Найти() и вызвала несуществующий Соответствие.Содержит(). Широкий Попытка/Исключение скрывал ошибку индекса и переводил поиск обратно к повторным линейным проходам.

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

Gemma 4: оболочка не дописала решение за модель

В OpenCode Gemma 4 26B получила 12: часть колонок терялась, а пустое значение приоритетной таблицы могло быть заменено вторичным. Ответ NanoBot с обозначением Gemma 4 оценён в 3. Он предложил запрос, который возвращал лишь несколько полей, а потом обращался к произвольным колонкам, которых в выборке нет. Основной алгоритм так и не был закончен. Удаление Markdown-разметки устранило часть замечаний анализатора, но не создало недостающую реализацию. Точная идентичность вариантов Gemma между клиентами не подтверждена, поэтому здесь сравниваются только сохранённые ответы семейства.

Почему проверка BSL не равна готовности к работе

В начальной группе из семи листингов BSL Language Server вернул 114 диагностик. Это полезный сигнал, но сравнивать модели простым числом ошибок нельзя. NanoBot RTX35B получил 14 замечаний и всё равно имел синтаксический блокер. Flash под NanoBot получил всего одно предупреждение, хотя имена переменных и перенос значений по ключу остались неверными. Фрагмент Qwen3.8 27B на 54 балла после удаления Markdown-разметки почти успокоил анализатор, но трёх вспомогательных функций в ответе вообще не было.

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

Что можно сказать о двух клиентах

Ответы в двух клиентах заметно различались. Для RTX вариант NanoBot оказался существенно лучше. Для Flash итог почти совпал, хотя внутреннее устройство кода стало другим. Для Qwen3.8 27B оба ответа NanoBot уступили исходному OpenCode; для Gemma 4 незавершённый ответ оказался ещё слабее. Ни один итоговый листинг в этом наборе не прошёл все проверки, необходимые перед использованием.

Эти ответы не позволяют назвать причиной разницы баллов одну только программу. У нас нет одинаковых повторов, полной истории NanoBot и подтверждения точных весов моделей. Поэтому мы не ранжируем скорость клиентов и не превращаем разницу баллов в универсальный коэффициент. Для такого вывода понадобился бы новый прогон на одинаковых условиях.

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

Откуда взяты результаты

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