На типовой справляется, на доработанной путается
Те, кто уже пробовал агентов в работе с 1С, описывают одну и ту же картину. Небольшую обработку или отчёт на типовой базе агент пишет уверенно. Стоит дать ему задачу на живой ERP с многолетними доработками, и качество падает.
Обычно в этом винят модель: слабая, маленькое окно, нужна подписка дороже. Модель здесь действительно важна, но причина в другом. Агенту не дали того, что знает о системе человек, который в ней давно работает.
Чего именно не хватает
Контекст в 1С — это не объём текста, а связи. Чтобы изменить поведение документа и ничего не сломать, нужно знать вещи, которые лежат в разных местах конфигурации:
| Что нужно знать | Где это лежит |
|---|---|
| Какие регистры двигает документ | Модуль объекта, модуль менеджера, общие модули проведения |
| Что ещё срабатывает при записи | Подписки на события, которых в самом документе не видно |
| Кто читает этот реквизит | Отчёты, обработки, обмены, другие документы |
| Кто имеет доступ | Роли и ограничения на уровне записей |
| Что здесь типовое, а что доработано | Сравнение с поставкой вендора, расширения |
Человек собирает эту картину годами. Агент начинает каждую задачу с нуля и видит только то, что ему показали.
Три способа дать контекст и чем они заканчиваются
Вставить фрагмент кода. Для вопроса про один модуль этого хватает. Но фрагмент не отвечает на вопрос, кто ещё пишет в этот регистр, и агент достраивает недостающее по типовой конфигурации, которую помнит из обучения. На доработанной базе это и есть источник уверенных ошибок.
Выгрузить конфигурацию в файлы и дать агенту читать. Конфигурация уровня ERP целиком в окно не помещается. Агент читает файлы по одному и тратит окно на то, что к задаче не относится.
Подключить универсальные инструменты чтения метаданных. Это шаг вперёд, и практики к нему приходят. Но каждый инструмент занимает место в окне своим описанием, а отдаёт сырые данные, в которых связи агенту нужно восстанавливать самому.
У всех трёх способов общий недостаток: агент получает текст, а нужна ему карта.
Карта вместо выгрузки
Индексация разбирает конфигурацию один раз и строит граф. В нём:
- объекты метаданных: документы, справочники, регистры, отчёты, обработки;
- связи между ними: кто куда пишет, кто что читает;
- код и то, к каким объектам он относится;
- роли и права, включая ограничения на уровне записей;
- ваши доработки вместе с типовой частью.
Дальше на вопрос агент получает не всю конфигурацию, а участок графа: объекты, с которых стоит начать, их связи и код, который с ними работает. Окно тратится на то, что относится к задаче.
Вот как выглядит ответ, построенный по такому графу. Это вопрос к типовой ERP 2.6 в нашем открытом чате:
Обратите внимание на первое предложение. Вопрос был задан с ошибкой: в документе нет реквизита, про который спрашивали. Без карты модели остаётся опираться на то, как реализация устроена «обычно». Здесь ответ начинается с того, что такого реквизита в этой конфигурации нет.
Где этот граф работает
- Чат-эксперт. Вопросы к конфигурации обычными словами: откуда берётся значение, что затронет изменение, как устроен механизм.
- 1Yes Аналитик. Разбор бизнес-требования: уточняющие вопросы, варианты решения, спецификация на доработку.
- Ваш собственный агент. Если команда уже работает с агентом, который поддерживает MCP, граф можно подключить к нему через «Живую Конфигурацию». Доступ выдаём мы по токену, вызовы по нему записываются в журнал.
Третий вариант нужен тем, кто уже выстроил свой процесс разработки с агентом и хочет не менять его, а дать агенту знание о конфигурации.
Что остаётся за человеком
Граф отвечает на вопрос «как устроено». Вопросы «что делать» и «правильно ли получилось» остаются за людьми.
- Поставить задачу. Чем точнее требование, тем лучше результат, и карта конфигурации этого не отменяет.
- Проверить результат. Код, который написал агент, проходит ревью и тесты так же, как код разработчика.
- Отвечать за то, что уходит в рабочую базу.
Индексация убирает поиск, а не ответственность.
Когда это не сработает
- Индекс устарел. Граф описывает конфигурацию на момент индексации. Если её активно дорабатывают, индекс нужно обновлять, иначе агент будет уверенно работать со вчерашней системой.
- Вопрос про данные. Для индексации нужны структура и код, продуктивные данные не нужны. Поэтому агент знает, как считается сумма, но не знает, почему она такая в конкретном документе.
- Задача небольшая и изолированная. Отчёт на трёх полях агент напишет и без графа. Карта окупается там, где изменение задевает несколько связанных объектов.
- Ожидание, что знание заменит проверку. Агент с картой всё равно может ошибиться. Тесты и ревью остаются.
С чего начать
- Замер конфигурации. Передаём скрипт-отчёт 1С, по нему считается объём индексации.
- Индексация. Система разбирает метаданные, связи, код и доработки.
- Проверка на ваших задачах. Лучше всего взять те, на которых агент уже ошибался: разница видна сразу.