rtk + context-mode поверх Serena + Semble: стоит ли нахлобучивать прокси-экономию токенов или это бред?

Здравствуй, искушенный читатель. Недавно я выкатил на Хабре статью про сравнение 21 подхода к сбору контекста для ИИ-агентов (habr.com/ru/articles/1042880/). Тема экономии токенов сейчас дико популярна, и мы с ребятами в Гильдии AI-инженеров знатно её пообсуждали. Напомню краткую суть: там связка Serena (LSP) + Semble (векторные эмбеддинги) + Ripgrep (поиск координат) показала себя абсолютным топом для точечной навигации.

Но в комментариях и личке мне тут же начали советовать: «Нахлобучь сверху еще rtk для сжатия вывода терминала и context-mode для полнотекстового индекса репозитория! Тема прокси-экономии сейчас на пике хайпа, сэкономишь еще больше!».

Я решил провести душный менеджерский аудит. Взял популярный open-source проект supermemory (~180 файлов, JS/TS) и замерил: действительно ли добавление rtk + context-mode дает реальный профит поверх моего текущего сетапа, или это просто карго-культ и оверхед, который утянет бюджет в минус?

1. Слоеный пирог: как они работают вместе

Чтобы понять, есть ли смысл в надстройке, разделим зоны ответственности инструментов.

1. Базовый слой (Serena + Semble + rg) — хирургический инструмент. Serena знает структуру кода (функции, типы, связи), Semble ищет по смыслу через векторную базу, rg моментально локализует строки по регуляркам. Они работают на этапе до вызова тяжелых операций, помогая агенту не читать лишнего.

2. rtk — CLI-прокси. Он перехватывает команды терминала (git, grep, ls) и фильтрует их вывод после выполнения, вырезая мусор перед отправкой в LLM.

3. context-mode — локальный текстовый индекс (FTS5). Он делит файлы на мелкие сниппеты и отдает их вместо полных исходников при текстовом поиске.

2. Глубокий разбор инструментов: Архитектура, Схемы, Боли

Для понимания целесообразности интеграции разберем каждый инструмент под капотом, схемы их работы и слабые места.

2.1. rtk (Rust Token Killer)

CLI-прокси, написанный на Rust. Встраивается между ИИ-агентом и командной оболочкой (shell).

Shellrtk (Proxy)AgentShellrtk (Proxy)AgentПарсинг вывода, удаление пробелов,вырезание ханков кода, сбор статистикиКоманда (например, git diff)Вызов сырой команды git diffСырой вывод (30,000 токенов)Сжатый вывод (5,000 токенов)

Проблемы и боли:

1. Lossy-слепота (сжатие с потерями). rtk сжимает git diff и git log -p, безжалостно вырезая ханки кода (оставляя только статистику изменений). Если агенту нужно проанализировать логику правок, он слепнет и делает повторные запросы.

2. Паразитный оверхед. На простых утилитах вроде npm ls или pip list rtk пытается на лету переформатировать дерево зависимостей, раздувая вывод в 2.5 раза.

3. Платформозависимость. На Windows unix-команды (ls, grep, wc) вызывают ошибки «command not found» из-за отсутствия родных бинарников в PATH.

Замеры rtk на проекте supermemory:

2.2. context-mode

Полнотекстовый текстовый индекс кодовой базы на SQLite FTS5 с алгоритмом BM25.

Проблемы и боли:

1. TF-IDF/BM25 слепота к смыслу. В отличие от Semble, context-mode не использует векторные эмбеддинги. Это жесткий текстовый поиск по токенам. Если агент ищет user authentication, а в коде написано SecuritySessionManager, context-mode ничего не найдет.

2. Оверхед схем MCP. При использовании как MCP-сервер, он скармливает агенту ~7.4k токенов JSON-описаний своих инструментов при каждом старте сессии.

3. Старение индекса. Требует регулярного запуска индексации (context-mode index) при изменении файлов.

Замеры context-mode (поиск useAuth на 180 файлов):

• Без context-mode (полное чтение): 324 453 токена.

• С context-mode (3 сниппета): 471 токен (экономия −99.85%).

2.3. Serena

MCP-сервер на базе Language Server Protocol (LSP). Извлекает AST-дерево проекта и строит граф символов.

Проблемы и боли:

1. Зависимость от LSP. Если в проекте сломаны типы, не настроен tsconfig.json или падает языковой сервер, Serena перестает видеть сигнатуры функций.

2. Слепота к не-коду. Бесполезна для поиска в markdown-документации, .env-файлах, JSON-конфигах или логах.

2.4. Semble

