Пять паттернов экономии токенов ИИ-агентов

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

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

Первый паттерн касается глобальных инструкций. Файлы вроде AGENTS.md или CLAUDE.md часто превращают в энциклопедию проекта, куда складывают архитектуру, конвенции всех сервисов, правила работы с БД, CI/CD и внешними интеграциями. Проблема в том, что при изменении billing-сервиса агенту не нужны правила мобильного приложения, а при создании миграции — конвенции UI. Глобальный контекст должен содержать только информацию, полезную для большинства задач, а остальное стоит загружать по необходимости.

Второй паттерн — progressive disclosure, постепенное раскрытие информации. Вместо загрузки всей документации агент проходит путь от общей карты проекта к конкретному сервису и задаче, получая знания по мере сужения области. В разных системах это может называться skills, instruction files или commands, но архитектурная идея одна: не загружать всё сразу, а подключать контекст, когда он становится релевантным. По сути это lazy loading, только для знаний о проекте.

Третий паттерн — точки входа и эталонные реализации. Хорошо структурированный репозиторий должен сразу подсказывать агенту базовую структуру приложения, чтобы ему не приходилось восстанавливать архитектуру чтением десятков файлов. Ещё эффективнее ссылки на golden examples: вместо подробного описания того, как должен выглядеть новый message consumer, можно указать на уже существующий эталон. Такой пример часто компактнее страниц документации и снижает риск того, что агент изобретёт новый паттерн там, где в проекте уже есть принятый.

Четвёртый паттерн — кэширование результатов дорогого исследования. Если агент разобрался в цепочке оплаты заказа, прочитав сотни файлов, а через неделю поступает новая задача по той же теме, знание приходится добывать заново. Стабильные и важные особенности системы имеет смысл сохранять: в глобальном контексте, рядом с конкретным сервисом, в task-specific инструкциях или просто в виде ссылки на существующий код. Следующая сессия сможет начать с нескольких сотен токенов структурированного описания вместо повторного чтения файлов.

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

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