Warum Produktions-AI-Agenten mehr als nur einen guten Prompt benötigen
Produktions-KI-Agenten benötigen mehr als nur einen guten Prompt: Kontext, Tools, Speicherfähigkeit, Fehlerbehandlung, Überwachbarkeit, Testing sowie Autonomie, die zum tatsächlichen Risiko passen.
Quellen: AI Agents Are Easy to Demo. Production Is the Hard Part.
In einer Demo wirkt ein KI-Agent fast zu einfach. Geben Sie einem LLM ein Ziel, verbinden Sie einige Tools miteinander, fügen Sie etwas Speicher hinzu und schließen Sie alles in einen Schleifenzyklus ein. Plötzlich denkt das System nach, ruft APIs auf, durchsucht Dokumente und erledigt Aufgaben – der erste Prototyp wirkt fast wie Magie. Erst in der Produktion beginnt die eigentliche Ingenieurarbeit.
Verbringen Sie genügend Zeit mit Agentensystemen, und das zentrale Problem ändert sich. Das Modell intelligent genug zu machen, ist dann nicht mehr der schwierige Teil. Die schwierigere Frage ist, wie man ein kluges, aber nicht-deterministisches Element in ein System einbettet, dessen Gesamtbehavior dennoch vorhersehbar bleibt. Fast jede architektonische Entscheidung ergibt sich daraus.
Mehr als nur ein LLM mit Tools
Die übliche Abkürzung besagt, dass ein Agent ein LLM zusammen mit Tools und Speicher ist. Das eignet sich zur Erklärung des Konzepts, reicht aber für die praktische Anwendung nicht aus, wo eine umfassendere Formel gilt: Schlussfolgerungsfähigkeit, Kontext, Tools, Zustand, Arbeitsablauf, Schutzmechanismen, Beobachtbarkeit und Wiederherstellung. Das LLM ist wichtig, stellt aber nur einen einzigen Bestandteil dar.
Nehmen wir einen Dokumentanalyse-Agenten. Ein Benutzer lädt eine Datei hoch und bittet um eine Analyse. Hinter dieser einen Anfrage muss das System möglicherweise Folgendes tun:
- Überprüfen, ob die Anfrage gültig ist.
- Informationen aus dem Dokument extrahieren.
- Relevanten Kontext abrufen.
- Die richtige Anfrage formulieren.
- Lassen Sie das Modell auf der Grundlage der Beweise schlussfolgern.
- Überprüfen, was das Modell zurückgegeben hat.
- Zusätzliche Tools verwenden.
- Genaue Ergebnisse berechnen.
- Das Ergebnis speichern.
- Den Fortschritt an die Benutzeroberfläche melden.
- Jedes fehlgeschlagene Vorgehen erneut versuchen.
Zu diesem Zeitpunkt handelt es sich nicht mehr um schnelles Design, sondern um das Design eines verteilten Systems, das zufällig ein LLM enthält. Eine klare Aufteilung der Verantwortlichkeiten hilft dabei.
Eingabe und Kontext
Der Kontext umfasst alles, was das System über die zu bewältigende Aufgabe weiß: Benutzeranweisungen, Dokumente, Datenbankdaten, den Status des Workflows aus früheren Schritten, abgeruftes Wissen sowie Metadaten der Anwendung. Die wichtigste Erkenntnis ist, dass das Hinzufügen von Kontext im Allgemeinen nicht hilft. Wenn dem Modell alles gegeben wird, entsteht Rauschen, die Kosten steigen und es fällt schwerer, sein Denken vorherzusagen. Streben Sie nach dem kleinstmöglichen Kontext, der dennoch zur Entscheidungsfindung ausreicht.
Die Denkebene
Hier zeigt sich, wofür das LLM nützlich ist. Es kann mehrdeutige Informationen interpretieren, Dokumente lesen, Beweise vergleichen, ein Werkzeug auswählen, Erklärungen schreiben, Dinge klassifizieren und den nächsten Schritt planen. Eine Regel verdient besondere Betonung: Übertragen Sie dem Modell keine Entscheidungen, die durch gewöhnlichen Code zuverlässig getroffen werden können.
Nehmen wir an, eine Geschäftsregel lautet Varianz <= 5% → BESTANDEN. Niemand braucht ein LLM, um zu entscheiden, ob 3,8% unter 5% liegt – rechnen Sie es einfach aus. Verwenden Sie das Modell dort, wo logisches Denken erforderlich ist, und Code dort, wo Determinismus möglich ist. Diese Trennung macht Agentensysteme weitaus einfacher testbar.
Werkzeuge machen Agenten nützlich
Ein LLM ohne Werkzeuge beschreibt hauptsächlich Aktionen. Ausgestattet mit Werkzeugen führt es diese aus. Typische Werkzeuge sind Suchfunktionen, Datenbanken, APIs, Dokumentabrufsysteme, Codeausführung, interne Dienste sowie Workflow-Systeme. Der übliche Ablauf verläuft von der Anfrage des Benutzers zum Agenten, der ein Werkzeug auswählt, es ausführt, beobachtet, was zurückkommt, und fortfährt.
Das ist das Herzstück des ReAct-Musters: Denken, Handeln, Beobachten und anschließend erneut Denken. Es ist leistungsstark, weil der Agent nicht alle Fakten im Voraus kennen muss und während der Aufgabe das finden kann, was er benötigt.
Jedes Tool stellt außerdem eine weitere Stelle dar, an der Fehler auftreten können. Eine API kann ablaufen, Zugangsdaten können ungültig werden, eine Datenbank kann ausfallen, ein Tool kann fehlerhaft formatierte Daten zurückgeben und das Modell kann falsche Argumente übergeben. Das Aufrufen eines Tools sollte niemals bedeuten, die Anfrage des LLM an eine API zu senden und auf das Beste zu hoffen. Für die Produktion sind Validierung, Zeitlimits, Wiederholungsversuche, Fehlerbehandlung, Berechtigungen sowie klar definierte Fehlerrichtlinien erforderlich.
Gedächtnis ist kein Sammelakt
Gedächtnis gehört zu den am meisten missverstandenen Aspekten beim Entwurf von Agenten. Intuitiv scheint es, als würde ein Agent, der mehr behält, intelligenter werden. Oft ist das jedoch nicht der Fall. Wenn jede Interaktion für immer gespeichert und in spätere Anfragen eingefügt wird, erhält der Agent nur Rauschen statt echten Gedächtnisinhalts.
Es hilft, in Schichten zu denken:
- Arbeitsspeicher speichert das, was für die aktuelle Aufgabe benötigt wird, wie z. B. den Status des Arbeitsablaufs, aktuelle Ergebnisse von Tools und Zwischenergebnisse von Berechnungen.
- Langlebiger Speicher speichert Informationen, die für mehrere Aufgaben nützlich sind, wie z. B. Präferenzen, zuvor bestätigte Fakten und historische Ergebnisse.
- Außergewöhnliches Wissen sind Daten, die bereits an anderer Stelle vorhanden sind und nur auf Anfrage abgerufen werden, wie z. B. Dokumente, Richtlinien, Datenbanken und Ergebnisse von Vektorabfragen.
Die richtige Frage ist nicht, wie viel der Agent sich merken kann, sondern was er im Moment wissen muss. Diese kleine Veränderung kann eine Architektur erheblich vereinfachen.
Achten Sie bei vielen Agenten auf Vorsicht
Mehre-Agenten-Setups sind faszinierend. Ein Koordinator kann sich auf einen Dokumenten-Agenten, einen Forschungs-Agenten, einen Validierungs-Agenten und einen Berichterstatter-Agenten aufteilen, wobei jeder für einen spezialisierten Teil des Problems zuständig ist. Auf einem ansprechend aussehenden Diagramm – doch das sollte nicht der Standardausgangspunkt sein.
Jeder zusätzliche Agent bringt eine weitere Aufforderung, einen weiteren Zustandswechsel, einen weiteren Fehlermodus, eine weitere Kommunikationsgrenze, mehr Latenz sowie etwas Mehr zum Debuggen mit sich. Oft ist ein Agent mit drei guten Werkzeugen leistungsfähiger als vier Agenten, die miteinander kommunizieren.
Eine praktikable Regel ist, mit dem einfachsten Design zu beginnen, das das Problem löst, und nur dann einen Agenten hinzuzufügen, wenn dessen Bedarf an unabhängigem Denken oder Verantwortung klar definiert werden kann. Das Mehr-Agenten-Design sollte ein architektonisches Problem lösen und nicht nur einen beeindruckenden Eindruck erwecken.
Planung für Fehlschläge
Stellen Sie sich einen Workflow vor, der ein Dokument hochlädt, den Inhalt extrahiert, Kontext abruft, analysiert, ein Tool aufruft und einen Bericht erstellt. Nun stürzt der Agent direkt nach der Analyse ab. Wird alles neu gestartet? Wurde bereits etwas in die Datenbank geschrieben? Ist es sicher, die Operation zweimal auszuführen? Zeigt die Benutzeroberfläche den Vorgang weiterhin als laufend an? Kann ein anderer Worker ihn übernehmen?
Hier wird traditionelle Backend-Entwicklung unverzichtbar. Produktionsagenten benötigen:
- Wiederholungsversuche, damit vorübergehende Fehler den Workflow nicht ruinieren.
- Idempotenz, damit ein Wiederholungsversuch keine doppelten Nebeneffekte verursacht.
- Checkpointe, damit ein langer Workflow weiß, welche Schritte bereits abgeschlossen sind.
- Zeitlimits, weil ein Agent nicht endlos weiterarbeiten sollte.
QUEUED → RUNNING → COMPLETED oder QUEUED → RUNNING → FAILED → RETRYING.Keines davon klingt so aufregend wie Prompt Engineering, doch gerade diese Aspekte sorgen dafür, dass Agenten vertrauenswürdig sind.
Was der Agent getan hat – nachvollziehen
Normale Anwendungen benötigen bereits Protokolle und Metriken. Agenten brauchen noch mehr. Wenn ein Agent ein schlechtes Ergebnis liefert, sagt allein die Tatsache, dass die HTTP-Anfrage 200 OK zurückgab, fast nichts aus. Entscheidend ist der gesamte Ablauf: die Anfrage, der abgerufte Kontext, die Erstellung des Prompts, der Modellaufruf, die Auswahl des Tools, der Toolaufruf, die Bewertung des Ergebnisses und die endgültige Antwort.
Bei jedem Lauf sollte ein Team in der Lage sein, Folgendes wiederherzustellen:
- Den Kontext, der dem Agenten gegeben wurde
- Das ausgeführte Modell
- Die aufgerufenen Tools und in welcher Reihenfolge
- Die für jeden Schritt aufgewendete Zeit
- Der Tokenverbrauch
- Die Ursache eines Fehlers, sei es Infrastrukturprobleme oder Rechenfehler
- Das Urteil aus dem Bewertungsschritt
Das ist ein Grund, warum Tracing und Bewertung zu so wichtigen Bestandteilen des Agentenökosystems geworden sind. Was nicht beobachtet werden kann, kann auch nicht verbessert werden.
Testen von nicht-deterministischem Verhalten
Klassische Software bietet eine beruhigende Regel: Eingabe A ergibt Ausgabe B. LLMs halten sich daran nicht immer, da zwei gültige Antworten völlig unterschiedlich formuliert sein können. Daher benötigt das Testen mehrere Ebenen.
Deterministische Komponenten werden auf die übliche Weise getestet: APIs, Berechnungen, Schemata, Zustandsübergänge und Datenbankoperationen. Die modellgesteuerten Komponenten werden hinsichtlich faktischer Richtigkeit, Vollständigkeit, Relevanz, Qualität der Argumentation, Auswahl der Werkzeuge sowie Einhaltung von Anweisungen bewertet. Realistische End-to-End-Arbeitsabläufe sollten mit repräsentativen Daten ausgeführt werden, da sie Probleme aufdecken, die isolierte Anfragen übersehen. Selbst ein leistungsstarkes System kann nicht alle realen Eingaben abdecken, weshalb der Bewertungszyklus auch nach dem Deployment weiterläuft.
Autonomie sollte Risiken berücksichtigen
Manche gehen davon aus, dass ein „echter“ Agent vollständig autonom sein muss. Diese Sichtweise übersieht die Rolle der Risiken. Vergleichen wir drei Aktionen: Das Zusammenfassen eines Dokuments, das Empfehlen einer Änderung an einem Finanzdatensatz sowie die automatische Ausführung einer hochwirksamen Transaktion. Sie sollten nicht denselben Genehmigungsmechanismus teilen. Eine praktische Lösung sieht wie folgt aus:
- Niedriges Risiko: Ausführen automatisch.
- Mittleres Risiko: Ausführen und anschließend protokollieren oder überprüfen.
- Hohes Risiko: Vor der Ausführung menschliche Genehmigung erforderlich.
Ziel ist nicht maximale Autonomie, sondern nützliche Autonomie bei kontrolliertem Risiko.
Insgesamt ergibt sich ein klares Bild, und das LLM stellt sich dabei als relativ kleiner Bestandteil dar. Das ist beabsichtigt.
Fragen vor der Auswahl eines Frameworks
Vor der Wahl eines Frameworks oder dem Verfassen einer ausführlichen Anweisung lohnt es sich, einige Fragen zu stellen:
- Welche Entscheidung benötigt wirklich KI? Ein einzelner Schlussfolgerungs Schritt macht den gesamten Arbeitsablauf nicht intelligent.
- Was kann deterministisch bleiben? Berechnungen, Validierungen, Berechtigungen und kritische Geschäftsregeln gehören in den Code.
Prompt-Engineering, Modellauswahl und RAG sind weiterhin wichtig. Doch in der Produktion wird eine breitere Disziplin benötigt: eine Softwarearchitektur, die auf probabilistischer Intelligenz beruht. Das beste Design ist nicht das mit den meisten Agenten, dem größten Modell oder dem aufwendigsten Orchestrierungsframework. Es ist vielmehr das, bei dem man genau definieren kann, was der Agent weiß, was er tun kann und was nicht, wie die Korrektheit gemessen wird, was bei Fehlern passiert und wie das System sich erholt. Dann hört ein KI-Agent auf, nur eine nette Demonstration zu sein, und wird zu Software, der man vertrauen kann.