Философия плагина MCP:RSV Server

Почему плагин устроен именно так: законченные сценарии вместо конструктора инструментов, штатные механизмы EDT вместо обходных путей — и полный цикл разработки, который ИИ-агент проходит сам, пока человек остаётся архитектором.

Инструменты, которые соединяют ИИ-агентов с 1С, сегодня развиваются по двум разным дорогам. Полезно честно описать обе — и объяснить, почему мы выбрали свою.

Два подхода

Первый подход — конструктор. Дать агенту и человеку как можно больше отдельных инструментов: читалки, писалки, метки, индексы, отчёты, панели. Человек-программист остаётся в среде разработки, смотрит в объекты и код, а инструменты ускоряют его работу. Это честный и рабочий путь — хороший ящик инструментов: чем он богаче, тем больше мастер может сделать. Но делать по-прежнему будет сам мастер, своими руками.

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

MCP:RSV Server построен по второму пути. Это не оценка чужого выбора — это другая цель. Мы делаем инструмент не для разработчика, а для архитектора и постановщика задач: не помощника, который ускоряет программисту рутину, а исполнителя, который берёт программирование на себя. Человек превращается из исполнителя в архитектора и приёмщика.

Как это выглядит

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

Из этой цели выводится всё остальное.

Принципы

Результат одним вызовом. Каждая операция плагина — законченный шаг сценария, а не деталь конструктора. «Создай форму списка» — это одна операция, после которой форма существует, корректна и открывается, а не десять вызовов, которые агент должен правильно сложить сам.

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

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

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

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

Почему у нас нет некоторых функций — осознанно

В инструментах-конструкторах встречаются функции, которых у нас нет и не будет. Не потому, что мы не успели — потому, что при нашем подходе они не нужны.

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

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

Баллы «технического долга». Сводный балл — цифра для презентации, а не для решения. Качество кода обеспечивают не баллы, а конкретные механизмы: проверка при каждой записи, ревью по стандартам, тесты, диагностика производительности. О них ниже.

Чем обеспечивается качество

Проверка встроена в запись. Когда агент записывает код, проверка среды разработки приходит в том же ответе: список ошибок со строками — или «ошибок нет». Цикл «записал → увидел → исправил» замыкается автоматически, человеку не нужно перепроверять за агентом каждую правку.

Код-ревью по стандартам 1С. Отдельный инструмент прогоняет код по проверкам стандартов разработки: сложность методов, длина, устаревшие конструкции, магические числа и десятки других. Агент получает замечания с позициями и чинит их сам.

Тесты — часть цикла, а не событие. Агент сам запускает модульные тесты (YAxUnit) и сценарные проверки интерфейса (Vanessa), сам читает отчёты, сам чинит падения и повторяет прогон. «Не двигаться дальше, пока тесты не зелёные» — для агента это правило, которое он соблюдает в каждом цикле.

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

Диагностика: правда рантайма вместо предположений

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

• Замер производительности показывает, какой код реально выполнялся: карту выполнявшихся методов, самые долгие строки и методы, число выполнений, полное и чистое время. Можно спросить «откуда реально вызывался этот метод» — и получить ответ по фактическим вызовам, а не по догадкам. Фактически это граф работы системы, построенный из реального выполнения.
• Технологический журнал ловит долгие запросы, серверные вызовы, исключения и блокировки — с точкой кода и текстом запроса.
• Журнал регистрации читается прямо из среды: что происходило в базе, без ручного открытия консолей.

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

Полный цикл — без человека внутри

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

Постановка словами → создание объектов и форм → код с автоматической проверкой → обновление информационной базы → модульные и сценарные тесты → код-ревью → фиксация результата в системе контроля версий. На каждом шаге — проверка; человек подключается дважды: в начале, чтобы поставить задачу, и в конце, чтобы принять работу. Это не план развития — так плагин работает уже сейчас, включая нашу собственную разработку.

Глубина и уникальные возможности

Философия законченных сценариев не означает скромный набор функций — наоборот. Плагин покрывает порядка 90% операций повседневной разработки: объекты и реквизиты, управляемые формы, табличные части, роли, подсистемы, макеты, схемы компоновки, расширения, внешние обработки и отчёты, обмен с информационной базой, тесты, отладка, диагностика, git. И каждая зона проработана в глубину — не «создать объект», а довести его до состояния, в котором с ним можно работать.

Есть и возможности, которых не даёт ни один другой инструмент. Пример — работа с обычноформенными конфигурациями (УТ 10.3 и другие конфигурации на обычных формах): чтение и запись кода модулей обычных форм, доработка таких конфигураций практически полным циклом. Для организаций, живущих на таких системах, это единственный способ подключить к ним ИИ-агента по-настоящему.

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

И ещё один — работа с внешними обработками и отчётами. Агент создаёт обработку в EDT, разрабатывает формы и код — и тут же собирает готовый бинарный файл (.epf/.erf, а таким же образом — поставки конфигураций и расширений .cf/.cfe): открывайте в базе и проверяйте сразу, без перезапусков — как в Конфигураторе. Это тоже философия в действии: максимум скорости и простоты без потери надёжности результата.

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

К чему мы идём

Направление одно: полная автоматизация разработки высокого уровня. Чтобы поводов заглядывать внутрь становилось ещё меньше, а планка результата — только выше. Мы расширяем проверки, углубляем сценарии и продолжаем мерить каждый шаг одним и тем же критерием: слабый агент справляется с первого раза.

Итог

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

Что дальше: скачайте плагин, откройте руководство пользователя — и поставьте своему агенту первую задачу.