Cursor-Hintergrundagenten: mehr davon parallel laufen lassen

Zuerst der Name: Cursors Docs sagen, "Cloud Agents hießen früher Background Agents." Gleiches Produkt, neuer Name — wir verwenden beide in diesem Guide. [3] Ein Hintergrundagent ist ein Coding-Agent, der über eine lange Zeitspanne fern von deinem Laptop läuft: Die Aufgabe wandert in die Cloud, und ein Agent trägt sie ohne Unterbrechung von Anfang bis Ende, und meldet sich dann mit dem Nachweis zurück, dass die Arbeit erledigt ist. [1]

Jeder läuft auf seiner eigenen dedizierten virtuellen Maschine mit einer vollständigen Entwicklungsumgebung — deinem Repository, Abhängigkeiten, Secrets und Netzwerkzugang. Der Agent plant die Aufgabe, bearbeitet Code, führt Befehle aus und testet seine Arbeit über Minuten oder Stunden, und läuft weiter, egal ob dein Rechner überhaupt online ist. [1] Die VM ist gesandboxt und von deinem lokalen Rechner isoliert, und du bestimmst, welche Repositories, Secrets und welchen Netzwerkzugang eine Umgebung erhält. [1]

Wenn die Arbeit fertig ist, öffnet der Agent einen Pull Request — und zeigt seine Arbeit. Während er läuft, hängt er Screenshots, Videos und Log-Referenzen an den PR, damit du Änderungen validieren kannst, ohne den Branch auszuchecken. [1] Cloud Agents können sogar ihren eigenen Desktop und Browser steuern und sich durch UI-Abläufe klicken, um zu verifizieren, dass das Gebaute tatsächlich funktioniert, bevor sie pushen. [2]

Du kannst einen Cursor Cloud Agent starten, von wo aus du schon arbeitest: [3]

Automations sind separat dokumentiert. [4] Bevor jemand einen Agenten aus einem Repository starten kann, verbindet ein Cursor-Kontoadmin die Quellcodeverwaltung: GitHub (Cloud und Enterprise Server), GitLab (Cloud und Self-Hosted), Bitbucket Cloud oder Azure DevOps. [3]

Das Hauptfeature wird leicht übersehen: Du kannst so viele Agenten wie du willst parallel laufen lassen, und keiner von ihnen braucht deinen lokalen Rechner verbunden. [3] Parallel ist der ganze Punkt. Ein einzelner Hintergrundagent ist eine nette Annehmlichkeit; fünf gleichzeitig sind ein Sprung in dem, was pro Woche ausgeliefert wird.

Aber parallele Agenten ändern, was der Engpass ist. Die Agenten können rund um die Uhr coden — was sie nicht können, ist zu entscheiden, was es wert ist getan zu werden, in welcher Reihenfolge, und ob die Arbeit tatsächlich fertig ist. Jeder Agent, den du hinzufügst, beansprucht mehr deiner Aufmerksamkeit genau in den Momenten, in denen du am beschäftigtsten bist: die nächste Aufgabe zu umreißen, einen gerade fertiggestellten PR zu reviewen, einen abgedrifteten Agenten zu entdecken. Lässt man genug davon unverwaltet laufen, verbringt man den Tag damit, zwischen Dashboards zu pendeln, statt das Produkt voranzutreiben.

Es gibt einen zweiten, leiseren Fehlermodus: Qualität. Ein Agent, der eine Stunde unbeaufsichtigt läuft, baut bei einer vagen Anweisung gern wunderschön das Falsche. Mit einem Agenten merkst du das. Mit zehn werden vage Anweisungen still und leise zu zehn falschen Pull Requests.

Und diese falschen Pull Requests kosten echtes Geld. "Cloud Agents werden zum API-Preis des gewählten Modells abgerechnet … ein größeres Kontextfenster kann Token-Nutzung und Kosten erhöhen." [3] Parallelität multipliziert diese Rechnung — eine vage Story ist also nicht nur verschwendete Review-Zeit, sondern Tokens, die mehrfach für das Falsche ausgegeben werden.

Die Fähigkeit, auf die es bei Hintergrundagenten ankommt, ist also nicht, sie zu starten — das hat Cursor auf eine Erwähnung reduziert. Es ist, sie zu versorgen. Die Teams, die am meisten aus parallelen Agenten herausholen, sind die, die Arbeit schreiben können, die scharf genug ist, um unbeaufsichtigt zu laufen, und die jeden laufenden Agenten im Blick behalten, ohne über einem von ihnen zu hängen. Wie viele du tatsächlich im Griff behalten kannst, ist vor allem eine Frage der Review-Kapazität.

Eine Anmerkung zur letzten Praktik: Multi-Repo-Umgebungen lassen einen einzelnen Agenten über getrennte Frontend-, Backend-, Infrastruktur- oder Shared-Library-Repositories hinweg arbeiten und in jedem geänderten Repo einen Pull Request öffnen. [3] Aber auch die beste Multi-Repo-Umgebung arbeitet immer nur eine Aufgabe nach der anderen ab — zu entscheiden, wie die architektonische Story über all diese Repos hinweg aussehen soll, bleibt deine Aufgabe. Wie man sie schreibt, steht in unserem Guide zu Storys für Coding-Agenten.

Berechtigte Frage. Du kannst ein Linear-Issue @Cursor zuweisen und ein Cloud Agent nimmt es sich vor, [5] und Automations können Agenten aus GitHub-, Linear- oder Slack-Events starten. [4] Cursor ist ein sehr guter Motor. Was es nicht tut, ist zu entscheiden, was läuft oder in welcher Reihenfolge — es führt aus, welches Issue du ihm auch gibst, wann du es gibst.

Das ist die Lücke, die Aerunit füllt. Denk an Cursor als den Motor und Aerunit als den Dispatcher: Es macht das Issue laufwürdig, verschickt es, wenn es bereit ist zu laufen, und schickt Review-Befunde an dieselbe Agent-Session zurück zur Behebung.

Zusätzlich zu Cursors eigener Linear-Integration und Automations fügt Aerunit vier Dinge hinzu:

• Es schreibt die Storys. Du beschreibst die Arbeit; Aerunit liest jedes Repository, das die Story betrifft, und schlägt Linear-Issues mit Umfang, Abnahmekriterien und Nicht-Zielen vor — eine Hauptstory plus ein Sub-Issue pro Repo bei repoübergreifender Arbeit.
• Es dispatcht in Abhängigkeitsreihenfolge. Aerunit folgt Linears Blocks-/Blocked-by-Relationen, sodass beim Mergen eines PRs die von ihm blockierten Issues automatisch an Cursor Cloud Agents gehen — kein manuelles Verteilen.
• Es reviewt jeden PR. Wenn ein Agent einen Pull Request öffnet, führt Aerunit ein Code-Review durch und schickt die Befunde an dieselbe Agent-Session zurück zur Behebung — sodass der Agent, der den Code geschrieben hat, ihn auch repariert.
• Es zeigt die ganze Flotte. Eine Liste aller laufenden Cloud-Agent-Sessions, jede mit ihrem Linear-Issue verknüpft — mehrere gleichzeitig anschreiben, fertige archivieren.