Преодолеваем границы возможного: каждую — буквально каждую — отработанную рутину автоматизируем инструментами. Даже создание запросов другим агентам. А чтобы агент работал точно, им нужен не «весь контекст», а верный контекст. Об этом — контекст-инженерия. Взгляд с разных перспектив.
У инженера есть десятки отработанных рутин: собрать отчёт, проверить логи, развернуть окружение, сформулировать задачу подрядчику. Прорыв агентского подхода в том, что каждую такую рутину можно превратить в инструмент, которым агент пользуется сам. Ты перестаёшь выполнять — ты строишь рычаги.
И граница сдвигается дальше, чем кажется: даже «попросить другого специалиста» — это рутина. Значит, и создание запросов другим агентам можно сделать инструментом. Автоматизация поднимается на уровень выше — туда, где инструменты порождают инструменты, а агенты ставят задачи агентам.
Пять хорошо спроектированных инструментов сильнее двадцати пересекающихся. Если ты сам не можешь сказать, какой инструмент применить в ситуации, — не сможет и агент. Цель — оптимальное покрытие, не исчерпывающее.
Целую рутину можно упаковать как «навык» (папка инструкций, скриптов и ресурсов, SKILL.md), который агент подгружает только когда он нужен. Это и есть твой опыт, переданный агенту.
Важная смена оптики: инструмент пишут под агента, а не под человека. У агента другие «аффордансы» — он иначе воспринимает возможные действия и иначе ошибается. И ещё: каждое определение инструмента занимает место в контексте. Отсюда — следующая тема.
Почему это критично: у модели ограниченный «бюджет внимания», и с ростом контекста наступает «context rot» — точность падает, модель теряет нужное среди лишнего. Это не баг, а прямое следствие архитектуры трансформера: каждый токен внимает каждому, число связей растёт как $n^2$. Больше — не значит лучше.
Отсюда — приёмы контекст-инженерии: подгрузка по требованию (just-in-time: хранить пути/запросы, доставать данные на лету через инструменты, как Claude Code с grep и head); прогрессивное раскрытие (контекст копится по мере исследования); компактизация (сводка у предела окна и рестарт; чекпоинты через git-коммиты и файлы прогресса); структурные заметки (память вне окна); и суб-агенты — каждому даём ровно тот контекст, что нужен, а основной диалог хранит только сводки. Принцип один: каждый токен драгоценен.
Так замыкается идея: рутину делегирования мы тоже инкапсулировали. Инженер проектирует как агенты делят работу и общаются, — а конкретные запросы порождаются автоматически. Это и есть преодоление границы: ты управляешь системой агентов, а не выполняешь задачи поштучно.
Любая твоя рутина — будущий инструмент. Ты строишь рычаги и проектируешь систему, а не выполняешь работу руками. Опыт превращается в навыки, которыми пользуются агенты.
У агента другие аффордансы и скудный контекст. Инструмент должен быть понятен агенту, иметь ясный контракт и не съедать внимание. Пиши под исполнителя, а не под себя.
Контекст — дефицитный ресурс. Экономь токены: подгружай по требованию, выноси тяжёлое в код, дроби работу на суб-агентов, храни сводки. Архитектура важнее «интеллекта».
Инструменты делают инструменты, промпты порождают промпты, агенты ставят задачи агентам. Автоматизация рекурсивна — и именно так раздвигается граница возможного.
Соберём. Каждая отработанная рутина — кандидат в инструмент; хороший инструмент чёток, экономен и комбинируем; контекст — дефицитный ресурс, которым управляет контекст-инженерия; а делегирование между агентами — тоже автоматизируемая рутина. Инженер перестаёт выполнять и начинает проектировать систему рычагов.
Это прямое продолжение роли инженера-проектировщика: вооружённый алгеброй, доказательствами и инструментами, человек поднимает автоматизацию на уровень выше — и преодолевает собственную границу, как спутник преодолевает орбиту.