Маршрутизация возможностей ИИ-агента Android: AutoAttach, Suggest, Fallback и контроль FoneClaw

От запроса к кандидатам возможностей

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

Телефонный агент не может разумно держать все инструменты, плагины, навыки и сценарии в активном контексте каждой задачи. Это делает ответы тяжелее, повышает риск ложного совпадения и усложняет контроль. Поэтому первый шаг — сузить поле. Запрос, текущий экран, тип приложения, разрешения, доступные возможности, история текущей задачи и confidence score помогают построить ранжированный список кандидатов.

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

Мы в FoneClaw проектируем этот слой как диагностическое дерево. Сначала агент понимает намерение и контекст. Затем выбирает кандидатов: built-in tool, Skill, Workflow, Plugin или Fallback. Потом проверяет, можно ли безопасно приложить контекст, показать suggestion, активировать расширение, запросить approval и выполнить Android-действие. Общий словарь слоев мы держим отдельно в статье Инструменты, плагины, навыки и сценарии FoneClaw: как выбрать слой, а здесь разбираем именно механику выбора маршрута.

AutoAttach, Suggest или Fallback

После ранжирования у capability router есть три практичных режима: AutoAttach, Suggest и Fallback. Они похожи тем, что помогают продолжить задачу, но отвечают за разные уровни уверенности и контроля. Самая частая ошибка — считать AutoAttach скрытым выполнением. В корректной архитектуре AutoAttach прикладывает релевантный контекст или metadata, но не запускает инструмент и не обходит approval.

AutoAttach подходит, когда совпадение очевидно и действие само по себе не имеет внешнего эффекта. Например, пользователь просит «объясни этот экран», а FoneClaw может приложить текущий экран, исключив собственные overlay-элементы. Или пользователь работает с открытой заметкой и просит краткое резюме: контекст текущего экрана помогает модели понять задачу, но еще не меняет данные. AutoAttach экономит шаги, когда риск ложного вложения низкий.

Suggest нужен, когда кандидат полезен, но требуется выбор. Например, запрос «сохрани это в задачу» может относиться к задачам, заметкам, календарю или Workflow. Агент показывает варианты: создать задачу, сохранить заметку, открыть календарный черновик, настроить повторяемый Workflow. Пользователь видит, что именно будет использовано, и выбирает маршрут. Suggest особенно важен, когда несколько возможностей имеют близкий confidence.

Fallback нужен, когда уверенного маршрута нет, возможность отсутствует, зависимость не активирована, permission отказан или цель неоднозначна. Хороший Fallback не прячет проблему. Он предлагает продолжение: открыть нужный экран вручную, сохранить текст как заметку, запросить недостающее разрешение, предложить Skill draft, показать Plugin candidate для review или завершить безопасную часть задачи без внешнего эффекта.

Эта матрица помогает проектировать поведение без лишней магии. Пользователь должен понимать, почему агент приложил экран, почему показал выбор или почему остановился. Именно здесь confidence становится UX-решением, а не внутренним числом.

Состояния маршрута: от discovery до execution

Главная категория ошибок в маршрутизации возможностей — смешать discovery, attachment, activation, approval и execution. Эти состояния должны быть разделены. Discovery отвечает за обнаружение кандидата. Attachment добавляет релевантный контекст. Activation включает или готовит возможность к использованию. Approval получает согласие на действие. Execution выполняет поддержанный шаг и проверяет результат.

Экосистема движется к более явным упаковкам возможностей. В публикации Google Developers об Agent Plugins Agent Plugins описаны как открытая vendor-neutral спецификация для упаковки Agent Skills и MCP servers с общей metadata. Это полезный сигнал: возможности агентной системы требуют описания, структуры и зависимостей. Но упаковка не означает доверие, installation, activation или право выполнить действие.

Похожая граница видна и в discovery-подходах. В анонсе GitHub об Agent finder система ранжирует релевантные ресурсы по запросу и работает в рамках настроенных registries и managed settings. Для нашей темы важен принцип: найденный ресурс не устанавливается молча и не получает автоматическое право действовать. Мы не заявляем интеграцию GitHub с FoneClaw; это полезная аналогия для разделения поиска и выполнения.

