Agentsystementwurfsmuster

Das Erstellen eines Agentsystems umfasst die Orchestrierung, wie LLM-Aufrufe, Datenabrufe und externe Aktionen miteinander fließen. Sie können sich Entwurfsmuster für Agentsysteme in einem fortlaufenden Maß an Komplexität und Autonomie vorstellen: von deterministischen Ketten über Einzel-Agent-Systeme , die dynamische Entscheidungen treffen können (und mehrere LLM-Aufrufe unter der Haube umfassen können), bis hin zu Multi-Agent-Architekturen , die mehrere spezialisierte Agents koordinieren.

Toolaufruf

Bevor Sie sich mit Entwurfsmustern vertraut machen, ist es wichtig, das Aufrufen von Tools als grundlegende Funktion zu verstehen, die in jedem Agentsystem verwendet werden kann, von einfach bis komplex. Toolaufrufe sind ein Mechanismus, mit dem ein Agentsystem mit externen Funktionen, Datenquellen oder Diensten interagieren kann. Dies kann Folgendes aktivieren:

• Livedatensuche wie SQL-Abfragen, CRM-Abrufe oder Vektorindexabrufe.
• Aktionen wie E-Mail senden oder Datensatz aktualisieren.
• Beliebige Logik oder Transformationen über Python-Funktionen oder APIs.

Das Aufrufen von Tools bietet somit einen leistungsfähigen Mechanismus, mit dem LLMs „bewusst“ für externe Daten oder APIs gemacht werden können, unabhängig von dem Entwurfsmuster, das Sie wählen.

Weitere Informationen zu Agenttools finden Sie unter KI-Agent-Tools.

In den folgenden Abschnitten werden drei Entwurfsmuster des Agentsystems erläutert, von denen jedes Werkzeugaufrufe in unterschiedlichem Grad nutzen kann.

Vergleich der Entwurfsmuster für generative KI-Anwendungen

Die Designmuster der generativen KI-App (Agent) werden nach ihrer Komplexität geordnet präsentiert.

Entwurfsmuster	Wann verwendet werden soll	Vorteile	Nachteile
Deterministische Kette	Klar definierte Aufgaben Statische Pipelines wie grundlegende RAG Keine Notwendigkeit für on-the-fly-Entscheidungen	Sehr einfach Einfach zu überwachen	Unflexibel Erfordert Codeänderungen zur Anpassung
Einzel-Agent-System	Moderate bis komplexe Abfragen in derselben Domäne Einige dynamische Entscheidungen ohne den Aufwand mehrerer spezialisierter Agenten.	Flexibel Einfacher als Mehragentensystem Guter "Standardwert"	Weniger vorhersehbar Muss vor wiederholten oder falschen Toolaufrufen schützen
Multi-Agent-System	Große oder funktionsübergreifende Domänen; mehrere "Experten"-Agenten; unterschiedliche Logik oder Unterhaltungskontexte; erweiterte Spiegelungsmuster.	Hoch modular Skaliert auf große Domänen	Schwer zu koordinieren Schwieriger zu verfolgen und zu debuggen

Einzel-Agent-System

Ein Einzel-Agent-System verfügt über einen koordinierten Logikfluss , der häufig mehrere LLM-Aufrufe orchestriert, um eingehende Anforderungen zu verarbeiten. Der Agent kann:

1. Nehmen Sie Anforderungen wie Benutzeranfragen und relevanten Kontext wie z. B. den Unterhaltungsverlauf entgegen.
2. Überlegen Sie, wie man am besten reagiert, und entscheiden Sie optional, ob Tools für externe Daten oder Aktionen aufgerufen werden sollen.
3. Wiederholen Sie dies bei Bedarf, indem Sie ein LLM (und/oder dieselben Tools) wiederholt aufrufen, bis ein Ziel erreicht oder eine bestimmte Bedingung erfüllt ist (z. B. Empfangen gültiger Daten oder Beheben eines Fehlers).
4. Integrieren Sie Werkzeugausgaben in das Gespräch.
5. Gibt eine zusammenhängende Antwort als Ausgabe zurück.

In vielen Anwendungsfällen reicht eine einzelne Runde der LLM-Begründung (häufig mit Toolaufrufen) aus. Erweiterte Agenten können jedoch mehrere Schritte durchlaufen, bis sie zu einem gewünschten Ergebnis gelangen.

Obwohl es nur einen "einzigen" Agent gibt, können Sie immer noch mehrere LLM- und Toolaufrufe unter der Haube haben (für planung, Generierung, Überprüfung usw.), die alle von diesem einzelnen, einheitlichen Fluss verwaltet werden.

