Konversation ist kein Kontrollfluss
Zwei Agenten, die miteinander sprechen, lösten unsere Aufgabe in der Demo und wurden im Betrieb nicht mehr debugbar. Das Muster war nicht falsch — unsere Verwendung war es. Hier verläuft für uns seitdem die Grenze.
Die Demo, die den Betrieb nicht überlebt hat
Die Aufgabe war Dokumenteneingang: eingehendes Dokument klassifizieren, Felder extrahieren, gegen ein Register prüfen und dann ablegen oder eskalieren. Wir haben das als zwei Agenten im Gespräch gebaut — einer schlägt vor, einer prüft — weil es sich sauber las und Sonderfälle abfing, ohne dass wir sie aufzählen mussten.
Es funktionierte. Dann funktionierte es bei etwa einem von dreißig Dokumenten nicht mehr, und wir konnten nicht sagen warum. Es gab keinen Schritt, auf den man zeigen konnte. Das Protokoll zeigte zwei Agenten, die sich ausführlich und in flüssiger Prosa auf etwas Falsches einigten.
Worin das Muster gut ist
AutoGen, im August desselben Jahres von Wu und Kollegen veröffentlicht, ist die klarste Ausformulierung dieses Ansatzes: Anwendungen aus mehreren Agenten, die sich zur Lösung einer Aufgabe unterhalten, mit Gesprächsmustern, die sich in natürlicher Sprache oder in Code programmieren lassen, und mit Menschen und Werkzeugen im selben Austausch.
Die Stärke ist echt. Konversation fängt Fälle ab, die man nicht geplant hat, weil die Agenten sich gegenseitig fragen können, statt an einem unerwarteten Zweig zu scheitern. Für Exploration und für Probleme, deren Form man noch nicht kennt, ist das genau richtig.
Wo es uns etwas gekostet hat
Der Betrieb stellt andere Fragen. Welcher Schritt ist gescheitert. Wie war der Zustand dabei. Ist ein Retry gefahrlos. Eine Konversation beantwortet keine davon direkt: Der Zustand verteilt sich über ein Protokoll, die Schrittgrenze ist implizit, und ein Retry spielt einen Dialog erneut ab, statt einen Prozess fortzusetzen.
Unser Fehler bei einem von dreißig war, dass zwei Agenten sich auf ein falsch gelesenes Feld einigten und einander bestätigten. In einem Zustandsautomaten ist das ein Validierungsfehler an einem benannten Schritt. In einer Konversation ist es ein Absatz.
Was wir heute tun
Der Prozess ist ein expliziter Zustandsautomat: benannte Schritte, ein typisiertes Zustandsobjekt und ein definierter Übergang aus jedem Schritt heraus. Agenten leben innerhalb der Schritte, dort wo ein Modell einer Regel wirklich überlegen ist — ein mehrdeutiges Dokument einordnen, entscheiden ob zwei Adressen dieselbe Einheit bezeichnen.
Der Übergang selbst ist Code. Er prüft die extrahierten Felder gegen ein Schema, und ein Schritt endet mit fertig, gescheitert oder eskaliert. Ein Retry setzt am letzten abgeschlossenen Schritt an, statt eine Diskussion zu wiederholen.
| Frage aus dem Betrieb | Wie beide antworten |
|---|---|
| Welcher Schritt ist gescheitert | Konversation: Protokoll lesen. Automat: steht im Datensatz |
| Wie war der Zustand | Konversation: rekonstruieren. Automat: ein typisiertes Objekt |
| Ist ein Retry gefahrlos | Konversation: unklar. Automat: ab letztem Abschluss fortsetzen |
| Wohin kommt eine neue Prüfung | Konversation: in einen Prompt. Automat: an den Übergang |
Wo wir sie weiterhin sprechen lassen
Wir haben das Muster nicht verboten. Innerhalb eines einzelnen Schritts, wo das Ergebnis geprüft wird, bevor es den Schritt verlässt, liefern ein Vorschlagender und ein Prüfender bessere Ergebnisse als ein einzelner Aufruf — besonders bei Ermessensfragen, wo ein zweiter Durchgang Selbstüberschätzung abfängt.
Die Regel, an der wir festhalten, betrifft den Geltungsbereich: Agenten dürfen innerhalb eines Schritts verhandeln, niemals über einen hinweg. An der Schrittgrenze wird Zustand festgeschrieben, und festgeschriebener Zustand ist das, was ein System betreibbar macht.
Was wir daraus nicht schließen
Wir schließen nicht, dass Konversationsframeworks das falsche Werkzeug sind. Für Forschung, für Prototypen und für Probleme, deren Ablauf tatsächlich nicht im Voraus feststeht, ist die Flexibilität der Punkt, und unsere Struktur wäre nur im Weg.
Wir behaupten auch nicht, dass der Zustandsautomat den Agenten richtig macht. Er macht die Fehler des Agenten auffindbar — eine andere und bescheidenere Aussage, aber die, an der sich entscheidet, ob ein System von Leuten betrieben werden kann, die es nicht gebaut haben.