Execution and approvals в Cursor: как настроить

Cursor Agent mode — автономный режим в панели агента: модель читает кодовую базу, редактирует файлы, запускает терминал и итерирует до результата. Это не «чат с подсказками» — правки применяются по ходу сессии, и вы смотрите diff в реальном времени. В официальной таблице Cursor (2026) в одной панели живут четыре режима ввода: Agent, Ask, Plan и Debug — переключение Shift+Tab в поле ввода агента.

Люди ищут «cursor agent», «cursor агенты», «cursor agent mode» с одной целью: как делегировать работу агенту и не разнести проект. Устаревшие гайды 2024–25 иногда называют эту панель Composer; в актуальной справке Cursor это Agent panel и режимы Agent / Ask / Plan / Debug. Composer я упоминаю только как устаревающий синоним панели Ctrl+I, чтобы не путать с формулировками из старых обзоров.

Когда Agent mode уместен, а когда достаточно Ask

Agent уместен, когда вы готовы к правкам в файлах и есть способ проверить результат (тесты, линтер, build из Rules). Ask — когда нужно только прочитать: «объясни этот модуль», «где в проекте валидируется форма» — без риска случайного diff. На разборе типичная ошибка: человек открывает Agent с промптом «расскажи, как тут всё связано» — агент начинает «улучшать» код. Для разведки — Ask; для правок — Agent с узким scope.

Plan — промежуточный вариант: сначала план и согласование подхода, потом правки. Я рекомендую Plan, если репозиторий новый и задача затрагивает несколько модулей: меньше шанс, что агент разнесёт структуру одним промптом «сделай как в проде».

Debug тоже пишет файлы — не смешайте его с «безопасным workflow». Это отдельный режим для отладки, не замена дисциплины diff + тестов в Agent.

Переключиться в Agent mode: откройте панель агента Ctrl+I (Windows/Linux) или Cmd+I (macOS). В поле ввода Shift+Tab циклично меняет режимы Agent / Ask / Plan / Debug; в dropdown у поля ввода тот же выбор. Панель агентов (cursor agents window в поисковых запросах) — это та же боковая Agent panel, не отдельный продукт.

Где в интерфейсе переключатель режимов

Переключатель сидит в поле ввода Agent panel: иконка или подпись режима слева или над текстовым полем, плюс Shift+Tab. Если после обновления Cursor не видите Plan — проверьте версию редактора и справку: Plan и Debug появились в актуальной линейке режимов. Editor и Agent panel — разные вещи: editor — вкладка кода, Agent — панель Ctrl+I / Cmd+I.

Agent window и очередь задач

В Agent panel можно ставить сообщения в очередь, пока агент работает — удобно для уточнений, но не для «накидать пять больших задач». Я держу одну активную задачу на сессию: очередь — для «не трогай package.json» или «остановись после тестов», а не для параллельных фич.

Checkpoints — локальные снимки файлов в сессии Agent; Restore Checkpoint откатывает правки внутри сессии. Это не замена Git: checkpoint = быстрый undo, Git = постоянный контроль версий. Перед крупным рефакторингом я прошу агента создать checkpoint или сам коммичу чистое состояние — так откат не зависит только от UI.

Безопасный workflow в Agent mode — не «надеяться на модель», а цепочка: узкая задача → diff в реальном времени → свои тесты/линт → commit после ревью. Cursor советует быть конкретным в промпте; на практике я добавляю критерии готовности и явный список файлов, которые можно трогать.

Как сформулировать ограниченную задачу и критерии готовности

Формула, которую я даю на наставничестве — четыре блока в одном сообщении:

1. 01

   Что — одна цель («добавить типы в formatDate», не «улучши проект»).

2. 02

   Где — путь или glob (src/utils/date.ts, только этот файл).

3. 03

   Как проверить — команда из Rules (npm test -- formatDate, npm run lint).

4. 04

   Что не трогать — package.json, конфиги, другие модули.

Пример промпта, который я разбираю с учеником:

В src/utils/date.ts добавь явные типы для formatDate и parseUserDate.
Не меняй другие файлы. Критерий готовности: npm test -- date.test.ts зелёный
и npm run lint без ошибок в src/utils/date.ts.
Не трогай package.json и lockfile.

