Вот вы просите Claude Code или Cursor найти все места, где вызывается конкретный хелпер — а агент начинает тупо, файл за файлом, перебирать проект, сжигая на этом тысячи токенов. А если проект не маленький, а, скажем, монолит на Go с тремя сотнями эндпоинтов — то это не поиск, а бюджетная катастрофа.

Потому что AI-агенты, при всех их чудесах, не умеют «видеть» код как мы. У них нет памяти о структуре. Каждый раз они заходят в код как в тёмную комнату и включают фонарик.

Тот самый случай, когда хочется сказать: «Подождите, а это вообще нормально?»

codebase-memory-mcp — инструмент, который решает ровно эту проблему. Один статический бинарник, который за секунды строит граф знаний по вашей кодовой базе и отдаёт его AI-агенту через MCP-протокол. Больше не надо гонять дорогие grep-циклы — граф уже содержит все связи, зависимости и вызовы. Авторы утверждают: пять структурных запросов через граф — ~3 400 токенов, против ~412 000 на ту же задачу «в лоб». Разница в 120 раз — это не бенчмарк-маркетинг, это физика задачи.

Кому читать дальше? Разработчикам, которые работают с AI-агентами в нетривиальных проектах и устали от «поиск на 40 секунд, ответ на пять строк». Кому можно пропустить? Если ваш рабочий проект — «блог на Next.js с тремя страницами», скорее всего, контекстное окно и так справляется.

Если просто

Представьте, что ваш проект — это город. Вы просите агента найти «все аптеки, которые работают круглосуточно». Без графа агент обходит каждое здание и читает вывески — долго и дорого. А codebase-memory-mcp заранее строит карту города со всеми вывесками, перекрёстками и даже режимом работы — и когда агент спрашивает, просто подсвечивает на карте нужный квартал.

Технически это граф знаний: функции, классы, вызовы, HTTP-роуты, зависимости между сервисами, связи с инфраструктурой (Dockerfile, Kubernetes-манифесты — да, они тоже попадают в граф). Индексация среднего проекта — миллисекунды, ядро Linux (28 миллионов строк, 75 тысяч файлов) — три минуты. И главное — всё на чистом C, в одном бинарнике, без внешних зависимостей. Данные обрабатываются строго локально, наружу ничего не утекает.

Что это решает

Боль, которую закрывает инструмент — это не «медленный поиск». Это утрата структурного понимания проекта между сессиями агента. Когда каждый новый диалог начинается с нуля, и агент тратит контекст не на решение задачи, а на восстановление картины.

Граф знаний делает две вещи:

  1. Даёт агенту «память» о кодовой базе. Один раз построили граф — и даже после рестарта агента он знает, где какой модуль, кто кого вызывает, где эндпоинты.
  2. Радикально сокращает число инструментальных вызовов. Агент не читает сотни файлов, а делает один графовый запрос — Cypher-подобный синтаксис позволяет спрашивать в духе «покажи все функции, вызывающие main()». Исследовательская статья (arXiv:2603.27277) на 31 репозитории показала 83% качества ответов при 10-кратном сокращении токенов и 2.1× сокращении инструментальных вызовов.

Как попробовать

Буквально одна команда. Для macOS/Linux:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Инсталлятор сам обнаружит установленные AI-агенты (из одиннадцати поддерживаемых: Claude Code, Cursor, Aider, Gemini CLI, Codex CLI, Zed и другие) и пропишет MCP-конфиги. Всё, дальше перезапускаете агента и говорите ему: «Index this project».

С визуализацией графа (3D UI на localhost:9749) — добавляете флаг --ui. На Windows — скачиваете PowerShell-скрипт и запускаете.

Хотите автоматическую индексацию при подключении:

codebase-memory-mcp config set auto_index true

Обновляться тоже просто: codebase-memory-mcp update. Удалить конфиги: codebase-memory-mcp uninstall.

3 сценария с примерами

1. Рефакторинг: найти все вызовы функции-кандидата на удаление

