ИИ в 1С-разработке быстро упирается в простой вопрос: он правда знает вашу базу или красиво угадывает? MCP помогает модели увидеть структуру конфигурации: документы, справочники, регистры, реквизиты и связи между объектами. Для разработки это уже большой шаг. Модель меньше фантазирует про несуществующие реквизиты и лучше ориентируется в конфигурации.
Но структура отвечает только на вопрос, как устроена система. В работе часто нужен другой ответ: что прямо сейчас лежит внутри этой системы. Какие остатки ушли в минус? После какого документа возникла проблема? Что находится в регистре по конкретному складу? Где фактическое движение не совпало с ожиданием пользователя?
Следующий шаг в этой истории — переход от каркаса конфигурации к содержимому базы.
Почему одной структуры мало
Когда ИИ видит только метаданные, он может помочь с навигацией по конфигурации. Например, подсказать, где искать регистр, какие документы потенциально участвуют в движениях, как может выглядеть запрос, куда смотреть в модуле.
Для разработчика это полезно, но в прикладной диагностике быстро появляется потолок. Модель знает, что в конфигурации есть регистр остатков, но не знает, какие записи в нем есть сейчас. Она может предположить, какой документ мог сделать движение, но не видит реальную цепочку событий. Она может написать правдоподобный запрос, но без доступа к данным не проверит, что этот запрос отвечает на рабочий вопрос.
Хороший пример — задача с отрицательными остатками. Пользователь приходит с конкретной проблемой: на складе появился минус. Ручной путь знаком многим: открыть отчеты, провалиться в движения, искать документы, сравнивать периоды, проверять регистры. MCP с доступом к данным меняет саму механику разбора.Модель сначала узнает структуру, затем запрашивает содержимое, потом строит следующий вопрос уже по фактам. Вместо общей гипотезы про реализацию появляется проверяемый результат: вот документы, после которых остаток стал отрицательным.
MCP как мост между ИИ и 1С
MCP, Model Context Protocol, нужен не для красивой интеграционной схемы. Его практический смысл в другом: дать ИИ контролируемый способ обратиться к внешнему инструменту и получить факт из системы.
В нашем случае таким инструментом становится 1C MCP Toolkit от ROCTUP. Он подключается к базе 1С через внешнюю обработку, поднимает встроенный HTTP-сервер и дает ИИ-агенту набор функций для работы с конфигурацией и данными. При этом не требуется менять конфигурацию, публиковать сервер 1С наружу или использовать COM-соединение.
Схема работы выглядит спокойно:
1. ИИ-агент получает задачу от разработчика.
2. Через MCP вызывает инструмент.
3. Инструмент обращается к 1С.
4. 1С возвращает структуру или данные.
5. Агент интерпретирует результат и задает следующий уточняющий запрос.
Здесь важна последовательность. Хороший сценарий начинается с проверки фактов. Сначала посмотреть, какие объекты есть. Потом понять, какие данные лежат в нужном регистре. Затем связать результат с документами и движениями. Только после этого формулировать рекомендацию.
Что изменилось в новом сценарии
Раньше MCP давал модели каркас: метаданные, имена объектов, связи, состав реквизитов. Теперь в контур добавляется работа с содержимым через SQL-запросы к базе 1С.
Это открывает несколько рабочих сценариев:
- быстро получить срез данных по условию;
- проверить записи регистра без ручного обхода интерфейса;
- найти документы, которые повлияли на остатки;
- собрать первичную диагностику по проблеме пользователя;
- получить черновик объяснения, основанный на реальных данных.
Самое интересное здесь не в том, что ИИ может выполнить запрос. Запрос и раньше мог написать разработчик. Интереснее цепочка: модель видит результат, понимает, что нужно уточнить, делает следующий запрос, сравнивает данные и собирает объяснение.
Например, в задаче с отрицательными остатками агент может пойти по такому маршруту:
- Найти регистр, где хранится остаток.
- Получить записи по складу и номенклатуре.
- Определить момент, когда остаток стал отрицательным.
- Посмотреть документы-регистраторы.
- Сформулировать вероятную причину и предложить проверку.
Для разработчика это похоже на работу младшего аналитика, которому можно поручить первичный разбор. Он не заменяет специалиста, но снимает часть рутины: найти, собрать, сопоставить, показать подозрительное место.
Где проходит граница пользы
Доступ к данным делает ИИ заметно полезнее, но вместе с этим растет ответственность команды. Если модель может читать содержимое базы, нужно заранее решить, где она работает и какие данные ей доступны.
Для первых экспериментов лучше использовать тестовую или обезличенную копию базы. Права должны быть ограничены чтением, а набор инструментов должен соответствовать задаче. Если нужен анализ остатков, не надо давать агенту больше возможностей, чем нужно для чтения нужных регистров и документов.
Еще один момент: ИИ не становится владельцем решения. Он помогает найти факты и собрать гипотезу. Разработчик проверяет запросы, оценивает выводы, смотрит на права, нагрузку и корректность интерпретации. Иначе есть риск заменить одну проблему другой. Раньше модель фантазировала из-за отсутствия данных. Теперь она может ошибиться в трактовке реальных данных. Разница большая: такую ошибку проще проверить, потому что есть исходные факты, но проверка все равно нужна.
Практический контур
Для первого пилота подойдет понятный маршрут:
1. Подключить MCP к учебной конфигурации 1С.
2. Запустить внешний инструмент и проверить, что он отвечает.
3. Подключить MCP-инструмент к ИИ-агенту.
4. Запросить структуру конфигурации.
5. Перейти к запросу содержимого регистра.
6. Разобрать прикладную задачу на реальных данных.
Важная мысль: само подключение инструмента еще не дает ценности. Нужна короткая прикладная задача с проверяемым результатом. Например, найти причину отрицательного остатка. Такая задача достаточно узкая, чтобы контролировать результат, и достаточно рабочая, чтобы сразу увидеть пользу.
Что меняется для 1С-разработчика
Разработчик получает новый режим работы. Вместо ручного обхода конфигурации и базы можно вести диалог с агентом, который умеет сам запрашивать часть фактов. Вместо просьбы "напиши мне запрос к регистру" появляется другая формулировка: "найди, после какого документа остаток стал отрицательным". Следующий уровень — попросить агента посмотреть структуру, проверить реальные движения и объяснить вывод по данным, которые он только что получил.
Такой подход особенно интересен для поддержки, разбора инцидентов, предварительной аналитики и подготовки к доработкам. Перед тем как писать код, можно быстрее понять, что происходит в базе и где искать причину.
Выводы
MCP становится заметно полезнее, когда ИИ работает с описанием конфигурации и фактами из базы. В этот момент диалог с моделью начинает напоминать рабочий разбор задачи вместо обмена красивыми предположениями.
Для первого пилота лучше выбрать узкую задачу: отрицательные остатки, поиск документов-регистраторов, проверку движений или сбор первичного среза по регистру. Так проще оценить пользу и не открыть агенту лишние данные.
Разработчик остается владельцем решения. ИИ помогает быстрее найти факты, собрать гипотезу и показать подозрительное место, но выводы все равно нужно проверять.
А как вы думаете, какую задачу в 1С стоит первой отдать такому агенту на разбор? Напишите в комментариях.
Вступайте в нашу телеграмм-группу Инфостарт