Диагностика и восстановление телефонного ИИ-агента: как найти причину сбоя и безопасно повторить шаг
Практический runbook для сбоев Android phone agent: как остановить задачу, собрать минимальные доказательства, найти корневую причину, восстановить разрешения, повторить только безопасный шаг и использовать текущие элементы контроля FoneClaw.
- При сбое телефонного ИИ-агента сначала остановите повтор, зафиксируйте текущий экран, определите, были ли внешние последствия, и не запускайте всю задачу заново вслепую.
- Поверхностная ошибка часто появляется позже корневой причины: сбой модели, маршрутизации, контекста, разрешения, инструмента, UI-состояния, внешнего сервиса или подтверждения нужно разделять по слоям.
- Цикл Detect–Attribute–Recover–Rerun из AgentDebugX полезен как исследовательская рамка: обнаружить сбой, найти ранний причинный шаг, восстановить предусловие и повторить минимальный безопасный хвост задачи.
- FoneClaw помогает применять этот runbook на поддерживаемых Android-сценариях через видимое состояние задачи, текущий экран по выбору пользователя, approvals, stopping, retry, permission recovery и проверку итогового состояния.
Первые пять минут после сбоя
Когда телефонный ИИ-агент ошибся, первая задача — не «попробовать еще раз», а остановить возможное удвоение действий. Если агент пытался прочитать состояние батареи, открыть экран или найти запись, повтор обычно безопаснее. Если он отправлял сообщение, менял настройку, создавал событие, звонил, удалял файл или обращался к внешнему сервису, полный повтор может создать второе внешнее последствие.
Свежая исследовательская работа AgentDebugX формулирует полезный цикл Detect–Attribute–Recover–Rerun: обнаружить сбой, атрибутировать причину, восстановить нужное условие и повторить. Для телефона этот цикл нужно заземлить в Android-состоянии: экран, разрешения, foreground-приложение, сеть, выбранный контакт, approval card, результат инструмента и фактический внешний эффект.
- Остановите текущую задачу или дождитесь явного состояния ожидания.
- Не повторяйте всю цепочку, пока не поймете, был ли завершен внешний шаг.
- Зафиксируйте текущий экран, последний видимый результат и последний запрос подтверждения.
- Разделите задачу на read-only, reversible setting и consequential external action.
- Определите, что именно видит пользователь: ошибка модели, отказ разрешения, пустой результат, неверный экран или неясное завершение.
В FoneClaw мы строим восстановление вокруг видимого состояния, а не вокруг магического перезапуска. Пользователь должен понимать, какой шаг уже прошел, какой заблокирован и где безопасно продолжить.
Минимальный набор доказательств
Для диагностики нужен не полный дамп личной жизни, а небольшой набор фактов, который восстанавливает намерение, траекторию и состояние устройства. Сохраните исходный запрос пользователя, ожидаемый результат, последний видимый экран, название приложения, состояние разрешения, сетевое состояние, approval card, результат инструмента и точку, где агент остановился. Если задача затрагивала контакт, сообщение, файл или адрес, замените личное значение нейтральным маркером.
AgentDebugX показывает, что trajectory-wide context помогает находить причину сбоя: ошибка может всплыть в конце, но возникнуть раньше. На телефоне это особенно часто: агент видит неверный экран, выбирает не тот contact, теряет foreground-приложение, получает permission denial или продолжает план после устаревшего состояния.
Минимальный failure bundle должен отвечать на пять вопросов: что пользователь хотел, какой шаг был последним успешным, что агент собирался сделать дальше, какое Android-состояние было на экране и какие внешние последствия уже случились. Скриншот сам по себе не достаточен: он показывает поверхность, но не раскрывает разрешение, сеть, выбранный инструмент и approval history.
Личные данные очищайте до отправки в поддержку. Уберите пароли, токены, полный текст сообщений, номера телефонов, адреса, вложения и имена людей, если они не нужны для воспроизведения. Для общей логики идентичности агента и проверяемого следа полезна статья Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов; здесь мы используем тот же подход в операционном runbook.
Как определить слой сбоя
Одна и та же поверхностная ошибка может иметь разные причины. Фраза «не удалось выполнить» может означать плохой исходный запрос, неверное распознавание цели, неправильный routing, устаревший контекст экрана, отозванное разрешение, сбой инструмента, изменение UI, недоступный внешний сервис или отсутствие пользовательского подтверждения. Корневая причина агента находится не в тексте ошибки, а в первом шаге, который сделал дальнейшую цепочку неправильной.
| Слой | Симптом | Диагностическая проверка | Типичное восстановление |
|---|---|---|---|
| Ввод | Агент понял не ту цель или адресата. | Сравните исходный запрос с планом и аргументами инструмента. | Уточните intent, объект и ограничения перед повтором. |
| Модель | План логичен на словах, но не соответствует доступным действиям. | Проверьте, выбрал ли агент поддерживаемый route и реальный инструмент. | Переформулируйте задачу через доступный Android-действие. |
| Маршрутизация | Выбран не тот tool, Skill или capability. | Сравните задачу с доступными возможностями и контекстом. | Выберите правильный capability или отключите ошибочный путь. |
| Контекст экрана | Тап, чтение или анализ относится к старому экрану. | Проверьте foreground-приложение, текущий screen state и время снимка. | Верните нужный экран и обновите контекст. |
| Разрешение | Действие заблокировано Android или приложением. | Проверьте runtime permission именно в момент использования. | Откройте нужную настройку, выдайте минимальный доступ и повторите шаг. |
| Инструмент | Вызов вернул ошибку, пустой результат или частичный результат. | Смотрите tool result, arguments и preconditions. | Исправьте предусловие и повторите только этот вызов. |
| Внешний эффект | Сообщение, звонок, запись или изменение могли уже произойти. | Проверьте фактическое состояние в целевом приложении. | Не повторяйте без подтверждения отсутствия дубликата. |
Официальная документация Android по runtime permissions подчеркивает, что разрешение нужно проверять при использовании: пользователь может отказать, отозвать доступ или выбрать постоянный отказ. Поэтому permission failure часто выглядит как сбой инструмента, хотя корень — состояние Android.
Для сбоев маршрутизации отдельная тема — AutoAttach, Suggest и Fallback. Если агент выбрал не ту возможность или предложил неправильный следующий шаг, читайте Маршрутизация возможностей ИИ-агента Android: AutoAttach, Suggest, Fallback и контроль FoneClaw. В этом runbook мы фиксируем место, где routing влияет на восстановление.
Как найти самый ранний причинный шаг
Атрибуция начинается с конца, но не заканчивается на последней ошибке. Возьмите surfaced failure и двигайтесь назад: какой результат ожидался, какой инструмент был последним, какие аргументы он получил, какое состояние телефона было предпосылкой, что агент предполагал о контакте, разрешении, приложении или сети. Самый ранний шаг, после которого задача стала неизбежно неверной, и есть рабочая корневая причина.
Метод Detect–Attribute–Recover–Rerun из AgentDebugX полезен именно этой дисциплиной. Detect — зафиксировать факт сбоя и видимый симптом. Attribute — назвать причинный шаг, а не только последний exception. Recover — восстановить предусловие: разрешение, экран, сеть, аргументы, approval. Rerun — повторить минимальный безопасный suffix, а не всю траекторию.
Для телефонного агента используйте read-only проверки перед действиями. Перед повтором сообщения проверьте, был ли черновик уже отправлен. Перед повтором календарного события проверьте, существует ли событие. Перед повтором настройки проверьте текущее значение. Перед повтором звонка проверьте журнал или экран вызова. Такие проверки дешевле, чем исправление дублей.
Строгая атрибуция остается сложной: иногда есть две правдоподобные причины. Тогда запишите основную гипотезу и альтернативу. Например: «вероятнее всего, permission revoked; альтернатива — tool selected wrong account». Для формальной оценки нескольких телефонов и повторяемых сценариев используйте Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году.
Как восстановить задачу без дублирования последствий
Восстановление начинается с инвентаризации уже завершенных эффектов. Read-only шаги можно повторять свободнее: прочитать экран, проверить статус, запросить список. Reversible settings требуют проверки текущего значения: громкость, яркость, Bluetooth, Wi-Fi или режим не должны хаотично переключаться туда-сюда. Consequential external actions требуют самой строгой проверки: сообщение, звонок, письмо, календарное событие, удаление, покупка, изменение файла.
Минимальная лестница восстановления выглядит так. Сначала восстановите предусловие: разрешение, foreground-приложение, сеть, выбранный аккаунт, экран или нужный объект. Затем выполните read-only verification: что уже произошло. После этого повторите только failed step или короткий suffix от него. Затем проверьте downstream state и остановитесь, если результат достигнут. Полный перезапуск оставляйте для задач без внешних эффектов или для сценариев, где вы подтвердили отсутствие завершенных действий.
Android-документация по разрешениям описывает состояния отказа, постоянного отказа и необходимость graceful degradation. На практике это значит: если пользователь отказал микрофону или контактам, агент должен дать понятный путь восстановления или предложить ручной вариант. Если permission auto-reset или vendor policy изменили доступ, повтор инструмента без восстановления предусловия будет просто повторять сбой.
Для длинных задач полезно разделять «план готов» и «действие выполнено». План можно пересобрать. Внешний эффект нужно проверять. Если агент создал черновик сообщения и остановился на подтверждении, повторяйте только подтверждение или редактирование. Если он уже отправил сообщение, не повторяйте отправку; создайте follow-up только после явной проверки.
Как использовать элементы восстановления FoneClaw
В FoneClaw мы проектируем recovery как часть работы агента, а не как отдельный аварийный режим. Пользователь может возвращаться к задаче, смотреть видимое состояние, останавливать выполнение, проверять approval и tool result, восстанавливать разрешения и повторять шаг после ремонта предусловия. Это особенно важно для Android, где экран, приложение, разрешение и сеть меняются независимо от модели.
Текущий экран в FoneClaw добавляется намеренно пользователем. Это важно для диагностики: мы не строим recovery на скрытом автоматическом захвате всего экрана. Если сбой связан с UI-состоянием, пользователь может вернуть нужный экран и предоставить актуальный контекст. Для подробностей по этой механике используйте Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль.
При сбое FoneClaw-сценария смотрите на четыре блока. Первый — task state: что уже выполнено и где остановилось. Второй — tool result: какой инструмент вернул результат, ошибку или частичный ответ. Третий — approval: было ли действие ожидающим подтверждения. Четвертый — permission recovery: не требуется ли открыть системную настройку и вернуть доступ.
На странице возможностей FoneClaw мы описываем текущие семейства поддерживаемых задач, 100+ built-in tools, Workflows, Shortcuts, Skills, Plugins и управляемые Android-действия. В runbook это превращается в правило: перед retry сначала определите тип инструмента и последствия. Read-only tool можно повторить после обновления контекста. Reversible setting проверяйте до и после. Consequential action требует подтверждения отсутствия дубликата.
Если задача пришла из Workflow или Shortcut, не запускайте весь сценарий заново автоматически. Вернитесь к месту остановки, восстановите permission или foreground state, затем повторите минимальный шаг. Так мы удерживаем непрерывность задачи без лишнего риска.
Как подготовить полезный отчет в поддержку
Перед обращением в поддержку остановитесь, если повтор неясен, внешний эффект мог завершиться, ошибка воспроизводится на нескольких попытках или требуется доступ к данным, которые вы не хотите раскрывать. Хороший отчет короткий, воспроизводимый и очищенный от секретов.
Шаблон: цель задачи; ожидаемый результат; фактический результат; последний успешный шаг; последний failed step; тип действия — read-only, reversible или consequential; состояние разрешений; приложение на переднем плане; сеть; было ли подтверждение; что уже проверено; время сбоя; модель устройства и версия Android; очищенный скриншот или текст ошибки. Уберите credentials, tokens, полный текст личных сообщений, номера телефонов, адреса и вложения, если они не являются самой причиной.
Для FoneClaw полезно добавить видимое состояние задачи, tool result, approval state и шаг permission recovery. Эти данные помогают отличить ошибку модели от отсутствующего Android-доступа, устаревшего экрана или внешнего сервиса.
Как предотвратить повторение сбоя
Профилактика начинается с маленького acceptance test. После восстановления запишите один regression case: исходный запрос, начальное состояние, разрешения, ожидаемый tool, ожидаемый approval, итоговое состояние и безопасный критерий остановки. Не считайте один успешный rerun постоянным исправлением: телефон меняет сеть, foreground-приложение, разрешения, батарейные ограничения и язык интерфейса.
Android best practices для разрешений рекомендуют тестировать потоки с разными комбинациями granted и revoked permissions. Для phone agent это превращается в матрицу: разрешение есть, разрешения нет, permission permanently denied, приложение закрыто, экран изменился, сеть пропала, объект уже существует, пользователь отменил approval.
Минимальная профилактическая матрица должна включать четыре сценария. Первый: успешный baseline. Второй: отсутствующее разрешение и восстановление. Третий: прерывание после частичного результата. Четвертый: повтор после уже завершенного внешнего эффекта. Для зрелых команд эти кейсы становятся частью оценки агента и его governance; продолжить можно в материале Как строить harness и governance для самоулучшающегося phone agent.
Главная привычка проста: каждый сбой превращайте в проверку предусловий, минимальный rerun и один новый acceptance test. Так диагностика и восстановление телефонного ИИ-агента становятся процессом, а не удачной догадкой.