5 октября 2026 г.
Быстрый онбординг ИИ-агента в legacy-конфигурацию 1С: граф зависимостей вместо гигабайтов XML
Почему legacy-конфигурация ломает контекст ИИ-агента
Типовая ERP, УТ 11, ЗУП 3.1 или КА — это 40 000+ файлов XML метаданных, 3–8 ГБ на диске и 400 000–900 000 строк кода на BSL. Когда разработчик открывает такую конфигурацию в Claude Code или Cursor и просит «разобраться, как рассчитывается себестоимость», агент начинает читать всё подряд: общий модуль, модуль объекта, модуль менеджера, формы, подписки на события.
Арифметика простая: одна строка BSL — это в среднем 12–18 токенов. Общий модуль РасчетСебестоимости на 8 000 строк — уже 120 000 токенов. Плюс модуль документа на 3 000 строк, плюс форма, плюс ещё три общих модуля, которые агент «на всякий случай» подтянул по импортам. Контекстное окно 200K переполняется за один вопрос, а в режиме agentic-цикла (десятки tool-call’ов) счёт за API уходит в сотни долларов в день.
Главная беда даже не в деньгах. Переполненный контекст означает, что агент начинает галлюцинировать: придумывает несуществующие методы ОбщегоМодуля.МойМетод(), путает экспортную и неэкспортную процедуру, зовёт функцию с другим числом параметров. В legacy-коде, где номенклатура методов исторически дублируется (ПолучитьЦену, ПолучитьЦенуНоменклатуры, ЦенаНоменклатурыПолучить), это гарантированный баг.
MCP — правильный протокол для такой задачи
Model Context Protocol (MCP) — это JSON-RPC 2.0-протокол, через который ИИ-агент получает доступ к внешним инструментам. Вместо того чтобы «засасывать» файлы в промпт, агент вызывает инструмент и получает ровно тот фрагмент, который нужен. Графон — это локальный MCP-сервер, который держит предварительно построенный граф зависимостей конфигурации 1С и отвечает на запросы агента за миллисекунды, без обращения к сети и без выгрузки данных за пределы машины разработчика.
Архитектура Графона
1С-конфигурация (XML + BSL)
│
▼
[ Индексатор ] ──► разбор метаданных, парсинг BSL (AST)
│
▼
[ Локальный граф ] узлы: метаданные, модули, процедуры,
│ функции, формы, подписки, запросы
│ рёбра: вызовы, чтение/запись реквизитов,
│ подчинение, использование в запросах
▼
[ MCP-сервер (stdio/HTTP) ]
│
▼
Claude Code / Cursor / Windsurf / Roo Code
Ключевые узлы и рёбра графа:
| Тип узла | Пример | Что даёт агенту |
|---|---|---|
| MetadataObject | Документ.РеализацияТоваровУслуг | структура реквизитов, табличные части |
| Module | ОбщийМодуль.Ценообразование | список процедур и сигнатур |
| Routine | Ценообразование.РассчитатьЦену | параметры, возврат, экспортность |
| Form | ФормаДокумента.РеализацияТоваровУслуг | обработчики, привязки |
| EventSubscription | ПередЗаписью_Реализация | источник и обработчик |
| Query | встроенный запрос | используемые таблицы и поля |
| Тип ребра | Смысл |
|---|---|
| CALLS | процедура A вызывает B |
| READS / WRITES | метод читает/пишет реквизит или регистр |
| SUBSCRIBES | подписка связывает событие и обработчик |
| QUERIES | запрос обращается к таблице метаданных |
| EXTENDS | расширение дополняет объект |
Установка и первый запуск: 5 шагов
- Скачайте Графон с
https://grafonbase.ruи распакуйте в локальную папку. - Выгрузите конфигурацию в XML (Конфигуратор → «Выгрузить конфигурацию в файлы») либо укажите путь к уже существующей выгрузке.
- Запустите индексацию — сервер построит граф и кэш:
grafon index --src ./src --out ./.grafon --threads 8
- Проверьте, что индекс собран корректно:
grafon stats --index ./.grafon
Objects: 24871 Modules: 19432 Routines: 412508 Edges: 1 903 244
- Пропишите MCP-сервер в конфиг агента.
Подключение к Claude Code / Cursor / Windsurf
Для Claude Code — .mcp.json в корне проекта:
{
"mcpServers": {
"grafon": {
"command": "grafon",
"args": ["mcp", "--index", "./.grafon"]
}
}
}
Для Cursor — тот же блок в ~/.cursor/mcp.json, для Windsurf — в mcp_config.json. После перезапуска агента в списке инструментов появятся grafon.*.
Практические сценарии MCP-запросов
1. Найти точку входа по имени
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"grafon.resolve_symbol",
"arguments":{"query":"РассчитатьЦену","kind":"procedure","limit":10}}}
Ответ содержит FQN, путь к файлу и строку — агент сразу знает, куда идти, вместо grep по 8 ГБ.
2. Получить сигнатуру и срез реализации
{"name":"grafon.get_routine_slice",
"arguments":{"fqn":"ОбщийМодуль.Ценообразование.РассчитатьЦену",
"includeCalls":true,"depth":1}}
Возвращается тело процедуры плюс сигнатуры всех вызываемых ею методов — но не их тела. Это и есть экономия контекста: агенту нужны контракты, а не реализация на 800 строк.
3. Найти всех, кто пишет в регистр
{"name":"grafon.find_writers",
"arguments":{"target":"РегистрСведений.ЦеныНоменклатуры","limit":100}}
Незаменимо при рефакторинге: видно каждое место, где цены меняются, включая подписки на события и регламентные задания.
4. Размотать подписку на событие
{"name":"grafon.trace_event_subscription",
"arguments":{"event":"ПередЗаписью","source":"Документ.РеализацияТоваровУслуг"}}
Результат — цепочка «событие → обработчик в общем модуле → вызываемые процедуры → объекты, которые они меняют».
Сравнение: с Графоном и без
Замеры на выгрузке УТ 11.5 (≈6,2 ГБ XML, 512 000 строк BSL), задача «разобраться, почему при проведении реализации не пересчитывается себестоимость».
| Метрика | Без Графона (grep + чтение файлов) | С Графоном (MCP) |
|---|---|---|
| Прочитано файлов агентом | 180–400 | 6–14 |
| Входные токены на задачу | ~1 400 000 | ~140 000 |
| Время до первой гипотезы | 25–40 мин | 2–4 мин |
| Число tool-call’ов | 60–120 | 5–9 |
| Галлюцинации (несуществующие методы) | регулярно | практически отсутствуют |
| Стоимость задачи (Sonnet) | ~$4–6 | ~$0,4–0,6 |
Разница в 10x по токенам — это не маркетинг, а прямое следствие того, что агент читает граф, а не файловую систему.
Кейс: правим проведение документа
Задача агента: «добавить контроль отрицательных остатков при проведении реализации». Без графа агент лезет в модуль объекта целиком и тонет. С Графоном агент сначала спрашивает граф и получает компактную карту:
// Ответ Графона: цепочка проведения
// Документ.РеализацияТоваровУслуг.ОбработкаПроведения
// └─ ОбщийМодуль.РеализацияТоваровУслуг.ПровестиДокумент
// └─ ОбщийМодуль.УчетЗапасов.ПроверитьОстатки (экспорт)
// └─ Подписка.ПередЗаписью_Реализация → ОбщийМодуль.Ценообразование.ПересчитатьЦены
После этого агент запрашивает только два среза и генерирует корректную правку:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
Возврат;
КонецЕсли;
// Вставка от ИИ-агента: контроль отрицательных остатков
РезультатПроверки = УчетЗапасов.ПроверитьОстатки(
СформироватьОтборПоТоварам(), Истина);
Если Не РезультатПроверки.Успешно Тогда
Сообщить(РезультатПроверки.ТекстОшибки, СтатусСообщения.Внимание);
Отказ = Истина;
Возврат;
КонецЕсли;
РеализацияТоваровУслуг.ПровестиДокумент(ЭтотОбъект, Отказ, РежимПроведения);
КонецПроцедуры
Важно: агент не выдумал ПроверитьОстатки — сигнатура метода и его экспортность пришли из графа. Это и есть разница между «ИИ угадал» и «ИИ знает».
Чеклист быстрого онбординга
- Выгрузить конфигурацию в XML — источники правды, а не EDT-проект.
- Собрать индекс Графона один раз на релиз, обновлять инкрементально.
- Прописать MCP-сервер в конфиг агента и перезапустить его.
- Дать агенту системный промпт: «сначала
grafon.resolve_symbol, потом срезы, никогда не читай модуль целиком». - Ограничить depth обхода графа (1–2 уровня) — иначе снова утонете в контексте.
- Добавить индекс в
.cursorignore/.gitignore, чтобы агент не индексировал бинарный кэш. - Прогнать пилотную задачу на 3–4 реальных багах и замерить токены до/после.
Онбординг ИИ-агента в legacy-конфигурацию 1С перестаёт быть двухнедельным проектом, когда у агента есть карта кода. Графон даёт эту карту локально, без выгрузки исходников в облако, и превращает «прочитать 6 ГБ» в «прочитать 12 файлов».