Первое, что стоит понять про Cursor, - это не редактор с умным автодополнением, а семейство поверхностей вокруг одного агента. Desktop-приложение с Tab и Inline Edit, отдельное окно параллельных агентов, терминальный CLI, изолированные Cloud Agents, автоматический review и программные API - всё это разные среды исполнения, которые делят часть конфигурации, но не делят границы доверия. Пока эта разница не усвоена, поведение продукта кажется капризным: одна и та же команда в двух местах ведёт себя по-разному, и объяснение ищут не в той причине. Причина при этом почти всегда одна и та же: совпадение названий не означает совпадения среды, в которой название исполняется.
Наивная модель понятна и потому живуча: есть Cursor, у него есть функции, и где-то они просто отображаются иначе. Из этой модели растёт ожидание, что настройка, сделанная в редакторе, действует и в облаке, что команда из changelog CLI найдётся в интерфейсе desktop, а разрешение, выданное один раз, распространяется на всё. Интерфейс этому ожиданию помогает: он намеренно сглаживает различия и показывает знакомое окно поверх совершенно разных исполнителей. Каждое из этих ожиданий рано или поздно ломается, и обычно в неудобный момент - когда агент не сделал того, что вы считали разрешённым, или сделал то, что вы считали запрещённым.
Ломается она на простом факте: место выполнения определяет и контекст, и полномочия. Локальный агент видит ваш рабочий каталог, ваш терминал и ваши переменные окружения. Cloud Agent видит свежий клон репозитория в чужом контейнере и ровно те секреты, которые вы туда положили. CLI работает в текущем shell с его правами, а API запускается из вашего кода с ключом, у которого своя квота и своя политика. Одинаковые слова - "агент", "правка", "разрешение" - за этими границами означают разные вещи, потому что за каждым словом стоит своя файловая система, свой набор процессов и своя сетевая политика.
Отсюда рабочий приём, который держит всё остальное: про любую функцию задавать четыре вопроса. Где она исполняется. Какой контекст получает. Какие действия ей разрешены. Как проверить результат. Эти четыре вопроса не философия, а способ не перепутать слой: они сразу показывают, в каком месте искать настройку и какой границей ограничено происходящее. Первый вопрос отвечает за то, чья это машина. Второй - за то, какие файлы вообще попали в поле зрения. Третий - за то, что агент может сделать без вашего участия. Четвёртый - за то, чем вы отличите заявленный результат от фактического.
Полезно один раз свести поверхности в таблицу, чтобы выбирать осознанно, а не по привычке к одному окну. Ниже такая карта: от desktop-IDE до Cloud API. К ней возвращаются, решая, где вести конкретную задачу: точечная правка рядом с кодом - в редакторе; несколько задач с визуальным контролем - в окне агентов; скрипты и CI - в CLI; долгая автономная работа без вашей машины - в облаке; массовые запуски из своего сервиса - через API и SDK.
| Поверхность | Где работает | Для чего выбирать | Главная граница |
|---|---|---|---|
| Cursor IDE | На локальной машине, рядом с редактором и терминалом | Tab, Inline Edit, Agent, быстрый цикл правки и проверки | Workspace Trust, Run Mode, локальный sandbox |
| Agents Window | Локально или в worktree и cloud target | Несколько задач сразу, работа с браузером, общий review | Выбранная цель выполнения и изоляция checkout |
| Cursor CLI | В текущем shell и рабочем каталоге | Терминальный workflow, скрипты, CI, ACP | cli-config.json, allow и deny, sandbox |
| Cloud Agents | В управляемой Cursor или своей VM | Долгие параллельные задачи, PR, computer use, automations | Cloud environment, секреты и отдельная сетевая политика |
| Cloud API и SDK | Из вашего приложения, local или cloud runtime | Своя оркестрация и массовые запуски | API-ключ, параметры runtime, hooks, квоты |
Один случай стоит разобрать целиком. Задача - обновить зависимости и убедиться, что проверки проекта проходят. Где исполнять: обновление тянет сеть и занимает время, а ваша машина для него не нужна, значит облако. Какой контекст: облачному агенту достанется клон репозитория, а не ваша рабочая копия, поэтому незакоммиченные правки и локальный файл окружения до него не доедут - их либо коммитят, либо кладут в окружение отдельно. Что разрешено: ставить пакеты и ходить в сеть - да, трогать чужие ветки и публиковать артефакты - нет. Чем проверить: не пересказом агента, а зелёным прогоном существующих проверок и просмотром diff по файлам. Четыре ответа заняли минуту и определили и поверхность, и границы задачи.
Соседние механизмы полезно различать отдельно, потому что они решают похожую задачу разными средствами. Окно параллельных агентов и Cloud Agents оба дают несколько дорожек работы одновременно, но платят за это по-разному. Окно агентов остаётся на вашей машине: агенты видят локальное состояние, делят ваши ресурсы и требуют вашего внимания, зато результат сразу под рукой и его нечем догонять. Cloud Agents работают в отдельной среде, не занимают ваш процессор и переживают закрытый ноутбук, но взамен ничего не знают о том, что не попало в репозиторий и в конфигурацию облачного окружения. Выбор между ними - это выбор между близостью к вашему состоянию и независимостью от него.
Цена ошибки в выборе поверхности не абстрактная. Запустить долгую миграцию в редакторе - значит занять свою машину и своё внимание на час. Отправить в облако задачу, которой нужны ваши локальные сервисы и незакоммиченные файлы, - значит получить агента, который честно работает не с тем состоянием. А выдать CLI в CI те же права, что и себе за терминалом, - значит открыть секрет всему, что этот job запускает. Поверхность выбирают под задачу, а не по тому, какое окно уже открыто.
Есть и обратная сторона: общего у поверхностей больше, чем кажется. Правила репозитория, AGENTS.md, skills и часть настроек переносятся между ними, и именно это делает возможным переход между окнами без переписывания процесса. Практический вывод - держать переносимым то, что определяет поведение агента, а специфичное для одного клиента не тащить в основу командного процесса. Тогда смена поверхности становится решением по задаче, а не переучиванием команды.
Типичный провал - объяснять поведение не той причиной. Настройка не применилась, потому что она относится к другой поверхности; агент не увидел файл, потому что работает в облачном клоне; команда не нашлась, потому что она есть только в CLI. Признак, по которому это узнают в реальной работе, простой: проблему описывают словами "почему-то не видит" или "почему-то не действует", без указания на слой. Прежде чем искать баг, стоит ответить на четыре вопроса о слое - в большинстве случаев ответ находится там же.