ИИ в 1С за последний год перестал быть экспериментом: поисковый спрос на тему вырос примерно вчетверо, а 1С-разработчики всё чаще спрашивают, какая нейросеть лучше работает с 1С, как внедрить ИИ-агента в разработку и можно ли автоматизировать рутину без облака.
В этой статье я, показываю свой ответ на эти вопросы — проект "Harness 1С" обвязку, которая превращает кодового AI-агента в полноценного разработчика 1С. Материал собран из трёх частей серии: MCP-сервер с контекстной подсказкой, MCP-сервер поиска по метаданным конфигурации и оркестратор Symphony с трекером задач в GitLab.
Если коротко, цель Harness 1С — довести автоматизацию разработки 1С близко к 100%: вы ставите задачу и уходите пить кофе, а анализ, планирование, написание кода, тестирование и merge request берёт на себя AI-агент под контролем человека на ключевых этапах.
Почему нейросети плохо знают 1С и при чём тут MCP-сервер
Главная проблема разработки 1С с помощью ИИ в том, что практически любая модель почти не знает языка 1С. Топовые облачные модели — Claude, кодовые модели OpenAI — что-то про 1С знают, но этих данных недостаточно: модель начинает придумывать несуществующие методы и функции. Значит, агенту нужно подавать качественный контекст — точную справку по объектам, методам и свойствам платформы.
Именно эту задачу решает первый кубик системы — MCP-сервер с контекстной подсказкой 1С для кодового агента. Я взял с одного из открытых MCP-серверов на GitHub только механизм загрузки справки 1С, а поиск переписал полностью под свои требования. Причина простая, готовый сервер отдавал в контекст огромные объёмы текста. Для мощной облачной модели это терпимо, она переварит и запустит суб-агентов. Но я делаю ставку на автономную разработку, и вот почему это важно:
- в любой момент могут отключить интернет — система должна продолжать работать
- исходники не должны утекать в облако
- локальной модели нужен максимально сжатый, точный контекст
Весь стенд работает локально. В первой версии — на двух видеокартах 5070 Ti с моделью Qwen3 на 27 млрд параметров, контекст 64 000 токенов. Позже я перешёл на более качественное квантование (Unsloth Qwen3, MTP, UD-Q8_K_XL) на связке 3090 + 5070 Ti с контекстом 65 000 токенов — это заметно ближе к оригинальной модели по качеству, чем раннее квантование NVFP4, которое, как справедливо заметили в комментариях, ощутимо уступает.
Как работает семантический поиск справки
На отладочном стенде видно, какие инструменты вызывает модель. Когда я прошу "обработку загрузки текстового файла", агент вызывает инструмент research, тот под капотом обрабатывает запрос и возвращает ровно нужный контекст: тип "Текстовый документ", методы чтения и записи файла, методы работы со строками, нужные свойства — всё, что необходимо для разработки. На модели в 27 млрд параметров это отрабатывает быстро (70–100 токенов в секунду) и точно.
На более сложном запросе — "напиши функцию отправки POST-запроса к HTTPS-сервису с обработкой исключений и логированием в журнале", агент подтягивает уже больше контекста (HTTP-соединение, HTTP-запрос и ответ, работу с защищённым соединением, запись журнала регистрации). Итоговая функция получается корректной: попытка/исключение, защищённое соединение, Content-Type application/json, тело в кодировке UTF-8, запись ошибки в журнал. Для полностью локальной модели результат отличный — и это без подключения к Claude Code, где качество будет ещё выше.
MCP-сервер поиска по метаданным конфигурации 1С
Справка по платформе — это половина дела. Вторая половина — знание конкретной конфигурации: какие справочники, реквизиты и табличные части в ней есть. Claude Code с облачной моделью решает это по-своему — пробегает субагентами по всей конфигурации и расширениям и собирает контекст. Но для автономной разработки на локальной модели нужен экономный инструмент, и им стал второй MCP-сервер — поиск по метаданным конфигурации 1С.
К уже готовому семантическому поиску справки (research) добавились новые инструменты: поиск по конфигурации и сборка готового контекста под задачу разработки. Всё это работает через графовую базу, где проиндексированы и типовая конфигурация, и моё расширение.
Как это выглядит на практике:
- Прошу доработать справочник "Масла" и добавить реквизиты. Инструмент видит, что каталога "Масла" нет, и предлагает похожие варианты
- Уточняю, нужен справочник "Моторные масла". Практически мгновенно агент вытаскивает все реквизиты, их типы, ссылки на ссылочные типы и перечисления, табличные части, метаданные и модули
- Прошу справочник "Бренды", которого в конфигурации нет. Агент находит похожий справочник "Марки", у которого в синониме указано "Бренды", и предлагает решение — в том числе из основной конфигурации
Результат: кодовый агент точно знает, в какой XML-файл идти и с каким объектом работать. Такой инструмент особенно ценен именно в автономном режиме, когда нет огромного лимита токенов по подписке, чтобы перелопачивать десятки тысяч строк кода крупной конфигурации вроде ERP.
Оркестратор Symphony и трекер задач в GitLab
Два MCP-сервера дают агенту знания. Но чтобы это стало системой автоматизации разработки 1С, нужен дирижёр — оркестратор Symphony. Это сердце управления всеми агентами и задачами. Он решает три ключевые задачи:
- мониторит трекер задач и реагирует на смену статусов
- запускает нужного AI-агента на конкретную задачу и ведёт её по этапам
- отправляет уведомления о ходе работы через отдельное приложение
Трекером служит локально развёрнутый GitLab: в репозиторий выгружено расширение 1С, а задачи ведутся через доску со статусами. У Symphony есть простой веб-интерфейс, где видно, какие агенты запущены и какую задачу каждый обрабатывает.
Уведомления в приложении на Flutter
Отдельный канал обратной связи — приложение на Flutter, работающее и на десктопе, и на телефоне. Логика такая, поставили задачу, занялись делами, а на телефон приходят уведомления по каждому шагу — "задача принята в работу", "агент составил план", "ждёт вашей проверки", "изменения влиты в основную ветку". В планах — открывать задачу и править план прямо из уведомления, не заходя в полноценный трекер.
Доска задач: как статусы управляют агентом
Ключевая идея — перемещение карточки по доске управляет поведением агента:
- Open — только что созданная задача
- Backlog — агент не работает, здесь можно подумать, разбить или переформулировать
- To Do — сигнал агенту взять задачу в работу
- Plan Review — агент составил план, его нужно проверить
- In Progress — план утверждён, идёт разработка
- Human Review — работа сделана, ждёт финальной проверки
Ещё один важный механизм — выбор исполнителя метками задачи. При постановке указывается агент: Claude (Claude Code), а в планах — OpenCode и Kimi. Это позволяет распределять модели по этапам, сильная модель на постановку и план, более простая и дешёвая (в том числе локальная) — на реализацию, когда ТЗ уже детально проработано.
Полный цикл разработки на живом примере
Соберём всё вместе на простой задаче: "изменить синоним справочника Магазины на Магазины версия 3".
- Постановка. Задача создаётся, переносится в Backlog — оркестратор начинает её мониторить. Перевод в To Do запускает агента, приходит уведомление "принята в работу".
- Планирование. Агент составляет детальный план: находит единственное место хранения синонима (XML-файл каталога магазина), планирует изменить нужное значение, проверить целостность структуры XML и прогнать поиск. Задача уходит в Plan Review.
- Правка плана. Я передумал и прямо в комментарии пишу "давай изменим на версия 4". Оркестратор реагирует на комментарий, агент полностью перерабатывает план с учётом замечания. Важно: на этом этапе не подключены ни MCP, ни скиллы — работает "чистый" Claude Code, и всё равно корректно находит нужное место.
- Разработка. Утверждаю план, задача переходит в In Progress. Агент выполняет работу, в веб-интерфейсе видно используемые инструменты.
- Проверка и слияние. Приходит "ждёт вашей проверки", задача в Human Review. Бот Symphony делает merge request: в XML-файле каталога магазина "магазин Авито" заменён на "магазин версия 4". Соглашаюсь, закрываю задачу — приходит уведомление о слиянии в основную ветку.
Отдельный принцип — разработка по веткам: агент не трогает основной код, работает в отдельной ветке, а слияние происходит только после утверждения человеком.
Зачем нужен контроль плана человеком
Да, конкретно эту задачу быстрее сделать руками — открыть конфигуратор и поправить синоним. Смысл раскрывается на масштабе, большая конфигурация и большой поток задач. Тренд — максимально отдавать разработку агентам, вплоть до отдельного агента-ревьюера. Но этап проверки плана человеком я оставляю осознанно, хочу видеть и утверждать план до начала разработки. Это разумный баланс автоматизации и контроля.
Куда движется Harness 1С
Дорожная карта объясняет, ради чего вся обвязка:
- Разработка на основе документации. Раз в день обновляется документация по внешнему API, при изменениях агент сам заводит задачи, ставит их исполнителю и сливает результат в нужную ветку.
- Ветки под конфигурации. Тиражное решение рассчитано на разные конфигурации, и каждая ветка — отдельное решение, отдельный агент отвечает за слияние по всем веткам.
- Автосборка и прогон расширений. После слияния скрипт собирает изменения, выгружает расширение и загружает его в каждую тестовую базу для прогона.
- Скиллы и MCP. К агенту подключаются скиллы и MCP, чтобы Claude знал структуру XML-файлов, документацию, строение конфигурации и расширения, связи метаданных, а также правила и работу с командной строкой конфигуратора (загрузка/выгрузка).
Итоговая цель — убрать с человека весь рутинный цикл, мониторинг документации, постановку задач, разработку, тестирование, релизы по всем конфигурациям и перезаливку изменений. Останется контроль плана — всё остальное делает агент.
Выводы: ИИ в 1С уже работает
Проект Harness 1С показывает практичный путь внедрения ИИ в реальную 1С-разработку — не абстрактную демонстрацию нейросетей, а рабочий конвейер:
- MCP-сервер для 1С решает главную проблему — незнание моделью языка 1С и конкретной конфигурации, отдавая агенту сжатый и точный контекст.
- Автономность на локальной нейросети (Qwen3) даёт независимость от облака, конфиденциальность исходников и работу без интернета.
- Оркестратор Symphony и GitLab превращают набор инструментов в систему: статусы задач управляют агентом, а метки выбирают исполнителя (Claude Code, OpenCode, Kimi).
- Человек остаётся в контуре на этапе утверждения плана — остальное берёт на себя агент, вплоть до merge request.
ИИ-агент для 1С — это уже не будущее, а рабочий инструмент. Спрос на тему растёт, и такой harness — способ автоматизировать разработку тиражного решения близко к 100%, оставаясь при этом полностью автономным.