DeepSeek Super-agent: wat cloud-codeeragents zijn en waar het past

AIHubMix8 min leestijd
DeepSeek Super-agent: wat cloud-codeeragents zijn en waar het past

In ontwikkelaarstools is een nieuwe gewoonte ontstaan: zet ergens een taak uit — een Issue, een chatvermelding, een promptveld — klap je laptop dicht en kom terug bij een branch of pull request die een agent heeft gemaakt terwijl je weg was. GitHub, Cursor, OpenAI, Anthropic, Cognition en xAI bieden nu allemaal een variant hiervan aan, onder namen als cloudagent, background agent, cloudsessie of autonome software-engineer. Dit artikel legt de categorie uit: wat deze producten precies doen, hoe de workflow verloopt, wat je ervoor inlevert en waar DeepSeeks open-sourceprototype Super-agent hierin past.

Wat geldt als een cloud-codeeragent?

De term is ruim, dus het helpt om de drie onderdelen te benoemen die alle producten in deze categorie gemeen hebben:

  • Een trigger waarvoor geen editor open hoeft te staan. Werk komt binnen via een Issue-toewijzing, een @vermelding in Slack of Feishu, een prompt in een webapp, een API-aanroep of een overdracht via de CLI.
  • Een omgeving buiten je machine. De agent kloont de repository, installeert wat nodig is en werkt in een sandbox of werkruimte die wordt beheerd door de leverancier of je organisatie.
  • Een resultaat dat je kunt beoordelen. De agent levert een branch, diff, concept-PR of opmerking op — iets dat iemand kan beoordelen en waar diegene iets mee kan doen.

Zo onderscheidt deze categorie zich van twee naburige categorieën. Een lokale IDE-agent draait op je laptop terwijl je meekijkt; een chatassistent beantwoordt vragen zonder de repository aan te raken. Een cloud-codeeragent zit ertussenin: hij heeft echte tools en een echte checkout, maar het is de bedoeling dat de mens weggaat.

Het woord bot beschrijft dezelfde aanpak in een chatgerichte vorm. In plaats van een Issue toe te wijzen, vermeld je de agent in Slack, Teams of Feishu. De trigger verandert, maar de externe omgeving niet. Het resultaat kan een PR, een diff of een verzameling afgeronde bestanden zijn.

Het productoverzicht

Zes producten, beschreven zoals hun leveranciers ze zelf omschrijven:

Product Startpunt Draait in Levert op
GitHub Copilot cloud agent Issue, @, Agents-paneel Cloudsandbox of Actions Branch of PR
Cursor Cloud Agents Desktop, web, Slack, Linear Geïsoleerde cloud-VM PR
OpenAI Codex Cloud ChatGPT-web, desktop, mobiel Cloudwerkruimte Wijzigingen of PR
Claude Code-cloudsessies Browser, mobiel, desktop, terminal Door Anthropic beheerde VM of zelfgehoste omgeving Branch of PR
Devin Slack, Teams, web, CLI, API Werkruimte met terminal, editor en browser Concept-PR
Grok Bot Desktop-/mobiele chat, @bot op X Cloudmachine (gehost door Cursor) Bestanden of concepten
De kolom ‘Draait in’ volgt de eigen bewoordingen van elke leverancier. De details over isolatie verschillen, en de documentatie van Devin beschrijft de VM-architectuur of isolatiegaranties niet.

Grok Bot is de breedste toepassing: xAI omschrijft het als een permanente AI-teamgenoot, die je start vanuit de desktop- of mobiele chat, of door @bot te vermelden op X wanneer de accounts zijn gekoppeld. Het draait op een cloudmachine op accountniveau die door Cursor wordt gehost, met toegang tot de browser, opslag en de opdrachtregel. De documentatie beschrijft afgeronde bestanden en concepten, geen repositoryworkflow; het aanmaken van branches en PR’s wordt niet gedocumenteerd. Daarmee bevindt het zich aan de botkant van het spectrum.

Vier verschillen zijn belangrijker dan de tabel:

Waar de trigger zich bevindt. GitHub Copilot cloud agent en OpenAI Codex Cloud zijn ontworpen voor werk dat al in GitHub of de ChatGPT-app staat. Cursor Cloud Agents en Devin zijn meer chatgericht: een Slack- of Teams-thread is het startpunt. Claude Code-cloudsessies accepteren triggers vanuit een browser, telefoon, desktopapp of claude --cloud in een terminal, en kunnen ook volgens een schema draaien.

