Агентская разработка в 1С: что можно поручить ИИ, кроме написания кода

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

Но дальше всё равно придётся разбираться самому. В какой форме нужна команда? Где уже рассчитывается сумма? Можно ли использовать существующую процедуру? Что ещё вызывается при изменении табличной части?

Написать цикл в этой истории — только часть работы. Остальное связано с конкретной конфигурацией, о которой нейросеть из нашего короткого запроса ничего не узнала.

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

В этой статье покажу, как устроить такую работу через Cursor, MCP и 1C: Platform Tools. Разберём настройку окружения, способы постановки задач и учебный пример с пересчётом табличной части. Заодно обсудим, почему фраза «Код пока не изменяй» бывает полезнее, чем подробный запрос на его генерацию.

Мне нужен не только код, но и понимание, куда его добавить

Начну с разницы между обычным диалогом с нейросетью и работой с агентом.

В обычном чате я описываю задачу и прикладываю код, который считаю важным. Получаю ответ, переношю его в проект, запускаю проверку. Если что-то не работает, возвращаюсь с ошибкой. Выясняется, что для решения нужен ещё один модуль, — прикладываю и его.

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

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

При этом последовательность действий не обязательно отдавать агенту целиком. Можно остановиться после исследования, проверить план или вообще ограничиться объяснением чужого кода. Доступ к инструментам не означает, что их нужно использовать все и сразу.

Связка Cursor, MCP и Platform Tools

У каждого инструмента в этой связке своя задача.

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

В Cursor при необходимости можно переключиться в IDE и поправить код вручную. Но в описываемом сценарии все правки делает агент — я объясняю, что нужно получить, и контролирую его работу.

1C: Platform Tools — расширение с инструментами разработки 1С. Оно объединяет дерево метаданных, навигацию, работу с информационными базами, сборку, запуск и тестирование. В частности, использует команды vanessa-runner.

MCP, или Model Context Protocol, — протокол, через который агент обращается к подключённым внешним инструментам и получает результаты их работы.

1C: Platform Tools MCP — отдельное расширение с MCP-сервером. Оно предоставляет агенту доступ к командам Platform Tools: например, для работы с профилями запуска, сборки конфигурации и выполнения тестов. 

То есть Platform Tools даёт инструменты для работы с 1С, а MCP-сервер позволяет агенту ими пользоваться. Сам MCP ничего не решает за разработчика и не проверяет, правильно ли агент понял задачу.

Схема получается такой:

Рисунок 1. Как Cursor связан с инструментами разработки 1С.

Между агентом и сервером используется MCP, а между сервером и расширением Platform Tools — IPC, то есть межпроцессное взаимодействие.

Но открыть исходники в Cursor недостаточно. Агент может видеть файлы, но не иметь рабочего подключения к инструментам 1С. Эти две вещи нужно проверять отдельно.

А руками код править всё ещё можно?

Да. Работа с агентом не означает, что редактор кода больше не нужен.

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

Рисунок 2. Задача в чате и отчёт агента о настройке окружения.

Агент отчитывается о настройке дополнительного MCP-сервера, но одновременно пишет, что в текущем чате его инструменты ещё не появились.

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

Когда нужно открыть конкретный файл, посмотреть изменения или поправить код самостоятельно, можно перейти в IDE. На следующем скриншоте переход отмечен красной стрелкой.

Рисунок 3. В IDE доступны дерево проекта, редактор файлов и панель агента.

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

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

Подготовим окружение

Дальше разберём настройку для Cursor. Kiro и другие среды здесь подробно не рассматриваю: команды и порядок подключения для них нужно уточнять отдельно.

Для нашего примера понадобятся Cursor, расширения 1C: Platform Tools и 1C: Platform Tools MCP, платформа 1С:Предприятие, OneScript, OPM и vanessa-runner. Изменения будем просматривать и фиксировать через Git. 

Открываем проект

Расширения устанавливаем из Marketplace или Open VSX. В Platform Tools есть раздел «Зависимости» для настройки необходимых компонентов.

Затем открываем рабочую папку проекта. Для его распознавания расширением в корне используется файл packagedef. Если проект ещё не инициализирован, вызываем палитру команд и выполняем:

• 1C: Зависимости: Инициализировать проект

Если нужно создать структуру каталогов, для этого есть отдельная команда:

• 1C: Зависимости: Инициализировать структуру проекта

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

Подключаем MCP

После установки обоих расширений и открытия проекта нажимаем F1 и выбираем:

• 1C: Platform Tools MCP: Настроить MCP для Cursor

