KI-Agenten zuverlässig machen: ein Schritt-für-Schritt-Plan von der Messung bis zur autonomen Arbeit

Warum ein Agent unzuverlässig ist, selbst wenn das Modell stark ist

Die Zuverlässigkeit eines Agenten ist eine Eigenschaft des gesamten Systems, nicht des Modells. Eine lange Aufgabe besteht aus Dutzenden Schritten, und Fehler summieren sich: Bei 95 % richtigen Schritten kommt eine Kette von zehn ohne einen einzigen Fehler in etwa 60 % der Läufe durch (0.95^10 ≈ 0.60), bei fünfzig weniger als 10 %. Die Genauigkeit des Modells können Sie nicht erhöhen, wohl aber einen Fehler genau an derselben Stelle abfangen und ihn günstig machen. Genau das leistet das Harness: Anweisungen, Werkzeuge, Umgebung, Zustand und Rückmeldung rund um das Modell.

Im Folgenden ein Plan, der von der „Bauchgefühl“-Arbeit zu messbarer Zuverlässigkeit und weiter zur autonomen Arbeit führt. Die Schritte sind nach ihrem Nutzen geordnet: Jeder folgende baut auf dem vorherigen auf.

Schritt 1. Hören Sie auf, nach Gefühl zu bewerten

Ein Ingenieur ist überzeugt, dass ein neuer Prompt alles verändert hat, ein anderer sieht keinen Unterschied, und gemessen hat niemand etwas. Beginnen Sie mit einem Fehlerprotokoll: Jedes Mal, wenn der Agent hängen bleibt, etwas kaputt macht oder ein defektes Feature als fertig meldet, notieren Sie eine Zeile.

| Datum | Aufgabe          | was passiert ist               | Teilsystem     |
|-------|------------------|--------------------------------|----------------|
| 10.10 | Warenkorb-Rabatte| „fertig“, E2E nicht gestartet  | Rückmeldung    |
| 10.10 | Zahlungs-Webhook | Datenbank ließ sich nicht starten | Umgebung    |
| 11.10 | API-Refactoring  | verworfene Lösung wiederholt   | Zustand        |

Die Spalte „Teilsystem“ ist entscheidend. Nach einer Woche zeigt sich, wo der Engpass liegt, und Sie reparieren genau diesen statt alles auf einmal. Zuverlässigkeit über erfolgreiche Läufe zu messen ist ein Fehler: Das Protokoll der Ausfälle zeigt, wo der Agent tatsächlich scheitert.

Schritt 2. Führen Sie zwei Kennzahlen ein: MTBF und MTTR

Zuverlässigkeit besteht aus zwei Zahlen. MTBF (mittlere Zeit zwischen Ausfällen) bedeutet beim Agenten: wie viele Schritte er schafft, bevor er hängen bleibt. MTTR (mittlere Wiederherstellungszeit) ist die Zeit, bis er nach einem Ausfall wieder arbeitsfähig ist. Die Verfügbarkeit steigt, wenn die erste Zahl wächst oder die zweite sinkt.

Das Rennen um einen Agenten, der nie Fehler macht, ist endlos. Die MTTR lässt sich meist innerhalb eines Tages senken. Beginnen Sie daher mit der zweiten Zahl.

Schritt 3. Machen Sie Fehler günstig

Autonomie ist nicht dann vertretbar, wenn der Agent aufgehört hat, Fehler zu machen, sondern wenn die Kosten eines Fehlers nahezu auf null gesunken sind. Dafür braucht es drei Dinge:

• Saubere kleine Commits — jede Änderung lässt sich mit einem Befehl zurücknehmen.
• Isolation — der Agent arbeitet in einem eigenen Branch oder einer eigenen Arbeitskopie, etwa über git worktree, und in einer Sandbox ohne Zugriff auf die Produktion.
• Ein Reset-Skript für die Umgebung — Datenbank, Abhängigkeiten und Dienste kehren mit einem Befehl in den Ausgangszustand zurück.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # Datenbank neu anlegen, Migrationen anwenden, Fixtures laden

Messen Sie mit der Stoppuhr, wie lange die vollständige Rückkehr in den Arbeitszustand dauert. Das ist Ihre MTTR. Begrenzen Sie außerdem den Schaden: eine Obergrenze für den Umfang des Diffs einer Aufgabe und ein Verbot, Dateien außerhalb ihres Bereichs zu ändern.