Hoeveel de leverancier over de werking laat zien. Claude Code documenteert de isolatie uitgebreid: in door Anthropic gehoste omgevingen draait elke sessie in een geïsoleerde VM, is netwerktoegang standaard beperkt en blijven git-referenties buiten de sandbox, terwijl een proxy namens de sessie de authenticatie verzorgt. Organisaties kunnen sessies in plaats daarvan naar een zelfgehoste omgeving sturen; de verantwoordelijkheid voor isolatie ligt dan bij hen. Cloudsessies delen de snelheidslimieten van je abonnement, zonder afzonderlijke VM-kosten; je hebt een claude.ai-aanmelding nodig en ze zijn niet beschikbaar wanneer Claude Code is ingesteld voor Amazon Bedrock, Google Cloud’s Agent Platform of een andere externe aanbieder. De overige leveranciers publiceren minder over de interne werking; ‘sandbox’ of ‘VM’ is vaak het einde van de openbare beschrijving.

Wat de agent mag aanraken. Sommige producten zijn beperkt tot één repository; andere bieden werk aan voor de hele organisatie of meerdere repositories. Dit is het eerste wat je moet toetsen aan je eigen opstelling, want een capabele agent met toegang tot de verkeerde repositories is nutteloos of gevaarlijk.

Voor welk soort werk het bedoeld is. De meeste producten op deze lijst zijn gericht op codeerwerk binnen repositories. Grok Bot is een algemene cloudteamgenoot: de documentatie beschrijft bestanden en concepten, geen repositoryworkflow. Zie ‘cloudagent’ als een spectrum, niet als één vaste productvorm.

Hoe de workflow precies verloopt

Haal de merktaal weg en de workflow is overal ongeveer hetzelfde:

  1. Intake. Er komt een trigger binnen. Het product bepaalt of het om een echte taak gaat, stelt soms een verduidelijkende vraag en zet een sessie in de wachtrij.
  2. Omgeving. De agent kloont de repository naar de juiste branch, voert een instellingsscript of image uit en installeert de toolchain. Netwerktoegang en geheimen worden hier ingesteld, niet later.
  3. Werk. De agent leest code, bewerkt bestanden, voert tests en opdrachten uit en opent soms een browser. Lange taken lopen door nadat je laptop in slaapstand gaat.
  4. Uitvoer. De agent pusht een branch en opent een PR, of levert een diff en een schriftelijke samenvatting. Sommige producten leveren concept-PR’s op omdat de agent geacht wordt te stoppen voordat er wordt gemerged.
  5. Review. Iemand leest de diff, geeft opmerkingen en merge’t de wijzigingen, vraagt om aanpassingen of zet het werk voort in een lokale sessie. Sommige producten kunnen de PR ook volgen en oplossingen pushen wanneer CI mislukt.

De verschillen die problemen opleveren, zitten in stap 2 en 5. Een instellingsscript dat te lang duurt, een repository die de agent niet kan klonen, een netwerkbeleid dat een pakketregister blokkeert of een referentie die de sandbox niet kan zien, kan een taak die eenvoudig leek stilleggen. En ‘resultaat dat je kunt beoordelen’ betekent nog steeds dat een mens het beoordeelt: geen van deze producten schrapt de reviewstap; ze verplaatsen het typwerk.

Waarom deze golf nu plaatsvindt

Drie voorwaarden moesten samenkomen. Modellen werden betrouwbaar genoeg om lange toolcycli zonder voortdurend toezicht uit te voeren. Sandboxes en instellingsscripts werden goedkoop genoeg om elke taak een eigen omgeving te geven. En de pull request werd de standaardinterface tussen een agent en een reviewer, waardoor teams geen nieuw reviewproces hoefden te bedenken.

Er speelt ook een argument rond aandacht. DeepSeeks begeleidende ontwerpessay maakt dat expliciet: één taak wordt begrensd door het model, maar de doorvoer van één persoon over meerdere taken wordt begrensd door aandacht. Een cloudagent neemt sessiebeheer, schakelen tussen contexten en wachten uit handen. Die bewering komt uit het essay van DeepSeek, niet uit onafhankelijk onderzoek, maar ze beschrijft waarom deze categorie nuttig aanvoelt.

