На одном из воркшопов на конференции 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-репозиторий описывают локальный индекс, текущее расширение опирается на внешний сервис поиска

Вывод⌗

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

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

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