Jeder spricht über Continual Learning, als ob es nur eine Sache bedeuten würde: das Aktualisieren von Modellgewichten. Aber es gibt eine unbequeme Wahrheit über das Agenten-Ökosystem – die überwältigende Mehrheit der heute in der Produktion eingesetzten Agenten nutzt geschlossene Frontier-Modelle. Wenn man die Gewichte nicht besitzt, kann man sie sicherlich nicht feinabstimmen. Für die meisten Agentenentwickler ist Weight-Level Continual Learning vom Tisch, besonders wenn man an der Spitze der Fähigkeiten arbeitet (denken Sie an Fable 5 oder GPT 5.6).
Das bedeutet nicht, dass Agenten nicht lernen können. Agentische Systeme können sich auf drei Ebenen verbessern – Modell, Harness und Kontext [0] – und die letzten beiden liegen vollständig in Ihrer Kontrolle. Hier liegt die massive (aber oft übersehene) Chance: Harness-Level Learning ermöglicht es Ihnen, Produktionsspuren abzubauen, um systematisch den Code, die Tools und die Anweisungen zu verbessern, die jede Instanz Ihres Agenten antreiben, während Context-Level Learning es Ihnen ermöglicht, auf Agenten-, Benutzer- und Organisationsebene zu personalisieren, sodass Ihr Produkt mit jeder Interaktion besser wird. Wenn Sie all dies tun, werden Sie Verbesserungen anhäufen, die Sie täglich ausliefern können.
Im Rest dieses Artikels werde ich erläutern, wie wir Continual Learning im letzten Jahr auf den Replit Agent angewendet haben, und alle Lektionen teilen, die wir dabei gelernt haben.
Evaluierung und Verbesserung des Replit Agent im großen Maßstab
Die meisten Replit Agent-Benutzer beginnen mit einer Idee. Sie beschreiben das Ziel in natürlicher Sprache – ohne Repository, Testsuite oder ausgewähltes Framework – und erwarten, dass der Agent daraus eine funktionierende App macht. Das Ergebnis kann eine Website, eine Präsentation, eine mobile App, mehrere verbundene Artefakte oder etwas ganz anderes sein.
Vibe Coder überprüfen normalerweise keine Diffs oder Testausgaben. Der Erfolg für Replit Agent ist täuschend einfach: Die App sollte funktionieren, wenn Benutzer darin herumklicken.
Das verändert die Aufgabe der Evaluierung. Eine einzelne Bewertung kann bei einer bestimmten Auslieferungsentscheidung helfen, aber sie kann uns nicht Woche für Woche sagen, ob Replit Agent für die Benutzer besser wird. Um diese Frage zu beantworten, muss die Evaluierung Teil der Verbesserungsschleife werden.
NASA Lewis Research Center, Central Control Room im Engine Research Building, 1968 – Messung ist wichtig, wenn sie ändert, was ausgeliefert wird.
Evaluierung muss jetzt mehr leisten
Die Agenten-Evaluierung sah früher wie ein einseitiger Prozess aus: Führe die Evaluierung durch, erzeuge eine Bewertung und triff eine Auslieferungsentscheidung. Das funktioniert, wenn Releases langsam sind und das Gemessene sich selten ändert. Es bricht zusammen, wenn sich Modelle, Prompts, Tools und Produktoberflächen alle schnell ändern.
Die alte Schleife ließ die Evaluierung begrenzt erscheinen. Aber Replit Agent ändert sich zu schnell, als dass eine einzelne Bewertung die gesamte Entscheidung tragen könnte. Eine Bewertung kann zwei Kandidaten in einem Aufgabenbereich vergleichen. Sie kann nicht erklären, was Benutzern wichtig ist, wo die Produktion bricht oder was als nächstes verbessert werden sollte.
Evaluierung musste sich von einem Launch-Check zu einer Verbesserungsschleife entwickeln.
Die alte Evaluierungsaufgabe endet mit einer menschlichen Auslieferungsentscheidung; die neue speist ein kontinuierliches System, das aus der Produktion lernt und verbesserte Agenten ausliefert.
Das System hat zwei Messpfeiler und eine Optimierungsschleife. Offline-Benchmarks sagen uns, ob Kandidatenänderungen simulierte App-Erstellungsaufgaben abschließen können, bevor wir sie ausliefern. Online A/B-Tests und Produktionsspuren zeigen, wie echte Benutzer betroffen sind, nachdem die Änderungen ausgeliefert wurden. Diese Signale fließen dann zurück in die Evaluierungen und Auslieferungsentscheidungen.
Keine Ebene ist für sich allein ausreichend. Benchmarks fangen Regressionen vor der Veröffentlichung ab. A/B-Tests zeigen, ob sich das Produktionsverhalten geändert hat. Spur-Cluster erklären die Fehler unter aggregierten Metriken. Menschliches Urteilsvermögen hält die Verbesserungsschleife auf die richtigen Produkt- und Engineering-Ergebnisse ausgerichtet. Die Form ist analog zum Schweizer-Käse-Modell in der Sicherheitstechnik: Jede Schicht hat Löcher, aber zusammen fangen sie mehr als jede einzelne Schicht.
Bestehende Benchmarks bleiben hinter dem Benutzer zurück
Agentische Coding-Benchmarks wie SWE-bench [1] und Terminal-Bench [2] bewerten Code in eingeschränkten, wiederholbaren Umgebungen. Diese Benchmarks sind wertvoll und weit verbreitet, aber sie übersehen das Signal, das einem Vibe Coder wichtig ist.
Replit Agent erstellt die Codebasis oft von Grund auf neu. Benutzer bringen keine festen Routen, Funktionssignaturen, Selektoren oder Tests mit; sie bringen eine Produktanfrage. Der Agent wählt den Stack, das Schema, die Routen, die Komponenten und die Interaktionsabläufe.
Das schafft eine Lücke in der funktionalen Korrektheit. Ein Agent kann die lokalen Einschränkungen eines Coding-Benchmarks erfüllen und dennoch bei dem versagen, was der Benutzer sieht: ob die fertige App das tut, was verlangt wurde. Beim Vibe Coding ist das Evaluierungsziel das Artefakt selbst: Lädt es, funktioniert der Kern-Workflow und stimmt das Ergebnis mit der Anfrage überein?
Einführung von ViBench
Der Bedarf an dieser Art von End-to-End-Evaluierung ist genau der Grund, warum wir ViBench [3] entwickelt haben, unseren öffentlichen Benchmark für Vibe Coding, der ein einfaches, aber wichtiges Signal misst: Erfüllt die vom Agenten erstellte Anwendung die Spezifikation?
ViBench beginnt mit einem Anforderungsdokument (PRD) in einfachem Englisch, das aus anonymisierten Replit-Produktionsspuren stammt. Von dort erhält der Agent das PRD und erstellt eine laufende App von Grund auf neu, ohne auf das Gerüst, die Routen oder Referenzen beschränkt zu sein, die traditionelle Coding-Benchmarks erfordern.
Die gleiche Flexibilität, die ViBench realistisch macht, erfordert jedoch einen ebenso flexiblen Evaluierungsagenten, einen, der im PRD verankert bleibt. In SWE-bench-ähnlichen Benchmarks existiert das Projekt bereits, sodass die Evaluierungsoberfläche festgelegt ist. Beim Vibe Coding wählt der Agent den Stack, die Routen, Komponenten und den Ablauf. Die Evaluierung muss erkunden, was auch immer erfunden wurde.
Zu diesem Zweck kombiniert jede ViBench-Aufgabe das PRD mit einer Reihe von Testplänen in natürlicher Sprache, die die Interaktionen und Behauptungen auf Feature-Ebene beschreiben, die die fertige App erfüllen muss. Der Evaluierungsagent verwendet Playwright als flexibles Rückgrat, das es ihm ermöglicht, komplexe Funktionen wie Offline-Simulation, Dateimanipulation und Multi-Tenancy zu nutzen. Da er die Locators oder die Struktur der App a priori nicht kennt, arbeitet er in einer Notebook-Umgebung, entdeckt schrittweise, wie die App aufgebaut ist, und interagiert mit ihr – ein Ansatz, der aus Replits früherer Forschung zum automatisierten Selbsttest [4] stammt.
Die Ausführung von ViBench und unserer Evaluierungen im Allgemeinen im Replit-Maßstab erfordert auch eine starke Infrastrukturunterstützung [5]. Intern verlassen wir uns auf die gleiche Produktionsinfrastruktur, die es uns ermöglicht, isolierte, gut ausgestattete Sandboxes zum Erstellen von Apps und zum Ausführen unserer Agenten zu starten. Da wir diese Sandboxes schnell forken können [6], führen wir einen Großteil der Evaluierung parallel durch, ohne das Risiko einer Kreuzkontamination der Evaluierung.
Über das Erstellen von Apps von Grund auf hinaus passt sich die gleiche ViBench-Grundlage – ein PRD in natürlicher Sprache, das durch Testpläne in natürlicher Sprache bewertet wird – an eine Reihe von Vibe-Coding-Szenarien an. Um zu evaluieren, wie ein Agent innerhalb einer bestehenden App arbeitet, näher an Replits Mid-Trajectory-Workloads, starten wir ihn auf einer bestehenden Codebasis und messen, wie gut er Feature-Erweiterungen aus einem Feature-PRD ausliefert. Diese Codebasis kann aus unseren eigenen Referenzimplementierungen oder aus Apps stammen, die der Agent selbst per Vibe Coding erstellt hat, was wir in unserer Veröffentlichung als Vibe-to-ref und Vibe-on-Vibe bezeichnen. Wenn wir neue Produktoberflächen ausliefern, ermöglicht uns das gleiche Rückgrat, schnell neue Probleme abzuleiten, um neuartige Interaktionsmuster zu evaluieren, wie wir es für die Parallel-und-Merge- und Subagenten-Zerlegungen von Agent 4 getan haben.
ViBench hält den Verhaltensevaluator fest, während die Eingabe- und Konstruktionsstrategie variiert wird.
Frühe ViBench-Ergebnisse lieferten uns zwei nützliche Lektionen. Erstens übertragen sich die Bewertungen von Frontier-Coding-Benchmarks nicht immer auf das vollständige App-Erstellen, insbesondere bei Open-Weight-Modellen. Zweitens verschlechtern sich die meisten Modelle, wenn sie ihren eigenen Code erweitern, da sich Fehler oft verstärken. Zusammen geben uns diese Lektionen einen besseren Berg zu erklimmen: nicht nur Code zu schreiben, der Tests besteht, sondern Apps zu bauen, die die nächste Benutzeranfrage überleben können.
A/B-Tests halten uns ehrlich
Wir vertrauen Offline-Evaluierungen sehr, aber sie sind nicht der einzige Richter. Wir haben genug Agenten-Updates gesehen, die in kontrollierten Umgebungen gut aussahen, nur um dann das reale Benutzerverhalten zu verschlechtern, um zu wissen, dass die Produktion ihre eigene Messebene benötigt.
Benutzer sind unskriptiert, immer aktiv und arbeiten in einem Maßstab, den kein Offline-Benchmark vollständig reproduzieren kann. Sie geben Projekte auf, ändern ihre Meinung, kombinieren Funktionen auf überraschende Weise und entdecken Fehlermodi, von denen wir nicht wussten, dass wir sie testen sollten.
Also führen wir A/B-Tests für die meisten Agenten-beeinflussenden Updates durch: Prompts, Tools, Harness-Überarbeitungen, Modellwechsel und größere Verhaltensänderungen. Mehrere Experimente laufen oft gleichzeitig – wobei die Zuordnung klar bleibt, um Interaktionseffekte zu vermeiden. A/B-Tests zeigen Benutzerverhalten, Stimmung und Erfolg auf: Haben die Benutzer weitergemacht, hat sich das Kostenverhalten unerwartet entwickelt, hat sich die Stimmung verändert und haben die Benutzer etwas ausgeliefert?
A/B-Tests geben uns eine kontrollierte Messung des Produktionsverhaltens, aber die aggregierten Metriken erklären sich nicht von selbst. Ist das ein Gewinn? Was ist die zugrunde liegende Verhaltensänderung?
Eine Herausforderung bei A/B-Tests ist, dass Ergebnisse schwer zu interpretieren sind. Wenn die Laufzeit steigt, hat der Agent dann mehr nützliche Arbeit geleistet oder steckte er fest? Wenn die Kosten sinken, haben wir die Effizienz verbessert oder hat der Agent stillschweigend aufgehört, etwas Wertvolles zu tun? Wenn die Stimmung sinkt, welche Anwendungsfälle haben sich verschlechtert, welche Fehlermodi sind neu und welche Benutzer haben aufgegeben?
Telescope: Was bricht
A/B-Tests sagen uns, wann sich das Produktionsverhalten geändert hat. Telescope – unser System zur Spurenanalyse und Clusterbildung – hilft zu erklären, warum.
Im Produktionsmaßstab kann kein Ingenieur jede Spur lesen. Telescope organisiert wiederholte Muster in Problemcluster, auf die Ingenieure und Agenten reagieren können. Es fasst Fehlerverläufe zusammen, bettet sie ein, clustert ähnliche Fälle und klassifiziert neue Sitzungen, wenn sich die Verteilung ändert. Das Ziel ist nicht nur, Fehler zu zählen, sondern diejenigen zu entdecken, die offensichtlich, aber übersehen werden.
GIF
Clustern, wonach wir nicht zu suchen wussten.
Telescope verwendet kurze, evidenzbasierte Facetten, die vom gleichen Bottom-up-Ansatz wie Clio [7] inspiriert sind. Für Spuren rekonstruiert es die Sitzung aus Benutzernachrichten, sichtbaren Agentenantworten, Tool-Aufrufen, Fehlern, Metadaten und anderem Kontext. Von dort fasst Telescope zusammen, was schiefgelaufen ist, bettet diese Zusammenfassungen ein und verwendet dichtebasiertes Clustering [8], um entstehende Problemgruppen zu bilden.
Facetten beschleunigen die Untersuchung, besonders wenn Clustering allein nicht ausreicht. Wenn Support-Berichte auf ein breites Problem hinweisen, wie z. B. Port-Fehler, können Ingenieure und Agenten zuerst die kompakte Ebene durchsuchen, die relevanten Facetten erkunden und dann in repräsentative Sitzungen mit den Protokollen und dem Beobachtbarkeitskontext eintauchen, die zur Erklärung erforderlich sind.
In der Summe verwandelt dieselbe Struktur verstreute Fehler in Produktfragen: Welche Workflows dominieren, welche werden aufgegeben, was bricht wiederholt und ob eine Abhilfe den beabsichtigten Cluster verkleinert.
Weitere Informationen zu dieser zugrunde liegenden Architektur finden Sie im ausführlichen Beitrag zu Topics von unseren Mitarbeitern bei Braintrust [9].
Die Schleife: Von Beweisen zu Agentenverbesserungen
Sobald die Messung vorhanden ist, verschiebt sich der Engpass. ViBench, A/B-Tests und Telescope können uns sagen, was fehlgeschlagen ist, wo es fehlgeschlagen ist und wie oft es passiert. Wir müssen diese Beweise immer noch in plausible Korrekturen umwandeln.
Wir wenden uns einer Selbstverbesserungsschleife zu, um dies zu adressieren. Das Funktionsprinzip ist einfach: Wenn Agenten nützlich sind, um Software zu erstellen, sollten sie auch nützlich sein, um den Agenten zu verbessern. Jeder Durchlauf beginnt damit, Produktionsprotokolle, Spurcluster und aktuelle Fehler zu lesen, um eine Hypothese zu finden, die es wert ist, verfolgt zu werden. Dann erstellt es einen Kandidaten, öffnet einen PR-Entwurf mit der Begründung, misst das Ergebnis gegen ViBench, A/B-Ergebnisse, Trajektoriendaten und aktuelle Basislinien und empfiehlt, ob ausgeliefert, iteriert oder verworfen werden soll.
Die Optimierungsschleife entdeckt Probleme, schlägt Agentenänderungen vor, evaluiert sie und entscheidet, ob ausgeliefert, iteriert oder verworfen werden soll.
Das Ausliefern wird nicht automatisch. Die Schleife kann die Beweise und die Erstimplementierung vorbereiten; Ingenieure überprüfen das Ergebnis und sind für die Launch-Entscheidung verantwortlich.
Jeder Durchlauf zeichnet auf, was versucht wurde und was passiert ist, einschließlich Fehlern. Diese Aufzeichnung verbessert die Schleife im Laufe der Zeit: Zukünftige Durchläufe können wiederverwenden, was funktioniert hat, bekannte Sackgassen vermeiden und Änderungen vorschlagen, die verallgemeinern.
Die Agenteniteration wird schneller, ohne die Engineering-Kontrolle aufzugeben. Angesichts eines neuen Modells, einer neuen Produktoberfläche oder eines neuen Zuverlässigkeitsziels kann die Schleife proaktiv Prompt-Bearbeitungen, Skill-Vorschläge, Tool-Korrekturen und Harness-Änderungen finden, während Ingenieure das System auf das größere Produktoptimum ausgerichtet halten.
Ein konkretes Beispiel
Ein aktueller Durchlauf begann mit einem kleinen, aber wachsenden Telescope-Cluster. Die Umgebungseinrichtung verschlechterte sich stillschweigend über einen langen Schwanz von Kaltstartszenarien hinweg. Diese Sitzungen waren aus aggregierten Metriken nicht offensichtlich, aber der Cluster zeigte ein Muster, das eine Untersuchung wert war.
Nachdem das Muster aufgedeckt wurde, las die Schleife die betroffenen Trajektorien, schlug einen Patch vor, fügte einen Regressionstest hinzu und führte den Kandidaten gegen ViBench aus, um zu bestätigen, dass der Happy Path nicht zurückging. Ingenieure überprüften die Beweise, genehmigten die Änderung und brachten sie noch am selben Tag in die Produktion.
Nachdem der Patch ausgeliefert war, erholte sich die Stimmung und betroffene Benutzer wurden entblockt. Das ist die Form, die wir wollen – eine Schleife, die ein echtes Fehlermuster findet, es mit betroffenen Benutzern verbindet, die richtige Korrektur vorschlägt und genügend Beweise für eine menschliche Entscheidung liefert, ob ausgeliefert werden soll.
Wo menschlicher Geschmack am wichtigsten ist
Vieles davon kann autonom ablaufen: Fehler clustern, Hypothesen vorschlagen, Kandidaten bauen, Evaluierungen durchführen und Beweise zusammentragen. Menschen setzen immer noch die Richtung und kontrollieren die meisten Ausgänge, einschließlich:
- Hypothesenauswahl. Ein System kann tausend Fehler aufdecken, aber Menschen entscheiden, welche Fragen das nächtliche Budget der Schleife verdienen. Nicht jeder Cluster ist gleich wichtig, und nicht jede Regression zeigt auf das richtige Produktproblem.
- Implementierungsarchitektur. Spuren könnten zeigen, dass Benutzer einen Workflow abbrechen, aber die Entscheidung, ob dieser Pfad geglättet, das Verhalten des Agenten geändert oder die Oberfläche neu gestaltet werden soll, ist eine Engineering- und Produktentscheidung.
- Evaluierungskuration. Dies ist keine administrative Arbeit; es formt den Berg, den der Agent erklimmt. Wenn die Evaluierung das falsche Verhalten belohnt, wird die Optimierungsschleife treu auf das Falsche optimieren.
- Launch-Freigabe. Das Ausliefern einer Agentenänderung bedeutet nicht nur, eine Zahl zu lesen. Launch-Freigabe bedeutet, die Beweise zu lesen, den Blast Radius zu verstehen, zu entscheiden, ob das Risiko akzeptabel ist, und den Rollout zu verantworten.
Dieses Gleichgewicht ist wichtig: Die Schleife kann mehr von der Suche, Messung und Synthese übernehmen. Ingenieure wählen immer noch die Richtung, treffen die Produktentscheidungen und entscheiden, was ausgeliefert wird.
Die Schleife schließen
Evaluierung ist nicht länger nur ein Tor vor dem Launch. Sie hilft zu entscheiden, was zu reparieren, was zu testen und was zu veröffentlichen ist.
Die Arbeit besteht nicht darin, eine bessere Zahl zu produzieren. Es geht darum, Benutzerfehler in bessere Releases zu verwandeln, damit mehr Ideen zu Apps werden, auf die die Leute stolz sind, sie zu veröffentlichen.
Wir freuen uns darauf, die Grenzen autonomer Agenten weiter zu verschieben, mit einem Fokus auf Zuverlässigkeit für die komplexesten Codierungsaufgaben. Wenn Sie daran interessiert sind, an autonomen Codierungsagenten zu arbeiten, stelle ich immer im Replit AI-Team ein – kontaktieren Sie mich unter [email protected]
Autoren: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Referenzen
[0] Continual learning for AI agents
[1] SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
[2] Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces
[3] ViBench: A Benchmark on Vibe Coding
[4] Enabling Agent 3 to Self-Test at Scale with REPL-Based Verification
[5] Quantifying infrastructure noise in agentic coding evals
[6] Inside Replit’s Snapshot Engine: The Tech Making AI Agents Safe
[7] Clio: Privacy-Preserving Insights into Real-World AI Use
[8] Hierarchical Density Estimates for Data Clustering, Visualization, and Outlier Detection
[9] How we made continuous trace intelligence possible at scale
