Бесплатная консультация
·6 мин чтения

AI-агенты, имитирующие человека в приложениях: полный разбор на примере Tinder

Архитектура человекоподобного AI-агента: гибрид vision + voice, Playwright через CDP
Архитектура: гибрид vision + voice, Playwright через CDP

Большинство «браузерных ботов» примерно так же незаметны, как кирпич в окне. Поднимают headless-Chromium, ломятся через DOM — и палятся, не успев поздороваться. Нам же хотелось обратного: агента, который ведёт себя как живой человек внутри реального приложения — смотрит на экран, рассуждает вслух и кликает с уверенностью слегка переоценивающего себя пользователя.

Полигоном мы выбрали Tinder. Не ради романтики — ради антифрода. Tinder требует голоса, контекста и визуала одновременно и активно охотится на автоматизацию. Если агент выживает там — выживет почти везде. Вот полный разбор.

1. Что значит «имитирующий человека»

Классический скрейпер читает данные. Наш агент пользуется приложением — видит карточку, оценивает её под ваш вкус, обсуждает голосом и свайпает. Разница принципиальная: скрейпер потребляет страницу, агент её проживает. Цель проекта — личный AI-помощник, который смотрит карточки, оценивает их по вашим критериям, обсуждает вслух и сам жмёт кнопки.

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

2. Как не спалиться у приложения (антибан)

Первый урок, выученный на собственной шкуре: headless-браузеры палятся за секунды. Tinder одним взглядом распознаёт headless-Chromium и зацикливает его в бесконечной капче. Конец игры.

Второй урок: импорт cookie не спасает. Tinder опирается на localStorage плюс fingerprint устройства, так что перенос cookies в свежий браузер не обманывает никого.

Решение почти философское. Вместо того чтобы запускать свой браузер, мы подцепляемся к браузеру пользователя. Через Chrome DevTools Protocol (CDP) Playwright управляет не своим Chromium, а вашим собственным Chrome — со всей реальной историей, cookies и fingerprint'ом. Ключевой инсайт: человекоподобный агент не должен открывать новый браузер. Он должен ехать внутри человеческого.

3. Playwright MCP — как AI получает «руки»

Это самый интересный кирпич в стене, поэтому развернём его ниже. Если коротко: Playwright даёт агенту руки, а MCP делает эти руки стандартным переиспользуемым инструментом.

4. Гибридный AI: разные модели для разных модальностей

Забавное ограничение. OpenAI Realtime API даёт роскошный голос с минимальной задержкой через WebRTC — но протолкнуть картинку в этот канал нельзя (у data-канала лимит на размер). То есть модель, которая красиво говорит, по сути слепа.

Решение — пусть каждая модель делает то, что умеет лучше всех. Claude Haiku 4.5 смотрит на скриншот и пишет чёткое текстовое описание. Этот текст уходит в OpenAI Realtime, который превращает его в естественную речь. Claude отвечает за зрение и рассуждение, OpenAI — за голос и диалог. Два специалиста бьют одного универсала, пытающегося тянуть всё сразу.

Вид агента: карточка профиля со свайп-кнопками, live AI-HUD с рассуждением агента и статистика сессии
Что «видит» агент — карточка, голосовой HUD и статистика сессии (UI-мокап).

5. Push-context архитектура

Наивный дизайн — конечный автомат, ощетинившийся кучей tools. Мы пошли в другую сторону. Вместо FSM сервер сам пушит контекст прямо в Realtime-сессию через conversation.item.create / input_text. Модель просто знает, что на экране новая карта, ещё до того как пользователь открыл рот.

Выхлоп: один tool (swipe) вместо трёх, никаких багов конечного автомата, а задержки спрятаны за естественным диалогом. UX остаётся плавным, потому что агент всегда на шаг впереди.

6. Промпт-инжиниринг с характером

