Агент остановился сам: новый источник отказов

В публикации о подготовке Astra к релизу OpenAI описала вещь, которая до сих пор в разговорах о надёжности не фигурировала: монитор, способный прервать выполняемую задачу. Формулировка вендора прямая — система может пометить законную активность как потенциальное злоупотребление, «включая работу, которая не выглядит напрямую связанной с кибербезопасностью, и задачи, в которых агент работает продолжительное время». Дальше — самое важное для тех, кто работает через API: в ChatGPT и Codex у пользователя спросят подтверждение, а на других поверхностях задача просто остановится. Это новый источник отказов, и он не похож ни на один из привычных.

Что именно написано

Три факта из публикации вендора, без пересказа.

Astra признана достигшей уровня Critical по кибербезопасности в рамках Preparedness Framework OpenAI — первая модель, получившая такое обозначение. Это означает, по формулировке компании, что при наличии инструментов и доступа модель способна находить неизвестные ранее уязвимости и разрабатывать способы их эксплуатации во многих хорошо защищённых системах без пошагового руководства человека.

Из-за этого усилены защиты, в том числе мониторинг, способный остановить потенциально несанкционированную активность.

Побочный эффект назван открыто. Дополнительные проверки, пишет вендор, могут иногда замедлять, приостанавливать или останавливать законную работу, включая защитную кибербезопасность. И отдельно — что под это может попасть работа, не связанная с кибербезопасностью напрямую, и длительные агентские задачи.

Отдельно стоит отметить, что компания это не прячет, а публикует до релиза. Для планирования это полезнее, чем обнаружить механизм самому.

Почему для API это хуже, чем для чата

Ключевая асимметрия, ради которой стоит читать дальше.

В ChatGPT и Codex остановка монитором превращается в вопрос пользователю: подтвердите действие, чтобы продолжить. Неприятно, но работа не теряется — человек за экраном разбирается.

На API человека за экраном нет. По формулировке вендора, задача останавливается. Ваш код получает не «подтвердите», а прерванный процесс.

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

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

Что это значит для архитектуры

Пять требований, которые из этого следуют. Все они полезны и без монитора, но теперь становятся обязательными.

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

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

Отличайте «не закончил» от «закончил». Прерванная задача не должна выглядеть как выполненная. Явный статус завершения, а не отсутствие ошибки.

Логируйте момент и причину остановки. Иначе вы не отличите монитор от таймаута, от отказа маршрута и от собственного бага — что писать в логи.

Ставьте предел на возобновление. Задача, которую перезапускают бесконечно, — это счёт без результата.

Первые два пункта — это то, что отличает агента, готового к проду, от демонстрации. Их обычно откладывают; теперь у этого появилась цена.

Что делать с длинными задачами

Практический вывод, специфичный именно для этого механизма.

Раз риск растёт с длительностью, длинную задачу стоит нарезать на короткие. Не «разберись с репозиторием и почини», а последовательность шагов с фиксацией результата после каждого.

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

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

Чем это отличается от привычных отказов

Сводка, чтобы различать в коде.

Последняя строка — новая, и её нет в привычных схемах обработки. Подробно про первые четыре — коды, повторы и fallback; про пятую — почему модель отказывается отвечать.

Касается ли это нас сегодня

Честный ответ.

GPT-6 Astra приехала в каталог KeyDealer 5 сентября 2026 года — 60 ₽ за миллион в обе стороны, chat_completions открыт. В каталоге на эту дату 55 позиций в шестнадцати семействах — разбор самой модели.

Но готовиться стоит независимо от этого, по трём причинам.

Механизм не уникален для одной модели. Это подход к безопасности сильных моделей, а не свойство конкретной позиции. Другие вендоры движутся туда же — мы писали про разбор инцидентов Anthropic и про первую модель с высоким уровнем киберспособностей.

Каталог меняется. За неделю до этой статьи в нём было 46 позиций, стало 54.

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

Как отличить остановку от других обрывов

Практическая часть, потому что внешне обрыв выглядит одинаково независимо от причины.

Четыре вещи, которые стоит фиксировать по каждому шагу агента — тогда разбор становится возможным.

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

Число потраченных токенов. Если шаг успел списать токены и оборвался — модель работала. Если списаний нет — запрос не дошёл.

Поле model из ответа. Отвечала ли та позиция, которую вы просили.

Последнее действие агента перед обрывом. Именно оно чаще всего объясняет причину: длинная последовательность обращений к внешним ресурсам выглядит иначе, чем короткий текстовый шаг.

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

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

Чего мы не утверждаем

Не оцениваем, насколько часто монитор срабатывает. Вендор говорит «иногда»; количественных данных в публикации нет, и своих замеров у нас тоже нет.

Не утверждаем, что это касается всех моделей вендора. Публикация посвящена Astra.

Не пересказываем систему безопасности целиком. Мы взяли из неё ровно то, что меняет работу разработчика на API.

Не сравниваем подходы вендоров к безопасности. Это отдельная тема, и она не про выбор модели под задачу.

Что нужно, чтобы подготовиться

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

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов. Платные текстовые модели доступны сразу на приветственном бонусе, восемь позиций тарифицируются по нулевой ставке после пополнения от 100 ₽. Один ключ на весь каталог: если модель, на которой вы работаете, окажется слишком строгой к вашим задачам, переключение — правка строки в конфигурации, а не новый договор.

Что держать в голове

Появился класс отказов, которого раньше не было: не ошибка и не отклонение запроса, а остановка выполняемой задачи посередине. И вероятность его тем выше, чем дольше работает агент.

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить устойчивость своего агента: keydealer.ru/login.