Beispiel: Helpdesk-Assistent

• Wenn der Benutzer eine einfache Frage stellt ("Was ist unsere Rückgaberichtlinie?"), kann der Agent direkt aus dem Wissen des LLM antworten.
• Wenn der Benutzer seinen Bestellstatus wünscht, ruft der Agent eine Funktion lookup_order(customer_id, order_id)auf. Wenn dieses Tool mit "ungültiger Bestellnummer" antwortet, kann der Agent den Benutzer erneut versuchen oder zur Richtigen ID auffordern, bis es eine endgültige Antwort geben kann.

Verwendungsbedingungen:

• Sie erwarten unterschiedliche Benutzerabfragen, aber immer noch innerhalb einer zusammenhängenden Domäne oder eines Produktbereichs.
• Bestimmte Abfragen oder Bedingungen können die Verwendung von Tools erfordern, z. B. die Entscheidung, wann Kundendaten abgerufen werden sollen.
• Sie benötigen mehr Flexibilität als eine deterministische Kette, erfordern jedoch keine separaten spezialisierten Agents für verschiedene Aufgaben.

Vorteile:

• Der Agent kann sich an neue oder unerwartete Abfragen anpassen, indem sie auswählen, welche (falls vorhanden) Tools aufgerufen werden sollen.
• Der Agent kann wiederholte LLM-Aufrufe oder Toolaufrufe durchlaufen, um Ergebnisse zu verfeinern , ohne dass eine vollständige Einrichtung mit mehreren Agents erforderlich ist.
• Dieses Entwurfsmuster ist häufig der süße Punkt für Unternehmensanwendungsfälle – einfacher zu debuggen als Multi-Agent-Setups, während gleichzeitig dynamische Logik und eingeschränkte Autonomie ermöglicht werden.

Überlegungen:

• Im Vergleich zu einer fest verdrahteten Kette müssen Sie sich gegen wiederholte oder ungültige Tool-Aufrufe wappnen. (Unendliche Schleifen können in jedem Toolaufrufszenario auftreten, sodass Iterationsgrenzwerte oder Timeouts festgelegt werden.)
• Wenn Ihre Anwendung radikal unterschiedliche Unterbereiche (Finanzen, DevOps, Marketing usw.) umfasst, kann ein einzelner Agent unübersichtlich werden oder durch die Funktionsanforderungen überlastet sein.
• Sie benötigen immer noch sorgfältig gestaltete Eingabeaufforderungen und Einschränkungen, um den Agenten fokussiert und relevant zu halten.

Deterministische Kette (hartcodierte Schritte)

In diesem Muster definiert der Entwickler, welche Komponenten in welcher Reihenfolge und mit welchen Parametern aufgerufen werden. Es gibt keine dynamische Entscheidungsfindung darüber , welche Tools aufgerufen werden sollen oder in welcher Reihenfolge. Das System folgt einem vordefinierten Workflow für alle Anforderungen, sodass er sehr vorhersehbar ist.

Häufig als "Chain" bezeichnet, ist der Fluss im Wesentlichen eine feste Kette von Schritten, z. B.:

1. Rufen Sie immer die Anforderung des Benutzers ab und rufen Sie aus einem Vektorindex für den relevanten Kontext ab.
2. Kombinieren Sie diesen Kontext mit der Anforderung des Benutzers in einer endgültigen LLM-Eingabeaufforderung.
3. Rufen Sie das LLM auf und geben Sie die Antwort zurück.

Beispiel: Grundlegende RAG-Kette

Eine deterministische RAG-Kette könnte immer:

1. Abrufen von Top-k-Ergebnissen aus einem Vektorindex mithilfe der Anforderung eines eingehenden Benutzers (Abrufen).
2. Formatieren Sie abgerufene Blöcke in einer Eingabeaufforderungsvorlage (Augment).
3. Übergeben Sie diese erweiterte Eingabeaufforderung an die LLM (generieren).
4. Gibt die Antwort des LLM zurück.

Verwendungsbedingungen:

• Für gut definierte Aufgaben mit vorhersagbaren Workflows.
• Wenn Konsistenz und Überwachung oberste Prioritäten sind.
• Wenn Sie die Latenz minimieren möchten, indem Sie mehrere LLM-Aufrufe für Orchestrierungsentscheidungen vermeiden.

Vorteile:

• Höchste Vorhersagbarkeit und Auditierbarkeit.
• In der Regel geringere Latenz (weniger LLM-Aufrufe für die Orchestrierung).
• Einfacheres Testen und Überprüfen.

