Best Practices für die Orchestrierung von KI-Agenten: Umgang mit Fehlern, Genehmigungen und Wiederholungsversuchen

Mehrere Agenten am selben Projekt arbeiten zu lassen, klingt äußerst effizient. Einer plant die Arbeit, ein anderer übernimmt das Design, und ein dritter schreibt den Code. Das funktioniert – bis es nicht mehr funktioniert. Und Ausfälle passieren häufiger, als einem lieb ist.

Um solche Ausfälle zu verhindern, ist sorgfältiges Workflow-Engineering nötig. Sehen wir uns also an, was orchestrierte Workflows unzuverlässig macht, und betrachten wir Best Practices für die Orchestrierung, die Zuverlässigkeit im Produktivbetrieb gewährleisten.

Was ist KI-Agenten-Orchestrierung?

KI-Agenten-Orchestrierung koordiniert mehrere KI-Agenten, Modelle und Tools, um eine mehrstufige Aufgabe zu erledigen. Doch jemand – oder etwas – muss weiterhin entscheiden, welcher Agent zuerst läuft, welche Informationen er erhält und was passiert, nachdem er fertig ist. Das ist die Rolle des Orchestrators – eines KI-Agenten, der als Manager fungiert, oder einer softwaregesteuerten Ausführungsschicht.

Vereinfacht gesagt zerlegt eine Orchestrierungsschicht ein Ziel in kleinere Aufgaben, verfolgt Abhängigkeiten, delegiert die Ausführung an die richtigen Agenten, verwaltet gemeinsamen Kontext und führt die Ergebnisse zusammen.

So funktioniert KI-Agenten-Orchestrierung: Ein Blick in die Ausführungs-Engine

Vergrößern

Sehen wir uns an, was passiert, nachdem Sie einem Orchestrator eine Aufgabe übergeben haben.

Nehmen wir ein Beispiel aus dem Computer-Workshop von Perplexity: die Erstellung eines Account-Intelligence-Dashboards mit Informationen aus Salesforce, Snowflake, E-Mail, Kalender und aktuellen Nachrichten.

1. Das Ziel verstehen und die Arbeit planen. Der Orchestrator geht vom gewünschten Ergebnis aus und zerlegt es in Aufgaben mit expliziten Abhängigkeiten. In unserem Dashboard-Beispiel bedeutet das, Informationen aus verschiedenen Quellen zu sammeln und daraus ein fertiges Arbeitsergebnis zu erstellen. Der Planer legt fest, welche Schritte von anderen abhängen und welche unabhängig ausgeführt werden können.
2. Aufgaben an die passenden Agenten weiterleiten. Der Orchestrator ermittelt Aufgaben, deren Abhängigkeiten erfüllt sind, und delegiert die Arbeit an spezialisierte Agenten oder Modelle. Abhängige Aufgaben warten auf ihre Voraussetzungen. Perplexity Computer nutzt mehrere Frontier-Modelle und leitet verschiedene Teile des Workflows an Systeme weiter, die für die jeweiligen Aufgaben geeignet sind. So kann unabhängige Arbeit auch parallel ausgeführt werden.
3. Tool-Aufrufe in kontrollierten Umgebungen ausführen. Agenten interagieren über Tools mit ihrer Umgebung, etwa über Websuche, APIs, verbundene Anwendungen, Dateioperationen oder Codeausführung. Die Ausführungsschicht führt diese Aktionen aus und gibt die Ergebnisse an die Agenten zurück.
4. Ergebnisse und Kontext zwischen Agenten weitergeben. Sobald ein Agent seine Aufgabe abgeschlossen hat, benötigt der nächste nachgelagerte Agent die relevante Ausgabe, um weiterzuarbeiten. Ein Übergabedatensatz könnte eine Aufgaben-ID, eine Ausgabereferenz, eine Schemaversion und Quellmetadaten enthalten. Der Orchestrator koordiniert diese Übergaben und hält dabei den Kontext bereit, der für die nachfolgenden Schritte erforderlich ist. Wichtig ist: Agenten müssen nicht den gesamten Verlauf der Arbeit aller anderen Agenten in ihren eigenen Kontextfenstern mitführen.
5. Ausführungsstatus getrennt vom Agentenkontext erfassen. Wenn Agenten Aufgaben starten, abschließen oder daran scheitern, aktualisiert die Ausführungs-Engine einen persistenten Workflow-Datensatz mit Aufgabenstatus, Ausführungsversuchen, Ausgabereferenzen und verbleibender Arbeit. Mit diesem Datensatz kann der Orchestrator den Fortschritt verfolgen und nach Unterbrechungen fortfahren, ohne dass ein LLM den Workflow aus dem Gesprächsverlauf rekonstruieren muss.
6. Ergebnisse validieren und über die nächsten Schritte entscheiden. Wenn eine Aufgabe ein Ergebnis zurückgibt, prüft die Orchestrierungsschicht, ob ihre Ausgabe den erwarteten Vertrag erfüllt und ob die Abhängigkeiten der nächsten Aufgabe erfüllt sind. Wird ein Problem festgestellt, kann der Workflow zur Korrektur zu einem früheren Schritt zurückkehren oder pausiert werden. Andernfalls läuft er weiter bis zum Abschluss.