Агент не обязан звучать как выверенный фокус-группой бот техподдержки. Немного характера решает многое — и, что важнее, делает разговор разговором. Мы подгружали собственные критерии пользователя (bio_criteria) в каждый промпт, чтобы оценки совпадали с его вкусом, а не вкусом модели. Плюс прикрутили триггер-фразы под готовые сценарии — говоришь нужные слова, и агент выдаёт статистику лайков и матчей. Характер — это не украшение, это UX.

7. Чему учит проект (5 инсайтов одной строкой)

  • Realtime API ≠ multimodal API — vision цепляй сбоку.
  • Hybrid AI — это норма, а не костыль — пусть специалисты специализируются.
  • CDP-attach > headless против любой серьёзной антифрод-системы.
  • Заполняй паузы — 6 секунд тишины убивают UX.
  • Системный промпт с характером даёт +100 к качеству диалога.

Развёрнуто: Playwright MCP

Вот ради этой части стоит притормозить.

Что такое MCP в одну строку

Model Context Protocol — стандарт от Anthropic (ноябрь 2024), который описывает, как LLM получает доступ к внешним инструментам. До MCP каждый клиент — Claude Code, Cursor, ваше приложение — тащил свои интеграции отдельно. С MCP единый протокол: сервер выставляет tools / resources / prompts, а любой клиент подключается и использует.

Что такое Playwright MCP

Playwright MCP — это MCP-сервер от Microsoft, который оборачивает Playwright в стандартный интерфейс. Результат: любая LLM может управлять браузером через стандартные tool-вызовы — browser_navigate, browser_click, browser_snapshot, browser_evaluate и другие.

Зачем он в нашем кейсе

Playwright у нас работает в двух режимах — и в этом весь фокус:

  • A. Прямой Playwright в Python (production-логика) — клики, скриншоты, инжект HUD. Точный контроль, обработка ошибок, асинхронность. Это «руки» агента в реальном времени.
  • B. Playwright MCP внутри Claude Code (разработка и отладка) — на этапе разработки можно буквально сказать «открой приложение, сделай скриншот», и модель сделает это через MCP. AI пишет код, глядя на живой результат: запустил скрипт, снял snapshot, увидел поломку, исправил, повторил.

Оба режима подключаются к одному Chrome через один CDP-порт (9222) и не конфликтуют с production-Playwright. Всю тяжёлую работу делает одна строчка конфига:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--cdp-endpoint", "http://localhost:9222"]
    }
  }
}

Один флаг --cdp-endpoint превращает MCP-сервер из «открывает свой Chromium» в «подцепляется к Chrome пользователя». Для антибана это решает всё.

Почему это ключевой кирпич, а не сноска

Playwright MCP превращает AI в самостоятельного разработчика: видит ошибку → правит код → проверяет через snapshot → итерирует. Тесты становятся разговором («проверь, что появилась плашка»), а та же самая связка автоматизирует любое веб-приложение — приделай её завтра к CRM, Notion-воркспейсу или дашборду Stripe, и получишь голосового агента и для них. Один стандартный протокол несёт агента через разработку, тесты и продакшн. Это и есть имитация человека на новом уровне: AI не просто скриптует действия — он держит браузер как инструмент, одинаково, на всех этапах.

Стек одной строкой

Claude Sonnet/Haiku 4.5 (vision) · OpenAI gpt-realtime (voice, WebRTC) · Playwright + Playwright MCP (Chrome через CDP) · FastAPI + SQLite WAL (бэкенд) · Streamlit (дашборд) · MCP (универсальный мост между AI и внешними инструментами).

Ничего из этого не привязано к Tinder. Меняете целевое приложение — и та же архитектура (скрытное управление браузером, гибрид vision-плюс-voice, push-context, один чистый tool) превращается в человекоподобного агента для любого нужного процесса. Если у вас есть приложение, которым вы бы втайне хотели управлять «как человек» — это ровно то, что мы умеем строить.