В Android-сценарии state machine выглядит так: пользователь дает запрос; маршрутизатор находит кандидатов; AutoAttach может приложить контекст; Suggest может показать варианты; activation review проверяет Plugin или Skill lifecycle; approval появляется перед чувствительным действием; execution открывает экран, создает черновик, меняет настройку или выполняет другой поддержанный шаг; result check подтверждает, что телефон действительно пришел в ожидаемое состояние.

Если включенная возможность существует, это не делает ее одобренной для каждого действия. Например, включенный календарный инструмент может быть доступен для чтения событий, но создание встречи требует отдельного результата, календаря, времени и подтверждения. В FoneClaw мы держим это разделение жестко: возможность может быть найдена, предложена и активирована, но consequential action остается approval-aware.

Какие данные нужны маршрутизатору

Надежная маршрутизация плагинов и навыков невозможна без входных данных. Первое — identity. Возможность должна иметь понятное имя, назначение, тип, источник, версию контракта в публичной поверхности, supported actions и ограничения. Для Plugin или Skill metadata помогает понять, какие задачи он покрывает, но сама metadata не делает расширение доверенным.

Второе — dependencies. Если возможность требует другой пакет, системное permission, активный аккаунт, установленное приложение, network state или external provider, это нужно проверить до activation или execution. Иначе агент создаст красивый план, который развалится на первом Android-экране. Dependencies должны быть либо удовлетворены, либо явно показаны пользователю как недостающий шаг.

Третье — context metadata. Текущий экран, тип приложения, выбранный текст, язык запроса, время, device state, доступные permissions и история текущей задачи помогают сузить кандидатов. Но контекстный выбор возможностей должен быть минимальным: прикладывать нужно то, что помогает задаче, а не все, что телефон потенциально может видеть.

Четвертое — confidence и ambiguity. Уверенность должна учитывать не только similarity между запросом и описанием возможности, но и риск. Высокий confidence для чтения экрана и высокий confidence для отправки сообщения — разные ситуации. Чем выше внешний эффект, тем больше роль Suggest и approval. Ложноположительное совпадение может быть хуже no-match, потому что пользователь увидит активное действие там, где нужна остановка.

Еще один практичный механизм — atomic capability snapshots. Если обновление набора возможностей или Plugin refresh завершилось не полностью, безопаснее сохранить последний согласованный набор, чем активировать частичное состояние. Для пользователя это выглядит просто: FoneClaw предлагает только те маршруты, которые может объяснить и провести до результата или честного recovery.

Восстановление при промахе маршрута

Маршрутизация инструментов Android должна проектироваться вокруг сбоев, а не только вокруг удачных совпадений. Возможность может отсутствовать, dependency может устареть, permission может быть отозван, Plugin может ждать review, Skill может быть сохранен как disabled draft, а цель может оказаться неоднозначной. В этих случаях бесконечный retry модели только ухудшает опыт.

Missing capability означает, что подходящего supported route нет. Правильный ответ — не имитировать действие, а предложить безопасную альтернативу: открыть нужный экран, сохранить черновик, попросить уточнение, предложить создать Skill draft или показать Plugin candidate для review. Если задача относится к registry discovery и доверенным каталогам, подробный фон вынесен в статью Agentic Resource Discovery: ai-catalog.json, доверенные каталоги и полномочия phone agent. Эта страница остается про выбор маршрута после появления кандидатов.

Stale dependency требует другого recovery. Например, приложение удалено, аккаунт вышел, permission исчез, экран изменился или Plugin capability snapshot устарел. FoneClaw должен показать, что именно мешает: нет доступа к календарю, не найдено приложение, нужно выбрать аккаунт, требуется системное разрешение. Permission recovery — это не то же самое, что model retry. Модель может объяснить, но Android-доступ должен быть восстановлен через понятный системный путь.

Denied permission и ambiguous target особенно важны для доверия. Если пользователь отказал в доступе к контактам, агент не должен угадывать адресата из памяти. Если найдено несколько Анн, нужно показать выбор. Если confidence низкий, Suggest или Fallback лучше, чем AutoAttach. Удобный агент иногда обязан замедлиться, чтобы не сделать неверный шаг.