Schritt 4. Schließen Sie die Rückkopplungsschleife

Ohne Prüfungen ist der Agent sein einziger Richter, und er hält die Arbeit aufrichtig für erledigt. Geben Sie ihm Befehle, mit denen er sich selbst prüft, und machen Sie diese verpflichtend.

• Fail-fast: Eine Prüfung bricht beim ersten Fehler mit einer klaren Meldung ab, statt hundert Zeilen Rauschen auszugeben.
• Schnelle Prüfungen nach jeder Änderung: Linter und Typprüfung über einen Hook des Agenten.
• Redundanz: eine zweite, unabhängige Prüfung derselben Eigenschaft — ein E2E-Szenario über den Unit-Tests. Grüne Unit-Tests beweisen nicht, dass das Feature beim Nutzer funktioniert.

Formulieren Sie das Kriterium „fertig“ als prüfbare Bedingung: „Das E2E-Szenario der Bestellung mit Promocode läuft durch“, nicht „Rabatt umgesetzt“.

Schritt 5. Lagern Sie das Gedächtnis in Dateien aus

Der Agent erinnert sich nicht an die letzte Sitzung. Alles, was zum Weitermachen nötig ist, muss im Repository liegen: das Ziel, das Erledigte und wie es geprüft wurde, Entscheidungen mit Begründung, Sackgassen, der nächste Schritt. Ein gutes Zeichen: Eine neue Sitzung beginnt, wenn sie nur das Repository und das Wort „mach weiter“ erhält, sofort mit sinnvoller Arbeit.

Eine lange, verdichtete Gesprächshistorie erzeugt das Gefühl von Kontinuität, verliert aber das Wertvollste: die Gründe für verworfene Entscheidungen. Ein bewusster Neustart der Sitzung mit vollständigem schriftlichem Zustand ist meist günstiger.

Schritt 6. Eine Aufgabe nach der anderen

Littles Gesetz: Die Zahl der gleichzeitig laufenden Aufgaben ist gleich der Eingangsrate multipliziert mit der Verweildauer einer Aufgabe im System. Bei fester Durchsatzleistung beschleunigen parallele Aufgaben nichts, sie verlängern nur jede einzelne. Für einen Agenten ist das noch strenger: Drei Features bedeuten drei Domänenmodelle im selben Kontextfenster.

• Halten Sie WIP=1: ein Feature, bis es ein geprüftes Ergebnis hat.
• Schneiden Sie Aufgaben passend zu: eine prüfbare Fähigkeit für Nutzer, 1 bis 3 Dateien, eine Prüfung, die in unter einer Minute läuft.
• Legen Sie ein BACKLOG.md an — ein Ventil für „nebenbei“. Bemerkt der Agent einen benachbarten Mangel, kommt eine Zeile ins Backlog, statt eigenmächtig zu ändern.

Schritt 7. Trennen Sie Ausführenden und Prüfer

Die Selbstbewertung des Agenten ist eine schwache Bremse: Dieselbe Sitzung, die den Code geschrieben hat, hält ihn tendenziell für richtig. Lassen Sie das Ergebnis von einem eigenen Sub-Agenten oder einer eigenen Sitzung bewerten, die nur die Anforderung, den Diff und die Prüfergebnisse erhält — ohne die Überlegungen des Ausführenden. Das Urteil des Prüfers stützt sich auf maschinelle Prüfungen, nicht auf „sieht gut aus“.

Schritt 8. Lassen Sie den Agenten in einen autonomen Zyklus

Das Harness macht einen einzelnen Lauf zuverlässig, der Zyklus macht eine Folge von Läufen autonom. Ein Zyklus auf einem schwachen Harness vervielfacht Fehler nur schneller, deshalb kommt dieser Schritt zuletzt. Der einfachste Zyklus lässt sich in drei Zeilen beschreiben:

Ziel:        E2E-Szenario Zahlung mit Promocode läuft durch
Prüfung:     make lint && make test && make e2e
Abbruch:     Ziel erreicht ODER 15 Versuche ODER 2 Stunden → Mensch rufen

