Фоновая задача AI-агента: какие статусы нужны кроме «думает»
Анализ большого пакета документов может длиться дольше браузерного соединения. Если интерфейс знает только «думает» и «готово», пользователь не отличает ожидание очереди от зависшего инструмента и запускает ещё одну задачу. Для фонового сценария нужен идентификатор работы и проверяемая модель состояния.
Отделите принятие запроса от начала исполнения. Успешный ответ сервера о постановке в очередь ещё не означает, что агент уже обработал документы.
Где возникает ошибка
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Статус | Что произошло | Что можно показать |
|---|---|---|
| Принята | Запрос сохранён | Идентификатор задачи |
| В очереди | Ждёт исполнителя | Положение без обещания точного времени |
| В работе | Есть активный шаг | Последний подтверждённый этап |
| Завершена | Результат сохранён | Ссылку на результат |
Процент готовности оправдан только при понятном объёме работы. Обработка половины файлов не означает половину времени, если оставшиеся файлы значительно больше. Лучше честное название этапа, чем декоративные девяносто девять процентов.
Статусы ошибок должны различать временный сбой, окончательный отказ и необходимость решения пользователя. Это помогает не превращать все ситуации в бесконечное ожидание.
Как воспроизвести проблему
Создайте короткую задачу, длинную задачу и задачу с искусственным сбоем. Закройте страницу после постановки в очередь, затем восстановите состояние по идентификатору. Убедитесь, что доступ к результату проверяется для текущего пользователя.
Задайте допустимые переходы и запретите возвращение из завершённого состояния в работу без новой попытки. Отдельно храните номер попытки и итог всей задачи. Контролируйте, что результат записан до объявления успеха, а устаревшее событие исполнителя не перезаписывает более свежий статус.
Что учитывать при переносе
Очередь не обеспечивает достоверный прогресс автоматически. Часть систем хранит технические статусы доставки, которые не равны бизнес-статусу работы. Связь между ними нужно спроектировать и проверить на сбоях.
Celery разделяет отправку задачи и её исполнение; пользовательскую модель результата проектируют поверх технического механизма. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу AI Agents PRO на Latorn: она охватывает граф состояний, инструменты, надёжность и эксплуатацию агентов. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: AI-агенты в приложениях: состояние, инструменты и сбои. По смежным вопросам: План AI-агента и исполнение: какие проверки ставить между ними, Задача AI-агента попала в DLQ: как разбирать, а не просто перезапускать.
