Как AI-расширения для VS Code работают с кодовой базой

m@ledin.pro (Михаил Ледин) — Wed, 15 Apr 2026 00:00:00 +0000

На одном из воркшопов на конференции GoCloud мы использовали расширение Roo Code для VS Code. И из всего, что там было, меня сильнее всего зацепила одна штука: индексация кодовой базы - то есть заранее подготовленная карта проекта для поиска и навигации.

До этого я уже использовал Cline, Continue и KiloCode. Но именно в Roo Code индексация выглядит как отдельный слой - то есть как самостоятельная подсистема, которая живет между запросами, а не собирается заново по ходу каждого ответа.

Три подхода

Если сравнить Cline, Continue, Roo Code и KiloCode, видно три разных архитектурных подхода.

Прямой обход репозитория без отдельного индекса. Расширение не держит отдельный долговременный индекс. На каждый запрос оно заново использует файловую структуру, поиск по шаблону или регулярным выражениям, чтение файлов и синтаксический разбор через Tree-sitter или LSP - стандартный протокол, через который редактор общается с языковыми серверами и получает данные о символах, определениях и ссылках. По такой схеме работает Cline.
Локальный индекс внутри расширения. Расширение заранее строит и хранит данные о кодовой базе между запросами: фрагменты кода, полнотекстовый индекс, векторные представления - числовые представления смысла кода для семантического поиска, - кэш, отслеживание изменений файлов. Внутри такого стека обычно появляются SQLite FTS5, LanceDB, Qdrant и Tree-sitter. Это архитектура Continue и Roo Code. При этом Continue делает гибридный индекс: полнотекстовый ищет по буквальному совпадению, а семантический - по смысловой близости. Roo Code использует локальный семантический индекс с Qdrant как векторным хранилищем.
Внешняя служба поиска. Расширение само не держит основной индекс, а обращается к внешнему поисковому сервису. В этом случае локально можно видеть только клиентскую часть, а сама индексация и поиск вынесены наружу. Это текущая архитектура KiloCode, если смотреть на основной репозиторий.

Как это устроено в конкретных расширениях

По Cline в документации репозитория и в пошаговом руководстве сказано, что расширение начинает работу с анализа файловой структуры, синтаксических деревьев, регулярного поиска и чтения релевантных файлов. По открытому коду также видно использование веб-версии Tree-sitter и готовых WASM-грамматик - скомпилированных описаний синтаксиса языков, которые можно загружать и выполнять прямо внутри расширения - для извлечения верхнеуровневых определений.

Это сильный структурный анализ проекта. Но признаков отдельного долговременного индекса, семантического поиска по векторным представлениям или векторной базы данных вроде Qdrant я не нашел.

У Continue картина другая. В руководстве по работе с кодовой базой и в описании подсистемы индексации прямо фигурируют поиск по кодовой базе и несколько типов индексов: фрагменты кода на основе Tree-sitter, полнотекстовый индекс на SQLite FTS5, а также векторный поиск на LanceDB / vectordb.

То есть у Continue уже гибридная схема: полнотекстовый поиск плюс семантический поиск по векторным представлениям. Отдельный слой индексации там есть, просто он построен не на Qdrant, а на LanceDB и SQLite.

У KiloCode картина уже другая. На официальном сайте документации Kilo Codebase Indexing прямо помечен как Legacy, а на странице What’s New in Kilo Code отдельно сказано: Code indexing is temporarily unavailable in the new extension. При этом для текущего расширения основной поиск по кодовой базе уже завязан на внешний сервис Morph. Этот случай я отдельно разберу ниже.

С самим Roo Code картина самая простая. В открытом репозитории видно локальный стек: Tree-sitter, разбиение кода на фрагменты, построение векторных представлений, хранение в Qdrant, кэш и обновление индекса при изменении файлов.

Подробнее про KiloCode