Hinter einer scheinbar einfachen KI-Agenten-Orchestrierung stecken viele bewegliche Teile. Wie Sie die Koordination der Agenten organisieren, bestimmt, wie viel Kontrolle Sie über die Ausführung haben. Und natürlich verursacht all diese Koordination zusätzlichen Aufwand. Deshalb lohnt sie sich nicht immer.

Wann sollten Sie KI-Agenten-Orchestrierung einsetzen?

Ziehen Sie eine Multi-Agenten-Orchestrierung in Betracht, wenn verschiedene Teile der Aufgabe unterschiedliches Fachwissen erfordern, unabhängige Arbeit parallel laufen kann oder sich der nächste Schritt nicht im Voraus bestimmen lässt.

Orchestrierung ist also in drei Szenarien hilfreich:

• Aufgaben erfordern unterschiedliche Spezialisierungen. Ein Programmierprojekt könnte beispielsweise von separaten Agenten für Planung, Design, Entwicklung und Review profitieren.
• Unabhängige Aufgaben können parallel ausgeführt werden. Statt einen einzigen Agenten alles nacheinander erledigen zu lassen, können mehrere Agenten gleichzeitig arbeiten und ihre Ergebnisse an einen Orchestrator zurückgeben.
• Das Problem ist ergebnisoffen. Agenten müssen möglicherweise verschiedene Ansätze ausprobieren, Entscheidungen treffen und zusammenarbeiten, statt einer vordefinierten Abfolge zu folgen.

Abgesehen davon ist Orchestrierung nur ein kostspieliger Trend. Mehr Agenten bedeuten außerdem mehr Koordination und potenziell höhere Token-Kosten.

„Ich beginne meist mit der einfachsten Option und baue darauf auf. Wenn wir die Schritte kennen und sie wiederholbar sind, ist das wahrscheinlich ein Workflow. Einen Grund, mehrere Agenten einzuführen, sehe ich nur, wenn sie unterschiedliche Verantwortlichkeiten, Berechtigungen oder Nutzer haben“, sagt Josh Spilker, Head of Search Marketing bei AirOps.

Wägen Sie selbst dann die Vorteile gegen zusätzliche Modellaufrufe, Übergaben, Latenz und Fehlerquellen ab.

Architekturen für KI-Agenten-Orchestrierung und ihre Vor- und Nachteile

Es gibt drei gängige Möglichkeiten, die Koordination von Agenten zu strukturieren: zentralisierte, dezentralisierte und hierarchische Orchestrierung. Die Wahl der richtigen Architektur hängt von einer einzigen Frage ab: Wer steuert die Arbeit, und wie koordinieren sich die Agenten untereinander?

Zentralisierte Orchestrierung

Bei der zentralisierten Orchestrierung steuert ein Orchestrator den Prozess. Er zerlegt die Aufgabe, delegiert die Arbeit an spezialisierte Agenten, verfolgt ihren Fortschritt und führt ihre Ergebnisse zusammen.

Vergrößern

Der Kompromiss: Zentralisierte Koordination erleichtert es, die Ausführung nachzuverfolgen und gemeinsame Regeln an einem einzigen Kontrollpunkt anzuwenden. Allerdings kann der Orchestrator zum Engpass werden, und sein Ausfall kann den gesamten Workflow unterbrechen, sofern das System keine Wiederherstellung unterstützt.

Dezentralisierte Orchestrierung

Bei der dezentralisierten Orchestrierung koordinieren sich Agenten direkter, statt sich darauf zu verlassen, dass ein einzelner Manager jede Entscheidung trifft. Sie können Nachrichten austauschen, einen gemeinsamen Status lesen und ihre nächsten Schritte selbstständig bestimmen.

Vergrößern

Der Kompromiss: Agenten können arbeiten, ohne auf einen zentralen Planer zu warten, was diesen Ansatz für explorative Arbeit und unabhängige Beiträge nützlich macht. Die Koordination wird jedoch schwieriger, wenn Agenten sich uneinig sind, gemeinsame Informationen aktualisieren oder zu einem konsistenten Ergebnis kommen müssen.

Hierarchische Orchestrierung

Die hierarchische Orchestrierung erweitert den Manager-Ansatz auf mehrere Ebenen. Ein übergeordneter Orchestrator delegiert Verantwortung an untergeordnete Orchestratoren, die wiederum ihre eigenen Gruppen spezialisierter Agenten koordinieren.

Stellen Sie sich einen Unternehmens-Workflow vor, an dem Vertriebs-, Finanz- und Rechtsteams beteiligt sind. Ein übergeordneter Orchestrator könnte jeden Arbeitsbereich an einen domänenspezifischen Koordinator delegieren. Diese Koordinatoren würden dann ihre eigenen spezialisierten Agenten steuern und konsolidierte Ergebnisse zurückmelden.

