Самоулучшающийся phone agent: версии навыков, тесты и откат

Что означает самоулучшение phone agent

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

Важно различать четыре части архитектуры. Первая — выбранная пользователем модель: она понимает запрос, рассуждает и составляет план. Вторая — agent harness, то есть обвязка из инструкций, инструментов, правил проверки, оркестрации и процедур восстановления. Третья — навыки, которые описывают повторяемые телефонные процессы. Четвертая — исполнитель Android-действий, изменяющий состояние устройства.

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

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

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

Чему учит исследование Self-Harness

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

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

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

Третий этап — валидация. Новое правило должно исправить исходную слабость и сохранить успешное поведение на других задачах. Авторы Self-Harness сообщают о повышении доли успешно пройденных отложенных задач Terminal-Bench-2.0 для трех фиксированных базовых моделей. В экспериментах изменялась обвязка, а не веса моделей. Эти результаты относятся к методике и выбранному набору задач, а не гарантируют одинаковый рост в каждом Android-приложении.

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

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

Как самоулучшение устроено в FoneClaw

Является ли FoneClaw самоулучшающимся phone agent? Да. FoneClaw использует результаты выполнения и трассы сбоев, чтобы совершенствовать планирование, поведение обвязки и повторно используемые телефонные навыки. Каждое улучшение проходит управляемый жизненный цикл с тестированием, одобрением, версией и возможностью отката.

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

Рассмотрим навык создания события. Трассы могут показать, что при нескольких календарях агент иногда выбирает первый доступный вариант. Улучшение не требует обучать модель заново. В обвязку добавляется правило: перед созданием определить выбранный пользователем календарь, а при неоднозначности запросить решение. Затем правка проверяется на сценариях с одним, несколькими и недоступными календарями.

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

Разрешения и подтверждения входят в критерии приемки. Если новая версия навыка неожиданно запрашивает дополнительный доступ или переносит подтверждение за точку значимого действия, она требует отдельного рассмотрения. Улучшение считается полезным только при сохранении управляемого Android-процесса.

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

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

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

1. Собрать доказательства. Зафиксировать исходную задачу, версию навыка, состояние Android, разрешения и точку расхождения.
2. Определить минимальную правку. Изменить одно правило, описание инструмента, проверку или процедуру восстановления.
3. Запустить регрессионный набор. Проверить исходную ошибку, ранее успешные сценарии и соседние варианты состояния.
4. Сравнить разрешения. Установить, добавляет ли версия приложение, категорию данных или новое значимое действие.
5. Получить одобрение. Показать смысл правки, тесты, изменения полномочий и план отката.
6. Присвоить версию. Сохранить код или описание навыка, зависимости, модельную конфигурацию и результаты тестов.
7. Выпустить поэтапно. Начать с ограниченного набора задач или устройств.
8. Наблюдать. Сравнивать успех, ошибки, задержку, подтверждения и ручные продолжения.
9. Откатить при отклонении. Вернуть предыдущую проверенную версию без потери истории.

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

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

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

Какие ошибки может создать само улучшение

Почему исправление иногда делает агента хуже? Первая причина — вымышленный сбой. Исследование Phantom Guardrails показывает риск, при котором оптимизатор придумывает проблему и добавляет ненужное ограничение. Если приемка проверяет только исчезновение предполагаемой ошибки, новое правило может пройти тест, хотя исходной проблемы не существовало.

Поэтому трасса должна подтверждать реальное расхождение. Полезны повторный запуск, независимая проверка итогового состояния и сравнение с контрольной версией. Suppression-only подход, при котором достаточно подавить тревожный сигнал, не устанавливает, стала ли задача выполняться правильнее.

Вторая причина — переобучение навыка на одном интерфейсе. Исправление может искать кнопку по точной позиции или тексту, который существует только в одном языке. После обновления приложения, смены ориентации или локализации правило перестает работать. Регрессионные тесты должны проверять смысловой элемент и несколько вариантов состояния.

Третья причина — permission drift. Новая версия начинает запрашивать более широкий доступ, чтобы повысить процент завершения. Такой рост нельзя считать обычной оптимизацией. Расширение полномочий требует явного обоснования и одобрения, а тесты должны подтверждать, что старые сценарии не получают ненужный доступ.

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

Наконец, неизменный benchmark недостаточен. Он не отражает новый интерфейс приложения, реальное состояние аккаунта, диалоги Android и последствия чувствительного действия. Лабораторный набор полезен как стабильная база, но его дополняют свежие трассы и проверки в контролируемой телефонной среде. Разницу между песочницей и реальными разрешениями объясняет статья Песочница AI-агента и разрешения телефона: почему безопасным агентам нужны границы.

Как проверить готовность новой версии к Android

Как понять, что самоулучшение готово к практическому применению? Новая версия должна отвечать не только на вопрос «стало ли больше успешных запусков», но и на вопросы о полномочиях, наблюдаемости и восстановлении.

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

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

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

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