Fester Workflow, einzelner Agent oder Multi-Agenten-System: So wählen Sie das passende Muster

Beschreiben Sie zunächst die Aufgabe, bevor Sie die Architektur wählen

Die erste Entscheidung ist nicht, wie viele Agenten gebaut werden sollen. Entscheidend ist zunächst, welche Arbeit automatisiert werden soll und woran sich ein korrektes Ergebnis erkennen lässt. Lassen sich Ziel, Eingaben und Schrittfolge präzise beschreiben, reicht möglicherweise ein herkömmliches Programm aus. Hängen einzelne Entscheidungen vom Inhalt des jeweiligen Falls ab, kann es sinnvoll sein, die Auswahl bestimmter Schritte teilweise dem Modell zu überlassen. Müssen unterschiedliche Verantwortlichkeiten bis zu einem gewissen Grad unabhängig voneinander bearbeitet werden, kann eine Kombination mehrerer Agenten in Betracht kommen. Das sind verschiedene Entwurfsoptionen – keine Rangfolge, in der jede Option automatisch fortschrittlicher oder besser wäre.

Erstellen Sie für den Vergleich der Alternativen zunächst eine kurze Aufgabenbeschreibung. Halten Sie das Ziel, die erwarteten Eingaben, die bekannten Schritte, die in der Praxis auftretenden Abweichungen, das beobachtbare Ergebnis und die Folgen eines Fehlers fest. Ergänzen Sie, welche Aktionen das System ausführen darf und welche eine Genehmigung oder menschliche Prüfung voraussetzen. So vermeiden Sie den Fehlschluss, eine Aufgabe mit vielen Schritten brauche automatisch Autonomie: Auch eine lange, aber stabile Abfolge lässt sich gut programmieren.

Die vorliegenden Quellen bieten Orientierung zur Entscheidung zwischen einem einzelnen Agenten und mehreren Agenten, stellen Entwurfsmuster vor und vergleichen Agenten mit Workflows. Die verfügbaren Auszüge enthalten jedoch keine vergleichbaren Messungen von Leistung, Kosten oder Fehlerraten dieser drei Ansätze. Die Entscheidungsmatrix und die Beispiele in diesem Leitfaden sind daher ein praktischer Analyserahmen – keine Behauptung, dass ein bestimmtes Muster generell bessere Ergebnisse erzielt.

Muster 1: deterministischer Workflow

Bei einem deterministischen Workflow legt das Programm die Abfolge der Vorgänge sowie die Bedingungen fest, unter denen ein Schritt fortgesetzt, wiederholt oder beendet wird. Ein solcher Workflow kann Aufrufe eines Modells enthalten – etwa zur Klassifizierung eines Textes oder zur Extraktion von Feldern –, ohne dass dadurch automatisch der gesamte Prozess zu einem autonomen Agenten wird. Entscheidend ist, wer den nächsten Schritt auswählt: In einem Workflow ist diese Entscheidung hauptsächlich im Code oder in einer ausdrücklich definierten Konfiguration festgelegt.

Dieses Muster eignet sich häufig, wenn die Eingaben bekannt sind, die Regeln relativ stabil bleiben, es nur wenige relevante Verzweigungen gibt und sich die Ausgabe anhand konkreter Prüfungen validieren lässt. Ein Prozess zur Annahme von Rechnungen könnte Daten extrahieren, Pflichtfelder prüfen, Beträge abgleichen und Fälle, die gegen eine Regel verstoßen, zur Überprüfung weiterleiten. Der Prozess kann Ausnahmen enthalten; das Team bildet sie jedoch mit ausdrücklichen Bedingungen ab, statt das Modell bei jedem Durchlauf eine Arbeitsroute erfinden zu lassen.

Als Entwurfskriterium hat dieser Ansatz den Vorteil, dass das Team die vorgesehene Reihenfolge untersuchen und jede Entscheidung einer Regel oder Prozessstufe zuordnen kann. Das garantiert nicht, dass die Komponenten korrekt funktionieren: Eine Extraktion kann fehlerhaft sein, und auch eine Regel kann falsch definiert sein. Die Einschränkung besteht darin, dass nicht vorgesehene Abweichungen Änderungen an Regeln, zusätzliche Zweige oder die Weiterleitung an eine Person erfordern. Häufen sich Ausnahmen, kann die Pflege des Workflows schwierig werden. Das beweist nicht automatisch, dass ein Agent nötig ist, ist aber ein Anlass, den Entwurf erneut zu prüfen.

