У меня работает система из нескольких AI-агентов на базе Claude Code. Роутер принимает задачи из Telegram и раздаёт их агентам, каждый в своём топике (подробнее про это

уже писал

). Агенты умеют ходить в браузер через Playwright MCP: открыть сайт, заполнить форму, опубликовать пост, проверить статус. В типичный день параллельно работают 3-5 агентов, каждый со своей задачей.

Пока агент один, всё хорошо. Проблемы начинаются, когда задачи идут параллельно: два агента из разных топиков начинают драться за одну и ту же вкладку. Один открывает Reddit, второй в ту же секунду перебивает её на Wikidata. Агент пишет “открыл страницу”, а на экране совсем не то. При попытке вручную открыть новую вкладку, боты страшно тупят.

Далее в статье попробую разобраться, почему так происходит на уровне Playwright и Chrome DevTools Protocol, что не сработало, и какое решение в итоге оказалось рабочим.

Почему вкладка общая

Базовая схема, с которой я начинал, типовая для headless-агентов:

Один Chrome запущен с --remote-debugging-port=9222 и постоянным профилем (--user-data-dir). В нём уже выполнены логины на нужные сайты.
@playwright/mcp запущен с --cdp-endpoint http://127.0.0.1:9222 и слушает HTTP-порт как MCP-сервер.
Каждый агент (отдельный процесс) подключается к этому MCP.

Ключевой момент: когда @playwright/mcp стартует с cdpEndpoint, он не создаёт свой браузер, а подключается к уже запущенному и работает в его default browser context. Это и даёт логины: контекст один, общий, со всеми куками профиля.

Но за это приходится платить тем, что если запустить несколько MCP-сессий (по одной на агента), то они, работая в одном default-контексте, пытаются использовать одну и ту же активную страницу. Playwright выполняет действия над конкретным объектом Page, но “текущую вкладку” агенты выбирают из общего набора страниц контекста и перехватывают её друг у друга.

Треугольник ограничений

Если попытаться решить это штатными средствами, упираешься в выбор двух пунктов из трёх:

Общий профиль и логины.
Изоляция вкладок между агентами.
Готовый инструмент без своего кода.

Я попробовал оба очевидных варианта.

Отдельный браузер или профиль на агента. Изоляция есть, но логины пропадают. browser.newContext() поверх CDP создаёт incognito-подобный контекст без кук профиля, а отдельный --user-data-dir это просто другой профиль, где ты не залогинен. Для сайтов с 2FA перелогиниваться в каждом контексте нереально.

Один общий контекст и штатный MCP. Логины на месте, но агенты дерутся за вкладку. Это то, с чего я начал.

Чтобы получить одновременно и общий логин, и изоляцию, штатного @playwright/mcp недостаточно. Нужен свой тонкий слой. Хорошая новость: переписывать инструменты не придётся.

Что внутри @playwright/mcp

Прежде чем писать что-то своё, я полез в исходники и выяснилось, что @playwright/mcp@0.0.76 оказался крайне тонкой обёрткой, так как весь его index.js:

const { tools } = require('playwright-core/lib/coreBundle');
module.exports = { createConnection: tools.createConnection };

Вся реализация MCP, включая снимки страницы для модели и систему ссылок на элементы, живёт внутри playwright-core в бандле coreBundle. Наружу торчит одна функция. Её сигнатура (из поставляемого index.d.ts):

import type { Server } from '@modelcontextprotocol/sdk/server/index.js';
import type { BrowserContext } from 'playwright';
import type { Config } from './config';

export declare function createConnection(
  config?: Config,
  contextGetter?: () => Promise<BrowserContext>
): Promise<Server>;

Второй аргумент contextGetter позволяет подсунуть свой BrowserContext. Можно управлять тем, в каком контексте будет работать конкретная MCP-сессия, и при этом переиспользовать все 23 штатных инструмента (browser_navigate, browser_click, browser_snapshot и т.д.).

Два нюанса, на которые я потратил время:

_snapshotForAI() нет в стабильной сборке. То есть в стабильном playwright-core@1.61.0 нет внутреннего метода page._snapshotForAI(), на который ориентируются старые примеры. @playwright/mcp@0.0.76 тянет конкретную alpha-сборку (playwright-core@1.61.0-alpha-...). Если хотите переиспользовать createConnection, ставьте ту же версию, что пинит сам @playwright/mcp, иначе поведение разойдётся.

ariaSnapshot() не даёт [ref=...]. Публичный locator.ariaSnapshot() существует, но не выдаёт ссылки на элементы, на которые опирается клик. Самостоятельно воспроизводить снимок смысла нет. Через createConnection всё работает из коробки.

Решение: свой контекст, общие куки, чужие инструменты

Идея простая. Одно подключение к общему Chrome. На каждого агента свой изолированный контекст (фактически своё окно). Куки профиля переносим в этот контекст, чтобы сохранить логины. Инструменты берём готовые через createConnection.

Минимальный рабочий код (один агент, свой порт):

import http from 'node:http';
import { randomUUID } from 'node:crypto';
import { chromium } from 'playwright-core';
import { createRequire } from 'module';
import { StreamableHTTPServerTransport }
  from '@modelcontextprotocol/sdk/server/streamableHttp.js';

const require = createRequire(import.meta.url);
const { tools } = require('playwright-core/lib/coreBundle');

const CDP = 'http://127.0.0.1:9222';
const CFG = { timeouts: { navigation: 60000, action: 30000 } };

const browser = await chromium.connectOverCDP(CDP);
const defaultCtx = browser.contexts()[0]; // профиль с логинами

