AI-агенты для 1С: от генерации кода до автоматизации разработки и тестирования

Тема статьи – агенты с искусственным интеллектом для 1С-разработчиков. Я расскажу, что такое ИИ-агенты, как они работают и какие инструменты можно использовать в собственных проектах.

ИИ-агент (AI-агент) – это интеллектуальная система или автономная программа, способная выполнять задачи и достигать многошаговых целей без прямого вмешательства человека.

Что характеризует ИИ-агента:

• Главная характеристика агента – автономность. Он работает сам, мы в него не вмешиваемся и помогаем по минимуму.

• Он умеет использовать внешние инструменты: базы данных, API, документацию и другие источники. Это не изолированная система – у него есть «глаза» и «руки», с помощью которых он взаимодействует с внешним миром.

• В идеале агент с искусственным интеллектом работает в коллаборации, в составе группы разработки, состоящей из нескольких ИИ-агентов, хотя это не обязательно.

• Обучаемость и рефлексия. Он также умеет самообучаться – понимать, насколько его действия успешны, где допущены ошибки и что нужно исправить.

Цикл работы ИИ-агента и аналогия с CI/CD

Давайте посмотрим, из чего состоит основной цикл работы агента.

Кому-то данная схема покажется знакомой, потому что она похожа на символ бесконечности в CI/CD, где идут сборка, тестирование, деплой и релиз.

ИИ-агенты работают похожим образом: итеративно проходят ряд операций и постепенно приближаются к цели. Основной цикл их работы состоит из блоков:

• планирование – определение следующих действий и задач,

• выполнение действий – реализация этих действий,

• наблюдение – оценка результатов своей работы,

• обучение – понимание, насколько выполненные шаги помогли достичь цели.

Если в CI/CD мы уже умеем строить пайплайны, в том числе в 1С, с тестами и расширенной логикой, то как построить подобный пайплайн для ИИ-агента – вопрос пока неочевидный для 1С-ников, да и для программистов на других языках тоже.

Попробуем разобраться, из каких элементов можно собрать такую систему.

Протокол MCP: глаза, уши и руки агента

Первое – протокол MCP (Model Context Protocol). Это Type-C для нейросетей, через который к ИИ-агенту можно подключить внешний механизм – это те самые «глаза, уши и руки», с помощью которых агент взаимодействует с внешней средой.

MCP состоит из трех частей: инструкций, ресурсов и утилит. Инструкции и ресурсы используются редко.

• Инструкции – это промты, описание того, как должна работать нейросеть. Например, в каком формате выдавать данные: JSON, текст или число.

• Ресурсы – контекстная информация, с которой работает агент. Пример – файловая система: у каждого файла есть уникальный путь, его можно прочитать, получить список ресурсов или конкретный файл.

• Через утилиты (tools) происходит взаимодействие с внешним миром: агент не только получает контекст, но и отправляет данные, формирует результаты и выполняет действия во внешних системах.

Архитектура взаимодействия: MCP-сервер и клиент

Отдельно стоит упомянуть, что именно взаимодействует с MCP. MCP – это протокол, в котором есть сервер и клиент. Клиентом чаще всего выступает ИИ-агент, он же является средой разработки. Большая языковая модель (LLM) может находиться локально или в облаке. MCP-сервер вызывает та сторона, где расположен ИИ-агент.

Если вы запускаете Cursor на своей машине, именно ваш локальный Cursor обращается к MCP-серверу – не облачная нейросеть и не локальный LM Studio.

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

Протокол A2A: коллаборация между агентами

Второй элемент, на котором строится пайплайн для ИИ-агентов – протокол A2A (Agent-to-Agent protocol). Это протокол взаимодействия между несколькими агентами (коллаборация).

Протокол А2А нужен, чтобы обойти технологические ограничения нейросетей. У каждой модели есть контекстное окно, в которое помещается не все. Если подключить более 40 MCP-серверов к одному ИИ-агенту, произойдет переполнение контекста, и система начнет выдавать ошибки из-за слишком большого числа утилит.

Поэтому одного большого ИИ-агента можно разбить на несколько небольших, которые будут взаимодействовать между собой через протокол A2A. Это стандартизированный способ обмена данными между агентами. Пока он используется редко, но в будущем, вероятно, станет активно применяться.

Существующие реализации ИИ-агентов: Cursor и CLI-инструменты

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