Die Werkzeuge eines Workflows lassen sich auf die im Code vorgesehenen Aufrufe beschränken. Berechtigungen und zugängliche Daten hängen davon ab, wie das System implementiert und konfiguriert ist; sie ergeben sich nicht aus der Bezeichnung des Musters. Auch dauerhaft gespeicherte Erinnerungen sind keine notwendige Eigenschaft eines Workflows. Der für einen Durchlauf erforderliche Zustand kann gespeichert werden. Dabei sollte dieser temporäre Zustand jedoch von Informationen unterschieden werden, die über mehrere Aufgaben hinweg wiederverwendet werden.

Muster 2: einzelner Agent mit Werkzeugen

Bei einem Muster mit einem einzelnen Agenten wirkt das Modell daran mit, die nächsten Schritte anhand des Ziels, des verfügbaren Kontexts und der bereitgestellten Werkzeuge auszuwählen. Das Programm steckt weiterhin den Rahmen ab: Es legt fest, welches Ziel vermittelt wird, welche Werkzeuge verfügbar sind, welche Grenzen gelten und wann der Agent stoppt oder um Hilfe bittet. Autonomie bedeutet nicht unbegrenzte Berechtigung. Die dynamische Auswahl einer Aktion muss innerhalb der vom System festgelegten Bedingungen stattfinden.

Dieses Muster kommt infrage, wenn sich die Fälle in relevanter Weise unterscheiden und ein starrer Ablauf unpraktisch ist, die erforderlichen Fähigkeiten aber in eine begrenzte Auswahl von Werkzeugen passen. Betrachten wir interne Supportanfragen: Eine Person meldet ein Problem, für dessen Bearbeitung möglicherweise Dokumentation durchsucht, der Status eines Dienstes geprüft und eine Antwort formuliert werden muss. Der Agent könnte je nach Fall auswählen, welche dieser Abfragen nötig ist. Hat eine Aktion wichtige Folgen, kann das System darauf beschränkt werden, eine Empfehlung zur Genehmigung durch eine Person vorzubereiten.

Die Flexibilität bringt andere Anforderungen an die Evaluierung mit sich. Es genügt nicht, einen einzigen Ablauf zu prüfen. Beobachtet werden muss auch, welche Aktionen der Agent ausgewählt hat, welche Informationen er verwendet, wann er gestoppt und ob er in mehrdeutigen Fällen eine Prüfung angefordert hat. Eine zufällig richtige Endantwort belegt nicht, dass auch die dazwischenliegenden Schritte angemessen waren. Es empfiehlt sich, wichtige Entscheidungen in angemessenem Umfang zu protokollieren und sowohl abgeschlossene Fälle als auch Fälle zu prüfen, die das System abgelehnt oder weitergeleitet hat.

Werkzeuge bilden einen wesentlichen Teil der betrieblichen Grenzen: Sie beschreiben verfügbare Aktionen, ihr tatsächlicher Umfang hängt jedoch von Implementierung, Authentifizierung und Kontrollen ab. Eine natürlichsprachliche Anweisung sollte nicht als Ersatz für technische Zugriffskontrollen verstanden werden. Je nach Produkt und Entwurf kann ein Agent gar keine, nur für die aktuelle Interaktion geltende oder dauerhaft gespeicherte Informationen nutzen. Für eine erste Evaluierung sollte ausdrücklich festgelegt werden, welcher Kontext erhalten bleibt und geprüft werden, ob er erforderlich ist – statt anzunehmen, mehr gespeicherter Kontext führe zu besseren Ergebnissen.

Muster 3: Multi-Agenten-System

