Einen Agenten an aktueller Arbeit testen, bevor er etwas ändern darf

Was Schattenbetrieb hier bedeutet

Die Idee stammt aus dem Release Engineering. Martin Fowler beschreibt Dark Launching als Aufruf neuen Backend-Verhaltens in Produktion, ohne dass Nutzer das Ergebnis sehen, und Parallelbetrieb als gleichzeitiges Ausführen alter und neuer Implementierungen mit Vergleich der Ergebnisse. Das SRE Workbook von Google beschreibt Traffic Teeing, bei dem eine Kopie des Produktionsverkehrs an eine neue Version geht und deren Antworten verworfen werden, und merkt an, dass dies für zustandsbehaftete Systeme schwieriger einzurichten ist.

Ein Prozessagent ist genau so ein System. Sein Nutzen liegt in den Änderungen, die er vornimmt; der Schattenbetrieb muss daher das Lesen, das echt stattfindet, vom Schreiben trennen, das nur vorgeschlagen wird.

Sicherstellen, dass er nichts ändern kann

• Geben Sie dem Agenten Zugangsdaten, die in den Zielsystemen selbst nur lesen dürfen. Eine Anweisung im Prompt ist keine Kontrolle
• Ersetzen Sie jedes schreibende Tool durch einen Rekorder, der den vollständigen vorgeschlagenen Aufruf, seine Argumente und die Fall-ID speichert
• Blockieren Sie ausgehende E-Mails und Nachrichten auf Netzwerk- oder Gateway-Ebene
• Prüfen Sie Lesezugriffe auf Nebenwirkungen: eine Nachricht als gelesen markieren, einen Datensatz sperren, ein API-Kontingent verbrauchen, in ein Audit-Log schreiben
• Belegen Sie den Aufbau mit einem Test: Der Agent versucht im Schattenbetrieb einen Schreibvorgang, und dieser muss scheitern

Das Aufzeichnen von Schreibvorgängen hat selbst eine Nebenwirkung. Spätere Schritte, die zurücklesen, was der Agent geschrieben hat, etwa eine neue Buchungsnummer oder einen geänderten Status, finden nichts. Geben Sie dem Schattenlauf entweder eine isolierte Kopie des Zustands, den er ändert, etwa einen Sandbox-Mandanten oder einen simulierten Datenspeicher, der spätere Lesezugriffe stimmig beantwortet, oder beenden Sie jeden Schattenlauf beim ersten Schreibvorgang und vergleichen nur bis dahin. Sonst scheitern oder verzweigen spätere Schritte aus Gründen, die nichts über den Agenten aussagen.

Fowler nennt als ursprünglichen Zweck des Dark Launching, zusätzliche Last vor dem Release zu messen. Das gilt auch hier: Ein Agent, der jeden Fall liest, erzeugt zusätzlichen Verkehr auf Produktionssystemen; stimmen Sie Grenzen mit deren Verantwortlichen ab.

Vorschläge mit Entscheidungen vergleichen

Ordnen Sie jedem aufgezeichneten Vorschlag zu, was eine Person schließlich mit demselben Fall getan hat. Da beide zur gleichen Zeit auf denselben Fällen arbeiten, vermeiden Sie eine Schwäche, auf die das SRE Workbook bei Vorher-nachher-Vergleichen hinweist: dass eine Änderung mit Unterschieden zwischen Wochen verwechselt wird. Sortieren Sie jeden Fall in eine dieser Gruppen:

• Übereinstimmung: gleiche Aktion und gleiche Schlüsselwerte
• Agent hat eskaliert, wo die Person den Fall abgeschlossen hat
• Abweichung, zu beurteilen von einer zweiten Fachperson, die nicht weiß, welche Seite was vorgeschlagen hat

Gehen Sie nicht davon aus, dass die Person recht hatte. Menschliche Entscheidungen sind eine Referenz, keine Wahrheit, und manche Abweichungen erweisen sich als menschliche Fehler. Auch Übereinstimmung ist kein Beweis, denn Agent und Person können sich auf dieselbe Weise irren; nehmen Sie daher auch eine Zufallsstichprobe der Übereinstimmungen in die verblindete Prüfung auf.

Eine ausgearbeitete Auswertung

Hypothetische Zahlen zur Veranschaulichung: Über drei Wochen läuft ein Rechnungsagent im Schatten bei 400 Fällen mit. Sein Vorschlag stimmt in 318 Fällen mit der Entscheidung der Person überein, 52 eskaliert er, bei 30 weicht er ab. Eine verblindete Prüfung der 30 durch eine Fachperson ergibt: 19-mal lag der Agent falsch, 8-mal die Person, 3 Fälle sind uneindeutig. Dieselbe Prüfung von zufällig ausgewählten 40 der 318 Übereinstimmungen findet 2 Fälle, in denen beide falsch lagen. Die meisten der 19 Fehler betreffen eine Lieferantengruppe mit Gutschriften.

In diesem Beispiel ergibt sich die Entscheidung aus den Kategorien, nicht aus der Schlagzeile von rund 80 Prozent Übereinstimmung. Gutschriften bleiben bei Menschen und kommen ins Testset. Standardabgleiche, die den Großteil der Übereinstimmung ausmachen, gehen in die nächste Stufe, in der der Agent mit Freigabe handelt. Bei so kleinen Zahlen braucht jede Kategorie ihre eigene Zählung, bevor jemand Schlüsse zieht.

Kriterien für das Ende des Schattenbetriebs

Halten Sie sie fest, bevor der erste Schattenfall läuft, und lassen Sie die prozessverantwortliche Person zustimmen, so wie das SRE Workbook verlangt, dass sich die Beteiligten auf ein Ziel einigen, bevor es für Entscheidungen genutzt wird. Eine typische Liste umfasst eine Mindestzahl von Fällen je Kategorie, eine akzeptable Fehlerquote bei beurteilten Fällen, gezogen aus Abweichungen und einer Stichprobe der Übereinstimmungen, keine versuchten Aufrufe außerhalb der erlaubten Tools, Kosten pro Fall im vereinbarten Budget und eine Erklärung für jeden Eskalationsgrund. Wer sie erfüllt, erreicht beaufsichtigtes Handeln, keine Autonomie.

Was der Schattenbetrieb nicht zeigen kann

Er kann den Schreibpfad nicht testen: Retries, Dublettenschutz und Fehler, die erst auftreten, wenn ein Aufruf wirklich etwas ändert. Er zeigt nicht, wie Kunden oder nachgelagerte Prozesse reagieren, und er verdoppelt die Arbeit, solange er läuft. Der Leitfaden von Anthropic zu Agenten-Evals merkt an, dass A/B-Tests echte Ergebnisse messen, aber genügend Verkehr brauchen und wenig über das Warum sagen. Der Schattenbetrieb liegt zwischen Offline-Evals und dieser Stufe. Ein guter erster Schritt: Listen Sie die schreibenden Tools Ihres Agenten auf und prüfen Sie, ob sich jedes durch einen Rekorder ersetzen lässt, ohne den Code des Agenten zu ändern.