Развиваем ИИ-платформу в 1С
Привет! Я - Роман Коротаев, ресурсный руководитель направления 1С в компании Синимекс.
В этом материале хочу рассказать, как мы пришли к ИИ для 1С и что из этого вышло. Материал получился про попытку собрать полноценную ИИ-платформу для работы с учетными данными. Расскажу, зачем нам понадобился MCP, как мы связали его с 1С:Шина, почему отдельно уперлись в права доступа и как в итоге устроили агента внутри 1С. Также покажу, где видим место для skills, RAG и OCR, и что пока не стали отдавать модели на самостоятельное выполнение.
В конце 2024-ого - начале 2025-ого года я, наконец, начал присматриваться к большим языковым моделям и, как и многие, был полон скепсиса.
Я был в отпуске, и первый опыт с только что вышедшей DeepSeek удивил.
Модель сносно писала шаблоны ЧТЗ и даже генерировала xml-скрипты bpmn-схем. Не с первого раза, понятно, но дотянуть до работающего варианта было возможно.
И я понял, что пора погружаться в тему серьёзно. Через пару месяцев подтянул к теме нашего архитектора 1С Дениса, научился оплачивать подписки, установил Cursor и дело пошло... :)
MCP-сервер на 1С:Шина
Разбираясь в теме function calling, tool use и MCP-серверов Денис предложил реализовать MCP на 1С:Шина. Кто не в курсе, 1С:Шина - это, по сути, платформа для разработки интеграционных приложений для баз 1С (и не только) на языке “1С:Предприятие.Элемент”. Это не язык 1С, но тоже на русском, похож на TypeScript.
Реализация MCP-сервера на 1С:Шина и размещение на нем функций (tools) облегчает задачу доступа к разным базам 1С предприятия без необходимости разработки и разворачивания дополнительных средств интеграции с выделенным сервером MCP.
Архитектура текущего решения представлена на схеме ниже.
Как это работает? На стороне 1С:Шина реализованы типовые endpoint сервера MCP. При вызове функции, ассоциируемой MCP-сервером с функциями 1С происходит вызов определенного кода на языке 1С в базах 1С.
Далее, на стороне 1С переданный код выполняется от лица переданного также пользователя и результат возвращается MCP-серверу.
Функции (tools, инструменты)
Что такое function calling? Представим себе функцию, написанную в конфигурации 1С на языке 1С, выполняющую какое-то простое действие. Например, SELECT по определенным условиям из таблицы. Тогда при правильно составленном запросе пользователя в чат ИИ “А что у нас по таким-то данным за прошлый год?”, LLM будет генерировать JSON с названием нужной функции и входящими параметрами. Дальше мы в 1С разбираем JSON, выполняем функцию и ответ возвращаем обратно в LLM, которая уже пользователю отвечает в удобном человеческом виде.
Вообще, разработке tools для MCP-сервера, работающего с бизнес-данными, можно посвятить отдельный материал. Здесь отмечу только, что важно проектировать инструменты именно с бизнес-ценностью. Например, у нас на демо-стенде есть mcp-1c_margin_breakdown. Эта функция-запрос к регистру накопления 1С “ВыручкаИСебестоимостьПродаж” с детализацией по Подразделению, Менеджеру, Складу за период. При вызове функция позволяет LLM отвечать, например, на такой вопрос:
Покажи топ-10 менеджеров по валовой прибыли и найди тех, у кого маржа ниже 10% за последний квартал.
Использование корректно спроектированных инструментов — это критически важная часть, позволяющая избегать галлюцинаций LLM практически в полном объеме. LLM тут не выдумывает цифры сама и не имеет доступа к базе, она только вызывает инструменты и форматирует ответ.
Права доступа
Конечно, вопрос прав доступа к данным при выдаче информации от LLM к конечному пользователю очень важен. Без этого решение не может использоваться в реальных процессах на предприятии. В 1С есть определенная сложность в запуске headless-режима - 1С:Шина запускает код в базе 1С под техническим пользователем с эксклюзивными правами, которые не повторяют права каждого из бизнес-пользователей 1С. Уточню, в 1С используется Row Level Security, и эти правила для каждого пользователя (профиля пользователей) свои. То есть, 1С база будет выдавать данные сообразно правилам RLS этого технического пользователя, что нам решительно не подходит.
Тем не менее, вариант реализации запуска инструментов MCP от имени пользователя системы был найден и реализован средствами 1С.
Дальше уже дело техники: создаем токены доступа для каждого пользователя и пробрасываем их до MCP-сервера, идентифицируем пользователя по токену и передаем его в базы 1С при вызове tools. 1С отдает только доступные для этого пользователя данные.
MCP-сервер успешно заработал! LLM начала определять подключившегося пользователя, здороваться по имени (неожиданная фича), вызывать инструменты и формировать ответы.
Модель
Мы сразу определились, что будем использовать для своих решений локальные модели. Это безопасность конфиденциальных и персональных данных. В причины можно записать и независимость от внешних поставщиков, прежде всего иностранных. Хотя возможность подключить облачную модель, конечно, имеется. В итоге, используем gpt-oss-120b в локальном контуре и моделью довольны.
Агенты
Для тестирования MCP-сервера мы остановились на open-source агенте OpenCode. Также пробовали OpenWork от тех же авторов. Но OpenCode в десктопном варианте нам понравился больше, можем рекомендовать.
Кроме того, конечно, нужно было затаскивать агента в среду 1С - для работы обычного пользователя 1С это основной рабочий вариант использования.
Поэтому мы подключили еще одного нашего энтузиаста ИИ - разработчика Павла, который и начал делать агента с интерфейсной частью уже непосредственно в 1С.
При этом серверная часть агента реализована с использованием Pydantic AI.
Как работает серверная часть агента? 1С отправляет HTTP-запрос в бэкенд оркестратор. Вначале, сделана небольшая проверка на тематику запроса – прям уж сильно отвлеченные запросы к модели проходить не будут. Далее, организуется динамическая сборка системного промпта (prompt composer) и LLM в процессе первого запроса определяет необходимость вызова набора инструментов (MCP-tools или skills или сразу ответ пользователю).
А дальше уже идет цикл обращения к инструментам или навыкам с оценкой достаточности ответа самой моделью. Если ответ недостаточен, модель может вызвать новые инструменты (или те же с другими параметрами).
Конечно, есть защиты от зацикливания: ограничения на переиспользование одного и того же инструмента с теми же параметрами. И просто ограничение на количество шагов в цикле. Это ограничение настраиваемое.
Когда ответ устраивает LLM начинается обработка финализации ответа. Например, форматирование таблиц, проверка на сырой JSON в ответе пользователю и ряд других проверок.
Вся цепочка взаимодействия (запросы пользователя, агентский цикл, ответы LLM) агента логируется на стороне сервера и доступна из интерфейса 1С. Это сильно помогает при отладке работы агента.
Skills
Конечно, мы не стали отставать от современных реалий и реализовали навыки в агенте.
Есть централизованные инструменты (tools) на стороне mcp-сервера, а есть локальные навыки (skills) на стороне 1С-базы. Тулы и скилы.
Для начала мы реализовали группу «инфраструктурных» навыков – это, к примеру, чтение объектов 1С по навигационной ссылке, чтение вложенных ссылок, чтение вложений к объекту и т.п. Эти навыки мы разместили непосредственно в коде агента 1С.
Следом появилась группа пользовательских навыков – это те, которые настраиваются и хранятся в конфигурации 1С (Хранилище значений 1С) или в виде файлов на диске. Обычно, пользовательские навыки имеют бизнес смысл, например local_find_purchase_documents (поиск документов «Приобретение товаров услуг» по заданным параметрам).
Для каждого заказчика набор пользовательских навыков нужно проектировать отдельно согласно требованиям. Это также справедливо и для инструментов MCP-сервера.
Приведем пример работы агента для конфигурации «1С:Документооборот»:
- Пользователь спрашивает агента: «Покажи, кто согласовывал договор №5589 и какие были комментарии?»;
- Агент находит подходящий навык для поиска документа в базе 1С – это local_find_document_requests и ищет документ;
- Далее, агент вызывает навык local_read_document_processing_route для извлечения данных из базы 1С по цепочке согласования;
- Все навыки на стороне 1С выполняются в фоновом задании под текущим сеансом. То есть, доступ к данным определяется ролевой моделью текущего пользователя;
- Полученные данные, включая этапы, участников, состояния документа, результаты и комментарии отправляются внутрь агента в LLM для формирования ответа пользователю;
- Агент возвращает ответ пользователю в удобном структурированном виде.
UI для агента 1С
Павел начал с реализации фронта агента в обработке 1С в «ПолеHTMLДокумента». Вариант хороший и позволяющий создать функциональный и современно выглядящий интерфейс чата. При этом максимально гибкий. Отмечу, что чат отрисовывается нашим скриптом js, который и взаимодействует 1С.
В чате доступна следующая дополнительная функциональность:
- Мультичат. Запоминаются ветки разговоров. Есть возможность параллельного запроса к агенту в диалогах.
- Прикрепление файлов.
- Возможность обрезать ветку по текущему сообщению.
- Редактирование сообщения и отправка агенту. После редактирования ветка снизу обрезается.
- Копирование сообщения, удаление сообщения.
- Голосовой набор.
- Экспорт диалога в HTML или PDF.
Также в функциональность агента добавлен вывод диаграмм с интерактивными контекстными командами.
А спустя некоторое время коллеги посоветовали присмотреться к реализации чата с агентом через типовую функциональность “Обсуждений” в “Системе взаимодействия” в 1С. Сказано - сделано!
Такой вариант дает хорошие возможности по передаче контекста в агента и программированию предопределенных действий (контекстная команда) пользователя прямо в чате.
Хотя, конечно, вариант более ограниченный в разработке, чем полностью кастомный UI через «ПолеHTMLДокумента». Полагаю, актуальны будут оба варианта: будем смотреть на сценарии использования агента у заказчика.
RAG и OCR
Конечно, мы не могли обойти стороной тему RAG и связанную с ней тему OCR. Думаю, на любом предприятии, активно использующем 1С, необходимость в оцифровке, распознавании документации и семантическом поиске по ней будет как никогда актуальна. Здесь мы реализовали типовые пайплайны. Для OCR используем easyOCR. Для хранения векторов - Qdrant. Чанки готовим с помощью intfloat/multilingual-e5-base, реранкер BAAI/bge-reranker-base. Используем не только векторный поиск, но и поиск по метаданным. Взаимодействие с RAG и OCR реализовали через инструменты MCP.
Сценарии использования RAG видим следующие:
- Во-первых, обогащение контекста для самого агента. Например, когда пользователь будет спрашивать у агента, в норме ли у нас маржинальность по новому направлению, агент должен понимать, что считается «нормой» именно для нас. И эту информацию агент сможет найти в RAG-хранилище;
- Во-вторых, это работа с данными, которых просто нет в 1С. Скажем, подробные технические характеристики номенклатуры или руководства пользователя. Загрузив их в RAG, мы даём агенту возможность отвечать на вопросы вроде «подбери все насосы, которые могут работать с вязкими жидкостями и имеют сертификат для пищевой промышленности».
- Ну и в-третьих, классический сценарий использования RAG — это хранение регламентов, правил предприятия и умный семантический поиск по этой базе знаний.
Что в итоге
На текущий момент мы видим контур нашего ИИ-решения, ИИ-платформы для 1С-заказчика прежде всего из:
- MCP-сервер, реализованный на 1С:Шина или как самостоятельный сервис
- ИИ-Агент в конфигурации 1С или работающий на базе open-source решений.
- Набор инструментов и навыков, спроектированный и реализованный под бизнес-задачи заказчика.
- Опциональное RAG-хранилище.
- Опциональный OCR-сервис оцифровки и распознавания документов.
upd.
Пока готовил этот материал, была добавлена интеграция с мессенджерами (Telegram, VK Teams, Яндекс.Мессенджер).
И еще одна интересная возможность: вывели локальные скилы для вызова наружу через mcp. То есть, фактически можно подключить тот же Codex и Claude и к инструментам и к навыкам 1С. Но, разумеется, нужно понимать какие данные вы будете передавать облачным провайдерам LLM.
Сессия вопросов и ответов
1. Что с безопасностью и персональными данными?
Предполагаем использование или локальных моделей LLM или провайдеров в РФ с соответствующими разрешениями. Реализацию DataMasking (слой для удаления чувствительных данных) пока не предполагаем. Ограничения к данным баз 1С на основе типовых профилей доступа 1С реализованы.
2. Ваш агент умеет сам писать код 1С и выполнять его потом? Ведь это и даст истинную свободу агенту!
Нет. Насколько нужна истинная свобода агента в учетных системах - вопрос дискуссионный :). Но такая функциональность рассматривается, например, в части вызова отчетов СКД. Генерировать код, изменяющий данные в базе - пока мы смотрим на этот сценарий с большой осторожностью.
3. Что будет, если пользователь спросит в чате чужую зарплату?
Первое. Если на уровне инструментов и навыков не реализованы функции выборки информации по зарплате, то агент физически не сможет показать эту информацию.
Далее, если функциональность чтения таких данных предусмотрена, то следующий барьер – сами права пользователя 1С в базах 1С. Если прав нет, то функции, выполняющиеся под текущим пользователем, не отдадут лишнюю информацию. Это уже определяется на уровне ролевой модели в базах 1С.
—
На этом всё. Спасибо за внимание. Если сталкивались с такими задачами, поделитесь опытом в комментариях — будет интересно обсудить!
Вступайте в нашу телеграмм-группу Инфостарт