Продолжение серии. В прошлой статье я разобрал почему Claude Code ломает проекты и как выстроить защиту от регрессий.
Но в комментариях и в личных сообщениях всплыл вопрос, который я тогда обошёл стороной: а что с самими токенами? Контекстное окно стало миллион, но агент всё равно жрёт его как не в себя. Куда уходят токены? Почему одна и та же сессия с одним и тем же проектом каждый раз начинается с нуля?
Анатомия слепого поиска
Задал Claude Code простой вопрос: «Какие способы оплаты поддерживает мой ХХХ-бот?»
Вот что произошло:
- Грепнул домашнюю директорию на слово «payment» — 3 tool call'а
- Нашёл 6 файлов-кандидатов в разных проектах, прочитал все — 6 вызовов
- Понял что попал не в тот проект, начал искать заново — 4 вызова
- Подключился по SSH к серверу чтобы проверить конфиг — 2 вызова
- Ответил — 15+ вызовов инструментов, 80K+ токенов, 8 минут
Ответ занял ~800 токенов. Всё остальное — навигация. Агент потратил 99% бюджета на то, чтобы понять где искать, и 1% — на сам ответ.
Решение: иерархический контекст
Все три подхода выше решают часть проблемы, но на разных уровнях. Мне нужна была система, которая покрывает все уровни сверху вниз:
Ключевой принцип: агент идёт сверху вниз, а не снизу вверх. Сначала карта → потом проект → потом код. Не grep → read all → hope for the best.
Level 0: Глобальная карта
Добавляется в глобальный файл инструкций агента (~/.claude/CLAUDE.md для Claude Code, .cursorrules для Cursor):
Это ~2KB. Загружается автоматически в каждой сессии. Агент мгновенно знает: какие проекты существуют, где они лежат, на каких серверах запущены.
Level 1: CLAUDE.md проекта
В корне каждого проекта — файл с архитектурой, стеком, ключевыми файлами, командами деплоя:
~3-5KB. Агент читает его когда вы упоминаете проект — и сразу знает всю архитектуру.
Level 1.5 (опционально): Graphify
Для навигации внутри кода — Graphify превращает кодовую базу в граф знаний. Вместо grep'а агент обращается к графу и знает какой именно файл нужен:
Это отдельный уровень между «архитектура проекта» и «читать исходники». Не обязателен, но для больших проектов экономит ещё 30-50% вызовов.
Результаты: замеры
Одни и те же вопросы, одна модель (Haiku — самая дешёвая), одна машина. С иерархией и без.
Тест 1: «Какая архитектура у Проекта A?»
Слепой агент
С иерархией
Tool calls
Grep → читает 4 файла → собирает ответ
Читает CLAUDE.md → отвечает
Тест 2: «Какие из моих проектов используют библиотеку X?»
Слепой агент
С иерархией
Tool calls
Сканирует весь диск
Целевой grep в известных путях
Пропустил 1 из 3 проектов
Нашёл все 3
Тест 3: «Где задеплоен Проект B? Имя сервиса? Логи?»
Слепой агент
С иерархией
Tool calls
Читает конфиги + SSH на сервер
Ответил из контекста
Второй тест — самый показательный. Слепой агент не просто потратил в 22 раза больше вызовов — он дал неправильный ответ, пропустив один проект. Больше контекста → более точные ответы, а не только дешевле.
Почему три файла работают лучше чем RAG
На первый взгляд это выглядит примитивно. Три markdown-файла против полноценного embedding-пайплайна с векторной базой? Но именно в простоте — сила:
Нулевая задержка. CLAUDE.md читается мгновенно — это файл на диске. RAG добавляет 200-500мс на каждый запрос к индексу.
Детерминированность. Вы знаете что агент прочитает. С RAG вы надеетесь что ре-ранкер выбрал правильные чанки. С иерархией — вы сами написали что важно.
Обновление в реальном времени. Поменяли деплой-конфиг? Обновили одну строку в CLAUDE.md. С RAG нужно переиндексировать.
Работает с любым агентом. Claude Code, Cursor, Codex, Gemini CLI — все умеют читать markdown. Не все поддерживают ваш конкретный RAG-сервер.
Масштабирование — файл на проект. 15 проектов = 15 CLAUDE.md по 5KB = 75KB суммарно. Карта проектов — 2KB. Итого 77KB структурированного контекста вместо 500KB-1MB сырых файлов.
Это не значит что RAG бесполезен. Для семантического поиска по документации, для работы с большими кодовыми базами, для ответов на вопросы типа «найди все места где мы обрабатываем ошибки оплаты» — RAG отлично работает. Но для навигации между проектами и быстрого ответа на вопрос «где что лежит» — markdown-иерархия быстрее, дешевле и надёжнее.
Бонус: индексация разговоров
Отдельная проблема: прошлые разговоры с AI содержат архитектурные решения, результаты дебага, заметки о деплое. Но агент не может их искать — каждая сессия начинается с чистого листа.
Я написал парсеры, которые конвертируют логи сессий Claude Code (.jsonl) и экспортированные чаты Claude Desktop в markdown с YAML frontmatter:
Проиндексировав их через Graphify, агент может найти «что мы решили про платёжный флоу на прошлой неделе» без повторных объяснений. По сути — персистентная память между сессиями, построенная на обычных файлах.
Миллион токенов — не решение
С выходом Opus 4.6 контекстное окно выросло до миллиона токенов. Может показаться что проблема навигации исчезла: просто загрузи всё, модель разберётся.
Но исследования показывают обратное. LLM хуже работают когда окружены нерелевантной информацией — это подтверждено множеством работ. Больше контекста — не просто дороже. Это может сделать модель хуже. Явление известно как «lost in the middle»: модель лучше вспоминает информацию из начала и конца контекста, а середину теряет.
Иерархический контекст решает это элегантно: агент получает только нужные файлы, в правильном порядке, на правильном уровне детализации. Не 500KB сырого кода — а 5KB архитектуры, и только потом конкретный файл если нужен.
С чего начать (10 минут)
- Напишите карту проектов в ~/.claude/CLAUDE.md (5 минут) — перечислите проекты, пути, серверы
- Добавьте CLAUDE.md в ваш основной проект (5 минут) — стек, ключевые файлы, деплой
- Задайте агенту вопрос о проекте в новой сессии
- Посмотрите как он отвечает без grep'а
Никаких зависимостей, установок, конфигураций. Три markdown-файла, которые превращают слепого агента в того, кто знает куда смотреть.