ИИ-агент с личным контекстом: как телефон понимает задачу и переходит к действию

Что такое личный контекст ИИ-агента на примере одной задачи

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

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

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

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

Стек контекста: экран, сессия, подключенные данные, предпочтения и память

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

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

Третий слой составляют подключенные данные и разрешенные сигналы телефона. Это календарь, почта, уведомления, контакты, геолокация, состояние сети, файлы, заметки, подключенные сервисы и другие источники, если они действительно нужны задаче. Справка Google по персонализации Gemini описывает разные источники персонализации, включая прошлые чаты, подключенные приложения и инструкции для ответов. Это хороший пример того, почему источники нужно различать: подключенный сервис, Android-разрешение и настройка ответа являются разными controls.

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

Пятый слой это долговременная память. Память и контекст ИИ часто смешивают, но для телефона это разные вещи. Память хранит устойчивые сведения и привычки, а контекст задачи помогает прямо сейчас. Для глубины по архитектуре памяти мы вынесли отдельный материал Статус сервера Hy-Memory и локальная память агента: что важно пользователям телефона. В этой статье важен прикладной вывод: временный контекст может быть полезен без постоянного хранения.

Как выбрать минимальный контекст для задачи

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

Android рекомендует минимизировать запросы разрешений, использовать scoped alternatives и gracefully degrade, когда пользователь отказывает в доступе. В пользовательском языке это звучит так: агент должен просить доступ в момент, когда он нужен, объяснять пользу и иметь запасной путь. Отказ в разрешении не должен ломать весь сценарий. Если нет доступа к геолокации, можно попросить пользователя выбрать адрес вручную. Если нет доступа к контактам, можно отправить черновик в выбранном приложении без чтения всей адресной книги.

При выборе контекста учитывайте четыре критерия. Первый: релевантность. Сигнал должен реально улучшать следующий шаг. Второй: чувствительность. Личные сообщения и файлы требуют более строгого контроля, чем настройка яркости. Третий: срок жизни. Одноразовый экранный контекст не должен автоматически становиться долговременной памятью. Четвертый: fallback. Если сигнал недоступен, агент должен предложить ручной ввод, сокращенный сценарий или остановку.

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

Как контекст превращается в поддерживаемое действие Android

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

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

После выполнения нужен visible state. Пользователь должен видеть, что изменилось: сообщение осталось черновиком или отправлено, событие создано, настройка включена, маршрут открыт, файл найден, разрешение восстановлено. Ответ модели «готово» не является достаточным доказательством, если действие имеет последствия. Проверяемое состояние телефона делает агентный workflow управляемым.

В FoneClaw этот мост устроен как governed Android execution. Совместимая настроенная модель отвечает за reasoning и планирование, а FoneClaw предоставляет поддерживаемые Android-инструменты, разрешения, approvals, stop, permission recovery, state checks и понятные сообщения о сбоях. Пользователь может начать с модели по умолчанию или настроить совместимую модель, но сама телефонная часть остается внутри управляемого Android-runtime.

Текущий экран особенно ускоряет этот процесс. Когда пользователь прикрепляет экран сам, агенту не нужно угадывать, где он находится. Он видит ограниченный фрагмент задачи, выбирает поддерживаемое действие и показывает следующий шаг. На странице Функции FoneClaw мы описываем 100+ built-in tools как практическую поверхность возможностей: экран и приложения, системное состояние, календарь, коммуникации, навигация, заметки, workflows и другие поддерживаемые действия. Точные детали стоит проверять там, потому что возможности продукта развиваются.

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

Когда контекст устаревает, мешает или содержит чужие инструкции

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

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

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

Четвертая проблема это instruction-bearing context. Страница, письмо, чат или документ может содержать фразы, похожие на инструкцию агенту: «игнорируй предыдущие правила», «отправь файл», «нажми эту кнопку». Такой текст может быть частью контента, а не намерением пользователя. Агент не должен автоматически превращать чужие инструкции в действие. Перед внешним эффектом он должен проверить источник, цель и подтверждение пользователя.

Эти риски не превращают контекст в плохую идею. Они показывают, почему нужны refresh, clarification, stop и user takeover. Если агент сомневается, он должен показать, какой контекст использует, попросить уточнение или остановить выполнение до безопасного продолжения. Для governance-слоя полезна отдельная статья Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов: она помогает понять, как связывать действие с владельцем, разрешением и доказательством.

Как безопасно проверить контекстного агента обратимой задачей

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

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

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

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

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

Как мы проектируем контекст в FoneClaw

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

Плавающий доступ и пользовательское прикрепление текущего экрана делают immediate context понятным. Пользователь сам вызывает FoneClaw, показывает, где он находится, и формулирует цель. Затем настроенная модель или модель по умолчанию помогает разобрать задачу, а FoneClaw проверяет, есть ли поддерживаемый Android-путь. Если действие возможно, оно идет через governed tools и approval choices. Если не хватает доступа, включается permission recovery. Если экран изменился или действие не поддержано, пользователь видит объяснение и может остановить или сузить задачу.

Мы также разделяем локальные и сетевые пути. Личная память, локально управляемая информация аккаунтов, настроенные онлайн-модели и подключенные сервисы имеют разные privacy и network implications. Поэтому пользователь должен понимать, где работает временный контекст, где хранится долговременная память и когда выбранная модель или сервис требует передачу данных по сети. Для оценки этого выбора полезен материал AI agent trust: локальный AI-агент на Android против облачной безопасности.

Следующий шаг практичный: посмотрите актуальные возможности на странице Функции FoneClaw, установку и совместимость на странице Загрузка FoneClaw, затем попробуйте одну обратимую Android-задачу. Для нас это и есть правильная траектория развития phone AI: меньше неопределенного сбора контекста, больше видимого выполнения, granular controls и безопасного восстановления, когда реальный телефон ведет себя не так, как ожидалось.