Kritiker und Prüfung · Agentenwerk

Lernziele

Du trennst eine Fertigmeldung des Agenten von einem Beleg, den der Loop selbst misst.
Du setzt Code als ersten Kritiker ein und schützt ihn vor dem Agenten, der die Arbeit macht.
Du schreibst eine enge Rubrik für einen LLM-Kritiker und prüfst mit der Prüf-Asymmetrie, ob sich ein Loop lohnt.

Ein Loop · engl. agent loopDie Schleife eines Agenten: denken, handeln, beobachten, wiederholen. Zwischen den Durchläufen wird der Kontext des Modells jedes Mal neu gebaut.Im Glossar ist so gut wie sein Richter. Einen weiteren Versuch erzeugt das Modell · engl. model, LLMDas Sprachmodell (LLM, Large Language Model). Es liest Text, schreibt Text und entscheidet in einem Agenten, was als Nächstes passiert.Im Glossar heute für ein paar Cent. Der Engpass liegt deshalb beim Beweis, dass ein Ergebnis funktioniert. Die Instanz, die als Kritiker · engl. criticDie Instanz, die einen Versuch im Loop bewertet: Code wie Tests und Linter oder ein zweiter Modellaufruf mit enger Rubrik. Der Kritiker arbeitet getrennt vom Agenten, der die Arbeit gemacht hat.Im Glossar urteilt, entscheidet, ob dein Loop Fortschritt ansammelt oder Ausschuss.

Fertig oder nur fertig gemeldet

Modelle sind darauf trainiert, dass ein Verlauf abgeschlossen aussieht. „Alle Tests laufen durch, das Feature ist fertig“ ist Prosa, und Prosa ist kein Beleg. Vielleicht hat der AgentEin System, in dem ein Sprachmodell seinen nächsten Schritt selbst wählt: Es ruft Werkzeuge auf, wertet das Ergebnis aus und macht weiter, bis das Ziel erreicht ist.Im Glossar die Tests gar nicht gestartet. Vielleicht hat er die falschen gestartet oder den fehlschlagenden Test still gelöscht.

Daraus folgt eine Regel ohne Ausnahme: Der Loop prüft selbst und fragt den Agenten nie. Fertig ist eine Eigenschaft der Welt, etwa ein Exit-Code, ein Diff · engl. diffDie Gegenüberstellung zweier Stände einer Datei: Zeilen mit Plus kamen dazu, Zeilen mit Minus fielen weg. Git zeigt so, was ein Commit geändert hat.Im Glossar oder eine grüne Pipeline. Gemessen wird sie von etwas anderem als dem Prozess, der die Arbeit gemacht hat. Aus demselben Grund zählt in Stoppbedingungen der Bericht des Agenten nie als Bedingung.

Gemeldet gegen gemessen (Beispiel)1/5

AgentIch habe den Parser korrigiert. Alle Tests laufen durch, das Feature ist fertig.

Der Diff zeigt neun gelöschte Testzeilen. Mit wiederhergestelltem Testordner schlagen zwei Tests fehl. Der Loop wertet den Exit-Code aus und ignoriert die Meldung.

Code als Kritiker

Nimm zuerst deterministische Kritiker: die Testsuite, die Typprüfung, den Linter, den Build. Sie kosten pro Lauf nichts, liefern jedes Mal dasselbe Urteil und lassen sich nicht überreden.

Ihre Schwäche: Sie beurteilen nur, was sie kodieren. Ein Agent unter Druck erfüllt dann den Buchstaben. Der klassische Zug ist, den fehlschlagenden Test abzuschwächen oder zu löschen. Halte den Kritiker deshalb außer Reichweite des Agenten, der die Arbeit macht. Zwei Wege:

Verweigere dem Agenten Schreibrechte auf tests/.
Stelle den Testordner vor jedem Prüflauf aus Git wieder her: git checkout -- tests/.

Ein Prüfer, den der Agent selbst ändern kann, prüft nichts. Wie du Schreibrechte im HarnessAlles, was festlegt, was der Agent erreichen darf: Tools, Berechtigungen, Sandbox, Zeitlimits und die Prüfung, bevor eine Aktion wirkt. Englisch für Geschirr oder Gestell.Im Glossar sperrst, zeigt Die vier Ringe.

LLM-Kritiker mit enger Rubrik

Manche Urteile kann Code nicht fällen: Ist der Diff minimal? Ist die Fehlerbehandlung echt oder Dekoration? Ist die Änderung innerhalb der Aufgabe geblieben? Dafür setzt du einen zweiten Modellaufruf als Kritiker ein und hältst ihn eng.

