6 сентября 2026 г.
Оптимизация контекстного окна LLM для кода 1С BSL — как Grafon снижает расход токенов в 10 раз
Почему обычная отправка кода в LLM переполняет контекст
Когда разработчик подключает Claude Code или Cursor к конфигурации 1С, у ассистента нет «знания» о том, какие модули относятся к задаче. Агент пытается прочитать файлы: открывает XML-выгрузку конфигурации, общие модули, модули объектов, менеджеров, формы и подписки на события. В типовых конфигурациях ERP, УТ, ЗУП или КА это тысячи модулей и гигабайты XML-метаданных. Контекстное окно LLM переполняется ещё до того, как модель увидела нужный фрагмент кода.
Посчитаем, что происходит на практике:
- LLM-агенту требуется понять, почему при проведении документа вызывается контроль остатков.
- Он начинает читать модуль объекта документа, общий модуль товарного учета, менеджер регистра, формы.
- К каждому файлу добавляются служебные данные и история предыдущих сообщений.
- Через несколько минут контекст достигает лимита, а агент уже смешал несвязанные методы и начал галлюцинировать.
Корень проблемы не в качестве LLM, а в архитектуре хранения кода 1С. BSL-модуль не имеет явных import, как TypeScript или Java. Связи между процедурами задаются через метаданные, общие модули, подписки на события и тексты запросов.
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
ТоварныйУчет.КонтрольОстатков(Ссылка, ТабличнаяЧасть, Отказ);
КонецПроцедуры
Чтобы понять этот вызов, LLM нужно знать, что метод КонтрольОстатков находится в общем модуле ТоварныйУчет, что он обращается к таблицам регистра ОстаткиТоваров и что его вызывает подписка на событие. Без графа зависимостей агент перебирает весь конфигурационный dump. Это и есть 10-кратный перерасход токенов.
Оптимизация контекста через граф зависимостей 1С
Grafon решает задачу как локальный инструмент и MCP-сервер. Вместо отправки в LLM целой конфигурации Grafon анализирует исходники 1С и строит граф зависимостей метаданных, процедур, функций, подписок на события и запросов.
Как устроен Графон
Архитектурно это трёхслойная система:
- Индексатор. Загружает выгрузку конфигурации в XML или JSON, разбирает BSL-модули и XML-метаданные.
- Граф. Строит связи между объектами: документ → общий модуль → регистр → подписка на событие → форма.
- MCP-сервер. Отдаёт агенту только релевантный срез кода через стандартный протокол MCP.
Для Claude Code, Cursor или Windsurf Grafon выглядит как набор инструментов, позволяющих заменить чтение гигантских файлов точечными запросами.
Пример MCP-запроса из агента:
{
"query": "КонтрольОстатков",
"metadata": "Документ.РеализацияТоваровУслуг",
"context": "ОбработкаПроведения"
}
Ответ Grafon содержит не весь файл, а минимальный связный подграф:
{
"symbol": "Документ.РеализацияТоваровУслуг.МодульОбъекта.ОбработкаПроведения",
"related": [
{ "module": "ОбщийМодуль.ТоварныйУчет", "method": "КонтрольОстатков" },
{ "module": "РегистрНакопления.ОстаткиТоваров", "method": "МенеджерЗаписи" }
],
"estimated_tokens": 4200
}
Теперь модель получает не 100 000 строк возможного кода, а точную сигнатуру метода и связанные объекты. Это и есть оптимизация контекстного окна.
Сравнение расхода токенов: с Графоном и без
Ниже типичный сценарий для УТ/ERP: разбор ошибки контроля остатков при проведении документа.
| Подход | Что попадает в контекст LLM | Расход токенов | Результат |
|--------|------------------------------|----------------|-----------|
| Чтение файлов «в лоб» | Модуль объекта + общий модуль + XML-представление документа | ~145 000 | LLM смешивает методы, ответ медленный |
| Отправка полной XML-выгрузки | Гигабайты конфигурации | >1 000 000 | Переполнение контекста или отказ модели |
| Grafon через MCP | 3 функции, сигнатуры, граф вызовов | ~8 500 | Точечный разбор нужного зависимого кода |
Время ответа так же радикально сокращается: меньше токенов — меньше задержка. Среднее снижение расхода токенов на задаче составляет до 10 раз.
Какие связи Grafon умеет находить
Важно, что Графон анализирует именно BSL-специфичные неявные связи, которые обычный RAG-поиск не видит.
Подписки на события
В 1С обработчик часто вызывается не из модуля объекта, а через подписку на событие.
Процедура ПриЗаписиТовара(Источник, Отказ) Экспорт
Цены = ЦеныНоменклатуры.ПолучитьПоследние(Источник);
Источник.Цена = Цены.Цена;
КонецПроцедуры
Если агент изменит модуль справочника, но не учтёт подписку, исправление сломает смежную логику. Grafon возвращает цепочку «подписка → обработчик → вызываемые методы», и LLM видит её до внесения изменений.
Запросы внутри строковых литералов
Большая часть бизнес-логики 1С живёт в текстах запросов. Статический поиск по файлу не показывает, что ВЫБРАТЬ ... ИЗ РегистрНакопления.ОстаткиТоваров.Остатки относится к конкретному регистру. Grafon разбирает текст запроса и связывает его с виртуальными таблицами, менеджерами регистров и используемыми полями.
Общие модули и менеджеры объектов
Grafon различает глобальные общие модули, модули менеджеров и модули объектов. Для агента это критично: вызов Справочники.Номенклатура.НайтиПоНаименованию не должен приводить к чтению всех модулей справочника.
MCP-инструменты, которые оптимизируют контекст
Типичный набор инструментов Grafon для ИИ-агента выглядит так:
| MCP-инструмент | Назначение |
|----------------|------------|
| search_symbol | Поиск процедуры/функции по имени и метаданным |
| get_subgraph | Получение связного подграфа от корневого метода |
| get_call_path | Построение цепочки вызовов «объект → метод → регистр» |
| get_file_slice | Получение точного фрагмента BSL-модуля |
| resolve_query | Разбор текста запроса и его связей |
Агент делает несколько маленьких MCP-запросов вместо одного огромного read_file. Каждый запрос возвращает только нужную сигнатуру, фрагмент или список смежных объектов. Так поддерживается оптимальное соотношение пользы и токенов в контекстном окне.
Как подключить Grafon к Claude Code или Cursor
Grafon работает в локальной сети разработчика. Клиентская конфигурация MCP выглядит стандартно.
{
"mcpServers": {
"grafon": {
"command": "grafon-mcp",
"args": [
"--workspace", "/srv/1c/erp_xml",
"--db", "~/grafon/erp.graph"
]
}
}
}
После подключения в инструкции проекта достаточно добавить правило:
Для работы с конфигурацией 1С используй MCP-сервер Grafon. Не читай общие модули и XML-выгрузку целиком. Сначала вызовиget_subgraphилиsearch_symbol.
Практические сценарии оптимизации
Сценарий 1: исправление ошибки в проведении документа
Разработчик пишет в Claude Code: «Найди причину ошибки “Поле не найдено” при проведении Реализации». Без Графона агент начинает читать сотни файлов. С Графоном он вызывает get_subgraph для метода ОбработкаПроведения и получает три-четыре связанных модуля. LLM сразу видит, что контролируемые данные берутся из запроса к таблице с другим именем реквизита.
Сценарий 2: изменение алгоритма расчёта себестоимости
Вместо отправки всех модулей расчёта Grafon находит подписки на события, общие модули и регистры, участвующие в пересчёте. Модель анализирует только изменяемый срез.
Сценарий 3: миграция кода на новый релиз
Grafon может показать все точки вызова устаревшего метода и подписки на событие. LLM получает компактный список мест для правки, а не весь типовой модуль.
Рекомендации по работе с контекстным окном
Даже с Графоном полезно придерживаться практик экономии контекста:
- Формулируйте одну задачу на одно обращение к агенту.
- Просите возвращать не файл целиком, а исправленный фрагмент или diff.
- Указывайте горизонт глубины графа: достаточно
depth=2— не тянуть всю связанную цепочку. - Не отправляйте агенту историю большого диалога: начинайте новый поток для новой задачи.
- Используйте ответы Grafon как единственный авторитетный источник сигнатур BSL — это предотвращает галлюцинации.
Вывод
Оптимизация контекстного окна LLM для кода 1С BSL — это не выбор более мощной модели и не увеличение лимита токенов. Это архитектурная работа с графом зависимостей конфигурации. Локальный MCP-сервер Grafon избавляет агента от необходимости читать гигабайты XML-метаданных и даёт ему точный срез кода, сигнатур и запросов.
Разработчик получает предсказуемую скорость работы ассистента, снижение расходов на токены до 10 раз и меньше ошибок в сгенерированном BSL-коде. Подключение к Claude Code, Cursor и Windsurf выполняется через стандартный MCP-протокол, поэтому инструмент легко встраивается в существующий процесс разработки на 1С.