Wat je ervoor inlevert

Elk gehost product ruilt controle in voor gemak:

  • Vertrouwensgrens. Je code en soms ook je referenties verlaten je machine. Leveranciers publiceren uiteenlopende details over isolatie, bewaring en netwerktoegang; bekijk die per product in plaats van aan te nemen dat de hele categorie hetzelfde werkt.
  • Isolatie. Een beheerde VM is bedoeld om de agent binnen de perken te houden, maar het blijft de omgeving van de leverancier. ‘Sandbox’ kan van alles betekenen: van een geharde VM tot een container met ruime netwerktoegang.
  • Aanpasbaarheid. Gehoste agents bieden instellingen, geen broncode. Als je workflow een andere trigger, een andere reviewregel of een ander model nodig heeft, ben je beperkt tot wat het product biedt.
  • Kostenmodel. De meeste producten worden gefactureerd via een abonnement of abonnementspakket met gebruikslimieten; de tijd van de agent is geen afzonderlijke kostenpost waarover je rechtstreeks controle hebt. Stel je budget vast op basis van het abonnement, niet per token.
  • Reikwijdte en leveranciersafhankelijkheid. Ondersteuning voor meerdere repositories, chatintegraties en bedrijfsfuncties verschilt per leverancier; een workflow van de ene naar de andere overzetten is niet gratis.

De zelfgehoste route: DeepSeeks Super-agent

De release van DeepSeek is interessant omdat die de vraag stelt hoe dezelfde workflow eruitziet wanneer het besturingsvlak bij jou blijft. De repository bevat een MIT-gelicentieerde TypeScript-plug-in voor DeepSeek Harness (DSH), versie 0.1.0, uitgebracht als onderzoeksprototype. De README maakt het expliciet: de plug-in is aangepast voor publicatie, is niet identiek aan de interne versie van DeepSeek en voert niet elk idee uit het ontwerpessay uit.

De opzet bestaat uit één langdurige Router-sessie en één Worker-sessie per ticket. Gebeurtenissen lopen via Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Een team geeft via een beleid toestemming voor werk; expliciete @vermeldingen van toegestane personen worden geaccepteerd, terwijl proactief werk start in de modus observe, die registreert wat de agent zou hebben gedaan zonder tickets aan te maken. Elk ticket krijgt een eigen sessie en map; met een voorbereidingsopdracht kan per ticket een git-worktree worden aangemaakt.

Het operationele model staat haaks op een sandbox van een leverancier. Het luistert naar één github.com-repository (geen GitHub Enterprise Server) en optioneel naar Feishu. Zowel de Router- als de Worker-voorinstellingen draaien met danger-full-access als de OS-gebruiker van de operator; accountwrappers kiezen de inloggegevens van de agent, maar isoleren het proces niet. In de implementatiehandleiding wordt aangeraden een apart OS-account te gebruiken dat alleen de inloggegevens van de agent bevat. De status wordt opgeslagen in SQLite onder een ingestelde stateDir. De filosofie wordt beschreven als een afweging: besteed zo weinig mogelijk menselijke aandacht en lever zo veel mogelijk waarde.

Het essay vermeldt planningscijfers uit een synthetische werklast — ongeveer 300 berichten en 20 werkaanvragen, gesimuleerde tools, vijf runs — met een p50/p95 van ongeveer 12.4 / 15.7 minuten, tegenover ongeveer 29.5 minuten p95 voor een basislijn met één sessie die geen subagentaanroepen deed. Dit zijn de eigen metingen van het essay met gesimuleerde tools, geen onafhankelijke benchmark voor codekwaliteit.

Het prototype laat iets zien dat beperkter en nuttiger is dan een productlancering: de eventgestuurde codeeragent die aan het eind wordt beoordeeld, zit niet opgesloten in de cloud van een aanbieder. Je kunt zelf de orkestrator, de status en de modelkeuze beheren. Het laat ook zien wat die verantwoordelijkheid kost: je beheert het proces, beveiligt het account en accepteert dat het prototype standaard geen sandbox heeft.

Welke optie past bij wie?

