У світі інструментів для розробників поширилася нова звичка: залишити завдання десь — в Issue, згадці в чаті чи полі для промпту, — закрити ноутбук і повернутися до гілки або pull request, створених агентом, поки вас не було. GitHub, Cursor, OpenAI, Anthropic, Cognition і xAI уже пропонують власні версії такого рішення під назвами на кшталт «хмарний агент», «фоновий агент», «хмарна сесія» або «автономний інженер-програміст». У цій статті ми розглянемо цю категорію: що насправді роблять ці продукти, як працює цикл, від чого доводиться відмовитися та яке місце в ньому посідає прототип DeepSeek Super-agent із відкритим кодом.
Що вважають хмарним агентом для програмування
Цей термін має нечітке значення, тож варто назвати три спільні риси всіх продуктів цієї категорії:
- Запуск без відкритого редактора. Завдання надходить як призначений Issue, згадка через @ у Slack або Feishu, промпт у вебзастосунку, виклик API чи передача через CLI.
- Середовище поза вашим комп’ютером. Агент клонує репозиторій, встановлює потрібні компоненти й працює в ізольованому середовищі або робочому просторі, яким керує постачальник чи ваша організація.
- Результат, який можна перевірити. Наприкінці агент надає гілку, diff, чернетку PR або коментар — щось, що людина може перевірити й використати.
Це відрізняє таку категорію від двох суміжних. Локальний агент в IDE працює на вашому ноутбуці, поки ви спостерігаєте; чат-асистент відповідає на запитання, не торкаючись репозиторію. Хмарний агент для програмування розташований між ними: він має реальні інструменти й локальну копію репозиторію, але людина має змогу відійти.
Словом бот описують чат-орієнтований формат тієї самої ідеї. Замість того щоб призначати Issue, ви згадуєте агента в Slack, Teams або Feishu. Змінюється спосіб запуску, але не віддалене середовище. Результатом може бути PR, diff або набір готових файлів.
Огляд продуктів
Шість продуктів в описах їхніх постачальників:
| Продукт | Запускається з | Працює в | Повертає |
|---|---|---|---|
| GitHub Copilot cloud agent | Issue, @, панель Agents | Хмарне ізольоване середовище або Actions | Гілка або PR |
| Cursor Cloud Agents | Настільний застосунок, веб, Slack, Linear | Ізольована хмарна віртуальна машина | PR |
| OpenAI Codex Cloud | Вебзастосунок ChatGPT, настільний і мобільний застосунки | Хмарний робочий простір | Зміни або PR |
| Claude Code cloud sessions | Браузер, мобільний і настільний застосунки, термінал | Віртуальна машина під керуванням Anthropic або самостійно розгорнуте середовище | Гілка або PR |
| Devin | Slack, Teams, веб, CLI, API | Робочий простір із терміналом, редактором і браузером | Чернетка PR |
| Grok Bot | Чат у настільному або мобільному застосунку, @bot у X | Хмарна машина (розміщена на Cursor) | Файли або чернетки |
Grok Bot — найширше поняття в цьому переліку: xAI описує його як постійного ШІ-напарника, якого можна запустити з чату в настільному чи мобільному застосунку або згадати через @bot у X, якщо облікові записи пов’язані. Він працює на хмарній машині рівня облікового запису, розміщеній на Cursor, і має доступ до браузера, сховища та командного рядка. У документації йдеться про готові файли й чернетки, а не про роботу з репозиторієм; створення гілок і PR не описано. Тож цей продукт ближчий до ботів на спектрі таких рішень.
Є чотири відмінності, важливіші за таблицю:
Де запускається агент. GitHub Copilot cloud agent і OpenAI Codex Cloud розраховані на роботу, яка вже ведеться в GitHub або застосунку ChatGPT. Cursor Cloud Agents і Devin тяжіють до чат-орієнтованого формату: точкою входу є обговорення в Slack або Teams. Claude Code cloud sessions можна запускати з браузера, телефона, настільного застосунку або командою claude --cloud у терміналі, а також за розкладом.
Наскільки детально постачальник описує середовище. Claude Code докладно описує ізоляцію: у середовищах під керуванням Anthropic кожна сесія працює в ізольованій віртуальній машині, мережевий доступ за замовчуванням обмежений, а облікові дані git зберігаються поза ізольованим середовищем; проксі автентифікується від імені сесії. Організації можуть натомість спрямовувати сесії у власне середовище, за ізоляцію якого вони відповідають самі. Хмарні сесії підпадають під обмеження швидкості вашого тарифного плану, окремої плати за віртуальну машину немає; для них потрібен вхід в обліковий запис claude.ai, і вони недоступні, якщо Claude Code налаштовано для Amazon Bedrock, Agent Platform від Google Cloud чи іншого стороннього провайдера. Інші постачальники розповідають про внутрішню будову менше: «ізольоване середовище» або «віртуальна машина» часто є межею публічного опису.
До чого агенту дозволено звертатися. Деякі продукти обмежено одним репозиторієм, інші заявляють про роботу на рівні всієї організації або з кількома репозиторіями. Саме це слід насамперед звірити з вашими налаштуваннями: спроможний агент із невідповідним набором доступних репозиторіїв буде або марним, або небезпечним.
Для яких завдань призначено продукт. Більшість рішень у цьому переліку призначені для роботи з кодом у межах репозиторію. Grok Bot — універсальний хмарний напарник: у документації йдеться про файли й чернетки, а не про роботу з репозиторієм. Сприймайте «хмарного агента» як спектр рішень, а не єдиний формат продукту.
Як насправді працює цикл
Якщо відкинути брендинг, цикл всюди приблизно однаковий:
- Отримання завдання. Надходить сигнал для запуску. Продукт визначає, чи це справжнє завдання, іноді ставить уточнювальне запитання й додає сесію до черги.
- Середовище. Агент клонує потрібну гілку репозиторію, запускає скрипт налаштування або образ і встановлює інструментарій. Мережевий доступ і секрети налаштовують на цьому етапі, а не пізніше.
- Робота. Агент читає код, редагує файли, запускає тести й команди та часом відкриває браузер. Тривалі завдання виконуються і після переходу ноутбука в режим сну.
- Результат. Агент надсилає гілку й відкриває PR або залишає diff і письмовий підсумок. Деякі продукти повертають чернетки PR, оскільки агент має зупинитися до злиття.
- Перевірка. Людина читає diff, залишає коментарі й або зливає зміни, або просить внести правки, або продовжує роботу в локальній сесії. Деякі продукти також можуть стежити за PR і надсилати виправлення, якщо CI завершується помилкою.
Найважливіші відмінності виникають на етапах 2 і 5. Якщо скрипт налаштування виконується надто довго, агент не може клонувати репозиторій, мережеві правила блокують реєстр пакунків або ізольоване середовище не має потрібних облікових даних, просте на перший погляд завдання зупиниться. А «результат, який можна перевірити» все одно має перевірити людина: жоден із цих продуктів не скасовує перевірку — вони переносять набір коду.
Чому ця хвиля набирає обертів саме зараз
Для цього мали збігтися три умови. Моделі стали достатньо надійними, щоб виконувати довгі цикли роботи з інструментами без постійного нагляду. Ізольовані середовища й скрипти налаштування стали достатньо дешевими, щоб для кожного завдання створювати окреме середовище. А pull request став стандартним інтерфейсом взаємодії агента з рецензентом, тож командам не довелося вигадувати новий процес перевірки.
Є й аргумент про увагу. У супровідному есеї DeepSeek прямо про це сказано: можливості виконання одного завдання обмежені моделлю, а продуктивність людини в багатьох завданнях — її увагою. Хмарний агент перебирає на себе керування сесіями, перемиканням контексту й очікуванням, звільняючи від цього людину. Цю тезу наведено в есеї DeepSeek, а не в незалежному дослідженні, але вона пояснює, чому такі рішення здаються корисними.
Чим доводиться поступитися
Будь-який хостинговий продукт обмінює контроль на зручність:
- Межа довіри. Ваш код, а часом і облікові дані, залишають ваш комп’ютер. Постачальники по-різному докладно описують ізоляцію, зберігання даних і мережевий доступ; вивчайте умови кожного продукту окремо, а не вважайте всі рішення цієї категорії однаковими.
- Ізоляція. Керована віртуальна машина призначена для ізоляції агента, але вона все одно належить до середовища постачальника. Під словом «ізольоване середовище» можуть мати на увазі що завгодно — від захищеної віртуальної машини до контейнера з широким мережевим доступом.
- Налаштування. Хмарні агенти пропонують параметри, а не вихідний код. Якщо вашому робочому процесу потрібен інший спосіб запуску, інше правило перевірки чи інша модель, ви обмежені можливостями продукту.
- Модель оплати. Більшість цих продуктів оплачуються за підпискою або тарифним планом з обмеженнями використання; час роботи агента не відображається окремою статтею витрат, якою ви можете безпосередньо керувати. Плануйте бюджет за тарифом, а не за токенами.
- Обсяг можливостей і прив’язка до постачальника. Підтримка кількох репозиторіїв, інтеграції з чатами й засоби корпоративного контролю відрізняються залежно від постачальника, а перенесення робочого процесу з одного продукту в інший не безкоштовне.
Самостійне розміщення: Super-agent від DeepSeek
Реліз DeepSeek цікавий тим, що ставить запитання: як виглядав би той самий цикл, якби площина керування залишалася у вас? Репозиторій містить TypeScript-плагін для DeepSeek Harness (DSH) за ліцензією MIT, версії 0.1.0, опублікований як дослідницький прототип. У README чітко сказано: його адаптували для публікації, він не ідентичний внутрішній версії DeepSeek і не реалізує всі ідеї з дизайн-есею.
Його структура передбачає довготривалу сесію Router і окрему сесію Worker для кожного тікета. Події проходять ланцюжком Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Команда надає дозвіл на роботу через політику; явні згадки через @ від дозволених учасників приймаються, а проактивна робота починається в режимі observe, який записує, що зробив би агент, не створюючи тікетів. Для кожного Ticket створюються окрема сесія й каталог; команда підготовки може створити git worktree для кожного тікета.
Операційна модель тут протилежна ізольованому середовищу постачальника. Система стежить за одним репозиторієм на github.com (GitHub Enterprise Server не підтримується) і, за бажанням, за Feishu. Профілі Router і Worker працюють із параметром danger-full-access від імені користувача ОС, який запускає систему; обгортки облікових записів визначають облікові дані агента, але не ізолюють процес. У посібнику з розгортання рекомендовано виділити окремий обліковий запис ОС, що зберігає лише облікові дані агента. Стан зберігається в SQLite у каталозі, заданому параметром stateDir. Філософію сформульовано як баланс: забирати якомога менше уваги людини й приносити якомога більше користі.
В есеї наведено показники планування для синтетичного навантаження — близько 300 повідомлень і 20 запитів на роботу, симульовані інструменти, п’ять запусків — із p50/p95 приблизно 12.4 / 15.7 хвилини проти приблизно 29.5 хвилини p95 для базового варіанта з однією сесією, який не виконував викликів субагентів. Це власні вимірювання з есею, отримані із симульованими інструментами, а не незалежний бенчмарк якості програмування.
Прототип демонструє дещо вужчу, але кориснішу річ, ніж запуск продукту: агент для написання коду, що запускається подіями й передає результат на перевірку наприкінці, не прив’язаний до хмари постачальника. Ви можете самостійно керувати оркестратором, станом і вибором моделі. Водночас він демонструє і ціну такого контролю: ви запускаєте процес, захищаєте обліковий запис і погоджуєтеся з тим, що прототип за замовчуванням не має пісочниці.
Що обрати
Залишайтеся з хмарним агентом, якщо вам потрібні нульові операційні клопоти, пісочниця під керуванням постачальника, функції для кількох репозиторіїв або організацій, а також запуск із GitHub, Slack, Teams чи вебзастосунку. Постачальник забезпечує ізоляцію та безперебійну роботу.
Розгляньте прототип для самостійного розгортання, якщо код не може залишати вашу інфраструктуру, вам потрібно змінювати оркестрацію або ви хочете обирати модель для кожної ролі. Передбачте окрему машину чи обліковий запис ОС і ставтеся до коду як до дослідницького ПЗ.
Практичний компроміс: використовуйте хмарних агентів для типових завдань із репозиторіями, а агента для самостійного розгортання — лише для репозиторіїв, де важлива межа даних. Етап перевірки в обох випадках однаковий.
Примітка щодо моделей
У прототипі модель не задана жорстко. Він використовує модель за замовчуванням у профілі Harness, якщо її не перевизначено для Eval або Execution, тож команда може призначити легшу модель для Router, а потужнішу — для Workers. AIHubMix підключає DeepSeek Harness через ендпоінт, сумісний з OpenAI: https://aihubmix.com/v1; у прикладі з посібника DeepSeek Harness вказано провайдера aihubmix і модель auto. У посібнику описано базове підключення DSH, а не плагін Super-agent, і хмарні продукти вище самостійно керують вибором моделі.
Поширені запитання
Що таке хмарний агент для написання коду?
Програмне забезпечення, яке отримує завдання з написання коду з Issue, згадки в чаті або виклику API, виконує його в середовищі поза вашим комп’ютером і повертає гілку, diff або pull request для перевірки.
Це те саме, що локальний агент для написання коду?
Ні. Локальний агент працює у вашому терміналі чи IDE, поки ви за ним спостерігаєте. Хмарний агент продовжує працювати після того, як ви закриєте ноутбук, і розрахований на подальшу перевірку.
Код усе одно потрібно перевіряти?
Так. Кожен із цих продуктів завершує роботу diff або PR, який має перевірити людина. Агент бере на себе набір коду, а не затвердження.
Де виконується ваш код?
У середовищі постачальника. Деталі різняться: Copilot описує хмарну пісочницю або середовище Actions, Cursor — ізольовані віртуальні машини, Codex — хмарний робочий простір, Claude Code — ізольовану віртуальну машину під керуванням Anthropic або середовище організації для самостійного розміщення, а Devin — робочий простір із терміналом, редактором і браузером. Перш ніж довіряти їм приватний код, прочитайте документацію кожного постачальника з безпеки.
Що таке бот для написання коду?
Чатова версія тієї самої ідеї: ви згадуєте агента в Slack, Teams або Feishu замість того, щоб призначати Issue. Він і далі працює у віддаленому середовищі; результатом може бути PR або diff, а для універсального помічника на кшталт Grok Bot — готові файли та чернетки.
Що додає Super-agent від DeepSeek?
Реалізацію тієї самої робочої схеми з ліцензією MIT для самостійного розгортання: архітектуру Router–Worker, модель політик і завдань, а також необов’язкову інтеграцію з Feishu. Це дослідницький прототип, а не хмарний продукт.
Чи готовий він до використання у виробництві?
Ні. У README він названий дослідницьким кодом, попередні налаштування запускаються з danger-full-access, а пісочниці за замовчуванням немає. Якщо вирішите його випробувати, використовуйте окремий обліковий запис ОС і окремий обліковий запис агента GitHub.
Джерела
- deepseek-ai/dsh-superagent-prototype — README, цитоване в ньому есе про дизайн і docs/000–008
- Підключення DeepSeek Harness до AIHubMix — AIHubMix
- Хмарний агент GitHub Copilot — документація GitHub
- Cursor Cloud Agents — документація Cursor
- Codex Cloud — ChatGPT Learn / OpenAI
- Claude Code у хмарі — Anthropic
- Документація Devin — Cognition
- Документація Grok Bot — xAI