Восстановление должно сохранять task continuity. Пользователь не должен начинать сначала после каждого отказа. Хороший routing layer помнит намерение, показывает недостающий шаг и возвращает задачу к месту, где ее можно безопасно продолжить.

Как это устроено в FoneClaw

В FoneClaw мы строим governed capability routing как практический Android-слой: запрос пользователя превращается в кандидатов, кандидаты проходят локальное сопоставление, а выполнение остается отделенным от выбора возможности. Текущий продукт дает 100+ built-in tools и управляемые пути для Skills, Workflows и reviewed Plugins. Это не универсальное управление каждым приложением; это проверяемые маршруты, где пользователь видит результат и контролирует важные шаги.

Один пример показывает механику. Пользователь открывает письмо с адресом и говорит: «построй маршрут и сохрани это как задачу». FoneClaw видит request, текущий экран и возможные candidates: извлечь адрес из экрана, открыть map navigation, создать task, сохранить Workflow для повторяемого сценария или предложить Fallback, если адрес не распознан. AutoAttach может приложить текущий экран как контекст. Suggest покажет, что можно сделать два отдельных шага: маршрут и задача. Approval потребуется там, где действие меняет данные или запускает внешний route.

AutoAttach в FoneClaw не запускает tool. Он помогает модели получить релевантный локальный контекст или capability metadata. Suggest дает пользователю выбор, когда маршрутов несколько или confidence недостаточно высок. Fallback сохраняет задачу, когда route missing, permission denied, dependency stale или target ambiguous. Мы специально разделяем эти состояния, потому что телефонные действия имеют последствия.

Plugin activation в FoneClaw проходит через review. Если Plugin предлагает новую capability, пользователь должен понимать источник и назначение, прежде чем она станет активным кандидатом. Skill learning работает через preview и confirmation перед сохранением disabled draft: пользователь видит, чему агент предлагает научиться, и решает, сохранять ли черновик. Это делает обучение полезным без скрытого включения действий.

Поддерживаемые built-in tools остаются базовым маршрутом для многих Android-задач: экран и приложения, системные панели, состояние устройства, настройки, навигация, календарь, заметки, коммуникации, workflows и другие повседневные сценарии. Но even built-in route не обходит approval. Если действие чувствительное, FoneClaw показывает объект, причину, уверенность или ограничение и ждет пользовательского решения. Глубже о permission-risk для Skills мы пишем в статье Безопасность навыков AI-агентов: почему телефону нужны проверки разрешений.

Сейчас мы развиваем FoneClaw в сторону более прозрачного routing UX: меньше скрытых переходов, больше проверяемых candidates, яснее причины Suggest и аккуратнее recovery. Текущие пользовательские возможности можно посмотреть на странице функций FoneClaw, а начать проверку на своем Android-устройстве — со страницы загрузки FoneClaw.

Семь проверок для capability router

Capability router нельзя оценивать только по accuracy на удачных запросах. Его нужно тестировать на ложных совпадениях, no-match, устаревших зависимостях, отказанных permissions и действиях с внешним эффектом. Семь проверок дают практичный минимум.

1. Candidate quality. Правильные candidates должны появляться выше похожих, но неподходящих возможностей.
2. False positive. Проверьте запрос, где похожая возможность есть, но запускать ее нельзя или не нужно.
3. No-match. Если маршрута нет, агент должен честно предложить Fallback, а не выдумать tool.
4. Attachment safety. AutoAttach должен прикладывать только релевантный контекст и не выполнять действие.
5. Dependency state. Отсутствующий provider, permission, Plugin или app должны останавливать activation или execution до recovery.
6. Approval boundary. Перед отправкой, изменением, удалением, звонком или раскрытием данных пользователь должен видеть результат и причину.
7. Recovery evidence. После сбоя задача должна вернуться к понятному состоянию, а не теряться в повторных попытках модели.

Для дизайна approval UX полезен отдельный разбор Интерфейс подтверждения действий ИИ-агента на телефоне: уверенность, причины и восстановление. Внутри capability routing главное правило остается простым: подбор помогает найти путь, но право выполнить действие появляется только после проверки состояния, разрешений, пользовательского выбора и видимого результата.