Ein Multi-Agenten-System bringt mehrere Komponenten mit unterschiedlichen Funktionen zusammen, die bei der Erledigung einer Aufgabe miteinander interagieren. Die Koordination kann unterschiedlich gestaltet sein: Eine Komponente kann Arbeit zuweisen, Komponenten können Ergebnisse austauschen oder das System kann eine Abfolge spezialisierter Funktionen organisieren. Die Bezeichnung allein sagt nicht, wer den Ablauf bestimmt, welche Informationen geteilt werden oder wie mit Meinungsverschiedenheiten umgegangen wird. Diese Eigenschaften müssen ausdrücklich festgelegt werden, damit sich der Entwurf evaluieren lässt.

Die Frage, mit der sich der Einsatz mehrerer Agenten begründen lässt, lautet nicht, ob das Problem groß wirkt. Entscheidend ist, ob die Trennung von Verantwortlichkeiten gegenüber einer einzelnen Arbeitseinheit oder einem expliziten Workflow einen überprüfbaren Vorteil bringt. Die Option könnte untersucht werden, wenn es klar unterscheidbare Aufgaben gibt, Kontexte besser getrennt bleiben sollten oder Tätigkeiten zunächst unabhängig voneinander Ergebnisse liefern müssen, bevor diese zusammengeführt werden. Die Aufteilung bringt jedoch Koordinationsaufwand, Kontextübergaben und zusätzliche Stellen mit sich, an denen Inkonsistenzen entstehen können. Ohne Messungen im konkreten Anwendungsfall sollte nicht behauptet werden, die Trennung verbessere die Qualität oder verkürze die Bearbeitungszeit.

Kehren wir zur Rechnung zurück. Ein hypothetischer Entwurf könnte die Dokumentextraktion, die Prüfung der Richtlinien und die Vorbereitung einer menschlichen Prüfung voneinander trennen. Vor der Umsetzung sollte das Team klären, ob diese Verantwortlichkeiten tatsächlich unabhängig sind, ob sich jede einzeln evaluieren lässt und ob das kombinierte Ergebnis besser oder leichter zu prüfen ist als ein fester Ablauf oder ein einzelner Agent mit denselben Werkzeugen. Lautet die Antwort nein, können zusätzliche Komponenten Kosten verursachen, ohne dass ein Nutzen belegt ist.

Die Interaktionen müssen nachvollziehbar sein: Es sollte sich rekonstruieren lassen, welche Komponente welche Informationen erhalten, welches Ergebnis sie erzeugt und wie dieses anschließend verwendet hat. Das erleichtert die Untersuchung von Fehlern, schließt sie aber nicht aus. Berechtigungen, Werkzeuge und gespeicherter Kontext werden durch die jeweilige Implementierung festgelegt; die Architektur löst diese Fragen nicht automatisch. Eine funktionale Trennung kann helfen, Verantwortlichkeiten einzugrenzen – allerdings nur, wenn Zugriffe und Datenaustausch ausdrücklich gestaltet und geprüft werden.

Vergleich am Beispiel und Entscheidungsmatrix

Für einen fairen Vergleich der Muster müssen Sie zunächst dieselbe Aufgabe, dieselben Fälle und dasselbe Erfolgskriterium festlegen. Beim Rechnungsbeispiel heißt das: repräsentative Dokumente, dieselben Buchhaltungsregeln und eine gemeinsame Definition dafür, was als korrekte Extraktion, angemessene Weiterleitung und akzeptabler Eintrag gilt. Ein Vergleich wäre nicht aussagekräftig, wenn ein Muster mehr Kontext, Werkzeuge oder menschliche Unterstützung erhält als ein anderes, ohne dass dies dokumentiert wird.

Die folgende Tabelle vergibt keine allgemeingültigen Punktwerte. Sie fasst Fragen zusammen, die das Team anhand von Prozessdaten, Tests und Messungen beantworten kann. „Hohe Variabilität“ sollte beispielsweise bedeuten, dass beobachtbare Unterschiede auftreten, die die erforderlichen Schritte verändern – nicht einfach, dass das Team den Prozess noch nicht kennt. Ebenso setzt „leicht zu prüfen“ einen Test oder ein Abnahmekriterium voraus und nicht nur einen subjektiven Eindruck.

Werkzeuge, Berechtigungen, gespeicherter Kontext und Aufsicht

