almdev Технический блог

Cursor CLI получил Plan, Ask и передачу задач Cloud Agent
Почему разделение исследования, планирования и выполнения важнее ещё одной команды в терминале.

Cursor добавил в CLI режимы Ask и Plan, а также передачу разговора Cloud Agent. Разбираю, как из отдельных промптов складывается управляемый инженерный workflow.

Подкатегория: Coding agents

Чтение
4 мин
Технологии / версии
Cursor · Cursor CLI · Coding agents · Agentic development
17 янв 2026 · 4 мин · AI
Четыре модуля процесса Cursor CLI: исследование, план, выполнение и передача в облако
Coding agents 01/2026

Что вышло 16 января

16 января 2026 года Cursor добавил в CLI три связанные возможности: режимы Ask и Plan, а также передачу текущего разговора в Cloud Agent. Команды и поведение описаны в официальном changelog Cursor.

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

ASK → PLAN → AGENT → VERIFY
                 ↘ CLOUD AGENT → RESULT

Мне здесь интересны не новые slash-команды сами по себе, а явные границы между этапами. Когда исследование, решение и правка кода разделены, ошибку проще заметить до того, как она разрастётся в большой diff.

Ask mode: исследование без правки файлов

Ask включается командой /ask или флагом --mode=ask. В этом режиме агент исследует кодовую базу и отвечает на вопросы, но не меняет проект.

Это удобный первый проход по незнакомому участку: найти реализацию авторизации, проследить зависимости сервиса, собрать связанные маршруты, тесты и конфигурацию. Запрос «добавь rate limiting» пока рано отдавать на реализацию. Сначала полезнее спросить:

Покажи, как запрос проходит от API-маршрута через authentication middleware до контроллера. Где используются Redis и общий формат ошибок? Файлы не меняй.

Ответ Ask — не архитектурная истина. Его всё равно нужно сверять с найденными файлами и фактическим flow. Но режим убирает неприятную неопределённость: агент не начнёт вносить правки, пока от него ждут карту системы.

Plan mode: контроль до появления diff

Plan запускается через /plan, --plan или --mode=plan. Cursor может задать уточняющие вопросы и оформить предполагаемый путь реализации до изменения файлов.

Раньше основная точка контроля находилась после генерации: разработчик открывал diff и пытался понять, почему агент выбрал новый middleware, затронул конфигурацию и переписал тесты. С планом первый review происходит раньше: выбранные границы задачи проверяются ещё до кода.

Для rate limiting хороший план должен назвать точку подключения, ключ лимита, зависимость от Redis, формат ответа 429, исключения для доверенных запросов и тесты. Если вместо этого получился список «создать middleware — подключить — проверить», решение ещё не продумано.

Cloud Agent handoff: продолжение разговора вне терминала

Для передачи задачи в Cloud Agent нужно поставить & в начале сообщения. Текущий разговор отправляется облачному агенту, а продолжить его можно через web или мобильный интерфейс Cursor.

& реализуй согласованный план, запусти тесты и верни результат

Здесь важна точность формулировки: речь идёт о handoff разговора, а не о магическом переносе локального терминального процесса. Перед отправкой стоит явно назвать ожидаемый результат, проверки и ограничения. Иначе в облако уедет контекст обсуждения, но не критерии готовности.

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

CLI становится пультом жизненного цикла задачи

Ранние AI-инструменты в терминале выглядели как короткая цепочка: prompt → model → answer. Теперь в одном интерфейсе появляются разные режимы с разными правами и ожидаемыми артефактами.

Ask     — карта кода и зависимостей
Plan    — решение и последовательность правок
Agent   — изменение файлов и запуск команд
Cloud   — удалённое продолжение согласованной работы
Verify  — тесты, diff и проверка результата

Это уже не выбор «какую модель вызвать». Разработчик управляет переходами между этапами и решает, когда агент получил достаточно контекста для следующего уровня доступа.

Как это выглядит на задаче из Laravel

Возьмём API на Laravel, где нужно ограничить частоту запросов. Немедленная просьба написать middleware заставляет агента одновременно угадывать устройство маршрутов, способ авторизации, доступность Redis и формат ошибок.

Я бы провёл такую задачу четырьмя короткими этапами:

  1. Ask: найти API-маршруты, middleware-группы, настройку Redis, обработчик исключений и существующие feature-тесты.
  2. Plan: выбрать между встроенным RateLimiter Laravel и отдельным middleware, определить ключ пользователя и поведение при недоступном Redis.
  3. Agent: реализовать согласованный вариант без побочного рефакторинга соседней авторизации.
  4. Verify: проверить обычный запрос, ответ 429, раздельные лимиты пользователей и поведение за reverse proxy.

Технология может быть другой — Symfony, CodeIgniter, Bitrix или старый PHP без фреймворка. Ценность даёт не стек, а последовательность: сначала восстановить факты, затем принять решение и лишь после этого разрешить агенту менять проект.

Контроль поднимается от строки к процессу

В autocomplete разработчик подтверждает почти каждую строку. В agentic development единицей управления становится задача: её границы, план, разрешённые инструменты и критерии приёмки.

Это не означает, что контроля становится меньше. Он просто смещается. Вместо проверки каждого нажатия клавиши приходится точнее формулировать инварианты: какие файлы нельзя трогать, какие тесты обязательны, что считать завершением и где нужен человеческий review.

Plan и Ask хорошо проявляют этот сдвиг. Фраза «напиши класс» уступает запросу «восстанови текущий flow, сравни варианты и подготовь решение». Код остаётся важным результатом, но перестаёт быть первым артефактом задачи.

Следующий этап — workflow вместо большого промпта

Попытка упаковать исследование, проектирование, реализацию и проверку в один идеальный промпт плохо масштабируется. Чем больше контекст, тем труднее заметить, на каком допущении агент свернул не туда.

Последовательность Ask → Plan → Agent → Verify делает промежуточные решения видимыми. Cloud handoff добавляет к ней ещё один выбор: где продолжать выполнение. Маленькой правке такой церемониал не нужен, но для архитектурной задачи это уже нормальная инженерная дисциплина, а не лишний слой общения с AI.

Поэтому главное в январском обновлении Cursor CLI — не три новые возможности. В терминале появился каркас процесса, где понимание системы, решение и исполнение больше не обязаны происходить в одном непрозрачном шаге.

#cursor #cursor-cli #coding-agents #agentic-development