Diese Struktur kann hilfreich sein, wenn Workflows zu umfangreich sind, als dass ein einzelner Orchestrator sie effektiv steuern könnte.

Vergrößern

Der Kompromiss: Hierarchien ermöglichen es Teams, Koordinationsaufgaben aufzuteilen und Ausfälle potenziell innerhalb einzelner Zweige zu behandeln. Allerdings bringen sie zusätzliche Übergaben, eine komplexere Statusverwaltung und einen höheren operativen Aufwand mit sich. Auch die lokale Wiederherstellung hängt davon ab, wie Checkpoints und Ausführungsstatus implementiert sind.

So schneiden diese Architekturen im Vergleich ab:

Sequenzielle, parallele und übergabebasierte Ausführung

Es gibt noch einen weiteren Unterschied, den man kennen sollte. Die Architektur bestimmt, wer die Agenten koordiniert. Das Ausführungsmuster bestimmt, wie ihre Aufgaben voranschreiten.

Es gibt drei Ausführungsmuster:

• Sequenzielle Workflows: Agenten arbeiten in einer festgelegten Reihenfolge, wobei das Ergebnis eines Agenten zur Eingabe für einen anderen wird.
• Parallele Ausführung: Unabhängige Agenten arbeiten gleichzeitig.
• Übergabebasierte Ausführung: Die Kontrolle wechselt im Verlauf der Aufgabe zwischen spezialisierten Agenten. Das ist sinnvoll, wenn ein anderer Agent für den nächsten Schritt besser gerüstet ist, wobei jede Übergabe die Informationen erhalten muss, die für die Fortsetzung nötig sind.

Die Muster schließen sich nicht gegenseitig aus und lassen sich nicht eins zu eins den Orchestrierungsarchitekturen zuordnen. Ziel ist es, die einfachste Struktur zu wählen, die den Abhängigkeiten und Koordinationsanforderungen Ihres Workflows gerecht wird und einen vertretbaren betrieblichen Aufwand verursacht.

Häufige Fehler bei der Orchestrierung von KI-Agenten

Bei der Orchestrierung kann alles Mögliche schiefgehen – von einfachen Versäumnissen bis hin zu komplexen Blockaden. Manchmal scheint ein Agent seine Aufgabe sogar korrekt zu erledigen, während der Workflow insgesamt scheitert. Auf Grundlage von Erfahrungen aus der Praxis haben wir einige der häufigsten Fehler zusammengestellt, die hinter unzuverlässigen orchestrierten Workflows stecken – behalten Sie sie im Blick:

• Verlustbehaftete Übergaben zwischen Agenten. Ein Orchestrator übergibt einem spezialisierten Agenten einen zusammengefassten Plan, doch in der Zusammenfassung fehlen Einschränkungen, Abhängigkeiten oder Implementierungsdetails.
• Verfrühte Fan-in-Ausführung. Ein nachgelagerter Agent beginnt mit dem Zusammenführen von Ergebnissen, bevor alle vorgelagerten Aufgaben abgeschlossen sind.
• Nichtdeterministische Aktualisierungen des gemeinsamen Zustands. Parallele Agenten schreiben in dieselben Zustandsschlüssel, ohne dass eine klar definierte Merge-Semantik existiert. Je nachdem, wie das Framework Aktualisierungen verarbeitet, kann dies zu verlorenen Schreibvorgängen, duplizierten Daten, reihenfolgeabhängigen Ausgaben oder widersprüchlichen Änderungen führen.
• Abweichung zwischen Checkpoint und Nebeneffekt. Eine Aufgabe führt eine externe Operation aus, doch ihre erfolgreiche Ausführung wird nicht dauerhaft festgehalten, bevor der Worker ausfällt. Bei der Wiederherstellung sieht der Orchestrator eine unvollendete Aufgabe und führt sie erneut aus.
• Race Conditions beim Fortsetzen nach menschlicher Freigabe. Das Pausieren und Fortsetzen der Ausführung bringt eigene Synchronisationsprobleme mit sich.
• Delegationsschleifen und sich aufschaukelnde Wiederholungsversuche. Agenten reichen sich Arbeit immer wieder gegenseitig weiter, weil sich ihre Zuständigkeiten überschneiden, Abhängigkeiten zirkulär sind oder Abschlussbedingungen mehrdeutig sind.
• Kontrollen auf Anweisungsebene, die mit Ausführungssicherheit verwechselt werden. Ein Orchestrator kann Agenten anweisen, weder auf bestimmte Ressourcen zuzugreifen noch sensible Aktionen auszuführen, doch Modellanweisungen erzwingen keine Betriebssystemberechtigungen, Netzwerkbeschränkungen oder Autorisierungsgrenzen. Die Security-Engineering-Recherche von Perplexity zeigt, warum Agenten beim Verfolgen legitimer Ziele Sicherheitsgrenzen überschreiten können – selbst ohne böswillige Anweisungen

