ИИ для 1С в 2026: что реально работает

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

За последний год спрос заметно сдвинулся. Запросы вокруг «ChatGPT для 1С» тихо угасают, зато «ИИ-агент для 1С» и «MCP-сервер для 1С» растут кратно: по нашим замерам примерно в 11 и в 5,6 раза за полгода. Дело не в моде на слова. За этим стоит технический сдвиг: от «бот отвечает текстом» к «агент читает и меняет данные внутри 1С».

Что вы заберёте из статьи:

• Чем ИИ для разработчика отличается от ИИ-агента над данными, и почему нельзя выбирать инструмент, пока не понял, какая из двух задач ваша.
• Как устроен рабочий стек разработчика: 1С:Напарник, Claude Code поверх выгрузки конфигурации в XML, локальные и облачные модели.
• Как агент обращается к 1С как к базе данных через MCP, с кодом инструмента на стороне 1С и агентом на стороне Python.
• Когда для 1С хватает облачного API, а когда данные обязаны остаться на своём сервере.

Конкуренты в топе выдачи обычно сваливают всё в один список «10 нейросетей для 1С по алфавиту». Проблема в том, что список моделей не отвечает на вопрос «что делать». ChatGPT, Claude и Qwen попадают в него все сразу, но под написание кода, под ответы по регламентам и под автосоздание документов нужны разные архитектуры, а не разные строчки в таблице. Поэтому дальше не рейтинг моделей, а две карты под две задачи.

Содержание

• Блок 1. ИИ для 1С-разработчика: как писать код быстрее
• 1С:Напарник — официальный ассистент внутри платформы
• Claude Code поверх выгрузки конфигурации в XML
• Какую модель ставить под код: облако, локаль, китайские API
• Кейс: ИИ оптимизирует запрос 1С по реальному плану
• Блок 2. ИИ-агент и 1С как база данных
• Инструмент на стороне 1С: обёртка над запросом
• Агент на стороне Python: цикл «думает, зовёт, отвечает»
• Дисциплина промпта: чтобы агент не выдумывал
• Как проверить, что модель реально работает
• Итог: два блока, две карты выбора

Блок 1. ИИ для 1С-разработчика: как писать код быстрее

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

1С:Напарник — официальный ассистент внутри платформы

Начинать стоит с него, потому что это стандарт от самой 1С и встроен он прямо в среду разработки 1С:EDT. Напарник умеет ровно то, что нужно каждый день: объяснить выделенный код, сделать ревью и предложить улучшения, сгенерировать документирующий комментарий с описанием параметров, исправить код по текстовой инструкции («добавь проверку на пустое значение»), собрать сообщение коммита по diff и продолжать код умным автокомплитом.

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

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

Claude Code поверх выгрузки конфигурации в XML

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

mcp_ones/
├── Catalogs/
│   ├── Номенклатура.xml
│   └── Партнеры.xml
├── Documents/
├── CommonModules/
│   ├── nsmcp_ОбщегоНазначенияСервер.xml
│   └── nsmcp_ОбщегоНазначенияСервер/Ext/Module.bsl
├── HTTPServices/
└── Configuration.xml

Дальше на эту папку натравливается агент-кодер вроде Claude Code. От Напарника отличие в масштабе контекста: агент видит не один файл, а всю структуру сразу, читает .bsl-модули, XML метаданных, связи между объектами. Ему можно дать задачу уровня «найди все места, где обращаемся к этому реквизиту, и добавь обработку пустого значения» или «объясни, как устроен обмен в этом расширении», и он сам обойдёт нужные файлы. По факту вы получаете разработчика, который за минуту прочитал всю конфигурацию.

Практическое правило простое. Напарник для точечной работы в EDT здесь и сейчас, Claude Code поверх выгрузки для задач, где нужно охватить всю конфигурацию или целое расширение.

Какую модель ставить под код: облако, локаль, китайские API

Модель под задачи разработки выбирают по трём осям: качество, приватность кода, цена. Разложу по вариантам, которые реально применяют.

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