После такого промпта агент ищет по кодовой базе, правит файл, может запустить тесты — в зависимости от Run Mode. Я не ухожу из сессии, пока идут правки: смотрю diff, при уходе в сторону — Stop.

Walkthrough на разборе: ученик с Vitest в Rules, файл src/utils/date.ts без типов на публичных функциях. Agent правит ~15 строк, в diff видно только date.ts и новые тесты в date.test.ts — если агент лезет в package.json, Stop и уточнение scope. Я прогоняю npm test -- date.test.ts сам в терминале, не полагаюсь только на вывод агента «тесты прошли». Diff читаю целиком: иногда агент добавляет any или отключает eslint-disable. Commit — когда я понимаю каждую строку.

Чек-лист перед Apply (и после правок)

Ниже — мой чек-лист из 12 пунктов (не официальная политика Cursor). Он совпадает с документацией и с тем, что я прошу на разборе.

До задачи

1. 01

   В проекте есть Cursor Rules с командами проверки и запретами.

2. 02

   Run Mode = Auto-review (не Run Everything).

3. 03

   Секреты не в чате; чувствительные пути в ignore.

4. 04

   Задача узкая: что / где / как проверить / что не трогать.

5. 05

   Для незнакомой области — Ask или Plan, потом Agent.

Во время

1. 01

   Следить за diff; Stop при уходе в сторону.

2. 02

   Одобрять shell/MCP осознанно; не игнорировать prompt classifier block.

3. 03

   Checkpoints перед крупным рефакторингом.

После

1. 01

   Прогнать свои тесты/линтер (команда из Rules).

2. 02

   Прочитать diff целиком; не merge «потому что зелёный один тест».

3. 03

   Git commit только когда понимаю каждое изменение.

4. 04

   Для облака/PR — отдельное ревью (Bugbot опционально).

В «зелёную зону» я отношу задачи, где область маленькая, есть тесты и Rules, а откат — дешёвый. По документации Cursor Agent как раз для feature work, refactor, bugfix и tests; матрица ниже — как я сам делю задачи после базовой настройки и Rules.

Запрос «ии агент cursor» и «cursor ai coding agent» часто ведут сюда: люди хотят «локального ии агента для программирования в cursor» — по факту это Agent mode на вашем workspace с вашими Rules, не отдельный сервис. Локальный агент читает ваш диск (с учётом ignore) и выполняет команды в терминале по Run Mode — не магия «автономного разработчика».

«Жёлтая зона» — задачи, где агент может сделать технически правильное, но опасное для проекта. Я поручаю, но diff + CI + второй проход глазами обязательны.

Обновление зависимостей — классический кейс на разборе: агент обновил vite и lockfile, unit-тесты зелёные, но e2e падает на плагине. Без npm audit и smoke я не коммичу. Для major — только с бэкапом ветки и явной задачей в Plan, не одним промптом в Agent.

«Красная зона» — задачи, где цена ошибки выше выгоды автоматизации. Агент может ошибиться даже с Rules; Run Modes не дают 100% safety boundary.

На разборе иногда присылают промпт «удали всё ненужное в src/» — даже с File-Deletion Protection я не даю такие задачи. Scope списком файлов или папкой с тестами.

Продакшен: можно ли доверять агенту прод? Мой ответ — нет как автономному исполнителю. Agent может подготовить diff в ветке; выкат, миграции, флаги — только человек по runbook. Cloud Agents тоже не «безопаснее» по умолчанию — там другой контур риска (ветка/PR), не нулевой.

Run Modes — отдельная ось от Agent / Ask / Plan / Debug. Они регулируют, сколько автономии у shell, MCP и Fetch: Auto-review, Allowlist, Run Everything. Настройка: Settings → Agents → Approvals & Execution. «Agent mode» ≠ «Run Everything»: можно быть в Agent с жёстким Auto-review.

Цепочка Auto-review для shell/MCP/Fetch: совпало с allowlist → выполняется; иначе shell → sandbox с ограничениями FS/сети; не sandboxится → classifier (allow / другой путь / approval prompt). Критичная оговорка из docs: Auto-review is not a security boundary — классификатор недетерминирован; для строгого контроля — Allowlist и ручные approve.

Дополнительные защиты (могут требовать approve даже при мягком Run Mode): Browser Protection, File-Deletion Protection (включая rm), External-File Protection (файлы вне workspace). Конфигурация: ~/.cursor/permissions.json, /.cursor/permissions.json с autoRun.allow_instructions / block_instructions; sandbox.json для сети и путей.

