Агенты на Qwen3.6-27B и Qwen3-4B не укладываются в тайм-бюджет без подсказок harness

Если сказать агенту «у тебя 30 минут», он не станет работать ровно 30 минут. Авторы свежего препринта на arXiv проверили это на двух небольших моделях: Qwen3.6-27B на пяти соревнованиях из MLE-Bench Lite и Qwen3-4B на текстовой игре Zork I из набора Jericho. Обе задачи выбрали не случайно: в них дополнительное время реально может улучшить результат. Вывод получился неудобный. Агенты не умеют ни укладываться в дедлайн, ни осмысленно использовать запас.

Почему одного промпта мало

В базовой постановке бюджет упоминается только в тексте задачи. Harness, то есть обвязка, которая запускает агента и исполняет его команды, никак не сообщает, сколько времени прошло. Агент остаётся без часов. Авторы называют три причины провала:

• нет обратной связи по времени: модель не видит, сколько секунд уже потрачено;
• нет оценки длительности действий: агент не может заранее понять, что обучение модели или долгий запуск не поместятся в остаток;
• нет выученной связи между бюджетом и стратегией: короткий лимит не заставляет его выбирать более простой план, длинный не побуждает копать глубже.

Вторая причина особенно важна для MLE-Bench. Там один неверно выбранный шаг, например запуск тяжёлого обучения, съедает остаток лимита целиком. Ошибка в планировании тут оказывается ошибкой в оценке времени.

Что помогло, а что нет

Исследователи проверили два класса вмешательств. Первый работает на уровне harness: показать агенту тайминги и принудительно обрывать работу по дедлайну. Второй обучает саму модель с помощью reinforcement learning, а именно GRPO с наградой, учитывающей бюджет.

С harness всё довольно прямолинейно. Для Qwen3.6-27B простая подача информации о времени заметно улучшила соблюдение бюджета, причём измеримого падения качества не было. Хуки принудительного завершения подтянули дисциплину ещё сильнее. Это дешёвое решение: модель трогать не нужно, достаточно изменить обвязку.

RL дал более неоднозначную картину. На Zork I GRPO довёл соблюдение бюджета почти до идеала и обобщился на бюджеты, которых не было в обучении. Модель, судя по всему, действительно научилась понимать, когда пора остановиться. Но на MLE-Bench обучение не улучшило итоговые метрики по сравнению с необученным агентом в той же обвязке.

Главная находка в другом. Даже когда агента заставили укладываться в лимит, он не стал использовать лишнее время продуктивно. Обученные политики часто заполняют оставшиеся минуты повторяющимися действиями. А при обучении сразу на нескольких бюджетах GRPO склонен схлопываться к стратегии, выученной под самый короткий лимит. Получается, что дедлайн модель уважает, но длинный бюджет не превращает в более сильное решение.

Практика для разработчиков агентов

Самый надёжный вывод из работы: не полагайтесь на промпт. Если у агента есть бюджет, дайте ему таймер в контексте и жёсткий обрыв на уровне инфраструктуры. Это не требует дообучения и, судя по результатам на 27B-модели, не ломает качество.

Второе: не принимайте соблюдение лимита за эффективность. Метрика «уложился в срок» должна идти рядом с метрикой результата при нескольких бюджетах. Если качество не растёт с ростом лимита, агент просто сжигает время.

Третье: при RL-обучении под разные лимиты стоит следить за схлопыванием к короткому режиму. Нужны отдельные проверки на длинных бюджетах и, возможно, награды, которые поощряют полезное использование запаса, а не только его соблюдение. Авторы прямо называют этот разрыв между дисциплиной и продуктивностью центральной нерешённой проблемой для агентов с условием по бюджету.

Ограничения работы тоже очевидны: две небольшие модели и два бенчмарка. Переносить выводы на крупные закрытые системы без проверки не стоит. Но как диагностика типичных ошибок тайм-менеджмента у агентов препринт полезен.