Harness first – zuerst das Geschirr prüfen
Ein Modell ist ein Motor. Die meisten „Modellprobleme“ sind ein fehlendes Geschirr: Nichts definiert eine korrekte Ausgabe, nichts überprüft Änderungen, nichts begrenzt Ausgaben, die Daten haben keine vereinbarten Definitionen, Aktionen haben keine Genehmigung, und es gibt keine Ablaufverfolgung, um den fehlerhaften Aufruf zu finden. Prüfe das, bevor du das Modell anfasst.
1. Reproduziere das Symptom anhand von Beweisen, nicht von Bauchgefühlen
- Lies den Agenten-Code, den das Symptom betrifft: die Schleife, Tool-Definitionen, Prompt-Zusammenbau, Datenzugriff, Tools mit Seiteneffekten.
- Lies alle vorhandenen Logs/Traces/Transkripte. Aggregiere sie (pro Konversation, pro Tool, pro Fehler): Wer verbraucht die Token, welche Aufrufe schlagen fehl, welche Antworten sind falsch. Einige wenige Ausreißer dominieren in der Regel.
- Formuliere die Ursache als Mechanismus mit Beweisen (Datei:Zeile, Log-IDs, von dir berechnete Zahlen). „Das Modell ist schlecht“ ist kein Mechanismus.
Häufige Mechanismen:
- Token-Verbrennung: Schleife ohne maximale Iterationen, Wiederholung bei einem deterministischen Fehler, vollständiger Verlauf oder ein riesiges Tool-Ergebnis, das bei jedem Durchlauf erneut gesendet wird, kein Caching von stabilem Kontext.
- „Halluzination“: Der Agent hat getreu eine mehrdeutige oder falsche Quelle verwendet (zwei Tabellen/Felder mit demselben Namen und unterschiedlicher Bedeutung, veraltetes Dokument). Berechne beide Zahlen selbst, um es zu beweisen.
- Sprödigkeit: Prompt-Änderungen ohne Regressionsdatensatz ausgeliefert; Verhalten, das nur der Autor von Hand geprüft hat.
2. Bewerte die sechs Teile des Geschirrs
Markiere für jeden Teil vorhanden / teilweise / fehlend mit den gefundenen Beweisen:
| Teil | Vorhanden bedeutet |
|---|---|
| Goldstandard (Golden Set) | ~20+ Fälle mit erwarteten Antworten/Einschränkungen, basierend auf echtem Traffic, Vorfällen und Randfällen |
| Bewerter (Judge) | Zuerst deterministische Prüfungen (Zahlen, Richtlinien, verbotene Inhalte), LLM-Rubrik nur für das, was Code nicht prüfen kann; wird bei jeder Prompt/Modell/Tool-Änderung ausgeführt |
| Kostenverwaltung | Harte Token-/Kostenobergrenzen pro Benutzer und pro Workflow, maximale Iterationen pro Durchlauf, gnädiges Anhalten mit einer Nachricht |
| Datenschicht | Schreibgeschützte Anmeldedaten für Lesezugriffe, ein Datenwörterbuch, das jede Metrik/jedes Feld definiert, das der Agent verwenden darf |
| Aktionssicherheit | Irreversible oder externe Aktionen (Senden, Bezahlen, Löschen, Schreiben, Rückerstatten) sind umkehrbar oder durch menschliche Genehmigung geschützt |
| Tracing | Jeder Modell- und Tool-Aufruf wird protokolliert mit Konversations-ID, Workflow, Eingabe, Ausgabe, Token, Kosten, Latenz, Fehler |
3. Entscheide vor dem Bauen
- Empfehle niemals einen Modellwechsel ohne Evaluierungsnachweise. Wenn jemand fragt „Sollten wir das Modell wechseln?“, lautet die Antwort: Behebe den Mechanismus, führe dann den Goldstandard auf beiden Modellen aus und vergleiche Qualität und Kosten. Sage, was die Behebung allein voraussichtlich einspart, mit deinen Zahlen.
- Genehmige niemals die Auslieferung einer Prompt-/Agenten-Änderung ohne einen Goldstandard-Durchlauf. Wenn aufgezeichnete Ausgaben existieren, bewerte sie selbst gegen die erwarteten Antworten und melde Fehler nach Fall-ID.
- Sicherheitslücken (ungeschützte Seiteneffekte, Schreibzugriff auf einem Lesepfad, Leck interner Daten) sind blockierend, selbst wenn niemand danach gefragt hat.
4. Baue das minimale Geschirr, in dieser Reihenfolge
- Stoppe die Blutung: maximale Iterationen, keine Wiederholung bei nicht-temporären Fehlern, kürze/fasse große Tool-Ausgaben zusammen, harte Kostenobergrenze pro Durchlauf.
- Schütze Seiteneffekte: Genehmigungsschritt oder Entwurfsmodus für irreversible Tools; schreibgeschützte Verbindung für Abfrage-Tools.
- Goldstandard-Datei (
evals/golden.jsonloder ähnlich): Eingabe, erwartete Antwort oder Einschränkungen, Quelle (Log-ID / Vorfall / Richtlinienklausel). Füge die gerade fehlgeschlagenen Fälle hinzu. - Bewerterskript, das den Goldstandard ausführt und Bestehen/Nichtbestehen pro Fall plus Summen ausgibt. Deterministische Prüfungen vor LLM-Bewertung.
- Datenwörterbuch für jede Metrik, die der Agent meldet (Definition, Quelltabelle/-feld, Ausschlüsse).
- Tracing – die oben aufgeführten Felder, falls fehlend.
Schreibe echte Dateien, keine Beschreibung von Dateien. Führe aus, was ausgeführt werden kann, und berichte das Ergebnis.
5. Bericht
- Einzeilige Antwort auf die tatsächlich gestellte Frage (z.B. „Noch kein Modellwechsel: 3 Durchläufe steckten in einer Wiederholungsschleife fest und verbrauchten 71 % der Token“).
- Ursache mit Beweisen und Zahlen.
- Bewertungstabelle des Geschirrs (die sechs Teile).
- Was du geändert oder erstellt hast und was du ausgeführt hast.
- Blockierende Risiken, dann eine kurze priorisierte Liste der nächsten Schritte.
Quellenangabe
Die Methode, der dieser Skill folgt, stammt aus einem öffentlichen Beitrag von Mark Ajzenstadt (@mardehaym): https://x.com/mardehaym/status/2099562230647804152. Die Argumentation stammt von ihm; das Verfahren, der Wortlaut und die Bewertung hier sind Edge's eigene, und der Autor hat sie nicht überprüft.