Расширение создаёт или обновляет .cursor/mcp.json. После этого перезагружаем окно и включаем сервер mcp-1c-platform-tools в настройках MCP.

Первый запрос агенту предлагаю сделать совсем простым:

Покажи состояние окружения 1С.

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

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

Дополнительные инструменты

Позже можно добавить другие MCP-серверы, инструменты тестирования, средства работы с Git и специализированные навыки — skills. Часть настройки тоже можно поручить агенту, если у него есть необходимые права и инструменты. Но установку неизвестных компонентов лучше контролировать отдельно. На старте мне важнее понимать, что именно уже работает. Агент читает проект? Инструменты 1С доступны? Нужная база выбрана? Проверки запускаются? После этого будет понятнее, чего действительно не хватает.

Как поставить задачу, чтобы не получить лишнюю работу

Не каждую доработку нужно начинать с большой спецификации. Но и формулировка «сделай красиво» вряд ли объяснит агенту, что я собираюсь принимать.

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

Короткий запрос: Vibe Coding

Для небольшой задачи можно начать с требования на естественном языке:

Найди форму документа «Пересчет товаров» и добавь команду, которая пересчитывает сумму по всем строкам табличной части.

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

Но даже в небольшой задаче остаются вопросы. Где должна появиться команда? Нужно ли использовать существующую процедуру? Должен ли документ сохраняться после пересчёта? Если ответы для меня важны, лучше сообщить их до реализации, а не удивляться выбору агента после неё.

Сначала план: Plan → Execute → Review

Для примера ниже я выберу вариант с промежуточным согласованием:

Изучи задачу и конфигурацию. Предложи план изменений. Код пока не изменяй.

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

Когда короткого плана недостаточно: SDD

Для более сложной задачи можно использовать SDD — разработку от спецификации.

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

Для организации такого процесса можно использовать GitHub Spec Kit. В нём предусмотрена работа со спецификацией, техническим планом, задачами и реализацией.

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

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

Попробуем на документе с табличной частью

Возьмём учебный пример.

Есть документ ПересчетТоваров с табличной частью Товары. В строках находятся поля Количество, Цена и Сумма. Нужно добавить команду пересчёта:

Сумма = Количество × Цена

Это не отчёт о доработке конкретной конфигурации: ниже разберём, как поставить такую задачу агенту и что проверить на каждом этапе. 

Шаг первый. Ищем существующий расчёт

Начну с такого запроса:

Изучи документ «ПересчетТоваров». Найди табличную часть «Товары». Нужно добавить команду пересчёта, которая для каждой строки устанавливает Сумма = Количество × Цена. Сначала изучи существующую реализацию и предложи, где лучше сделать изменение. Код пока не изменяй.

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

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

Шаг второй. Разбираемся, что именно агент собирается сделать

Для нашего примера план может быть простым: добавить команду «Пересчитать» и обработчик, пройти по строкам табличной части, вычислить суммы и обновить данные формы. Затем проверить пустую и заполненную таблицу.

Но даже такой план стоит прочитать внимательно.

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

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

Выполни согласованный план.

Шаг третий. Проверяем, что изменение хотя бы собирается

После изменения исходников прошу:

Проверь синтаксис и собери конфигурацию.

Здесь агент уже обращается через MCP к инструментам Platform Tools и получает результат выполнения команд.

Если сборка завершилась ошибкой, можно продолжить:

Проанализируй ошибку сборки, исправь проблему и повтори проверку.

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

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

Шаг четвёртый. Проверяем поведение

Сборка прошла. Хорошо, но задачу я ставил не «получить успешную сборку», а «добавить пересчёт суммы».

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

Агенту тоже можно поручить ревью:

Проверь реализацию относительно исходного требования. Найди возможные проблемы и предложи необходимые исправления.

Но его проверка не заменяет мою. Если один и тот же агент неправильно понял задачу, написал под это понимание код и затем проверил его по собственному плану, внутренне всё может выглядеть согласованно. Это ещё не означает, что реализовано нужное поведение. .

Иногда лучший запрос — ничего не менять

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

Допустим, я разбираюсь в незнакомом документе. Вместо задания на изменение можно начать с вопроса:

Изучи механизм проведения этого документа и объясни, какие регистры он изменяет.

Или поставить задачу на поиск причины ошибки:

Найди причину ошибки в проведении документа. Не изменяй код, пока не определишь причину.

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

Что я не стал бы отдавать агенту без контроля

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

С правами на выполнение команд тоже стоит разобраться заранее. Поведение подтверждений MCP-вызовов зависит от настроек Cursor. И ещё я бы не смешивал три вещи:

