Von Architekturentscheidungen bis zum Produktiv-Deployment deckt dieser Leitfaden alles ab, was Sie zum Aufbau zuverlässiger, sicherer und tatsächlich nützlicher KI-Agenten benötigen. ReAct-Schleifen, Multi-Agent-Orchestrierung, Leitplanken, Evaluierung und die hart erarbeiteten Muster, die Demos von Produktionssystemen unterscheiden.
Ein KI-Agent ist ein System, das ein großes Sprachmodell als Reasoning-Engine nutzt, um zu entscheiden, welche Aktionen zu ergreifen sind, diese Aktionen über Tools ausführt, die Ergebnisse beobachtet und iteriert, bis ein Ziel erreicht ist. Anders als ein einfacher LLM-Aufruf, der eine Eingabe annimmt und eine Ausgabe zurückgibt, arbeitet ein Agent in einer Schleife mit der Fähigkeit, seine Umgebung zu beeinflussen.
Der entscheidende Unterschied liegt in Autonomie und Tool-Nutzung. Ein Chatbot beantwortet Fragen. Ein Agent bucht das Meeting, legt das Ticket an, fragt die Datenbank ab und schreibt den Bericht — und entscheidet bei jedem Schritt, was als Nächstes zu tun ist, basierend auf dem, was er bisher gelernt hat.
Nicht jedes System benötigt volle Autonomie. Zu verstehen, wo Ihr Anwendungsfall auf diesem Spektrum liegt, bestimmt Ihre Architektur, Ihre Sicherheitsanforderungen und Ihre betriebliche Komplexität.
Prompt rein, Antwort raus. Keine Tools, keine Schleife. Klassifizierung, Zusammenfassung, Extraktion.
Das Modell ruft ein oder mehrere Tools auf und synthetisiert die Ergebnisse. Die meisten Function-Calling-Chatbots.
Das Modell denkt nach, handelt, beobachtet und wiederholt. Es entscheidet, wann es fertig ist. ReAct-Agenten.
Mehrere spezialisierte Agenten koordinieren sich, um komplexe Aufgaben zu lösen. Supervisor- oder Swarm-Muster.
Agenten überwachen, planen und handeln über lange Zeithorizonte mit minimaler menschlicher Aufsicht. Erfordert umfangreiche Leitplanken.
Agenten erhöhen Latenz, Kosten und Unvorhersehbarkeit. Wenn Sie das Problem mit einer deterministischen Pipeline lösen können (Extraktion, Klassifizierung, fester Workflow), tun Sie das. Greifen Sie zu Agenten, wenn die Aufgabe dynamische Entscheidungsfindung erfordert: wenn Sie nicht im Voraus vorhersagen können, welche Tools in welcher Reihenfolge und wie oft aufzurufen sind. Ist die Verzweigungslogik zur Entwurfszeit bekannt, verwenden Sie einen Workflow; muss sie zur Laufzeit ermittelt werden, verwenden Sie einen Agenten.
Die gewählte Architektur bestimmt, wie Ihr Agent denkt, plant und Arbeit koordiniert. Jedes Muster hat unterschiedliche Kompromisse hinsichtlich Steuerbarkeit, Latenz und Komplexität.
Der Agent verschränkt Reasoning-Spuren mit Tool-Aufrufen in einer Schleife: Gedanke, Aktion, Beobachtung, wiederholen.
Das LLM entscheidet, welche Tools mit welchen Argumenten aufzurufen sind, und synthetisiert die Ergebnisse dann zu einer endgültigen Antwort.
Ein Planer-LLM erzeugt im Voraus einen mehrstufigen Plan, dann führt ein Ausführer-LLM jeden Schritt sequenziell aus.
Mehrere spezialisierte Agenten arbeiten zusammen, jeder verantwortet eine bestimmte Domäne oder Fähigkeit, koordiniert von einem Supervisor.
Ein zentraler Agent leitet Aufgaben an spezialisierte Sub-Agenten weiter und aggregiert deren Ausgaben. Saubere Trennung der Zuständigkeiten, aber der Supervisor ist ein Engpass und Single Point of Failure.
Am häufigsten in der ProduktionAgenten übergeben kontextbasiert direkt aneinander. Kein zentraler Koordinator. Widerstandsfähiger, aber schwerer zu debuggen und nachzuvollziehen.
Aufkommendes MusterEin Baum von Supervisoren, von denen jeder ein Team von Sub-Agenten verwaltet. Ermöglicht komplexe Organisationsstrukturen, fügt aber erheblichen Koordinationsaufwand hinzu.
Nur für komplexe AnwendungsfälleBeginnen Sie mit der einfachsten Architektur, die funktionieren könnte. Ein einzelner ReAct-Agent mit guten Tools übertrifft jedes Mal ein schlecht entworfenes Multi-Agent-System. Fügen Sie Komplexität nur hinzu, wenn Sie Belege dafür haben, dass ein einfacherer Ansatz Ihre Anforderungen nicht erfüllen kann. Die meisten Produktiv-Agent-Systeme, die wir bauen, verwenden einen einzelnen Agenten mit 5-15 gut entworfenen Tools.
Die Landschaft der Agent-Frameworks entwickelt sich rasant. Hier ist ein ehrlicher Vergleich der führenden Optionen, basierend auf unserer Erfahrung beim Aufbau von Produktionssystemen mit jeder davon.
| Framework | Am besten für | Vorteile | Nachteile | Reife |
|---|---|---|---|---|
| LangGraph | Komplexe zustandsbehaftete Workflows, Produktionssysteme | Feingranulare Steuerung, Human-in-the-Loop, Persistenz, Streaming | Steilere Lernkurve, graphbasiertes mentales Modell | Hoch |
| CrewAI | Multi-Agent-Zusammenarbeit, rollenbasierte Aufgaben | Einfache API, Rolle/Ziel/Hintergrund-Modell, integrierte Delegation | Weniger Kontrolle über den Ausführungsfluss, schwerer zu debuggen | Mittel |
| OpenAI Agents SDK | OpenAI-native Apps, schnelles Prototyping | Natives Tool-Calling, Übergaben, Leitplanken, integriertes Tracing | Anbieterbindung, eingeschränkte Modellauswahl | Mittel |
| AutoGen | Forschung, konversationelle Multi-Agent-Muster | Flexible Gesprächsmuster, Code-Ausführung, verschachtelte Chats | Komplexe Konfiguration, schwerere Abstraktion | Mittel |
| Custom (no framework) | Volle Kontrolle, minimale Abhängigkeiten, spezifische Einschränkungen | Kein Abstraktionsaufwand, genau das, was Sie brauchen, leicht zu auditieren | Mehr Boilerplate, Persistenz/Streaming müssen Sie selbst bauen | k. A. |
Für die meisten Produktiv-Anwendungsfälle empfehlen wir LangGraph für Python-basierte Systeme oder eine benutzerdefinierte Implementierung für TypeScript. LangGraph bietet feingranulare Kontrolle über den Ausführungsgraphen, integrierte Persistenz und Human-in-the-Loop-Muster ohne übermäßige Abstraktion. Für einfachere Anwendungsfälle bietet das OpenAI Agents SDK einen schnelleren Weg zur Produktion, wenn Sie bereits im OpenAI-Ökosystem unterwegs sind.
Tools sind die Hände und Augen Ihres Agenten. Die Qualität Ihrer Tool-Schnittstellen ist der größte einzelne Bestimmungsfaktor für die Agent-Leistung. Ein mittelmäßiges Modell mit hervorragenden Tools übertrifft ein Spitzenmodell mit schlecht entworfenen Tools.
Tool-Namen sollten Verb-Substantiv-Paare sein (search_documents, create_ticket). Beschreibungen sollten erklären, wann das Tool zu verwenden ist, nicht nur, was es tut.
Definieren Sie strikte JSON-Schemata mit Enums, Min/Max-Grenzen und Pflichtfeldern. Das LLM erzeugt bessere Argumente, wenn das Schema seinen Ausgaberaum einschränkt.
Geben Sie strukturierte Fehler zurück, über die der Agent nachdenken kann. Statt eines generischen Fehlschlags geben Sie zurück, was schiefging und was der Agent anders versuchen sollte.
Nur-Lese-Tools sollten frei aufrufbar sein. Schreib-Tools sollten nach Möglichkeit idempotent sein, und destruktive Aktionen sollten eine Bestätigung erfordern.
Führen Sie Code-Ausführungs-Tools in isolierten Containern aus. Begrenzen Sie Dateisystemzugriff, Netzwerkaufrufe und Ausführungszeit. Geben Sie Agenten niemals Root- oder Admin-Anmeldedaten.
Geben Sie nur zurück, was der Agent benötigt. Vollständige API-Antworten abzuladen verschwendet Tokens des Kontextfensters und verwirrt das Modell. Fassen Sie zusammen oder extrahieren Sie Schlüsselfelder.
Jede Tool-Beschreibung sollte für das LLM drei Fragen beantworten: Was tut dieses Tool? Wann sollte es verwendet werden? Welche Einschränkungen gibt es?
In der Praxis lassen sich die meisten Agent-Fehler auf drei Grundursachen zurückführen: (1) mehrdeutige Tool-Beschreibungen, die das Modell das falsche Tool wählen lassen, (2) Tool-Ausgaben, die zu groß oder zu unstrukturiert sind, als dass das Modell sie verarbeiten könnte, und (3) fehlende Fehlerinformationen, die den Agenten an der Erholung hindern. Beheben Sie diese drei Dinge, bevor Sie zu einem leistungsstärkeren Modell greifen.
Ein Agent ohne Speicher ist zustandslos — er vergisst zwischen den Turns alles. Produktiv-Agenten benötigen mehrere Speicherebenen, um Kontext zu wahren, aus Erfahrung zu lernen und langlaufende Aufgaben zu verwalten.
Der aktuelle Gesprächsverlauf, der als Nachrichten an das LLM übergeben wird. Dies ist die grundlegendste Form des Speichers und wird vom Chat-Framework verwaltet.
Fakten, Präferenzen und Wissen, die über Sitzungen hinweg in einem Vector Store oder einer strukturierten Datenbank persistiert werden. Zur Inferenzzeit über semantische Ähnlichkeit abgerufen.
Aufzeichnungen vergangener Agent-Trajektorien: was der Agent versuchte, was funktionierte, was fehlschlug. Ermöglicht das Lernen aus Erfahrung ohne Neutraining.
Ein strukturiertes Scratchpad, das der Agent während einer einzelnen Aufgabe verwendet, um Zwischenzustand, Teilergebnisse und nächste Schritte zu verfolgen.
Ein verbreiteter Irrtum ist, dass größere Kontextfenster die Notwendigkeit der Speicherverwaltung beseitigen. Das tun sie nicht. Selbst bei Fenstern mit über 200k Tokens verschlechtert sich die Leistung bei Informationen, die in der Mitte langer Kontexte vergraben sind. Noch entscheidender: alles in das Kontextfenster zu stopfen ist teuer — zu aktuellen Preisen kostet ein Kontext mit 100k Tokens pro Aufruf 10-50x mehr als ein gut verwalteter Kontext mit 4k Tokens und gezieltem Abruf.
Agenten haben die Fähigkeit, echte Aktionen in der Welt auszuführen. Das macht Leitplanken nicht verhandelbar. Ein schlecht eingegrenzter Agent kann falsche E-Mails senden, Daten löschen oder Ihr gesamtes API-Budget in Minuten ausgeben. Sicherheit ist kein Feature, das man später hinzufügt — sie ist eine Entwurfseinschränkung vom ersten Tag an.
Halten Sie die Ausführung vor irreversiblen Aktionen an (E-Mails senden, Datenbanken ändern, Käufe tätigen). Präsentieren Sie die geplante Aktion und warten Sie auf eine ausdrückliche Freigabe.
Leiten Sie an einen Menschen weiter, wenn die Konfidenz des Agenten unter einem Schwellenwert liegt. Nützlich für Grenzfälle außerhalb der Trainingsverteilung.
Lassen Sie den Agenten Aufgaben abschließen, markieren Sie aber Ausgaben für eine asynchrone menschliche Prüfung. Gut für Aufgaben mit hohem Volumen und geringerem Risiko, bei denen Geschwindigkeit zählt.
Ohne explizite Iterationsgrenzen können Agenten in Endlosschleifen geraten — sie rufen wiederholt dasselbe Tool mit leicht unterschiedlichen Argumenten auf oder oszillieren zwischen zwei Zuständen. Jeder Produktiv-Agent muss eine harte maximale Iterationsanzahl (typischerweise 10-25 Schritte) und ein Wanduhrzeit-Timeout haben. Wird eine der Grenzen erreicht, sollte der Agent anmutig ein Teilergebnis mit einer Erklärung zurückgeben, anstatt stillschweigend zu scheitern.
Agenten zu testen ist grundlegend schwieriger als das Testen herkömmlicher Software. Agenten sind nicht-deterministisch; ihr Verhalten hängt vom Modell, den Tools und der Umgebung ab. Sie benötigen eine mehrschichtige Evaluierungsstrategie, die Korrektheit, Effizienz, Sicherheit und Kosten abdeckt.
| Dimension | Beschreibung | Zielwert | Wie zu messen |
|---|---|---|---|
| Aufgabenerfüllung | Hat der Agent das angegebene Ziel erreicht? | > 85% | Binäres Bestehen/Durchfallen an einer zurückgehaltenen Aufgabensuite |
| Trajektorien-Effizienz | Wie viele Schritte unternahm der Agent im Vergleich zum Optimum? | < 1.5x Optimum | Schrittzahl mit von Experten erstellten Lösungen vergleichen |
| Tool-Genauigkeit | Wurden die richtigen Tools mit korrekten Argumenten aufgerufen? | > 90% | Trace-Vergleich mit erwarteten Tool-Aufruf-Sequenzen |
| Sicherheitskonformität | Hat der Agent Leitplanken und Grenzen respektiert? | 100% | Red-Team-Tests mit adversen Prompts |
| Latenz (P95) | End-to-End-Zeit von der Nutzereingabe bis zur endgültigen Antwort | < 30s | Perzentil-Verfolgung über den Produktionsverkehr |
| Kosten pro Aufgabe | Gesamtkosten für LLM + Tool-Aufrufe pro abgeschlossener Aufgabe | Innerhalb des Budgets | Verfolgung von Tokens und API-Aufrufen pro Trace |
Testen Sie jedes Tool isoliert mit bekannten Eingaben und erwarteten Ausgaben. Mocken Sie externe Abhängigkeiten. Dies ist Standard-Softwaretest und fängt Integrationsfehler ab, bevor sie sich in der Agent-Schleife verstärken.
Zeichnen Sie die vollständige Sequenz von Tool-Aufrufen, Argumenten und Beobachtungen für eine Reihe von Testaufgaben auf. Vergleichen Sie mit Referenz-Trajektorien, die von Domänenexperten erstellt wurden. Bewerten Sie sowohl das Endergebnis als auch die Effizienz des eingeschlagenen Wegs.
Erstellen Sie eine Suite von 50-200 repräsentativen Aufgaben mit bekannten korrekten Ergebnissen. Führen Sie den vollständigen Agenten gegen diese Aufgaben aus und messen Sie die Aufgabenerfüllungsrate. Führen Sie die Suite vor jedem Deployment und nach Modell-Upgrades erneut aus.
Sondieren Sie den Agenten systematisch mit Prompt-Injections, Anfragen außerhalb des Geltungsbereichs, Grenzfällen und adversen Eingaben. Stellen Sie sicher, dass die Leitplanken unter Belastung standhalten. Dies ist besonders wichtig für nutzerseitige Agenten.
Plattformen für Tracing und Evaluierung in der Produktion. Zeichnen Sie jede Agent-Ausführung auf, annotieren Sie Traces, führen Sie Evaluierungen auf historischen Daten aus und fangen Sie Regressionen ab.
Frameworks zur Evaluierung von Prompts und Agenten. Definieren Sie Testsuiten als Code, bewerten Sie Ausgaben mit benutzerdefinierten Evaluatoren und integrieren Sie sie in CI-Pipelines.
Die Lücke zwischen einer funktionierenden Demo und einem Produktiv-Agenten ist enorm. Produktiv-Agenten müssen observierbar, kosteneffizient, ausfallresistent und unter Last skalierbar sein.
Sobald Sie ein funktionierendes Einzel-Agent-System in der Produktion haben, können diese Muster neue Fähigkeiten erschließen. Jedes fügt erhebliche Komplexität hinzu, übernehmen Sie sie daher nur, wenn Sie einen klaren Bedarf und die betriebliche Reife haben, um sie zu tragen.
Nach der Erzeugung einer Ausgabe bewertet ein separater LLM-Aufruf (oder dasselbe Modell mit einem Kritiker-Prompt) die Qualität des Ergebnisses und schlägt Verbesserungen vor. Der Agent überarbeitet dann seine Ausgabe auf Basis der Kritik. Dies ist besonders wirksam bei Codegenerierung, Schreiben und Analyseaufgaben, bei denen sich die Qualität durch Iteration verbessert.
Implementierungshinweis: Beschränken Sie die Reflexion auf 2-3 Runden. Darüber hinaus stagniert die Qualität, während die Kosten linear steigen. Verwenden Sie strukturierte Bewertungskriterien für den Kritiker, um vage Feedback-Schleifen zu vermeiden.
Am besten für qualitätssensible AusgabenStellen Sie Ihren Agenten als API-Endpunkt bereit, den andere Systeme aufrufen können. Der Agent wird zu einem Microservice, der Aufgabenbeschreibungen annimmt und Ergebnisse zurückgibt. Dies ermöglicht Komposition: ein Orchestrator-Agent kann spezialisierte Agent-Dienste aufrufen, jeder mit eigenen Tools und Domänenwissen.
Zentrale Entwurfsüberlegungen: asynchrone Ausführung mit Webhooks für lange Aufgaben, Idempotenzschlüssel für Wiederholungssicherheit, versionierte API-Verträge und klare SLAs für Antwortzeit und Erfolgsrate.
Am besten für Plattformteams und interne WerkzeugeEin Meta-Agent zerlegt komplexe Aufgaben in Teilaufgaben, leitet jede an den am besten geeigneten Spezialisten-Agenten weiter und aggregiert die Ergebnisse. Dies ist das Multi-Agent-Supervisor-Muster im großen Maßstab, bei dem jeder Sub-Agent selbst ein Dienst mit eigenen Tools, eigenem Speicher und eigenen Leitplanken sein kann.
Der Orchestrator benötigt: eine Strategie zur Aufgabenzerlegung (LLM-basiert oder regelbasiert), ein Fähigkeitsregister der verfügbaren Agenten, eine Fehlerbehandlung für Teilausfälle und einen Syntheseschritt, der Teilergebnisse kohärent zusammenführt.
Am besten für Unternehmens-Workflows über mehrere DomänenDer Agent zeichnet erfolgreiche und fehlgeschlagene Trajektorien auf und ruft dann zur Inferenzzeit ähnliche vergangene Erfahrungen ab, um seine aktuellen Entscheidungen zu fundieren. Mit der Zeit lernt der Agent effektiv aus seiner eigenen Produktionshistorie ganz ohne Modell-Fine-Tuning. Fehlgeschlagene Trajektorien werden mit einer Grundursachenanalyse annotiert und als Negativbeispiele eingeschleust.
Dies erfordert: einen Trajektorienspeicher (Vector DB, indexiert nach Aufgabenbeschreibung), einen Ähnlichkeitsschwellenwert für den Abruf, menschliche Annotation der Fehlermodi und eine Prompt-Vorlage, die vergangene Beispiele als Few-Shot-Kontext einbindet.
Am besten für wiederkehrende domänenspezifische AufgabenNicht alle Agenten reagieren auf Nutzer-Prompts. Manche laufen nach Zeitplänen (cron-artig) oder werden durch Ereignisse ausgelöst (neue E-Mail, Slack-Nachricht, Datenbankänderung). Diese Hintergrund-Agenten überwachen, fassen zusammen, eskalieren und automatisieren Routine-Workflows ohne menschliche Auslösung.
Entwurfsmuster: Polling + Änderungserkennung, webhook-ausgelöste Ausführung, Dead-Letter-Warteschlangen für fehlgeschlagene Läufe und idempotente Verarbeitung, um doppelte Ereignisse sicher zu handhaben.
Am besten für BetriebsautomatisierungOb Sie Ihr erstes Agent-System entwerfen oder ein bestehendes skalieren — wir helfen Ihnen, die Architekturentscheidungen zu navigieren, häufige Fallstricke zu vermeiden und Agenten auszuliefern, die zuverlässig, sicher und kosteneffizient sind.
Bauen Sie Retrieval-Augmented-Generation-Systeme, die in der Produktion funktionieren
Stellen Sie sicher, dass Ihre KI-Agenten die regulatorischen Anforderungen erfüllen
End-to-End-Design, -Aufbau und -Deployment von KI-Agenten