Wie wir unsere Umgebung für Cloud-Agenten eingerichtet haben
Als wir beschlossen, Cloud-Agenten mit Computern auszustatten, damit sie ihre Änderungen testen können, mussten wir zunächst sicherstellen, dass sie dies in unserer eigenen Codebasis zuverlässig tun können.
Bei der Einrichtung unseres Monorepos für Cloud-Agenten haben wir gelernt: Die Entwicklungsumgebung ist ein eigenständiges Produkt – mit Agenten als Benutzern. Cloud muss der lokalen Entwicklung entsprechen, das Repository muss so verständlich sein, dass Agenten Code ohne internes Wissen ausführen und testen können, und die Umgebung muss mit den Veränderungen der Codebasis Schritt halten.
Der Aufbau dieser Umgebung hat unsere Arbeitsweise verändert. Im Dezember verfassten Cloud-Agenten etwa jede zehnte PR, die in das Cursor-Monorepo gemergt wurde. Heute schreiben sie mehr als die Hälfte.
7-day rolling share of merged PRs from cloud agents
Cloud-Umgebung an die lokale Entwicklung anpassen
Der erste Schritt, damit Cloud-Agenten in unserem Repository gut funktionieren, bestand darin, unser Repository in einer Cloud-VM zuverlässig zum Laufen zu bringen. Diese Phase kennt jeder Entwickler, der zum ersten Mal eine Remote-Entwicklungsumgebung eingerichtet hat.
Die meisten Cursor-Entwickler arbeiten lokal auf Macs, unsere Cloud-VMs laufen jedoch unter Linux. Daher mussten wir verschiedene Entwicklungstools und Setup-Skripte plattformunabhängig gestalten, damit sie auf Ubuntu-VMs funktionieren. Wir haben wichtige Entwicklungsabhängigkeiten zu einem von Cursor definierten Dockerfile hinzugefügt, das als Basis-Image für Cloud-Agenten dient.
Außerdem haben wir gemeinsam mit unserem Sicherheitsteam Sicherheitsfunktionen für Cloud-Agenten entwickelt, damit Benutzer erforderliche Secrets bedenkenlos in die Umgebung des Agenten einfügen können. Dazu gehören Einschränkungen für ausgehenden Netzwerkverkehr, eingeschränkter und über Proxys vermittelter Zugriff auf Git-Remotes, das Scannen von Secrets in Commits und Commit-Nachrichten sowie die Schwärzung von Secrets in Tool-Ergebnissen. Dadurch kann der Agent keine Secret-Werte lesen, selbst wenn er es versucht.
Eine einfachere Oberfläche für Agenten
Auch nachdem unser Dev-Setup auf Ubuntu-VMs funktionierte, taten sich Agenten noch immer schwer damit, unseren Code auszuführen. Das war nicht überraschend, denn unsere Entwicklererfahrung war unübersichtlich und erforderte, zahlreiche Build-Befehle, Build-Flags und Hilfsskripte zu lernen und sich zu merken.
Wir erstellten Skills für das Erstellen und Ausführen vieler Teile des Systems, aber das half nur begrenzt. Skills können die richtigen Befehle dokumentieren, doch die Befehle selbst waren kompliziert und voller Fallstricke.
Um diese Komplexität zu reduzieren, entwickelten wir eine CLI namens anydev, mit der Agenten alle Services starten können. Auch gängige Hilfsskripte führen wir über anydev aus und statteten anydev mit mehreren --help-Menüs aus, die die Nutzung der einzelnen Unterbefehle erklären. anydev verfügt außerdem über einen Supervisor-Prozess, der lang laufende Build-Befehle überwacht und neu startet, sodass das Modell diese Verantwortung nicht mehr übernehmen muss.
anydev vereinfachte die Entwicklungserfahrung so weit, dass Agenten ihren Code zuverlässig ausführen konnten. Skills halfen dabei, die Nutzung zu dokumentieren, doch die größere Veränderung bestand darin, dass Agenten nicht mehr mit speziellen mehrstufigen Build-Befehlen jonglieren, versteckte Fallstricke umgehen oder lang laufende Prozesse beaufsichtigen mussten.
Ab diesem Zeitpunkt boten Cloud-Agenten, jeweils mit ihrem eigenen Computer, gegenüber lokalen Agenten einen echten Mehrwert. Mit Computer-Use, ihrem recordScreen-Tool und einer funktionierenden Entwicklungsumgebung konnten Agenten ihre Änderungen nun End-to-End testen und dem Nutzer die Korrektheit ihrer Arbeit nachweisen.
Sie konnten außerdem von Agenten aufgezeichnete Demos in Slack teilen, wenn jemand einen Bugbericht behoben hatte, oder in einer PR, wenn sie eine Änderung erstellt hatten. Bei vielen Aufgaben konnten Ingenieure Code von Cloud-Agenten nun bedenkenlos mergen und deployen, ohne den Branch jemals lokal auszuchecken.
Eine selbstheilende Umgebung
Die Umgebung eines Agent verändert sich ständig. Um sie betriebsbereit zu halten, müssen daher fortlaufend seine Ausführung und Zugriffsmöglichkeiten angepasst werden.
Um beeinträchtigte Umgebungen zu diagnostizieren und wiederherzustellen, sobald Fehler auftreten, haben wir Cursor Cloud MCP entwickelt. Wir haben uns für MCP entschieden, weil es uns dynamisch auffindbare Tools mit Schnittstellen bietet, die wir ändern können, ohne den Agent Loop neu erstellen zu müssen. Cloud-Agenten nutzen es, um ihre eigene Umgebung auf Setup-Fehler, Richtlinien für ausgehenden Netzwerkverkehr, geänderte Secrets und mehr zu prüfen. So können sie Probleme diagnostizieren und beheben, sobald sie auftreten, und beeinträchtigte Umgebungen schneller wiederherstellen.
Mit Cursor Cloud MCP haben wir eine Automatisierung namens Cloud Doctor eingerichtet, die regelmäßig nach Fehlern sucht, sich merkt, welche Fehler möglicherweise vorübergehend oder relevant sind, Analysen der eigentlichen Ursache durchführt und PRs öffnen kann, um Probleme mit hoher Sicherheit zu beheben.
Verbesserung der Agent-Erfahrung
Selbst in einer stabilen Umgebung wählen Agenten manchmal lange oder umständliche Wege, um ihre Änderungen zu verifizieren. Sie nutzen möglicherweise den falschen Skill, stoßen in der VM auf vermeidbare Probleme oder folgen Workflows, die länger dauern als nötig.
Auch hier nutzen wir Cursor Cloud MCP. Cloud-Doctor-Agenten analysieren Traces, um herauszufinden, wo ein anderer Agent falsch abgebogen ist, welche Skills oder Befehle irreführend waren und welche Workflows systematisch langsam sind. Auf Grundlage dieser Befunde überarbeitet Cloud Doctor den Skill, vereinfacht den Weg oder ändert die Umgebung, damit der nächste Agent es leichter hat.
Dieser Kreislauf verbessert kontinuierlich die Entwicklererfahrung mit den Agenten selbst. Wenn die Umgebung stabil und selbstheilend ist, laufen Agenten zuverlässig und Entwickler vertrauen Cloud-Agenten wichtigere Aufgaben an.
Dadurch konnten wir die interne Nutzung von Cloud-Agenten skalieren, sodass sie inzwischen den Großteil des Codes erstellen, den wir ausliefern.
Ihre Umgebung für Cloud-Agenten vorbereiten
Wie produktiv Cloud-Agenten sind, hängt maßgeblich von der Umgebung ab. Um herauszufinden, ob Ihre Codebasis bereit ist, beantworten Sie zunächst drei Fragen:
- Haben Agenten Zugriff auf dieselben Tools und Daten wie Entwickler?
- Können Agenten Skills finden, die dokumentieren, wie Ihre Entwickler tatsächlich arbeiten?
- Können Agenten zentrale Workflows testen und verifizieren?
Wenn Sie Hilfe bei der Vorbereitung Ihrer Umgebung benötigen, nehmen Sie bitte Kontakt mit uns auf.
Oder lesen Sie, wie Faire mit Cloud-Agenten den wöchentlichen PR-Durchsatz verdoppelte.