Überlegungen:

• Begrenzte Flexibilität für die Behandlung unterschiedlicher oder unerwarteter Anforderungen.
• Kann zunehmend komplex und schwierig zu handhaben sein, wenn logische Verzweigungen wachsen.
• Möglicherweise ist eine erhebliche Umgestaltung erforderlich, um neue Funktionen zu berücksichtigen.

Multi-Agent-System

Ein Multi-Agent-System umfasst zwei oder mehr spezialisierte Agents, die Nachrichten austauschen und/oder an Aufgaben zusammenarbeiten. Jeder Agent verfügt über eigene Domänen- oder Aufgabenkompetenzen, Kontext und potenziell unterschiedliche Toolgruppen. Ein separater „Koordinator“, der möglicherweise ein anderer LLM oder ein regelbasierter Router ist, leitet Anfragen an den entsprechenden Agenten weiter oder entscheidet, wann die Übergabe von einem Agenten zu einem anderen erfolgen soll.

Beispiel: Enterprise-Assistent mit spezialisierten Agents

• Kundendienstmitarbeiter: Behandelt CRM-Nachschlagevorgänge, -rückgaben und -versand.
• Analyse-Agent: Konzentriert sich auf SQL-Abfragen und Datenzusammenfassung.
• Supervisor/Router: Wählt aus, welcher Agent für eine bestimmte Benutzerabfrage am besten geeignet ist oder wann gewechselt werden soll.

Jeder Unter-Agent kann Toolaufrufe innerhalb seiner eigenen Domäne (wie lookup_customer_account oder run_sql_query) ausführen, wobei oft einzigartige Eingabeaufforderungen oder Unterhaltungshistorien erforderlich sind.

Verwendungsbedingungen:

• Sie haben unterschiedliche Problembereiche oder Qualifikationssätze, z. B. einen Codierungsagenten oder einen Finanzberater.
• Jeder Agent benötigt Zugriff auf aufgezeichnete Unterhaltungen oder domänenspezifische Eingabeaufforderungen.
• Sie haben so viele Tools, dass es unpraktisch ist, sie alle in das Schema eines einzigen Agenten zu integrieren; jeder Agent kann eine eigene Teilmenge besitzen.
• Sie möchten Reflexion, Kritik oder wechselseitige Zusammenarbeit zwischen spezialisierten Agenten implementieren.

Vorteile:

• Dieser modulare Ansatz bedeutet, dass jeder Agent von separaten Teams entwickelt oder verwaltet werden kann, die sich auf eine enge Domäne spezialisiert haben.
• Kann große, komplexe Unternehmensworkflows verarbeiten, die ein einzelner Mitarbeiter möglicherweise schwer bewältigen könnte.
• Erleichtert die erweiterte mehrstufige oder multispektivische Begründung , z. B. einen Agenten, der eine Antwort generiert, eine andere, die sie überprüft.

Überlegungen:

• Erfordert eine Strategie für das Routing zwischen Agents sowie mehr Aufwand für protokollierung, Ablaufverfolgung und Debugging über mehrere Endpunkte hinweg.
• Wenn Sie über viele Unter-Agents und Tools verfügen, kann es kompliziert werden, zu entscheiden, welcher Agent Zugriff auf welche Daten oder APIs hat.
• Agenten können Aufgaben unbestimmt miteinander hin- und herschieben, ohne eine Lösung, wenn sie nicht sorgfältig eingegrenzt sind.
  • Unendliche Schleifenrisiken bestehen auch bei Toolanrufen mit einem Einzigen Agent, aber Multi-Agent-Setups fügen eine weitere Ebene der Debuggingkomplexität hinzu.

Praktische Beratung

Berücksichtigen Sie unabhängig davon, welches Entwurfsmuster Sie auswählen, die folgenden bewährten Methoden für die Entwicklung stabiler, wartungsfähiger Agent-Systeme.

1. Beginnen Sie einfach: Wenn Sie nur eine einfache Kette benötigen, ist eine deterministische Kette schnell zu erstellen.
2. Schrittweises Hinzufügen von Komplexität: Wenn Sie dynamischere Abfragen oder flexible Datenquellen benötigen, wechseln Sie mit Toolaufrufen zu einem Einzel-Agent-System.
3. Nutzen Sie mehrere Agenten: Nur wenn Sie eindeutig unterschiedliche Bereiche oder Aufgaben, mehrere Unterhaltungskontexte oder einen großen Werkzeugsatz haben, der für die Eingabeaufforderung eines einzelnen Agents zu groß ist.

