Откройте свежую сессию Claude Code или Cursor в репозитории, в котором работаете месяцами, и посмотрите, что агент делает до того, как напишет первую строку.
Он листает директории. Грепает символ и получает сорок совпадений. Открывает шесть файлов целиком, чтобы понять, какие из сорока важны. Руками идёт по цепочке импортов. Читает конфиг, чтобы разобраться, как это вообще связано. Где-то посередине задаёт вопрос, на который вы отвечали во вторник.
Ничего из этого не является задачей. Всё это в счёте. И завтра это повторится точно так же, потому что ничего из того, что агент сегодня выяснил, конец сессии не пережило.
Я называю это налогом на холодный старт, и как только начинаешь его мерить, а не ощущать, выясняется, что это крупнейшая единичная статья расходов в большинстве агентских процессов — крупнее, чем само редактирование, часто с большим отрывом.
Куда реально уходят токены
Разберите пару десятков транскриптов агента на то, что исследовалось, а не менялось, — и почти в каждой сессии возвращаются одни и те же четыре вопроса:
- Какой формы эта штука? Раскладка директорий, границы модулей, что где лежит. Выводится заново листингом и открыванием файлов.
- Где определён X и кто его вызывает? Отвечает греп, который возвращает каждое строковое совпадение, включая комментарии, тесты и не относящуюся к делу переменную с похожим именем. Дальше агент открывает файлы, чтобы разобраться.
- Что эта библиотека делает именно в этой версии? Отвечают тренировочные данные, которые часто на мажорную версию позади, — а потом это исправляется тяжёлым способом, когда сигнатура вызова оказывается не той.
- Что здесь было решено и почему? Обычно не отвечает никто. Агент предлагает то, что пробовали и отвергли полгода назад, и либо вы ловите это на ревью, либо нет. Отвечаемым это делает граф решений.
Каждый из этих вопросов дёшев один раз. Проблема в том, что ни один из них не один раз. Они на сессию, на агента и — если вы гоняете несколько агентов параллельно — на воркера. Пять агентов на одном репозитории платят налог на холодный старт пять раз, параллельно, за одну и ту же информацию.
Почему большое окно контекста это не чинит
Интуитивный ответ — закинуть весь репозиторий в модель с большим контекстом и перестать переживать. Не работает, по трём отдельным причинам.
Стоимость масштабируется тем, что вы отправили, а не тем, что было нужно. Загрузить 400 000 токенов репозитория ради вопроса, которому хватило бы 3 000, — это не основательность, это счёт. Умножьте на каждую сессию и каждого воркера.
Внимание деградирует раньше, чем кончается окно. Модель с очень большим окном не одинаково хороша по всей его длине. Материал в середине огромного контекста обрабатывается менее надёжно, чем материал у краёв, — то есть ответ получается одновременно менее точным и более дорогим, что худший из возможных исходов.
Он устарел по построению. Дамп репозитория — снимок. В момент, когда другой воркер закоммитил или вы переключили ветку, контекст описывает дерево, которого больше нет, — и ничто в промпте модели об этом не сообщает. Уверенные ответы про изменившийся код хуже, чем отсутствие ответов.
Чинит это не больший контекст. Чинит правильный контекст, разрешённый, в момент, когда он нужен, — а для того, что не меняется от задачи к задаче, чинит вообще не выводить его заново.
Три слоя, которые действительно снимают налог
Слой 1 — инструкционный (самый дешёвый, делать первым)
Большинство репозиториев не сообщают агенту ничего о том, как в них работать. Всё, что знает команда — где что лежит, какие конвенции, какие директории несущие, а какие архивные, — живёт в головах и в комментариях на ревью.
Записать это скучно и даёт лучшую отдачу из всего списка, потому что это чистый текст, который модель читает один раз за сессию за смешную цену:
AGENTS.md/CLAUDE.mdв корне с правилами, которые действительно важны: конвенции коммитов, что нельзя трогать никогда, какие команды проверяют изменение, политика языка и форматирования.- Навигационные индексы — по одному на директорию любого размера, с описанием, что там лежит. Это заменяет рефлекс «полистать и открыть шесть файлов» одним чтением.
- Правила на уровне директорий там, где у поддерева свои конвенции, с явным правилом приоритета (ближайший предок выигрывает).
- Манифест чтения для типовых задач: «прежде чем трогать биллинг, прочитай эти четыре документа».
Полезная дисциплина: держите жанры раздельно. Файл, который говорит что здесь лежит, — не тот файл, который говорит как здесь работать, и ни один из них не человеческий README. Смешение производит документ, который никто не поддерживает и который агент читает наполовину.
Слой 2 — слой выборки
Греп — это сопоставитель строк, притворяющийся инструментом кодовой интеллектуальности. Он не отличает определение от упоминания в комментарии, не знает, что метод является реализацией интерфейса, и возвращает сорок результатов там, где верен один.
Замените типовые расследования структурными операциями: go-to-definition, find-references, иерархия вызовов, структура проекта. Это разрешённые ответы, а не строковые совпадения, и они возвращают за десятки токенов то, на что цикл «грепнуть и открыть» тратит тысячи.
Для нечётких вопросов, где вы не знаете точной строки, слою выборки нужен бюджет, а не top_k. Это отдельная тема — см. выборку под бюджет токенов: как строится и как измеряется отбор под потолок по токенам.
Слой 3 — слой памяти
Слои 1 и 2 делают расследование дешёвым. Слой 3 его убирает — для всего, что не меняется от задачи к задаче: решения и их обоснование, грабли, за которые уже заплатили, конвенции, которых код не показывает, и текущее состояние того, что в работе.
Ловушка в том, что наивный файл заметок протухает за недели: почти-дубликаты дробят выборку, а устаревшие записи обгоняют актуальные, потому что многословнее. Правила должны работать на записи, а не на чтении. Долговременная память агента разбирает конструкцию целиком.
А если вы гоняете больше одного агента, отказы координации — отдельная категория: двойные claim'ы, тихие зависания, вывод, потерянный вместе с процессом. Это много агентов, один репозиторий.
Измерьте до того, как чинить
Аргументация всего этого рассыпается без чисел, а числа собираются легко. Возьмите десять представительных задач и зафиксируйте по каждой:
| Метрика | Как читать |
|---|---|
| Токены до первой полезной правки | Собственно налог на холодный старт. Разрыв между началом сессии и первой строкой настоящей работы. |
| Всего токенов на выполненную задачу | Главная стоимость. Должна падать вместе с первой метрикой, и сильнее. |
| Правки не в тот файл | Как часто агент менял то, что менять не следовало. Проблема структуры, а не модели. |
| Повторные вопросы | Вопросы, которые агент уже задавал. Прямо меряет, работает ли память. |
| Настенное время до первого готового к ревью диффа | То, что вы реально ощущаете. Включает расследование, которое счётчик токенов прячет. |
Дальше примените только Слой 1 — день письма, без всякого тулинга — и прогоните те же десять задач. По моему опыту первые две метрики двигаются сразу и заметно, и обычно этого достаточно, чтобы обосновать Слои 2 и 3 перед тем, кто держит бюджет.
Порядок, который работает
- Написать инструкционный слой. День. Никаких новых зависимостей. Наибольшая отдача на потраченный час.
- Измерить. Десять задач, до и после. Бэйзлайн нужен, чтобы аргументировать что угодно дальше.
- Добавить структурную кодовую интеллектуальность. Определение, ссылки, иерархия вызовов по MCP, чтобы агент перестал грепать.
- Добавить память. Решения, грабли, конвенции, состояние — читается автоматически, пишется осознанно.
- И только потом параллелить. Веерный запуск до починки холодного старта умножает налог на число воркеров.
Порядок не произвольный. Каждый шаг удешевляет следующий, а прыжок сразу к пятому — что делает большинство команд, потому что параллельные агенты выглядят самой интересной частью, — покупает вам пять агентов, каждый из которых платит полную цену за одно и то же переоткрытие.
Откуда это
Три слоя выше — это форма Hilum Tools, MCP-платформы, которую я строю и ежедневно гоняю против мультирепозиторного воркспейса: девять доменов инструментов на одном сервере, дающих агенту разрешённую структуру, выборку под бюджет, долговременную память, происхождение решений и координацию — вместо грепа и догадки.
Под всеми тремя слоями лежит одно правило, которое стоит прочитать отдельно: когда потребитель сервиса — агент, а не человек, ответ обязан заявлять собственную надёжность. Всё сказанное выше — следствие того, чтобы отнестись к этому всерьёз.
Если вы предпочли бы, чтобы это сделали с вашей кодовой базой, а не строить самому, — для этого есть направление AI-разработка: аудит того, как агенты сейчас падают на вашем репозитории, написанный инструкционный слой, подключённый тулинг и письменная передача того, что изменилось и почему.