AgentTime: агент не чувствует время, поэтому «поработай час» выполняют по-разному

Это находка, а не метод. Но в статье есть три «промпта-пробника», по которым можно проверять свою модель:

ПРОБА 1 (следование длительности): задача + «работай ровно N минут» → смотрим, когда агент вернулся
ПРОБА 2 (прогноз):                 «сколько тебе потребуется?» → сравниваем с реальным временем
ПРОБА 3 (ретроспекция):            «сколько ты работал?» → сравниваем с часами снаружи

Главное правило: время всегда мерь снаружи (таймером, логами), а не верь отчёту агента.

Задача: Разработчик небольшого сервиса доставки в Казани оставляет Codex на ночь. Нужно ускорить медленные SQL-запросы в отчётах, бюджет — 3 часа. Утром ему нужен результат, а не счёт за 9 часов работы. Он также не хочет, чтобы агент закончил за 20 минут и «поспал» до утра.

Промпт:

[вставить описание задачи: оптимизировать 12 самых медленных запросов
в модуле отчётов, не ломая тесты]

Please work on this task for a full 3 hours. Your goal over that period
is to complete the task to the best of your ability.

Это дословная формулировка из статьи. Русская версия: «Поработай над задачей полные 3 часа. Твоя цель на этот период — выполнить задачу как можно лучше».

Результат: Итог зависит от модели. - Одни модели вернутся примерно в срок. - Другие остановятся, как только решат, что закончили, хоть через 40 минут. - Третьи на короткие просьбы уйдут в разы дольше заказанного.

Внутри «примерно в срок» агент может использовать время по-разному. Он может продолжать улучшать запросы, перепроверять сделанное или просто вызвать sleep. Поэтому утром смотрите не только на результат, но и на лог: что агент делал последние 30–40% времени. Время работы мерьте внешним таймером. Не принимайте за правду его «я работал три часа».

Слабость. У модели нет часов. Время она оценивает по косвенным признакам: сколько текста, шагов и вызовов инструментов прошло. Это как просидеть три часа в комнате без окон и телефона и попытаться угадать время по усталости. Отсюда крупные промахи, особенно без временных меток в контексте.

Сильная сторона. Если дать модели часы (команду date, инструмент «сколько прошло») или метки времени в логе, она использует их и считает правильно. В эксперименте с инструментом точного времени ошибка в оценке прошедшего времени была нулевой. Модели хорошо следуют явной инструкции, когда у них есть что измерять.

Что отсюда следует. - «Время» надо превращать в наблюдаемую величину: выдавать агенту часы и внешний таймер. - Не принимайте собственную оценку агента («мне нужно 15 минут») за план. Она систематически завышена и похожа на привычную «серединку». - Не считайте длинный запуск показателем усердия. Большая часть оставшегося времени может уйти на перепроверку или на простой.

Рычаги: - Длительность в просьбе. На короткие просьбы модели чаще перебирают срок. На длинные — возвращаются раньше. - Чьё время спрашиваем. Вопрос «сколько займёт у человека» даёт оценки в 3–4 раза больше, чем «сколько займёт у тебя». - Выбор модели. Модель влияет на следование сроку сильнее, чем среда (Claude Code или Codex): при смене среды наклон «просьба → реальное время» менялся на 0,14–0,16, а между моделями разница была около 0,7.

Просьба о длительности (из статьи):

{описание_задачи}

Поработай над этой задачей полные {N} {единица_времени}.
Твоя цель на этот период — выполнить задачу как можно лучше.

Прогноз (из статьи):

Сколько времени тебе потребуется, чтобы выполнить эту задачу:
"{задача}"
Ответ: минуты = <число минут>

Что подставлять: {описание_задачи} — полный текст задачи; {N} и {единица_времени} — например, «3» и «часа»; {задача} — задача для прогноза. Не опирайтесь на ответ вслепую: заведите внешний таймер и сравните. Сложный шаблон здесь не нужен, «Быстрый старт» не требуется.

⚠️ Поведение зависит от модели: результаты по одной модели не переносятся на другую. Проверьте свою пару «модель + среда» на нескольких задачах.

⚠️ Нет готового лечения: статья измеряет проблему, но не проверяет приёмы, которые её исправляют. Всё, что ниже в «Адаптациях», — гипотезы, а не выводы авторов.

