Einen Agenten mit einem Entscheidungsmodell beobachten
Coding-Agenten sind der Ort, an dem diese Modelle am dichtesten verwendet werden, und die Verwendungen gruppieren sich an drei Stellen. Alle drei teilen eine Struktur: nimm das Urteil aus dem generativen Modell, gib es etwas Billigerem und Schnellerem, und lass Code auf einer typisierten Antwort handeln.
1. Vor einem Tool-Aufruf: erlauben oder nicht
Die direkteste Stelle. Ein Claude Code PreToolUse-Hook macht das:
Frage ein
Noul: Ist dieser Shell-Befehl strikt nur lesend? Automatisch genehmigen bei 0.95, andernfalls auf den normalen Berechtigungs-Prompt zurückfallen — und niemals verweigern.
Drei Designentscheidungen sind es wert, benannt zu werden:
- 0.95 ist hoch. Die Hürde für automatisches Genehmigen liegt deutlich über der Hürde für „das sieht riskant aus”. Eine fälschliche Erlaubnis kostet eine Maschine; eine fälschliche Blockierung kostet eine zusätzliche Bestätigung. Asymmetrische Kosten gehören in asymmetrische Schwellenwerte.
- Es verweigert nie. Es fügt nur eine Genehmigung hinzu; alles andere kehrt zum ursprünglichen System zurück. Ein Gate, das nur Fähigkeiten hinzufügt, ist weit leichter zu testen — sein schlimmster Fall ist, nicht geholfen zu haben.
- Gefährliche Befehle erreichen das Modell nie. Eine lokale Hard-No-Liste und ein Injection-Filter fangen sie zuerst ab. Das ist wichtiger als der Schwellenwert — siehe Was im Code leben muss.
Gemessenes Ergebnis: 0 von 8 zustandsändernden Befehlen wurden automatisch genehmigt.
2. Wenn der Agent stoppen will: ist er fertig?
Eine weitere häufige Stelle. Ein Stop-Hook fragt das Entscheidungsmodell, ob der Agent zu früh fertig wird, indem er ihm seine umgangssprachlichen Abschlussregeln vorlegt.
Die zurückhaltendere Version funktioniert so:
Gib einen Aufruf mit vier Fragen nur aus, wenn sich Dateien geändert haben und seitdem keine bestandene Prüfung gelaufen ist. Bei jedem Fehler fail-open.
„Nur fragen, wenn es sich zu fragen lohnt” ist der Kern für diese Klasse — diese Hooks laufen jede Runde, und bedingungslos aufzurufen multipliziert die Kosten mit der Rundenzahl. Die Bedingung oben ist „unverifizierte Änderungen”, genau der Moment, in dem ein Agent am wahrscheinlichsten den Sieg erklärt, ohne geprüft zu haben.
Ein verwandter Hook hält einen Agenten davon ab, zu früh fertig zu werden, indem er umgangssprachliche Abschlussregeln beurteilt, statt der Behauptung des Agenten selbst zu vertrauen.
3. Wenn der Kontext volläuft: was wird noch gebraucht?
Die dritte Stelle ist die Kontext-Kompaktierung, wo die Ansätze am stärksten divergieren.
Traditionelle Kompaktierung fasst zusammen: Du übergibst einem Modell einen Abschnitt Konversation und bekommst Prosa zurück. Das Original ist weg, und Zusammenfassen ist irreversibel.
Der Ansatz mit Entscheidungsmodell schreibt nicht um — er scored nur:
| Ansatz | Was bewahrt wird |
|---|---|
| Jeden Tool-Aufruf und sein Ergebnis nach „noch gebraucht” scoren | Zeilen, die als zu behalten beurteilt werden, bleiben wörtlich |
Niedrige Scores in einen Store verschieben, einen expand()-Pointer zurücklassen |
Nichts wird gelöscht, nur gefaltet |
| Ein eingefrorenes Append-only-Präfix | Der Prompt-Cache wird nie gebrochen |
| Lange Bash-Ausgabe kürzen, bevor das Modell sie sieht | Terminal-Rauschen gelangt nie ins Fenster |
Der gemeinsame Satz: Die Aufgabe des Entscheidungsmodells ist hier ein binäres Behalten/Verwerfen-Urteil, kein Umschreiben. Genau das kann es gut und generative Modelle schlecht — und „falten statt löschen” verwandelt ein falsches Urteil von „für immer verlorene Information” in „ein zusätzliches expand”.
Der Gegenpunkt: Sicherheits-Gates und Effizienz-Gates scheitern in entgegengesetzte Richtungen
Der lehrreichste Kontrast in diesem Teil des Ökosystems: Auf dieselbe Frage „was passiert bei einem Fehler” wählten Projekte entgegengesetzte Antworten, und beide sind richtig.
- Ein Berechtigungs-Judge: verweigert bei Fehler oder Timeout.
- Ein Stop-Hook: erlaubt bei jedem Fehler.
Das Kriterium ist nicht „welches ist sicherer”, sondern ob dieses Gate Risiko oder Durchsatz schützt. Gates, die Risiko schützen (Berechtigungen, Secrets, gefährliche Befehle), sollten lieber etwas Gutes blockieren, als etwas Schlechtes durchzulassen; Gates, die Durchsatz schützen (Abschlussprüfungen, Formatprüfungen), sollten lieber etwas durchlassen, als den Ablauf zu blockieren.
In einem Satz
Agenten sind der natürlichste Ort für diese Modelle, weil sie sehr viele billige Urteile brauchen, deren Ergebnisse sofort von Code konsumiert werden. Aber an jedem dieser Punkte entscheide zuerst: in welche Richtung sollte dieses Gate fallen, wenn es bricht?