Как экономить токены AI-агентов при работе с большой кодовой базой: 5 паттернов

Проблема: токены тают на исследование

AI-агенты глубже интегрируются в процесс разработки — уже не только генерируют функции, но исследуют проекты, ищут файлы, анализируют архитектуру, запускают тесты. На больших кодовых базах возникает острая проблема: значительная часть токенов расходуется до написания первой строки кода. Перед небольшим изменением агенту может потребоваться изучить структуру репозитория, найти нужный сервис, прочитать документацию, разобраться с conventions, посмотреть как устроены тесты. При следующей задаче часть этого исследования повторяется снова. На маленьком проекте это незаметно, но чем больше репозиторий, тем дороже исследование системы.

Попытки скормить агенту всю документацию сразу или использовать более дешёвую модель дают либо небольшой эффект, либо переносят расход токенов в другое место. Правильный подход — рассматривать управление токенами как задачу управления контекстом, применяя принципы lazy loading, локальности данных, кэширования, разделения ответственности к информационному потоку AI-агента.

Пять паттернов оптимизации контекста

1. Minimize Permanent Context

Дочка складирования знаний выглядит всегда одинаково: создаём AGENTS.md или CLAUDE.md и начинаем складывать туда всё больше информации. Сначала архитектура и структура репозитория, потом правила написания кода, conventions сервисов, особенности работы с БД, тестированием, CI/CD и интеграциями.

Проблема: весь этот набор становится постоянным контекстом. При изменении billing-сервиса агенту вряд ли нужны правила разработки мобильного приложения, но если они в глобальном контексте, модель получает их снова и снова. Глобальные инструкции должны быть картой проекта (где находится информация?), а не энциклопедией (что вообще рассказать?). Корневой AGENTS.md указывает, где лежат детальные инструкции для auth, billing, database, infrastructure — всё остальное загружается по требованию.

2. Progressive Context

Знания организуются слоями: global context → domain/service context → task-specific instructions → reference implementation → relevant source code. Для задачи добавления нового payment provider агент проходит путь: AGENTS.md → services/payments/AGENTS.md → skills/add-payment-provider.md → existing provider implementation → relevant source files. Для мобильного приложения путь совершенно иной, для инфраструктуры — третий. Вместо 20 000 токенов на «всё об проекте» получается: global context (500) + service context (700) + task instructions (600) + reference (800) + source files (2500). Большая часть проектных знаний существует отдельно и попадает в контекст только когда становится релевантной.

3. Reduce Exploration

Даже при небольшом постоянном контексте остаётся крупный источник расхода — исследование кодовой базы. Агенту нужно выяснить, где обработчики платежей, какой сервис публикует события, какой message broker, где consumers, как создаются уведомления, где шаблоны, как их тестируют. Хороший репозиторий предоставляет точки входа: project map с разделами (HTTP handlers: services//handlers/, Business logic: services//domain/ и т.д.), golden examples (для нового message consumer ссылка на services/orders/consumers/order-created/ показывает структуру, naming, обработку ошибок, logging, взаимодействие слоёв, тестирование), search before read (сначала поиск через rg, git grep, LSP-tools, потом чтение).

4. Reuse Knowledge

Когда агент исследует оплату заказа, он раскрывает цепочку: HTTP request → order service → billing service → payment provider → payment event → message broker → order consumer. Для этого читает сотни файлов. Затем сессия закончена, новая задача приходит через неделю, и новый агент начинает исследование заново.

Это дублирование знаний нужно исключить. Если исследование выявило важную и стабильную особенность системы, результат стоит сохранить в docs/payment-flow.md с кратким описанием, списком файлов и ссылкой на reference implementation.

Следующая AI-сессия начнёт с сотен токенов структурированного описания вместо повторного чтения файлов. Полезные знания хранятся в AGENTS.md, service instructions, documentation, task-specific skills, architecture notes, golden examples или code comments в зависимости от области действия.

Получается цикл: Expensive discovery → Structured knowledge → Cheap future retrieval.

5. Keep Context Clean

Обратная сторона предыдущего подхода: если каждое полезное открытие сохранять, документация постоянно растёт и начинается context pollution — устаревшие инструкции, неактуальные примеры, забытые соглашения сосуществуют с новыми. Контекст нужно регулярно очищать: удалять устаревшую информацию, актуализировать примеры, убирать дублирование. Как и в коде, устаревшую документацию лучше удалить, чем оставлять с комментарием.

Все пять паттернов работают вместе: минимизируем постоянный контекст, загружаем знания слоями по мере необходимости, помогаем агенту меньше исследовать через точки входа, не повторяем дорогое исследование дважды и удаляем устаревшую информацию. Результат — расходы токенов снижаются не за счёт более дешёвых моделей, а за счёт управления тем, какую информацию видит агент и когда.