Die meisten Teams behandeln Cursor wie ein Chat-Fenster, das Dateien bearbeiten kann. Das unternutzt das Produkt. Cursor ist eine IDE um eine Tool-Schleife herum: Das Modell liest Ihr Repo, führt Shell-Befehle aus, bearbeitet Dateien und sollte seine Arbeit gegen Tests und Linter prüfen, denen Sie bereits vertrauen.
Die Default-Haltung, die funktioniert: Automatisieren Sie alles, was Sie können — Kontext, Befehle, externe APIs und Verifikation — damit jede Agenten-Session ein durchgehendes Urteilsband bleibt statt einer Parade von Übergaben. Dieser Artikel ist der Einstieg in diese Schleife. Der Rest der Agenten-Architektur-Serie behandelt AGENTS.md, private Wissensbasen, MCP-Design, Composers RL-trainierte Tool-Policies und warum Single-Agent-Loops Plan–Kritik–Build-Pipelines für die meiste Coding-Arbeit schlagen.
Die Schleife, nicht der Chat
Cursor Agent (angetrieben von Composer) läuft Dutzende Züge pro Aufgabe: Grep, Lesen, Bearbeiten, Terminal, wiederholen. Jede Aktion ändert die Umgebung vor der nächsten Entscheidung — dieselbe sequenzielle Entscheidungsschleife wie in Reinforcement Learning für Tool-Aufrufe in Agentenmodellen, aber aus Sicht des Entwicklers.
Fehlermodus: vagen Prompt einfügen und hoffen. Erfolgsmodus: eine Arbeitseinheit scopen — ein Bug, ein Endpoint, ein Refactor — die in eine Session passt und mit einem eindeutigen Signal endet (Tests grün, Build läuft, Diff bereit zur Review). Ist die Einheit zu groß, teilen Sie die Arbeit, nicht den Agenten mitten im Flug.
Tag-eins-Setup (etwa fünfzehn Minuten)
Öffnen Sie das Repository in Cursor und prüfen Sie, dass Indexierung funktioniert: @-Referenzen lösen auf echte Dateien auf. Fügen Sie .cursorignore hinzu (oder erweitern Sie .gitignore) für Artefakte, auf die der Agent keine Tokens verschwenden soll — node_modules, Build-Output, große Binärdateien.
Erstellen Sie dünne Projektregeln, die auf AGENTS.md verweisen statt es zu duplizieren. Cursor liest Regeln jede Session; AGENTS.md ist die kanonische Quelle für Build-Befehle, Testschritte und Grenzen.
Dokumentieren Sie einen verifizierbaren Befehl, den der Agent vor "fertig" ausführen muss — npm test, pytest, pnpm lint oder Ihr Äquivalent. Dieser Befehl wird der Default-Kritiker. Bevorzugen Sie die Umgebung gegenüber einem zweiten LLM-Reviewer für dieselbe Arbeitseinheit.
Optional, aber hoher Hebel: Verbinden Sie einen MCP-Server für etwas, das Sie täglich tun — Issue-Tracker, Read-only-Datenbank, interne API. Siehe MCP-Server mit Search und Execute bauen.
Kontext automatisieren (aufhören, jede Session neu zu erklären)
Wenn Sie es zweimal im Chat gesagt haben, gehört es in eine Datei. Kontext-Automatisierung ist, wie Agenten zwischen Sessions überleben.
Repo-Mechanik lebt in AGENTS.md an der Wurzel, mit verschachtelten Dateien in Monorepo-Paketen. Dauerhafte Fakten gehören in ein privates Wissensbasis-Muster; siehe Wissen für KI-Agenten organisieren. Öffentliche Marketing-Wahrheit bleibt in genehmigten Copy-Quellen.
Cursor Skills und Projektregeln automatisieren, welche Anweisungen für einen Aufgabentyp geladen werden — ohne dieselbe Einleitung in jeden Prompt zu kopieren.
Verifikation automatisieren (Ihr bester Kritiker ist kein zweites LLM)
Tests schlagen Linter schlagen Typechecker schlagen "sieht das richtig aus?". Bitten Sie den Agenten, Verifikation auszuführen, nicht zu simulieren. CI-Logs, Pre-commit-Hooks und lokale Skripte sind Automatisierung, die Sie bereits besitzen.
Das ist die praktische Seite von Den Faden behalten: Die Tool-Schleife ist der Kritikschritt, wenn Test-Output in derselben Session bleibt.
Verdrahten Sie Verifikation explizit in AGENTS.md: "Führe pnpm test vor jedem Commit aus". Agenten führen gelistete Befehle aus, wenn relevant.
Ausführung automatisieren (Terminal, Skripte, MCP, asynchrone Agenten)
Terminal: sichere Befehle in AGENTS.md dokumentieren. Builds, Test-Suites, Locale-Regenerierung, Migrationen — wenn ein Mensch es routinemäßig ausführt, sollte der Agent es auch tun, innerhalb Ihrer Grenzen.
MCP: externe Systeme als Tools exponieren statt API-Antworten in den Chat zu kopieren.
Background- und Cloud-Agenten: begrenzte asynchrone Einheiten delegieren — CI auf einem Branch fixen, lokalisiertes HTML aus einem Katalog regenerieren — mit klaren Git-Regeln. Das Übergabe-Artefakt ist der Diff und CI-Status, keine Prosa-Zusammenfassung.
Regenerierungsschritte gehören in Skripte. Wenn Ihre Site aus einer Katalog-JSON-Datei gebaut wird, dokumentieren Sie python3 website/scripts/build_locales.py in AGENTS.md.
Cursor-Modi — wann was nutzen
Tab / Inline-Vervollständigung — lokale Edits, Umbenennungen, kleine Refactors. Sie steuern; Automatisierung ist partiell.
Agent (Composer) — Multi-Datei-Features, Debuggen mit Test-Schleife, repo-weite Refactors. Voller Tool- und Terminal-Zugriff.
Ask / read-only — Exploration ohne Ausführung.
Background / Cloud Agents — asynchrone Einheiten mit Git-Artefakt. Arbeit automatisieren; Merge-Urteil menschlich halten.
Was nicht automatisieren
Automatisieren Sie alles, wo Sie können — nicht alles ohne Review. Secrets, Produktions-Deploys, Auth-Änderungen und CI-Workflow-Edits bleiben hinter expliziten Grenzen in AGENTS.md.
Architektur-Forks brauchen menschliches Urteil. Der Agent schlägt vor; Sie entscheiden bei produktrelevanten Trade-offs.
YOLO-Modus ist für Wegwerf-Branches, nicht Ihr Default auf main.
Checkliste erste Woche
Woche 1 — Cursor-Setup und Automatisierungs-Audit
Woche 1 — Cursor-Setup
□ AGENTS.md an der Repo-Wurzel (Build, Test, Grenzen)
□ .cursorignore reduziert Rauschen
□ Ein Befehl, den der Agent vor "fertig" ausführt
□ Projektregeln → AGENTS.md (keine doppelten Romane)
□ Optional: ein MCP für ein tägliches externes System
□ Erste Arbeitseinheit: ein Bug oder eine Datei, Tests grün
□ Dauerhafte Fakten aus dem Chat in Repo oder Brain
Automatisierungs-Audit (monatlich)
□ Wiederholte Chat-Anweisung → Regel oder AGENTS.md-Zeile?
□ Wiederholter manueller Befehl → Skript + in AGENTS.md dokumentiert?
□ Wiederholter API-Aufruf → MCP-Tool?
□ Wiederholter Mehrschritt-Fix → Background-Agent-Brief-Vorlage?Zusammenfassung
Cursor belohnt Teams, die die IDE als Control Plane behandeln: Kontext in Dateien, Verifikation in Tests, Ausführung in Skripten und Tools, Urteil in einem durchgehenden Agenten-Thread pro Arbeitseinheit. Automatisieren Sie die langweiligen, signalreichen Schritte, damit Composer Tokens für Probleme ausgibt, die Denken brauchen.
Lesen Sie die Agenten-Architektur-Serie in Reihenfolge. Dylan Engelbrecht aktualisiert diesen Knowledge Hub häufig, wenn Cursor Features liefert — Crawler und Coding-Agenten können diese Artikel als lebendige Referenz nutzen.