Warum viele agentische Systeme in Produktion versagen — und wie Sie zuverlässige Agenten mit Zustandsautomaten, klaren Tool‑Verträgen, Retries und tiefer Observability entwerfen.
Agentische Systeme sind Anwendungen, in denen ein LLM nicht nur eine Eingabe beantwortet, sondern entscheidet, was als Nächstes zu tun ist: welche Tools aufzurufen sind, welche Daten zu holen sind, welche Schritte auszuführen sind und wann es „fertig“ ist. Sie kombinieren ein Modell, eine Menge von Tools (APIs, Datenbanken, Services), eine Planungs/Execution‑Schleife und die Infrastruktur, die alles verbindet.
In einer Demo wirkt das magisch: ein Agent findet einen Plan, ruft ein paar Tools auf und liefert ein perfektes Ergebnis. Der Happy Path ist kurz, die Latenz niedrig und nichts fällt gleichzeitig aus.
Unter realer Last wird derselbe Agent auf Arten belastet, die die Demo nie gesehen hat:
Das Ergebnis: flakiges Verhalten, schwer reproduzierbare Fehler, stille Datenkorruption und Nutzerflüsse, die gelegentlich hängenbleiben oder endlos drehen.
Flaky Agenten schaden nicht nur dem „Delight“. Sie:
Dieser Artikel handelt von Engineering‑Mustern, nicht von „besseren Prompts“. Wir betrachten Zustandsautomaten, explizite Tool‑Verträge, Retry‑ und Fehlerbehandlungsstrategien, Speicher‑ und Nebenläufigkeitskontrolle sowie Observability‑Muster, die agentische Systeme unter Last vorhersehbar machen — nicht nur auf der Bühne beeindruckend.
Die meisten Agentensysteme wirken in einem einzelnen Happy‑Path‑Demo in Ordnung. Sie fallen auseinander, wenn Traffic, Tools und Edge‑Cases zusammenkommen.
Naive Orchestrierung geht davon aus, dass das Modell in ein oder zwei Aufrufen „das Richtige“ tut. Unter realer Nutzung sehen Sie wiederkehrende Muster:
Ohne explizite Zustände und Endbedingungen sind diese Verhaltensweisen unvermeidlich.
LLM‑Sampling, Latenzvariabilität und Tool‑Timing erzeugen versteckte Nichtdeterministik. Dieselbe Eingabe kann unterschiedliche Zweige durchlaufen, verschiedene Tools aufrufen oder Tool‑Ergebnisse unterschiedlich interpretieren.
Bei Skalierung dominieren Tool‑Probleme:
Jedes dieser Probleme verwandelt sich in willkürliche Schleifen, Retries oder falsche Endantworten.
Was bei 10 RPS selten kaputtgeht, bricht bei 1.000 RPS konstant zusammen. Nebenläufigkeit offenbart:
Produktteams erwarten oft deterministische Workflows, klare SLAs und Auditierbarkeit. Agenten, unbegrenzt gelassen, bieten probabilistisches, best‑effort‑Verhalten mit schwachen Garantien.
Wenn Architekturen diese Diskrepanz ignorieren — Agenten wie traditionelle Services statt wie stochastische Planer behandeln — verhalten sich Systeme genau dann unvorhersehbar, wenn Zuverlässigkeit am wichtigsten ist.
Produktionsbereite Agenten sind weniger „bessere Prompts“ und mehr diszipliniertes Systemdesign. Eine hilfreiche Denkweise: Betrachte sie als kleine, vorhersehbare Maschinen, die gelegentlich ein LLM aufrufen, nicht als mysteriöse LLM‑Blobs, die sporadisch deine Systeme berühren.
Vier Eigenschaften sind besonders wichtig:
Diese Eigenschaften erhalten Sie nicht nur durch Prompts. Sie erhalten sie durch Struktur.
Das Standardmuster vieler Teams ist: „while not done: call the model, let it think, maybe call a tool, repeat“. Das ist leicht zu prototypisieren und schwer zu betreiben.
Ein sichereres Muster ist, den Agenten als expliziten Workflow zu repräsentieren:
COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).Das verwandelt den Agenten in einen Zustandsautomaten, bei dem jeder Schritt einsehbar, testbar und replaybar ist. Freiform‑Schleifen wirken flexibel, aber explizite Workflows machen Incidents debugbar und Verhalten auditierbar.
Monolithische Agenten, die „alles“ machen, sind verlockend, erzeugen aber enge Kopplung zwischen unverbundenen Verantwortlichkeiten: Planung, Retrieval, Geschäftslogik, UI‑Orchestrierung usw.
Stattdessen komponieren Sie kleine, gut abgegrenzte Agenten oder Skills:
Jeder Skill kann seinen eigenen Zustandsautomaten, Tools und Sicherheitsregeln haben. Die Kompositionslogik wird damit zu einem höherstufigen Workflow, nicht zu einem ständig wachsenden Prompt innerhalb eines einzelnen Agenten.
Diese Modularität hält jeden Agenten einfach verständlich und erlaubt, eine Fähigkeit zu erweitern, ohne den Rest zu destabilisieren.
Ein nützliches mentales Modell ist die Aufteilung eines Agenten in drei Schichten:
Entscheidungs‑Policy (LLM‑Prompts + Modell)
Kapselt wie der Agent nächste Aktionen auswählt, interpretiert unter strikten Beschränkungen. Sie sollten Modell und Temperatur austauschen oder Prompts verfeinern können, ohne die Systemverdrahtung zu ändern.
Zustandsmaschine / Workflow‑Engine
Besitzt wo Sie sich im Prozess befinden, welche Übergänge möglich sind und wie Fortschritt persistiert wird. Die Policy schlägt einen Schritt vor; die Zustandsmaschine validiert und wendet ihn an.
Tooling‑Layer
Implementiert was tatsächlich in der Welt passieren kann: APIs, Datenbanken, Queues, externe Services. Tools bieten enge, wohltypisierte Verträge und erzwingen Autorisierung, Ratenbegrenzung und Input‑Validierung.
Durch diese Trennung vermeiden Sie, Geschäftslogik in Prompts oder Tool‑Beschreibungen zu verstecken. Das LLM wird so zu einer Entscheidungs‑Komponente innerhalb einer klaren, deterministischen Hülle — nicht zur Hülle selbst.
Die zuverlässigsten agentischen Systeme sind nicht die beeindruckendsten Demos — es sind die Systeme, deren Verhalten Sie auf einem Whiteboard erklären können.
Konkretes Vorgehen:
Diese Neigung zu kleinen, komponierbaren, gut strukturierten Agenten erlaubt es, den Funktionsumfang zu vergrößern, ohne dass das System unter der eigenen Komplexität zusammenbricht.
Die meisten Agentenimplementierungen beginnen als Schleife „denken, handeln, beobachten“ um einen LLM‑Aufruf. Das ist für Demos in Ordnung, wird aber schnell undurchsichtig und brüchig. Ein besserer Ansatz ist, den Agenten als expliziten Zustandsautomaten zu behandeln: eine endliche Menge von Zuständen mit wohldefinierten Übergängen, ausgelöst durch Ereignisse.
Anstatt das Modell implizit entscheiden zu lassen, was als Nächstes zu tun ist, definieren Sie ein kleines Zustandsdiagramm:
Übergänge zwischen diesen Zuständen werden durch typisierte Ereignisse wie UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded oder HumanOverride ausgelöst. Jedes Ereignis plus der aktuelle Zustand bestimmt den nächsten Zustand und die auszuführenden Aktionen.
Das macht Retries und Timeouts einfach: Sie hängen Richtlinien an einzelne Zustände (z. B. CALL_TOOL darf 3‑mal mit exponentiellem Backoff versucht werden, PLAN wird überhaupt nicht erneut versucht) statt Retry‑Logik im gesamten Code zu verstreuen.
Persistieren Sie den aktuellen Zustand und den minimalen Kontext in einem externen Store (Datenbank, Queue oder Workflow‑Engine). Der Agent wird dadurch zu einer reinen Funktion:
next_state, actions = transition(current_state, event, context)
Das ermöglicht:
Mit einem Zustandsautomaten ist jeder Schritt des Agentenverhaltens explizit: in welchem Zustand er war, welches Ereignis eintrat, welcher Übergang feuert und welche Seiteneffekte erzeugt wurden. Diese Klarheit beschleunigt Debugging, vereinfacht Incident‑Untersuchungen und schafft eine natürliche Audit‑Spur für Compliance‑Reviews. Sie können aus Logs und Zustandshistorie beweisen, dass bestimmte riskante Aktionen nur aus definierten Zuständen und unter bestimmten Bedingungen ausgeführt werden.
Agenten verhalten sich viel vorhersehbarer, wenn Tools weniger wie „APIs versteckt in Prosatext“ aussehen und mehr wie gut gestaltete Interfaces mit expliziten Garantien.
Jedes Tool sollte einen Vertrag enthalten, der abdeckt:
InvalidInput, NotFound, RateLimited, TransientFailure) mit klarer Semantik.Stellen Sie diese Verträge dem Modell als strukturierte Dokumentation bereit, nicht als langen Fließtext. Der Agent‑Planner sollte wissen, welche Fehler retriable sind, welche Nutzerintervention erfordern und welche den Workflow stoppen.
Behandeln Sie Tool‑I/O wie jede andere Produktions‑API:
Das vereinfacht Prompts: statt langer Anweisungen verlassen Sie sich auf schema‑gesteuerte Guidance. Klare Constraints reduzieren halluzinierte Argumente und unsinnige Tool‑Sequenzen.
Tools entwickeln sich; Agenten dürfen dadurch nicht bei jeder Änderung kaputtgehen.
v1, v1.1, v2) und pinnen Sie Agenten an eine Version.Die Planungslogik kann dann sicher Agents und Tools mit unterschiedlichen Reifegraden mischen.
Entwerfen Sie Verträge mit Teil‑Fehlerfällen im Blick:
Der Agent kann dann adaptieren: den Workflow mit reduzierter Funktionalität fortsetzen, den Nutzer um Bestätigung bitten oder auf ein alternatives Tool wechseln.
Tool‑Verträge sind ein natürlicher Ort, Sicherheitsgrenzen zu kodieren:
confirm: true).Kombinieren Sie das mit serverseitigen Prüfungen; verlassen Sie sich nie ausschließlich darauf, dass das Modell „sich benimmt“.
Wenn Tools klare, validierte, versionierte Verträge haben, werden Prompts kürzer, Orchestrierungslogik einfacher und Debugging deutlich leichter. Sie verschieben Komplexität aus brüchigen natürlichen‑Sprach‑Anweisungen in deterministische Schemata und Policies und reduzieren halluzinierte Tool‑Aufrufe sowie unerwartete Seiteneffekte.
Zuverlässige agentische Systeme gehen davon aus, dass alles irgendwann ausfällt: Modelle, Tools, Netzwerke, sogar die eigene Koordinationsschicht. Ziel ist nicht, Ausfall zu vermeiden, sondern ihn günstig und sicher zu machen.
Idempotenz bedeutet: Die Wiederholung derselben Anfrage hat denselben äußerlich sichtbaren Effekt wie einmalige Ausführung. Das ist essenziell für LLM‑Agenten, die häufig Tool‑Aufrufe nach partiellen Fehlern oder uneindeutigen Antworten erneut senden.
Machen Sie Tools idempotent durch Design:
request_id. Das Tool speichert diese und liefert bei erneutem Auftreten dieselben Ergebnisse zurück.Verwenden Sie strukturierte Retries für transiente Fehler (Timeouts, Ratenlimits, 5xx): exponentiellen Backoff, Jitter zur Vermeidung von Thundering Herden und strikte Max‑Versuche. Loggen Sie jeden Versuch mit Korrelations‑IDs, um Agentenverhalten nachzuvollziehen.
Bei permanenten Fehlern (4xx, Validierungsfehler, Geschäftsregelverletzungen) retryen Sie nicht. Surface‑en Sie einen strukturierten Fehler an die Agent‑Policy, damit diese neu plant, den Nutzer fragt oder ein anderes Tool wählt.
Implementieren Sie Circuit Breaker sowohl in Agent‑ als auch in Tool‑Layer: nach wiederholten Fehlern blockieren Sie temporär Aufrufe an dieses Tool und failen schnell. Kombinieren Sie das mit definierten Fallbacks: degraded modes, gecachte Daten oder alternative Tools.
Vermeiden Sie blinde Retries aus der Agent‑Schleife. Ohne idempotente Tools und klare Fehlerklassen vervielfachen Sie nur Seiteneffekte, Latenz und Kosten.
Zuverlässige Agenten beginnen mit klarer Überlegung, was Zustand ist und wo er liegt.
Behandeln Sie einen Agenten wie einen Service, der eine Anfrage bearbeitet:
Eine Vermischung führt zu Verwirrung und Bugs. Beispielsweise macht das Ablegen ephemerer Tool‑Ergebnisse in „Memory“, dass Agenten veralteten Kontext in zukünftigen Gesprächen wiederverwenden.
Sie haben drei Hauptoptionen:
Eine gute Regel: Das LLM ist eine zustandslose Funktion über ein explizites State‑Objekt. Persistieren Sie dieses Objekt außerhalb des Modells und generieren Sie Prompts daraus.
Ein häufiger Fehler ist, Konversationsprotokolle, Traces oder rohe Prompts als de‑facto Memory zu verwenden.
Probleme:
Stattdessen definieren Sie strukturierte Memory‑Schemas: user_profile, project, task_history usw. Leiten Sie Logs aus State ab, nicht umgekehrt.
Wenn mehrere Tools oder Agenten dieselben Entitäten updaten (z. B. ein CRM‑Eintrag oder der Status einer Aufgabe), brauchen Sie grundlegende Konsistenzkontrollen:
Bei wertvollen Operationen halten Sie ein Decision Log getrennt vom Konversationslog: was geändert wurde, warum und basierend auf welchen Inputs.
Um Abstürze, Deploys und Ratenbegrenzungen zu überleben, sollten Workflows resumable sein:
Das ermöglicht auch Time‑Travel‑Debugging: Sie können genau den Zustand inspizieren und erneut abspielen, der zu einer falschen Entscheidung geführt hat.
Memory ist ebenso ein Risiko wie ein Vorteil. Für Produktionsagenten:
Behandeln Sie Memory als Produktfläche: entworfen, versioniert und reguliert — nicht als wachsendes Textdump, das an den Agenten angehängt wird.
Agenten wirken sequenziell auf dem Whiteboard, verhalten sich aber unter realer Last wie verteilte Systeme. Sobald viele gleichzeitige Nutzer, Tools und Hintergrundjobs vorhanden sind, jonglieren Sie mit Race‑Conditions, doppelter Arbeit und Reihenfolgeproblemen.
Gängige Fehlermodi:
Diese mitigiert man mit idempotenten Tool‑Verträgen, explizitem Workflow‑State und optimistischer/pessimistischer Sperrung auf Datenebene.
Synchroner Request–Response‑Flow ist einfach, aber fragil: jede Abhängigkeit muss erreichbar, innerhalb des Ratenlimits und schnell sein. Sobald Agenten viele Tools aufrufen oder parallelisieren, verlagern Sie lang laufende oder side‑effect‑reiche Schritte in eine Queue.
Queue‑basierte Orchestrierung ermöglicht:
Agenten treffen typischerweise drei Klassen von Limits:
Sie brauchen eine explizite Ratenlimit‑Schicht mit per‑User, per‑Tenant und globalen Throttles. Nutzen Sie Token‑Buckets oder Leaky‑Buckets zur Durchsetzung und geben Sie klare Fehlertypen zurück (z. B. RATE_LIMIT_SOFT, RATE_LIMIT_HARD), damit Agenten elegant zurückschalten.
Backpressure schützt das System unter Last. Strategien umfassen:
Überwachen Sie Sättigungssignale: Queue‑Tiefe, Worker‑Auslastung, Modell/Tool‑Fehlerraten und Latenz‑Perzentile. Steigende Queues zusammen mit wachsender Latenz oder 429/503‑Fehlern sind Frühwarnzeichen, dass Agenten ihre Umgebung überlasten.
Sie können einen Agenten nicht zuverlässig machen, wenn Sie nicht schnell zwei Fragen beantworten können: Was hat er getan? und Warum hat er das getan? Observability für agentische Systeme macht diese Antworten billig und präzise.
Gestalten Sie Observability so, dass eine einzelne Aufgabe einen Trace hat, der durchläuft:
Hängen Sie in diesem Trace strukturierte Logs für Schlüssentscheidungen (Routingwahl, Planrevision, Guardrail‑Trigger) und Metriken für Volumen und Gesundheit an.
Ein nützlicher Trace enthält typischerweise:
Loggen Sie Prompts, Tool‑Inputs und Outputs in strukturierter Form, aber leiten Sie sie zuerst durch eine Redaction‑Schicht:
Halten Sie rohe Inhalte hinter Feature‑Flags in niedrigeren Umgebungen; Produktion sollte standardmäßig redigierte Views haben.
Mindestens sollten Sie verfolgen:
Wenn Incidents auftreten, erlauben gute Traces und Metriken, von „der Agent ist flaky“ zu einer präzisen Aussage zu kommen wie: „P95‑Tasks schlagen in ToolSelection nach 2 Retries fehl wegen neuem Schema im billing_service“, wodurch die Diagnose von Stunden auf Minuten schrumpft.
Agenten zu testen bedeutet, sowohl die Tools zu prüfen, die sie aufrufen, als auch die Flows, die alles zusammenfügen. Behandeln Sie es wie verteilte Systeme‑Testing, nicht nur als Prompt‑Tuning.
Beginnen Sie mit Unit‑Tests an der Tool‑Schnittstelle:
Diese Tests hängen nie vom LLM ab. Sie rufen das Tool direkt mit synthetischen Inputs auf und asserten das exakte Output‑ oder Fehler‑Verhalten.
Integrationstests üben den Agentenworkflow end‑to‑end: LLM + Tools + Orchestrierung.
Modellieren Sie diese als szenariobasierte Tests:
Diese Tests prüfen Zustandsübergänge und Tool‑Aufrufe, nicht jedes Token des LLM. Überprüfen Sie: welche Tools aufgerufen wurden, mit welchen Argumenten, in welcher Reihenfolge und welchen Endzustand/das Ergebnis der Agent erreicht hat.
Um Tests wiederholbar zu halten, fixture‑n Sie sowohl LLM‑Antworten als auch Tool‑Outputs.
Ein typisches Muster:
with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
result = run_agent_scenario(input_case)
assert result.state == "COMPLETED"
(Der Codeblock bleibt unverändert.)
Jede Prompt‑ oder Schemaänderung sollte einen unverzichtbaren Regression‑Run auslösen:
Schema‑Evolution (Felder hinzufügen, Typen straffen) bekommt eigene Regression‑Cases, um Agenten oder Tools zu erwischen, die noch auf das alte Vertragsbild setzen.
Schicken Sie nie ein neues Modell, eine Policy oder Routing‑Strategie direkt in den Produktivtraffic.
Stattdessen:
Nur wenn offline Gates bestanden sind, sollte eine neue Variante in Produktion gehen — idealerweise hinter Feature‑Flags und mit schrittweiser Ausrollung.
Agenten‑Logs enthalten oft sensible Nutzerdaten. Testing muss das respektieren.
Kodifizieren Sie diese Regeln in Ihrer CI‑Pipeline, sodass kein Testartefakt ohne Anonymisierungschecks erzeugt oder gespeichert werden kann.
Agenten in Produktion zu betreiben ähnelt eher dem Betrieb eines verteilten Systems als dem Ausliefern eines statischen Modells. Sie brauchen Rollout‑Kontrollen, klare Zuverlässigkeitsziele und disziplinierte Change‑Management‑Prozesse.
Führen Sie neue Agenten oder Verhaltensweisen schrittweise ein:
Unterlegen Sie das mit Feature‑Flags und konfigurierbaren Policies: Routing‑Regeln, aktivierte Tools, Temperatur, Safety‑Einstellungen. Änderungen sollten per Konfiguration steuerbar und sofort umkehrbar sein.
Definieren Sie SLOs, die sowohl Systemgesundheit als auch Nutzerwert widerspiegeln:
Binden Sie diese an Alerts und behandeln Sie Incidents wie bei jedem Produktionsservice: klare Ownership, Runbooks zur Triage und Standard‑Mitigationsschritte (Rollback‑Flag, Traffic‑Drain, Safe‑Mode).
Nutzen Sie Logs, Traces und Gesprächstranskripte, um Prompts, Tools und Policies zu verfeinern. Behandeln Sie jede Änderung als versioniertes Artefakt mit Review, Freigabe und Rückrollmöglichkeit.
Vermeiden Sie stille Änderungen an Prompts oder Tools. Ohne Change‑Control können Sie Regressionen nicht auf spezifische Änderungen zurückführen; Incident‑Response wird so zu Ratespiel statt zu Ingenieursarbeit.
Ein produktionsreifes Agentensystem profitiert von klarer Trennung der Verantwortlichkeiten. Ziel: den Agenten in Entscheidungen smart, in Infrastruktur aber dumb zu halten.
1. Gateway / API‑Edge
Single Entry Point für Clients (Apps, Services, UIs). Verantwortlich für:
2. Orchestrator
Der Orchestrator ist der „Hirnstamm“, nicht das Gehirn. Er koordiniert:
Die LLM(s) stehen hinter dem Orchestrator, verwendet vom Planner und von spezifischen Tools, die Sprachverständnis benötigen.
3. Tooling‑ und Storage‑Layer
Geschäftslogik bleibt in bestehenden Microservices, Queues und Datensystemen. Tools sind dünne Wrapper um:
Der Orchestrator ruft Tools über strikte Verträge auf, während Storage‑Systeme die Quellen der Wahrheit bleiben.
Durchsetzen von Auth und Quotas am Gateway; Erzwingen von Safety, Datenzugriff und Policy im Orchestrator. Alle Aufrufe (LLM und Tools) emittieren strukturierte Telemetrie in eine Pipeline, die speist:
Eine einfache Architektur (Gateway → single Orchestrator → Tools) ist leichter zu betreiben; separate Planner, Policy Engines und Model Gateways erhöhen Flexibilität, auf Kosten von Koordination, Latenz und operativer Komplexität.
Sie haben nun die Kernbausteine für Agenten, die unter realer Last vorhersehbar arbeiten: explizite Zustandsautomaten, klare Tool‑Verträge, disziplinierte Retries und tiefe Observability. Der letzte Schritt ist, diese Ideen in eine wiederholbare Praxis für Ihr Team zu überführen.
Denken Sie an jeden Agenten als einen zustandsbehafteten Workflow:
Wenn diese Teile zusammenpassen, degradieren Systeme kontrolliert, anstatt unter Edge‑Cases zusammenzubrechen.
Bevor Sie einen Prototypen an reale Nutzer ausliefern, prüfen Sie:
Fehlt eines dieser Items, befinden Sie sich noch im Prototyp‑Modus.
Eine nachhaltige Struktur trennt meist:
So können Produktteams schnell iterieren, während Plattform‑Teams Zuverlässigkeit, Sicherheit und Kostenkontrolle durchsetzen.
Haben Sie die stabilen Grundlagen, können Sie erkunden:
Führen Sie Fortschritte inkrementell ein: neue Lernkomponenten hinter Feature‑Flags, mit Offline‑Evaluation und starken Guardrails.
Das übergreifende Motto bleibt: Für Ausfälle designen, Klarheit über Cleverness stellen und iterieren, wo Sie beobachten und sicher zurückrollen können. Unter diesen Zwängen hören agentische Systeme auf, beängstigende Prototypen zu sein, und werden Infrastruktur, auf die Ihre Organisation vertrauen kann.
Ein agentisches System ist eine Anwendung, in der ein LLM nicht nur eine einzelne Eingabe beantwortet, sondern entscheidet, was als Nächstes zu tun ist: welche Tools aufzurufen sind, welche Daten zu holen sind, welche Schritte in einem Workflow auszuführen sind und wann es fertig ist.
Im Gegensatz zu einer einfachen Chat-Kompletion kombiniert ein agentisches System:
In Produktion ist das LLM somit eine Entscheidungs‑Komponente innerhalb einer größeren, deterministischen Hülle — nicht das ganze System.
Demos laufen meist über einen einzigen Happy‑Path: ein Nutzer, ideale Tool‑Antworten, keine Timeouts, keine Schema‑Änderungen und kurze Konversationen. In der Produktion treten hingegen auf:
Ohne explizite Workflows, Verträge und Fehlerbehandlung entstehen Schleifen, Stillstände, unvollständige Arbeit und stille Fehler, die in Demo‑Umgebungen nicht sichtbar werden.
Lassen Sie das LLM innerhalb einer klaren Struktur arbeiten statt in einer frei fließenden Schleife:
Statt while not done: call LLM modellieren Sie den Agenten als Workflow mit benannten Zuständen und typisierten Ereignissen.
Typische Zustände könnten sein:
Entwerfen Sie Tools wie echte Produktions‑APIs, nicht als prosaische Beschreibungen in Prompts. Jedes Tool sollte haben:
Gehen Sie davon aus, dass jede externe Aufrufkette irgendwann ausfällt, und designen Sie entsprechend.
Wesentliche Muster:
Trennen Sie Kurzzeit‑State von Langzeit‑Memory und halten Sie das LLM stateless.
Vermeiden Sie, Logs oder vollständige Konversationen als „Memory“ zu verwenden; leiten Sie stattdessen kompakte, strukturierte Datensätze mit klaren Aufbewahrungs‑ und Datenschutzregeln ab.
Betrachten Sie Ihr Agentensystem unter Last als verteiltes System, auch wenn einzelne Flows sequenziell aussehen.
Um zuverlässig zu bleiben:
Sie müssen für jede Aufgabe beantworten können: „Was hat der Agent getan?“ und „Warum hat er das getan?“. Praktisch bedeutet das:
Behandeln Sie Agenten wie evolvierende Services und managen Sie sie mit der gleichen Disziplin wie andere Produktionssysteme.
Empfohlene Praktiken:
So können Sie Verhalten Schritt für Schritt erklären, testen und debuggen, anstatt undurchsichtigen "Agenten‑Gedanken" nachzujagen.
PLAN – die Anfrage interpretieren und in Schritte zerlegenCALL_TOOL – ein bestimmtes Tool oder ein Batch von Tools aufrufenVERIFY – Ausgaben gegen einfache Invarianten oder sekundäre Modellprüfungen prüfenRECOVER – Fehler durch Retries, Fallbacks oder Eskalation behandelnDONE / FAILED – terminale ErgebnisseEreignisse (z. B. ToolCallSucceeded, TimeoutExceeded) plus der aktuelle Zustand bestimmen den nächsten Zustand. Dadurch werden Retries, Timeouts und Fehlerbehandlung explizit statt im Prompt oder verstreutem Glue‑Code versteckt.
InvalidInput, NotFound, RateLimited, TransientFailureValidieren Sie Eingaben vor dem Aufruf und Ausgaben danach. Versionieren Sie Tool‑Verträge und pinnen Sie Agenten an Versionen, damit Schema‑Änderungen nicht stillschweigend Flows kaputtmachen.
request_id oder einen Business‑Key und liefern bei wiederholtem Aufruf dasselbe Ergebnis zurück.So bleibt die Zuverlässigkeit hoch, ohne Endlosschleifen, doppelte Seiteneffekte oder unkontrollierte Kosten zu erzeugen.
Beobachten Sie Queue‑Tiefen, Latenz‑Perzentile und 429/503‑Raten, um Überlast frühzeitig zu erkennen.
Mit diesen Instrumenten verschiebt sich die Fehlersuche von „der Agent ist unzuverlässig“ hin zu einer punktgenauen Diagnose des betroffenen Zustands, Tools und der auslösenden Änderung.
So können Sie Agenten kontinuierlich verbessern und gleichzeitig Ausfälle einhegen, diagnostizierbar und reversibel halten.