Перейти к содержимому
PD
MCP-серверы

MCP-сервер для 1С: как подключить агента к учётной системе

Какие задачи хочет закрыть 1С-аудитория с помощью ИИ-агента, какие есть варианты доступа к данным, как сделать обёртку над HTTP-сервисами и OData, и где проходят границы по правам и безопасности.

Все статьи гида MCP-серверы · 11

Запрос на связку ИИ и 1С растёт, а готовых решений почти нет. Разберём, что здесь реально работает и на какие грабли наступают первыми.

Что хочет 1С-аудитория

Запросы почти всегда сводятся к трём:

  • Спросить данные словами. «Сколько осталось этой позиции», «что с заказом такого-то», «сводка по контрагенту за квартал». Сейчас это отчёт, обработка или звонок программисту.
  • Разобрать входящее в структуру. Письмо от поставщика, скан накладной, заявка в свободной форме превращаются в заготовку документа.
  • Убрать рутину сверки. Сопоставить данные из внешнего источника с тем, что в базе.

Общее у всех трёх: агент здесь читает и предлагает, а вносит человек. Это не ограничение технологии, а разумная граница: учётная система - место, где ошибка имеет последствия.

Варианты доступа к данным

Четыре варианта, от плохого к хорошему.

Прямое обращение к базе СУБД. Не делайте так. Обход платформы означает нарушение блокировок, игнорирование прав и данные, не соответствующие логике учёта.

OData. Штатный механизм публикации. Прост в настройке, даёт доступ к объектам конфигурации. Минус: отдаёт структуру платформы, а не задачу, и агент вязнет в реквизитах.

HTTP-сервисы. Наиболее подходящий вариант. Вы сами описываете, какие операции доступны, и отдаёте готовый ответ на бизнес-вопрос, а не сырые объекты. Это одновременно и слой безопасности.

База-витрина. Данные регулярно выгружаются в отдельное хранилище, агент работает с ним. Максимальная безопасность и никакой нагрузки на рабочую базу; цена - неактуальность в пределах интервала выгрузки. Для аналитики подходит лучше всего.

Обёртка над HTTP-сервисами

Схема выглядит так: агент вызывает инструмент MCP-сервера, сервер обращается к вашему HTTP-сервису в 1С, тот возвращает данные, сервер отдаёт их агенту.

Что определяет успех:

Инструменты формулируются в терминах задачи, а не платформы. Не «получить объект справочника Номенклатура», а «найти товар по названию или артикулу и вернуть остаток по складам». Агент выбирает инструмент по описанию, и описание в терминах метаданных он выберет неверно.

Ответ отдаётся готовым. Расчёты, сворачивание, фильтры - на стороне 1С, где для этого есть язык запросов. Отдать агенту тысячу строк регистра и ждать, что он сам посчитает, - плохая идея: он забьёт контекст и ошибётся в арифметике.

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

Ошибки возвращаются текстом. «Контрагент не найден» полезнее, чем пустой ответ: агент прочитает и уточнит запрос вместо того, чтобы придумать данные.

Как устроен сам сервер и его инструменты - в статье про обёртку своего API и сервер на Python.

Права и безопасность

Порядок, который не приводит к неприятностям:

  1. Отдельный пользователь 1С с ролью только на чтение нужных объектов. Не администратор, не «полные права на время теста».
  2. Публикация во внутренней сети, а не наружу. Если наружу необходимо - только по HTTPS и с аутентификацией.
  3. Никаких инструментов записи на старте. Изменение документов добавляется отдельно, по одному действию, и с подтверждением человеком.
  4. Логирование вызовов на стороне 1С: кто, что и когда спросил.
  5. Персональные данные - отдельный вопрос. Всё, что попало в контекст, ушло провайдеру модели. Если в ответах есть данные физлиц, это надо решать до запуска: либо обезличивание, либо локальная модель.

Ограничения, о которых стоит знать заранее

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

Производительность. Каждый вызов - обращение к рабочей базе. Десяток вопросов подряд в разгар дня заметен. Витрина решает это лучше кэша.

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

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

Общая картина по протоколу - гид по MCP. Если нужна такая интеграция под конкретную конфигурацию - см. страницу услуг.

Вопросы и ответы

Можно ли подключить ИИ-агента к 1С?

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

Безопасно ли давать агенту доступ к базе 1С?

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

Что реально даёт агент поверх 1С?

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

Ещё по теме