Полный cookbook «Разработка в 1С на ИИ-агентах» – от теории до практики, от проблем до решений

Меня зовут Владимир Акимов, я руководитель ИТ. Мы – небольшой финтех-стартап, и ИИ для нас – не просто тренд, а необходимость, инструмент, ускоряющий нашу работу. Тем более что я не ИТ-директор, я именно ИТ-руководитель, и у меня в подчинении совсем небольшая команда системных администраторов, а в целом ИТ-ресурсы в компании довольно ограничены. Поэтому ИИ для нас – отличный вариант.

Меню. Теория и инструменты, практика и результат

Сегодня мы рассмотрим полный рецепт: как готовить разработку в 1С с ИИ-агентами. Не абстрактные обещания, а конкретный рабочий процесс, который можно забрать и использовать. Я расскажу:

• Без каких двух главных ингредиентов ничего не получится.

• Как избежать типичных кулинарных ошибок, если что-то пошло не так.

• Как соблюдать технику готовки и превратить сырого ИИ-агента в изысканное блюдо, которое понимает специфику 1С.

• Какие инструменты использовать и где их взять (конкретные репозитории).

• Как организовать процесс «готовки» с документацией и тестами: практический рецепт на примере реальной задачи.

• Быстрый старт: с чего начать готовить уже завтра.

• Выход блюда – реальная эффективность без розовых очков.

Два кита: Обратная связь + Контекст

Вся работа с ИИ стоит на двух китах – это обратная связь и контекст. И неважно, где это используется – для 1С или нет.

• Под циклом обратной связи подразумевается, что агент должен видеть результат.

• А контекст важен, чтобы агент максимально понимал поставленную задачу.

Если убрать любой из этих ключевых ингредиентов, блюдо не выйдет, ИИ-агент работать не будет. Получится все что угодно, кроме результата.

Что касается обратной связи.

Агент может предполагать, что будет правильно, но он не может этого проверить. А обратная связь для него – это возможность посмотреть результат. Поэтому, когда он получает информацию об ошибке, он понимает, что ему нужно исправить.

Думаете, LLM глупая? Конечно, нет. Разве кто-нибудь пишет код с первого раза без тестов? Вот и она не умеет.

Второй огромный кит – это контекст.

Контекст состоит из трех слоев:

• Слой 1 – это ваши промты, то, что вы пишете в браузерном окошке, когда общаетесь с ИИ-шками.

• Слой 2 – это знание рецептуры. По сути, это правила, как готовить, как делать, как что выполняется.

• Слой 3 – это правила вашей кухни. У каждого из нас своя кухня, мы по-своему работаем. Свои правила ведения разработки. Поэтому ИИ должен все это знать.

Важно понимать, что у агента нет долгосрочной памяти. Каждая сессия для него – это как первое знакомство. Он ничего о вас не помнит. Поэтому контекст необходимо передавать явно. Именно он объясняет модели, что нужно сделать и как именно это должно быть сделано.

Но ИИ, конечно, далеко не идеальный помощник.

Он любит упрощать задачи, особенно сложные, если их за одно действие выполнить не получается.

Он может нахалтурить – пройтись по верхам и отчитаться, что все сделал, а на самом деле наколотить затычек.

А еще он может вас неправильно понять. Причем это справедливо и для людей. Мы тоже друг друга не всегда понимаем, хотя и говорим одни и те же слова.

На скриншоте – прекрасный пример того, как ИИ может халтурить.

Обратите внимание, что фазы 5 и 6 не доделаны, фаза 5 реализована на 85%, но агент нам радостно сообщает, что проект завершен успешно.

Мы просим ИИ завершить работу на 100%. Но он просто исправляет процент выполнения, утверждая, что оставшиеся 5% use-case для нас не важны.

Как с этим бороться?

Один из ответов – это SDD, Spec-Driven Development. Звучит непонятно, но расшифровывается как разработка по спецификации, и 1С-ники с этим работают всю жизнь. Все же знают, что без нормального ТЗ и результат будет такой себе. Вот и здесь то же самое – пока вы не опишете задачу подробно, ИИ не будет понимать, что ему делать.

