Очередь задач ИИ-агента на Android: сессии и статусы
Как устроить очередь задач Android-агента: изоляция диалогов, статусы, подтверждения в сессии, порядок действий и восстановление.
- Очередь задач ИИ-агента на Android — это управление жизненным циклом телефонных действий, а не просто список открытых диалогов.
- Надежная очередь разделяет состояния running, waiting, approval, permission, stopped, failed и completed, чтобы пользователь понимал, что происходит с каждой задачей.
- Подтверждение должно быть привязано к конкретной сессии, задаче, цели и предлагаемому действию; ожидание или отказ не передают разрешение другому диалогу.
- Текущие возможности FoneClaw используют основу multi-conversation queue и floating continuity для поддерживаемых Android-действий, сохраняя изоляцию задач, остановку и восстановление разрешений.
Зачем нескольким диалогам агента нужна настоящая очередь задач
Очередь задач ИИ-агента на Android начинается там, где обычные вкладки чата перестают быть достаточными. Представьте два запроса подряд: в одном диалоге пользователь просит подготовить SMS после встречи, в другом — проверить Bluetooth и включить DND перед звонком. Первый сценарий может ждать подтверждения адресата, второй — разрешения или изменения системной настройки. Если агент хранит только последние сообщения, эти задачи легко смешать: не тот текст, не та цель, не тот экран, не то подтверждение.
Мы в FoneClaw рассматриваем очередь не как список сообщений, а как управление жизненным циклом телефонной задачи. У задачи есть исходный диалог, намерение, текущий контекст, выбранная цель, состояние выполнения, ожидаемое действие, право на выполнение, результат и путь восстановления. Такой подход особенно важен на телефоне: Android-задача может остановиться из-за разрешения, ожидания пользователя, изменившегося экрана, сетевого условия, неоднозначного контакта или приложения, которое требует ручного выбора.
Ключевая идея проста: несколько диалогов могут быть активны, но каждое телефонное действие должно знать, к какой задаче оно относится. Один разговор может ждать разрешения на доступ к уведомлениям, другой — продолжать низкорисковую проверку громкости, третий — оставаться черновиком. Это не параллельная магия и не обещание одновременного выполнения всех действий. Это дисциплина состояния, которая позволяет пользователю видеть, что запущено, что ждет, что требует подтверждения и что уже завершилось.
Для построения самих многошаговых Android-сценариев у нас есть отдельный guide Как автоматизировать задачи Android одной голосовой командой. Здесь фокус уже: как удержать несколько таких сценариев изолированными, управляемыми и восстанавливаемыми.
Состояния running, waiting, approval, permission, stopped и completed
Хорошая очередь задач должна говорить на языке, понятном пользователю. Внутри может быть сложная логика, но снаружи человеку нужны ясные статусы: задача выполняется, ждет данных, требует подтверждения, просит разрешение, остановлена, завершена или завершилась ошибкой. Ожидание — не успех, не провал и не скрытое согласие. Это отдельное состояние, которое позволяет переключиться в другой диалог без потери исходной задачи.
| Состояние | Что это значит для пользователя | Следующее безопасное действие |
|---|---|---|
| Running | Агент выполняет поддерживаемый шаг или проверяет состояние | Показать прогресс, дать возможность остановить задачу |
| Waiting | Не хватает уточнения, данных, приложения, сети или выбора пользователя | Сохранить задачу и спросить ровно то, что нужно для продолжения |
| Approval | Действие подготовлено и требует явного подтверждения | Показать задачу, цель, результат и последствия перед выполнением |
| Permission | Android-доступ не выдан или был отозван | Запустить восстановление разрешения и вернуться к исходной задаче |
| Stopped | Пользователь остановил выполнение или агент остановился по правилу | Оставить понятный след: что сделано, что не сделано, что можно продолжить |
| Failed | Шаг не выполнен: экран изменился, действие недоступно, приложение не готово | Показать причину и предложить повтор, ручной переход или новую проверку |
| Completed | Ожидаемый результат достигнут и проверен | Закрыть задачу с видимым результатом или оставить запись для аудита |
Такой state model важен не из-за аккуратной терминологии, а из-за поведения. Если задача в состоянии permission, она не должна блокировать каждый другой разговор. Если задача в состоянии approval, она не должна выполняться автоматически после переключения в новый диалог. Если задача stopped, она не должна тихо продолжиться через минуту, когда пользователь уже занят другим экраном.
Мы проектируем очередь так, чтобы статус был связан с действием, а не с настроением модели. Модель может сформулировать план, но runtime должен знать, какой Android-шаг сейчас допустим. Телефонная задача живет дольше одного ответа: она может начаться в Home, ждать разрешения, продолжиться из floating assistant и завершиться после проверки результата.
Идентичность диалога и изоляция задач
Изоляция задач отвечает на вопрос: что именно принадлежит этому диалогу и не должно утечь в другой. Минимальный набор включает исходный запрос, task id, conversation id, выбранную цель, текущий экран или прикрепленный контекст, proposed action, permission state, approval state, результат и recovery path. Это не то же самое, что контекстное окно модели. Контекст модели может быть временным, а идентичность телефонной задачи должна быть долговечной.
Например, в первом диалоге пользователь просит подготовить сообщение Ивану: «Буду через десять минут». Во втором диалоге он просит проверить громкость и DND перед созвоном. Если подтверждение из первого диалога всплывает, когда пользователь смотрит на второй сценарий, карточка должна ясно показать: это задача про сообщение Ивану, из такого-то диалога, с таким текстом и таким внешним эффектом. Без этой привязки пользователь может подтвердить действие, думая, что оно относится к текущему экрану.
Изоляция также защищает от смешивания device state. Один диалог может использовать текущий экран настроек, второй — состояние Bluetooth, третий — список задач. Переключение между диалогами должно менять видимый контекст, а не перемещать чужой action plan. Если экран изменился, задача получает stale-state check, а не продолжает старый план как будто ничего не произошло.
Для глубокой архитектуры идентичности, разрешений и audit trails мы держим отдельный материал Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов. В очереди задач нам нужен практический вывод: каждое действие должно иметь владельца, а владелец должен быть видимым пользователю в момент принятия решения.
Подтверждение в рамках сессии без дублирования UX
Подтверждение в рамках сессии защищает от неверного действия тем, что связывает согласие не с общей кнопкой «ОК», а с конкретной задачей. Approval должен знать conversation id, task id, цель, приложение или Android surface, proposed effect, подготовленные данные и состояние, в котором карточка была создана. Если пользователь переключился в другой диалог, старое подтверждение не должно становиться разрешением для новой задачи.
На телефоне это особенно важно для сообщений, звонков, файлов, навигации, системных настроек и действий с внешним эффектом. Подготовить черновик — одно состояние. Отправить сообщение, включить настройку или передать данные в приложение — другое. Если задача ожидает подтверждения, она должна оставаться в состоянии approval, пока пользователь не примет, отклонит или изменит ее. Ожидание не является согласием. Отказ не может быть переиспользован как разрешение для соседнего сценария.
Нам не нужно каждый раз изобретать новый approval UX для очереди. Нужно, чтобы существующая карточка подтверждения показывала идентичность задачи: откуда запрос, что будет сделано, кому или чему это адресовано, какие данные используются и можно ли продолжить после отказа. Детали confidence, rationale и recovery мы разбираем на отдельной странице Интерфейс подтверждения действий ИИ-агента на телефоне: уверенность, причины и восстановление. В этом guide важна привязка: подтверждение принадлежит сессии, а не глобальному состоянию ассистента.
Параллельные команды агентов и очередь задач телефона
Параллельность Android-агента часто путают с многоагентными системами. В desktop или cloud-сценариях несколько агентов могут исследовать тему, писать код, проверять результат и собирать артефакты. MiniMax в материале о MiniMax Agent Team описывает роли leader, worker и verifier для long-running tasks, а также durable session lifecycle с pause, resume и human intervention. Это полезный сигнал для агентной работы, но он относится к другому слою: длительное производство результата, а не одновременное выполнение телефонных side effects.
OPPO в анонсе о синергии OPPO и Google Cloud описывает Agent-to-Agent interoperability как направление экосистемы, вместе с device-cloud collaboration, memory и privacy. В исследовательском контексте репозиторий OPPO Mente X-OmniClaw документирует multi-session parallelism, per-session agent loops, isolated runtime и precise stop chains. Эти примеры показывают, что индустрия серьезно относится к изоляции сессий и остановке выполнения.
Microsoft в архитектурном материале о workflow-oriented multi-agent patterns разделяет orchestration, agents, state и process control. Для phone agent это полезная рамка: даже если агенты умеют работать параллельно на уровне анализа, телефонные действия могут требовать очередности, проверки и явного подтверждения. Нельзя одновременно отправить два несовместимых сообщения, менять одну настройку из двух диалогов и считать это надежной параллельностью.
Поэтому очередь задач телефона — это не попытка назвать каждый диалог отдельным агентом. Это control plane для Android-действий. Исследование, планирование и подготовка могут идти независимо. Но действия с устройством проходят через порядок, видимую идентичность, permission flow и recovery. Для широкой идеи телефона как командного центра полезен материал Управление AI-агентом с телефона: как смартфон становится командным центром; здесь мы держим фокус на очереди телефонных задач.
Остановка, продолжение, восстановление разрешений и stale-state checks
Очередь становится действительно полезной после первого сбоя. Пока все выполняется сразу, кажется, что достаточно красивого чата. Реальный Android-сценарий выглядит иначе: пользователь запускает задачу, приложение просит permission, экран меняется, приходит звонок, сеть пропадает, пользователь открывает другой диалог, а потом хочет вернуться. Очередь должна сохранить исходную задачу и заново проверить условия перед продолжением.
Возьмем сценарий: диалог A готовит сообщение, но ждет подтверждения получателя. Диалог B проверяет Bluetooth и DND перед встречей. В это время Android отзывает нужный доступ или приложение просит permission. Надежная очередь не смешивает эти задачи. Диалог A остается в approval или waiting. Диалог B переходит в permission и показывает путь восстановления. После выдачи доступа задача B возвращается к исходному состоянию и проверяет, сохранилась ли цель.
Resume должен быть осторожным. Перед продолжением стоит проверить четыре вещи: исходная цель та же, текущий экран или target не устарели, нужное разрешение действительно доступно, proposed effect по-прежнему безопасен и понятен. Если прошло много времени, изменился экран или появился новый контекст, агент должен показать fresh preview или спросить уточнение. Особенно это важно для сообщений, файлов, навигации и системных настроек.
Остановка тоже не равна удалению памяти. Когда пользователь нажимает stop, очередь должна показать, что уже было сделано, что осталось и можно ли продолжить позже. Для некоторых действий undo недоступен, поэтому правильнее проектировать preview, confirmation и stop до выполнения, а не обещать универсальный откат после side effect. В FoneClaw мы относим recovery к качеству execution layer: задача должна возвращаться к человеку с понятным состоянием, а не теряться между диалогами.
Как FoneClaw переносит задачи между диалогами
По актуальной информации о продукте на момент обновления статьи, текущая доступная база FoneClaw несет вперед foundation для этого guide: recent-session management, strict cross-conversation task queue, independent running and waiting states, session-bound approvals, task isolation и permission recovery. К этому добавлены movable floating assistant, deliberate current-screen attachment и task continuity между Home и floating assistant. Актуальную сборку мы направляем через страницу загрузки FoneClaw.
Важно описать это точно. Текущая доступная база FoneClaw сохраняет фокус на Android phone-agent runtime, а не на платформе параллельных reasoning agents. Мы строим Android phone-agent runtime, где настроенная модель рассуждает и планирует, а поддерживаемые Android действия проходят через governed tools, permission flows, approvals, visible results, state checks и recovery. На странице функций FoneClaw мы описываем 100+ built-in tools как текущую публичную поверхность возможностей; в очереди задач каждое действие сохраняет свой статус и свои условия выполнения.
Практический сценарий: пользователь начинает в Home задачу «подготовь телефон к встрече», затем открывает другое приложение и вызывает floating assistant поверх текущего экрана. Он прикрепляет current screen и спрашивает, что сделать дальше. Если задача ждет permission, FoneClaw сохраняет ее состояние и помогает восстановить доступ. Если в другом диалоге подготовлен черновик сообщения, его approval остается привязанным к исходной сессии. Если пользователь останавливает задачу из floating assistant, Home видит тот же факт остановки.
Это именно то, что мы считаем зрелым поведением очереди. Пользователь может переключаться между контекстами, но телефонные действия не теряют владельца. Диалог может ждать, не блокируя все остальные задачи. Approval может оставаться видимым, не превращаясь в глобальное разрешение. Permission recovery может вернуть пользователя к исходному действию, а не к пустому чату. Мы строим дальше в этом направлении: меньше скрытого состояния, больше понятной task identity и более надежное восстановление после реального Android-шума.
Чеклист оценки очереди задач Android-агента
Оценивать очередь задач лучше на низкорисковых сценариях. Создайте два диалога: в первом попросите подготовить черновик сообщения без отправки, во втором — проверить поддерживаемую настройку устройства. Затем искусственно введите точку ожидания: не дайте разрешение, оставьте approval без ответа или измените экран. После этого переключитесь между диалогами и проверьте, не смешались ли цель, контекст и действие.
Минимальный scorecard выглядит так:
- Идентичность: видно ли, к какой сессии и задаче относится действие?
- Состояние: понятно ли, задача running, waiting, approval, permission, stopped или completed?
- Изоляция: не подтягивает ли один диалог контекст или approval другого?
- Порядок: выполняются ли телефонные действия в безопасной последовательности?
- Восстановление: возвращает ли recovery к исходной задаче с fresh state check?
Количество открытых чатов само по себе мало что говорит о качестве. Важнее, видит ли пользователь следующий безопасный шаг. Начинайте с обратимых задач: громкость, DND preview, черновик, открытие приложения, проверка экрана. Потом добавляйте permission recovery и approval. Только после этого стоит переходить к сценариям с внешним эффектом.