Локальная модель на своём сервере. Когда код не должен покидать периметр, ставите модель у себя. В 2026-м открытые модели догнали облако достаточно, чтобы это не было жертвой качеством. Qwen3 в варианте на 27–30 миллиардов параметров крутится на одной-двух хороших видеокартах и уверенно тянет генерацию и объяснение кода. У нас в проектах агент работает как раз на Qwen3 через vLLM: модель локальная, а API у неё OpenAI-совместимый, так что клиентский код не отличается от облачного. Как поднять такой сервер, я разбираю в гайде по запуску vLLM на RTX 3090 и Tesla V100, а как выбрать под это железо, в сравнении видеокарт для LLM.

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

Универсального ответа «какая модель лучшая для 1С» тут нет, и это не отговорка. Под архитектурный рефакторинг выиграет одна модель, под быстрый разбор десятка модулей другая, под приватный контур третья. Честный способ выбрать я показываю ниже.

И это ещё не всё измерение выбора. Кроме архитектурного кода у разработчика 1С хватает более узких, но не менее частых задач: классификация номенклатуры, поиск по регламентам, разбор сканов. Там правильный ответ часто вообще не «модель побольше», а маленькая специализированная модель, которую большая LLM разметкой обучила один раз. Подробную карту «тип 1С-задачи → класс модели» и разбор паттерна дистилляции смотрите в статье «Нейросети для программиста 1С: какую выбрать под задачу».

Кейс: ИИ оптимизирует запрос 1С по реальному плану

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

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

Смысл шире одного запроса. ИИ-разработчик полезен ровно тогда, когда его выводы проверяются фактами из системы, а не принимаются на веру. Это мостик ко второму блоку, где 1С из объекта разработки превращается в источник данных для агента.

Блок 2. ИИ-агент и 1С как база данных

Второй тип задач переворачивает роль 1С. Здесь она не то, что мы редактируем, а источник живых данных, к которому агент обращается как к базе. Пользователь спрашивает на человеческом языке, «покажи заказы Видео маркета за последний месяц и есть ли просрочка», а агент сам решает, какие данные поднять из 1С, вызывает нужные инструменты и собирает ответ. Отличие от разработки в том, что агент читает и меняет боевые данные, а не код.

Идея: 1С публикует инструменты, агент их вызывает

Чтобы агент работал с 1С как с базой, ему нужны не прямые SQL-запросы, а инструменты: функции с понятным описанием, которые внутри делают запрос к базе и возвращают результат. Стандарт, который это описывает, называется MCP (Model Context Protocol). Он задаёт единый формат: инструмент описывается один раз, и его понимает любой MCP-совместимый клиент, будь то Claude, Cursor или ваш собственный агент. Раньше под каждого клиента писали свою интеграцию, теперь один сервер работает на всех.

Удобнее всего поднять этот MCP-сервер прямо внутри 1С, на HTTP-сервисах платформы, отдельным расширением. Тогда никакой прослойки: агент по HTTP дёргает сервис, сервис внутри 1С делает запрос к базе и отдаёт JSON. Как устроен такой сервер целиком, я показываю в статье «MCP-сервер для 1С: что это и как создать свой».

Инструмент на стороне 1С: обёртка над запросом

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

