Als wir vor einem Jahr erstmals Cloud-Agenten eingeführt haben, wirkten sie wie eine naheliegende Erweiterung lokaler Agenten. Seitdem haben sich die Fähigkeiten von Cloud-Agenten deutlich weiterentwickelt.

Cloud-Agenten laufen jetzt auf eigenen dedizierten virtuellen Maschinen, mit eigenen Umgebungen, Abhängigkeiten und Netzwerkzugriff. Sie können parallel arbeiten, unbeaufsichtigt laufen und längere Aufgaben übernehmen als ein lokaler Agent auf deinem Laptop.

Diese Fähigkeiten bringen Herausforderungen bei Umgebungs-Setup, Zuverlässigkeit und Orchestrierung mit sich, die deutlich weniger ins Gewicht fallen, wenn ein Agent auf deinem Laptop läuft.

In diesem Beitrag möchten wir die wichtigsten Erkenntnisse teilen, die wir beim Entwickeln von Cloud-Agenten gewonnen haben, und warum diese Arbeit immer weniger wie das Portieren eines lokalen Agenten auf einen Server aussieht und immer mehr wie der Aufbau einer Betriebsschicht darum herum."

#Die Entwicklungsumgebung ist das Produkt

Im letzten Jahr haben wir gelernt, dass der mit Abstand wichtigste Faktor für die Output-Qualität von Cloud-Agenten ist, sicherzustellen, dass sie über eine vollständige Entwicklungsumgebung verfügen – so wie ein Entwickler.

Lokal musst du darüber viel weniger nachdenken, weil lokale Agenten deine funktionierende Entwicklungsumgebung ganz automatisch von deinem Laptop übernehmen. In der Cloud musst du all das von Grund auf neu nachbilden, und es ist überraschend schwer zu erkennen, wenn das nicht perfekt gelungen ist.

Statt eines Absturzes oder einer Fehlermeldung ist der einzige Hinweis oft nur eine subtile Verschlechterung der Output-Qualität. Vielleicht bemerkst du es anfangs gar nicht, und wenn doch, führst du es womöglich auf das Modell zurück.

Aber immer wieder sind wir bei derselben Diagnose gelandet: Dem Cloud-Agent fehlt die Umgebung, die er braucht, um seine Arbeit auszuführen oder zu verifizieren. Vor einem Jahr war das noch weniger wichtig, weil Modelle ihre Umgebung ohnehin kaum nutzen konnten. Aber je intelligenter sie geworden sind, desto mehr ist das Umgebungs-Setup zum entscheidenden Faktor dafür geworden, ob sie ihr volles Potenzial ausschöpfen.

Heute erfordert der Weg zur „vollständigen Umgebung“ den Neuaufbau überraschend viel Infrastruktur:

• Bessere Tools für Nutzer, um die Agent-Umgebung zu erstellen
• Methoden, um Agent-VMs zwischen Nachrichten effizient in den Ruhezustand zu versetzen und wiederaufzunehmen
• Pipelines, mit denen sich VM-Images schnell und dauerhaft checkpointen, wiederherstellen und forken lassen
• Eng verzahnte Harness- und Client-Integrationen, damit sowohl Agenten als auch Menschen die Umgebung interpretieren und mit ihr interagieren können

Und je mehr Arbeit Cloud-Agenten übernehmen, desto mehr brauchen sie kontrollierten Netzwerkzugriff, um PRs zu erstellen, Abhängigkeiten herunterzuladen und Recherchen durchzuführen. Mit der Zeit haben wir im Grunde so etwas wie Enterprise-IT für Agenten aufgebaut – komplett mit Secret-Redaction, Netzwerkrichtlinien und Anmeldedatenverwaltung.

#Langlaufende Agenten brauchen dauerhafte Ausführung

