Почему Cursor пропускает половину вызовов при правках в нескольких файлах?

Если вы работали в Cursor или Claude Code с правками в нескольких файлах — смена интерфейса, переименование функции, выделение модуля, когда затрагиваются десятки или сотни файлов — вы, скорее всего, видели одно и то же: пропущенные вызовы, правки не в том файле, случайный урон общим модулям. Модель «понимает фрагмент», но не систему. В 2026 году Agent уже умеют запускать тесты и открывать PR, однако чем больше команда и старше репозиторий, тем устойчивее этот паттерн сбоя. Корень проблемы часто не в «недостаточно умной» модели, а в отсутствии запрашиваемого, инкрементального и общего кодового knowledge graph (Code Knowledge Graph). Ниже — что это за «карта», почему векторный RAG и сверхдлинный context window всё ещё не хватает, и как инженерным командам построить структурированную «память репозитория» для Agent.

Слепая зона Agent: context window — не «карта»

Типичный pipeline AI programming Agent выглядит так: вопрос пользователя → retrieval релевантных файлов → упаковка в context → генерация diff. Retrieval включает @-файлы, ripgrep, embedding similarity или встроенный codebase index продукта. Эти методы неплохо отвечают на вопрос «какой текст похож на ответ», но систематически проваливаются на «кого затронет изменение здесь». Причины:

• У текстового chunk нет топологии: нарезка ломает цепочки вызовов; два похожих по комментариям метода могут попасть в context вместе, а реальный caller окажется в другом chunk.
• grep знает только строку, не тип: перегрузки, generics, макросы, сгенерированный код и Swift extension делают «одинаковое имя» ≠ «один символ».
• Context budget — игра с нулевой суммой: даже 200 файлов в prompt не показывают, какие 5 из них — узлы на обязательном пути.
• Сессия без состояния: границы модулей после прошлого рефакторинга следующий диалог приходится угадывать заново.

Опытный инженер опирается не на «знание всего репозитория наизусть», а на слои карты: границы модулей, направление зависимостей, кто от кого зависит, где тесты. Кодовый knowledge graph — это вынесенная наружу, машиночитаемая и версионируемая версия этой карты.

Что такое кодовый knowledge graph

В узком смысле это property graph или heterogeneous graph для software engineering: узлы — сущности кода, рёбра — проверяемые отношения. В отличие от общего «knowledge graph», большинство рёбер здесь детерминированно выводится статическим анализом или build graph, а не достраивается галлюцинациями LLM.

Ценность графа не в количестве узлов, а в воспроизводимости multi-hop reasoning: путь «от клика пользователя до SQL в базе» может быть фиксированным, а не пересобираемым моделью каждый раз заново.

Сравнение с векторным RAG: семантическое сходство ≠ структурная связь

Векторный поиск трактует код как абзацы естественного языка — это хорошо для «найти логику, похожую на payment processing». Но следующие задачи по природе — graph traversal:

• Перед удалением deprecated flag перечислить все реальные точки ссылки на if (featureX), включая макросы и generated code.
• При переводе API с sync на async вывести полный call stack по репозиторию и test doubles.
• При разбиении God class найти связные подграфы и внешний fan-out.

На практике используют hybrid retrieval: после классификации intent структурные вопросы идут в graph tools, исследовательские — в vectors; результаты сортируются с приоритетом узлов на graph path, затем обрезаются под context. Только embeddings без рёбер часто упирают merge rate Agent в крупных monorepo с плотными зависимостями.

Сравнение с LSP / IDE index: внутри сессии vs на уровне организации

Language Server даёт jump to definition, find references и rename — это почти те же узлы, что и в графе. Разница в жизненном цикле и потребителе:

• LSP обычно привязан к текущему открытому workspace; у Agent в CI или remote runner часто нет того же LSP instance.
• Rename API — интерактивный сценарий; Agent нужен пакетный и scriptable get_callers(symbol_id).
• На граф можно повесить бизнес-метаданные: owner сервиса, дата deprecated, compliance tags — LSP такие рёбра не моделирует.
• Сравнение веток (main vs feature) в графе — это diff двух подграфов, а не два ручных jump.

Прагматичный путь: LSP / compiler frontend как source of truth, граф как persistence и Agent protocol layer — без дублирования парсеров.

Рекомендуемая архитектура: три слоя памяти, граф в центре

Разделите «понимание репозитория» Agent на три слоя — так проще не смешивать понятия:

Структурный слой (кодовый knowledge graph)

Отвечает: что за код и как он связан. Строится из static analysis, build graph (Bazel/Gradle/Xcode project graph), OpenAPI/Proto. Триггеры обновления: merge, scheduled full rebuild или watch на изменения файлов. Хранение: graph DB или SQLite с adjacency index; наружу — MCP tools.

Семантический слой (векторный index)

Отвечает: какая реализация «похожа» на описание пользователя. Embeddings для тел функций, комментариев, ADR, Issue. Важно делить с графом один symbol_id, иначе retrieval найдёт chunk, но не привяжет символ.

Эпизодический слой (память задач и design decisions)

Отвечает: почему мы так изменили в прошлый раз. PR summary, runbook или Topic-узлы в Memory OS класса OpenHuman. Он не заменяет граф, а помечает рёбра весами вроде «обсуждено» или «deprecated».

Пять классов задач Agent, которые граф улучшает напрямую

