CoreWeave erklärt, wie ARIA, der Forschungsagent in W&B, so gebaut wurde, dass er den Chat überdauert

Vom Kontext ausgehen, bei Artefakten ankommen

Die ursprüngliche Idee sei gewesen, einen leistungsfähigen Agenten mit Werkzeugzugriff direkt in W&B zu platzieren, wo Runs, Metriken, Artefakte und Produktions-Traces bereits liegen, so CoreWeave. Das Team erwartete, dass der Kontext der wichtigste Vorteil sein würde: Forschende sollen nicht erst ein halbes Projekt in einen Prompt kopieren müssen, bevor ein Agent helfen kann.

Der Beitrag schildert einen typischen Fall: Ein Training ist langsamer geworden, und die Forschenden haben bereits einen gefilterten Workspace, mehrere verdächtige Runs ausgewählt und eine Metrik, die sich nach einem Konfigurationsupdate verändert hat. Ein allgemeiner Assistent bräuchte all das per Copy-and-paste. ARIA hingegen startet laut CoreWeave mit dem W&B-Kontext rund um die Frage. Der Agent kann Experimentdaten und Produktions-Traces prüfen, Hinweisen über mehrere Runs hinweg folgen und einen Workspace oder Report erstellen, der das Ergebnis zusammen mit den zugrunde liegenden Daten festhält.

Diese Dauerhaftigkeit habe die Sicht des Teams darauf verändert, was eine gute Antwort ausmacht. Ein Absatz, der mit dem Gespräch verschwindet, lasse sich schwer prüfen und helfe Kolleginnen und Kollegen, die nicht dabei waren, kaum. Ein Report lasse sich teilen, ein Workspace könne sich aktualisieren, sobald neue Runs eintreffen. Der Autor schreibt, die Artefakte seien „Teil der Antwort“ geworden und nicht bloß eine schönere Darstellungsform. So könne eine andere Forscherin einer Schlussfolgerung widersprechen und auf Basis derselben Belege weiterarbeiten.

Die Entscheidungsgewalt bleibt bei den Forschenden

Die Arbeit innerhalb von W&B zwang das Team auch dazu festzulegen, was der Agent eigenständig tun darf. CoreWeave unterscheidet drei Arten von Schritten: Das Lesen ausgewählter Runs gehört zur Untersuchung, das Erstellen eines Reports verändert ein gemeinsames Projekt, und das Starten eines Experiments verbraucht echte Rechenleistung.

ARIA kann die mühsame Arbeit rund um diese Entscheidungen übernehmen, etwa ein Folgeexperiment vorbereiten. Doch in den Worten des Beitrags gilt: „Dass das Modell selbstsicher klingt, darf nicht der Grund sein, ihm mehr Rechte einzuräumen.“ Forschende geben folgenreiche Aktionen weiterhin frei, und der Kreislauf vom Beobachten eines Ergebnisses bis zum Start des nächsten Experiments schließt sich erst mit ihrer Zustimmung.

Dauerhafte Turns und eine geteilte Architektur

Die erste Agentenschleife war simpel: Anfrage entgegennehmen, ein Werkzeug auswählen, das Ergebnis prüfen und weitermachen, bis eine Antwort vorliegt. Ein Harness stellte Prompt und Projektkontext zusammen, machte die erlaubten Werkzeuge verfügbar, führte den Verlauf und setzte Limits durch. Reale Untersuchungen machten das unübersichtlich. Eine Frage wie „Warum sind die Runs langsamer geworden?“ kann von der gerade angezeigten Seite, ihren Filtern, einer bestimmten Metrik und einem Artefakt aus einem früheren Experiment abhängen. CoreWeave wandelte diesen Seitenzustand in strukturierten Kontext um und hält zugleich die Einschränkung fest: Eine gefilterte Seite sei ein nützlicher Ausgangspunkt, aber kein Beleg dafür, dass der Agent das ganze Projekt gesehen hat.

Auch die Aufgaben wurden länger. ARIA prüft womöglich Hunderte Runs, erzeugt eine Visualisierung, wartet auf Remote-Arbeit, erholt sich von einem fehlgeschlagenen Werkzeugaufruf oder arbeitet weiter, nachdem die Forschenden den Browser geschlossen haben. Der Produktionsdienst speichert deshalb jede Nutzeranfrage samt der folgenden Agentenarbeit als dauerhaften Turn. Laut CoreWeave umfasst ein Turn:

