Раньше для подключения N инструментов к M моделям требовалось N×M адаптационных слоев. MCP разделяет сторону инструментов и сторону моделей, поэтому каждой достаточно один раз реализовать протокол. В статье разбираются это архитектурное решение, абстракции браузерных сред и действий на странице, а также нерешенные на сегодня вопросы.
Когда Agent должен действительно выполнить работу, дело обычно заканчивается браузером: входом в аккаунт, публикацией, сбором данных или заполнением форм. Техническая сложность не в том, может ли он нажать кнопку, а в стоимости интеграции при передаче браузера Agent.
Ловушка адаптаций N×M
Предположим, на рынке есть N инструментов и M моделей. Поставщику инструмента приходится писать отдельное подключение для каждой модели, а стороне модели — отдельный адаптационный слой для каждого инструмента. Обе стороны поддерживают свои реализации, поэтому общее число вариантов равно N×M.
Проблема в умножении. Добавление одного инструмента означает не одну дополнительную задачу, а необходимость подключить этот инструмент к каждой модели. И наоборот, при смене версии модели уже подключенные инструменты могут потребовать повторной проверки. Возможность может быть реализована отлично, но без адаптера для конкретной модели она там не работает — инструмент застревает на этапе распространения.
На раннем этапе каждому приходилось писать собственную интеграцию. Одни и те же действия — получить список сред, запустить браузер, прочитать страницу — переписывались для каждого нового вызывающего приложения, причем логика часто расходилась: одни помещали ожидание в клиент, другие — в сервер.
Протокол разделяет две стороны
MCP (Model Context Protocol) был публично представлен в конце 2024 года. Его подход — стандартизировать обнаружение и вызов инструментов: что именно публикуется, как описываются параметры и в какой структуре возвращается результат, определяется протоколом.
Архитектура превращается в Agent, подключенный к MCP Client. Client по протоколу соединяется с несколькими MCP Server, за которыми находятся конкретные возможности. Объем реализации уменьшается с N×M до N+M: сторона модели один раз реализует клиент, а сторона инструмента — сервер.
Ролей всего три. Host — приложение, в котором работает модель и которое запускает клиент. Client — реализация клиента протокола, обычно один на каждый Server. Server создается поставщиком инструмента и предоставляет возможности в виде стандартизированных инструментов.
Сейчас используются два режима связи. Локальный режим работает через стандартный ввод и вывод, а клиент и сервер находятся на одной машине; путь короткий, конфигурации мало, поэтому такой вариант часто используется в автоматизации. Удаленный режим использует HTTP или WebSocket и подходит для распределенных развертываний, но требует отдельно продумать аутентификацию и сетевые границы.
В браузере открываются три уровня возможностей
Когда браузерная среда подключается к протоколу, предоставляемые возможности можно условно разделить на три уровня.
Верхний уровень — среда: получить список сред аккаунта, создать новую по конфигурации, запустить указанную среду, привязать сетевой выход и закрыть после использования. Раньше эти операции были разбросаны по API разных поставщиков; теперь они становятся инструментами, которые модель может обнаруживать и вызывать. После запуска обычно возвращается отладочный endpoint, например порт или адрес WebSocket, который можно передать драйверам вроде Selenium или Puppeteer.
Средний уровень — страница: открыть адрес, прочитать DOM или дерево доступности, переключить вкладку и сделать снимок экрана.
Нижний уровень — действия: нажатие, ввод, прокрутка, ожидание условия и обработка всплывающих окон.
Ключевое изменение не в количестве действий. Среда превращается из кода, который нужно писать самостоятельно, в ресурс, который Agent может сам выбрать и использовать. Достаточно четко указать цель; Agent может решить, создать новую среду или повторно использовать существующую, а также в каком порядке вызывать инструменты. Особенно заметно это при параллельной работе нескольких сред: планирование задается в prompt, а не жестко кодируется в script.
Что пока остается нерешенным
Протокол решает подключение, но не корректность. Остается несколько моментов, которые легко упустить.
Качество описаний инструментов определяет результат вызова. Если параметры указаны неверно или выбран не тот инструмент, протокол это не исправит. По мере роста числа инструментов их описания занимают контекст, поэтому приходится выбирать баланс между количеством и детализацией. Слишком крупная гранулярность мешает модели понять, сколько задач выполняет один инструмент; слишком мелкая быстрее заполняет контекст.
Права и аудит пока находятся на ранней стадии. Многие Server работают локально на одной машине, при запуске получают значительные привилегии и не имеют тонкой авторизации или подробных журналов вызовов. В удаленном режиме прежде всего нужно определить, кто может подключаться и что может видеть.
Нестабильность страниц также никуда не исчезает. Ненайденные элементы, нестабильный порядок загрузки, истекшие сессии и CAPTCHA по-прежнему требуют ожиданий, повторных попыток и резервной логики. Протокол стандартизирует только точку входа.
Зрелость экосистемы тоже неодинакова. Разные Server не полностью совпадают по поддерживаемым типам ресурсов, структурам ответа и кодам ошибок. Когда задача объединяет несколько Server, оркестрацию часто все еще приходится писать самостоятельно. Сам протокол продолжает развиваться, поэтому необходимо учитывать различия поведения между версиями.
Важно отделять еще одну границу: протокол определяет, как модель вызывает инструменты, но не решает, соответствует ли сама задача правилам. Есть ли разрешение на сбор данных, является ли цель использования аккаунта законной и не нарушаются ли правила платформы — это отдельные оценки, не связанные с тем, насколько гладко работает подключение.
В сценариях с несколькими средами изоляция между ними и согласованная настройка сетевого выхода, часового пояса и языка часто влияют на результат сильнее, чем способ интеграции. На уровне изоляции сред PurpleMark предоставляет интерфейсы создания, запуска и сетевой настройки сред, которые могут вызываться AI-инструментами и координироваться одним клиентом.
Этот материал предназначен только для объяснения технических принципов. Используйте соответствующие протоколы и инструменты в рамках применимого законодательства и правил.
