ИИ не должен угадывать время: как контролировать срок фоновой задачи

Что проверяли исследователи

В публикации The Decoder от 30 августа 2026 года пересказано исследование двух участников программы MATS. Они просили Claude Code и Codex оценить длительность задания заранее, выполнить его, а затем сообщить, сколько времени прошло. Это испытание программирующих агентов, не диспетчерских служб.

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

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

Где возникает рабочая проблема

Предлагаемый редакционный пример — помощник, который готовит утреннюю сводку незакрытых сервисных заявок. Диспетчеру она нужна до начала распределения работ. Ответ «почти закончил» бесполезен, если он не связан с сохранёнными карточками и фактическим временем выполнения.

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

Не просите модель вычислять остаток времени по длине переписки или количеству прочитанных заявок. Дайте ей результат инструмента, а прекращение работы поручите внешнему контроллеру. Самооценка агента может служить комментарием, но не механизмом остановки.

Что сохранять до остановки

Разделите сводку на независимые карточки. После каждой завершённой записи сохраняйте идентификатор заявки, использованные сведения и статус проверки. Это позволяет отдать диспетчеру частичный результат, а не потерять всю работу из-за одного зависшего запроса.

• В готовой части перечислите только действительно обработанные заявки.
• В остатке сохраните идентификаторы непрочитанных и неразрешённых карточек.
• Ошибку источника помечайте отдельно от отсутствия проблемы у клиента.
• Для возобновления укажите последнюю подтверждённую запись и версию входной выборки.

Сохранение файла тоже нужно проверить. Сообщение агента о записи не гарантирует существования документа. Контроллер должен получить подтверждение хранилища, а при продолжении прочитать сохранённое состояние, прежде чем начинать следующую порцию.

Что происходит на границе срока

Заранее решите, разрешено ли завершить уже начатую операцию. Для чтения это может быть небольшой дополнительный интервал, для записи в рабочую систему нужен определённый протокол. Нельзя оборвать действие и затем автоматически повторить его, не проверив, применилось ли оно.

В уведомлении диспетчеру укажите, что готово, что не успело и где требуется ручная проверка. Не заменяйте этот список общим процентом, который модель придумала по ощущению. Если результат неполон, это должно быть видно до начала использования.

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

Как испытать ограничение времени

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

Не переносите численные результаты coding-бенчмарка на свою сводку. Соберите собственные измерения времени и качества при типичных размерах очереди. Полезность такого помощника определяется тем, получает ли диспетчер проверяемый результат к своему рабочему сроку.