Start Debugging

Cursor 3.4 добавляет мультирепозиторные окружения и ускоряет сборки Dockerfile для облачных агентов

Cursor 3.4 (13 мая 2026) позволяет одному окружению облачного агента включать несколько репозиториев, добавляет секреты сборки для Dockerfile, пересборки с кэшем слоёв на 70% быстрее и шаг настройки под управлением агента, который проверяет учётные данные до первого запуска.

13 мая 2026 года Cursor выпустил версию 3.4, и этот релиз в основном про инфраструктуру, которая нужна флотам облачных агентов, чтобы реально работать. Главная новость — мультирепозиторные окружения, но именно изменения с секретами сборки и кэшированием слоёв под капотом делают параллельный запуск множества агентов достаточно дешёвым, чтобы это было применимо на практике. Это прямое продолжение работы над параллелизмом в Cursor 3.3, ориентированное на команды, которые уже разделяют задачи между субагентами и упирались в стену “один репозиторий на окружение”.

Одно окружение, много репозиториев

До 3.4 окружение облачного агента было ограничено одним репозиторием. Это ломалось в тот момент, когда задача пересекала границы: backend API плюс пакет общих типов, приложение Flutter плюс сервер на Dart или решение .NET плюс соседний инфраструктурный репозиторий. Либо вы клонировали дополнительные репозитории вручную в скрипте настройки (медленно и хрупко), либо делили задачу и теряли контекст между репозиториями.

Cursor 3.4 переиспользует механику multi-root workspaces и позволяет перечислить каждый репозиторий, который нужен агенту, как часть определения окружения. Типичная конфигурация выглядит так:

{
  "name": "api-and-shared-types",
  "repositories": [
    { "url": "github.com/acme/api", "branch": "main" },
    { "url": "github.com/acme/shared-types", "branch": "main" }
  ],
  "dockerfile": "./infra/agent.Dockerfile"
}

Оба репозитория клонируются в одно и то же окружение, и агент видит их как единый workspace. Сессии переиспользуют окружение, поэтому запуск нового агента на той же паре — это попадание в кэш, а не свежий клон.

Секреты сборки и попадания в кэш на 70% быстрее

Путь через Dockerfile также получил два практичных исправления. Первое — --mount=type=secret для секретов сборки, которые остаются за пределами работающего контейнера:

# syntax=docker/dockerfile:1.7
FROM mcr.microsoft.com/dotnet/sdk:9.0
RUN --mount=type=secret,id=nuget_pat \
    dotnet nuget add source https://nuget.pkg.github.com/acme/index.json \
      --name acme --username ci \
      --password "$(cat /run/secrets/nuget_pat)" --store-password-in-clear-text
COPY . /src
WORKDIR /src
RUN dotnet restore

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

Второе исправление — кэширование слоёв. Сборки, попадающие в кэш, по заметкам релиза идут на 70% быстрее, потому что при правке Dockerfile пересобираются только изменённые слои. На практике это означает, что итерации по строке RUN apt-get install ... больше не инвалидируют длинный dotnet restore ниже, при условии что слой restore находится выше места изменения.

Настройка под управлением агента ловит отсутствующие учётные данные до запуска

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

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

Полный changelog Cursor содержит остальное по 3.4.

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Назад