Pinky через MCP дал Claude управление реальным телефоном — платежи только с вашего «ок»

Если вы хоть раз писали мобильное приложение, то знаете главную боль: проверять его приходится руками. Тапнуть, пролистнуть, увидеть баг, вернуться в редактор. Кодинг-агенты вроде Claude Code и Cursor давно справляются с терминалом и браузером, но до телефона не дотягивались. Проект Pinky пытается это исправить: он отдаёт агенту настоящий смартфон через протокол MCP.

Что именно заявлено

Судя по посту в X от @xiaoanlab, схема такая. Pinky выступает MCP-сервером, к которому подключаются Claude Code или Cursor. Через него агент получает картинку экрана реального устройства и может по нему нажимать. Заявлена поддержка и iPhone, и Android. Речь не об эмуляторе, а о физическом телефоне, и это важное отличие: на настоящем железе вылезают те баги, которых нет в симуляторе, от капризов камеры и пуш-уведомлений до поведения системных диалогов.

Простой пример. Вы просите агента: «Открой приложение, пройди регистрацию и проверь, что после входа показывается онбординг». Раньше такой сценарий надо было описывать в UI-тестах на Appium или XCUITest, а потом чинить при каждом изменении вёрстки. Здесь агент смотрит на экран как человек и принимает решения по ходу дела.

Главный вопрос: кто держит руку на кнопке

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

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

Ограничения и что с этим делать

Сначала о том, чего мы не знаем. Источник один, это короткий пост с 88 просмотрами, текст обрезан на середине фразы. Нет ни документации, ни цены, ни данных о задержках, ни сведений о том, как реализован доступ к iPhone. С iOS это нетривиально из-за закрытости системы, и подробностей автор не даёт. Неизвестно, работает ли всё локально или экран уходит на чужие серверы. Для тестирования приложений с пользовательскими данными это критично.

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

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