Поэтому прорабатывайте постановку задачи вместе с ИИ. Задавайте ему вопросы – как он это понял, и что он понял, а что – нет. Просите его задать вопросы вам. Используйте одну модель, чтобы собрать требования в документ, а потом попросите другую модель критически оценить результат. Попутно вы получите бесплатную документацию по каждой задаче – просто как часть процесса.

Следующий вариант – это Test-Driven Development. Для работы с ИИ этот подход просто жизненно необходим, потому что именно он как раз и обеспечивает тот самый цикл обратной связи.

• Вы сначала написали спецификацию.

• Потом вы по ней отдельно написали тесты, которые позволят проверить и убедиться, что ИИ сделал ровно то, что вы просили.

• После того как ИИ написал код, вы эти тесты выполняете.

• ИИ видит, что тесты не проходят, и идет переделывать.

• И только после того, как все тесты будут пройдены, он вернется к вам с ответом, что делать дальше.

Agent-based 1C Developer Framework. Open Source

А теперь от теории перейдем к практике и поговорим о том, как запустить агентную разработку для 1С.

В ходе самостоятельного изучения этого вопроса я собрал Agent-based 1C Developer Framework – open source-фреймворк, который объединяет готовые инструменты, MCP-серверы и мои собственные наработки для организации полного цикла агентной разработки на 1С. Сейчас немного расскажу, как он устроен и что умеет.

Первое, с чем сталкиваешься при попытке применить ИИ для разработки на 1С – это отсутствие у платформы готовых инструментов, через которые агент мог бы полноценно взаимодействовать со средой разработки и выполнения. Агент не может получить логи. Агент не может запустить тесты и увидеть их результат. Агент вообще мало что может без дополнительных инструментов.

Здесь на помощь приходят MCP-серверы (MCP расшифровывается как Model Context Protocol), которые предоставляют агенту дополнительные возможности.

Для работы с фреймворком нет жесткой привязки к конкретной среде или ИИ-агенту. В качестве IDE можно использовать, например, Cursor или VS Code, а в качестве кодинг-агентов – Claude Code, Codex CLI, Gemini CLI и другие совместимые решения. У каждого варианта есть свои плюсы и минусы, поэтому конкретную связку выбирайте под свои задачи самостоятельно.

Напомню, что для эффективной работы ИИ нужно, чтобы он понимал контекст.

А поскольку изначально агент про 1С мало что знает, ему необходимо получить актуальную справку по синтаксису вашей версии платформы. За это отвечает MCP-сервер из репозитория BSL Platform Context.

Второй полезный MCP-сервер – это 1С.Напарник Прокси. Он позволяет подключить к агенту сервис 1С:Напарник и использовать его как дополнительный источник специализированных знаний об устройстве платформы и типовых решений. Для работы потребуется ваш персональный токен доступа к сервису 1С:Напарник.

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

Еще один инструмент – ИТС-скраппер.

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

Зачем вообще что-то выгружать локально? Для простых вопросов агенту действительно целесообразно точечно обратиться к 1С:Напарнику и получить нужную информацию. Но в сложных задачах – например, при работе с технологическим журналом – иногда полезнее сразу выдать для ИИ полный объем документации, чтобы он сам собрал весь нужный ему контекст. Для этого достаточно добавить в каталог проекта документы с нужными блоками знаний: описание конфигурации, БСП, тех. журнал и т.д.

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

Одна из ключевых составляющих такой обратной связи, без которой у нас бы ничего не получилось – это юнит-тесты. MCP YAxUnit Test Runner позволяет агенту запускать тесты YAxUnit непосредственно из среды разработки. Перед запуском сервер анализирует изменения в исходниках и при необходимости собирает конфигурацию, обновляя информационную базу. После этого запускаются тесты, а их результаты возвращаются агенту, который может на основании этой обратной связи исправить найденные ошибки.

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

Второй инструмент для получения обратной связи – это MCP Log Checker.

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