Инструмент.Вставить("name", "get_orders_report");
Инструмент.Вставить("description",
    "Список заказов клиентов с номерами, датами, суммами и итогом.
     Достаточно для вопросов «покажи заказы», «заказы партнёра».
     Все параметры необязательные. Если не указан период,
     возвращаются ВСЕ заказы. Не добавляй фильтр по дате,
     если пользователь явно не просит.");
Инструмент.Вставить("inputSchema", Схема); // type=object, properties: partner, period...

Само описание это уже промпт-инжиниринг. Чем точнее сказано модели, когда инструмент нужен, а когда нет, тем меньше она делает лишних вызовов. Рядом лежит функция-реализация: она включает привилегированный режим, строит запрос к регистрам и справочникам и возвращает данные в JSON. Добавление нового инструмента в расширение это дисциплинированная процедура из нескольких шагов (XML метаданных модуля, код на .bsl, регистрация модуля в конфигурации и в роутере), и пропуск любого шага ломает компиляцию. Механику я подробно расписываю в статье про MCP-сервер.

Агент на стороне Python: цикл «думает, зовёт, отвечает»

На стороне клиента агент собирается на LangGraph. Инструменты с 1С-сервера подтягиваются автоматически, их не нужно описывать в Python руками:

from langchain_mcp_adapters.client import MultiServerMCPClient

client = MultiServerMCPClient({
    "ones": {"transport": "streamable_http",
             "url": "http://ваш-сервер/ones/hs/nsmcp"}
})
tools = await client.get_tools()   # инструменты приходят прямо из 1С

Дальше сам агентный цикл. Модель получает вопрос, решает, нужен ли инструмент. Если да, вызывает его, получает данные из 1С, смотрит на них и решает: звать ещё инструмент или уже отвечать. Так образуется петля агент → инструмент → агент → … → ответ. В LangGraph она собирается буквально одной функцией:

from langgraph.prebuilt import create_react_agent
graph = create_react_agent(llm, tools, prompt=SYSTEM_PROMPT)

Модель здесь тот же Qwen3 через vLLM, что и в первом блоке, только запущенный с поддержкой вызова инструментов. Данные при этом не покидают периметр: и 1С, и модель, и агент живут на вашей инфраструктуре. Полное руководство со сборкой графа вручную и разбором каждого узла лежит в статье «ИИ-агент для 1С на LangGraph».

Дисциплина промпта: чтобы агент не выдумывал

Агент над боевыми данными опаснее чат-бота. Если он додумает несуществующую задолженность, это уже не косметическая ошибка. Поэтому системный промпт агента это не «будь полезным ассистентом», а набор жёстких правил. Вот выжимка из нашего боевого промпта:

- Отвечай ТОЛЬКО на основе данных из инструментов.
  Никогда не выдумывай и не дополняй.
- Если данных нет в ответе инструмента (адрес, способ оплаты,
  гарантия), прямо скажи «Этой информации нет в системе».
- uuid — внутренний идентификатор, не показывай его,
  но используй при вызовах. Номер заказа это НЕ uuid.

Первое правило снимает главный риск галлюцинаций: модель не имеет права говорить то, чего нет в данных. Второе учит её честно признавать пробел вместо выдумки. Третье про частую техническую грабельку, когда путают человекочитаемый номер и внутренний идентификатор. Хороший системный промпт для агента над 1С пишется не за один заход, его дошлифовывают на реальных вопросах.

Как проверить, что модель реально работает, а не выглядит умной

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

Рабочий способ это оценка через модель-судью (LLM-as-a-judge). Вместо ручной проверки вы поручаете оценку отдельной модели по чётким критериям. Для агента над данными её удобно разбить надвое: один судья смотрит, поднял ли агент релевантные данные под вопрос, второй смотрит, насколько точен итоговый ответ относительно эталона. Оценки сводятся в один нормализованный балл, по которому уже можно сравнивать модели и ловить регрессии от версии к версии.

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

Итог: два блока, две карты выбора

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

ИИ для разработчика (пишем код):

• Точечная помощь в EDT, ревью, автокомплит: 1С:Напарник, и он бесплатен до октября 2026.
• Задачи по всей конфигурации, разбор расширения: Claude Code поверх выгрузки конфигурации в XML.
• Код не должен уходить наружу: локальная модель (Qwen3 27B) на своём сервере.
• Нет своего железа, но нужен дешёвый длинный контекст: облачные Kimi или GLM.

ИИ-агент над данными (1С как база):

• Отвечать на вопросы по данным, читать заказы и остатки: агент с инструментами через MCP-сервер для 1С.
• Подключить готового клиента (Claude, Cursor) к 1С: тот же MCP-сервер, клиент любой.
• Данные не могут покидать периметр: локальная модель для агента, всё внутри.
• Собрать агента с нуля и понять механику: ИИ-агент для 1С на LangGraph.

И общее для обоих. Не верьте демке, заведите свой датасет и измеряйте. «Лучшей нейросети для 1С» не существует, есть подходящая под вашу задачу и ваш контур.

Все эти подходы, работа с кодом, RAG, агенты, MCP, локальные и облачные модели, разобраны с рабочим кодом в курсе «ИИ для 1С»: от первого чат-бота до боевого агента, который читает и меняет данные в вашей конфигурации.