Переход от чатов к агентам и инфраструктура (MCP)
Я аналитик 1С. Опыт работы у меня около двух лет, но я горю искусственным интеллектом и создал первый автоматический бенчмарк нейросетей в разработке на 1С. А именно – бенчмарк агентских подходов.
Почему я решил так сделать? Потому что сейчас индустрия очень активно меняется, и мы уже, по идее, должны переходить от общения с большими языковыми моделями в формате чата к работе с агентами, которые могут самостоятельно планировать, вносить изменения и что-то делать. Они по-настоящему ускоряют работу. По крайней мере, я начал выполнять в несколько раз больше дел, но при этом почему-то начал меньше спать.
Выбор этих подходов в большинстве случаев сейчас субъективный и интуитивный. То есть кто-то пошел, попробовал, заработало – ну и продолжает пользоваться.
Давайте посмотрим, чем отличается работа с обычным чатом в разработке от работы с чатами и LLM. Посмотрим, что такое CLI-агенты и как с ними работать. Потом спроектируем эксперимент: как мы должны оценивать агентов и нейросети, в каких задачах будем их оценивать, чтобы понять, насколько они реально эффективны именно в наших задачах. И какие ошибки они допускают и как эти ошибки исправлять.
Мой бенчмарк изначально был бенчмарком «голых» моделей. Мы просто отправляли сообщение с задачей в чат, получали ответ, как-то парсили код из этого ответа, вставляли его в конфигурацию, и он как-то работал. То есть мы, по сути, делали это вручную – как сейчас, возможно, многие пытаются внедрять искусственный интеллект в свою работу.
И на самом деле такой подход иногда даже немного замедляет. Как часто любят говорить: «Вот ваш искусственный интеллект ничего не ускоряет, он только меня замедляет».
Но агенты работают кардинально по-другому. Они могут действовать внутри определенного пространства, среды, внутри папок и делать те же действия, что и мы. Мы нажимаем кнопки, копируем файлы, пишем файлы, читаем файлы, что-то с ними делаем, выполняем запросы к другим сервисам. Агенты буквально занимаются тем же самым.
Подробнее расскажу про CLI-агентов. Это не такие привычные агенты, как Cursor или Antigravity. Это IDE, а внутри них как раз работают CLI-агенты. Такие агенты вызываются буквально одной командой в терминале. Например: «Codex, напиши мне программу». Мы пишем это прямо в терминале, как будто делаем echo и выводим какое-то сообщение.
То же самое происходит и в Cursor: по сути, не сам Cursor все это делает, а CLI-агент внутри него.
Тут важно еще ввести терминологию MCP-сервера. Я думаю, многие с этим знакомы, но все равно возникает путаница.
Поговорим именно про MCP-сервер. По сути, это отдельный инфраструктурный объект, который мы ставим рядом с нашим агентом либо где-то у себя на сервере – там, где он доступен агенту.
Агент видит, что у него есть какой-то MCP-сервер. MCP-сервер отдает ему набор инструментов, которые выполняет за агента. Агент, обращаясь к MCP-серверу, видит, что у него есть, например, инструмент «внести задачу в систему задач». Он видит, что нужно подать на вход и что получит на выходе, а в ответ получает новую информацию: задача создана.
То есть, когда раньше мы в чате обращались к большой языковой модели, к нейросети, и говорили: «Сделай мне задачу в системе», она могла придумать: «Да, я сделала». А здесь она вызывает наш MCP-сервер, и MCP-сервер делает это за нее.
Зачем сделали такой подход, если можно было просто встроить в агента какой-то инструмент, захардкодить его и вызывать оттуда? На самом деле, это сделано для безопасности, чтобы унифицировать подход и сделать так, чтобы агент ничего не придумал и не сделал что-то плохое сам. Потому что, как мы помним, агент может вызывать команды в терминале и реально что-то сломать. Например, мне говорили, что он удалил десятилетний архив фотографий. Для меня это, конечно, очень страшно.
Дизайн эксперимента: задачи, метрики и тестируемые решения
Давайте поговорим про задачи и про наш эксперимент. Я выделил три основные задачи.
Первая – это написание кода. Вторая – доработка кода: то, чем занимаются программисты 1С и чем мы, в принципе, занимаемся почти каждый день. И здесь я добавил еще одну важную вещь: если агент пытается быть автономным, он должен уметь писать тесты на тот код, который он генерирует.
В идеале это должен быть полноценный план: агент написал код, другой агент сгенерировал на этот код Unit-тесты. Либо наоборот: сначала сгенерировались Unit-тесты на задачу, потом по этим Unit-тестам прогнался сгенерированный код.
Дополнительно я сделал небольшую функцию, чтобы по итогам генерации кода и тестирования генерировалась документация: описание изменений, что произошло у нас в коде, что изменилось, и какое-то пояснение, если были сделаны сложные алгоритмы.
Первый этап – разработку и доработку кода 1С – я разбил на четыре категории:
-
Простые функции, алгоритмические задачи.
-
Написание запросов к метаданным – например, выбрать что-то из справочника или сделать более сложные запросы.
-
Работа с метаданными – создание или изменение метаданных внутри наших конфигураций.
-
Исправление ошибок. То есть мы говорим, что у нас в каком-то модуле есть ошибка, что-то работает не так, и модель идет и сама это все исправляет.
Что именно мы сравниваем? Как я уже говорил, есть агенты, но агенты не могут работать без моделей, которые отвечают, когда мы обращаемся к ChatGPT в формате чата, агент использует ту же модель, только покрывает ее циклом обратной связи. Он говорит: «Нужно сделать это», модель пытается это сделать. Если получается, ответ возвращается обратно, и она продолжает свои действия до тех пор, пока, по ее мнению, задача не будет выполнена.
Мы будем тестировать несколько режимов: без контекста, с ошибками тестов, то есть с обратной связью, и с инструментами. В рамках агентов будут тестироваться открытые решения:
-
модели (GPT/Claude/YaGPT/опенсорс и т.д.).
-
агенты (Kilo/Cline/Claude Code/ваши CLI-обвязки).
-
режимы: без контекста/с XML/с ошибками тестов/с инструментами.
Их можно скачать уже сегодня, они доступны. Правда, там нужна настройка провайдеров, чтобы подключить и использовать большие языковые модели.
Пример задачи, которую мы будем задавать нашим агентам: реализовать функцию регламентного задания по отправке выбранных отчетов на почту пользователя. Условно, описание задачи в виде промпта отправляется агенту, который находится в рамках выгруженной в XML файловой конфигурации, и агент начинает выполнять свои действия.
После того как он выполнил задачу, прогоняются эталонные Unit-тесты, которые написаны по этой задаче. Если все выполняется, мы идем дальше.
Так и будет работать полноценный эксперимент. Мы сначала проектируем задачи, которые будем давать агентам, выбираем, какого агента и с какой моделью будем запускать. Далее этот агент в рамках выгруженной конфигурации выполняет свои задачи, прогоняются Unit-тесты, сохраняются логи, парсятся попытки, фиксируется, что в итоге произошло с Unit-тестами, и собирается статистика.
В итоге мы будем смотреть по этой статистике, прошли тесты или нет. Это, по сути, главная метрика. Она называется Pass@k: за сколько попыток была выполнена задача. Если задача хотя бы один раз была выполнена, например, за две попытки, то Pass@2 будет равняться единице. То есть в 100% случаев задача выполнилась за две попытки. Если Pass@1 равен единице, значит, все выполнено с первой попытки.
Вторая метрика – это анализ логических ошибок: что произошло, из-за чего что-то не сработало. Мы подробно разбираем, что это за ошибка, почему она возникает и как ее исправить.
Также смотрим время: сколько агент затрачивает на выполнение той или иной задачи.
И еще есть более субъективная оценка применимости: насколько код написан в стиле регламентов разработки, насколько он соответствует нашим архитектурным ограничениям. Но это именно субъективная оценка, которая в рамках первичного эксперимента пока не проводилась. Ее можно проводить для себя, анализируя, что именно агент вносил и какие изменения делал.
Масштаб исследования и сравнение результатов моделей
Эксперимент был проведен по той схеме, которую мы сейчас спроектировали. Масштаб эксперимента уже достаточно большой: потрачено более 100 долларов на токены, буквально за несколько дней тестов было сожжено 170 миллионов токенов.
Были полноценно протестированы четыре open-source-агента, которые можно скачать и, например, запускать в закрытом контуре у себя, используя свои большие языковые модели. Было 10 задач из четырех категорий. Было протестировано около десяти разных LLM: самые мощные и самые популярные на данный момент модели, а также самые мощные открытые модели для установки у себя в контуре.
Когда я запускал этот эксперимент, я рассчитывал примерно так: у нас есть Claude, у нас есть Gemini, у нас есть GPT, и они, по идее, должны вообще затмевать все остальные открытые модели. Единственное, что не получилось запустить, – это ChatGPT, потому что он ругается, что мы находимся в нашей родной стране.
Но результаты получились вот такими. Из 10 задач 9 правильно решил Claude Opus 4.6 с первой попытки. Gemini 3.0 Flash Preview тоже решила девять задач. То есть мы буквально запустили агента без инструментов, без навыков, просто пустили Open Code в рамках выгруженной в XML конфигурации 1С и получили такие результаты.
Но самое удивительное, чего я вообще не ожидал, – это то, что китайская модель MiniMax M2.5, самая популярная модель на OpenRouter сейчас, решила восемь задач. То есть она выступила на уровне моделей, которые сейчас платные, стоят денег и недоступны у нас без обходных решений. GLM также решила задачи максимально хорошо. Kimi K2.5 тоже показала очень хороший результат.
И здесь как раз видно четкое разделение, которое я хотел показать изначально. Мы видим, что тесты запускались с теми же моделями, но на разных open-source-агентах. Например, первые три места заняли модели, которые выполнялись в рамках агента Open Code. Это открытое решение, которое можно скачать с GitHub и запустить у себя в контуре.
Потом был Cline. Это агент, который можно установить как расширение в VS Code и разрабатывать с его помощью. Аналог Codex, который также можно установить в VS Code как расширение и использовать параллельно с основной разработкой.
А Roo Code – это форк Cline, который тоже можно запускать как расширение. Он также открыт, и его можно использовать.
Мы видим, что, например, в рамках Open Code и Cline Claude Opus 4.6 – самая мощная модель на данный момент, которая почти во всех бенчмарках занимает первые места, – показывает разницу в исполнении в две задачи.
То есть мы видим, что у разных агентов внутри находятся разные инструменты. Они по-разному настроены, у них разные системные промпты. И из-за этих различий может возникать разница в две задачи.
Если мы перенесем это на масштаб разработки в рамках большой конфигурации и большой команды, можно представить, какие это могут быть издержки, если инструмент заранее подобран не тот, не самый эффективный.
По времени, затраченному на задачу, выполнение в среднем было в районе восьми минут. Но в эти восемь минут входило и разворачивание базы 1С. Она не самая большая: это самописная небольшая конфигурация для pet-проекта, для быстрой проверки гипотезы о том, что агенты будут выдавать разные результаты.
Естественно, если мы будем выбирать большие конфигурации, все будет занимать больше времени, и мы будем получать уже другие цифры.
Самое интересное: я также проверял Gemini 3.1 Pro Preview. Это тоже одна из самых мощных моделей на данный момент. Но в тех же условиях, абсолютно в одинаковых условиях вместе с Gemini Flash 3 предыдущего обновления, она решила всего три задачи.
И это показывает, что разница между Gemini 3.1 Pro и Gemini 3 Flash – в рассуждениях. Gemini 3 Flash не рассуждает: она видит текст и сразу начинает писать код или что-то изменять. А Gemini 3.1 Pro начинает думать, продумывать, передумывать и иногда путается. И в рамках 1С это стало критично.
Анализ типичных ошибок и особенности работы с 1С
Дальше я залез посмотреть, в чем ошиблась лучшая нейросеть. На данный момент это Claude Opus 4.6. Там была такая задача.
В одной задаче он все-таки ошибся. Был специально сделанный отдельный общий модуль. В задаче было написано: «В этом модуле добавь экспортную функцию “СводкаПоСтеллажу”». Конфигурация была для ПВЗ: нужно было отслеживать, в каких стеллажах какие ячейки заняты, какие свободны.
Нужно было добавить запрос, который возвращал бы таблицу значений с информацией, представленной в задаче: количество занятых ячеек, количество свободных ячеек, количество небольших заказов, которые лежат в ячейках, и общее количество ячеек.
Claude Opus придумал интересную формулировку в запросе: «КоличествоЯчеек.КоличествоЯчеек». Он сделал подзапрос, назвал таблицу в подзапросе «КоличествоЯчеек», и так же была названа основная таблица в основном запросе. В итоге возникло несоответствие, и все, естественно, упало.
Эффективность решения – это тоже отдельная проверка, и, наверное, она будет следующим этапом развития бенчмарка. Естественно, запросы могут быть эффективными и неэффективными, но в рамках такой быстрой доработки это все равно может помочь.
Дальше были ошибки у Gemini Flash, которая тоже набрала девять баллов и решила девять задач. Задача была немного другой: модель ошиблась в работе с метаданными конфигурации. Нужно было создать новый документ с точным именем «ПеремещениеЗаказа», и были указаны реквизиты, которые нужны: ссылочные типы, строка с определенной длиной и так далее.
Unit-тесты проверяли соответствие этих реквизитов, соответствие названия. То есть по метаданным искался такой документ, искались такие реквизиты и проверялись их типы.
Сначала, когда я смотрел git diff, который написала нейросеть, все выглядело нормально. Сначала она добавила документ в общую конфигурационную XML-структуру.
Далее написала информацию о реквизитах.
Но когда я начал погружаться глубже, там появились вот такие uuid. Было семь реквизитов, и у всех сначала были значения 111, потом 222, потом 333. Честно, я не погружался прямо до конца, не открывал заново конфигурацию и не запускал ее с этими значениями, но мне что-то подсказывает, что именно в этом и была ошибка.
Далее я тестировал режим написания Unit-тестов по написанному коду. Так как у меня к задачам уже были написаны эталонные Unit-тесты, совпадение было около 57%. Из тех тестов, которые не совпали, в большинстве случаев это были ошибки в синтаксисе. То есть тесты просто не запускались в рамках той же базы и того же задания. Также были и другие ошибки.
Отдельный этап – документация, когда мы пишем изменения: что именно нейросеть внесла в рамках задачи. Генерируется Markdown-файл с описанием того, что было изменено. И сохраняется тот же git diff, то есть патч: что мы вносим, что удаляем.
Здесь это было сделано просто базовым промптом: «Опиши, что ты сделал». Естественно, можно докрутить этот промпт, написать какой-то навык агента, чтобы документация соответствовала вашему корпоративному стилю – так, как вы пишете, или так, как вам удобнее. Можно просто посмотреть, что написала нейросеть.
Это тоже может помочь. Условно, если мы отдаем это на код-ревью, мы добавляем к коду еще и описание того, что было изменено. Это моя гипотеза: возможно, так можно как-то улучшить качество оценки. Либо человек, который будет ревьюировать код, просто посмотрит рядом, что на самом деле было изменено.
Если анализировать ошибки дальше, то много ошибок было в директивах. Модели путались: писали запросы на клиенте либо писали функции без директивы, и потом это тоже плохо работало. Я тестировал добавление в промпт отдельного условия: использовать директивы «НаСервере», «НаКлиенте». Это помогало.
Как я уже показывал на примере с метаданными, с формами пока сложно работать без инструментов, которые будут делать часть работы за нейросеть так, чтобы 1С это приняла. Модель не может сама сгенерировать правильный uuid. Нам нужно проверить уникальность этого uuid, чтобы он не повторялся нигде в конфигурации, иначе все упадет.
Также модели путаются в синтаксисе. Например, я еще в рамках предыдущего этапа бенчмарка тестировал самые новые модели GPT: GPT-4, GPT Codex 5.3. У них почему-то есть представление, что в 1С существует формулировка «Шаг -1». Естественно, такого нет, и из-за этого все ломается. В итоге получается не то, что мы хотели.
Еще был пример: в рамках запуска GLM 5 модель начала искать данные в конфигурации. На вход в контексте ей сначала подавалось 90 тысяч токенов, потом 98 тысяч токенов, и так это постепенно возрастало. И это дорого.
Используя инструменты и навыки, можно сократить потребление токенов в разы, а в рамках такого случая – даже в десятки раз. Сейчас уже есть популярные MCP-серверы, которые показывают метаданные и сразу вытаскивают их. Тогда нейросети и агенту не приходится самим искать метаданные по всей конфигурации.
Выводы
На этом эксперимент был закончен. Основные выводы такие: агенту очень важно правильно выстроить цикл обратной связи, чтобы он сам мог тестировать свои изменения и сам понимать, правильно он написал код или нет.
Тогда использование агентов не будет замедлять работу. Вы сможете отдать задачу: «Сделай это». Агент сам будет прогонять свои тесты, проверять результат, исправлять ошибки. Вы в это время будете думать над другой задачей, а через 30 минут к вам придет уже готовая протестированная задача.
Естественно, без контекста конфигурации агент просто не поймет, что нужно делать. Поэтому нужно использовать инструменты для работы с метаданными и формами. Они уже есть.
Я понимаю, что задачи, на которых я тестировал агентов, я придумал сам. Они показались мне нормальными для первого варианта, но они не отражают всю объективность разработки на 1С.
И здесь у меня появилась идея. Условно, доверие к моему опыту в рамках разработки не очень большое. Но мы все доверяем друг другу и опытным разработчикам: тем, кто выступает на конференциях, приезжает целыми компаниями, у кого есть свои штаты разработки и колоссальный опыт.
Что, если мы соберем набор задач – публичный или не совсем публичный, – который будет выстроен в рамках контекста выгруженных в XML конфигураций? Соберем много таких задач от разных компаний, чтобы мы все им доверяли. И на основе этого сделаем один большой бенчмарк, который будет периодически прогоняться: раз в квартал или раз в полгода.
По итогам будут публиковаться открытые рейтинги решений на текущий момент. Можно будет открыть open-source-решение, скачать его и использовать уже сегодня. Естественно, модели обновляются, агенты обновляются, и все это требует обновления бенчмарка.
Судя по тому, сколько у меня затратилось на этот эксперимент, тестирование – не самое дешевое удовольствие. Но мне кажется, это важно и должно помогать людям.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
