24 марта 2026 г.
Размышляя об эффективности обвязки
Размышляя об эффективности обвязки
Сейчас типичное использование инструментов для работы с кодинговыми агентами выглядит так: кто готов платить за жирную подписку, сидит на самой мощной модели, а кто пытается экономить — использует дорогую модель для планирования и что-то попроще для генерации кода.
Еще есть сценарии, когда обвязка выбирает модель на свое усмотрение (даже сам ChatGPT использует маленькую модель-роутер, чтобы принять решение, в каком режиме «думать» над вашим промптом).
Но почему-то (по крайней мере, насколько мне известно) инструменты вроде Claude Code или Codex не применяют подобный подход для оптимизации контекста.
Типичный ризонинг любой задачи выглядит примерно так:
кожаный попросил добавить кнопку, сейчас пойму, что у нас тут за проект. Для этого получу листинг файлов в корне... Ага, вижу README, почитаю. Хм, ничего полезного. Почитаю package.json. Ага, похоже, используется какая-то библиотека. Поищу ее документацию в интернете. Нашел 20 релевантных сайтов, первый в выдаче выглядит подходящим, качаю его... Так, вижу ссылку на документацию, качаю ее. Нашел ссылку на нужную страницу, читаю документацию... Хорошо, теперь поищу исходники, для этого получу листинг папки src. Так, вижу файлы, погрепаю их в поисках строки button. Нашел 45 файлов со вхождением, почитаю их... Примерно понятно, как использовать button, теперь ищу, куда именно добавить кнопку, для этого почитаю еще 50 файлов...
и так далее.
А потом все эти скачанные результаты веб-поиска вместе с HTML-разметкой, запуски консольных команд (например, для установки зависимостей с кучей выхлопа) и прочитанные наугад файлы попадают в контекст и гоняются с каждым запросом до конца выполнения задачи.
Сначала от избыточного контекста модель тупеет, а потом и вовсе срабатывает механизм компактизации, убивая заодно и кэширование.
А пользователь все это оплачивает.
Хотя кажется, что было бы гораздо эффективнее готовить контекст до того, как он попадет в медленную и дорогую модель: сначала супер-быстрая и дешевая моделька могла бы взять на себя тул-коллинг (включая даже вызов MCP) и обработку ответов, выкинуть явно лишнее, оптимизировать нужное, и передавала бы в большую только действительно релевантный код.
Плюсы очевидны, минусов, кроме минорного оверхеда на быструю модель, вроде нет. Что я упускаю? Делает ли так кто-нибудь?