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

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

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

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

Хотя, погодите... Именно так многие машины теперь и собирают. Второй завод берет за сборку свои деньги, клеит свой шильдик и продает дороже заводского. Машина та же, дорога длиннее, платит за нее покупатель. Но рационально ли это?

Два разных вопроса, а маршрут предлагают один

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

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

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

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

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

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

Полгода назад я бы на этом и остановился

За последние месяцы для 1С появились MCP‑серверы (Model Context Protocol, протокол, по которому агент обращается к внешним инструментам и данным), и это уже не пара любительских экспериментов. В курируемом каталоге 1c‑mcp сейчас сорок два проекта, тридцать семь из них с открытым кодом, и у флагманов по две с лишним сотни звезд. Заведены они в феврале и марте, то есть вся эта поляна выросла буквально за полгода.

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

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

Метаданные из живой базы, код из выгрузки

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

Возьмем mcp-1c, сервер для работы с живой базой: один бинарник на Go, одиннадцать инструментов в открытой редакции. Поиск по коду там есть, называется search_code. Читаем описание в его же таблице инструментов:

reload_dump — перечитать выгрузку без перезапуска сервера: после повторной выгрузки конфигурации search_code начинает искать по новому содержимому. Доступен только с --dump

А вот и сам флаг, из таблицы параметров запуска:

--dump — Путь к выгрузке конфигурации (DumpConfigToFiles), включает инструменты search_code и reload_dump

Так же устроены и формы:

get_form_structure ‑...полный состав читается из выгрузки, поэтому нужен запуск с --dump; без него возвращается только то, что отдал HTTP‑сервис 1С, и форму он выбирает сам

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

У второго флагмана, 1c‑mcp‑toolkit, картина похожая с другой стороны. В его таблице тринадцать инструментов: выполнение запросов, выполнение произвольного кода, метаданные, журнал регистрации, объект по ссылке, ссылка на объект, поиск ссылок на объект, права доступа, справочник по встроенному языку, снимок окна, деанонимизация ответа и две команды управления сеансом. Инструмента, который отдал бы текст модуля, среди них нет, и вывод тот же: код живая база не отдает.

Отдельно про цену

У mcp-1c есть таблица сравнения редакций, и открывать ее стоит до того, как начнете прикидывать, во что вам обойдется переход. Открытая редакция под лицензией MIT бесплатна и содержит те самые одиннадцать инструментов. Расширенная стоит 1990 рублей в месяц, профессиональная 4990, и добавляют они довольно много всего: линтер, оптимизатор запросов, синтакс‑помощник, работу с расширениями, шаблоны, массовый анализ кодовой базы.

На странице тарифов и в README возможности чтения кода названы по‑разному. Но поиск по коду в таблице инструментов описан однозначно: он работает по заранее сделанной выгрузке, и без --dump инструмент просто не включается. В описании платных редакций выгрузка всплывает снова и снова там, где речь о конфигурации. «Резолв имен объектов по индексу выгрузки», «структурная проверка XML по реальной выгрузке», «разбор прав и RLS ролей, а также планов обмена (офлайн, по выгрузке)». Выгрузка тут не побочный режим, на нее опирается часть возможностей работы с кодом и конфигурацией.

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

Чем держится HTTP‑служба

Дальше начинается то, что в описаниях проходит одной строкой, а разворачивается в отдельную задачу. Сервер общается с базой через HTTP‑сервис, и служба эта сама собой не поднимается, ее что‑то должно держать.

Первый способ — опубликовать HTTP‑сервис 1С на веб‑сервере. Тогда у вас появляется Apache или IIS со всем, что к ним прилагается. У mcp-1c это прямо третий шаг быстрого старта:

Опубликуйте HTTP‑сервис 1С через Apache или IIS (Конфигуратор → Администрирование → Публикация на веб‑сервере)

Второй способ — держать службу внутри клиентского сеанса, как у toolkit, где встроенный сервер обеспечивают нативные компоненты: в репозитории лежит инструкция по их сборке и настроен CI. Веб‑сервер тогда не нужен, зато агенту вы даете адрес вида http://<ip-компьютера-1С>:6003/mcp, и это адрес машины с запущенным клиентом. Со всеми вытекающими: открытый порт на рабочем месте, занятая лицензия, права того пользователя, под которым сеанс запущен. И живет такой сервер ровно столько, сколько открыт сеанс: закрыли 1С или выключили компьютер, уходя домой, и агенту обращаться больше некуда.

Что сеанс тут именно настоящий, видно по двум последним инструментам из той же таблицы. restart_1c_session описан как «перезапуск текущей сессии 1С (требуется после обновления конфигурации)», а close_1c_session как «закрытие текущей сессии 1С с возвратом команды запуска новой (для операций, требующих эксклюзивного доступа к базе)». Обновили конфигурацию — перезапускайте сеанс. Понадобился монопольный доступ — закрывайте и открывайте заново.

Есть и третий способ, он платный. В списке расширенной редакции mcp-1c есть строка «работа через реверс‑опрос (long polling): фоновое регламентное задание в 1С само опрашивает сервер, публиковать HTTP‑сервис на веб‑сервере не нужно». Инфраструктурная возня снимается подпиской, что для многих контор будет самым дешевым вариантом из трех, если считать рабочее время администратора.

Установка mcp-1c описана как «сам найдет платформу, поставит расширение, обновит конфигурацию БД». Сделано удобно, но конфигурация базы данных при этом действительно обновляется, и там, где такие вещи согласовывают, согласовать придется.

Что протухает

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

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

Сложим, что получается

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

Первый маршрут — mcp-1c с публикацией. Расширение в базе, из‑за которого обновляется конфигурация базы данных, веб‑сервер с опубликованным HTTP‑сервисом и выгрузка конфигурации на диске, чтобы работал поиск по коду. Открытая редакция бесплатна.

Второй — mcp-1c с реверс‑опросом. Все то же самое, кроме веб‑сервера, и это подписка от 1990 рублей в месяц.

Третий — toolkit из внешней обработки. Ни расширения, ни веб‑сервера, зато открытый порт на рабочей станции и постоянно запущенный клиентский сеанс. Для вопросов про данные этого достаточно, а для вопросов про код маршрут не годится: инструмента, отдающего текст модулей, в его списке нет.

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

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

А если вопросы про данные

Возвращаюсь ко второй задаче, с которой начинался разговор с коллегой: собрать отчет по чужой конфигурации и понять, откуда берутся числа. Здесь код агенту не нужен, нужны метаданные и возможность выполнить запрос, а то и другое живая база отдает сама. Бесплатного MCP‑сервера для этого достаточно. Вопрос в том, сколько шагов вы готовы поставить между собой и ответом.

И вот тут пригождается та самая привычка, про которую я вспоминал в начале. Маршрут через MCP уносит работу с запросом в IDE, к агентской среде, а отлаживать запросы в 1С принято в Предприятии, на живых данных. Проверить запрос оттуда можно, execute_query для этого и сделан: агент выполняет его на базе и видит настоящий результат. Только результат приходит агенту, и в чате вы видите его в том виде, в каком агент решил показать, а привычные таблица, отбор и выгрузка в файл остались в 1С, в соседнем окне. Это не смертельно и кого‑то устроит, но место работы лучше выбирать самому, чем принимать то, где случайно оказался агент.

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

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

#