Diese Elemente werden nicht automatisch durch die Wahl eines Musters festgelegt. Das Muster verändert, wo Entscheidungen getroffen werden und wie viele Komponenten beteiligt sind. Der tatsächliche Umfang hängt jedoch von den angebundenen Werkzeugen, den Zugriffskontrollen, den bereitgestellten Daten und der Prüflogik ab. Deshalb sollte eine Architektur nicht allein deshalb als „sicher“ oder „kontrolliert“ bezeichnet werden, weil sie ein Workflow oder ein System mit mehreren Agenten ist.

Dokumentieren Sie für jedes Werkzeug die verfügbare Aktion, ihre Auswirkungen und die Personen oder Komponenten, die sie aufrufen dürfen. Unterscheiden Sie Lesevorgänge von Aktionen, die Daten ändern, Nachrichten versenden oder andere externe Auswirkungen haben. Bei einem Workflow kann das Programm jedes Werkzeug an einer vorgesehenen Stelle aufrufen. Bei einem Agenten kann das Modell ein Werkzeug aus den erlaubten Optionen auswählen. Bei einem Multi-Agenten-System muss geklärt werden, welche Komponenten auf welche Werkzeuge zugreifen dürfen und wie verhindert wird, dass eine weitergegebene Ausgabe eine nicht genehmigte Aktion auslöst.

Legen Sie für Speicher und Kontext fest, was während eines Durchlaufs erhalten bleibt und was gegebenenfalls für einen späteren Durchlauf wiederverwendet wird. Dokumentieren Sie den Grund dafür und prüfen Sie die Auswirkungen mit Testfällen. Zusätzlicher gespeicherter Kontext kann helfen, erforderliche Informationen verfügbar zu halten, aber auch veraltete oder irrelevante Inhalte einbringen. Diese Möglichkeit sollte als zu prüfendes Entwurfsrisiko behandelt werden, nicht als unvermeidliches Ergebnis.

Menschliche Aufsicht braucht eine konkrete Funktion. Eine Person kann Aktionen genehmigen, Ausnahmen bearbeiten, Ergebnisse prüfen oder den Prozess stoppen. Kommt die Prüfung zu spät, verhindert sie womöglich nicht mehr die Wirkung, die sie kontrollieren sollte. Muss jeder Schritt geprüft werden, kann die Automatisierung unnötig werden. Legen Sie Prüfpunkte anhand der möglichen Fehlerfolgen fest und messen Sie, wie viele Fälle geprüft werden, wie viel Arbeit die Prüfung erfordert und welche Meinungsverschiedenheiten auftreten.

Erste Evaluierung: erst messen, dann mehr Autonomie zulassen

Ein aussagekräftiger Pilot beginnt nicht mit einer Vorführung, bei der alles reibungslos läuft. Er beginnt mit einer Fallauswahl, die die geplante Nutzung abbildet: häufige Fälle, bekannte Grenzfälle, unvollständige Dokumente, mehrdeutige Eingaben und Ausnahmen, bei denen das System anhalten muss. Halten Sie den bisherigen Prozess als Vergleichsbasis fest und dokumentieren Sie die Bedingungen jedes Tests. Werden Anweisungen, Werkzeuge oder Regeln geändert, sollte die Änderung protokolliert werden, damit ein möglicher Effekt nicht fälschlich der Architektur zugeschrieben wird.

Bewerten Sie das Ergebnis und den Weg dorthin getrennt. Zu den Fragen zum Ergebnis zählen: Wurden die richtigen Daten extrahiert? Wurde der zulässige Ablauf gewählt? Wurde erkannt, dass eine Prüfung nötig ist? Wurde eine Aktion trotz unzureichender Informationen vermieden? Fragen zum Prozess betreffen unter anderem die Zwischenschritte, die verwendeten Werkzeuge, die Relevanz der abgerufenen Informationen und den richtigen Zeitpunkt für einen Abbruch. Bei Agenten und Multi-Agenten-Systemen helfen solche Aufzeichnungen zu erkennen, ob eine akzeptable Antwort auf einem angemessenen Weg zustande kam.