Wählen Sie den Zyklustyp nach der Aufgabe. Hat die Arbeit eine Ziellinie, brauchen Sie einen zielorientierten Zyklus mit Gedächtnis für den Fortschritt, einem unabhängigen Prüfer und einem Schrittbudget. Gibt es kein Ende (morgendliche CI-Prüfung, Sichtung neuer Fehler), eignet sich ein zeitgesteuerter Zyklus. Ein häufiger Fehler ist, eine Aufgabe mit Ende zeitgesteuert laufen zu lassen: Jeder Lauf beginnt sie dann von vorn.

Regeln für sichere Autonomie

• Die Abbruchbedingung muss rein maschinell prüfbar sein, dazu ein Limit für Versuche und Budget.
• Eskalation: Legen Sie im Voraus fest, was dem Zyklus nicht anvertraut wird (Produktionsmigrationen, Geld, Löschen von Daten).
• Steckt eine Aufgabe fest und wächst der Fortschritt nicht wirklich, ist das ein Signal, sie einem Menschen zu übergeben, statt weiterzudrehen.
• Lesen Sie die Diffs. Das Tempo des Zyklus darf Ihr Lesetempo nicht übersteigen, sonst verstehen Sie Ihre eigene Codebasis nicht mehr.

Häufige Fehler auf diesem Weg

Mit dem Umschreiben der Anweisungen beginnen

Die beliebteste Reaktion auf einen Fehler des Agenten ist, eine Regel in AGENTS.md zu ergänzen. Nach ein paar Monaten ist die Datei auf Hunderte Zeilen angewachsen, und die wichtigen Regeln gehen darin unter. Zeigt das Fehlerprotokoll, dass der Agent die Prüfungen nicht ausgeführt hat, behebt man die Rückmeldung: einen Prüfbefehl und einen Hook, nicht einen weiteren Absatz Text.

Alles auf einmal reparieren

Man möchte alle fünf Teilsysteme des Harness gleichzeitig verbessern. Dann ist aber unklar, was tatsächlich geholfen hat. Bewerten Sie jedes Teilsystem auf einer Skala von 1 bis 5, investieren Sie eine halbe Stunde in das schwächste und lassen Sie denselben Satz von fünf typischen Aufgaben vorher und nachher laufen. Der Unterschied im Fehlerprotokoll zeigt, ob es einen Effekt gab.

„Tests sind grün“ mit „das Feature funktioniert“ verwechseln

Der Agent kann einen Test schreiben, der seine eigene Implementierung prüft statt der Anforderung. Ein solcher Test ist immer grün. Der Schutz ist eine Prüfung auf Nutzerebene (ein E2E-Szenario), die vor der Umsetzung oder von einem unabhängigen Prüfer geschrieben wird, sowie die Regel, dass der Agent keinen Test ändert, damit er durchläuft.

Prüfungen aus Geschwindigkeitsgründen abschalten

Langsame Prüfungen verleiten dazu, sie „diesmal“ zu überspringen. Besser ist es, sie zu trennen: schnelles Linting und Typprüfung nach jeder Änderung, die vollständige Testsuite und E2E vor dem Wort „fertig“. So bleibt die Rückmeldungsschleife kurz und stört die Arbeit nicht.

Die Ablation als ersten Schritt betrachten

Man kann Teilsysteme des Harness nacheinander abschalten und beobachten, wie stark die Qualität sinkt. Das ist eine nützliche Prüfung, aber aufwendig und nicht der erste Schritt: Zuerst zeigt das Fehlerprotokoll den Engpass, die Ablation bestätigt nur die Hypothese. Ein Abfall von null beim Abschalten einer Komponente heißt nicht, dass sie nutzlos ist — vielleicht hat die gewählte Aufgabenmenge sie einfach nicht gebraucht.

Die Reifeleiter

Fazit

So machen Sie einen KI-Agenten zuverlässig: messen, das schwache Teilsystem über das Fehlerprotokoll finden, Fehler günstig machen, die Rückmeldungsschleife schließen, das Gedächtnis in Dateien auslagern, eine Aufgabe nach der anderen halten und Ausführenden und Prüfer trennen. Erst danach wird ein autonomer Zyklus mit maschinell prüfbarer Abbruchbedingung sicher. Jeder Schritt dieses Plans wird im Kurs zum Harness Engineering praktisch behandelt.