Cursor Cloud Agents: что отдать агенту, а что оставить платформе (Рубрика #AI4SDLC)
Прочитал июньский разбор Джоша Ма из Cursor о годе работы над облачными агентами. Зацепил не рост автономности, а смена архитектурной границы: процедурная логика переезжает из обвязки агента (harness) в управляемые им инструменты. Сложность не исчезает, а нарастает вокруг среды, надёжности, политик и состояния. И облачный агент здесь — уже не цикл в одной VM, а система из рабочего процесса, среды, журнала событий, инструментов и подагентов.
1️⃣ Первый сдвиг — среда стала частью качества агента. Локально он наследует репозитории, зависимости, сборку, тесты, настройки и доступы с ноутбука разработчика. В облаке всё это нужно восстановить явно. По наблюдениям Cursor, неполная среда может не падать с ошибкой: агент просто работает хуже, а деградацию списывают на модель.
Я бы развёл две роли. Песочница (sandbox) ограничивает действия, а рабочая среда агента (development environment) содержит всё нужное для цикла «изменил → запустил → проверил». Изолированная VM без зависимостей, тестов, API и управляемой сети может быть безопасной, но бесполезной.
Поэтому Cursor строит возобновляемое рабочее место: VM можно усыплять и возобновлять, образы — сохранять, восстанавливать и разветвлять, а сеть и учётные данные контролировать отдельно. В соседнем материале компания описывает среду как код: Dockerfile, историю версий и откат, аудит, правила исходящего доступа и работы с секретами. Это уже платформенная инженерия для агентов.
2️⃣ Второй сдвиг — harness перестаёт диктовать маршрут. Раньше он перепроверял результат, принудительно делал commit и push, а в CI Autofix ещё и забирал логи. Теперь агент получает GitHub CLI, инструменты для веток и PR, карту репозиториев и доступные для поиска файлы с большими выводами — и сам выбирает процедуру 🤖.
Детерминированный слой остаётся. Я бы провёл границу так: агент выбирает инструменты, их порядок и момент проверки; платформа удерживает границы прав и сети, выдачу секретов, восстановление, аудит и защиту от дублей при повторе внешних действий. Обвязка перестаёт быть сценаристом: она даёт возможности, а гарантии распределяются между оркестрацией исполнения и управлением средой.
3️⃣ Третий сдвиг — «один агент» декомпозируется по времени жизни и владельцу состояния. Agent loop живёт в Temporal, жизненный цикл VM управляется отдельно, а хранение и поток разговора вынесены в свой слой. При повторе шага клиент перематывает отображаемый поток; асинхронный подагент может работать на другом pod и пережить родителя.
Сам рабочий процесс тоже разрезали: вместо «вечного» — несколько коротких, каждый завершается одной задачей; отдельные операции получают свои тайм-ауты и повторные попытки.
Для работы с интерфейсом (computer use) у Cursor пока остаётся отдельный подагент со своей маршрутизацией моделей, инструкциями и записью экрана. VNC и Chrome находятся в общей среде, а родитель решает, когда его подключить. Зрелую способность можно отдать агенту как инструмент, слабую пока удерживает дополнительная обвязка.
Практически для платформенной команды отсюда следуют три решения:
1) Версионировать описание среды: образ, зависимости, проверки готовности, сетевые правила и правила выдачи секретов; сами секреты хранить и ротировать отдельно;
2) Выдавать возможности через инструменты, но держать безопасность, надёжность и аудит вне вероятностного плана модели;
3) Разделять цикл агента, машину, разговор и подагентов по владельцу состояния, времени жизни, лимиту времени и правилам повторного запуска.
Для меня главный вывод такой: перенос логики из harness в сторону модели — не упрощение, а смена контракта. Границу нужно двигать отдельно для каждой способности и только после проверок качества (evals).
#AI #AI4SDLC #Agents #Architecture #PlatformEngineering #Engineering
Прочитал июньский разбор Джоша Ма из Cursor о годе работы над облачными агентами. Зацепил не рост автономности, а смена архитектурной границы: процедурная логика переезжает из обвязки агента (harness) в управляемые им инструменты. Сложность не исчезает, а нарастает вокруг среды, надёжности, политик и состояния. И облачный агент здесь — уже не цикл в одной VM, а система из рабочего процесса, среды, журнала событий, инструментов и подагентов.
1️⃣ Первый сдвиг — среда стала частью качества агента. Локально он наследует репозитории, зависимости, сборку, тесты, настройки и доступы с ноутбука разработчика. В облаке всё это нужно восстановить явно. По наблюдениям Cursor, неполная среда может не падать с ошибкой: агент просто работает хуже, а деградацию списывают на модель.
Я бы развёл две роли. Песочница (sandbox) ограничивает действия, а рабочая среда агента (development environment) содержит всё нужное для цикла «изменил → запустил → проверил». Изолированная VM без зависимостей, тестов, API и управляемой сети может быть безопасной, но бесполезной.
Поэтому Cursor строит возобновляемое рабочее место: VM можно усыплять и возобновлять, образы — сохранять, восстанавливать и разветвлять, а сеть и учётные данные контролировать отдельно. В соседнем материале компания описывает среду как код: Dockerfile, историю версий и откат, аудит, правила исходящего доступа и работы с секретами. Это уже платформенная инженерия для агентов.
2️⃣ Второй сдвиг — harness перестаёт диктовать маршрут. Раньше он перепроверял результат, принудительно делал commit и push, а в CI Autofix ещё и забирал логи. Теперь агент получает GitHub CLI, инструменты для веток и PR, карту репозиториев и доступные для поиска файлы с большими выводами — и сам выбирает процедуру 🤖.
Детерминированный слой остаётся. Я бы провёл границу так: агент выбирает инструменты, их порядок и момент проверки; платформа удерживает границы прав и сети, выдачу секретов, восстановление, аудит и защиту от дублей при повторе внешних действий. Обвязка перестаёт быть сценаристом: она даёт возможности, а гарантии распределяются между оркестрацией исполнения и управлением средой.
3️⃣ Третий сдвиг — «один агент» декомпозируется по времени жизни и владельцу состояния. Agent loop живёт в Temporal, жизненный цикл VM управляется отдельно, а хранение и поток разговора вынесены в свой слой. При повторе шага клиент перематывает отображаемый поток; асинхронный подагент может работать на другом pod и пережить родителя.
Сам рабочий процесс тоже разрезали: вместо «вечного» — несколько коротких, каждый завершается одной задачей; отдельные операции получают свои тайм-ауты и повторные попытки.
Для работы с интерфейсом (computer use) у Cursor пока остаётся отдельный подагент со своей маршрутизацией моделей, инструкциями и записью экрана. VNC и Chrome находятся в общей среде, а родитель решает, когда его подключить. Зрелую способность можно отдать агенту как инструмент, слабую пока удерживает дополнительная обвязка.
Практически для платформенной команды отсюда следуют три решения:
1) Версионировать описание среды: образ, зависимости, проверки готовности, сетевые правила и правила выдачи секретов; сами секреты хранить и ротировать отдельно;
2) Выдавать возможности через инструменты, но держать безопасность, надёжность и аудит вне вероятностного плана модели;
3) Разделять цикл агента, машину, разговор и подагентов по владельцу состояния, времени жизни, лимиту времени и правилам повторного запуска.
Для меня главный вывод такой: перенос логики из harness в сторону модели — не упрощение, а смена контракта. Границу нужно двигать отдельно для каждой способности и только после проверок качества (evals).
Чем умнее агент, тем меньше платформа диктует ему шаги — и тем лучше управляет средой, границами и последствиями.
#AI #AI4SDLC #Agents #Architecture #PlatformEngineering #Engineering