Как обучить phone agent показом: запись экрана, навыки и безопасность Android

Что значит обучить phone agent показом

Можно ли научить AI-агента рабочему процессу, просто выполнив его перед камерой экрана? Демонстрация действительно дает богатый пример: видно последовательность экранов, выбранные элементы и конечный результат, а голосом можно объяснить причины решений. Однако полезный навык появляется не из самой видеозаписи, а из правил, которые система сумела извлечь из показанного сценария.

Свежий пример такого взаимодействия появился в Claude Cowork. По данным ITmedia от 22 июля 2026 года, функция Record a Skill записывает выполнение задачи вместе с устным объяснением и преобразует демонстрацию в повторно используемый навык. Практический обзор Android Authority от 21 июля уточняет, что пользователь показывает процесс на экране и комментирует его, чтобы реже повторять подробные инструкции для регулярных задач.

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

Для phone agent главный вопрос звучит так: сможет ли навык понять, что должно остаться неизменным, а что меняется при каждом запуске. В сценарии отправки отчета постоянным может быть порядок проверки и отправки, а переменными — дата, файл и получатель. Контекст Claude Cowork как интерфейса агента раскрывает статья Claude Cowork на телефоне: почему смартфон становится интерфейсом AI-агента; здесь же нас интересует проектирование надежного Android-навыка.

Как демонстрация превращается в повторно используемый навык

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

Затем требуется разобрать демонстрацию на намерение, обязательные этапы и случайные детали. Если пользователь прокрутил экран, чтобы увидеть кнопку, прокрутка не обязательно является правилом. Если он выбрал контакт Анну, система должна понять, всегда ли нужен именно этот контакт или имя является параметром будущей команды. Если перед отправкой человек сверил сумму, проверка может быть обязательным условием, а не необязательной паузой.

Следующий этап — параметризация. В повторяемом навыке фиксируются переменные: приложение, учетная запись, получатель, дата, текст, файл, сумма или категория. Для каждой переменной полезно определить источник, допустимый формат и поведение при отсутствии значения. Команда «отправь еженедельный отчет руководителю» может подставлять текущую неделю и заранее заданного получателя, но при неоднозначной учетной записи должна запросить выбор.

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

Голосовой комментарий особенно полезен для решений, которые невозможно увидеть. Фраза «выбираю этот вариант, потому что он не создает подписку» сообщает правило, которого нет в жесте. Аналогично полезны пояснения «если файла нет, остановись» или «перед отправкой покажи адресата». Чем яснее обозначены цель, исключения и ожидаемый итог, тем меньше случайных действий попадет в итоговый сценарий.

Вызов готового навыка может быть коротким, но выполнение остается многоэтапным. Материал Как автоматизировать задачи Android одной голосовой командой показывает, как единая команда связывается с последовательностью действий. Демонстрация добавляет к этому способ объяснить последовательность на конкретном примере.

Почему Android нельзя надежно воспроизводить по координатам

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

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

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

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

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

Поэтому демонстрация служит исходным примером, а не готовой трассой воспроизведения. Навык должен опираться на цель, состояние, смысл элементов и проверку результата после каждого важного перехода. Исследовательский контекст адаптации телефонных агентов к разным состояниям рассматривается в материале PhoneBuddy-4B и обучение телефонных агентов: зачем Android Agent нужен Mock-App RL.

Как записать чистую и безопасную демонстрацию

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

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

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

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

• Используйте тестовые контакты, документы и учетные записи.
• Начинайте с известного состояния приложения.
• Называйте цель, переменные и ожидаемый результат.
• Объясняйте причины выбора, а не только касания.
• Не вводите секреты и коды подтверждения в записываемом сеансе.
• Останавливайте запись до открытия личной переписки или чувствительного документа.
• Показывайте исключения отдельными примерами.
• После записи проверьте каждый кадр и удалите ненужные данные.

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

Как тестировать навык и управлять его версиями

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

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

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

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

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

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

Как повторяемые сценарии вписываются в FoneClaw

Как мы в FoneClaw смотрим на навыки, полученные из демонстраций? Ценность такого подхода заключается не в сохранении каждого касания, а в возможности передать модели хороший пример намерения, правил и ожидаемого результата. Для Android-сценария надежный навык должен оставаться параметризованным, проверять состояние и учитывать границы разрешений.

FoneClaw работает как настраиваемый Android phone agent. Совместимая модель, выбранная и настроенная пользователем, обеспечивает понимание языка, рассуждение и планирование. FoneClaw связывает этот план с поддерживаемыми действиями Android, показывает ход и результат, учитывает разрешения и оставляет пользователю подтверждение там, где действие имеет значимые последствия.

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

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

Практичный результат для phone agent — не полная автономность любой ценой. Хороший повторяемый сценарий сокращает рутину, но сохраняет видимость и понятный запасной путь. Если интерфейс изменился, элемент не найден или появилось новое разрешение, FoneClaw может остановить поддерживаемое выполнение и передать управление пользователю в конкретной точке, не скрывая незавершенный результат.

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