async function makeContext() {
  const cookies = await defaultCtx.cookies();
  const ctx = await browser.newContext();
  if (cookies.length) await ctx.addCookies(cookies);
  return ctx;
}
const topicCtx = await makeContext();

const transports = Object.create(null);
const isInit = (b) =>
  b && (Array.isArray(b) ? b.some((m) => m?.method === 'initialize')
                         : b.method === 'initialize');

http.createServer((req, res) => {
  const chunks = [];
  req.on('data', (c) => chunks.push(c));
  req.on('end', async () => {
    const body = chunks.length
      ? JSON.parse(Buffer.concat(chunks).toString('utf8')) : undefined;
    const sid = req.headers['mcp-session-id'];
    let transport = sid ? transports[sid] : undefined;

    if (!transport && !sid && isInit(body)) {
      transport = new StreamableHTTPServerTransport({
        sessionIdGenerator: () => randomUUID(),
        onsessioninitialized: (id) => { transports[id] = transport; },
      });
      transport.onclose = () => { delete transports[transport.sessionId]; };
      const server = await tools.createConnection(CFG, async () => topicCtx);
      await server.connect(transport);
    }
    if (!transport) { res.writeHead(400).end('no session'); return; }
    await transport.handleRequest(req, res, body);
  });
}).listen(8940, '127.0.0.1');

Что это даёт:

Логины общие, потому что куки переносятся из профиля через addCookies. Вкладки изолированы детерминированно: у каждого агента свой BrowserContext, они физически не пересекаются. Все инструменты родные, потому что реализацию даёт createConnection. Ответы приходят в том же формате, что и у штатного @playwright/mcp, включая снимок страницы со ссылками на элементы.

Сквозной тест: два агента на разных портах, первый ушёл на Reddit, второй на Wikipedia. У каждого осталась своя страница, без перехвата.

В моей конфигурации процессы поднимает брокер: на каждый активный Telegram-топик он стартует node server.mjs на отдельном порту из пула, а агенту через конфиг MCP подсовывается соответствующий URL.

Как понять, где чьё окно

Когда окон несколько, непонятно, какое к какому агенту относится. Решается init-скриптом контекста, который проставляет префикс в заголовок:

const prefix = `[${topicName}] `;
await ctx.addInitScript(`(() => {
  const P = ${JSON.stringify(prefix)};
  const apply = () => {
    const base = (document.title || '').replace(/^\\[[^\\]]*\\]\\s*/, '');
    const want = P + base;
    if (document.title !== want) document.title = want;
  };
  apply();
  setInterval(apply, 1000);
})();`);

В заголовке окна и в превью на панели задач видно [Имя агента] Заголовок страницы. setInterval нужен, потому что SPA-приложения (тот же Facebook) постоянно перезаписывают document.title.

Грабли эксплуатации

Вещи, которые в продакшене важнее самой архитектуры.

MCP подключается один раз, в начале сессии. Переподключиться внутри сессии нельзя. Если перезапустить MCP-сервер посреди работы агента, тот получит “MCP server is not connected” и в худшем случае свалится на shell-команды вроде start url, которые откроют ссылку в системном браузере, мимо управляемого. Изменения кода применяйте пересозданием процессов агентов, а не рестартом инфраструктуры.

Зависший navigate копит idle-таймаут. Если страница не догружается (нужен логин, тяжёлый сайт, антибот), вызов browser_navigate висит без событий. Сторожевой таймаут может убить процесс раньше, чем страница ответит. Лечится явными таймаутами в конфиге (timeouts.navigation, timeouts.action) и предварительным логином в профиль до запуска агентов.

Не убивайте активные процессы при сборке мусора. Если у вас пул с переработкой простаивающих по таймеру, проверяйте наличие ESTABLISHED-соединения на порту MCP, иначе закроете окно агента прямо посреди задачи. Я на это потратил вечер отладки.

И еще немного про ограничения

Отдельно пропишу, чтобы не вводить в заблуждение.

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

Контекст изолированный, значит incognito-подобное окно. Куки переносятся, и для уже залогиненных сайтов всё работает. Но сохранённые пароли из профиля для автозаполнения недоступны. Впрочем, это решается тем, что ты авторизуешь агенту только нужные сайты один раз вручную, а затем пользуешься как обычно.

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

Решение опирается на внутренний путь playwright-core/lib/coreBundle и конкретную версию playwright-core. Это не публичный API. При обновлении @playwright/mcp проверяйте, что путь и сигнатура createConnection на месте.

Вместо выводов

Половина работы с автономными агентами это не промпты и не выбор модели, а скучная инженерия вокруг браузера: кто в какой вкладке, чьи это куки, видно ли оператору, что происходит. Для нескольких агентов в одном Chrome рабочая схема получилась такой: одно подключение по CDP, свой изолированный контекст на агента с перенесёнными куками, createConnection из playwright-core ради штатных инструментов и подпись окон именем агента для наглядности.

Изоляция детерминированная, логины на месте, оператор видит каждое окно. У меня эта схема работает несколько недель с 3-5 параллельными агентами. Пока ни одного случая перехвата вкладки (не то, то вначале насмотревшись рилсов про волшебство playwright mcp, удивлялся, что ж это в нескольких топиках написал проверить формы на сайте и протестировать что-то, а оно ни в одном не сработало, как оказалось из-за того, что все агенты одну и ту же вкладку насиловали).

Frontender`s Spectre

[PurpleSchool | Anton Larichev] Orca — полный разбор бесплатной IDE для AI-агентов

Несколько LLM-агентов в одном Chrome: изоляция вкладок без потери логинов