Beachten Sie, wie unterschiedlich diese Fehler sind. Ein verfrühter Zustandswechsel im Scheduler oder ein mehrdeutiger externer Schreibvorgang kann gleichermaßen zu einem falschen Ergebnis führen, doch sie entstehen in unterschiedlichen Phasen des Ausführungslebenszyklus. Deshalb erfordert eine zuverlässige Orchestrierung mehr, als nur Prompts zu verbessern oder Wiederholungsversuche hinzuzufügen.

7 Best Practices für die Orchestrierung von KI-Agenten im zuverlässigen Produktivbetrieb

1. Explizite Aufgabenverträge, Akzeptanzkriterien und Abbruchbedingungen definieren

Vage Ziele und eine unklare Definition of Done führen oft zu enttäuschenden Ergebnissen von Agenten. Die Lösung ist ein Prompt-Vertrag (eine Leistungsbeschreibung für einen Agenten): Legen Sie Ziel, Einschränkungen, Ausgabeformat und Fehlerbedingungen fest, bevor die Ausführung beginnt.

So könnten Sie beispielsweise einen Vertrag für einen Agenten definieren, der einen sporadisch fehlschlagenden Integrationstest beheben soll:

• Ziel: Die Ursache eines instabilen (flaky) Integrationstests für die Checkout-API ermitteln und beheben.
• Eingaben: Quellcode des Tests, CI-Fehlerprotokolle, aktuelle Commits und relevanter Anwendungscode.
• Einschränkungen: Keine Tests deaktivieren, keine Assertions lockern und kein Anwendungsverhalten ändern, das nicht damit zusammenhängt.
• Erwartete Ausgabe: Ein Code-Patch, eine Erklärung der Grundursache und die Ergebnisse der Testausführung.
• Akzeptanzkriterien: Der zuvor fehlschlagende Test besteht in 10 aufeinanderfolgenden Durchläufen, und die relevante Regressionstest-Suite besteht ebenfalls.
• Fehlerbedingungen: Die Grundursache lässt sich nicht ermitteln, die Korrektur führt zu Regressionen oder die erforderliche Testumgebung ist nicht verfügbar.

Doch es gibt noch einen weiteren wichtigen Punkt: Wann sollte der Agent aufhören?

Ein Agent sollte nicht endlos weiter iterieren, nur weil er noch kein zufriedenstellendes Ergebnis geliefert hat. Legen Sie fest, was als erfolgreicher Abschluss gilt, wann eine teilweise abgeschlossene Aufgabe zurückgegeben werden soll und wann abgebrochen werden muss, weil eine Anforderung nicht erfüllt werden kann. Legen Sie eine maximale Delegationstiefe und Iterationslimits oder Ausführungsbudgets fest, damit ungelöste Aufgaben nicht zu Endlosschleifen werden.

Zurück zu unserem CI-Beispiel. Sie könnten folgende Abbruchbedingungen definieren:

• Erfolg: Die Korrektur besteht 10 aufeinanderfolgende Testläufe und die relevante Regressionstest-Suite.
• Iterationslimit: Der Agent darf höchstens zwei Korrekturkandidaten ausprobieren.
• Ausführungsbudget: Der Agent muss nach 60 Minuten aufhören, auch wenn das Problem weiterhin ungelöst ist.
• Delegationslimit: Der Agent darf Arbeit an einen spezialisierten Agenten delegieren; eine weitere Delegation an Subagenten ist nicht zulässig.
• Teilweiser Abschluss: Wenn beide Versuche fehlschlagen oder das Zeitlimit abläuft, gibt der Agent seine Erkenntnisse, die versuchten Änderungen und die Testergebnisse zurück.
• Blockierte Ausführung: Wenn die Testumgebung nicht verfügbar ist, hält der Agent an und meldet das Hindernis, anstatt einen Erfolg zu behaupten.

2. Orchestratoren schlank halten und strukturierte Übergaben durchsetzen

Manchmal übertragen Entwickler einem Orchestrator zu viele Aufgaben, und anstatt spezialisierte Agenten zu koordinieren, beginnt er, selbst Code zu schreiben, zu debuggen oder detaillierte Reviews durchzuführen. Das schafft einen Engpass: Der Orchestrator verbraucht sein Kontextbudget für Implementierungsdetails, verzögert die Delegation und verwischt die Verantwortung für die Ergebnisse.

Lassen Sie Orchestratoren also ihre eigentliche Arbeit machen, und setzen Sie Übergaben durch, die auf konkrete Artefakte verweisen: die ursprüngliche Aufgabe, relevante Eingaben, Ausgabeartefakte, den Ausführungsstatus und alle ungelösten Probleme.

