Управление Android ИИ-агентом: намерение, подтверждение и проверка результата

Полный цикл управления телефоном

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

В FoneClaw мы строим этот цикл как управляемый Android phone-agent runtime. Модель помогает понять смысл запроса и выбрать план, но сама по себе не должна напрямую менять любую часть телефона. Между рассуждением и действием стоят поддерживаемые tools, Android-разрешения, состояние экрана, видимый результат и решение пользователя там, где действие имеет последствия.

Самый короткий пример: «Включи тихий режим на время встречи». Слабая автоматизация сразу меняет настройку и надеется, что угадала. Надежный телефонный агент сначала проверяет, что сейчас включено, какой режим нужен, сколько длится встреча, какие исключения оставить, есть ли доступ к настройке, затем показывает предложение. Только после подтверждения FoneClaw выполняет поддерживаемое действие и проверяет финальное состояние.

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

Намерение, цель и текущее состояние

До любого изменения настройки FoneClaw должен понять три вещи: какой результат хочет пользователь, к чему относится действие и в каком состоянии телефон находится сейчас. Естественная фраза часто неполная. «Подготовь к встрече» может означать выключить звук, открыть календарь, включить Do Not Disturb, создать напоминание, открыть заметки или отправить сообщение о занятости. Без уточнения агент рискует выполнить не то.

Мы разделяем outcome, target и constraints. Outcome — желаемый результат: меньше отвлечений на встрече. Target — конкретная поверхность Android: режим уведомлений, календарь, контакт, приложение, экран. Constraints — ограничения: оставить будильники, разрешить звонки от семьи, вернуть прежнее состояние через час, не отправлять сообщения без проверки. Чем яснее эти элементы, тем меньше агенту приходится гадать.

Текущее состояние меняет безопасный следующий шаг. Если Do Not Disturb уже включен, FoneClaw не должен повторно включать его вслепую. Если режим выключен, но нет доступа к политике уведомлений, сначала нужен permission flow. Если включен Battery Saver или OEM-настройка ограничивает фоновые действия, результат может отличаться. Если пользователь находится на нужном экране, текущий экран становится частью контекста.

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

Предложение перед действием

После распознавания намерения FoneClaw должен превратить его в reviewable proposal. Предложение — это не длинное объяснение модели, а короткая карточка решения: что будет сделано, какая настройка или приложение затронуты, какие зависимости есть, что изменится после выполнения и как вернуть состояние. Именно здесь пользователь понимает, совпадает ли план с его намерением.

Для встречи хорошее предложение звучит предметно: «Сейчас режим «Не беспокоить» выключен. Предлагаю включить Priority mode на 60 минут, оставить будильники и приоритетные контакты, остальные уведомления приглушить. После окончания вернуть прежний режим. Подтвердить?» В такой формулировке нет размытого «настроить телефон». Есть точная настройка, срок, исключения и восстановление.

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

Мы в FoneClaw считаем это частью продукта, а не декоративным подтверждением. Агент должен показывать affected state: что было до, что станет после, какой tool будет использован и какие разрешения нужны. Если действие не поддержано на конкретном устройстве или требует системного экрана, предложение должно честно показать границу и дать пользователю понятный путь.

• Плохое предложение: «Я изменю настройки телефона».
• Хорошее предложение: «Включить Do Not Disturb в Priority mode на один час, оставить будильники и избранные контакты».
• Плохое восстановление: «Потом все верну».
• Хорошее восстановление: «После часа отключить DND и вернуть прежний режим уведомлений».

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

Подтверждение по уровню риска

Подтверждение действия ИИ должно соответствовать влиянию действия. Read-only inspection можно выполнять быстро: проверить текущий режим уведомлений, посмотреть состояние батареи, открыть экран, собрать доступные варианты. Такие действия не меняют телефон, но результат все равно должен быть видимым. Пользователь должен понимать, на чем основано следующее предложение.

