Cursor 3.9 Customize Page: что унифицированный слой управления плагинами, MCP и субагентами означает для операторских команд

Вопрос корпоративного управления инструментами в Cursor наконец получил более чёткий ответ. В версии 3.9 (выпущена 22 июня 2026 г.) Cursor собирает плагины, skills, MCP, субагенты, правила, команды и хуки в единой странице Customize — и предоставляет операторам управление на трёх уровнях: пользователь, команда и рабочее пространство (workspace). Для команд, которые маршрутизируют запросы через общий AI-gateway, это меняет подход к аудиту: какие инструменты доступны агентам, к каким MCP-серверам они могут обратиться, какие поведения субагентов разрешены.

Что изменилось в Cursor 3.9

Главная функция — новая страница Customize, которая объединяет всё, что прежде было разбросано по разным меню. Разработчик или администратор теперь управляет из одного интерфейса:

• Плагинами — пакеты сторонних возможностей
• Skills — повторно используемые поведения агента
• MCP — серверы Model Context Protocol, предоставляющие агентам доступ к внешним инструментам и источникам данных
• Субагентами — именованные дочерние агенты с конкретными ролями
• Правилами, командами и хуками — конфигурация рабочих процессов

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

Marketplace leaderboard показывает самые популярные плагины, skills и MCP внутри команды. Любой элемент добавляется в конфигурацию разработчика одним кликом со страницы Customize из командной библиотеки.

Plugin canvases вводят новую абстракцию — готовые шаблоны совместного использования, которые команда может открывать и переиспользовать: Hex Canvas для визуализации данных и Atlassian Canvas для просмотра задач и проектов в реальном времени.

Командные маркетплейсы теперь поддерживают импорт репозиториев плагинов из GitLab, Bitbucket и Azure DevOps — прежде поддерживался только GitHub. Это критично для предприятий, где внутренний инструментарий хранится на самостоятельно поднятых системах контроля версий.

Почему это важно для AI-инженерных команд

Главный управленческий вывод: политика MCP теперь является полноправной административной концепцией в Cursor, а не личным предпочтением разработчика. До версии 3.9 MCP-сервер, настроенный одним разработчиком, не имел принудительных ограничений относительно командной политики. С трёхуровневым управлением администратор команды определяет, какие MCP-серверы одобрены, а страница Customize отображает, что реально запущено у каждого разработчика.

Для команд, маршрутизирующих запросы агентов через централизованный gateway, появляется новый аудируемый сигнал: к каким инструментам имела доступ данная сессия? Когда облачный агент, запущенный через Automations (добавлены в Cursor 3.8), отправляет вебхук и делает downstream-вызовы API, именно командная конфигурация MCP определяет, к каким внешним сервисам он может обратиться. Этот набор инструментов теперь можно просмотреть с одной страницы.

Поддержка GitLab, Bitbucket и Azure DevOps закрывает корпоративный пробел — команды, работающие не на GitHub, раньше были вынуждены использовать обходные пути для внутренних репозиториев плагинов.

Управление субагентами в 3.9 также стало строже: субагенты управляются вместе с плагинами и MCP на одной странице Customize, а политика относительно их профилей и областей видимости теперь не отделена от остальной конфигурации инструментов.

Угол routing/operator

Для операторов, управляющих командами Cursor через централизованный AI-routing-gateway, три момента требуют внимания:

Инвентаризация MCP-серверов. Страница Customize даёт командный обзор включённых MCP-серверов. Сопоставьте это с вызовами инструментов, проходящими через ваш gateway, чтобы выявить пробелы — MCP-серверы, одобренные в политике Cursor, но чей трафик ещё не учтён в слое маршрутизации или биллинга.

Маршрутизация модели субагента. Поскольку профили субагентов теперь управляются в Customize на уровне рабочего пространства, если эти профили ссылаются на конкретные model endpoints, ваш gateway должен обрабатывать маршрутизацию для этих идентификаторов — особенно важно, когда расход модели субагента должен быть изолирован от бюджета родительского агента.

Аудируемость plugin canvases. Plugin canvases (примеры Hex и Atlassian) — это разделяемое состояние уровня рабочего пространства, которое может читать внешние источники данных. Для регулируемых команд важно понять, какие данные может получить canvas и проходят ли эти запросы через ваш прокси.

Что стоит проверить операторам на TheRouter

Если ваша команда использует Cursor Automations (3.8) и теперь Customize (3.9), слой управления внутри Cursor формирует то, что оператор gateway хотел бы видеть: политики с областями видимости, командная курация и аудируемый список одобренных инструментов.

Практический вопрос для команд, маршрутизирующих через AI-gateway: захватывает ли ваше логирование вызовов инструментов MCP-инициированные запросы от субагентов Cursor? Если нет, расширенные определения областей видимости Cursor 3.9 означают, что инструментальная поверхность ваших агентов только что выросла — и это должно быть видно в вашей модели маршрутизации и стоимости.

Проверьте конфигурацию MCP-логирования gateway и убедитесь, что MCP-серверы на уровне workspace, добавленные через новую страницу Customize в Cursor 3.9, учтены в вашей политике маршрутизации провайдеров. В отличие от предыдущих версий Cursor, где инструментальная конфигурация была фрагментирована по разработчикам, Cursor 3.9 создаёт единый источник истины — и именно он должен быть синхронизирован с вашими правилами gateway.