Долгоживущие AI-агенты должны уметь ждать

AI-агент может остановиться по хорошей причине. Нужный документ ещё не прислали. Между правдоподобными трактовками должен выбрать человек. Перед следующим действием требуется проверка. Генерация ещё одного ответа не устранит ни одну из этих зависимостей.

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

Моя позиция проста: долгоживущему агенту нужны явное состояние ожидания, понятное условие продолжения и сохранённый результат уже выполненной работы. Иначе паузу трудно отличить от сбоя, а команда «продолжить» может означать «начать заново». Записи рабочих процессов Norman позволяют увидеть эту разницу на практике. Здесь интересно содержание состояний, а не количество задач в каждом из них.

Что делает AI-агента долгоживущим?

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

Именно в эту сторону движутся анонсы индустрии. 14 сентября 2026 года Salesforce представила среду для задач на дни и недели; первый агент Hunter находился в пилоте. 15 сентября Workiva представила Agent Studio с контекстом компании и запуском процессов по расписанию.

Из этих обещаний возникает новый продуктовый вопрос. Чат-ассистент может вернуть управление после ответа. Долгоживущий процесс должен объяснить, за кем следующий ход, когда одного ответа недостаточно для продолжения. Фраза «агент активен» этого не объясняет: она ничего не говорит о том, чьего действия сейчас ждёт система.

Для разработчика меняется сама единица работы. У разговора, обращения к модели и бизнес-задачи разные сроки жизни. Если считать их одним объектом, обычная пауза начинает выглядеть как техническая ошибка или как завершённое задание. Пользователь получает неверное представление о происходящем, даже если отдельные операции работают правильно.

Ожидающий агент считается сломанным?

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

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

Таблица ниже предлагает язык для проектирования продукта. Это не описание конкретной реализации какого-либо поставщика.

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

Что показали рабочие данные Norman?

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

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

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

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

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

Что агенту сохранить перед ожиданием?

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

«Пожалуйста, проверьте» описывает задачу слишком слабо. «В документе и транзакции разные даты; выберите, какой документ должен подтверждать эту запись» задаёт конкретное решение. Формулировка зависит от процесса, но должна объяснять, почему агент не может достоверно получить ответ из уже доступной информации. Вопрос нужен именно там, где самостоятельное продолжение потребовало бы предположения.

Также важно указать, кто должен действовать. Иначе все видят остановку, но никто не понимает, относится ли запрос к нему. Человек должен иметь возможность ответить, явно пропустить допустимый шаг или отменить задачу. У этих действий разные последствия, поэтому их различие должно сохраняться и после возобновления работы.

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

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

Как AI-агенту продолжить после паузы?

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

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

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

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

Как оценивать агента, который иногда ждёт?

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

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

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

Я бы оценивал обещание долгоживущего AI именно по этому переходу. Может ли продукт объяснить причину остановки, сохранить полезную работу и правильно отреагировать на изменившиеся обстоятельства? Если может, у него есть содержательное основание работать с задачей долго. Сама продолжительность непрерывного запуска такого основания не создаёт.