Harness Engineering: Der ultimative Leitfaden für den Aufbau stabiler KI-Agenten

Die meisten Leute versuchen, KI-Agenten auf der falschen Ebene zu verbessern.

Wenn ein Agent scheitert, schreiben sie das Prompt um.

Wenn er wieder scheitert, fügen sie weitere Anweisungen hinzu.

Bevor wir beginnen:

Folge meinem Substack für frische KI-Alphas, Agenten-Workflows und Schritt-für-Schritt-Anleitungen, bevor sie auf X erscheinen: [https://substack.com/@lunarresearcher

Dann wechseln sie die Modelle, fügen weitere Tools hinzu, vergrößern das Kontextfenster und hoffen, dass der nächste Durchlauf anders verläuft.

Aber viele Agentenfehler sind keine Denkfehler.

Es sind Umgebungsfehler.

Der Agent wusste nicht, welche Dateien wichtig waren.

Er hat das richtige Tool an der falschen Stelle eingesetzt.

Er hat die Entscheidungen aus der vorherigen Sitzung verloren.

Er hat Erfolg gemeldet, ohne die Überprüfungen durchzuführen.

Er hat eine Aktion nach einem Teilfehler wiederholt.

Er hatte die Erlaubnis, etwas zu tun, das eine Genehmigung hätte erfordern sollen.

Das Modell war nicht unbedingt das Problem. Das System um das Modell herum war unvollständig.

Dieses System ist das Harness.

Und dessen Design wird zu einer eigenen Ingenieursdisziplin.

Harness Engineering ist die Praxis, die Umgebung zu schaffen, die Modellintelligenz in zuverlässige Arbeit verwandelt.

Ein Prompt ändert einen Versuch.

Ein Harness ändert jeden Versuch.

Dieser Leitfaden erklärt, wie man eines baut.

1. Das Modell ist nicht der Agent

Ein Modell kann denken, generieren, vergleichen und auswählen.

Aber ein Agent muss auch mit einer realen Umgebung interagieren.

Er muss:

• die Aufgabe verstehen
• den relevanten Kontext finden
• Tools auswählen und nutzen
• den Zustand bewahren
• Berechtigungen respektieren
• das Ergebnis überprüfen
• sich von Fehlern erholen
• beweisen, dass die Arbeit abgeschlossen ist

Das Modell ist die Denkmaschine in diesem System.

Das Harness ist alles, was das Denken operational macht.

1Benutzeranfrage
2     |
3     v
4+-----------------------------+
5|          HARNESS            |
6| Vertrag | Kontext | Richtlinie |
7| Tools   | Zustand | Prüfungen  |
8| Ablaufverfolgung | Wiederherstellung |
9+-----------------------------+
10     |
11     v
12    Modell
13     |
14     v
15reale Umgebung

Ein leistungsstarkes Modell in einem schwachen Harness ist immer noch ein schwacher Agent.

Es kann beeindruckende einzelne Antworten liefern, aber es wird sich bei langen Aufgaben, sich ändernden Umgebungen und Teilfehlern inkonsistent verhalten.

Das Ziel des Harness Engineering ist es nicht, die Unsicherheit des Modells zu beseitigen.

Es geht darum, diese Unsicherheit in einem System einzudämmen, das beobachten, verifizieren und wiederherstellen kann.

2. Beginne mit einem Aufgabenvertrag

Die meisten Agentenaufgaben beginnen als vage Absicht:

Verbessere den Onboarding-Prozess.

Dieser Satz mag für ein Gespräch ausreichen.

Für eine autonome Ausführung reicht er nicht.

Bevor der Agent handelt, sollte das Harness die Anfrage in einen Aufgabenvertrag umwandeln.

Ein nützlicher Vertrag beantwortet fünf Fragen:

1. Welches Ergebnis muss vorliegen?
2. Was liegt im Umfang?
3. Was darf sich nicht ändern?
4. Welcher Nachweis belegt die Fertigstellung?
5. Welche Aktionen erfordern eine menschliche Genehmigung?

1Ziel: Reduzierung der Abbrüche beim Onboarding
2
3Umfang:
4  - Anmeldeablauf
5  - Onboarding-Analysen
6
7Einschränkungen:
8  - Authentifizierung nicht ändern
9  - bestehendes mobiles Verhalten beibehalten
10
11Abnahmekriterien:
12  - Tests bestehen
13  - Analyseereignis wird ausgelöst
14  - Screenshots decken Desktop und Mobil ab
15
16Genehmigung erforderlich:
17  - Produktionsbereitstellung
18  - Datenbankmigration

Dies ändert die Frage des Agenten von:

Was soll ich als nächstes tun?

zu:

Welche Aktion bringt die Umgebung dem vereinbarten Ergebnis näher?

Ohne Vertrag optimiert der Agent auf plausible Aktivität.

Mit einem Vertrag kann er auf verifizierte Fertigstellung optimieren.

3. Gib dem Agenten eine Karte, kein Handbuch

Das gesamte Repository, die Dokumentation und den Gesprächsverlauf in den Kontext zu werfen, ist kein gutes Kontext-Engineering.

Es ist Kontext-Überflutung.

Das Harness sollte zuerst eine kleine Karte bereitstellen und dem Agenten dann erlauben, Details abzurufen, wenn sie relevant werden.

1PROJEKTKARTE
2
3Produktregeln     -> docs/product/
4Architektur       -> docs/architecture.md
5Frontend          -> apps/web/
6Backend           -> services/api/
7Tests             -> tests/
8Befehle           -> docs/commands.md
9Release-Regeln    -> docs/release.md

Dies ist eine progressive Offenlegung:

1Aufgabe
2  -> Projektkarte
3      -> relevantes Subsystem
4          -> genaue Dateien
5              -> lokale Anweisungen

Der Kontext sollte sich erweitern, weil die Aufgabe es erfordert, nicht weil die Informationen existieren.

Ein guter Kontext-Compiler entscheidet:

• was immer benötigt wird
• was später abgerufen werden kann
• was veraltet ist
• was zusammengefasst werden kann
• was wörtlich bleiben muss

Das Ziel ist nicht maximaler Kontext.

Es ist maximales Signal pro Token.

4. Baue ein Tool-Gateway, keinen Tool-Haufen

Einem Agenten zwanzig Tools zu geben, macht ihn nicht fähig.

Es gibt dem Agenten zwanzig Möglichkeiten, einen Fehler zu machen.

Jedes Tool sollte einen klaren Vertrag haben:

1TOOL: edit_file
2
3Eingaben:
4  Pfad
5  Patch
6
7Vorbedingungen:
8  Pfad existiert
9  Pfad liegt im erlaubten Arbeitsbereich
10
11Erfolgsnachweis:
12  Patch angewendet
13  resultierendes Diff zurückgegeben
14
15Fehlerverhalten:
16  keine teilweise Überschreibung
17  strukturierter Fehler zurückgegeben
18
19Risikoklasse:
20  umkehrbar

Das Harness sollte steuern, wie Tools bereitgestellt und verwendet werden.

Es kann:

• irrelevante Tools ausblenden
• Argumente validieren
• Pfade und Domänen einschränken
• Timeouts anhängen
• Wiederholungen idempotent machen
• Ausgaben normalisieren
• Bestätigung für riskante Aktionen verlangen
• Nachweise zurückgeben, nicht nur "Erfolg"

Dies schafft eine wichtige Trennung:

1Modell entscheidet Absicht
2Gateway validiert Aktion
3Tool ändert Umgebung
4Sensor beobachtet Ergebnis

Das Modell kann eine Aktion vorschlagen.

Das Tool-Gateway entscheidet, ob diese Aktion gültig genug ist, um ausgeführt zu werden.

5. Trenne das Gehirn, die Hände und die Historie

Viele fragile Agenten mischen alles in ein wachsendes Transkript.

Denken, Tool-Aufrufe, Dateien, Entscheidungen, Fehler und alte Beobachtungen konkurrieren alle um dasselbe Kontextfenster.

Ein stärkeres System trennt drei Verantwortlichkeiten:

1GEHIRN
2plant, denkt, wählt aus
3
4HÄNDE
5führen Tools in einer kontrollierten Umgebung aus
6
7HISTORIE
8speichert dauerhafte Fakten, Entscheidungen und Ausführungszustand

Das Modell benötigt nicht jedes rohe Ereignis im aktiven Kontext.

Es benötigt den richtigen aktuellen Zustand.

Die Sandbox muss nicht das gesamte Ziel verstehen.

Sie muss eine begrenzte Aktion sicher ausführen.

Das Sitzungsprotokoll muss nicht denken.

Es muss bewahren, was passiert ist, nachdem der aktuelle Kontext verschwunden ist.

Diese Trennung macht langlebige Agenten einfacher wiederaufnehmbar, überprüfbar und reparierbar.

Sie ermöglicht es auch, einen Teil auszutauschen, ohne das gesamte System neu aufzubauen.

6. Gedächtnis muss zu dauerhaftem Zustand werden

Der Gesprächsverlauf ist kein zuverlässiges Gedächtnis.

Es ist ein Ereignisstrom.

Nützliches Gedächtnis sollte in expliziten Zustand umgewandelt werden.

Bewahre mindestens vier Kategorien auf:

1FAKTEN
2stabile Informationen, die über die Umgebung entdeckt wurden
3
4ENTSCHEIDUNGEN
5getroffene Entscheidungen und der Grund dafür
6
7FORTSCHRITT
8abgeschlossene, aktive, blockierte und verbleibende Arbeit
9
10LEKTIONEN
11Fehler, die das zukünftige Verhalten ändern sollten

Zum Beispiel:

1fakten:
2  - Checkout-Validierung befindet sich in services/orders
3
4entscheidungen:
5  - die bestehende Validierungspipeline wiederverwenden
6  - grund: vermeidet eine zweite Quelle der Wahrheit
7
8fortschritt:
9  abgeschlossen:
10    - serverseitige Regel hinzugefügt
11  verbleibend:
12    - Integrationstest aktualisieren
13
14lektionen:
15  - lokaler Testbefehl benötigt TEST_DB_URL

Dies ist weitaus nützlicher, als fünfzig Seiten Transkript abzuspielen und zu hoffen, dass das Modell die wichtige Zeile bemerkt.

Speichere den rohen Verlauf für die Prüfbarkeit.

Komprimiere dauerhaften Zustand für die Ausführung.

7. Fertigstellung erfordert Nachweise

Ein Agent, der "erledigt" sagt, ist kein Beweis dafür, dass die Aufgabe erledigt ist.

Es ist nur eine weitere Modellausgabe.

Die Fertigstellung muss durch beobachtbare Änderungen in der Umgebung entschieden werden.

1Behauptung                     Nachweis
2--------------------------------------------------
3"der Fehler ist behoben"       fehlschlagender Test besteht jetzt
4"die Seite funktioniert"       Browser-Ablauf abgeschlossen
5"die Migration ist sicher"     Trockenlauf und Rollback bestehen
6"der Bericht ist korrekt"      Werte stimmen mit Quelldaten überein
7"die Aufgabe ist abgeschlossen"  jede Abnahmeprüfung besteht

Das Harness sollte zuerst die günstigsten deterministischen Prüfungen durchführen.

1Syntax
2  -> Typen
3      -> gezielte Tests
4          -> Integrationstests
5              -> visuelle oder semantische Überprüfung
6                  -> menschliche Genehmigung

Verwende kein weiteres Modell, wo ein Compiler, Schema, eine Prüfsumme, Abfrage oder ein Test die Frage beantworten kann.

Verwende Modelle für Mehrdeutigkeit.

Verwende Code für die Infrastruktur.

Ein Modell kann vorschlagen, dass die Aufgabe abgeschlossen ist.

Nur die Umgebung kann es beweisen.

8. Verifikation sollte das Ergebnis angreifen

Arbeiter und Evaluatoren sollten nicht dasselbe Ziel teilen.

Der Arbeiter versucht, die stärkste Lösung zu erstellen.

Der Evaluator versucht, den Grund zu finden, warum sie abgelehnt werden sollte.

1Arbeiter
2  -> erzeugt Kandidaten
3
4Prüfer
5  -> prüft Vertrag
6  -> sucht nach fehlenden Fällen
7  -> testet unbelegte Behauptungen
8  -> versucht, Ergebnis zu brechen
9
10Überlebt
11  -> akzeptieren
12
13Scheitert
14  -> gezielte Nachweise zurückgeben

Diese Asymmetrie ist wichtig.

Wenn man denselben Agenten im selben Kontext bittet, "seine Arbeit noch einmal zu überprüfen", bewahrt er oft die Annahmen, die den Fehler verursacht haben.

Eine nützliche Verifikationsstufe sollte haben:

• eine explizite Ablehnungsrubrik
• Zugriff auf das erstellte Artefakt
• Zugriff auf den Abnahmevertrag
• unabhängige Tools oder frischen Kontext bei Bedarf
• die Erlaubnis, abzulehnen, ohne zu reparieren

Verifikation ist keine zweite Meinung.

Es ist ein versuchter Widerlegungsbeweis.

9. Das Modell schlägt vor, die Richtlinie autorisiert

Einige Regeln sollten niemals davon abhängen, ob das Modell sie sich merkt.

1niemals ohne Genehmigung veröffentlichen
2niemals ein Geheimnis preisgeben
3niemals außerhalb des Arbeitsbereichs schreiben
4niemals das Ausgabenlimit überschreiten
5niemals Tests als bestanden markieren, wenn sie nicht gelaufen sind

Dies sind keine Prompt-Vorschläge.

Es sind Richtlinien.

Das sicherste Design hält die Richtlinie außerhalb der Denkschleife.

1GERINGES RISIKO
2Dateien lesen, suchen, überprüfen
3-> automatisch
4
5UMKEHRBARE ÄNDERUNG
6Arbeitsbereich bearbeiten, Tests ausführen
7-> automatisch mit Ablaufverfolgung
8
9EXTERNE AUSWIRKUNG
10Nachricht senden, bereitstellen, kaufen
11-> explizite Genehmigung
12
13UNUMKEHRBAR ODER SENSIBEL
14Daten löschen, Anmeldeinformationen rotieren, global veröffentlichen
15-> harte Sperre oder verboten

Je stärker die Konsequenz, desto härter die Sperre.

Autonomie ist nicht die Abwesenheit von Kontrolle.

Es ist die Fähigkeit, frei innerhalb einer klar durchgesetzten Grenze zu operieren.

10. Wiederherstellung sollte auf die Fehlerklasse abzielen

Die häufigste Wiederherstellungsstrategie ist:

Etwas ist fehlgeschlagen. Versuche es noch einmal.

Das ist keine Wiederherstellung.

Es ist Wiederholung.

Das Harness sollte den Fehler klassifizieren, bevor es die nächste Aktion auswählt.

1Tool-Timeout
2-> Wiederholung mit Backoff
3
4ungültige Argumente
5-> Tool-Aufruf reparieren
6
7fehlender Kontext
8-> spezifische Quelle abrufen
9
10fehlgeschlagener Test
11-> fehlschlagendes Verhalten überprüfen
12
13Zugriff verweigert
14-> Genehmigung anfordern oder sicheren Pfad wählen
15
16widersprüchliche Anforderungen
17-> an Menschen eskalieren
18
19wiederholter unveränderter Fehler
20-> Schleife stoppen

Ein Wiederholungsversuch sollte mindestens eine relevante Bedingung ändern.

Sonst bezahlt das System dafür, denselben Fehler zu reproduzieren.

Eine begrenzte Agentenschleife sieht so aus:

1beobachten
2  -> entscheiden
3      -> handeln
4          -> messen
5              -> akzeptieren
6              -> reparieren
7              -> eskalieren
8              -> stoppen

Jede Schleife benötigt ein Budget:

• maximale Versuche
• maximale Zeit
• maximale Ausgaben
• maximaler zerstörerischer Umfang
• Eskalationsbedingung

Zuverlässige Agenten wissen, wie sie weitermachen können.

Sie wissen auch, wann Weitermachen nicht mehr rational ist.

11. Anweisungen sollten zu Infrastruktur werden

Agentenanweisungen sind nützlich, wenn sie die lokale Realität erklären.

Aber Anweisungen allein sind eine schwache Durchsetzung.

Wenn eine Regel wiederholt wichtig ist, verschiebe sie im Stack nach unten.

1"den Formatierer verwenden"
2-> Formatierer automatisch ausführen
3
4"nicht schichtübergreifend importieren"
5-> Architekturtest hinzufügen
6
7"einen Migrations-Rollback einschließen"
8-> Rollback-Datei in CI verlangen
9
10"generierte Dateien nicht ändern"
11-> Schreibvorgänge auf generierte Pfade blockieren
12
13"jede externe Behauptung zitieren"
14-> Zitierabdeckung validieren

Dies erzeugt eine Anweisungsleiter:

1Erklärung
2  -> Checkliste
3      -> Vorlage
4          -> automatisierte Prüfung
5              -> durchgesetzte Richtlinie

Verschiebe wichtiges Wissen so weit wie möglich auf dieser Leiter nach unten.

Das Prompt sollte das Urteilsvermögen erklären.

Das Harness sollte Invarianten durchsetzen.

12. Beobachte den Durchlauf, nicht nur die endgültige Antwort

Ein sauberes endgültiges Artefakt kann einen schrecklichen Prozess verbergen.

Der Agent könnte:

• auf die falschen Daten zugegriffen haben
• einen fehlgeschlagenen Befehl ignoriert haben
• eine externe Aktion zweimal wiederholt haben
• das zehnfache des erwarteten Budgets verbraucht haben
• die richtige Antwort aus dem falschen Grund gefunden haben

Du benötigst Ablaufverfolgungen, die den Durchlauf rekonstruierbar machen.

109:14  Vertrag erstellt
209:15  Kontextquelle geladen: architecture.md
309:17  Datei bearbeitet: checkout.ts
409:18  Gezielter Test fehlgeschlagen: doppelter Coupon
509:21  Implementierung repariert
609:22  Gezielter Test bestanden
709:24  Integrationstest bestanden
809:25  Externe Bereitstellung blockiert: Genehmigung erforderlich

Eine nützliche Ablaufverfolgung zeichnet auf:

• Zustandsübergänge
• Kontextquellen
• Tool-Eingaben und -Ausgaben
• Umgebungsänderungen
• Verifikationsergebnisse
• Wiederholungsgründe
• Genehmigungsentscheidungen
• Kosten und Latenz

Das Ziel ist nicht Überwachung.

Das Ziel ist lokale Reparatur.

Wenn ein Durchlauf bei Schritt 18 fehlschlägt, solltest du von einem vertrauenswürdigen Prüfpunkt neu starten können, anstatt die gesamte Aufgabe zu wiederholen.

13. Jeder Durchlauf benötigt eine Änderungsquittung

Lange Agententranskripte sind schwer zu überprüfen.

Am Ende eines Durchlaufs sollte das Harness eine kleine Änderungsquittung erstellen.

1ZIEL
2Doppelte Coupon-Anwendung beim Checkout beheben.
3
4GEÄNDERT
5- Checkout-Validierungslogik
6- gezielter Regressionstest
7
8VERIFIZIERT
9- Lint bestanden
10- Unit-Tests bestanden
11- Checkout-Integrationstest bestanden
12
13NICHT VERIFIZIERT
14- Produktions-Zahlungsanbieter
15
16ENTSCHEIDUNGEN
17- bestehende Coupon-Prioritätsreihenfolge beibehalten
18
19RISIKEN
20- Legacy-Mobilclient war lokal nicht verfügbar
21
22GENEHMIGUNG ERFORDERLICH
23- auf Staging bereitstellen

Die Quittung ist keine Zusammenfassung dessen, was das Modell gesagt hat.

Es ist eine Zusammenfassung dessen, was das System beweisen kann.

Dies gibt Menschen eine kompakte Überprüfungsfläche und der nächsten Agentensitzung einen vertrauenswürdigen Ausgangspunkt.

Die beste Übergabe ist nicht "hier ist das Gespräch."

Es ist "hier ist der Zustand, die Nachweise und das ungelöste Risiko."

14. Jeder Fehler sollte das Harness verbessern

Die schwächsten Teams beheben die fehlgeschlagene Ausgabe.

Die stärksten Teams beheben auch das System, das sie ermöglicht hat.

Frage nach einem Fehler:

1War der Aufgabenvertrag mehrdeutig?
2War wichtiger Kontext unsichtbar?
3War das falsche Tool verfügbar?
4Fehlte eine Vorbedingung?
5War das Ergebnis nicht überprüfbar?
6Wurde die Richtlinie im Prompt belassen?
7War die Wiederherstellung zu breit?
8War die Ablaufverfolgung unzureichend?

Wandle dann die Lektion in eine wiederverwendbare Verbesserung um.

1Fehler
2  -> Diagnose
3      -> neuer Sensor, Regel, Karte, Test oder Tool-Vertrag
4          -> zukünftige Durchläufe verbessern sich automatisch

Dies ist das Harness-Schwungrad.

Das System wird zuverlässiger, weil Fehler Infrastruktur hinterlassen.

Eine korrigierte Antwort hilft einem Durchlauf.

Ein korrigiertes Harness hilft jedem zukünftigen Durchlauf.

15. Auch Harnesses verfallen

Mehr Harness ist nicht immer besser.

Modelle verbessern sich. Tools verbessern sich. Aufgaben ändern sich. Alte Sicherheitsvorkehrungen können unnötige Reibung werden.

Ein Workaround, der für das gestrige Modell erstellt wurde, kann das heutige Modell daran hindern, eine bessere Strategie zu verwenden.

Dies erzeugt Harness-Verfall:

1alte Modelleinschränkung
2  -> Harness-Workaround
3      -> Modell verbessert sich
4          -> Workaround bleibt bestehen
5              -> System wird langsamer oder weniger leistungsfähig

Behandle Harness-Komponenten wie Produktionscode.

Messe, ob sie noch einen Mehrwert bieten.

Frage für jeden Router, Evaluator, jede Speicherschicht und Wiederholungsregel:

• Welchen Fehler verhindert dies?
• Wie oft tritt dieser Fehler noch auf?
• Welche Latenz und Komplexität fügt dies hinzu?
• Kann dasselbe Ergebnis jetzt einfacher erzielt werden?
• Was passiert, wenn wir es entfernen?

Das beste Harness ist nicht das größte.

Es ist das kleinste System, das zuverlässig die Lücke zwischen Absicht und Nachweis schließt.

Baue, um zu löschen.

16. Das minimal lebensfähige Harness

Du benötigst keine Orchestrierungsplattform, um zu beginnen.

Baue das Harness in Schichten.

Stufe 1: Eine begrenzte Aufgabe

• Ziel
• Umfang
• Einschränkungen
• Abnahmeprüfungen

Stufe 2: Eine lesbare Umgebung

• Projektkarte
• Befehle
• lokale Anweisungen
• bekannte Abhängigkeiten

Stufe 3: Kontrollierte Aktionen

• typisierte Tools
• Argumentvalidierung
• Pfad- und Berechtigungsgrenzen
• strukturierte Ergebnisse

Stufe 4: Dauerhafte Ausführung

• expliziter Ausführungszustand
• Prüfpunkte
• Entscheidungen
• Lektionen

Stufe 5: Nachweise

• deterministische Prüfungen
• adversariale Verifikation
• Änderungsquittung

Stufe 6: Wiederherstellung und Lernen

• Fehlerklassifizierung
• begrenzte Wiederholungen
• Eskalation
• Harness-Updates aus wiederkehrenden Fehlern

Baue die kleinste Schicht, die den Fehler beseitigt, den du tatsächlich hast.

Beginne nicht mit einer Multi-Agenten-Architektur, weil ein einzelnes Prompt gelegentlich Klärung benötigt.

Komplexität sollte durch beobachtete Fehler verdient werden.

17. Eine wiederverwendbare Harness-Spezifikation

Bevor du einem Agenten sinnvolle Autonomie gibst, definiere dies:

1AGENTEN-HARNESS-SPEZIFIKATION
2
31. VERTRAG
4   Ziel:
5   Umfang:
6   Einschränkungen:
7   Abnahmenachweise:
8
92. KONTEXT
10   immer geladene Karte:
11   Abrufquellen:
12   lokale Anweisungen:
13   Aktualitätsregeln:
14
153. TOOLS
16   erlaubte Tools:
17   Vorbedingungen:
18   Nebenwirkungen:
19   Erfolgsnachweise:
20   Timeout- und Wiederholungsrichtlinie:
21
224. ZUSTAND
23   Fakten:
24   Entscheidungen:
25   Fortschritt:
26   Lektionen:
27   Prüfpunktformat:
28
295. RICHTLINIE
30   automatische Aktionen:
31   genehmigungspflichtige Aktionen:
32   verbotene Aktionen:
33   Budgetgrenzen:
34
356. VERIFIKATION
36   deterministische Prüfungen:
37   adversariale Prüfungen:
38   Abnahmeregel:
39
407. WIEDERHERSTELLUNG
41   Fehlerklassen:
42   Wiederholungsgrenzen:
43   Eskalationsbedingungen:
44   sicherer Rollback:
45
468. BEOBACHTBARKEIT
47   Ablaufverfolgungsereignisse:
48   Metriken:
49   endgültige Änderungsquittung:

Wenn diese Felder undefiniert sind, ist der Agent nicht autonom.

Er improvisiert.

18. Messe das System auf der richtigen Ebene

Die Token-Anzahl ist nicht die endgültige Metrik.

Auch nicht die Anzahl der versuchten Aufgaben.

Die nützliche Einheit ist akzeptierte Arbeit.

Eine praktische Metrik ist:

1akzeptierte Ausgaben
2------------------------------
3menschliche Überprüfungsminuten + Durchlaufkosten

Verfolge auch:

• Erstakzeptanzrate
• Wiederherstellungsrate nach Tool-Fehler
• wiederholte Fehlerrate
• menschliche Eingriffe pro Aufgabe
• unbelegte Fertigstellungsbehauptungen
• Zeit von Anfrage bis verifiziertem Ergebnis
• Harness-Overhead nach Komponente

Dies verhindert eine häufige Illusion:

Ein Agent kann hochproduktiv aussehen, während er teure Überprüfungsarbeit erzeugt.

Das Ziel ist nicht mehr Agentenaktivität.

Es ist mehr vertrauenswürdige Ergebnisse pro Einheit menschlicher Aufmerksamkeit.

19. Wann du kein schweres Harness benötigst

Nicht jeder Modellaufruf benötigt ein Betriebssystem.

Verwende ein einfaches Prompt, wenn:

• die Aufgabe kurz ist
• die Ausgabe leicht zu überprüfen ist
• Fehler billig sind
• keine externen Nebenwirkungen auftreten
• der Benutzer in der Schleife bleibt

Füge ein Harness hinzu, wenn:

• die Arbeit mehrere Tools oder Sitzungen umfasst
• sich die Umgebung ändern kann
• Aktionen reale Konsequenzen haben
• die Fertigstellung schwer manuell zu beurteilen ist
• derselbe Fehler wiederholt auftritt
• die menschliche Überprüfung zum Engpass wird

Der Zweck eines Harnesses ist nicht, eine Demo ausgefeilt aussehen zu lassen.

Es ist, reale Arbeit zuverlässig zu machen.

Der wirkliche Wandel

Die erste Generation von KI-Produkten wurde um Prompts herum gebaut.

Die nächste Generation wird um Umgebungen herum gebaut.

Die Frage ist nicht mehr nur:

Wie bringen wir das Modell dazu, besser zu antworten?

Sie ist:

Wie bauen wir ein System, in dem gute Aktionen einfach sind, gefährliche Aktionen kontrolliert werden, Fehler sichtbar sind und die Fertigstellung beweisbar ist?

Das ist der Wandel vom Prompt Engineering zum Harness Engineering.

Das Modell liefert Intelligenz.

Das Harness liefert Struktur.

Zusammen erzeugen sie zuverlässige Ausführung.

Wenn dein Agent ständig auseinanderfällt, hör auf, dem Prompt Adjektive hinzuzufügen.

Baue die Umgebung, die er braucht, um erfolgreich zu sein.

Wenn du es bis hierher geschafft hast

Lesezeichen für diesen Leitfaden.

Folge @LunarResearcher auf X

Abonniere meinen Substack

Sende diesen Artikel an jemanden, der immer noch versucht, jeden Agentenfehler mit einem längeren Prompt zu beheben.