Code Index — структурный поиск по коду 1С через MCP
Зачем это нужно
Когда работаешь с конфигурацией 1С через LLM-агента (Claude Code, Cursor, любой MCP-совместимый клиент) — самая дорогая операция это поиск по коду. Агент гоняет grep по гигабайтам выгрузки, забивает контекст сырыми строками, и через пару итераций ты упираешься в лимит окна. А поиск по BSL осложняется тем, что обычные индексаторы (ctags, ripgrep) не понимают структуру модулей 1С — они ищут текст, а не функции.
Code Index решает обе проблемы: парсит BSL (и ещё 7 языков) в SQLite-индекс, отдаёт по MCP-протоколу готовые функции, классы, граф вызовов. Агент получает не «строки 1234–1267 файла Х», а структурированный ответ: имя процедуры, путь, тело, кто её вызывает.
Что умеет (общие инструменты)
- Поиск функций и классов по имени — найти
ОбработкаПроведенияво всей конфигурации за миллисекунды - Граф вызовов — кто вызывает эту процедуру (
get_callers), что вызывает она сама (get_callees) - Получение тела функции по точному имени — без чтения всего модуля
- Карта файла — список всех функций/классов модуля без открытия исходника
- grep по телам функций — поиск подстроки или regex именно внутри процедур (не в комментариях документации)
- Полнотекстовый поиск через SQLite FTS5 — мгновенный по любому объёму
Специальные инструменты для XML-выгрузки 1С
Поверх обычного BSL-парсера в code-index подключается отдельное расширение bsl-extension, которое разбирает не только модули, но и XML-файлы выгрузки конфигуратора. Эти инструменты появляются в MCP автоматически, если хотя бы один репо помечен language = "bsl".
Что разбирается из XML:
- Configuration.xml — корневой файл конфигурации (состав, версия, совместимость)
- <Объект>.xml (справочники, документы, регистры…) — реквизиты, табличные части, синонимы, типы
- Form.xml — управляемые формы: реквизиты, элементы, обработчики событий
- EventSubscription.xml — подписки на события (источник → обработчик)
- ConfigDumpInfo.xml — UUID объектов конфигурации
И на основе этих данных — четыре MCP-инструмента, которых нет в обычных индексаторах:
| Инструмент | Что делает |
|---|---|
get_object_structure |
Структура объекта по full_name (например Справочник.Контрагенты): meta_type, синоним, все реквизиты с типами, табличные части. Заменяет ручное чтение XML-файла объекта |
get_form_handlers |
Все обработчики события формы: (событие → имя процедуры) для указанной формы. Сразу видно где сидит ПриОткрытии, ПередЗаписью и т.д. |
get_event_subscriptions |
Все подписки на события репо (с фильтром по модулю-обработчику). Полезно когда нужно понять «кто подписан на запись справочника» — обычно эту информацию приходится искать вручную по всем подпискам |
find_path |
Путь вызовов от одной процедуры к другой через граф proc_call_graph (recursive CTE в SQLite). Отвечает на «как ОбработкаПроведения доходит до СформироватьДвижения» — реальная цепочка через все промежуточные модули |
Плюс есть enrichment-режим — необязательное обогащение индекса через LLM: для каждой функции генерируется сигнатура и краткое описание, которые потом попадают в FTS-поиск. Запрашивая «найди процедуру, которая считает курсовые разницы» — агент находит её даже если в имени нет ни слова «курс», ни «разниц».
Поддерживаемые языки
BSL (1С), Python, Rust, Java, Go, JavaScript, TypeScript, XML. Один индекс — все языки разом.
Архитектура
Два процесса:
- Daemon индексации — отслеживает изменения файлов через mtime, переиндексирует только изменённое
- HTTP MCP-сервер на
127.0.0.1:8011/mcp— один на все клиенты, читает SQLite в режиме read-only
Подключение к Claude Code / Cursor / любому MCP-клиенту — три строки в .mcp.json:
"code-index": { "type": "http", "url": "http://127.0.0.1:8011/mcp" }
В каждом вызове передаётся алиас репо — один сервер обслуживает сколько угодно конфигураций.
Преимущества перед grep / ripgrep / встроенным поиском Конфигуратора
- Структурный поиск: возвращает функции, а не строки. Агент сразу понимает контекст
- Граф вызовов из коробки — никаких сторонних утилит
- Понимает выгрузку 1С как структуру — формы, объекты, подписки, а не просто XML
- Инкрементальная индексация — после первого прохода обновления почти бесплатные
- Один индекс на все репо — переключение между конфигурациями без перенастройки
- Read-only SQLite — несколько агентов параллельно не мешают друг другу
- Федеративный режим — один MCP-сервер может проксировать запросы к индексам на других машинах
Производительность — реальный замер
Прогон на типовой бухгалтерии (выгрузка XML), Linux VM, режим in-memory, NVMe:
- Файлов в репо: 93 648 (из них ~19 300 .bsl)
- Размер итогового индекса: 5.2 ГБ
- Пик RAM: ~14 ГБ (in-memory режим всю БД держит в RAM до финального сброса)
Разбивка по фазам:
| Фаза | Время | Что делается |
|---|---|---|
| Сбор кандидатов | 5.6 сек | walkdir по 93K файлам + stat() — около 17 000 stat-операций в секунду |
| Парсинг + запись данных | 19 сек | tree-sitter парсит каждый BSL-файл, извлекает функции/классы/переменные/импорты; батчи по 2000 в SQLite. ~5 000 файлов/сек |
| Создание B-tree индексов + FTS5 rebuild | 78.7 сек | строятся индексы на колонки (для join/lookup) и перестраивается полнотекстовый индекс через FTS5 — самая долгая фаза |
| Финальный flush на диск | ~29 сек | сброс in-memory БД (5.2 ГБ) на NVMe |
| Wall-clock итого | 2 мин 31 сек |
Почему B-tree + FTS5 занимают 78 секунд — это последовательная операция: для каждой записи в таблицах functions/classes выполняется токенизация и вставка в виртуальную FTS5-таблицу. На объёме 92K+ функций фрагментация во временных структурах вынуждает много random I/O даже на NVMe. Это плата за то, что после индексации поиск работает за миллисекунды.
Инкрементальные обновления — на порядки быстрее: при повторном запуске на тех же 93K файлах daemon сравнивает mtime+size без чтения содержимого и обрабатывает только реально изменённые файлы — обычно секунды вместо минут.
Скорости запросов после индексации
- Поиск функции по имени: <10 мс
- get_callers / get_callees: <20 мс
- grep_body по regex с фильтром по языку: <100 мс на репозитории УТ
- get_object_structure / get_form_handlers: <5 мс (одиночный SELECT по индексу)
Установка
Бинарник под Windows / Linux собирается через cargo build --release. Подробная инструкция и release-сборки — в репозитории.
Ссылка
Вступайте в нашу телеграмм-группу Инфостарт