• Агент изменил файлы. Значит, есть изменения, которые можно посмотреть.
• Проверки прошли. Значит, нужно понять, какие именно проверки были выполнены.
• Задача решена. Это уже вывод о соответствии результата требованиям.

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

Отдельно о данных: не передавайте конфиденциальную информацию во внешние ИИ-сервисы. Развёртывание агентов на рабочей инфраструктуре нужно согласовать и получить официальное разрешение. 

Что в итоге

Для меня главное в агентской разработке — возможность поручить ИИ задачу целиком, а не просить его написать отдельную процедуру. Найти нужный модуль, разобраться в существующем коде, предложить изменение, внести его и запустить проверки. Связка Cursor, MCP и 1C: Platform Tools даёт агенту инструменты для такой работы. 

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

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

Полезные ресурсы

1C: Platform Tools: GitHub, Marketplace,профили запуска.

1C: Platform Tools MCP: GitHub,Marketplace,примеры запросов агенту.

Cursor: документация по MCP.

Разработка от спецификации: GitHub Spec Kit.

СЛОВАРЬ иностранных слов

Термин	Расшифровка / оригинал	Что означает в статье
BSL	Built-in Script Language (язык встроенных скриптов)	Встроенный язык 1С, на котором пишется код обработчиков и модулей.
Cursor	— (название продукта)	Среда разработки с ИИ-агентом, через которую автор ставит задачи и контролирует работу агента.
MCP	Model Context Protocol	Протокол, через который агент обращается к внешним инструментам и получает результаты их работы.
Model Context Protocol	—	Полное название MCP.
1C: Platform Tools	—	Расширение с инструментами разработки 1С: дерево метаданных, навигация, работа с базами, сборка, запуск, тестирование.
1C: Platform Tools MCP	—	Отдельное расширение с MCP-сервером, дающее агенту доступ к командам Platform Tools.
IPC	Inter-Process Communication	Межпроцессное взаимодействие — способ обмена данными между процессами; в статье — между MCP-сервером и расширением Platform Tools.
Vibe Coding	— (от vibe — «настроение, ощущение»)	Подход, когда задача ставится коротким запросом на естественном языке без развёрнутой спецификации.
Plan → Execute → Review	«План → Выполнение → Проверка»	Схема работы: сначала агент предлагает план, затем выполняет его после согласования, затем результат проверяется.
SDD	Specification-Driven Development	Разработка от спецификации: сначала фиксируются требования и критерии приёмки, затем план, задачи и реализация.
GitHub Spec Kit	—	Инструмент для организации разработки от спецификации: спецификация, технический план, задачи, реализация.
skills	«навыки»	Специализированные навыки/инструменты, которые можно дополнительно подключить агенту.
Marketplace	«торговая площадка»	Магазин расширений, откуда устанавливаются расширения для среды разработки.
Open VSX	Open VSX Registry	Открытый реестр расширений для редакторов кода; альтернативный источник установки расширений.
packagedef	package definition	Файл в корне проекта, по которому расширение распознаёт проект 1С.
vanessa-runner	— (название инструмента)	Инструмент/набор команд для сборки, запуска и тестирования 1С, который использует Platform Tools.
OneScript	— (название инструмента)	Среда исполнения скриптов на языке 1С; используется в окружении разработки.
OPM	OneScript Package Manager	Менеджер пакетов для OneScript.
Git	— (название системы)	Система контроля версий; в статье через неё просматриваются и фиксируются изменения.
Git diff	diff — «различие»	Показ различий между исходными и изменёнными файлами.
IDE	Integrated Development Environment	Интегрированная среда разработки; в статье — режим, где можно открыть файлы, посмотреть изменения и поправить код вручную.
MCP-сервер	—	Компонент, который предоставляет агенту доступ к инструментам по протоколу MCP.
MCP-вызов	—	Обращение агента к инструменту через MCP.
профиль запуска	—	Набор параметров работы с информационной базой: какая база, версия платформы и т.п.
ревью	review — «просмотр, проверка»	Проверка реализации относительно требования.
diff	—	См. Git diff: различия между версиями файлов.
чат	—	Диалоговое окно с агентом, где ставится задача и читается отчёт.
агент	agent — «действующее лицо»	ИИ-помощник, который может искать файлы, изучать код, вносить изменения и запускать проверки.
агентский подход	—	Подход, при котором агенту дают не только описание задачи, но и доступ к исходникам и инструментам разработки.
Vibe Coding	—	См. выше: короткий запрос без большой спецификации.
SDD	—	См. выше: разработка от спецификации.