Harness² — Wiederholbare Aufgaben verfestigen
Adaptiert von Harness²: Recursive Agent Harnessing for an Open World, beschränkt auf den Fall, dass eine Ausführung bereits akzeptiert wurde und das Ziel die Wiederholung ist.
Überblick
Einmal erfolgreich zu sein ist nicht dasselbe wie wiederholbar zu sein. Der akzeptierte Durchlauf ist Ihr einziger vertrauenswürdiger Referenzpunkt: Er enthält ein echtes Ergebnis, eine reale Vorgehensweise und die Stellen, an denen der Benutzer persönlich Änderungen vorgenommen hat.
Das Optimierungsziel ist der Prozess des nächsten Durchlaufs, nicht das Ergebnis des aktuellen. Das Ergebnis ist also kein besserer Bericht – es ist ein Harness, eine SOP und eine Regressions-Checkliste.
Wann verwenden
- Der Benutzer sagt „das machen wir ab jetzt jede Woche“ oder „lasst uns diesen Prozess festzurren“
- Die gleiche Art von Aufgabe wurde mindestens einmal erledigt und das Ergebnis wurde akzeptiert
- Der Prozess lebt im Kopf einer Person: wer welches Skript zuerst ausführt, welcher Schritt eine menschliche Prüfung benötigt, wo die Fallen liegen
- Die gleiche Aufgabenklasse scheitert immer wieder auf die gleiche Weise: fehlende Quellenangaben, inkonsistente Definitionen, ständige Nacharbeit
Wann NICHT verwenden
- Einmalige Aufgabe → einfach erledigen
- Ein echter Bewerter, Komponententest oder berechenbares Abnahmekriterium existiert → verwenden Sie dies; es schlägt Verhaltensvergleiche bei weitem
- Der Benutzer möchte nur ein Format oder eine Definition ändern und hat diese bereits genannt → bearbeiten Sie das Harness direkt, überspringen Sie den Vergleichszyklus
- Der Prozess ist bereits stabil und Kosten oder Latenz sind knapp
Was ein Harness ist
Alles rund um das Modell, das bearbeitet werden kann. Vier Komponenten reichen für den Betrieb; acht ist der vollständige Satz:
| Komponente | Rolle | Minimum |
|---|---|---|
| System-Prompt | Rolle, Ausgabe-Kontrakt | ✅ |
| Tool-Anleitung | Wann welche Datenquelle nutzen, wie Argumente füllen | ✅ |
| Skills | Wiederverwendbare Urteile und Verfahren | ✅ |
| Leitplanken | Harte Einschränkungen (niemals Zahlen erfinden, immer Quellen zitieren) | ✅ |
| Gedächtnis | Domänennotizen, die über Instanzen hinweg getragen werden | |
| Skripte | Deterministische Arbeiten (Konvertierung, Deduplizierung, Aggregation) | |
| Sub-Agenten | Verifikation oder paralleles Abrufen, ausgelagert | |
| Plugins | Middleware (z. B. Selbstprüfung alle N Schritte erzwingen) |
Ein Harness muss als Dateien existieren, die versioniert und wiederverwendet werden können. „Das machen wir normalerweise so“ – in einem Chat hinterlassen – lässt sich nicht verfestigen.
Der Kreislauf: Vorschlagen → Testen → Zusammenstellen
0. Baseline einfrieren
Archivieren Sie den letzten Durchlauf vollständig: Harness-Momentaufnahme, vollständige Vorgehensweise (Tool-Aufrufsequenz + Zwischenergebnisse), endgültiges Ergebnis, das Bearbeitungs-Diff des Benutzers, Abnahmekriterien, Datenmomentaufnahme oder Zeitfenster.
Stellen, die der Benutzer persönlich bearbeitet hat, sind hochzuverlässige Fehlerstellen – zuverlässiger als jede Vermutung.
1. Vorschlagen
Lesen Sie die Baseline und schlagen Sie zwei Kandidaten vor, jeder mit einem Satz, der den adressierten Defekt benennt:
- invariant: Prozessdefekte – keine Querprüfungen, Zwischenergebnisse nie gespeichert, Fehler nicht wiederholt, Quellen unbeschriftet, Kontext aufgebläht
- domain: fachliche Einschränkungen dieser Aufgabenklasse – konsistente Definitionen, Währungs- oder Einheitenumrechnung, abgestimmte Zeitfenster
Sie benötigen beide, um „allgemeine Krankheit“ von „Krankheit dieser Aufgabenklasse“ zu trennen. Mit einem einzigen Kandidaten können Sie das Ergebnis nicht zuordnen.
2. Testen
Wiederholung mit derselben Eingabe bei kontrollierten Variablen: gleiches Modell, gleicher Toolsatz, gleiche Datenmomentaufnahme. Nur das Harness ändert sich.
Vergleichen Sie zwei Dinge:
- Verhaltensunterschied zur Baseline: Toolsatz und -reihenfolge, Schrittanzahl, wiederholte Aufrufe, Fehler und Wiederholungen, ob manuelle Korrekturpunkte verschwunden sind, ob Zwischenergebnisse gespeichert wurden, ob Quellen vollständig attribuiert sind
- Wiederholkonsistenz: Führen Sie es erneut aus – ist die Struktur gleich? Die Kernmetrik der Verfestigung ist Stabilität, nicht die beste Einzelausführung
Der Vergleich zeigt „Verhalten hat sich geändert“. Er zeigt nicht „das Ergebnis ist richtig“. Verwechseln Sie niemals beides.
3. Zusammenstellen
Behalten Sie nur Änderungen, die (a) nach Wiederholung immer noch die Abnahmekriterien erfüllen und (b) Nacharbeit oder manuelle Korrekturen reduzieren. Die Beibehaltung des Originals ist erlaubt – eine Änderung ohne Beleg ist Rauschen.
Dokumentieren Sie jede Entscheidung in einer Zeile: Änderung | adressierter Defekt | beobachteter Beleg | übernommen / überarbeitet / verworfen.
4. Verfestigen
Drei Artefakte; fehlt eines, ist die Verfestigung nicht abgeschlossen:
harness/– die editierbaren DateienSOP.md– Schritte, Prüfpunkte, wann ein Mensch gefragt werden muss, bekannte Fallen (bei über zehn Punkten liest sie niemand)REGRESSION.md– die Abnahme-Checkliste, die nach dem nächsten Durchlauf durchgegangen wird
Wenn eine Änderung über mehrere Runden übernommen wird, erheben Sie sie zu einem eigenständigen Skript oder Skill.
Beweishierarchie
Benutzer-Edit-Diff > Vergleich mit akzeptiertem Ergebnis > Wiederholkonsistenz > Vorgehensweisen-Unterschied > Intuition
Keine Beweise: ein längerer oder detaillierterer Bericht, „der Benutzer hat sich diesmal nicht beschwert“, die Behauptung des Modells, es habe besser abgeschnitten.
Budget
Standard: k=1 plus eine Wiederholung. Verfestigung zahlt sich über Zeit aus – amortisieren Sie sie über mehrere Durchläufe: Testen Sie während jedes wiederkehrenden Durchlaufs einen Kandidaten, statt 3× den Aufwand für parallele Zweige zu betreiben.
Warnsignale – anhalten, wenn eines auftritt
- Das vorherige Harness ungeprüft übernehmen, ohne das Bearbeitungs-Diff des Benutzers zu lesen
- Mit einer anderen Eingabe, einem anderen Modell oder einer anderen Datenmomentaufnahme wiederholen und trotzdem behaupten „es ist besser“
- Aus einer einzigen Wiederholung schließen, ohne Zufälligkeit auszuschließen
- Fünf Komponenten gleichzeitig ändern, sodass eine Zuordnung unmöglich wird
- Eine 20-Punkte-SOP, die beim nächsten Mal niemand befolgen wird
- Einen einmaligen glücklichen Trick in einen invarianten Eintrag schreiben
Häufige Fehler
| Fehler | Folge | Lösung |
|---|---|---|
| Optimieren vor dem Archivieren | Baseline verloren, Änderungen nicht zuordenbar | zuerst Baseline einfrieren |
| „Liest sich besser“ als Beleg | Sie verfestigen eine Vorliebe, keinen Prozess | an eine konkrete Beobachtung binden |
| Nur Prompt-Änderungen, keine Prüfpunkte | Menschen patchen beim nächsten Mal immer noch manuell | jeden Defekt mit einem Prüfpunkt paaren |
| SOP als Reisebericht geschrieben | Niemand liest sie, also wird nichts verfestigt | nur Entscheidungspunkte und Fallen notieren |