# Память для AI-агента: граф знаний, который не сжирает 120X токенов и живёт прямо у вас на диске

- Site: VeraPoint News
- Section: Инструменты
- Date: 2026-06-24
- Canonical: https://verapointmedia.com/tools/deusdata-codebase-memory-mcp/
- Markdown: https://verapointmedia.com/tools/deusdata-codebase-memory-mcp.md
- Summary: codebase-memory-mcp индексирует кодовую базу в граф знаний за секунды, радикально сокращая число токенов при работе с AI-помощниками. Что это даёт разработчику на практике, где подвох и к...
- SEO title: Память для AI-агента: браузерная отладка и проверка сайтов AI-агентом
- SEO description: codebase-memory-mcp индексирует кодовую базу в граф знаний за секунды, радикально сокращая число токенов при работе с AI-помощниками. Что это даёт разработ
- Target queries: Память для AI-агента; Память для AI-агента github; что такое Память для AI-агента; как использовать Память для AI-агента
- Tags: #mcp #devtools #code-intelligence #knowledge-graph #claude-code #cursor
- Image: https://verapointmedia.com/static/content-assets/tools/deusdata-codebase-memory-mcp/cover.webp

## Sources

- https://github.com/DeusData/codebase-memory-mcp
- https://deusdata.github.io/codebase-memory-mcp/
- https://tree-sitter.github.io/tree-sitter/
- https://arxiv.org/abs/2603.27277

---

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

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

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

[codebase-memory-mcp](https://github.com/DeusData/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:

```bash
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-скрипт и запускаете.

Хотите автоматическую индексацию при подключении:
```bash
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 с отправкой кода на чужой сер

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

- [Все материалы про AI-агентов](/topics/ai-agents/)
- [Что такое AI-агент простыми словами](https://verapointmedia.com/guides/chto-takoe-ai-agent-prostymi-slovami/)
- [Все материалы про AI-инструменты](/topics/ai-tools/)
- [Как отличить рабочий AI-инструмент от красивой демки](https://verapointmedia.com/guides/kak-otlichit-rabochiy-ai-instrument-ot-krasivoy-demki/)

## Материалы

- [DeusData/codebase-memory-mcp] DeusData/codebase-memory-mcp: https://github.com/DeusData/codebase-memory-mcp
- [deusdata.github.io] supporting context: https://deusdata.github.io/codebase-memory-mcp/
- [tree-sitter.github.io] supporting context: https://tree-sitter.github.io/tree-sitter/
- [arxiv.org] supporting context: https://arxiv.org/abs/2603.27277