С KiloCode важнее всего не запутаться между legacy-схемой и текущей архитектурой. На официальном сайте документации Kilo Codebase Indexing уже помечен как Legacy, и там же есть плашка: This page applies to the legacy VSCode extension. А на странице What’s New in Kilo Code отдельно сказано: Code indexing is temporarily unavailable in the new extension. То есть в официальных источниках прямо сказано: в новом расширении от старой локальной схемы ушли.

При этом в репозиторной документации по Codebase Indexing по-прежнему описан локальный стек на Tree-sitter, векторных представлениях и Qdrant. Но в отдельном документе про Codebase Indexing & Semantic Search прямо сказано, что основные точки реализации лежат в kilocode-legacy, а не в текущем расширении.

В текущем расширении поиск по кодовой базе завязан на внешний сервис Morph. По коду видно использование @morphllm/morphsdk и WarpGrep - внешнего поискового компонента Morph для работы по кодовой базе. При этом документация WarpGrep отдельно подчеркивает, что это не embeddings-индекс и не локальная индексация, а внешний поисковый агент, работающий через API и локальные вызовы ripgrep - консольного инструмента для быстрого поиска по тексту в файлах.

С конфигурацией тоже есть расхождение. В новом UI KiloCode провайдер Morph существует как обычный provider, но сам codebase_search включается отдельно через experimental.codebase_search, а ключ читается напрямую из MORPH_API_KEY. Если ключа нет, используется прокси Kilo.

С оплатой и данными прозрачность неполная. По коду видно, что после бесплатного периода нужен ключ Morph, но в пользовательской документации KiloCode я не нашел внятного объяснения, кто именно оплачивает поиск в промежуточной схеме с прокси Kilo. По документации WarpGrep поиск не выглядит как предварительная выгрузка всей кодовой базы во внешний сервис, но запрос, структура репозитория и найденные кодовые фрагменты передаются во внешний API Morph.

Явное предупреждение для пользователя тоже вижу только частично: codebase_search помечен как экспериментальный и контролируется системой разрешений, но явного текста про внешний сервис Morph и его условия хранения данных я не нашел. Это важно, потому что политика конфиденциальности Morph и условия использования Morph описывают отдельный режим обработки данных: на бесплатном тарифе данные могут храниться до 90 дней, на платном - до 30 дней, а режим zero retention - без хранения данных после обработки - доступен только для enterprise.

Если сжать это в одну таблицу

Инструмент	Тип архитектуры	Подтвержденные подходы и библиотеки	Архитектурный вывод
`Roo Code`	Локальный индекс внутри расширения	`Tree-sitter`, разбиение кода на фрагменты, векторные представления, `Qdrant`, кэш, отслеживание изменений файлов	Цельный локальный индекс: синтаксический разбор -> фрагменты -> векторные представления -> семантический поиск
`Cline`	Навигация по живому репозиторию	Анализ файловой структуры, регулярный поиск, чтение файлов, `Tree-sitter` для извлечения верхнеуровневых определений	Сильный структурный анализ проекта без отдельного слоя индексации
`Continue`	Локальный индекс внутри расширения	`Tree-sitter`, SQLite FTS5, `LanceDB` / `vectordb`, векторные представления, полнотекстовый и семантический поиск	Гибридный локальный индекс: полнотекстовый поиск плюс семантический
`KiloCode`	Внешняя служба поиска	В документации: `Tree-sitter`, векторные представления, `Qdrant`; в текущем расширении: внешний поиск через Morph WarpGrep; в `kilocode-legacy`: локальный индекс с `Qdrant` и `LanceDB`	Переходная схема: документация и legacy-репозиторий описывают локальный индекс, текущее расширение опирается на внешний сервис поиска

Вывод

Главный вывод для меня здесь не в том, какое расширение “лучше”.

Под одинаковой формулировкой “умеет работать с кодовой базой” у разных инструментов могут скрываться принципиально разные ограничения и возможности. Где-то все держится на прямом обходе репозитория, где-то на локальном индексе, а где-то поиск уже вынесен во внешний сервис.