Следующий инструмент – плагин к VS Code, который добавляет в IDE удобный просмотр дерева метаданных, Meta Viewer. Причем его можно также использовать в Cursor, Antigravity, Kiro и других IDE, которые фактически являются форками VS Code.

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

И последний, один из самых функциональных инструментов – MCP-Server 1C. Он дает агенту доступ к метаданным конфигурации 1С, благодаря чему тот может понять структуру конкретной информационной базы: какие в ней есть справочники, документы и другие объекты. Особенно это важно при работе с нетиповыми конфигурациями, о которых модель заранее ничего не знает. При необходимости функциональность можно расширять собственными MCP-инструментами. Кроме того, MCP-сервер позволяет агенту выполнять запросы непосредственно к данным информационной базы.

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

А дальше у нас иногда может произойти вот так. Когда мы работаем, работаем, работаем, а потом бац, и пропал диск D. Неприятная ситуация.

Поэтому важная часть – это работа в песочнице. Агент должен жить в песочнице, и никак иначе.

Я таким образом расстался с 10-летним архивом фото на личном компе. Жена чуть не убила. Но, в общем-то, это был хороший опыт, потому что после этого я собрал песочницу.

Плюс песочницы – можно не следить за агентом, не проверять каждый его шаг, каждую команду. Вы его просто запускаете, и все. Даже если он сломает песочницу, новая разворачивается за 5 минут.

Теперь посмотрим, из чего складывается контекст агента:

• Skills (навыки) – практические инструкции, которые объясняют агенту, как выполнять определенные задачи, какие шаги пройти, какие инструменты использовать и как с ними работать.

• Rules (правила) – обязательные требования и ограничения, которые определяют, что агент должен или не должен делать и в каких ситуациях.

• Tools – инструменты, предоставляемые агенту MCP-серверами. Информация о них также занимает место в контексте: агент должен знать, какие возможности у него есть, и как к ним обращаться.

• Prompts (промпты) – ваши непосредственные инструкции, которые задают текущую задачу.

И здесь возникает еще одна проблема – ограниченность контекстного окна у агента. Ему, как и человеку, нельзя запихать в голову слишком много информации.

Поэтому контекстом нужно управлять.

С одной стороны, в нем должна оставаться вся информация, которая необходима для выполнения задачи.

С другой – нельзя забивать его целиком правилами и документацией, потому что агенту еще нужно оставлять свободное место в контекстном окне, чтобы работать с вашими задачами.

Чтобы справиться с проблемой ограниченности контекста, нужно декомпозировать задачи, разделять роли и использовать сабагентов. До появления нормальной поддержки сабагентов было гораздо сложнее – приходилось бороться за место в контексте.

Сейчас можно организовать так, чтобы у вас был:

• Один агент-оркестратор, который не пытается делать всю работу сам, а хранит в контексте только состояние процесса и результаты отдельных этапов.

• Один агент, который проводит исследование проекта – готовит спецификацию и техническое задание.

• Другой агент пишет тесты.

• Третий пишет код.

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

В результате ваша кухня разработки начинает выглядеть примерно так, как на слайде.

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

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

Вайб-кодинг – это когда вы сказали: «Сделай», получили ответ и пошли дальше.

А в агентной разработке ИИ просто помогает вам выполнять работу, но ответственность за конечный результат остается на вас. Потому что если агент напишет ерунду, и это попадет в продуктив, заказчику вряд ли понравится объяснение: «Извините, это ИИ ошибся». Отвечать все равно будете вы.

На выходе вы получаете достаточно большое ускорение, особенно в рутинных задачах. Конечно, не в 100 раз, как на картинке. Но ускориться в 5 раз по моим собственным оценкам – наверное, легко.

Особенно выгодно применять ИИ для проектов, связанных с интеграциями: когда у вас есть два контракта – контракт с одной стороной и контракт с другой – и вам нужно их свести и описать.

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

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

Еще сильнее эффект заметен на нетиповых задачах по работе с Excel или Word.