Cloud-Agenten bringen eine andere Art von Zuverlässigkeitsherausforderung mit sich als lokale Agenten. Statt auf deinem Laptop um lokale Ressourcen zu konkurrieren, laufen Cloud-Agenten in ihren eigenen isolierten VMs. Dadurch können Entwickler leichter viele Agenten parallel ausführen und langlaufende Aufgaben delegieren, die oft Stunden statt Minuten dauern.

Allerdings macht die Ausführung in einer VM anfällig für Störungen wie Ausfälle von Inference-Providern, Pods, die ersetzt werden müssen, und EC2-Knoten, die ausfallen.

Wir haben mit dem Aufbau von Cloud-Agenten auf Basis einer Work-Stealing-Architektur begonnen, bei der Worker-Knoten Agenten übernehmen und in einer Schleife bis zum Abschluss ausführen konnten. Damit haben wir das, was lokal funktioniert, auf einen Server übertragen — und das Setup war fragil: Unsere frühe Beta der Cloud-Agenten erreichte oft nur eine Zuverlässigkeit von einer Neun.

Als Cloud-Agenten ausgereifter wurden, merkten wir, dass wir kurz davor waren, viele der Bausteine für dauerhafte Ausführung neu zu entwickeln, die Temporal bereits bereitstellt (z. B. Retry-Mechanismen, die Verteilung von Arbeit über mehrere Maschinen hinweg und Ausfallsicherheit bei Knotenausfällen). Deshalb sind wir stattdessen dorthin migriert.

Unser aktueller Agent Loop auf Temporal übersteht kurze Einbrüche bei der Inference-Zuverlässigkeit, die Hibernation und Wiederaufnahme von Pods sowie Ausführungen, die sich über Tage oder sogar Wochen erstrecken. Allein diese Migration hat uns auf mehr als zwei Neunen Zuverlässigkeit gebracht, und heute verarbeitet Temporal mehr als 50 Millionen Aktionen pro Tag über mehr als 7 Millionen eindeutige Workflows hinweg. Intern stammen inzwischen mehr als 40 % unserer PRs von Cloud-Agenten — Tendenz steigend.

Mit der Zeit haben wir gelernt, unsere Temporal-Workflows besser zu gestalten. Wir sind von „ewigen“ Agent-Workflows zu mehreren kürzeren übergegangen, die nach Abschluss einer einzelnen Aufgabe enden, was Versions-Upgrades vereinfacht. Außerdem haben wir Aktivitäten aufgeteilt, um Timeouts und Retries besser als asynchrone Tool-Aufrufe abzubilden, da Subagents und Ausfälle von Inference-Providern unsere zugrunde liegenden Annahmen verändert haben.

#Entkopplung von Agenten und Maschinen vom Unterhaltungszustand

Ein Cloud-Agent ist nicht mehr nur ein einzelner Loop, der auf einer Maschine läuft. Stattdessen kann ein Agent auf einer Maschine laufen, asynchrone Subagents auf mehrere Maschinen verteilt starten oder lokal beginnen und dann Arbeit an die Cloud delegieren. Ein Subagent kann seinen übergeordneten Agenten sogar überdauern oder auf einem völlig anderen Typ von Pod laufen.

Damit das funktioniert, hat es sich für uns bewährt, den Agent Loop, den Maschinenzustand und den Unterhaltungszustand als entkoppelte Komponenten zu behandeln. Da der Agent Loop in Temporal läuft und nicht auf der VM selbst, können wir Pod-Lebenszyklen unabhängig verwalten und Agenten auf verschiedenen Arten von Pods ausführen — einschließlich Optimierungen wie schreibgeschützten oder vorgewärmten VMs.

Für die Unterhaltung haben wir die Speicher- und Streaming-Schicht vom zentralen Agent-Workflow getrennt. Wir haben einen effizienten Append-only-Speichermechanismus entwickelt, der Aktualisierungen der Unterhaltung an Web- und Desktop-Clients streamt. Diese Schicht berücksichtigt Wiederholungsversuche, sodass der Client, wenn ein Schritt des Agent Loop nach dem Streamen einer teilweisen Ausgabe fehlschlägt und dann erneut ausgeführt wird, dies erkennen, seinen Stream zurücksetzen und die neuen Daten statt der alten anzeigen kann.