Legen Sie vorab Kriterien fest, nach denen der Test fortgesetzt, eingegrenzt oder beendet wird. Treten die schwerwiegendsten Fehler bei der Aktionsauswahl auf, müssen möglicherweise Werkzeuge eingeschränkt oder diese Entscheidung wieder dem Code überlassen werden. Lassen sich Fälle nicht konsistent bewerten, sollte zunächst die Erfolgsdefinition verbessert werden. Korrigiert die menschliche Prüfung regelmäßig dieselbe Art von Ergebnis, benötigt das System vielleicht eine ausdrückliche Regel, bessere Eingaben oder eine Validierungsstufe – nicht unbedingt zusätzliche Agenten.

Wann Sie keinen Agenten einsetzen oder die Autonomie reduzieren sollten

Es kann die richtige Entscheidung sein, keinen Agenten einzusetzen: etwa wenn sich ein bekannter Routineprozess mit herkömmlichem Code lösen lässt, die Regeln stabil und überprüfbar sind oder sich das Ergebnis nicht zuverlässig kontrollieren lässt. Auch wenn Fehler schwerwiegende Folgen haben und Aktionen kaum rückgängig zu machen sind, kann es besser sein, eine Person in den Prozess einzubeziehen. In diesen Fällen kann die Automatisierung darauf beschränkt werden, Daten aufzubereiten, Informationen zusammenzufassen oder einen Ablauf vorzuschlagen, ohne ihn auszuführen.

Kehren Sie zu einem festen Workflow zurück oder begrenzen Sie den Agenten auf eine Stufe, wenn die Aktionsauswahl keinen messbaren Vorteil bringt, der Agent unnötige Werkzeuge verwendet, sich Ausnahmen inzwischen klar als Regeln darstellen lassen oder die Entscheidungsfindung schwer nachvollziehbar ist. Bei Meinungsverschiedenheiten zwischen Komponenten eines Multi-Agenten-Systems sollten Sie prüfen, ob die Aufteilung tatsächlich hilft. Für den konkreten Fall könnte ein expliziter Ablauf mit Validierungen leichter zu testen sein – das muss das Team jedoch überprüfen.

Wenn Sie eine Kombination von Agenten evaluieren, beginnen Sie mit getrennten Funktionen, für die Eingaben, Ausgaben und Abnahmekriterien definiert sind. Zerlegen Sie eine Aufgabe nicht intuitiv in zahlreiche abstrakte Rollen. Testen Sie zuerst eine einfache Version, beobachten Sie, wo sie scheitert, und erweitern Sie sie nur dann, wenn ein konkretes Problem vorliegt, das sich durch die Aufteilung lösen lässt. Auch eine der bereitgestellten Sekundärquellen empfiehlt, mit dem einfachsten passenden Muster zu beginnen. Hier wird das als Entwurfsheuristik aufgegriffen, die im jeweiligen Anwendungsfall überprüft werden sollte – nicht als allgemeingültiges Gesetz.

Abschließende Checkliste zur Dokumentation der Entscheidung

Eine Architekturentscheidung lässt sich besser überprüfen, wenn sie auch nach Beobachtungen unter realen Bedingungen nachvollziehbar bleibt. Dokumentieren Sie, welches Problem gelöst werden soll, welche Alternativen verglichen wurden und welche Nachweise ausschlaggebend waren. Die Wahl muss nicht dauerhaft sein: Ändern sich die Variabilität der Fälle, die Fehlerfolgen oder die verfügbaren Werkzeuge, kann sich auch das angemessene Muster ändern.

Für einen vertieften Vergleich zwischen einzelnen und mehreren Agenten können Sie den in den Quellen genannten Leitfaden von Microsoft Learn heranziehen. Zum Vergleich von Agenten und Workflows lässt sich die Dokumentation von UiPath nutzen; beachten Sie dabei, dass es sich um Anbieterdokumentation handelt. Die Seiten zu Entwurfsmustern von Microsoft Learn und Google Cloud bieten architektonische Orientierung. Ihre Empfehlungen sollten anhand der Anforderungen und Einschränkungen des eigenen Teams bewertet werden. Diese Referenzen ersetzen keine eigenen Tests und belegen für sich genommen keine Leistungsergebnisse für eine konkrete Aufgabe.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.