Для разработчиков 1С это далеко не самые привычные технологии – каждый раз приходится вспоминать, как устроен Word, разбираться с его COM-объектом, искать нужный синтаксис и так далее.

Для ИИ такой проблемы нет. Ему не принципиально, на каком языке писать. Он прекрасно напишет для вас код на 1С, который сможет работать с Excel или Word, сделает табличку, документ и все что угодно.

Когда вы начинаете работать с ИИ, процессы разработки меняются:

• Если раньше вы как тимлид ставили задачу сотрудникам, то теперь вы как тимлид ставите эту задачу агенту.

• Если раньше тимлид или технический архитектор проводил код-ревью результата, написанного обычным человеком, то теперь тимлид или технический архитектор проводит код-ревью результата, полученного от агента.

• При этом архитектура никуда не исчезает. Вам все равно нужно принимать ключевые технические решения и нести ответственность за результат – такие вещи агенту отдавать не стоит.

• Но появляется новая роль – архитектор контекста. Вам нужно управлять тем, что именно должен знать агент – какие правила ему передать, какие документы положить в контекст, какие инструменты подключить.

Вместо заключения: как ИИ готовил доклад про ИИ

Поскольку доклад про ИИ, было бы странно не привлечь к его подготовке сами модели. Что я, собственно, и сделал.

• Все иллюстрации были подготовлены с помощью Nano Banana Pro.

• Я написал только черновой вариант в виде потока мысли и вбросил его в Claude Opus 4.5, а он мне весь текст структурировал и разбил по слайдам.

• Потом я прочитал и подкорректировал получившиеся тезисы, и отдал их GPT-5.2 вместе с шаблоном презентации. Первый результат, который получился у ИИ, был ужасным – текстовые блоки наезжали друг на друга и выходили за рамки страниц. Поэтому я попросил его сохранить слайды как изображения, самому посмотреть, что получилось и исправить это. В итоге буквально через пару итераций презентация была готова. Причем такой принцип обратной связи одинаково хорошо работает и для презентаций, и для разработки, и практически для любой другой задачи. Если модель может увидеть результат собственной работы и сравнить его с ожидаемым – качество резко повышается.

• Отдельное спасибо сообществу «Нейросельди в жёлтой банке (1С)». Когда я сам начинал разбираться в ИИ, это сообщество оказалось для меня одним из самых продуктивных, где могут и подсказать, и помочь. Только не приходите туда продавать свои продукты – сообщество посвящено именно open source.

Фреймворк выложен в репозитории на GitHub – там навыки, правила, инструменты и даже чуть больше.

Я добавил туда отдельный обучающий раздел, который рассказывает про основы работы с агентами и про контекст – в общем, про все, что нужно знать, чтобы работать с искусственным интеллектом. Подключайтесь, присоединяйтесь.

Самое важное для развития агентной разработки – это качественные навыки и инструкции для агентов: как выполнять определенные задачи, что делать, что не делать, какие подходы использовать.

Конечно, агенты уже сами умеют писать для себя такие инструкции, но у них получается плохо: вода водяная, мыло мыльное. Написанное человеком работает намного лучше.

P.S. Статья написана по материалам, актуальным на начало весны 2026 г. Попробую немного актуализировать, что изменилось за прошедшее время (на конец августа 2026 г.):

1. YaxUnit Runner переработан и заменен v8-runner - он теперь умеет работать с YAxUnit, Vanessa и выполнять операции с базой (выгрузка/загрузка/обновление)

2. mcp_devkit + 1c_mcp + web-socket - получился v8-sm инструмент, обеспечивающий ИИ-агенту доступ и к серверному и к клиентскому контексту (как исполнения, так и получения данных из клиентской сессии).

3. 1С:Напарник стал предупреждать, что его использование Вне контура EDT противоречит лицензионному соглашению.

4. Фронтирные модели стали страдать овер-инжинирингом

5. Для vanessa вышел mcp, упрощающий с ней работу

6. Вышли плагины к Codex / Claude / VSCode с наборами навыков и инструментов. Удобно для старта, но меньше гибкости в выборе отдельных инструментов.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.