Wenn Ihr Anwendungsfall klein beginnt – wie eine einfache RAG-Kette – beginnen Sie mit einer hartcodierten Kette. Da sich die Anforderungen weiterentwickeln, können Sie Toolaufruflogik für dynamische Entscheidungsfindung hinzufügen oder sogar Aufgaben in mehrere spezialisierte Agents segmentieren. In der Praxis kombinieren viele reale Agentsysteme Muster. Verwenden Sie z. B. eine meist deterministische Kette, aber ermöglichen Sie es der LLM, bestimmte APIs bei Bedarf dynamisch in einem einzigen Schritt aufzurufen.

Mosaik AI Agent Framework ist unabhängig von dem muster, das Sie auswählen, wodurch es einfach ist, Entwurfsmuster zu entwickeln, während Ihre Anwendung wächst.

Entwicklungsleitfaden

• Aufforderungen
  • Halten Sie Aufforderungen klar und minimal, um widersprüchliche Anweisungen, ablenkende Informationen zu vermeiden und Halluzinationen zu reduzieren.
  • Stellen Sie nur die Tools und den Kontext bereit, die Ihr Agent benötigt, anstatt einen ungebundenen Satz von APIs oder einen großen irrelevanten Kontext.
• Protokollierung und Überwachbarkeit
  • Implementieren Sie detaillierte Protokollierung für jede Benutzeranfrage, jeden Agentenplan und jeden Toolaufruf. Die MLflow-Ablaufverfolgung kann beim Erfassen strukturierter Protokolle für das Debuggen helfen.
  • Speichern Sie Protokolle sicher und achten Sie auf personenbezogene Informationen (PII) in Unterhaltungsdaten.
• Modellupdates und Versionsfixierung
  • LLM-Verhaltensweisen können sich verschieben, wenn Anbieter Modelle hinter den Kulissen aktualisieren. Verwenden Sie Versionsfixierung und häufige Regressionstests, um sicherzustellen, dass die Agentlogik robust und stabil bleibt.
  • Die Kombination von MLflow mit Mosaik AI Agent Evaluation bietet eine optimierte Möglichkeit zur Versionsverwaltung und regelmäßige Bewertung von Qualität und Leistung.

Leitfaden zu Tests und Iterationen

• Fehlerbehandlungs- und Fallbacklogik
  • Planen Sie Werkzeug- oder LLM-Fehler ein. Timeouts, falsch formatierte Antworten oder leere Ergebnisse können einen Workflow unterbrechen. Fügen Sie Wiederholungsstrategien, Fallbacklogik oder eine einfachere Fallbackkette ein, wenn erweiterte Features fehlschlagen.
• Iterative Eingabeaufforderungsentwicklung
  • Erwarten Sie, dass Aufforderungen und Kettenlogik im Laufe der Zeit optimiert werden. Versionieren Sie jede Änderung (mit Git und MLflow), sodass Sie ein Rollback durchführen oder einen Leistungsvergleich über Versionen hinweg ausführen können.
  • Erwägen Sie Frameworks wie DSPy , um Eingabeaufforderungen und andere Komponenten in Ihrem Agentsystem programmgesteuert zu optimieren.

Produktionsleitfaden

• Latenz im Vergleich zur Kostenoptimierung
  • Jeder zusätzliche LLM- oder Toolaufruf erhöht den Tokenverbrauch und die Reaktionszeit. Kombinieren Sie nach Möglichkeit Schritte oder zwischenspeichern Sie wiederholte Abfragen, um die Leistung und Kosten überschaubar zu halten.
• Sicherheit und Sandboxing
  • Wenn Ihr Agent Datensätze aktualisieren oder Code ausführen kann, isolieren Sie diese Aktionen oder erzwingen Sie, falls erforderlich, eine menschliche Genehmigung. Dies ist in Unternehmens- oder regulierten Umgebungen wichtig, um unbeabsichtigte Schäden zu vermeiden.
  • Databricks empfiehlt Unity-Katalogtools für die Sandkastenausführung. Siehe Auswählen des Toolansatzes. Unity Catalog ermöglicht die Isolierung der willkürlichen Codeausführung und verhindert, dass böswillige Akteure den Agent dazu bringen, Code zu generieren und auszuführen, der andere Anforderungen stört oder abhört.

Anhand dieser Richtlinien können Sie viele der am häufigsten auftretenden Fehlermodi wie z. B. Fehlaufrufe von Tools, Verschlechterung der LLM-Leistung oder unerwartete Kostenspitzen mindern und zuverlässigere, skalierbare Agent-Systeme erstellen.