DigitalOcean Simulations testet KI-Agenten über ganze Gespräche statt über einzelne Antworten

Warum Tests mit Einzelantworten zu kurz greifen

DigitalOcean veranschaulicht das Problem mit einem Coding-Agenten, der gefragt wird, auf welche Python-Version man von 3.11 aus aktualisieren soll. Der Agent wählt aus dem Gedächtnis eine Version aus, nennt ein paar Änderungen aus den Release Notes und bezeichnet das Upgrade als unkompliziert. Laut DigitalOcean würde eine Single-Turn-Evaluation, die fragt, ob dies eine vernünftige Empfehlung ist, dies wahrscheinlich bestehen lassen.

Ein erfahrener menschlicher Entwickler, so das Unternehmen, arbeitet die Frage dagegen über mehrere Gesprächsrunden hinweg ab. Er prüft, welche Versionen aktuell unterstützt werden, legt die Optionen dar und überlässt dem Nutzer die Wahl. Anschließend ermittelt er, was zwischen Ausgangs- und Zielversion kaputtgeht, einschließlich der dazwischenliegenden Releases, und prüft den Code darauf. Nichts davon ist in einem einzelnen Prompt mit einer Antwort sichtbar. Simulations soll diese Lücke schließen.

Die vier Komponenten und zentrale Begriffe

DigitalOcean beschreibt eine Simulation als inszeniertes Gespräch, bei dem im hinteren Teil des Raums ein Bewerter sitzt. Vier Komponenten machen das möglich:

• Der Kandidat: das, was getestet wird. Das kann ein verwalteter Agent auf Harness Runtime sein, ein Modell, ein Dedicated-Inference-Deployment oder ein Inference Router, den die Simulation in einen Agenten einbettet.
• Das Szenario: eine Situation, die der Nutzersimulator durchspielt, samt dem, was der Nutzer will, wer er ist, was der Agent erledigen soll und wie viele Runden erlaubt sind.
• Der Nutzersimulator: ein Modell, das den Nutzer Runde für Runde spielt.
• Der Richter: ein Modell, das das fertige Gespräch anhand der gewählten Metriken bewertet.

Ein Turn ist ein Austausch aus einer Nutzernachricht und der Antwort des Agenten, einschließlich Tool-Aufrufen. Eine Episode ist ein einmal gegen den Kandidaten gespieltes Szenario, bis die Abbruchkriterien erfüllt sind oder das Rundenlimit erreicht ist. Eine Trajektorie ist die Aufzeichnung einer Episode und wird vom Richter bewertet. Ein Simulationslauf ist eine Gruppe von Episoden, die jedes Szenario eines Szenario-Sets so oft abdeckt, wie angefordert wurde.

Der Agent läuft in einer isolierten Harness-Runtime-Sandbox mit seiner Produktionskonfiguration und den Action-Gateway-Tools. Da der Richter in jeder Runde jede Nachricht und jeden Tool-Aufruf sieht, kann er laut DigitalOcean einen Denkfehler von einem Fehler bei der Tool-Nutzung unterscheiden und einen Agenten erkennen, der frühere Runden vergisst.

Das Beispiel mit dem Python-Upgrade

Das durchgespielte Beispiel verwendet einen Coding-Agenten auf Harness Runtime, der einen kleinen Python-Dienst namens orders-api pflegt, der unter Python 3.11 läuft. Der Agent kann Webseiten abrufen und das Repository durchsuchen. Ein gutes Gespräch umfasst drei Runden, die jeweils auf der vorherigen aufbauen:

• Der Nutzer fragt, auf welche Version er aktualisieren soll. Der Agent ruft die Statusseite der Python-Releases ab, gibt die unterstützten Versionen und deren jeweilige Supportdauer zurück und fragt, was dem Nutzer wichtig ist.
• Der Nutzer wählt eine Version und fragt, was kaputtgehen wird. Der Agent ruft die Release Notes aller Versionen zwischen 3.11 und der gewählten ab, nicht nur der Zielversion, und listet auf, was entfernt wurde.
• Der Nutzer fragt, ob sein Code betroffen ist. Der Agent durchsucht das Repository nach den entfernten Modulen und schlägt für jedes gefundene einen Ersatz vor.

DigitalOcean weist darauf hin, dass die Optionen veraltet sein können, wenn der Abruf in Runde 1 übersprungen wird, und dass die Liste in Runde 2 alles auslässt, was in den dazwischenliegenden Releases entfernt wurde, wenn der Agent 3.11 vergisst.

So werden Szenarien geschrieben

Ein Szenario ist ein JSON-Objekt in einem Szenario-Set, gespeichert als JSONL mit einem Szenario pro Zeile. Es gibt drei Wege, sie zu erstellen: den Scenario Builder, in dem ein Generatormodell aus ein oder zwei Sätzen Beschreibung ein Set schreibt; den Export aus Produktions-Traces mit Signals, das markierte Harness-Runtime-Gespräche in ein wiederholbares Set verwandelt; oder das Schreiben von Hand und das Hochladen der Datei.

Nur das Feld description ist Pflicht. Zu den optionalen Feldern gehören eine Nutzerpersona, Abbruchkriterien und eine maximale Rundenzahl. Abbruchkriterien werden als Handlungen des Agenten formuliert, etwa „The agent fetches...“ oder „The agent lists...“. Der Nutzersimulator führt das Gespräch weiter, bis der Agent alle Kriterien erfüllt hat, und beendet es dann. Bleiben die Kriterien leer, entscheidet der Simulator anhand der Beschreibung, wann Schluss ist, andernfalls endet das Gespräch bei max_turns. Ein Agent, der die Kriterien nie erfüllt, läuft in dieses Limit, was DigitalOcean selbst als Signal wertet.

Das Feld expected_outcome wird nur für die Metrik Agent Policy Adherence benötigt, die prüft, ob der Agent eine Regel befolgt oder einen Endzustand erreicht hat. Andere Gesprächsmetriken, darunter User goal completion, brauchen es nicht.

Da die Versionen aus einem Live-Webabruf stammen, kann das Szenario die Wahl des Nutzers nicht im Voraus festlegen. Aus demselben Grund sind die Abbruchkriterien relativ zur gewählten Version formuliert, statt eine bestimmte zu nennen. Sobald ein Simulationslauf ein Set verwendet, wird das Set gesperrt, damit frühere Läufe nachvollziehbar bleiben.

Was das für Teams bedeutet

Für Teams, die Agenten bauen, bietet Simulations die Möglichkeit, eine Baseline mit einem Kandidaten zu vergleichen. Laut DigitalOcean lassen sich dieselben Szenarien gegen Versionen eines Agenten oder gegen zwei Modelle laufen lassen, um zu zeigen, was sich verbessert und was verschlechtert hat. Jeder Schritt ist über doctl evaluation und die DigitalOcean API verfügbar. Der vorliegende Quelltext bricht mitten im Abschnitt über die Szenarien ab, daher werden Details zu den übrigen Stufen, darunter Bewertung und Vergleich, hier nicht behandelt.