Все статьи

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С и строит граф зависимостей метаданных, процедур, функций, подписок на события и запросов.

Как устроен Графон

Архитектурно это трёхслойная система:

  1. Индексатор. Загружает выгрузку конфигурации в XML или JSON, разбирает BSL-модули и XML-метаданные.
  2. Граф. Строит связи между объектами: документ → общий модуль → регистр → подписка на событие → форма.
  3. 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С.