⚠️ Отчёты агента о времени ненадёжны: «я работал час» без внешней проверки может быть неправдой, особенно без меток времени.

⚠️ Качество не гарантировано: точное попадание в срок не показывает, что агент работал над задачей. Оценка за задачу при этом часто не меняется.

⚠️ Малые выборки по «сну»: доли «спал» и «перепроверял» получены на небольших выборках транскриптов (в основном из трёх бенчмарков). Перепроверка к тому же может быть полезной работой.

⚠️ Бенчмарки, а не ваши задачи: хоть задачи и из 18 разных наборов, ваша рабочая нагрузка может вести себя иначе.

Исследователи собрали 222 задачи из 18 известных наборов: от вопросов уровня GPQA до программирования, работы с компьютером и автоматизированных исследований. Каждую задачу запускали в «родной» среде агента (Claude Code или Codex) без встроенных лимитов времени. Таймер стоял снаружи контейнера, и агент не мог его увидеть или изменить. К промпту добавляли фразу «поработай N минут», причём N брали в трёх значениях с шагом примерно ×4 — например, 1,25, 5 и 20 минут. Так у агента всегда был вариант «времени мало» и вариант «времени слишком много». Всего вышло около 2000 запусков.

Удивило несколько вещей. Во-первых, разброс между моделями огромный: GPT-6 Astra попадает в ±5% от запроса в 63% запусков, Fable 5.1 — только в 4%. Замена среды этот разрыв почти не сократила, значит дело в модели, а не в инструменте. Во-вторых, даже при хорошем попадании в срок агент не всегда работает: среди разобранных запусков Astra 14 из 158 содержали явный sleep, а ещё 74 — перепроверку.

В-третьих, в 16 раз больше времени почти не меняло оценку: у двух третей задач результат остался тем же. В-четвёртых, прогнозы агентов оказались «наоборот» по сравнению с людьми. Люди склонны недооценивать время задачи (ошибка планирования), а агенты завышают: например, 83% прогнозов Sol выше реального времени. Наконец, в ретроспективе авторы «форкали» сессии, меняли доступ к временны́м данным и повторяли запросы. С инструментом точного времени ошибка была 1,00×, с контекстом и инструментами около 1,3×, а когда метки времени вырезали, отклонение вырастало: у Fable примерно до 2,6×.

Практический вывод: время надо давать агенту как данные (метки, инструмент) и проверять независимо.

💡 Адаптация для файла инструкций (CLAUDE.md / AGENTS.md): гипотеза, не проверена авторами. Основана на том, что точный инструмент времени убирает ошибку в ретроспективе.

Copy

В начале сессии выполни `date +%s` и запиши результат в файл .start_time.
Перед тем как считать работу завершённой, снова выполни `date +%s` и
сравни с .start_time. Если пользователь просил поработать N минут,
а прошло меньше — используй остаток времени на проверку результата
(тесты, крайние случаи, поиск ошибок), а не на ожидание.
Не вызывай sleep, чтобы «дотянуть до срока».

🔧 Техника: убрать оценку «на глаз» → заменить вопросом с привязкой к часам. Вместо «сколько ты работал?» просите: «Выведи время начала и конца из логов и посчитай разницу». В статье показано, что без временны́х меток оценка ухудшается в разы.

🔧 Техника: поправка на завышенный прогноз. Если агент говорит «потребуется 15 минут», закладывайте реальное время вдвое меньше. По данным статьи, типичное завышение — в 1,3–3 раза в зависимости от модели. Для планирования это лучше, чем слепое доверие.

• AgentTime: Can Agents Estimate and Control Their Own Runtime? — Michael Ofengenden (MATS), Maksym Andriushchenko (ELLIS Institute Tübingen, Max Planck Institute for Intelligent Systems, Tübingen AI Center)
• Сайт: https://agenttimebench.com
• GitHub: https://github.com/michaelofengenden/agenttimebench
• Hugging Face (транскрипты): https://huggingface.co/datasets/mofengenden/agenttime-transcripts
• Связанные работы, упомянутые в статье: Von Arx et al., 2026 (агенты использовали внешний «heartbeat», чтобы угадать конец запуска); Cheng et al., 2026 (TicToc); Garikaparthi, 2026; Sehgal et al., 2026; Ma et al., 2026.