Ein Beispiel: status: completed bezieht sich auf die zugewiesene Arbeit des Agenten, nicht auf den gesamten Workflow. Da die Tests noch den Status pending haben, sollte der Orchestrator das Endergebnis nicht freigeben.

3. Workflow-Zustand persistieren und Kontextwachstum kontrollieren

Der Gesprächsverlauf eines Agenten ist keine verlässliche Aufzeichnung des Workflow-Fortschritts. Wenn sich sein Kontextfenster füllt, kann die automatische Komprimierung wichtige Details verwerfen. Und wenn ein Worker abstürzt, muss der nächste Agent wissen, welche Schritte tatsächlich abgeschlossen wurden.

Wenn der Coding-Agent beispielsweise einen Patch erzeugt und dann abstürzt, sollte der nächste Worker das gespeicherte Artefakt abrufen und ab dem aufgezeichneten Workflow-Zustand weitermachen. Hat der Agent jedoch zusätzlich einen externen CI-Lauf ausgelöst, muss der Orchestrator diesen Lauf separat abgleichen, bevor er die Aktion wiederholt

Halten Sie den Ausführungszustand daher vom Arbeitskontext des Agenten getrennt. Speichern Sie Aufgabenstatus, Ausführungsversuche, abgeschlossene Schritte und Artefaktverweise in einem dauerhaften Speicher. Laden Sie gleichzeitig nur die Anweisungen, Eingaben und Ergebnisse, die für die aktuelle Aufgabe des Agenten relevant sind, anstatt den gesamten Ausführungsverlauf in sein Kontextfenster zu stopfen.

4. Fehlerbewusste Wiederholungsversuche und wiederherstellbare Tool-Ausführung entwerfen

Angenommen, Ihr CI-Agent löst einen Testlauf aus, doch bei der API-Anfrage kommt es zu einer Zeitüberschreitung. Konnte der Testlauf nicht gestartet werden, oder hat der CI-Dienst ihn in die Warteschlange gestellt und die Antwort ging verloren?

Eine Zeitüberschreitung bedeutet nicht zwangsläufig, dass eine Operation fehlgeschlagen ist. Deshalb müssen Sie zwischen verschiedenen Fehlern unterscheiden, bevor Sie entscheiden, wie es weitergeht:

• Vorübergehende Fehler (429, 503): Mit begrenztem exponentiellem Backoff und Jitter erneut versuchen und dabei Retry-After beachten, sofern angegeben.
• Validierungs- oder Berechtigungsfehler (400, 403): Abbrechen oder das zugrunde liegende Problem beheben, statt dieselbe Anfrage zu wiederholen.
• Mehrdeutige Ergebnisse (Zeitüberschreitung nach einem möglichen Schreibvorgang): Prüfen, ob die Operation erfolgreich war, bevor sie erneut versucht wird.

Hinweis: Auch wiederholbare Fehler brauchen Grenzen. Legen Sie für jeden Tool-Aufruf ein Timeout fest, begrenzen Sie die Anzahl der Wiederholungsversuche und die gesamte Wiederholungszeit, und setzen Sie eine übergreifende Workflow-Deadline durch, damit verschachtelte Agenten nicht immer wieder dieselbe Operation neu starten können. Wenn eine Abhängigkeit wiederholt ausfällt, verwenden Sie einen Circuit Breaker, um Anfragen vorübergehend zu stoppen.

Weisen Sie bei Operationen mit externen Nebeneffekten jeder logischen Aktion einen stabilen Idempotenzschlüssel zu und verwenden Sie ihn bei allen Wiederholungsversuchen erneut. Unterstützt die API eine serverseitige Deduplizierung, kann sie wiederholte Anfragen erkennen, ohne die Aktion zweimal auszuführen. Ist das nicht der Fall, fragen Sie das externe System über eine Korrelations-ID oder eine andere maßgebliche Referenz ab.

Wenn Sie nicht feststellen können, was passiert ist, brechen Sie ab und eskalieren Sie.

Ein Beispiel für die Retry-Logik unseres CI-Agenten, ausgedrückt als Pseudocode:

Hinweis zum Code: Das Beispiel setzt voraus, dass die CI-API das Nachschlagen von Läufen anhand der Anfrage-ID unterstützt. Die request_id verhindert Duplikate nur dann, wenn der Anbieter Idempotenz ausdrücklich garantiert. bounded_retry() ist beispielhafter Pseudocode. In der Produktion sollten Wiederholungsversuche sowohl durch ein Retry-Budget pro Operation (maximale Anzahl an Versuchen oder verstrichene Zeit) als auch durch die übergreifende Workflow-Deadline begrenzt werden.

Bei längeren Workflows, die mehrere Dienste umfassen, sollten Sie das Saga-Muster in Betracht ziehen, um kompensierende Aktionen zu koordinieren, wenn spätere Schritte fehlschlagen. Denken Sie aber daran, dass eine Kompensation nicht immer ein vollständiges Rollback ist. Sie können ein Datenbank-Update rückgängig machen, aber eine versendete E-Mail nicht zurückholen.