• den Prompt und einen rekonstruierbaren Verlauf
• den konfigurierten Agenten und die Umgebung
• den Zustand, der zum Fortsetzen nötig ist

Turns bilden einen Baum, sodass Forschende zu einem früheren Punkt zurückkehren und die Arbeit in eine andere Richtung lenken können. Ein Worker übernimmt einen Turn und protokolliert den Fortschritt, die aktive Arbeit läuft in einer isolierten Sandbox, deren Dateien und Zustand als Snapshot gesichert und wiederhergestellt werden können. Wie es im Beitrag heißt: „Das Schließen des Browsers entfernt den Betrachter, nicht die Arbeit.“

Die Zuständigkeiten wurden bewusst getrennt. Der ARIA-Dienst verantwortet Autorisierung, Persistenz, Verteilung und Fortschritt. Der Agent entscheidet, was als Nächstes passiert, die Umgebung stellt Zustand und Werkzeuge bereit, und die Sandbox isoliert die Ausführung. Ein gemeinsamer Treiber koordiniert einen Turn über diese Bausteine hinweg. Nach Angaben von CoreWeave haben Fehler dadurch eine klarere Adresse: Eine falsche Werkzeugwahl verweist auf das Verhalten des Agenten, verlorener Worker-Zustand auf die Wiederherstellung, und eine Sandbox, die vor Beginn der Aufgabe ausfällt, zählt nicht als falsche Antwort.

Produktionsfehler werden zu Evaluierungen

Zunächst ging das Team mit Fehlern so um, dass es den Trace las und eine sauberere Evaluierungsaufgabe schrieb. Das habe, so CoreWeave, oft genau den Grund beseitigt, warum der Fehler aufgetreten war, weil Seitenkontext, frühere Turns oder Umgebungszustand verloren gingen. Das Ergebnis war ein Test einer vereinfachten Geschichte statt dessen, was Nutzer tatsächlich erlebt hatten.

Der dauerhafte Turn biete einen besseren Ausgangspunkt, da er Anfrage, Verlauf, Konfiguration und einen Verweis auf wiederherstellbaren Zustand bereits enthält. Derselbe Treiber, den der Produktions-Worker nutzt, kann eine kontrollierte Aufgabe offline ausführen. So bleibt der evaluierte Kandidat nahe an der Version, die tatsächlich ausgeliefert werden könnte, und ist keine reine Benchmark-Variante.

Zwei weitere W&B-Bausteine unterstützen das. Weave, das Observability- und Evaluierungssystem des Unternehmens für Agenten und LLM-Anwendungen, zeichnet Agentenoperationen als Calls auf und verknüpft sie zu Traces. Damit kann das Team ein Evaluierungsergebnis bis zu den dahinterliegenden Modell- und Werkzeugaufrufen zurückverfolgen. W&B Agent Factory, kurz WBAF, liefert die ARIA-spezifische Forschungsumgebung: Es importiert eine produktionsnahe ARIA-Konfiguration und führt die Aufgaben, Umgebungen und Scorer aus, die zum Testen einer vorgeschlagenen Änderung nötig sind. Der ARIA-Dienst bleibt die maßgebliche Quelle für die Produktion, und eine Änderung, die gut aussieht, durchläuft trotzdem die normale Produktionsprüfung. WBAF liefert kein zweites ARIA aus.

Was das für Nutzer bedeutet

Für W&B-Nutzer deutet der Beitrag auf einen Agenten hin, dessen Ergebnisse dafür gedacht sind, von Kolleginnen und Kollegen geprüft, geteilt und fortgeführt zu werden. Bevor gemeinsame Projekte verändert oder Rechenleistung verbraucht wird, ist eine Freigabe erforderlich. Lange Untersuchungen sind so ausgelegt, dass sie einen geschlossenen Browser-Tab überstehen.

CoreWeave nennt auch eine Grenze. Das System könne Gesprächs- und Sandbox-Zustand erhalten, doch das umgebende W&B-Projekt verändere sich ständig: Neue Runs kommen hinzu, Artefakte wandern, und Dienste liefern unterschiedliche Daten. Ein erneut abgespielter Turn könne die Welt um sich herum deshalb nicht vollständig einfrieren.