Первый – это среды разработки и плагины к ним. Самый популярный пример – Cursor. У таких решений средний уровень автономности: можно подсказать агенту, посмотреть его текущее состояние и понять, какие утилиты он вызывает. На текущем уровне развития нейросетей и ИИ-агентов – это наиболее удобный вариант, потому что видно, что делает модель.

Второй класс – CLI-инструменты (командная строка строка). У них высокий уровень автономности: они работают в режиме агента длительное время. В их работу нельзя вмешиваться: им ставится задача, и остается только ждать результата.

Является ли «1С-Напарник» ИИ-агентом в классическом понимании? Верный ответ– нет. У него минимальная автономность: мы задаем вопрос, получаем ответ, на этом взаимодействие заканчивается, цикла нет. Он не умеет использовать инструменты MCP или A2A, а его обучаемость находится на минимальном уровне. Возможно, со временем он догонит и перегонит другие решения, но пока это не так.

Подключение MCP-сервера к Cursor

mcp.json

{
  "mcpServers": {
    "Playwright": {
      "command": "npx",
      "env": {},
      "args": [
        "-y",
        "@playwright/mcp@latest",
        "--extension"
      ]
    }
  }
}

Чтобы подключить MCP-сервер, используется файл mcp.json – глобальный или находящийся в вашем проекте. В него записывается название MCP-сервера и команда для его запуска. После этого взаимодействие между MCP-сервером и ИИ-агентом происходит через HTTP, SSE-протокол или стандартный ввод-вывод.

В большинстве случаев разработчикам достаточно стандартного ввода-вывода – не требуется никаких дополнительных настроек, кроме одной команды запуска.

После редактирования файла в интерфейсе появляется возможность включать и выключать MCP-сервер, просматривать список его утилит, промптов, инструкций и ресурсов.

Готовые MCP-серверы: командная строка и веб-поиск

Теперь рассмотрим, какие существующие MCP-серверы, изначально разработанные не для 1С, можно использовать.

Самый простой вариант – командная строка. Этот MCP-сервер встроен во все ИИ-агенты, предназначенные для разработки, и может выполнять любые консольные команды. Несмотря на простоту, через него можно собрать проект, проверить синтаксис или запустить деплой. В нашем CI/CD уже есть готовые скрипты.

Мы можем, например, создать файл build.cmd с командой сборки внешней обработки через vanessa-runner. Если попросить ИИ-агента выполнить сборку проекта, он просканирует каталог с файлами, найдет build.cmd, поймет, что это сборка, и запустит его.

Если у вас есть специфические задачи и по названию скриптов LLM не понимает, что это за файлы, напишите в README обычным языком: «Для выполнения такой-то задачи запусти такой-то файл». Этого достаточно – агент поймет и выполнит действие, когда понадобится.

Также существует встроенный (или доступный как отдельный MCP-сервер) веб-поиск. Он используется для поиска документации в интернете. Ограничение в том, что работает он только с открытыми источниками: закрытые ресурсы, такие как ИТС, обрабатываются плохо – по ним ищется и читается информация с ошибками. Зато можно искать и анализировать ошибки: если при выполнении compile.epf появилась ошибка, ИИ-агент может найти ее описание в сети, определить причину и предложить исправление.

Локальная база знаний как решение для закрытых источников

Закрытость ИТС можно обойти с помощью локальной базы знаний. Можно подготовить собственную базу и загрузить в нее нужную информацию. Полученные данные можно передать нейросети через базу знаний.

Такие базы работают по принципу векторных баз, которые обеспечивают смысловой поиск информации – не полнотекстовый, а именно по смыслу.

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

Docs MCP-сервер и генерация случайного числа

Docs MCP-сервер – очень простой инструмент. Он устанавливается и запускается одной командой, после чего открывается веб-интерфейс, в который можно загрузить любую информацию. Это может быть сайт – тогда он парсится и индексируется, или каталог на жестком диске.

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

Пример того, как это работает:

Многие нейросети ошибаются даже при простой задаче – сгенерировать случайное число на языке 1С. У них возникают «галлюцинации»: они придумывают несуществующий метод глобального контекста СлучайноеЧисло(). Если просто попросить нейросеть написать код, как в примере: «Напиши код, который выводит случайное число от 1 до 10», она создаст такой метод.

Далее, так как это ИИ-агенты, они проверят синтаксис через плагин – например, для VS Code или Cursor (в данном случае использовался Language 1C (BSL)). Линтер не обнаружит ошибки, потому что подобный вызов может существовать в каком-то общем модуле или другом контексте. В итоге нейросеть считает, что все корректно, и сообщает, что задача выполнена.

