Неделю назад у меня не было ничего, кроме идеи: пусть агент на базе LLM сам разбирается в платформе 1С — читает метаданные, пишет код, отлаживает его, документирует себя и растёт дальше без моего участия в рутине. Через семь дней агент — назовём его тут просто робот — исследовал структуру базы, поднял OData-интеграцию, научился ставить точки останова через собственный отладчик и написал тысячи строк рабочего BSL-кода. Я за это время ни разу не открыл конфигуратор.
Ну ладно. Открыл только для того, чтобы "посмотреть". Интересно же, что там нагородил агент. Я был приятно удивлен
[Тут будут ссылки на статьи с подробностями, когда я их напишу]
С чего всё началось
Первая неделя — это не «поговорили с чатом и получили скрипт». Это полноценный инженерный спринт: 160 коммитов в ядре агента и ещё 230 в MCP-инструменте, через который он управляет 1С. Робот не просто генерировал код по запросу — он исследовал платформу как новый сотрудник в первый рабочий день: разобрался, как устроены объекты метаданных, нашёл, как ходить в базу через OData без ручного парсинга полной EDMX-схемы (это почти 800 объектов метаданных — вручную никто в здравом уме туда не полезет), и построил себе кэш документации по ИТС и OneScript, чтобы не гадать на пустом месте, а сверяться со стандартом.
К концу недели у него был целый инструментальный пояс:
- 🔌 рабочий OData-слой поверх боевой конфигурации — с поиском объектов без полного парсинга схемы и с тулом «найди Ref_Key по бизнес-полю» вместо самодельного питона поверх фильтров;
- 🐞 собственный отладчик — рабочий протокол RDBG, который сам себе починиL9;л (об этом ниже) и подключение через внешнюю обработку, без танцев с конфигуратором;
- 📚 база знаний по BSL и кэшированная документация ИТС/OneScript — чтобы не выдумывать API, а сверяться с фактами;
- 🗂 задача-трекер (tasksDB) — общая база задач, куда робот сам пишет, что сделал, что заблокировано и почему;
- 🧳 механизм передачи файлов между агентом и сервером 1С — вместо того чтобы гонять абсолютные серверные пути и содержимое файлов через диалог, тулы
processor_push_file/processor_pull_fileкладут и забирают файлы напрямую, не засоряя контекст; - MCP-сервер, спроектированный так, чтобы экономить токены и общаться с инструментарием 1с проверенным способом
- 🧬 базовая функциональность добавления и модификации метаданных прямо руками агента — и это не абстракция ради красивого слова: модули объектов, общие модули, константы, подсистемы, макеты, внешние обработки — всё это агент умеет создавать и дорабатывать сам, без ручного похода в конфигуратор. Одна команда с параметрами со стороны ИИ-агента — и на выходе новая структура метаданных, которая тут же загружается в базу;
- 🧭 сценарий оркестрации, который держит весь этот процесс в рамках: планирование, исследование, контроль результата, документирование, проверка кода на соответствие стандартам — с блоками обратной связи и повторными попытками там, где с первого раза не получилось.
Большая часть кода — это BSL, код самой платформы 1С: модули расширений, обработчики, обёртки для OData, генераторы XML-разметки для табличных документов. Я лично оцениваю объём написанного за неделю в 11 000 строк — часть этого живёт прямо в конфигурации боевой базы как объекты метаданных, а не только в текстовых файлах в git, поэтому точный подсчёт «построчно» тут не такая простая штука, как для обычного репозитория на Python. Но по ощущениям от объёма проделанной работы — это она и есть, 11 тысяч строк рабочего, протестированного кода.
Отдельно стоит сказать про OData — за неделю это была самая заметная стройка, но далеко не единственная. Просто она хорошо иллюстрируется: было «руками через фильтры и парсинг полной EDMX-схемы почти на 800 объектов метаданных», стало «тул на конкретный вопрос "найди мне Ref_Key вот этого элемента"». Остальной инструментарий рос рядом, тише, но не менее плотно.
Где робот путался — и я включался как старший товарищ
Самое интересное — не там, где всё прошло гладко. Самое интересное там, где агент упёрся в стену и его пришлось за руку выводить обратно на дорогу.
История 1. «Пять мест» оказались шестнадцатью
Была задача — научить инструмент самостоятельно определять версию платформы 1С вместо того, чтобы полагаться на захардкоженный путь (это, кстати, было прямое замечание BSL-анализатора — хардкод путей он не любит). В постановке задачи было явно сказано: правки нужны в пяти местах. Робот начал копать — и обнаружил, что реальных мест на самом деле не пять, а шестнадцать: девять в одном модуле расширения, ещё два в другом, плюс исходные пять.
Вот тут он повёл себя как хороший инженер, а не как безбашенный автомат: не стал доделывать всё «как получится», а остановился и написал прямым текстом — объём задачи вырос почти втрое, нужно решение человека, продолжать нельзя, пока не подтверждено. Я подтвердил — расширять объём. Дальше агент нашёл ещё и реальный баг деплоя (несовпадение числа параметров при вызове, которое не поймал даже статический анализ), починил и его, и довёл задачу до готового состояния за четыре шага. Отличный пример того, зачем вообще нужен «старший товарищ» рядом: не переделывать за агента, а вовремя сказать «да, продолжай» или «нет, стоп».
История 2. «Эти замечания BSL-анализатора не мои»
Тут робот повёл себя как студент, которого отчитывают за чужую парту. При закрытии одной из задач субагент увидел, что в коде остались предупреждения BSL-анализатора, и решил, что это нормально — ведь эти замечания были «не от меня», они были в коде до того, как он взялся за задачу. Формально логично, по существу — нет: код с любыми незакрытыми замечаниями BSL-анализатора не считается готовым, вне зависимости от того, кто их туда внёс.
Пришлось вмешаться и явно, жёстко зафиксировать правило: «чистый прогон» — это ноль замечаний, точка, без исключений «эти не мои». Правило теперь прописано в регламенте оркестрации агента, чтобы больше не возникало соблазна закрыть глаза на чужой мусор в коде.
История 3. Монопольная блокировка на весь лес ради одной ветки
Ещё один забавный момент саморегуляции: у агента было правило «никогда не открывать два конфигуратора одновременно», введённое, чтобы избежать конфликтов записи в базу. Проблема в том, что робот трактовал это правило слишком буквально — блокировал вообще ЛЮБУЮ параллельную работу с базой целиком, хотя монопольный доступ реально нужен только для конкретных операций в конфигураторе, а не для всего вообще. Это тормозило параллельную работу нескольких подагентов там, где реального конфликта не было. Правило сейчас пересматривается — конкретная точная граница «где реально нужна монополия» формулируется отдельной задачей.
История 4. Ложный тупик, придуманный самим агентом
Задача была прикладная — собрать макет табличного документа (SpreadsheetDocument) как внешнюю обработку. Агент собирал .epf из BSL-модуля, получал битые символы в исходнике и добросовестно перепробовал два варианта кодировки — оба падали по-разному. После этого он остановился и записал в задачу вывод: похоже на дефект собственного тула сборки .epf. Разумно, но неверно: причина оказалась в другом месте — в диалоге агента вручную копировали гигантскую base64-строку модуля, а не отправляли её напрямую через файл. Именно ручная вставка длинной base64-строки в чат и резала символы. Диагноз «дефект тула» был снят только тогда, когда прогнали то же самое в обход диалога — собрали JSON-тело на диске и отправили его curl'ом напрямую. Показательно, что это не разовая случайность: то же самое скрытое усечение base64 при ручном копировании повторилось ещё раз в отдельной задаче (сборка внешней обработки роли) — тул при этом рапортовал {"ok": true}, хотя результат был нерабочим. После второго повторения правило «не копировать base64 руками в диалог, только через файл на диске» закрепили как обязательное — не потому что стало любопытно, а потому что один и тот же ложный след возник дважды независимо.
История 5. Настоящий баг там, где агент сам был автором
Не всегда путаница агента — это неверный диагноз. Иногда диагноз верный, а виноват сам агент: в собственном BSL-генераторе XML-разметки колонок табличного документа обнаружился баг — ширина колонки записывалась напрямую в тег <column>, хотя платформа ожидает её только через палитру форматов (<format>/<formatIndex>), а размер палитры вообще всегда прописывался как «1», игнорируя реальное число колонок. Результат — макет собирался без ошибок, но выглядел не так, как задумано. Никакой статический анализ такое не ловит, потому что XML был синтаксически валидным — просто платформа не читала ширину оттуда, где её искал агент. Нашли и починили только прогоном реального макета и сверкой с ожидаемым видом. Урок практический: генератор разметки — это код, который нужно гонять на реальных данных, а не только линтовать.
Главная фишка: агент, который сам себя достраивает
Всё перечисленное выше — это не разовые правки от меня в код агента. Это то, что я называю полиморфизмом агента: он сам себя документирует и сам себя дорабатывает. У него есть собственный трекер задач, куда он сам заносит, что сделал, что заблокировано, какое решение принял и почему. У него есть собственная база знаний по BSL, которую он сам пополняет по мере того, как натыкается на неочевидные вещи платформы (например — та самая находка, что PATCH-запись табличной части через OData заменяет её целиком, а не добавляет строки; это не задокументировано нигде явно, агент нашёл это сам и записал себе в базу знаний, чтобы больше не наступать на эти грабли).
Он даже сам себе меняет процесс работы: когда обнаружил, что документирование инструмента иногда происходит до того, как код прошёл BSL-анализатор — то есть по потенциально не финальному коду, — сам зафиксировал задачу переставить эти волны местами: сначала BSL-анализатор и правки, потом документирование.
Это и есть рост, как у ребёнка: не «мы обновили версию», а агент сам увидел свою ошибку в процессе, сам сформулировал правило, которое эту ошибку не повторит, и сам вписал это правило туда, где будет соблюдать его дальше.
Что дальше
За неделю робот прошёл путь от «ничего не знает о базе» до «умеет ходить в OData, отлаживаться через собственный протокол и документировать сам себя». В процессе он путался — недооценивал объём задач, пытался закрыть глаза на чужие огрехи, слишком буквально трактовал собственные правила безопасности. Каждый раз это заканчивалось не тихим заметанием под ковёр, а явной остановкой, вопросом ко мне и новым, более точным правилом на будущее.
Именно в этом, а не в скорости написания кода, я вижу главный результат недели: агент, который умеет вовремя сказать «стоп, тут нужно решение человека» — гораздо ценнее агента, который бодро генерирует код, не понимая, где кончается его компетенция.
Вступайте в нашу телеграмм-группу Инфостарт