5. Arbeit mit expliziten Ressourcenbudgets routen und parallelisieren

Hier gilt es, zwei Dinge auszubalancieren: wie viel Modellleistung jede Aufgabe benötigt und wie viele Aufgaben Sie gleichzeitig ausführen können. Liegen Sie bei einem davon falsch, riskieren Sie, dass Agenten um gemeinsame API-Kontingente konkurrieren oder sich ausschließlich auf teure Reasoning-Modelle verlassen.

Bei der Modellauswahl gilt: Passen Sie Modellleistung und Reasoning-Aufwand an die Komplexität der Aufgabe an – einfach, aber oft übersehen. Beachten Sie, dass Sie entweder selbst Routing-Regeln konfigurieren und Modelle evaluieren oder eine Orchestrierungsplattform nutzen können, die die Modellauswahl für Sie übernimmt.

Mit dem Effort Mode von Perplexity Computer können Sie beispielsweise festlegen, wie viel Aufwand eine Aufgabe verdient, ohne manuell ein Modell auszuwählen. Wählen Sie Light, Standard, High oder Ultra, und Perplexity wählt automatisch das orchestrierende Modell und dessen Reasoning-Level aus. Dieser Orchestrator delegiert dann Teilaufgaben an unterstützende Agenten, die Modelle verschiedener Anbieter nutzen können.

Perplexity bewertet Modellkonfigurationen hinsichtlich Qualität und Kosten und bevorzugt günstigere Optionen, die vergleichbare Ergebnisse liefern. Sie können auch die Custom-Einstellungen verwenden, wenn Sie Modell und Reasoning-Level lieber selbst auswählen möchten.

Bei der Parallelisierung sollte sich die Grenze aus Ihrer Infrastruktur und Ihren externen Abhängigkeiten ergeben. Prüfen Sie die Rate Limits gemeinsam genutzter APIs für Anfragen und Tokens, und führen Sie dann Lasttests Ihres Workflows mit zunehmender Parallelität durch. Beobachten Sie, ob sich der Durchsatz verbessert oder ob Anfragen in Warteschlangen landen, langsamer werden oder 429-Fehler zurückgeben.

Damit der Ressourcenverbrauch vorhersehbar bleibt, sollten Sie Ressourcenlimits und Scheduling-Kontrollen durchsetzen:

• Parallelität und Anfrageraten steuern: Begrenzen Sie laufende Aufrufe pro Dienst und stellen Sie überschüssige Arbeit in eine Warteschlange. Denken Sie daran, dass eine Begrenzung der Parallelität allein keine Limits für Anfragen pro Minute oder Tokens pro Minute durchsetzt.
• Token- und Kostenbudgets verfolgen: Erfassen Sie die Nutzung über den gesamten Workflow hinweg, einschließlich Subagenten, und starten Sie keine neuen Arbeiten mehr, wenn das verbleibende Budget nicht ausreicht.
• Ausführungsfristen durchsetzen: Legen Sie Zeitlimits für Aufgaben und Workflows fest, und geben Sie Abbrüche an laufende Agenten weiter, sofern dies unterstützt wird.
• Abhängigkeiten berücksichtigen: Starten Sie nachgelagerte Aufgaben erst, wenn die benötigten Eingaben verfügbar sind, anstatt alle Agenten gleichzeitig zu starten.

6. Freigaben durchsetzen und die Ausführung von Agenten isolieren

Lassen Sie niemals das Modell entscheiden, ob seine eigenen Aktionen sicher sind. Erteilen Sie Agenten stattdessen Berechtigungen nach dem Least-Privilege-Prinzip, und setzen Sie risikobasierte Freigaberegeln im Anwendungscode durch. Wenn Agenten Code ausführen, isolieren Sie diese Ausführung von Ihrer Host-Umgebung und beschränken Sie den Zugriff auf Dateien, Netzwerke und Anmeldedaten. So begrenzen Sie den Schaden, falls der Agent einen Fehler macht oder unsicheren Code ausführt.

„Ich bin skeptisch gegenüber übermäßig komplizierten Multi-Agent-Systemen, vor allem wenn Agenten gegenseitig ihre Arbeit prüfen und freigeben. Am Ende reichen womöglich mehrere Agenten selbstbewusst denselben Fehler weiter, ohne dass ihn irgendjemand tatsächlich bemerkt“, warnt Spilker.

Vergrößern

Bei Aktionen, die eine menschliche Freigabe erfordern, pausieren Sie die Ausführung und speichern Sie die genaue vorgeschlagene Operation:

• ihre Parameter
• ihre Zielressource
• ihren Commit oder ihre Zustandsversion
• die Entscheidung der prüfenden Person

Legen Sie außerdem fest, was passiert, wenn eine Freigabe abgelehnt wird, abläuft oder eskaliert werden muss. Das ist für fortsetzbare Frameworks unerlässlich, da beim Fortsetzen eines unterbrochenen Knotens der Code ab dem Anfang dieses Knotens erneut ausgeführt wird. Nebeneffekte, die vor der Unterbrechung aufgetreten sind, können also erneut auftreten.