Задача: у вас микросервис на TypeScript, вы подозреваете, что функция formatLegacyDate больше нигде не используется. Хотите убедиться перед удалением.

Вместо того чтобы просить агента просматривать файлы — один запрос через граф:

MATCH (f:Function)-[:CALLS]->(g)
WHERE g.name = 'formatLegacyDate'
RETURN f.name, f.file

Агент получает точный список вызывающих функций и файлов за миллисекунды. Не 40 файлов, а 3 строки ответа.

2. Кросс-сервисный анализ: кто ходит в этот эндпоинт

Задача: переписываете API эндпоинт POST /api/v1/orders/validate в одном сервисе, но боитесь сломать коллег из соседнего сервиса. Агент без графа тупо найдёт определение эндпоинта и всё.

С codebase-memory-mcp можно спросить: какие HTTP-вызовы ссылаются на этот роут из других сервисов. Граф содержит HTTP_CALLS-рёбра с confidence-скорингом — можно получить список файлов и сервисов, где формируются запросы к вашему эндпоинту. Увидели, что соседний сервис дёргает validate с нестандартным телом — теперь вы не сломаете прод.

3. Онбординг в новую кодовую базу

Задача: пришли на проект с 200+ файлами и десятком микросервисов, разбросанных по трём репозиториям. Надо понять, как вообще устроена архитектура.

Просите агента: «Покажи архитектуру». Инструмент get_architecture возвращает языки, пакеты, точки входа, роуты, горячие точки, границы, слои и кластеры — одним вызовом. Если подключен UI — можно открыть трёхмерный граф в браузере и физически «походить» по зависимостям. Кросс-репозиторный режим собирает связи между несколькими проектами в один граф.

Где можно застрять

Первое. Бинарник на C — это прекрасно для скорости, но если вы на macOS и привыкли к «скачал, запустил», готовьтесь к тому, что Gatekeeper будет ругаться. Инсталлятор, по словам авторов, сам снимает карантинные атрибуты и подписывает бинарник ad-hoc — но у меня, честно скажу, к автоматическим скриптам с curl | bash всегда есть лёгкое «ну и ну». Для параноиков: исходники открыты, можно собрать самому или просто просмотреть скрипт перед запуском.

Второе. Индексация 158 языков — это круто, но семантическое разрешение типов через Hybrid LSP обещано только для 10 языков (Python, TypeScript, Go, Rust, Java, C# и несколько других). Если ваш проект на Scala, Elixir или Ruby — синтаксический уровень (tree-sitter) всё равно отработает, но тонких связей на уровне типов ждать не стоит.

Третье. 137 открытых issue на GitHub — для проекта с 12 000+ звёзд это нормально, но говорит о том, что шероховатости есть. Например, я заметила темы про граничные случаи с гигантскими монорепозиториями и про конфликты с кастомными конфигами агентов (не все 11 агентов одинаково гладко конфигурятся на Windows, судя по тикетам).

Кому это нужно

Разработчикам, у которых AI-агент стал частью ежедневного цикла, а не игрушкой на выходные. Особенно если вы работаете с:

  • монорепозиториями (20+ сервисов, большая кодовая база);
  • CI/CD-конвейерами, где агент анализирует pull request автоматически;
  • кросс-сервисными проектами, где важно понимать, кто кого дёргает по HTTP/gRPC/tRPC;
  • архитектурным ревью и онбордингом — граф как документация, которая не врёт.

Кому это не нужно

Тем, кто пишет код в одиночку в проектах до 50 файлов — контекстное окно современных моделей и так всё удерживает, а граф будет избыточным инструментом.

И тем, кто не использует AI-агентов в принципе — codebase-memory-mcp заточен под MCP-протокол, это не самостоятельная IDE-фича, а надстройка над Claude Code, Cursor, Aider и подобными.

Вердикт Веры

Это не магия — это инженерно грамотная попытка дать AI-агентам «глаза и память», которых у них нет от природы.

Мне особенно импонирует, что авторы не стали делать очередной SaaS с отправкой кода на чужой сер

Что читать дальше

Материалы