С Cursor 3.5 (22.05.2026) режим Ask Every Time deprecated; Run in Sandbox переименован в связку Allowlist + sandbox. Не описывайте Ask Every Time как текущий default — для новых установок рекомендован Auto-review.

CLI (для продвинутых): в headless approvalMode allowlist | unrestricted — без IDE classifier; риск выше. На первом занятии не трогаем.

Cursor Rules снижают риск, потому что подмешивают стек, команды lint/test/build и запреты в каждый режим панели — Agent, Ask, Plan, Debug. Project Rules в .cursor/rules/*.mdc, User/Team Rules, AGENTS.md — всё это вероятностическое руководство, не детерминированный gate. Rules сужают поведение агента, но не заменяют diff и тесты человеком.

Три слоя, которые я проговариваю на разборе:

1. 01

   Rules — что агент должен помнить (стек, команды, запреты).

2. 02

   Diff — что агент реально изменил в файлах.

3. 03

   Свои тесты/линт — прошёл ли проект ваши критерии, не только вывод агента.

Подробная настройка — в материале Cursor Rules: alwaysApply, globs, чек-лист «правило молчит». Запросы «cursor agents md» ведут к AGENTS.md и .cursor/agents/ — это следующий уровень после базовых project rules.

Минимальный набор rules перед первой «боевой» задаче агенту

Перед первой задаче в Agent я проверяю, что в overview.mdc есть:

• стек и версии (Node, TS, тест-раннер);
• одна строка команд проверки, которая реально работает в терминале;
• запрет секретов и массового удаления;
• «не менять lockfile без задачи»;
• язык ответов, если чат на русском.

Без этого Agent «угадывает» Jest вместо Vitest и выдумывает yarn test. Rules не гарантируют соблюдение — но без них разброс выше.

Локальный Agent mode и Cloud Agents — разные контуры. Cloud Agents (cursor.com/agents) работают на выделённой машине в облаке и не используют Run Modes IDE — нет той же цепочки approve на каждое действие. Ревью там через ветку и PR, не через локальный diff в реальном времени.

Background agents и Cursor Agent CLI — смежные темы: фоновая работа и headless-режим. В этой статье их не разбираю пошагово. Граница простая: облако само по себе не «безопаснее» — там другой workflow ревью.

Subagents — делегирование подзадач в отдельное контекстное окно; кастомные в .cursor/agents/*.md, есть readonly: true. Следующий уровень после одиночного Agent; не снимает ревью артефактов.

MCP расширяет агента внешними инструментами (репозиторий, браузер, CMS, Telegram). Это отдельная большая тема — здесь только граница ответственности. MCP не снимает ручной ревью: агент может отправить сообщение, создать пост или дернуть webhook с персональными данными и токенами. Для подключений держите staging/dev, проверяйте содержимое и не публикуйте в прод без человека.

В обзорах иногда обещают «автоворонку лидов в Cursor: правила и два субагента за вечер». Идея субагентов после Rules и MCP в CRM полезная, но я не обещаю лиды за вечер и не копирую чужие призывы. Subagents в Cursor есть — они изолируют контекст, не снимают ответственность. Прототип автоматизации в отдельной папке репозитория — только с проверкой каждого артефакта; прод без ревью остаётся красной зоной.

Что читать дальше

• Промпты для Cursor — как формулировать задачи агенту.
• Что такое вайбкодинг — границы цикла intent → patch → verify.
• Обучение Cursor — регулярная практика на вашем стеке.

Если после Rules и этого чек-листа всё ещё неясно, что поручить Agent на вашем репозитории — на наставничестве разбираем конкретную задачу: формулируем промпт, смотрим diff вместе, фиксируем критерии готовности.

Что прислать в Telegram:

• ссылку на репо или описание стека;
• одну задачу, которую боитесь дать агенту;
• есть ли .cursor/rules и какие команды тестов реально работают.

По теме в блоге

Как пользоваться Cursor AI и Cursor Rules. Если Agent mode уже в работе — следующий шаг: промпты для Cursor. Про подход к разработке с ИИ — вайбкодинг.

Автор: Пашкуров Пётр Сергеевич. Источники: документация Agent, Rules, модели и pricing.