Wird eine Freigabe also abgelehnt oder läuft sie ab, wird die Anfrage geschlossen. Ändern sich Ziel-Commit, Parameter oder Berechtigungen vor der Ausführung, machen Sie die Freigabe ungültig und fordern Sie eine neue an.

Spilker hält auch nichts von der Vorstellung, vollständig autonome End-to-End-Agenten seien das eigentliche Ziel. „Für mich ist es besser, einige wenige fokussierte Agenten mit klaren Zuständigkeiten, definierten Berechtigungen und menschlicher Prüfung an den richtigen Stellen zu entwickeln. Man erreicht trotzdem Effizienz, ohne die volle Kontrolle aufzugeben“, so sein Fazit.

7. Ausgaben unabhängig verifizieren und das Wiederherstellungsverhalten testen

Hat Ihnen ein Agent schon einmal Success gemeldet, obwohl er in Wirklichkeit gescheitert ist? Ärgerlich, wenn nicht gar zum Verzweifeln – und die Lösung ist nicht schnell gefunden, denn die abschließende Nachricht des Agenten verrät Ihnen nicht unbedingt, wo etwas schiefgelaufen ist.

Um der Sache auf den Grund zu gehen, verfolgen Sie nach, was während der Ausführung passiert ist, und überprüfen Sie die Ergebnisse unabhängig. Nehmen wir uns also etwas Zeit, um das Problem einzugrenzen und zu beheben.

Den Workflow nachverfolgen, um den Fehler zu finden

Bevor Sie die Prompts eines Agenten debuggen, erfassen Sie den gesamten Ausführungspfad. Sie benötigen einen Trace, der Agent-Aufrufe, Tool-Aufrufe, Fehler und Wiederholungsversuche innerhalb desselben Workflow-Laufs miteinander verknüpft.

Die GenAI Semantic Conventions von OpenTelemetry bieten eine standardisierte Möglichkeit, diese Operationen zu beschreiben. So kennzeichnet beispielsweise invoke_workflow die Ausführung eines Workflows, invoke_agent den Aufruf eines Agenten und execute_tool einen Tool-Aufruf. Jede Operation kann als span mit Zeitangaben, Status und relevanten Metadaten aufgezeichnet werden.

Dieser Schritt liefert Ihnen einen Trace des Ausführungspfads, sodass Sie erkennen können, wo ein Agent ins Stocken geraten ist.

Ein beispielhafter Ausführungs-Trace.

Die Ausgabe unabhängig prüfen

Setzen Sie wo immer möglich programmatische Prüfungen ein. Validieren Sie Ausgaben anhand von JSON-Schemas, führen Sie Unit- und Integrationstests aus, prüfen Sie, ob die erforderlichen Artefakte vorhanden sind, und fragen Sie externe Systeme ab, um zu bestätigen, dass Aktionen tatsächlich erfolgreich waren.

Für Ausgaben, die eine subjektive Beurteilung erfordern – und sich daher nicht durch programmatische Prüfungen bewerten lassen –, setzen Sie einen unabhängigen Reviewer-Agenten ein. Ein Ansatz ist eine Implementer-Reviewer-Resolver-Schleife, bei der ein Agent ein Artefakt erstellt, ein Reviewer mit frischem Kontext Probleme identifiziert und ein Resolver diese behebt, bevor die Validierung erneut ausgeführt wird.

Sie müssen die Ergebnisse des Reviewers dennoch nach Möglichkeit validieren, und wenn Sie LLM-basierte Bewerter für wiederholte Evaluierungen einsetzen, kalibrieren Sie deren Urteile anhand von Beispielen, die von Menschen geprüft wurden.

Fehler gezielt einschleusen, um die Wiederherstellung zu testen

Bisher haben Sie nachverfolgt, was die Agenten ausgeführt haben, und geprüft, ob ihre Ausgaben korrekt waren. Doch was passiert, wenn ein Worker mitten in einer Aufgabe abstürzt oder bei einer API nach dem Annehmen einer Anfrage ein Timeout auftritt? Überraschenderweise kann sich Ihr Workflow unter normalen Bedingungen einwandfrei verhalten, bei der Wiederherstellung jedoch versagen.

Um das zu testen, injizieren Sie in einer Testumgebung gezielt Fehler:

• API-Timeouts simulieren
• Worker zwischen externen Schreibvorgängen und Checkpoints abstürzen lassen
• Fehlerhafte Tool-Ausgaben zurückgeben
• Genehmigungen ablaufen lassen

Prüfen Sie nach jedem Test den Ausführungs-Trace, um zu sehen, welche Schritte ausgeführt wurden, an welcher Stelle der Workflow fortgesetzt wurde und ob Aktionen wiederholt oder übersprungen wurden. Überprüfen Sie anschließend die tatsächlichen Ergebnisse.

