Короткий ответ
Дорабатывать конфигурацию не нужно. В платформе 1С есть стандартный интерфейс OData — готовый REST поверх базы, включается галочкой при публикации на веб-сервере. Поверх него ставится MCP-обёртка, и агент видит данные как набор разрешённых операций. Права при этом остаются теми же, что у пользователя 1С.
Три способа связать
Через OData — быстрее всего. Включается в Конфигураторе: Администрирование → Публикация на веб-сервере → галочка «Публиковать стандартный интерфейс OData». Нужен веб-сервер, IIS или Apache.
Через OData можно читать, создавать, изменять и удалять данные. Но не всё: недоступны отчёты, команды, критерии отбора, регламентные задания, внешние источники данных, пользователи и журнал регистрации. Если сценарий упирается в отчёт — понадобится HTTP-сервис.
Через HTTP-сервисы — когда нужна своя логика: сложные выборки, запись с проверками, бизнес-правила. Больше работы, полный контроль.
Через обмен файлами — самый безопасный: агент кладёт данные в папку, 1С забирает по расписанию. Подходит, когда не нужен реальный масштаб времени.
Подробный разбор всех трёх — в статье про MCP-сервер для 1С.
Права: что важно понять
OData не вводит собственную модель прав. Доступ регулируется правами того пользователя 1С, под которым выполняется запрос. Те же роли и ограничения, что в обычном сеансе, действуют и через REST.
Это удобно и это же главный риск: дадите агенту учётку с широкими правами — он получит всё, что она позволяет.
Правила:
- отдельный технический пользователь, не администратор и не чья-то личная учётка;
- публиковать только нужные виды объектов, планы обмена не открывать вовсе;
- чтение по умолчанию, запись — под конкретную задачу;
- все действия видны в журнале.
Что это даёт
Сценарии, ради которых обычно и затевается:
- вопросы по данным обычным языком вместо построения отчётов;
- сверка документов с учётной системой, расхождения отдельным списком;
- подготовка первички — агент разбирает входящие и готовит к загрузке;
- уведомления по событиям: просроченная оплата, залежавшийся остаток.
Смежная тема — ЭДО: агент сверяет входящие документы с 1С, но подпись остаётся за человеком.
1С:EDT, репозитории и разработка
Отдельный пласт задач, который ищут не реже, чем связку с учётными данными: подключить агента не к базе, а к самой разработке на 1С.
1С:EDT. Среда разработки хранит конфигурацию в файлах, и это меняет дело: агент работает с ними как с обычным кодом — читает, ищет, предлагает правки. Никакого OData здесь не нужно, достаточно доступа к каталогу проекта.
Репозитории. Если конфигурация лежит в Git, подключается стандартный MCP-сервер для работы с репозиториями — тот же, что для любого другого проекта. Агент видит историю, ветки, различия между версиями.
Разработка с агентом. Практическая связка выглядит так: файлы конфигурации из
EDT плюс доступ к тестовой базе через OData. Первое даёт агенту понимание кода,
второе — возможность проверить, что получилось, на реальных данных. Правила
проекта при этом стоит задать файлом AGENTS.md, чтобы не
объяснять соглашения при каждой задаче.
Готовые серверы. Отдельные MCP-серверы под 1С выкладывают в открытый доступ. Прежде чем ставить, действует то же правило, что и для любого чужого сервера: посмотреть, какие операции он открывает и под каким пользователем работает.
Вайб-кодинг в 1С: что реально работает
Запрос «вайб-кодинг 1С» вырос вместе с модой на вайб-кодинг вообще, но у платформы своя специфика, и честная картина такая.
Что работает уже сейчас. Конфигурация в файлах EDT — это код, и терминальные агенты вроде Claude Code работают с ним как с любым другим: находят нужный модуль по описанию задачи, пишут процедуры на встроенном языке, правят формы в XML. Русскоязычный встроенный язык 1С моделям знаком — хуже, чем Python, но достаточно для рутины: типовые обработки, заполнение по образцу, разбор чужого кода.
Где всё спотыкается. Агент не запустит конфигуратор и не проверит своё творение в предприятии — цикл «написал → проверил → поправил», который делает вайб-кодинг рабочим на обычных языках, в 1С разомкнут. Проверка остаётся на разработчике. Частично это лечится тестовой базой через OData (агент хотя бы сверяет данные) и статической проверкой синтаксиса.
Практический вывод: вайб-кодинг в 1С — это «агент пишет, человек прогоняет», а не полная автономия. Для типовой рутины это всё равно кратный выигрыш времени. Правила проекта — в AGENTS.md, русский язык ответов у Claude Code настраивается одной строкой.
Шесть серверов экосистемы с проверяемыми цифрами — звёзды, лицензии, даты последних изменений — собраны в отдельном разборе вайб-кодинга в 1С.
Чего не делать
- Открывать через OData всю конфигурацию.
- Использовать существующую учётную запись — не отличите действия агента от действий сотрудника.
- Публиковать базу наружу без ограничения по сети. OData поверх веб-сервера — это открытый HTTP-эндпоинт.
- Доверять агенту цифры без сверки. Он уверенно выдумывает, когда данных не хватает.