#Wissen, wann man sich besser zurücknimmt

Ein Cloud-Agent-Harness zu erstellen bedeutet, ständig neu abzuwägen, wie viel Verhalten deterministisch sein soll und wie viel dem Agent überlassen wird.

Anfangs haben wir dem Agent noch nicht besonders vertraut. Deshalb hat das Harness seine Arbeit nach jeder Aufgabe noch einmal überprüft, einen Commit erzwungen und gepusht. Als die Modelle besser wurden, haben wir begonnen, Logik aus dem Harness herauszunehmen und in Tools zu verlagern, die der Agent selbst steuert. Vor einem Jahr erforderten Multi-Repo-Setups noch fest im Harness codiertes Verhalten. Heute können wir dem Agent das Repo-Layout geben, Tools für Branches und PRs bereitstellen und ihn selbst entscheiden lassen, wie er die Arbeit erledigt.

Dasselbe ist bei CI Autofix passiert: Frühere Versionen unseres Cloud-Agent-Harnesses enthielten Logik, um Logs von fehlgeschlagenen Jobs abzurufen und sie in die VM zu schreiben. Heute geben wir dem Agent einfach Zugriff auf die GitHub CLI und schreiben große Ausgaben automatisch in Dateien, die er durchsuchen kann. Dadurch wurde auch die Benachrichtigung an den Agent deutlich einfacher, und wir gehen davon aus, dass sich dieser Trend fortsetzt.

Das Harness verschwindet also nicht, aber sein Inhalt verändert sich. Computer Use ist dafür gerade ein gutes Beispiel. Unser Cloud-Agent-Harness hat einen dedizierten Subagent-Typ für Computer Use, mit eigenem Model-Routing, benutzerdefiniertem Prompting und Bildschirmaufzeichnung. VNC und Chrome gehören zur Umgebung, die sich Parent-Agent und Subagent teilen. So kann der Parent sie auch direkt nutzen, zum Beispiel durch das Ausführen eines Playwright-Skripts. Wir verwenden dieses Gerüst, weil Modelle noch nicht ganz so weit sind, Computer Use allein zu bewältigen, aber der Agent steuert weiterhin, wann es aufgerufen wird.

Cloud-Agenten brauchen im Harness außerdem andere Arten von Prompts als lokale Agenten. Wir halten sie dazu an, autonomer zu handeln, weil die Kosten von Blockierungen deutlich höher sind. Lokal merkst du, wenn ein Agent anhält und auf eine Erlaubnis wartet, aber in der Cloud kann er dort stundenlang untätig bleiben, bevor du wieder nach ihm siehst.

#Selbstheilende Agent-Umgebungen

Mit Blick auf die Zukunft wollen wir die starre Wahl hinter uns lassen, den Agenten entweder an die Hand zu nehmen oder ihn einfach machen zu lassen. Besser ist es, dem Agenten Tools zu geben, mit denen er das System um sich herum verstehen kann.

Wir möchten, dass Cloud-Agenten erkennen und melden können, wenn Secrets fehlen, der Netzwerkzugriff blockiert ist oder ihre Umgebung sie anderweitig daran hindert, Fortschritte zu machen, und dann selbstheilend darauf reagieren können. In einem aktuellen Research-Blog haben wir über einen Weg gesprochen, dies zu erreichen, den wir „autoinstall“ nennen.

Cloud-Agenten haben sich allein in den letzten Monaten enorm verbessert, und wir erwarten, dass sich dieses Tempo weiter beschleunigt. Cursor Cloud-Agenten ermöglichen es Teams, diese breite Einsatzfläche zu nutzen, ohne die zugrunde liegende Infrastruktur erstellen oder warten zu müssen.