Angenommen, Ihr CI-Agent sendet eine Anfrage zum Starten eines Testlaufs, doch bei der API-Antwort tritt ein Timeout auf. Der Agent versucht es erneut, erhält eine erfolgreiche Antwort und meldet Erfolg. Alles scheint in Ordnung, bis Sie den CI-Dienst prüfen und feststellen, dass statt eines Testlaufs zwei erstellt wurden.

Deshalb sollten Sie sowohl den vom Workflow aufgezeichneten Zustand als auch die tatsächlichen Änderungen in externen Systemen überprüfen. Ein Wiederherstellungstest sollte nur dann als bestanden gelten, wenn der Workflow den erwarteten Zustand ohne unbeabsichtigte Nebeneffekte erreicht.

Nehmen Sie entdeckte Fehler in Ihre Regressionstests auf, damit künftige Änderungen sie nicht erneut einführen.

Letztlich bedeutet Erfolg, dass der Workflow die erforderlichen Prüfungen bestanden hat und seine externen Ergebnisse verifiziert wurden.

FAQ zur Orchestrierung von KI-Agenten

Warum versagen isolierte KI-Agenten im Unternehmensmaßstab?

Isolierte Agenten können ihre jeweiligen Aufgaben korrekt erledigen und zusammen dennoch inkonsistente Ergebnisse liefern. Stellen Sie sich vor, ein Vertriebsagent ruft um 10:00 Uhr Kundenkonditionen ab, ein Preisagent berechnet um 10:05 Uhr ein Angebot mit aktualisierten Preisen und ein Rechtsagent prüft einen Vertrag, der sich um 10:07 Uhr geändert hat. Jeder Agent arbeitet mit einer anderen Momentaufnahme des Unternehmens, sodass sich ihre Ausgaben widersprechen können.

Im Unternehmensmaßstab verschärft sich das Problem, weil Agenten mit mehreren Systemen interagieren, die unabhängig voneinander aktualisiert werden, mit unterschiedlichen Berechtigungen arbeiten und nicht unbedingt Kontext oder Ausführungszustand teilen.

Wie lassen sich endlose Wiederholungsschleifen bei KI-Agenten verhindern?

Legen Sie Grenzen auf mehreren Ebenen fest: maximale Wiederholungsversuche für Tool-Aufrufe, maximale Agenten-Iterationen, Delegationstiefe und eine Gesamtfrist für den Workflow. Klassifizieren Sie Fehler, bevor Sie einen erneuten Versuch starten. Beachten Sie bei vorübergehenden 429-Antworten Retry-After, sofern angegeben. Verwenden Sie andernfalls einen begrenzten exponentiellen Backoff mit Jitter.

Senden Sie unveränderte Anfragen nach Validierungs- oder Berechtigungsfehlern nicht erneut. Wenn ein nachgelagerter Dienst wiederholt ausfällt, kann ein Circuit Breaker verhindern, dass Agenten zusätzliche Last erzeugen.

Wie lässt sich ein KI-Agenten-Workflow nach einem Absturz fortsetzen?

Der Wiederherstellungsmechanismus hängt von Ihrer Laufzeitumgebung ab. Bei LangGraph speichert ein persistenter Checkpointer wie PostgresSaver den Graph-Zustand unter einer thread_id, sodass die Ausführung vom persistierten Zustand aus fortgesetzt werden kann. Bei Temporal kann ein anderer Worker einen Workflow rekonstruieren, indem er dessen Event-Historie erneut abspielt. Beim Replay verwendet er zuvor aufgezeichnete Activity-Ergebnisse wieder.

Wenn die Anwendung neu bereitgestellt wird, während noch Workflows laufen, sind gespeicherte Zustände und Ausführungshistorien möglicherweise nicht mehr kompatibel. Temporal löst dies mit Worker Versioning und Workflow-Patching. Planen Sie bei Checkpoint-basierten Systemen Schemamigrationen und testen Sie die Wiederherstellung anhand bestehender gespeicherter Zustände, bevor Sie inkompatible Änderungen ausrollen.

Wie lässt sich die Zuverlässigkeit der Orchestrierung von KI-Agenten testen?

Führen Sie dieselben repräsentativen Aufgaben mehrmals aus und unterscheiden Sie zwischen pass@k (ob mindestens einer von k Versuchen erfolgreich ist) und pass^k (ob alle k Versuche erfolgreich sind)

Messen Sie Ergebnisse nach Aufgabenkategorie und Workflow-Version, statt sich auf eine einzige aggregierte Erfolgsquote zu verlassen. Erfassen Sie den Erfolg beim ersten Versuch, die Konsistenz über wiederholte Durchläufe hinweg, die p95-Latenz, die Kosten pro abgeschlossener Aufgabe und den Anteil der Aufgaben, die menschliches Eingreifen erfordern. Geben Sie für Erfolgsquoten Stichprobengrößen und Unsicherheitsintervalle an.