Сред инструментите за разработчици се наложи нов навик: оставяте задача някъде — в Issue, като споменаване в чат или в поле за промпт — затваряте лаптопа и се връщате към клон или заявка за изтегляне, създадени от агент, докато ви е нямало. GitHub, Cursor, OpenAI, Anthropic, Cognition и xAI вече предлагат различни варианти на това под имена като облачен агент, фонов агент, облачна сесия или автономен софтуерен инженер. В тази статия обясняваме категорията: какво всъщност правят тези продукти, как протича работният цикъл, от какво се отказвате и къде в него се вписва прототипът с отворен код Super-agent на DeepSeek.
Какво се счита за облачен агент за програмиране
Това понятие е широко, затова е полезно да назовем трите общи елемента на всеки продукт в тази категория:
- Задействане, което не изисква отворена среда за редактиране. Задачата постъпва като възложен 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 | Браузър, мобилно или настолно приложение, терминал | Виртуална машина, управлявана от Anthropic, или самостоятелно хоствана среда | Клон или PR |
| Devin | Slack, Teams, уеб, CLI, API | Работна среда с терминал, редактор и браузър | Чернова на PR |
| Grok Bot | Чат в настолно/мобилно приложение, @bot в X | Облачна машина (хоствана от Cursor) | Файлове или чернови |
Grok Bot е най-общият продукт в списъка: xAI го описва като постоянен AI колега, който се задейства от чат в настолно или мобилно приложение, или чрез споменаване на @bot в X, когато акаунтите са свързани. Работи на облачна машина на ниво акаунт, хоствана от Cursor, с достъп до браузър, хранилище и команден ред. Документацията му описва готови файлове и чернови, но не и работен процес с хранилище; създаването на клонове и PR не е документирано. Така той попада в бот края на спектъра.
Четири разлики са по-важни от таблицата:
Къде се намира начинът на задействане. GitHub Copilot cloud agent и OpenAI Codex Cloud са предназначени за задачи, които вече се намират в GitHub или приложението ChatGPT. Cursor Cloud Agents и Devin разчитат повече на чат: нишка в Slack или Teams е входната точка. Облачните сесии Claude Code могат да се задействат от браузър, телефон, настолното приложение или командата 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. Задача, която изглежда лесна, може да спре заради бавен скрипт за настройка, хранилище, което агентът не може да клонира, мрежова политика, блокираща регистър с пакети, или идентификационни данни, недостъпни за пясъчника. А „резултат, готов за преглед“ все така означава, че човек трябва да го прегледа: нито един от тези продукти не премахва прегледа — те само преместват писането на кода.
Защо тази вълна настъпва точно сега
Три условия трябваше да се съберат. Моделите станаха достатъчно надеждни, за да изпълняват дълги цикли с инструменти без постоянен надзор. Пясъчниците и скриптовете за настройка станаха достатъчно евтини, за да се осигурява отделна среда за всяка задача. А заявката за изтегляне се превърна в стандартния интерфейс между агент и проверяващ, така че екипите не трябваше да измислят нов процес за преглед.
Има и аргумент, свързан с вниманието. В придружаващото си есе за дизайна DeepSeek излага идеята изрично: една задача е ограничена от възможностите на модела, но производителността на човек по много задачи е ограничена от вниманието му. Облачният агент прехвърля управлението на сесиите, превключването между контексти и чакането извън задачите на човека. Това твърдение идва от есето на DeepSeek, а не от независимо изследване, но описва защо категорията изглежда полезна.
От какво се отказвате
Всеки хостван продукт разменя контрол за удобство:
- Граница на доверие. Вашият код, а понякога и идентификационните ви данни, напускат компютъра ви. Доставчиците публикуват различни нива на подробност за изолацията, съхранението на данни и мрежовия достъп; проверявайте всеки продукт поотделно, вместо да приемате, че условията са еднакви за цялата категория.
- Изолация. Управляваната виртуална машина е проектирана да ограничава агента, но все пак е среда на доставчика. „Пясъчник“ може да означава всичко — от подсилена виртуална машина до контейнер с широк мрежов достъп.
- Персонализиране. Хостваните агенти предоставят настройки, а не изходен код. Ако работният ви процес изисква различен начин на задействане, друго правило за преглед или друг модел, възможностите ви се ограничават до предлаганото от продукта.
- Модел на ценообразуване. Повечето от тези продукти се таксуват чрез абонамент или план с ограничения за използване; времето на агента не е отделен разход, който можете да контролирате пряко. Планирайте бюджета според плана, а не според токените.
- Обхват и обвързване с доставчик. Поддръжката на няколко хранилища, интеграциите с чат и корпоративните контроли се различават при отделните доставчици, а прехвърлянето на работен процес от един към друг не е безплатно.
Самостоятелно хостваният вариант: Super-agent на DeepSeek
Публикацията на DeepSeek е интересна, защото задава въпроса как би изглеждал същият работен цикъл, ако равнището за управление остане при вас. Хранилището съдържа TypeScript плъгин за DeepSeek Harness (DSH), версия 0.1.0, с лиценз MIT и публикуван като изследователски прототип. В 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 или заявка за изтегляне за преглед.
Същото ли е като локален кодиращ агент?
Не. Локалният агент работи във вашия терминал или IDE, докато го наблюдавате. Облачният агент продължава да работи, след като затворите лаптопа, и е предназначен за последващ преглед.
Трябва ли все пак да преглеждате кода?
Да. Всеки продукт тук завършва с diff или PR, който човек да прегледа. Агентът поема писането на код, но не и одобрението.
Къде се изпълнява кодът ви?
В средата на доставчика. Детайлите се различават: Copilot описва облачна изолирана среда или среда на Actions, Cursor — изолирани виртуални машини, Codex — облачно работно пространство, Claude Code — изолирана виртуална машина, управлявана от Anthropic, или самостоятелно хоствана среда на организацията, а Devin — работно пространство с терминал, редактор и браузър. Прочетете документацията на всеки доставчик за сигурността, преди да му поверите частен код.
Какво е бот за програмиране?
Чат версията на същата идея: вместо да възлагате Issue, споменавате агента в Slack, Teams или Feishu. Той пак работи в отдалечена среда; резултатът може да е 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