Ein guter Kritiker-Prompt · engl. promptDer Text, den du einem Sprachmodell bei einem Aufruf schickst. In einem Agenten setzt er sich aus Systemprompt, Tool-Definitionen, Verlauf und aktueller Anfrage zusammen.Im Glossar hat drei Merkmale:

Er nennt drei bis fünf prüfbare Regeln.
Er verlangt ein strukturiertes Urteil: PASS oder eine Liste von Verstößen mit Fundstelle und Korrektur.
Er verbietet ausdrücklich jeden Kommentar zu anderen Themen.

Weite Rubriken nach dem Muster „Prüf diesen Code“ erzeugen plausibles Rauschen. Der nächste Versuch verbraucht sein Budget dann für Stilmeinungen.

Weite Rubrik

„Prüf diesen Code und gib Feedback.“
Antwort: Absätze zu Namen, Stil, Architektur
Der nächste Versuch jagt Meinungen
Kein klares Ende: Irgendetwas findet der Kritiker immer

Enge Rubrik

„Prüf nur diese vier Regeln. Antworte mit PASS oder einer Liste: Regel, Datei:Zeile, Korrektur.“
Antwort: PASS oder zwei konkrete Verstöße
Der nächste Versuch behebt genau diese
Klares Ende: PASS beendet die Prüfung

LLM-Kritiker erben alle Schwächen eines Judge · engl. LLM as a judgeEin Sprachmodell, das die Ausgabe eines anderen Modells nach einer festen Frage bewertet, etwa ob eine Antwort auf der gefundenen Notiz beruht. Ein Judge ist ein Messgerät und muss gegen eigene Labels geprüft werden.Im Glossar: Milde, eine Vorliebe für lange Antworten und eine Vorliebe für die eigene Arbeit. Die letzte wiegt hier am schwersten. Lass das Modell seine Arbeit nie im selben Kontext bewerten. Der Kritiker bekommt einen frischen Kontext und sieht nur den Diff und die Rubrik. Am besten ist er ein anderes Modell. Das Handbuch Eval Engineering behandelt die Schwächen von Judges ausführlich. Den Kritiker zwischen zwei Versuchen verdrahtest du in Build: Der Kritiker.

Prüf-Asymmetrie

Loops funktionieren, weil Prüfen meist billiger ist als Machen. Eine Testsuite prüft in Sekunden, wofür der Agent zwanzig Minuten gebraucht hat. Diese Asymmetrie treibt den Loop an: Du kaufst viele billige Versuche und bezahlst den vollen Preis nur für das Urteil.

Sie zeigt dir auch, welche Aufgaben du loopen solltest. Arbeit mit billigem, verlässlichem Prüfer eignet sich gut: fehlschlagende Tests, ein reproduzierbarer Bug, eine Benchmark-Zahl. Arbeit, deren Prüfung so viel kostet wie die Arbeit selbst, eignet sich schlecht: Architekturgeschmack, Qualität von Prosa, Produktentscheidungen. Wer sie trotzdem loopt, erzeugt nach unserer Einschätzung selbstsicheren Ausschuss in großer Menge.

Bestimme deshalb vor jedem Loop den Preis des Prüfers. Kannst du dir keinen echten leisten, bleibt der Mensch am Steuer.

Lohnt sich ein Loop?

Ordne jede Aufgabe nach dem Preis ihres Prüfers ein.

Noch offen (6)

Drei Tests in tests/ schlagen nach einem Update fehl
Ein Bug mit Reproduktionsskript, das bei Erfolg 0 zurückgibt
Die Startzeit einer App soll unter 2 Sekunden fallen, ein Benchmark misst sie
Die Modulstruktur soll „eleganter“ werden
Der Ton eines Kundenbriefs soll freundlicher werden
Welches von zwei Features als Nächstes gebaut wird

Billiger Prüfer: loopen (0)

Teurer Prüfer: Mensch bleibt dran (0)

Merksätze

Der Loop misst Fertigsein an der Welt: Exit-Code, Diff, Pipeline. Die Meldung des Agenten ist kein Beleg.
Code ist der erste Kritiker: kostenlos, gleichbleibend, nicht zu überreden.
Ein Prüfer, den der Agent ändern kann, prüft nichts. Sperre tests/ oder stelle den Ordner vor jeder Prüfung wieder her.
Ein LLM-Kritiker bekommt drei bis fünf Regeln, ein strukturiertes Urteil, einen frischen Kontext und am besten ein anderes Modell.
Loope nur Arbeit, deren Prüfung deutlich billiger ist als die Arbeit selbst.

Prüf dich selbst

Denkfrage

Der Agent meldet „Alle Tests grün“. Warum reicht das dem Loop nicht?

Denkfrage

Wie verhinderst du, dass der Agent den Test anpasst, statt den Code zu reparieren?

Denkfrage

Woran erkennst du eine Aufgabe, die du nicht loopen solltest?