Kies voor een gehoste cloudagent als je geen operationele taken wilt, een door de aanbieder beheerde sandbox wilt, functies voor meerdere repositories of organisaties nodig hebt en een trigger wilt in GitHub, Slack, Teams of een webapp. De aanbieder is verantwoordelijk voor isolatie en uptime.

Overweeg het zelf gehoste prototype als code je infrastructuur niet mag verlaten, je de orkestratie moet aanpassen of je per rol het model wilt kiezen. Reserveer budget voor een aparte machine of een apart OS-account en behandel de code als onderzoekssoftware.

Een praktische combinatie: gebruik gehoste agents voor routinematig werk aan repositories en een zelf gehoste agent alleen voor repositories waarvoor de datagrens belangrijk is. In beide gevallen is de beoordelingsstap hetzelfde.

Een opmerking over modellen

Het prototype legt geen model vast in de code. Het gebruikt standaard het profiel van Harness, tenzij Eval of Execution dit overschrijft. Zo kan een team een lichter model inzetten voor de Router en een krachtiger model voor Workers. AIHubMix verbindt DeepSeek Harness via een OpenAI-compatibel eindpunt op https://aihubmix.com/v1; het voorbeeld in de DeepSeek Harness-gids gebruikt aanbieder aihubmix en model auto. De gids behandelt de basisverbinding met DSH, niet de Super-agent-plug-in; de gehoste producten hierboven regelen hun modelkeuze zelf.

Veelgestelde vragen

Wat is een cloudcodeeragent?
Software die een codeertaak oppakt vanuit een Issue, een chatvermelding of een API-aanroep, deze uitvoert in een omgeving buiten je eigen machine en een branch, diff of pull request terugstuurt ter beoordeling.

Is dat hetzelfde als een lokale codeeragent?
Nee. Een lokale agent draait in je terminal of IDE terwijl je meekijkt. Een cloudagent blijft werken nadat je je laptop hebt dichtgeklapt en is bedoeld om later te worden beoordeeld.

Moet je de code nog steeds beoordelen?
Ja. Elk product hier levert uiteindelijk een diff of PR op die iemand moet beoordelen. De agent neemt het tikwerk over, niet de goedkeuring.

Waar wordt je code uitgevoerd?
In de omgeving van de aanbieder. De details verschillen: Copilot beschrijft een cloudsandbox of Actions-omgeving, Cursor geïsoleerde VM's, Codex een cloudwerkruimte, Claude Code een geïsoleerde VM die door Anthropic wordt beheerd of een zelf gehoste omgeving van een organisatie, en Devin een werkruimte met terminal, editor en browser. Lees de beveiligingsdocumentatie van elke aanbieder voordat je die met privécode vertrouwt.

Wat is een codeerbot?
Dezelfde aanpak, maar dan rechtstreeks vanuit chat: je vermeldt de agent in Slack, Teams of Feishu in plaats van een Issue toe te wijzen. De agent werkt nog steeds in een externe omgeving; de uitvoer kan een PR of diff zijn, of, bij een algemene collega zoals Grok Bot, voltooide bestanden en concepten.

Wat voegt DeepSeeks Super-agent toe?
Een zelf gehoste implementatie met MIT-licentie van dezelfde cyclus, met een Router–Worker-ontwerp, een beleids- en ticketmodel en optionele ondersteuning voor Feishu. Het is een onderzoeksprototype, geen gehost product.

Is het klaar voor productie?
Nee. De README noemt het onderzoekscode, de presets draaien met danger-full-access en er is standaard geen sandbox. Gebruik een apart OS-account en een speciaal GitHub-account voor de agent als je ermee aan de slag gaat.

Bronnen

  1. deepseek-ai/dsh-superagent-prototype — README, het aangehaalde ontwerpessay en docs/000–008
  2. DeepSeek Harness verbinden met AIHubMix — AIHubMix
  3. GitHub Copilot-cloudagent — GitHub Docs
  4. Cursor Cloud Agents — Cursor Docs
  5. Codex Cloud — ChatGPT Learn / OpenAI
  6. Claude Code in de cloud — Anthropic
  7. Devin-documentatie — Cognition
  8. Grok Bot-documentatie — xAI

Eén gateway naar meerdere AI-aanbieders. Gebouwd voor productie.

Bezoek AIHubMix