Первый промпт для BSL: как научить ИИ-агента сверяться с метаданными конфигурации

Модель отвечает про конфигурацию 1С уверенно и (почти всегда) ошибается в именах. Причина простая: у LLM нет доступа к структуре вашей конфигурации. Модель читала типовые решения и чужие примеры, но про вашу конфигурацию не знает ничего: реквизит суммы у вас называется СуммаДокумента, а контрагент лежит в шапке документа.

Ошибка в имени реквизита не мешает модулю загрузиться. BSL исполняется интерпретатором, поэтому обращение к несуществующему полю всплывает в момент выполнения строки, сообщением «Поле объекта не обнаружено». Если строка стоит в обработчике проведения, ошибку первым увидит пользователь.

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

🧱 Почему агент выдумывает имена

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

Три места, где это ломается чаще всего:

• Реквизиты с нестандартными именами. В типовых решениях их переименовывают при доработках: ЮрАдрес, ИННКонтрагента, СуммаСНДС. Модель подставит общеупотребительное имя.
• Строковый код. Вызовы через Выполнить("ПроверитьЗаполнение") и Вычислить("Цена * Количество") собираются во время работы, и по тексту модуля их не видно ни человеку, ни агенту.
• Общие модули и их экспортные функции. Даже верно угаданное имя общего модуля не даёт сигнатуры: сколько параметров, какие обязательные, что возвращается.

Синтаксис при этом остаётся правильным. Модуль проверится, конфигурация обновится, а падение случится на конкретном документе в конкретном сценарии.

🔌 Что отдаёт MCP-сервер метаданных

MCP (Model Context Protocol) - открытый протокол, по которому агент запрашивает данные у внешнего процесса. Обмен идёт сообщениями JSON-RPC: клиент вызывает tools/list и получает список инструментов сервера с описанием параметров, затем tools/call с именем инструмента и аргументами. Формат описан в спецификации протокола, раздел Tools.

Сервер метаданных для 1С подключается к базе внешним соединением или через HTTP-сервис, читает структуру объектов и отдаёт её агенту по запросу. Внешнее соединение открывается COM-объектом и строкой подключения:

1
2

Соединитель = Новый COMОбъект("V83.COMConnector");
Соединение = Соединитель.Connect("Srvr=""srv-1c"";Ref=""dev_base"";Usr=""robot"";Pwd=""***"";");

Для файловой базы строка другая: File="C:\bases\dev";Usr="robot";Pwd="***";. Через полученное соединение доступны объекты встроенного языка и экспортные процедуры общих модулей с включённым свойством «Внешнее соединение».

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

Если сервер пишете сами, учтите ограничение на имя инструмента из спецификации: от 1 до 128 символов, латиница, цифры, подчёркивание, дефис и точка. Имена вида [get_object_structure] в квадратных скобках протокол не примет - квадратных скобок в допустимых символах нет.

🧪 Выгрузка метаданных на BSL

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

1
2
3
4

СправочникМД = Метаданные.НайтиПоПолномуИмени("Справочник.Номенклатура");
Для Каждого Реквизит Из СправочникМД.Реквизиты Цикл
    Сообщить(Реквизит.Имя + " - " + Строка(Реквизит.Синоним));
КонецЦикла;

Состав коллекций зависит от вида объекта. У документа есть ТабличныеЧасти, у каждой части - свои Реквизиты. У регистра накопления - Измерения и Ресурсы, у регистра сведений к ним добавляется периодичность. Стандартные реквизиты (Ссылка, ПометкаУдаления, Дата, Номер, Проведен) лежат отдельно, в коллекции СтандартныеРеквизиты, и в Реквизиты не попадают. Сервер, который читает только Реквизиты, отдаст агенту неполную картину, и агент снова угадает Проведен.

Код выше не прогнан на платформе: в облаке нет 1С. Проверьте его на своей базе перед тем, как встраивать в сервер.

