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

Именно эту проблему изучают авторы статьи «Do AI Agents Know When a Task Is Simple?», опубликованной в июле 2026 года. Они не просто зафиксировали неудобство — они формализовали его математически, создали бенчмарк и предложили решение.

Суть проблемы: стратегия «максимального контекста»

Современные LLM-агенты (Claude Code, Cursor, Copilot Workspace и другие) работают по принципу, который исследователи назвали Maximum-Context-First (MCF). Перед любым действием агент сканирует файловую структуру, читает зависимости, анализирует архитектуру проекта и только потом приступает к редактированию. Эта стратегия родилась не от хорошей жизни: слишком много случаев, когда агент, не разобравшись в контексте, вносил разрушительные правки. Поэтому индустрия пошла по пути перестраховки — лучше прочитать лишнее, чем недостаточно.

Но у этой стратегии есть оборотная сторона. На 121 задаче из бенчмарка MSE-Bench стратегия MCF добивается 100% успешности, но средняя стоимость каждого действия оказывается в 12,9 раза выше необходимого минимума. Агент читает 8,5 файлов в среднем на задачу, тратит 4421 токен и делает 16,5 вызовов инструментов — когда для тривиальной правки достаточно одного файла и 340 токенов.

Исследователи ввели метрику Agent Cognitive Redundancy Ratio (ACRR) — отношение реальной стоимости выполнения к минимально достаточной. ACRR равен 1, если агент делает ровно столько, сколько нужно. У MCF этот коэффициент 12,9. При этом парадокс в том, что наибольшая относительная избыточность возникает на самых простых задачах — Level 1, где нужно просто найти и заменить строку в одном файле.

Почему существующие решения не работают

Можно было бы сказать: «Просто делайте агента тупее, пусть не читает лишнего». Но это сломает решение сложных задач. Альтернативный подход — Fixed ReAct, фиксированный цикл «поиск → чтение → правка → тест» — экономит ресурсы (ACRR всего 1,29), но решает только 66,9% задач, потому что никогда не добирается до косвенных зависимостей. Он дёшев, но ненадёжен.

Другой вариант — Adaptive Retrieval, умный адаптивный агент, который масштабирует усилия в зависимости от найденного контекста. Он решает 100% задач с ACRR 1,21 — уже неплохо. Но ему не хватает одного ключевого элемента: предварительной оценки сложности. Агент начинает с полного чтения найденных файлов и всегда запускает тяжёлую проверку, даже когда задача элементарна.

Фреймворк E3: оцени, выполни, расширь

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

На этапе Estimate агент определяет начальную рабочую точку — оценивает глубину вложенности задачи (d), сложность символьной подстановки (s), необходимость рефакторинга (r) и контекстуальную неопределённость (c). Для этого используются лексические маркеры: прямые ссылки на файлы в запросе («замени ... в index.html») сигнализируют о правке одного файла, широкие формулировки («рефакторинг по всей кодовой базе») — о задаче на уровне репозитория. Если ни то, ни другое не ясно, агент делает один поисковый запрос для оценки.

На этапе Execute агент действует строго в рамках оценки. Если задача определена как однофайловая правка — читается только этот файл, делается замена, проходит лёгкая проверка. Никакого сканирования зависимостей, никакого анализа архитектуры.

На этапе Expand, и только если проверка провалилась или уверенность низкая, агент расширяет область на один уровень: читает дополнительные файлы, трассирует зависимости, запускает полную проверку. Цикл повторяется до трёх раз, после чего задача либо решена, либо признана неразрешимой в текущих ограничениях.

Результаты: 85% экономии без потери качества

На бенчмарке MSE-Bench из 121 задачи E3 достигает тех же 100% успешности, что и MCF и Adaptive Retrieval, но со средней стоимостью 18,6 вместо 122,9 у MCF. Это сокращение на 84,9% по скалярной стоимости.

Конкретные цифры впечатляют. E3 сокращает задержку на 58,6%, потребление токенов на 90,9%, количество вызовов инструментов на 52,3%, и число прочитанных файлов на 92,2%. По сравнению с более сильным конкурентом — Adaptive Retrieval — E3 всё равно выигрывает: на 16% меньше стоимости и на 66,8% меньше прочитанных файлов при одинаковой успешности.