1. Cross-file refactor: rename, extract interface, migrate package — пакетные правки по call edges, меньше пропущенных файлов.
2. Bug localization: от top frame stack trace вверх по calls к общему промежуточному слою, а не full-text search по строке ошибки.
3. Onboarding: «entry points payment module» = подграф от UI route до service быстрее, чем README.
4. Test selection: минимальный test set по covers для изменённых узлов — можно оркестрировать на той же машине, что и TestFlight validation pipeline.
5. Security и compliance scan: reachable_from для sensitive API точнее regex.

Как строить: инкрементально, с graceful failure, language-aware

Минимальный pipeline (совпадает с HowTo schema в head):

• Parsing: tree-sitter (multi-language), SourceKit (Swift), rust-analyzer (Rust) и т.п. экспортируют AST symbol table.
• Edges: call resolution можно делать консервативно (false negative лучше false positive); inherit/implement должны быть exact.
• Incremental: hash на уровне файла; при изменении локально инвалидируются соседи в радиусе двух hops.
• Versioning: граф несёт commit_sha; параметры Agent tools должны требовать его, чтобы не смешивать ветки.
• Tool surface: 6–10 high-level API (get_callers, get_module_graph…), без ad-hoc Cypher от модели — меньше injection risk.

{
  "symbol": "PaymentService.charge",
  "callers": [
    {"id": "CheckoutViewModel.submit", "file": "ios/Checkout/VM.swift", "line": 88},
    {"id": "SubscriptionRenewalJob.run", "file": "jobs/renewal.ts", "line": 41}
  ],
  "graph_version": "a3f9c2e"
}

Особенности крупных Apple / iOS codebases

Комбинация Swift, Objective-C, SPM и Xcode project особенно больно бьёт по «чистому text RAG»: extension, conditional compilation и @objc bridge дают рёбра, невидимые статически, но проявляющиеся в runtime. Построение графа должно:

• Идти в macOS-среде, изоморфной Xcode (локальный Mac или Cloud Mac на Mac mini M4), а не на Linux CI с silent skip при ошибке парсинга.
• Строить Module-level edges из .xcodeproj / SPM target dependencies, затем спускаться к symbol level.
• Для Flutter iOS hybrid repo связывать Dart ↔ Platform Channel cross-language edges (ручная разметка + scan generated code).

Индексация CPU- и disk-intensive и долгая — её логично крутить 24/7 на выделенном Cloud Mac; локальный Cursor по SSH/MCP потребляет remote graph API, на ноутбуке остаётся лёгкий client. Это согласуется с выводом из Mac VPS vs Cloud Mac про разделение compute и disk: graph service не должен конкурировать за I/O с oversubscribed VPS.

Разделение ролей с OpenClaw и agentmemory

OpenClaw и подобные multi-channel Agent хороши в оркестрации cron, webhook и внешних tools; кодовый knowledge graph — structured backend для сценария «читать репозиторий». Продукты персональной памяти (Memory Tree в OpenHuman) хранят decision trail и диалог, но не должны заменять call graph текстовым summary.

Рекомендуемая интеграция: зарегистрировать в OpenClaw / Cursor MCP инструменты code_graph_*; Memory OS хранит метаданные вроде «об этом рефакторинге уведомили команду X», а в audit log пишет версию графа при retrieval.

Типичные ловушки и anti-patterns

• «Угадывать» call relations через LLM: нет regression test, после merge граф гниёт.
• Graph out of sync с source: хуже, чем отсутствие графа — Agent правит не те файлы с излишней уверенностью.
• Только file-level nodes: не лучше @folder, не тянет rename/refactor.
• Dump всего графа в prompt: нужны tool calls + multi-hop pruning, не JSON всего repo.
• Игнор generated code и lockfile: Protobuf, GraphQL codegen, Swift macro должны попадать в build hooks.

FAQ

Graph или vector RAG — выбор «или-или»? Нет. Граф — структура, vectors — семантика; связывайте через один symbol_id.

Хватит ли LSP? Для одного человека в одной сессии — частично; для org-level Agent кормите LSP output в граф.

Нужен ли граф маленькому проекту? Стройте, когда Agent «снова пропускает callers»; cost можно размазать managed index service.

Как часто обновлять? Incremental после каждого merge в main; перед long-running task проверяйте graph_version.

Зачем свой граф, если продукт уже индексирует? Если нужны CI integration, compliance audit и единый source of truth между tools.

Зачем Cloud Mac? Persistent graph store, Swift/ObjC parsing, Xcode co-location, remote consumption по SSH для local IDE.

Безопасность? Граф раскрывает module layout и symbol names — права как у source; не пишите в public LLM logs.

И Memory OS? Graph = structural facts; memory = decisions и preferences; комбинируйте на interface layer.

Вывод

Потолок AI programming Agent всё чаще задаёт понимание структуры репозитория, а не один удачный prompt. Кодовый knowledge graph выносит call chains, module boundaries и test mapping в queryable, versioned, auditable data — вместе с vector retrieval и personal memory OS это три взаимодополняющих слоя. Команды в 2026 году, которые по-прежнему полагаются только на «больший context + file search», будут снова платить за пропущенные callers в monorepo с частыми cross-file changes и Apple toolchain projects. Индекс на правильной инфраструктуре (macOS parsing + persistent disk) — минимальная инженерная инвестиция, чтобы Agent перешёл от «умеет писать код» к «умеет менять систему».