Легковесный локальный векторный поисковик по эмбеддингам кода.

Проблемы и боли:

1. Ресурсоемкость. Генерация эмбеддингов требует мощностей CPU/GPU и времени при первом запуске.

2. Промах мимо точных названий. Из-за семантической природы может вернуть концептуально близкий код вместо конкретного метода с точным совпадением имени.

3. Лестница стоимости: сколько стоит один запрос

Сравним все инструменты на одной задаче: найти и прочитать функцию useAuth в проекте supermemory.

Полный read файла  ▏████████████████████████████████████████ 1476 tokcontext-mode search▏████████████ 471 tokSemble search      ▏█████ 180 tokSerena find_symbol ▏██ 83 tokripgrep locate     ▏█ 38 tok

4. Парадокс оверхеда: почему экономия уходит в минус

Главный подводный камень ИИ-проксирования — налог на схемы инструментов.

Замеры общего расхода токенов за стандартную сессию ИИ-агента (решение 1 средней задачи):

• Чистая база (Serena + Semble + rg): 12 323 токена.

• База + rtk (через CLI): 16 406 токенов.

• База + rtk + context-mode (как MCP): 35 737 токенов ❌.

none (чистая база)               12 323 ████████████integrated (rtk + хуки)          16 406 ████████████████+ rtk only                      25 649 █████████████████████████+ context-mode MCP              34 199 ██████████████████████████████████Оба вместе                       35 737 ████████████████████████████████████

Подключение context-mode в качестве активного MCP-сервера добавляет ~7.4k токенов схем на каждом старте сессии.
Если ваша задача решается за 2-3 шага, стартовый оверхед гарантированно перекроет всю экономию от сжатия. Экономия токенов через прокси — это инвестиция с высоким порогом входа: она окупается только на длинных дистанциях (от 10-15 шагов агента).

5. Итоговый вывод: как собрать идеальный стек

Скрещивать rtk + context-mode + Semble + ripgrep + Serena в один мега-стек — это худшее, что вы можете сделать. Вы получите монстра Франкенштейна, который:

1. Сожрет до 15–20k токенов на старте сессии только на системные промпты и JSON-схемы MCP-инструментов.

2. Запутает агента. Имея 5 разных поисковиков, модель начинает метаться между ними, совершая лишние «пристрелочные» вызовы и тратя ваши деньги.

Вместо этого соберите один из трех прагматичных стеков под вашу задачу:

Сценарий А: «Точечный скальпель» (Semble + Serena + ripgrep)

• Для чего: Сложные проекты с ООП, жесткой типизацией и активной кодогенерацией (TS/JS, Python, Go, Java).

• Почему это работает: Semble ищет по смыслу (векторный поиск), ripgrep мгновенно дает точные координаты строк, а Serena через LSP вытаскивает чистые сигнатуры и тела функций. Оверхед минимальный, точность ювелирная. context-mode здесь абсолютно лишний — он дублирует поиск и забивает контекст.

Сценарий Б: «Легкий вездеход» (context-mode CLI + ripgrep)

• Для чего: Проекты без строгой типизации, монорепозитории с кучей Markdown-документации, JSON/YAML-конфиги или языки без качественной поддержки LSP (где Serena бесполезна).

• Почему это работает: Нет тяжелых LSP-серверов и оверхеда на генерацию эмбеддингов. context-mode (строго в CLI-режиме, без MCP-схем!) нарезает файлы на сниппеты, а ripgrep находит координаты. Быстро, просто, дешево.

Сценарий В: Дополнение «Git-фильтр» (rtk)

• Для чего: Длинные сессии отладки (от 10+ шагов), где агент постоянно анализирует историю коммитов.

• Правило настройки: Подключайте rtk к любому стеку, но строго для фильтрации git-команд (git diff, git log, git status). Обязательно исключите из его области видимости чтение файлов и менеджеры пакетов (npm, pip).

• Фикс для Windows: Чтобы rtk не ломал стандартные unix-команды в PowerShell, пропишите утилиты Git в конец пользовательского PATH:

  $p = [Environment]::GetEnvironmentVariable("Path","User")[Environment]::SetEnvironmentVariable("Path","$p;C:\\Program Files\\Git\\usr\\bin","User")
  

Главный вердикт: Один тип поиска на одну сессию. Либо семантический векторный (Semble), либо текстовый индекс сниппетов (context-mode). Сочетание обоих чистый оверхед, карго-культ и неоправданные траты.

А как вы экономите контекст при работе с ИИ-агентами? Какой стек у вас полетел в продакшене, а какой оказался оверхедом? Жду ваших мнений и кейсов в комментариях.