На самых простых задачах (Level 1) E3 работает почти как оракул — минимально достаточный путь. На задачах средней сложности (Level 2, переименование символа с косвенными зависимостями) он тратит ровно столько, сколько нужно для трассировки. И только на самых сложных задачах (Level 3, многошаговые изменения с скрытыми зависимостями) E3 разворачивается до полного контекста — но даже здесь он эффективнее альтернатив, потому что до сложной задачи доходит не вслепую, а с накопленным пониманием.

Аналог из инженерии: представьте метод Ньютона-Рафсона для расчёта потоков мощности в электрической сети. Если начальная точка близка к решению — сходимость за три итерации, 100% надёжность. Если начальная точка далека — итерации растут, а при ошибке больше 2,4 метод расходится. Хорошая начальная оценка не есть ответ, но она делает последующее уточнение коротким и стабильным. Именно эту интуицию формализует E3: предварительная оценка — не гадание, а инженерный приём.

Что это значит на практике

Для разработчиков, использующих AI-агенты ежедневно, это исследование объясняет то, что многие чувствовали интуитивно. Когда вы просите Claude Code заменить одну строку, а он тратит две минуты на «анализ проекта» — это не баг, это системная избыточность. Но именно на таких мелочах накапливаются расходы: если за день агент выполняет 50 задач, и 40 из них тривиальные, то 80% бюджета уходит на задачи, которые не требовали и 20% усилий.

Для создателей агентов E3 предлагает конкретный архитектурный паттерн: встраивать эстиматор сложности перед каждым циклом выполнения. Это не требует обучения дополнительной модели — в простейшем варианте это набор лексических правил плюс один поисковый запрос. При этом эстиматор совместим с существующими подходами к маршрутизации усилий (effort routing) — он определяет что и сколько нужно понимать, а маршрутизатор решает, какой модели это поручить.

Авторы уже выпустили валидацию на реальных LLM — LLM-Case с GPT-4o. Реальная модель оказалась заметно экономнее симулированного worst case, но E3 всё равно остаётся самой быстрой и экономной политикой. На сложных задачах, где надёжность становится стохастической, именно самые тяжёлые стратегии с максимальным чтением чаще всего терпят неудачу — некоторые даже упираются в rate limit провайдера. E3 остаётся среди быстрых и надёжных ранов.

Часто задаваемые вопросы

Разве «думать меньше» — это не шаг назад для AI-агентов?

Нет. E3 не призывает агента «думать меньше» вообще — он призывает его думать пропорционально. На простых задачах избыточное размышление не повышает качество, а только тратит токены и время. На сложных задачах E3 расширяется до полного контекста. Идея в том, что глубокое рассуждение — ресурс, и его нужно распределять, а не тратить indiscriminately.

Не сломает ли это решение нетривиальных задач?

Нет, потому что E3 включает цикл Expand. Если минимальный путь не прошёл проверку, агент расширяет контекст и повторяет. На бенчмарке MSE-Bench E3 решает 100% задач — столько же, сколько стратегия полного чтения. Расширение происходит не более трёх раз, что ограничивает верхнюю границу стоимости даже для самых сложных задач.

Как это связано с проблемой «overthinking» у reasoning-моделей?

Прямая связь. Исследования overthinking у o1-подобных моделей показали, что избыточные цепочки рассуждений не только тратят токены, но иногда и ухудшают результат. E3 решает эту проблему на уровне архитектуры агента, а не на уровне промпта: вместо того чтобы надеяться, что модель «сама поймёт, что задача простая», система явно оценивает сложность и ограничивает область выполнения.

Можно ли применить E3 к существующим агентам?

Да. Эстиматор в E3 — это простой интерфейс: он принимает запрос и, при необходимости, делает один дешёвый запрос к окружению. Его можно встроить как middleware перед любым агентным циклом. Авторы показывают, что эстиматор на лексических правилах работает уже хорошо, а LLM-backed эстиматор (когда модель сама оценивает сложность) — естественное следующее улучшение, совместимое с тем же интерфейсом.

Итог

LLM-агенты научились решать сложные задачи, но ещё не научились распознавать простые. Стратегия «собрать максимум контекста, потом действовать» превращает элементарные правки в полноценные аудиты кодовой базы — в 13 раз дороже необходимого. Фреймворк E3 (Estimate, Execute, Expand) решает эту проблему, сокращая стоимость на 85% и количество прочитанных файлов на 92% при сохранении 100% успешности. Следующий шаг — интеграция обучаемых эстиматоров сложности в реальные продуктовые агенты, чтобы «умное бездействие» стало таким же естественным, как «умное действие».