💻 Первый промпт

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

Ты - эксперт по разработке на платформе 1С:Предприятие 8.3.
У тебя подключён MCP-сервер метаданных конфигурации.

Порядок работы над задачей:
1. Получи список инструментов MCP-сервера. Если структура нужных объектов уже есть
   в контексте этой сессии, повторно не запрашивай.
2. Определи объекты, которые нужны для задачи, и запроси структуру каждого:
   реквизиты шапки, табличные части и их колонки, измерения и ресурсы регистров.
3. Пиши код только по именам, которые вернул сервер. Имя, которого нет в ответе
   сервера, использовать нельзя, даже если оно выглядит стандартным.
4. Перед ответом перечисли имена, взятые из метаданных, и укажи, из какого ответа
   сервера получено каждое.

Если сервер недоступен или не вернул структуру объекта - остановись и напиши:
«Нет данных о структуре объекта <имя>». Код в этом случае не пиши.

Задача: <опишите задачу>

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

Пункт 4 - дешёвая проверка для вас. Агент сам показывает, какие имена он взял из ответов сервера. Если в списке пусто или имена не совпадают с тем, что вернул сервер, промпт не сработал, и это видно до запуска кода.

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

🧰 Как проверить промпт на своей конфигурации

Три теста, каждый на своей базе:

1. Несуществующий реквизит. Дайте задачу, для которой нужен реквизит, отсутствующий в конфигурации, например Справочник.Номенклатура.АртикулПоставщика при его отсутствии. Правильное поведение - сообщение, что в метаданных такого реквизита нет.
2. Нестандартное имя. Возьмите свой реквизит с переименованием (СуммаДокумента, ЮрАдрес) и посмотрите, какое имя окажется в коде. Совпадение с базой означает, что агент читал структуру.
3. Отключённый сервер. Уберите MCP-сервер из настроек агента и повторите задачу. Кода в ответе быть не должно.

К тестам добавляется журнал вызовов инструментов. Посчитайте, сколько разных объектов агент запросил за задачу. Если в задаче участвуют десять объектов, а в журнале два, промпт работает вполсилы, и пункт 2 стоит переписать конкретнее.

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

🚧 Границы

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

📚 Источники и чем эта статья отличается

• Спецификация Model Context Protocol, раздел Tools: методы tools/list и tools/call, поля описания инструмента, правила именования.
• «Технологии интеграции 1С:Предприятия 8.3», раздел «Внешнее соединение» (its.1c.ru): COM-объекты V83.COMConnector и V82.COMConnector, строка подключения, ограничения внешнего соединения.
• Методическая документация 1С по работе с объектами метаданных во встроенном языке (its.1c.ru): Метаданные.НайтиПоПолномуИмени(), коллекции Реквизиты, СтандартныеРеквизиты, ТабличныеЧасти.
• Разбор ошибки «Поле объекта не обнаружено» на Infostart (статья 2286929): почему она возникает во время выполнения и чем проверять существование свойства.

Публикации на ту же тему, прочитанные 30.09.2026:

📦 Файл к статье

К публикации приложен архив 02.2-companion.zip, он в блоке «Файлы» вверху страницы:

• prompt-mcp-metadannye.md - промпт из статьи: агент сначала запрашивает структуру объектов у MCP-сервера метаданных и пишет код только по полученным именам; если данных нет - останавливается.
• bsl/rekvizity-spravochnika.bsl - перебор реквизитов справочника через Метаданные.НайтиПоПолномуИмени.
• bsl/vneshnee-soedinenie.bsl - подключение через V83.COMConnector.
• README.md: что внутри, как пользоваться и что проверено.

🏁 Итог

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

Проверяется это на трёх задачах: несуществующий реквизит, переименованный реквизит, отключённый сервер. Замер частоты вызовов сервера на своих задачах я не проводила: это зависит от модели и от описаний инструментов в вашем сервере.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 28+ технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S