Если подключить базу знаний с данными из синтаксис-помощника, ситуация меняется. На картинке видно, что агент вызвал утилиту search_docs – поиск по документации. Нейросеть нашла информацию о существовании объекта ГенераторСлучайныхЧисел и метода СлучайноеЧисло(), после чего написала правильный код с первого раза.

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

Браузер как MCP-сервер: автоматизация тестирования и взаимодействие с интерфейсом

Более интересный кейс – возможность подключить браузер Chrome как MCP-сервер к ИИ-агенту.

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

В этом случае агент через командную строку соберет проект, задеплоит его, откроет браузер, введет логин и пароль, выполнит вход и проверит интерфейс. Если не привязываться к 1С, это может быть и интеграция с веб-сайтами – например, создание новой учетной записи для тестирования. ИИ-агент сам откроет браузер, перейдет по нужному адресу, заполнит форму и создаст запись. Капча ему не помеха – он справляется и с этим.

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

Эти проблемы решаемы: поведение можно скорректировать при помощи промта.

Тестирование HTTP-сервисов и работа с OData

Нейросеть может не только написать HTTP-сервис, но и протестировать его.

Уже существуют готовые решения:

• Для классического подхода https://github.com/dkmaker/mcp-rest-api

• Для работы с OpenAPI https://www.npmjs.com/package/@mcp-apps/api-tools-mcp-server 

Эти MCP-серверы можно подключить к ИИ-агенту, и после написания кода HTTP-сервиса нейросеть сможет проверить его, вызвав нужный endpoint – новый, измененный или существующий – и проанализировав результат.

Анализ результатов нейросеть выполняет автоматически. Можно задать ожидаемый ответ, но чаще она сама определяет, соответствует ли поведение сервиса ожиданиям.

Также есть протокол OData, который многие не любят. Однако это стандарт, и с ним можно работать, в том числе за пределами экосистемы 1С. Через него можно готовить тестовые данные или проверять результаты после тестов.

Не все MCP-серверы, поддерживающие OData, подходят для 1С, но тот, что здесь показан , справляется со своей задачей.

Есть одна особенность: в этом решении на каждый элемент метаданных создается отдельная утилита – не просто на элемент, а на элемент плюс действие. Например, одна утилита отвечает за получение количества элементов номенклатуры, другая – за поиск, третья – за получение конкретного элемента.

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

Кроме того, есть инструмент RAD, который предоставляет Swagger-интерфейс для управления данными внутри 1С. Его также можно подключить – и, возможно, он будет работать даже эффективнее.

Создание собственного MCP-сервера на OneScript

Все эти инструменты уже существуют и работают, но у них есть ограничение – они написаны на JavaScript или Python. Разбираться и дорабатывать их неудобно, поэтому предлагаю написать собственный MCP-сервер. Для этого подготовлена библиотека autumn-mcp.

Это удобно и быстро. MCP-сервер создается буквально в три шага:

1. Установить OneScript.

2. Установить autumn-mcp через OPM (opm install autumn-mcp).

3. Подготовить файл main.os, который будет запускать проект:

#Использовать autumn
#Использовать autumn-mcp
#Использовать "."

Поделка = Новый Поделка();
Поделка.ЗапуститьПриложение();

Теперь под каждую утилиту можно создать отдельный модуль, отдельный файл с расширением *os, где при помощи аннотаций мы указываем, что это за инструмент, какие у него параметры и какая функция будет выполняться при его вызове.

Приведу простой пример. Инструмент будет получать список установленных на нашем компьютере версий платформы 1С.

Реализуем инструменты. Файл versions.os:

#Использовать v8find

&Инструмент(Имя = "v8list", Описание = "Версии платформы 1С")

Процедура ПриСозданииОбъекта()
	
КонецПроцедуры

&ВыполнениеИнструмента
Функция MCP_V8List() Экспорт
	
	Возврат Платформа1С.ПолучитьТаблицуУстановленныхВерсий();
	
КонецФункции

Первая аннотация – аннотация «Инструмент». Кто знаком с другими языками программирования, представляет, что такое аннотации. По факту это описание процедуры или переменной.

У инструмента есть два аргумента:

• Имя – то, что будет внутри JSON, который уйдет в нейросеть. Это просто уникальное имя.

• Описание – это описание инструмента, которое нейронка прочитает и поймет. Если это описание подойдет для ее задачи, нейронка вызовет этот инструмент. Оно должно быть понятным вам и нейронке. За описанием нужно следить.

