Маршрутизация моделей для телефонного агента: Kimi, DeepSeek, GLM и Android-действия FoneClaw
Как выбирать модель для Android-агента не по статичному рейтингу, а по надежности вызова инструментов, задержке, стоимости LLM, контексту, приватности, fallback и проверке действий на телефоне.
- Маршрутизация моделей для телефонного агента — это выбор подходящего движка рассуждения под конкретную задачу, а не поиск одной вечной модели-победителя.
- Для Android-действий важны пять сигналов: надежность структурированных вызовов, задержка, стоимость LLM, удержание контекста и границы приватности или размещения модели.
- Kimi, DeepSeek и GLM стоит рассматривать как текущие кандидаты для разных маршрутов, но каждый вариант нужно проверять внутри реального phone-agent loop, а не только по новостям или бенчмаркам.
- В FoneClaw модель помогает понять и спланировать запрос, а Android-выполнение проходит через 100+ built-in tools, capability routing, approvals, видимые результаты, остановку и permission recovery.
Выбирайте маршрут, а не вечного победителя
Маршрутизация моделей для телефонного агента — это правило выбора модели под конкретную задачу телефона: быструю команду, длинный контекст, сложное рассуждение, чувствительные данные, дешевый массовый сценарий или действие, где особенно важна надежность вызова инструментов. Поэтому вопрос «какая модель лучше для Android-агента» полезнее переформулировать так: какую модель стоит использовать для этого запроса, на этом устройстве, с этими разрешениями и с таким допустимым риском.
Статичный рейтинг быстро устаревает. Доступность моделей меняется, цены API меняются, провайдеры добавляют новые маршруты, а поведение модели может отличаться между обычным чатом и структурированным вызовом инструмента. Модель, которая отлично пишет текст, не обязательно стабильно формирует аргументы для календаря, контакта, маршрута, заметки или системной настройки. И наоборот: быстрая недорогая модель может быть правильным выбором для короткой команды, если задача проста и Android-слой хорошо ограничивает действие.
В телефонном агенте есть две разные части. Первая — модельное понимание: разобрать намерение, удержать контекст, выбрать план и подготовить параметры. Вторая — выполнение на Android: проверить состояние устройства, разрешения, доступный инструмент, экран результата, подтверждение и восстановление. Если смешать эти слои, модельный хайп начнет подменять доказательство действия.
Мы в FoneClaw строим маршрутизацию именно вокруг этой границы. Модель помогает думать, а FoneClaw выполняет поддерживаемый Android-маршрут через управляемые шаги. Подробную настройку endpoint лучше держать отдельно: для этого есть руководство Как подключить API ИИ-модели к Android-агенту FoneClaw. В этой статье фокус другой: как принять решение, когда моделей несколько и ни одна не должна автоматически становиться единственным ответом.
Пять сигналов для маршрутизации модели
Хорошая маршрутизация ИИ-моделей начинается с пяти сигналов: надежность, задержка, стоимость, контекст и приватность. Эти сигналы нужно оценивать вместе. Самая дешевая модель может быть дорогой на практике, если часто ошибается в аргументах инструмента. Самая крупная модель может быть избыточной для простого действия вроде «открой настройки Wi-Fi». Самый длинный контекст не помогает, если модель теряет ключевой номер телефона или путает адресата.
| Сигнал | Что проверять в phone agent | Когда менять маршрут |
|---|---|---|
| Надежность | Стабильность JSON, схемы, аргументов, выбора инструмента, уточнений и отказа от неподдержанного действия | Модель придумывает tool, путает поля, пропускает approval или уверенно выбирает неверный объект |
| Задержка | Время до понятного плана и до первого полезного результата на телефоне | Пользователь ждет дольше, чем заняло бы ручное действие |
| Стоимость LLM | Цена повторяющихся команд, длинных контекстов, fallback-повторов и мультимодальных запросов | Простой сценарий начинает потреблять бюджет как сложный анализ |
| Контекст | Удержание текущего экрана, языка, контакта, даты, вложения, истории задачи и ограничений пользователя | Большой контекст ухудшает точность или модель цепляется за нерелевантные детали |
| Приватность | Какие данные уходят онлайн, что можно сократить, когда подходит локальный или поддерживаемый on-device route | Запрос содержит личные сообщения, контакты, документы, почту или данные, которые лучше минимизировать |
Надежность вызова инструментов для телефона означает больше, чем «модель правильно ответила». Она должна выдавать параметры, которые можно проверить: один контакт вместо расплывчатого имени, конкретное время вместо «вечером» без уточнения, поддерживаемое действие вместо воображаемого API, корректный fallback вместо имитации успеха. Для Android особенно важна дисциплина аргументов: приложению нельзя передавать неясную цель, если следующий шаг меняет данные или отправляет сообщение.
Задержка тоже зависит от сценария. Для голосовой команды пользователь ожидает быстрый ответ. Для анализа длинного письма или документа допустима большая пауза, если модель возвращает точный план. Стоимость LLM следует считать не только по одному вызову, а по всей задаче: повторные уточнения, ошибки маршрута, слишком длинный контекст и неудачный fallback могут сделать дешевый маршрут дорогим.
Приватность и размещение модели задают отдельный слой решения. Онлайн-модель удобна для качества и масштаба, локальный или поддерживаемый on-device route полезен, когда нужен меньший сетевой след или работа с более ограниченным контекстом. Но локальность не отменяет Android-разрешения, а облачный маршрут не должен получать больше данных, чем нужно для задачи. Если нужно глубже посчитать стоимость и локальные варианты, рядом полезна статья AI agent token cost: почему локальный Android-агент может снизить расходы.
Kimi, DeepSeek и GLM как текущие кандидаты
Kimi, DeepSeek и GLM полезно рассматривать не как участников одного окончательного пьедестала, а как текущие кандидаты для разных маршрутов. В исходном сравнении MarkTechPost о Kimi K3, DeepSeek V4 Pro и GLM-5.2 модели разбирались через бенчмарки, лицензирование и стоимость обслуживания. Это полезно для карты рынка, но phone agent требует следующего шага: проверить, как модель ведет себя в структурированном Android-сценарии.
У Kimi появился дополнительный инфраструктурный сигнал: GitHub сообщил о доступности Kimi K3 в GitHub Copilot как выбираемой модели. Для разработчиков это показывает расширение присутствия модели в mainstream model picker. Для Android-агента это не доказательство надежности телефонных действий, но хороший повод добавить Kimi в список кандидатов для тестов: короткие инструкции, планирование, многошаговые рассуждения и стабильность формата.
DeepSeek остается важным примером маршрута, где команды часто смотрят на соотношение возможностей, доступности и стоимости. Но для телефонного агента проверка должна быть прикладной: не только насколько убедительно модель рассуждает, а как она выбирает tool, задает уточнение, удерживает русский запрос с английскими именами контактов и останавливается при неоднозначности. Текстовая сила без дисциплины выполнения может ухудшить UX.
GLM интересен как еще один кандидат для сложных рассуждений и внешних проверок. В текущей базе статьи сохраняется ссылка на оценку NIST CAISI для Z.ai GLM-5.2, потому что независимые оценки важны для доверия к модели. Но и здесь граница та же: внешняя оценка модели не заменяет тест на вашем Android-устройстве, с вашими разрешениями, языком, приложениями и real-world failure modes.
Qwen, Hy3 и другие модели могут входить в такую же политику маршрутизации. сообщение South China Morning Post о новом Qwen-превью Alibaba показывает, насколько быстро меняется верхний слой моделей. Именно поэтому мы не строим рекомендацию вокруг одного имени. Мы строим тест: что модель делает с задачей телефона, сколько стоит маршрут, какова задержка и насколько стабильно она готовит Android-действие.
Как пережить смену цены и доступности API
Стоимость LLM и доступность API меняются быстрее, чем привычки пользователей. Если телефонный агент привязан к одной модели без fallback, любой скачок цены, лимит, outage или изменение поведения может сломать рабочий сценарий. Правильная политика маршрутизации описывает не только «основную модель», но и условия переключения: когда использовать быстрый маршрут, когда повышать качество, когда сокращать контекст, когда возвращаться к пользователю за подтверждением.
Инфраструктурный рынок движется в ту же сторону. В публикации Google Developers о unified API для маршрутизации моделей Google Cloud API Gateway описывает model routing в public preview и поддержку нескольких провайдеров через один управляемый API surface. Для нас это важный сигнал инфраструктуры: продукты хотят переключать модели осознанно, не переписывая каждый сценарий вручную. Но это не доказательство, что любой провайдер автоматически совместим с FoneClaw или надежен для Android-действий.
Цена должна менять маршрут, но не должна незаметно менять риск. Для низкочувствительной задачи, например переформулировать заметку или обобщить короткий текст, можно переключиться на более дешевую модель после базовой проверки качества. Для отправки сообщения, создания события, работы с почтой, контактами или системными настройками переключение требует повторного теста: структура аргументов, уточнения, approval, видимый результат и recovery должны остаться стабильными.
Мы рекомендуем задавать бюджетные пороги на уровне класса задач. Короткие массовые запросы получают cost ceiling. Длинные документы получают отдельный лимит контекста. Чувствительные действия получают quality floor и запрет на silent provider switching. Если fallback меняет модель, пользовательский опыт должен оставаться понятным: задача может быть замедлена, упрощена или остановлена, но не должна завершаться скрытым изменением поведения.
После каждого заметного изменения цены, доступности или endpoint-настроек нужно прогнать короткий набор regression tasks. Не проверяйте только ответы. Проверяйте failure modes: неправильный контакт, отсутствующее разрешение, несколько календарей, потеря сети, длинный контекст, неоднозначный экран. Именно такие сбои показывают, выдерживает ли routing policy реальный телефон.
Проверка модели внутри Android-действия
Качество модели для Android-агента измеряется внутри полного action loop. Первый шаг — понять запрос. Второй — построить план. Третий — сформировать валидные параметры инструмента. Четвертый — сверить состояние устройства: приложение установлено, экран доступен, разрешение есть, объект выбран. Пятый — показать результат и approval. Шестой — восстановиться, если устройство отличается от ожидания.
Правильный ответ в чате может все равно привести к проваленному телефонному действию. Например, модель точно поняла «напомни мне позвонить Ивану завтра утром», но передала несуществующий contact id, выбрала не тот календарь, не уточнила время или попыталась завершить действие без проверки разрешения. В обычном текстовом бенчмарке это может выглядеть как мелкая ошибка. На телефоне это уже нарушение маршрута.
Проверяйте модель на одном и том же устройстве, с одним и тем же языком, аккаунтом, состоянием разрешений и набором приложений. Один тестовый набор должен включать простую команду, длинный контекст, неоднозначный контакт, отсутствующее разрешение, unsupported action и действие с подтверждением. Оценивайте не только success rate, но и качество остановки: модель должна уметь сказать «нужно уточнить», «это действие не поддержано», «требуется разрешение» или «я подготовил черновик, подтвердите отправку».
Для телефонных агентов benchmark должен смотреть на выполнение, а не только на рассуждение. Если вам нужен полный фрейм для таких проверок, используйте наш материал Бенчмарк телефонных агентов Android: как оценивать ИИ-агента в 2026 году. В контексте model routing вывод короткий: модель подходит для маршрута только после проверки в Android loop.
Хороший тест не обязан быть опасным. Начните с обратимой задачи: создать черновик заметки, подготовить несохраненное календарное событие, открыть карту без запуска поездки, проверить статус Wi-Fi или составить SMS без отправки. Сравните две модели на одном маршруте. Если одна быстрее, но чаще теряет аргументы или пропускает уточнение, она может быть хорошей для текста и слабой для phone action.
Как FoneClaw разделяет модель и выполнение
В FoneClaw модель — это слой понимания и планирования, а Android-выполнение остается управляемым продуктовым маршрутом. Пользователь может начать с бесплатной модели по умолчанию или настроить совместимый онлайн-маршрут, а также использовать поддерживаемые on-device варианты там, где это подходит задаче. Мы не считаем выбор модели разрешением на действие. Сначала модель помогает разобрать намерение, затем FoneClaw сопоставляет задачу с возможностью и только потом ведет Android-шаги через видимый результат.
Текущий FoneClaw предоставляет 100+ built-in tools для поддерживаемых Android-сценариев. Внутри продукта это означает практичные маршруты для экрана и приложений, состояния устройства, системных панелей, связи, календаря, заметок, навигации, почты, workflows, Skills и Plugins. Модель может предложить план, но capability routing, activation, approval и execution разделены. AutoAttach, Suggest и Fallback помогают подобрать путь и контекст, но не обходят подтверждение для чувствительного действия.
Наш опыт строительства FoneClaw показывает, что самый полезный model routing начинается с классификации запроса. Быстрая команда вроде «открой настройки батареи» не требует той же модели, что длинное письмо с несколькими условиями. Многоязычная задача с русской фразой и английскими именами контактов требует иной устойчивости, чем простое обобщение заметки. Конфиденциальная почта требует минимизации контекста и ясного результата.
Дальше FoneClaw проверяет Android-реальность. Есть ли нужное разрешение? Установлено ли приложение? Сколько найдено контактов? Какой экран сейчас открыт? Можно ли выполнить действие встроенным инструментом, Workflow, Skill или Plugin? Если ответ неоднозначен, FoneClaw останавливается на уточнении или предлагает fallback. Если действие имеет внешний эффект, пользователь видит, что именно будет сделано.
Для читателя лучший способ проверить FoneClaw — сравнить два настроенных маршрута на одной обратимой задаче. Например: «создай черновик заметки из этого текста», «подготовь событие календаря, но не сохраняй», «проверь состояние сети» или «открой страницу приложения в настройках». Оцените не красоту ответа, а весь путь: понял ли агент задачу, выбрал ли поддерживаемый tool, показал ли результат, запросил ли approval где нужно и объяснил ли recovery при отсутствующем разрешении. Текущие пользовательские возможности доступны на странице функций FoneClaw, а начать проверку можно со страницы загрузки FoneClaw.
Если нужно увидеть, как модельный маршрут соединяется с реальным Android-действием, рядом полезен разбор Управление телефоном AI-агентом: как Android переходит от команд к действиям. Он помогает не путать качество рассуждения с правом и способностью выполнить действие на устройстве.
Практическая политика маршрутизации
Практическая routing policy для phone agent должна быть короткой и проверяемой. Сначала классифицируйте задачу: информационный ответ, текстовый черновик, длинный анализ, Android-действие без внешнего эффекта, действие с внешним эффектом или чувствительный сценарий. Затем задайте quality floor: какой процент корректных tool arguments, уточнений и recovery считается допустимым. После этого задайте cost ceiling и latency ceiling для каждого класса.
- Определите класс задачи. Не направляйте открытие системной панели и анализ длинного письма в один маршрут без причины.
- Выберите основную модель. Смотрите на надежность, задержку, стоимость, контекст и приватность, а не только на бенчмарк.
- Назначьте fallback. Он может быть более сильным, более дешевым, локальным, онлайн или ручным, но его нужно протестировать.
- Запишите stop rules. Нет разрешения, неоднозначный объект, неподдержанное действие, превышение бюджета или нестабильная схема должны останавливать выполнение.
- Проверяйте на реальном телефоне. Фиксируйте не только удачи, но и failure modes: неверный контакт, пропущенное уточнение, задержку, timeout и recovery.
Маршрутизация моделей для телефонного агента не должна быть set-and-forget настройкой. Она живет вместе с ценами, доступностью, новыми моделями, языками пользователей и Android-ограничениями. Поэтому мы в FoneClaw строим устойчивую границу: модель можно менять и тестировать, а выполнение поддерживаемых Android-действий остается управляемым, видимым и подтверждаемым.