TL;DR
Когда автономный AI-агент (Claude Code, Cursor, Codex) получает задачу, он не может остановиться и спросить «а что вы имели в виду?» — он сам додумывает недостающие детали через дополнительные попытки и рассуждения. Каждая пропущенная деталь превращается в токены: агент тратит их на то, что вы могли бы просто сказать заранее.
Учёные обнаружили: если убрать из задачи всё, кроме короткого описания «что нужно сделать», агент решает её так же успешно, но тратит на 30% больше токенов и делает на 16% больше попыток — и так на каждой проверенной задаче. При этом абстрактные критерии («результат должен соответствовать требованиям») почти не экономят токены — агент их будто пропускает мимо ушей. А конкретные примеры («если на входе X, на выходе должно быть Y») реально сокращают работу агента, потому что дают точный ориентир, что проверять.
Самое неожиданное: неаккуратно вставленный сырой лог ошибки иногда дешевле красиво оформленного технического задания — потому что называет точное место проблемы, а причёсанная спецификация без этой детали заставляет агента искать её самостоятельно. И ещё: пухлые шаблоны и инструкции окупаются только когда агент работает в быстром режиме размышлений — на максимальном уровне «раздумий» лишние детали почти не помогают, потому что модель и так дорассуждает до всего сама.
Что показало исследование
СПЕЦИФИКАЦИЯ ЗАДАЧИ → ЭФФЕКТ НА РАСХОД ТОКЕНОВ
Полное ТЗ (8 разделов) → базовая стоимость
Только описание "что нужно" → +30% токенов, +16% попыток, успех тот же
Убрать конкретные примеры/тест-кейсы → +7% попыток (единственный раздел с изолированным эффектом)
Убрать абстрактные критерии → эффекта почти нет
Сырой лог ошибки без оформления → часто ДЕШЕВЛЕ полного ТЗ
РЕЖИМ РАЗМЫШЛЕНИЙ АГЕНТА → ВЛИЯНИЕ ДЕТАЛИЗАЦИИ
Быстрый режим (low effort) → разница между лучшей и худшей формулировкой ×2.1
Максимальный режим (max effort) → разница падает до ×1.6
Пример применения
Задача: Вы поручаете Cursor Agent (или Claude Code) исправить баг в скрипте Telegram-бота: он неправильно считает скидку при заказе больше 3 товаров. Хочется, чтобы агент не «гулял» по коду лишние 10 минут и не сжигал токены впустую.
Промпт (дорогой вариант — только описание):
Бот неправильно считает скидку при заказе больше 3 товаров, исправь.
Промпт (эффективный вариант — с конкретикой):
Бот неправильно считает скидку при заказе больше 3 товаров.
Вот лог ошибки, где видно, какая функция и файл срабатывают неправильно:
{вставить реальный traceback или вывод теста}
Конкретные случаи, которые ДОЛЖНЫ работать после исправления:
- 4 товара по 500 рублей → скидка 10%, итог 1800 рублей
- 2 товара по 500 рублей → скидка не применяется, итог 1000 рублей
Проверь оба случая перед тем, как считать задачу решённой.
Результат: во втором варианте агент сделает меньше «разведочных» шагов — лог сразу указывает файл и функцию, а конкретные примеры задают чёткую цель проверки. Итог: меньше кругов работы, меньше токенов, тот же результат. Если вы используете режим глубокого/максимального размышления — разница будет заметно меньше, но всё равно в пользу конкретики.
Почему это работает
Автономный агент не может уточнить задачу в процессе работы — недостающая информация восполняется не вопросом, а дополнительным поиском и рассуждением, и это стоит токенов. Абстрактные формулировки требований («должно соответствовать спецификации») не дают агенту точки опоры — он не может проверить по ним результат, поэтому просто их игнорирует.
Модель хорошо цепляется за конкретные, проверяемые ориентиры: «если X, то Y» — это то, что можно реально протестировать. Именно поэтому конкретные тест-кейсы работают, а абстрактные критерии — нет. И именно поэтому сырой лог ошибки часто эффективнее вылизанного ТЗ: он называет точное место проблемы, экономя агенту шаги на поиск.
Рычаги управления: - Работаете в быстром режиме (обычный чат, low/default reasoning) → детализация промпта резко экономит токены, вкладывайтесь в конкретные примеры. - Работаете в глубоком режиме (extended thinking, max effort) → экономия от детализации меньше, можно писать короче. - Вставляйте реальные логи/ошибки как есть, не оформляйте их в красивый текст — сырой контекст с точной локализацией часто дешевле. - Замените списки абстрактных требований на 2-3 конкретных примера входа/выхода — это единственный тип детали, который реально снижает расход.
Шаблон промпта
Задача: {краткое описание проблемы}
Вот сырой лог/вывод ошибки, где видно, что именно ломается:
{вставить лог, traceback, вывод теста как есть}
Конкретные случаи, которые должны работать после исправления (это важнее всего):
- Если {условие 1} → должно получиться {результат 1}
- Если {условие 2} → должно получиться {результат 2}
- Если {условие 3} → должно получиться {результат 3}
Проверь эти случаи перед тем, как считать задачу выполненной.
Не тратьте время на длинные списки формальных требований и «критериев успеха» — исследование показало, что они почти не влияют ни на результат, ни на экономию. Вместо этого потратьте это время на 2-3 конкретных примера.
Ограничения
⚠️ Узкая проверка: эффект измерен на одной модели (Kimi K3) и всего пяти задачах. Разброс между задачами огромный — от 13% до 115% — поэтому нельзя считать цифры универсальными, эффект нужно проверять на своей задаче.
⚠️ Экономия ≠ качество: детализация снижает расход токенов, но не повышает шанс правильного решения — агент решает задачу одинаково успешно и с деталями, и без них, просто дороже.
⚠️ Эффект тает при глубоком размышлении: если агент работает в режиме максимального reasoning, выгода от детализации промпта резко падает — не ждите той же экономии.
⚠️ Разброс между одинаковыми запусками не лечится формулировкой: повторный запуск одного и того же промпта даёт разброс токенов ×1.34 независимо от того, как написана задача — это свойство модели и инфраструктуры, а не текста.
Как исследовали
Команда взяла пять задач из SWE-bench Verified (реальные баги в открытых Python-проектах) и для каждой создала 12 вариантов постановки задачи: от полного технического задания с 8 разделами (по шаблону GitHub Spec Kit) до урезанных версий, где убирали то один раздел, то почти всё, плюс два «якоря» — сырой лог ошибки и версия с готовым решением (для проверки методики). Каждый вариант прогнали на трёх уровнях «усилия размышления» и повторили 15 раз — итого 2700 запусков агента Kimi K3.
Удивление в том, что убирание деталей не портит результат, но стабильно повышает стоимость — и эффект нелинейно зависит от режима размышления модели: чем глубже модель рассуждает сама, тем меньше ей нужна подсказка извне. Ещё исследователи проверили, можно ли предсказать стоимость новой задачи заранее: оказалось, что один дешёвый тестовый запуск (около 11 центов) снижает ошибку прогноза с 161% до 36% — то есть выгоднее один раз протестировать задачу, чем гадать по аналогии с другими.
Ресурсы
Jakub Smékal, Stanford University. "Can your AI agent be cheaper? Investigating the effects of task specifications on token spend in agentic coding tasks". Ссылки на SWE-bench Verified, шаблон GitHub Spec Kit, сравнение с работой Bai et al. "How do AI agents spend your money?" (2026).