Вторая аннотация – выполнения инструмента. Ее вешаем на функцию, которая будет вызываться при вызове инструмента.

Реализуем инструменты. Файл v8path.os:

#Использовать v8find

&ПараметрИнструмента(Имя = "version", Описание = "Версия", Обязательный = Истина)
Перем НомерВерсии; // Строка

&Инструмент(Имя = "v8path", Описание = "Путь к версии платформы 1С")

Процедура ПриСозданииОбъекта()
	
КонецПроцедуры

&ВыполнениеИнструмента
Функция MCP_V8Find() Экспорт
	
	Возврат Платформа1С.ПутьКПредприятию(НомерВерсии);
	
КонецФункции

Немного усложним и добавим параметры: любая утилита может обладать параметрами. На переменные внутри модуля вешаем аннотацию параметра инструмента. В коде выше только основные аргументы: имя – то, как эту переменную увидит LLM-ка; описание – то, как поймет LLM-ка, что делает данный аргумент. Описание пишем тщательно, подбирая слова, чтобы нейросеть поняла.

Кроме этого, есть признак обязательный или необязательный и типизация: можно задать тип параметра (строка и любой примитивный тип) и обернуть его в массив. Все, в библиотеке больше ничего нет, но этого достаточно для очень интересных задач.

Демонстрация работы собственного MCP-сервера

Давайте посмотрим, что получилось.

Подключаем к ИИ-агенту через mcp.json:

{
  "mcpServers": {
    "autumn-mcp": {
      "command": "oscript",
      "args": [
        "main.os"
      ]
    }
  }
}

Мы подключаем наш MCP-сервер, состоящий из двух утилит, к Cursor. В файле mcp.json прописываем oscript и путь к файлу main.os. После этого Cursor сразу видит MCP-сервер, позволяет включать и выключать его в графическом интерфейсе и просматривать список инструментов.

Результат на экране: мы задаем нейросети задачу – найти путь к максимальной из установленных версий 1С на компьютере. ИИ-агент сначала вызывает утилиту для получения всех версий, анализирует результат, затем делает второй вызов, передает туда максимальную версию и получает путь.

Этот пример показывает, как работает связка MCP-сервера и ИИ-агента.

Расширение возможностей: автоматизированное тестирование через MCP

Я сделал более сложный инструмент, чтобы попытаться обойти ограничения браузера. Браузер не очень удобен для автоматизации тестирования, в нем сложно выполнять некоторые действия. Зато у нас есть механизм автоматизированного тестирования, который хорошо сочетается с концепцией MCP-серверов.

Есть инструменты вроде Vanessa-ADD и Vanessa-Automation, где шаги уже описаны понятным для человека языком. Эти шаги понятны и нейросети. В теории можно создать две утилиты: первая получает список шагов, вторая выполняет шаг. Этого достаточно для автоматизированного сценарного тестирования, создания видеоинструкций, сбора и анализа данных. Более того, можно заставить ИИ-агента работать как оператор 1С. Например, человек в чат-боте пишет: «Создай документ», – и агент открывает 1С и выполняет действие за пользователя.

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

Состав инструментов MCP-сервера автоматизированного тестирования выглядит так:

• Список доступных шагов,

• Запуск шагов на клиенте,

• Получение списка окон,

• Получение дерева элементов формы,

• Получение командного интерфейса клиента,

• Получение табличных документов,

• Работа с переменными контекста Vanessa,

• Деплой и запуск внешней обработки.

Была поставлена задача написать обработку, которая получает курс юаня за последние пять дней. Нейросеть успешно справилась с первой попытки: написала корректный код, использовала API Центробанка и выполнила все правильно. Самое интересное – она проверила, что обработка работает.

ИИ-агент задеплоил проект, запустил 1С, и после единственного клика мышью с моей стороны (изменение размера окна) ИИ-агент сам нажал кнопку «Обновить» и проверил результат. Все сработало корректно.

Есть ограничения – проблемы с полями ввода ссылочного типа и со сложными динамическими формами. Но в целом прототип выглядит перспективно.

Что уже можно делать и чего пока ждать

Прямо сейчас можно начинать собирать собственные ИИ-пайплайны. Уже доступны:

• Сборка и деплой,

• Проверка синтаксиса,

• Использование документации через RAG,

• Использование REST/OData,

• BDD-тестирование,

• Браузерные сценарии для несложных UI.

Но лучше немного подождать, если у вас:

• Сложные сценарии с динамическими формами,

• A2A-оркестрация без участия человека,

• Автогенерация длинных модулей с нуля.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.