Teil 2 eines Lernwegs in fünf Etappen für Entwickler und Admins: Agent-Modus mit Plan Mode, Checkpoints und Freigaben, Cloud Agents mit Umgebung, Secrets und Ausgabenlimit, zum Schluss ein kleines eigenes Projekt mit Checkliste. Stand der Dokumentation: 6. November 2026.
Inhalt 8 Abschnitte

Teil 2 von 3: Aus dem Chat wird ein Helfer, der im Hintergrund arbeitet. Die Etappen 3 bis 5 führen dich dorthin. Voraussetzung ist Teil 1: installiertes Cursor, Regeln und eine AGENTS.md.
Du hast jetzt einen Agenten, der deine Konventionen kennt. Damit lernst du, ihm grössere Aufgaben zu geben und die Kontrolle zu behalten. Alle Funktionen und Namen stammen aus der Cursor-Dokumentation, abgerufen am 6. November 2026.
Das Wichtigste in Kürze
- Plan Mode spart Korrekturschleifen. Bei Aufgaben über mehrere Dateien klärt der Agent zuerst Fragen und legt einen Plan vor.
- Checkpoints sind lokal und ersetzen Git nicht. Sie machen Änderungen des Agenten rückgängig, nicht Commits.
- Cloud Agents brauchen einen passenden Tarif und eine Umgebung. Free und Plus enthalten sie laut Dokumentation nicht.
Tag 3: Agent-Modus mit Plan Mode und Checkpoints
Ziel: Du gibst dem Agenten eine Aufgabe über mehrere Dateien und behältst die Kontrolle.
Dafür bringt der Agent viel mit: Er kann Dateien lesen und ändern, Terminalbefehle ausführen, im Web suchen und mit dem eingebauten Browser Screenshots machen. Eine Obergrenze für Werkzeugaufrufe gibt es laut Dokumentation nicht. Deshalb lohnt es sich, den Rahmen früh zu setzen. Diese Tastenkürzel brauchst du dafür:
| Kürzel | Wirkung | Bemerkung |
|---|---|---|
Cmd+I |
Agent in der Seitenleiste öffnen |
Einstieg für jeden Auftrag |
Shift+Tab |
Zwischen Modi wechseln, etwa in den Plan Mode |
Cursor schlägt Plan Mode bei komplexen Aufgaben auch selbst vor |
Enter |
Nachricht in die Warteschlange stellen |
Der Agent arbeitet sie nach dem aktuellen Auftrag ab |
Cmd+Enter |
Nachricht sofort senden |
Umgeht die Warteschlange |
Cmd+/ |
Modell wechseln |
Gilt ab der nächsten Nachricht |
Drücke Shift+Tab im Eingabefeld, um in den Plan Mode zu wechseln. Dort stellt der Agent Rückfragen, durchsucht die Codebasis und legt einen Plan vor, den du bearbeitest, bevor er baut. Pläne landen standardmässig in deinem Home-Verzeichnis; „Save to workspace“ legt sie ins Projekt. Weicht das Ergebnis vom Gewünschten ab, verwirf die Änderungen, schärfe den Plan und starte neu. Das geht laut Dokumentation oft schneller, als einen laufenden Agenten zu korrigieren.
Zudem sichern Checkpoints den Zustand vor grösseren Änderungen. Klicke einen Checkpoint im Verlauf an, schau dir die Dateien an und stelle sie wieder her. Das betrifft nur Dateien, nicht die Nachrichten. Checkpoints liegen lokal und ersetzen kein Git.
Über die Warteschlange gibst du dem Agenten während der Arbeit weitere Anweisungen. Ausserdem wählst du unter Settings > Agents > Approvals & Execution den Ausführungsmodus. Dabei führt Auto-review bekannt sichere Aufrufe direkt aus, sandboxt Shell-Befehle nach Möglichkeit und lässt den Rest von einem Klassifikator prüfen. Die Dokumentation nennt das für die meisten die sicherste brauchbare Einstellung.
| Modus | Was ohne Rückfrage läuft | Sandbox | Passt, wenn |
|---|---|---|---|
Auto-review |
Freigegebene Aufrufe sofort, übrige Shell-Befehle in der Sandbox, Rest nach Prüfung durch einen Klassifikator |
Ja, für Shell-Befehle |
Du willst wenige Rückfragen und eine Prüfung vor riskanten Aufrufen |
Allowlist |
Nur Aktionen auf deiner Liste |
Optional |
Du willst feste Abläufe mit wenigen vertrauten Aktionen |
Run Everything |
Jeder Aufruf |
Nein |
Du nimmst das Risiko bewusst in Kauf |
Übung: Wechsle mit Shift+Tab in den Plan Mode und gib einen Auftrag über mindestens drei Dateien, zum Beispiel:
Plane eine neue Konfigurationsoption für das Projekt.
Betroffen sind Code, Test und Doku. Stelle vor dem Plan Rückfragen.
Ändere den Plan einmal ab, baue ihn und stelle danach einen Checkpoint testweise wieder her.
Geschafft, wenn du einen Plan bearbeitet, gebaut und einen Checkpoint wiederhergestellt hast.
Cursor Learn: Working with Agents
Tag 4: Cloud Agents
Ziel: Ein Agent arbeitet auf einer eigenen VM an einem Branch und meldet sich mit einem Ergebnis.
So laufen Cloud Agents auf isolierten Ubuntu-Maschinen, arbeiten auf einem getrennten Branch und pushen ihre Änderungen in dein Repository. Dein Rechner muss dafür nicht eingeschaltet bleiben. Gestartet werden sie von mehreren Orten aus:
| Ort | So startest du | Bemerkung |
|---|---|---|
Desktop-Programm |
Cloud im Dropdown unter dem Eingabefeld wählen |
Bequem für den Wechsel zwischen lokal und Cloud |
Web |
Auf jedem Gerät, unter Android als installierbare Web-App |
|
iOS |
Cursor-App für iPhone und iPad |
Agenten starten, verfolgen und Pull Requests prüfen |
Slack, GitHub, Bitbucket, Linear |
@cursor in Befehl oder Kommentar |
Auch per API möglich |
Dabei sind drei Voraussetzungen aus der Cloud-Agent-Dokumentation leicht zu übersehen:
- Ein Admin des Cursor-Kontos muss die Quellcodeverwaltung verbinden: GitHub, GitLab, Bitbucket Cloud oder Azure DevOps. Ohne Repository bleibt „Start from scratch“.
- Du brauchst Lese- und Schreibrechte auf das Repository und abhängige Repositories oder Submodule.
- Der Tarif muss Cloud Agents enthalten: Premium und höher, Teams, Enterprise oder ein älterer Bezahltarif. Free und Plus gehören nicht dazu. Beim ersten Start fragt Cursor nach einem Ausgabenlimit.
Ausserdem entscheidet die Umgebung über die Qualität. Laut Setup-Seite hast du zwei Wege: Der Agent richtet sie selbst ein (empfohlen, laut Dokumentation in unter zehn Minuten) oder du beschreibst sie per Dockerfile in .cursor/environment.json. Secrets trägst du im Dashboard ein; sie werden beim Start eingespielt, nach einer Änderung brauchst du also einen neuen Agenten.
Übung: Richte die Umgebung für dein Übungs-Repository ein, am besten mit dem geführten Setup. Gib dann einen Auftrag mit klarem Ende:
Ergänze Unit-Tests für das Modul X, führe sie aus
und öffne einen Pull Request.
Schau dem Agenten über das gemeinsame Terminal oder die Artefakte (Screenshots, Logs) zu.
Geschafft, wenn der Agent seine Änderung selbst getestet hat und du den Pull Request im Repository liest.
Cursor Learn: Reviewing and Testing Code
Tag 5: Dein eigenes kleines Projekt
Ziel: Du baust eine kleine Anwendung von der Idee bis zum Pull Request und nutzt alles aus den Tagen 1 bis 4.
Deshalb wählst du etwas, das du an einem Tag schaffst: ein Kommandozeilenwerkzeug, eine kleine API oder ein Skript, das Logdateien auswertet. Die Reihenfolge ist vorgegeben.
- Lege
AGENTS.mdmit Build- und Testbefehlen an, bevor du Code schreibst. - Plane im Plan Mode das Gerüst und baue es lokal.
- Setze eine File-Rule für deine wichtigste Konvention.
- Gib einem Cloud Agent die Aufgabe, Tests zu ergänzen, und einen zweiten, die README zu schreiben.
- Lies beide Pull Requests und gib frei.
Eine knappe AGENTS.md für Schritt 1 kann so aussehen:
# Projekt
- Build: `npm run build`
- Tests: `npm test` (müssen vor jedem Pull Request grün sein)
- Stil: Named Exports, Funktionen unter 50 Zeilen
- Nie ändern: Ordner `dist/` und `generated/`
Dabei rät die Best-Practices-Seite, den Agenten wie einen klugen Entwickler ohne Vorwissen zu behandeln. Was er braucht, um zu testen, gehört in AGENTS.md oder in Skills. Für Admins taugt dieselbe Übung mit einem Skript-Repository: Der Agent ergänzt Tests, Hilfetexte und eine Parameterprüfung für ein PowerShell- oder Bash-Skript.
Auf den Cursor Marketplace gehört eine Vorsicht: Erweiterungen laden Code auf deinen Rechner, ein Auto-Update schliesst das nicht aus. Wie das schiefgehen kann, beschreibt der Beitrag Infizierte Erweiterung im Cursor Marketplace.
Geschafft, wenn zwei Pull Requests des Agenten gemergt sind und du für jeden sagen kannst, was du geprüft hast.
Cursor Learn: Putting It Together
Checkliste zum Abhaken
- [ ] Cursor installiert, Konto angemeldet, Projekt geöffnet
- [ ] Codebasis erklären lassen und eine Änderung im Diff geprüft
- [ ] Mindestens zwei Regeln angelegt, eine davon mit
globs - [ ]
AGENTS.mdmit Build- und Testbefehlen vorhanden - [ ] Plan Mode genutzt, Plan bearbeitet, Checkpoint wiederhergestellt
- [ ] Ausführungsmodus unter Approvals & Execution bewusst gewählt
- [ ] Cloud-Umgebung eingerichtet, Secrets eingetragen, Ausgabenlimit gesetzt
- [ ] Cloud Agent hat getestet und einen Pull Request geöffnet
- [ ] Eigenes Projekt mit zwei geprüften Pull Requests abgeschlossen
Einordnung: Was das für Entwickler heisst
So verschiebt der Wechsel vom Chat zum Agenten verschiebt die Arbeit vom Tippen zum Prüfen. Wer Regeln, Pläne und Tests sauber vorgibt, bekommt Änderungen, die sich in Minuten lesen lassen. Ohne diese Vorgaben entstehen lange Diffs, die niemand gern freigibt. Für Teams zählt deshalb nicht die Zahl der Agenten, sondern die Qualität der Umgebung: Ein Cloud Agent, der nicht bauen kann, liefert Vermutungen. Plane auch die Kosten ein, denn Cloud Agents verbrauchen die Nutzung deines Tarifs zum Preis des gewählten Modells. Admins sollten zudem früh klären, wer Quellcodeverwaltung und Secrets verbindet.
Wie du dem Agenten Aufträge sprichst, statt sie zu tippen, zeigt Voice Chat in Cursor. Weitere Meldungen und Artikel zum Werkzeug sammelt der Cursor-Fahrplan. Mit Hooks als Leitplanken, MCP-Servern und Bugbot geht es in Teil 3 weiter.
Fazit
Damit lernst du mit Plan Mode, Checkpoints und Cloud Agents das Werkzeug in der Reihenfolge, in der es dir Arbeit abnimmt. Den grössten Hebel haben weiterhin Rules und AGENTS.md, weil sie jede Etappe verbessern. Plane den Cloud-Tag erst ein, wenn Tarif, Repository-Anbindung und Secrets geklärt sind, und arbeite die Checkliste einmal ab.
Quellen: Agent Overview, Plan Mode, Run Modes, Cloud Agents, Cloud-Umgebung, Best Practices. Foto: Tumisu / Pixabay. Stand: 6. November 2026.
Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht: Cursor-Bootcamp Teil 2, Agent-Modus und Cloud Agents.