Обратимые настройки требуют scoped confirmation. Включить Do Not Disturb, изменить яркость, громкость, тайм-аут экрана или режим энергосбережения — это не то же самое, что прочитать состояние. Подтверждение должно быть привязано к конкретному изменению: «включить Priority mode до 15:00», «уменьшить яркость до 40%», «включить Battery Saver сейчас». Одно согласие не дает открытого права менять другие настройки.

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

Scoped confirmation делает телефонный агент Android предсказуемым. Пользователь видит не абстрактное «разрешить агенту действовать», а конкретную границу: это действие, с этим объектом, на этот период, с таким ожидаемым результатом. Именно такая модель сохраняет доверие, когда агент приближается к реальным настройкам и данным.

Выполнение через Android tools и проверка

После подтверждения FoneClaw выполняет действие через поддерживаемые Android tools. Это важная граница: модель не «двигает Android напрямую». Она формирует план и параметры, а runtime направляет действие через поддерживаемый инструмент, системную поверхность, разрешение или видимый экран. Если tool требует доступа, пользователь видит permission path. Если действие недоступно, FoneClaw должен остановиться и объяснить причину.

Tool success сам по себе еще не равен пользовательскому результату. Если Android сообщил, что команда настройки выполнена, нужно сверить финальное состояние. Для DND-сценария это означает проверить, активен ли режим, выбран ли Priority mode, какие исключения действуют и задано ли восстановление. Для SMS — черновик или отправка после подтверждения. Для календаря — созданное событие с правильным временем.

Пример встречи показывает полный цикл. Пользователь говорит: «Подготовь телефон к встрече на час, оставь важные звонки». FoneClaw определяет намерение, проверяет текущий режим уведомлений, предлагает Priority Do Not Disturb на один час с будильниками и приоритетными контактами, ждет подтверждения, выполняет поддерживаемое изменение и проверяет, что состояние телефона совпадает с предложением. Если доступ к Do Not Disturb policy не выдан, выполнение не маскируется под успех: FoneClaw открывает путь к настройке или предлагает завершить вручную.

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

Актуальные поддерживаемые возможности FoneClaw можно проверить на странице Функции FoneClaw, а установку и совместимость — на странице Загрузка FoneClaw. Мы развиваем продукт вокруг управляемых tools, видимых разрешений и проверки результата, потому что именно там телефонный агент становится полезным в реальной жизни.

Восстановление, отмена и контроль

Реальный Android-сценарий может остановиться частично. Экран изменился, разрешение не выдано, настройка называется иначе, сеть пропала, пользователь передумал, target выбран неверно или действие поддержано только через системную панель. Надежный агент не должен скрывать такую ситуацию. Он должен показать, что уже произошло, что не произошло и какой безопасный следующий шаг возможен.

Partial success требует точного отчета. Например: «Проверка состояния выполнена, но DND не изменен, потому что нет доступа к политике уведомлений». Или: «Priority mode включен, но восстановление прежнего режима не создано». Это разные состояния, и действия после них тоже разные. В первом случае нужно открыть настройки доступа или остановиться. Во втором — добавить восстановление или вручную вернуть прежний режим.

Отмена тоже должна быть scoped. Если FoneClaw включил Do Not Disturb на час, undo означает вернуть прежний режим уведомлений или отключить DND, если до сценария он был выключен. Если создан черновик, отмена может удалить черновик или оставить его. Если открыт экран, отмена может просто остановить задачу. Нельзя считать, что «отменить» одинаково для всех действий.

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

• Остановиться: когда target неясен, доступ отсутствует или действие выходит за поддержку.
• Показать частичный результат: что выполнено, что не выполнено, что требует решения.
• Откатить точно: отменять конкретное изменение, а не «что-нибудь вернуть».
• Сузить повтор: повторять только failed step после проверки состояния.
• Сохранить контроль: оставить пользователю финальное решение для чувствительных действий.

Первый обратимый тест должен быть простым: попросите FoneClaw проверить текущий режим уведомлений, предложить временный Priority Do Not Disturb на короткий период, показать точное изменение, дождаться подтверждения, выполнить, проверить состояние и вернуть прежний режим. Если каждый этап понятен, управление Android ИИ-агентом работает как проверяемый цикл, а не как скрытая автономия.