Zuverlässigkeit für das Agentenunternehmen

Autonome Agenten führen nichtdeterministische Ausführungsmuster ein, die sich grundlegend von der herkömmlichen Salesforce-Automatisierung unterscheiden. Während Salesforce Flow und Apex vorhersehbaren Pfaden folgen, die unter kontrollierten Bedingungen wiederholbare Ergebnisse liefern, führen Agenten Probleme dynamisch aus. Beispielsweise kann dieselbe Frage, die zweimal gestellt wird, unterschiedliche Ausführungspfade aufweisen, unterschiedliche Ressourcen verbrauchen und unterschiedliche Ergebnisse hervorrufen. Dieser Nicht-Determinismus stellt Zuverlässigkeitsherausforderungen, die von herkömmlichen Test- und Überwachungsansätzen nicht angegangen werden.

Die Fehlermodi für die Agentenzuverlässigkeit unterscheiden sich kategorial von Fehlern in Salesforce Flow oder Apex. Rückschlussservices für große Sprachmodelle stellen externe Abhängigkeiten dar, deren Verfügbarkeitsmerkmale von der Salesforce Platform getrennt sind. Agenten generieren Antworten, die gelegentlich trotz Aufforderungsanweisungen gegen die erwartete Struktur verstoßen. Die Agentenkontextvorbereitung verbraucht Obergrenzen unvorhersehbar. Der unbegrenzte Datenabruf wirkt sich stärker auf Agenten aus, da Agenten offenen Kontext anfordern können, während deterministische Abfragen explizite Scope-Steuerung aufweisen.

Für eine zuverlässige Agentenarchitektur ist eine mehrstufige Ausweichkette erforderlich, die sich stark verschlechtert – von komplexen Agenten über einfachere Agenten mit reduziertem Kontext bis hin zu deterministischen Regelmodulen und schließlich zur menschlichen Übergabe über Omnikanal. Plattformereignisse unterstützen Warteschlangen für dauerhafte Wiederholungen mit Prüfpunktmustern, sodass fehlgeschlagene Workflows nach dem letzten erfolgreichen Schritt fortgesetzt werden können. Leistungsschalter verfolgen den LLM-Servicestatus im Plattform-Cache für den Echtzeitstatus, unterstützt durch benutzerdefinierte Metadatentypen für Schwellenwerte und Konfiguration, und leiten ihn nach aufeinanderfolgenden Fehlern an Ausweichmuster weiter. Die Überwachung erfordert die Verfolgung der Unterhaltungserfolgsraten, der mittleren Zeit zwischen Fehlern (MTBF), der mittleren Zeit bis zur Wiederherstellung (MTTR) und der Erdungsgenauigkeit. Die Agentforce Observability bietet Sitzungsverfolgungen, Gesundheits- und Latenzkennzahlen sowie Eskalations- und Ableitungsraten. Sie müssen jedoch selbst Kennzahlen zur Zuverlässigkeit wie MTBF, MTTR und Erdungsgenauigkeit messen.

In diesem Dokument wird beschrieben, was sich ändert, wenn Agenten im Bild sind. Informationen zu grundlegenden Zuverlässigkeitsmustern, die für alle Salesforce-Lösungen gelten (Design des Service Level Object (SLO), Fehlertoleranz, Skalierung und Überwachung), finden Sie in der Säule Zuverlässigkeit.

Agentforce schlägt auf andere Weise fehl als Salesforce Flow oder Apex. Das Verständnis dieser Fehlermodi prägt die Zuverlässigkeitsarchitektur.

Nichtverfügbarkeit des LLM-Service: Bei LLM-Rückschlussendpunkten treten gelegentlich Latenzspitzen oder Verfügbarkeitsprobleme auf. Agentforce wird zusammen mit Analytics und anderen Salesforce-Services auf trust.salesforce.com als überwachtes Produkt aufgeführt. Granulare LLM-Rückschlusslatenz und Leistungskennzahlen pro Anforderung werden dort jedoch nicht angezeigt. Implementieren Sie Leistungsschalter, indem Sie den Plattform-Cache für Echtzeitstatus mit geringer Latenz verwenden, unterstützt durch benutzerdefinierte Metadatentypen für Schwellenwerte und Konfiguration, um den LLM-Servicezustand zu verfolgen. Der Plattform-Cache ist das Beste – Einträge können vor ihrer Lebenszeit (Time-to-Live, TTL) geräumt werden. Daher sollten Sie den Status “Offen/Ausgelöst” in einem dauerhaften Shop wie einem benutzerdefinierten Objekt beibehalten und nicht nur im Cache. Passen Sie die Fahrtbedingung auf den Endpunkt an: eine Anzahl aufeinanderfolgender Fehler (beispielsweise fünf) oder eine Fehlerrate, die einen Schwellenwert über einem rollierenden Fenster überschreitet. Wenn die Schaltung ausgelöst wird, öffnen Sie sie und leiten Sie sie zu Ausweichmustern weiter, beispielsweise einfacheren Aufforderungen, zwischengespeicherten Antworten oder einer menschlichen Übergabe, bis eine erfolgreiche Testanforderung die Wiederherstellung anzeigt.
Fehler bei der Antwortvalidierung: Agenten generieren gelegentlich Antworten, die trotz Aufforderungsanweisungen gegen die erwartete Struktur verstoßen. Ein Agent gibt manchmal eine falsch formatierte JSON zurück, lässt Pflichtfelder aus oder enthält unerwartete Datentypen. Im Plattform-Cache können validierte Antwortschemas gespeichert werden, was eine schnelle Validierung ermöglicht. Wenn die Validierung fehlschlägt, versuchen Sie es mit genaueren Aufforderungen, einschließlich des Validierungsfehlers und eines Beispiels für die richtige Struktur. Legen Sie eine maximale Anzahl an Wiederholungen (3–5) fest, um Endlos-Wiederholungsschleifen zu verhindern.
Halluzinationserkennung: Wenn die Kontextbildung unvollständig ist, erstellen Agenten plausible, aber falsche Informationen. Im Gegensatz zu deterministischen Abfragen, die “nicht gefunden” zurückgeben, füllen Agenten Lücken mit Rückschlüssen. Das Einstein Trust Layer Audit Trail protokolliert alle Aufforderungen, maskierten Aufforderungen, Reaktionen, Ergebnisse der Toxizitätserkennung und Benutzerfeedbacks für die Überprüfung der Verwaltung nach dem hoc-Vorgang. Es werden jedoch keine schrittweisen Argumentationsspuren erfasst. Verwenden Sie für die schrittweise Argumentationserfassung das Agentforce Session Tracing, das Ausführungen des Argumentationsmoduls aufzeichnet. Fordern Sie Agenten auf, Data 360-Abrufquellen (ehemals Data Cloud) für die Abruf-Augmented Generation (RAG) anzuführen. Querverweis-Agentenansprüche gegen abgerufene Quellen, um faktische Abweichungen vor der Ausführung der Aktion zu erkennen. Eine Inline-Überprüfung führt zu geringer Latenz, da sie für Quellen ausgeführt wird, die sich bereits im Kontext befinden. Eine Überprüfung, die eine separate Roundtrip-Erfahrung erfordert, beispielsweise einen zweiten Modellaufruf oder einen externen Service, kostet mehr. Reservieren Sie diese Überprüfungen für Schreibvorgänge mit hoher Auswirkung, einschließlich Finanz- oder Auftragsaktualisierungen, und führen Sie sie während der Echtzeitunterhaltung asynchron aus.
Obergrenzenspitzen für Gouverneure: Die Agentenkontextvorbereitung verbraucht SOQL-Abfragen (Salesforce Object Query Language), CPU-Zeit und Heap-Speicher unvorhersehbar basierend auf dem Unterhaltungs-Flow. Proactive Monitoring ist ein Signaturerfolgs-Anspruchsservice (ehemals Signaturunterstützung) im Salesforce Success-Plan, bei dem Salesforce Kundenaccounts proaktiv überwacht. Proactive Monitoring ist keine Self-Service-Benachrichtigung, die für alle Kunden konfigurierbar ist. Verwenden Sie das Skalierungscenter, um ressourcenintensive Agentenvorgänge zu identifizieren, die sich den Obergrenzen nähern, um die Überwachung der Obergrenzen für Self-Service-Obergrenzen zu ermöglichen. Implementieren Sie die Paginierung in Agentenaktionen, die große Datensatzsammlungen abrufen. Verwenden Sie Plattform-Cache für häufig aufgerufene Referenzdaten.
Datenverzerrung im Agentenkontext: Agenten, die Kontext für Accounts mit mehr als 10.000 Opportunities oder Kundenvorgänge mit vergleichbar großen Aktivitätsverläufen abrufen, stehen vor denselben Herausforderungen wie Batch Apex. Im Gegensatz zu deterministischen Abfragen, bei denen Sie den Umfang steuern, kann die Agentenüberlegungen “den gesamten Verlauf” unvorhersehbar anfordern. Um dies zu verhindern, entwerfen Sie Agentenaktionen mit sinnvollen harten Obergrenzen (z. B. eine Obergrenze von 200 untergeordneten Elementen pro übergeordnetem Element) und implementieren Sie Stichprobenstrategien, wenn Obergrenzen überschritten werden. Die Obergrenze begrenzt, wie viele Daten in den Kontext des Agenten gelangen. Kombinieren Sie sie mit selektiven indizierten Filtern, damit die Abfrage selbst billig bleibt, da ein nicht indizierter Filter oder ein Aggregat für ein verzerrtes übergeordnetes Element den vollständigen untergeordneten Satz scannt, bevor die Obergrenze angewendet wird.

Entwerfen Sie mehrstufige Ausweichketten, damit Agenten mit eingeschränkter Funktionalität weiterarbeiten können, statt komplett auszufallen.

Hauptagent mit vollständigem Kontext: Anspruchsvoller Agent mit vollständiger Data 360-Grundlage, umfangreichem Unterhaltungsverlauf und komplexer Argumentation. Höchste Qualität, aber ressourcenintensivstes und höchstes Ausfallrisiko.
Sekundärer Agent mit reduziertem Kontext: Einfacherer Agent mit komprimiertem Kontext (z. B. letzte 30 Tage im Vergleich zum gesamten Verlauf, Top-5-Vektorsuchergebnisse im Vergleich zu Top-20). Kleinerer Kontext bedeutet weniger Token, schnellere Rückschlüsse und eine geringere Wahrscheinlichkeit von Fehlern, aber nur, wenn der reduzierte Kontext noch die Daten abdeckt, die die Aufgabe benötigt.
Deterministisches Regelmodul: Traditionelle Salesforce Flow- oder Apex-Logik, die häufige Szenarien verarbeitet, wenn die Argumentation des Agenten fehlschlägt. Regeln können sich nicht an neue Situationen anpassen, verarbeiten jedoch bekannte Muster zuverlässig. Der Auftragsvalidierungsagent greift auf Standardvalidierungsregeln zurück, während der Leadbewertungsagent auf die regelbasierte Bewertungsberechnung zurückgreift.
Humane Übergabe über Omnikanal: Weiterleiten zur menschlichen Warteschlange, wenn die automatisierten Optionen erschöpft sind. Konfigurieren Sie die fertigkeitsbasierte Weiterleitung, um sicherzustellen, dass Eskalationen die entsprechende Expertise erreichen. Übergeben Sie den vollständigen Unterhaltungskontext (einschließlich versuchter Strategien, etwaiger Konfidenzbewertungen, die Sie für den Agenten berechnen, und Fehlerursachen), um ein effizientes Eingreifen zu ermöglichen.

Implementieren Sie Ausweichlogik in Salesforce Flow oder Apex, die durch Plattformereignisse ausgelöst werden. Jede Ebene protokolliert, welche Strategie erfolgreich war, wodurch Einblick in Fehlermuster und Effektivität der Ausweichlösung geschaffen wird.

Alle Plattformereignismuster in diesem Abschnitt gehen von Plattformereignistypen mit hohem Volumen aus, die das 72-Stunden-Aufbewahrungsfenster für die erneute Wiedergabe bereitstellen. Plattformereignisse mit Standardvolumen werden nur 24 Stunden lang gespeichert. Verwenden Sie Ereignistypen mit hohem Volumen für alle Agentenresilienz-, Wiederholungswarteschlangen- und Prüfpunktmuster, bei denen die Haltbarkeit der erneuten Wiedergabe eine Anforderung an die Zuverlässigkeit ist. Plattformereignisse bieten dauerhafte Nachrichten, mit denen Agenten-Workflows Fehler überstehen und automatisch wiederhergestellt werden können.

Prüfpunktagentfortschritt: Agenten-Workflows mit mehreren Schritten veröffentlichen Prüfpunktereignisse nach jedem erfolgreichen Schritt. Der Vertragsverarbeitungsagent schließt die Dokumentextraktion ab, veröffentlicht das Ereignis “ContractParsed” mit extrahierten Daten und fährt dann mit der Klauselanalyse fort. Wenn die Klauselanalyse fehlschlägt, geben Sie das Ereignis “ContractParsed” erneut wieder, um es aus den extrahierten Daten ohne erneute Analyse fortzusetzen. Dies funktioniert, wenn die Prüfpunktnutzlast diese Daten überträgt und der Abonnent idempotent ist, da die erneute Wiedergabe Ereignisse erneut zustellt, statt einen Workflow in der Mitte des Schritts fortzusetzen. Speichern Sie den Prüfpunktstatus in der Ereignisnutzlast, einschließlich der Korrelations-ID, der abgeschlossenen Schritte und des für die Fortsetzung erforderlichen Status.
Warteschlange für Wiederholungen mit exponentieller Absicherung: Fehlerhafte Agentenanforderungen werden im Ereignis “AgentRetryRequested” mit der Anzahl der Wiederholungen in der Nutzlast veröffentlicht. Ereignisabonnent verarbeitet Wiederholungen mit exponentiellen Backoff-Verzögerungen (z. B. 30 Sekunden, 2 Minuten, 8 Minuten, 30 Minuten). Leiten Sie nach maximalen Wiederholungen (in der Regel 5) den Vorgang zur Warteschlange mit toten Briefen und Warnungen weiter. Bei Plattformereignissen mit hohem Volumen wird ein 72-Stunden-Wiedergabefenster beibehalten. Verwenden Sie den Ereignistyp mit hohem Volumen für Warteschlangen für Agentenwiederholungen, damit Abonnenten nach Wartungszeitfenstern oder Ausfallzeiten der Bereitstellung auf dem Laufenden bleiben können. Plattformereignisse mit Standardvolumen werden nur 24 Stunden lang gespeichert.
Ereignisgesteuerte Orchestrierung: Entwerfen Sie Agenten-Workflows als lose gekoppelte Ereignisketten. Bei der Leaderstellung wird LeadCreated veröffentlicht. Leadbewertungsagent abonniert, bewertet und veröffentlicht Leadbewertungen. Leadweiterleitungsagent abonniert LeadScored und weist die entsprechende Warteschlange zu. Jeder Agent kann fehlschlagen und es unabhängig wiederholen. Ein einzelner Agentenfehler blockiert nicht den gesamten Workflow – nachgelagerte Agentenprozesse, wenn Abhängigkeiten wiederhergestellt werden.
Korrelations-ID-Verfolgung: Fügen Sie eine Korrelations-ID als benutzerdefiniertes Feld in alle zugehörigen Ereignisnutzlasten ein. Erneutes Abspielen von Ereignissen mithilfe der Pub/Sub-API by replayId, einer opaken, nicht zusammenhängenden Kennung, um den Workflow-Verlauf innerhalb des 72-Stunden-Aufbewahrungsfensters zu rekonstruieren. Implementieren Sie zum Aktivieren des korrelations-ID-basierten Debuggings ein abonnentenseitiges Muster, das eingehende Ereignisse mit ihrer replayId und ihrer Korrelations-ID in einem benutzerdefinierten Objekt protokolliert und so die ereignisübergreifende Rückverfolgbarkeit ermöglicht. Dieses Protokollierungsmuster ist eine benutzerdefinierte Implementierung, die Sie selbst erstellen, und keine native Plattformabfragefunktion.

Verschieben Sie Agentenvorgänge, die synchrone Obergrenzen überschreiten, in einen asynchronen Kontext, was höhere Obergrenzen und längere Zeitüberschreitungen ermöglicht.

Batch-Apex für Massenvorgangsagenten: Ein Agent, der mehr als 1.000 Datensätze analysiert, profitiert von Batch Apex mit 200 SOQL-Abfragen, 150 DML-Anweisungen (bis zu 10.000 DML-Zeilen) und 60.000 Millisekunden (60 Sekunden) CPU-Zeit pro Ausführungsmethode. Leadbewertungsagent verarbeitet nächtliche Leadimporte. Analyse der Kundenvorgangsstimmung in historischen Kundenvorgängen. Opportunity-Prognosen zur Analyse vollständiger Pipelines.
Warteschlangenketten für mehrstufige Workflows: Komplexe Agenten-Workflows, die mehrere externe API-Aufrufe, große Datenset-Analysen oder eine längere Verarbeitungszeit erfordern, verwenden warteschlangenfähige Apex-Ketten. Jeder warteschlangenfähige Auftrag erhält 60 CPU-Zeit und 12 MB Heap. Kette bis nächste Warteschlange für Workflows, die die Obergrenzen für Einzelaufträge überschreiten. Verfolgen Sie den Fortschritt in “Benutzerdefinierte Objekte”, damit ein fehlgeschlagener Auftrag ab dem letzten abgeschlossenen Schritt fortgesetzt werden kann.
@future für einfache asynchrone Übergaben: Leichtgewichtige Agentenvorgänge wie das Senden von Benachrichtigungen, das Protokollieren an externe Systeme oder nicht dringende Aktualisierungen verwenden die Methoden @future. Das Muster zum Auslösen und Vergessen passt, wenn ein Workflow keine Ergebnisse zurückverlangen muss und Fehler tolerieren kann.

Überwachen Sie die asynchrone Verarbeitungskapazität über die Seite “Apex Aufträge” (Setup → Apex Aufträge) und die flexible Apex Warteschlange. Maximal 5 gleichzeitige Batchaufträge schränken die parallele Agentenverarbeitung ein. Zusätzliche Aufträge werden in der flexiblen Apex-Warteschlange mit bis zu 100 Aufträgen im Status “Halten” in die Warteschlange gestellt. Alle asynchronen Apex-Typen, Batch, Future, Queueable und Scheduled Apex, haben dieselbe organisationsweite tägliche Obergrenze (DailyAsyncApexExecutions) für asynchrone Apex Ausführungen: je größer die 250.000- oder 200-fache Anzahl an Benutzerlizenzen ist. Wenn Sie Hochfrequenz-Agentenabfragen ausführen oder Abonnentenwarteschlangen wiederholen, kann es sein, dass Queueables diese Quote schnell ausschöpft. Um dies zu vermeiden, sollten Sie diese Warteschlangen in Batches unterteilen oder drosseln, um innerhalb der Obergrenze zu bleiben. Diese gilt organisationsweit für alle asynchronen Apex-Typen und nicht als separate Zuteilung für Warteschlangen allein. Benachrichtigen, wenn sich der Verbrauch diesen Obergrenzen nähert, damit Teams die Kapazität proaktiv verwalten können.

Validieren Sie die Agentenresilienz vor der Produktion durch Teststrategien, die nicht deterministisches Verhalten berücksichtigen.

Lasttests in der Full Copy Sandbox: Testen Sie die Agentenleistung unter Last im Produktionsmaßstab mithilfe vollständiger Datenvolumen. Simulieren Sie gleichzeitige Unterhaltungen entsprechend der Spitzennachfrage. Messen Sie die Latenz von p95 und p99 und identifizieren Sie Leistungseinbußen unter Stress. Validieren Sie, dass der Verbrauch der Reglerobergrenze bei Spitzenlast unter den Schwellenwerten bleibt. Das Laden von Tests in einer Teilkopie-Sandbox mit reduzierten Daten bietet irreführende Sicherheit, da sich das Datenvolumen direkt auf die Agentenleistung auswirkt. Lassen Sie sich vor dem Ausführen dieser Tests von Salesforce genehmigen (mindestens eine Woche im Voraus für Leistungstestanforderungen). Nicht genehmigte Tests können gedrosselt oder blockiert werden.
Fehlerinjektion: Führen Sie bewusst Fehler beim Validieren von Wiederherstellungsmechanismen ein. Simulieren Sie LLM-Rückschlussfehler in der Serviceebene, die Ihr Leistungsschalter überwacht, um zu überprüfen, ob der Schalter aktiviert ist. Fügen Sie SOQL-Ausnahmen zum Testen der Fehlerverarbeitung hinzu. Beschädigte Agentenantworten auf Testvalidierungslogik. Führen Sie eine Datenverzerrung (Accounts mit mehr als 10.000 untergeordneten Elementen) ein, um die Paginierungslogik zu testen. Legen Sie aggressive Zeitüberschreitungen fest, um die Verarbeitung von Zeitüberschreitungen und Wiederholungsstrategien zu testen.
Chaos Engineering: Deaktivieren Sie nach dem Zufallsprinzip Plattformereignis-Abonnenten, um die Wiederherstellung der erneuten Wiedergabe zu testen. Beenden Sie asynchrone Aufträge während der Ausführung, um den Neustart des Prüfpunkts zu testen. Führen Sie die variable Latenz in externe Systeme ein, um progressive Zeitüberschreitungsstrategien zu testen. Chaosexperimente validieren die Widerstandsfähigkeit in realistischen Fehlerkombinationen. Planen Sie regelmäßige Chaostage in Staging-Umgebungen, um die Widerstandsfähigkeit bei der Entwicklung der Agenten zu erhalten.
Langfristige Stabilitätstests: Führen Sie Agentenarbeitslasten 72+ Stunden lang kontinuierlich aus und überwachen Sie sie auf zeitabhängige Fehler. Anhäufen von Fehlern und allmähliche Verschlechterung der Leistungsoberfläche nur im Dauerbetrieb. Verfolgen Sie CPU-Zeittrends, um eine allmähliche Verschlechterung während der Ausführung zu erkennen.

Definieren Sie Service Level Indicators (SLIs), um die objektive Zuverlässigkeitsmessung zu ermöglichen. Richten Sie SLOs ein, bevor Sie Agenten erstellen, nicht nach Produktionsfehlern.

Unterhaltungserfolgsrate: Prozentsatz der Agentenunterhaltungen, die ohne Fehler oder Zeitüberschreitungen abgeschlossen wurden. Zählen Sie eine anmutige Übergabe an einen Menschen als Erfolg, nicht als Misserfolg – Eskalation ist die letzte Ausweichstufe. Zählen Sie fehlgeschlagene oder unbeabsichtigte Eskalationen anhand der Kennzahl. Dies ist ein nützliches Zuverlässigkeitssignal, aber ein unvollkommener Proxy für die Benutzererfahrung, da eine höfliche Abmeldung ein ungelöstes Problem maskieren kann. Verfolgen Sie separat nach Agententyp und Anwendungsfall, da sich die Erfolgskriterien für die Leadbewertung von der Vertragsüberprüfung unterscheiden. Warnung, wenn die Erfolgsrate unter SLO fällt (in der Regel 95–99 %).
Mittlere Zeit zwischen Fehlern (MTBF): Durchschnittliche Betriebszeit zwischen Agentenfehlern. Höhere MTBF bedeutet weniger Ausfälle und höhere Zuverlässigkeit. Berechnen Sie die Gesamtbetriebszeit des Agenten geteilt durch die Anzahl der Fehler. Verfolgen Sie die Verfolgung pro Agententyp, um die am wenigsten zuverlässigen Agenten zu identifizieren, die Optimierungsinvestitionen erfordern.
Mittlere Zeit bis zur Wiederherstellung (MTTR): Durchschnittliche Zeit von der Fehlererkennung bis zur Servicewiederherstellung. Die automatische Wiederherstellung über die Plattformereigniswiedergabe und Leistungsschalter stellt den Service viel schneller und mit weniger manuellen Fehlern als bei praktischen Eingriffen wieder her. Die niedrigere MTTR reduziert die Auswirkungen pro Vorfall auf das Geschäft.
Genauigkeit der Erdung: Prozentsatz der faktisch richtigen Agentenantworten basierend auf der Quelldatenvalidierung. Beispiel für zufällige Agentenantworten zum Validieren von Ansprüchen für Data 360-Quellen. Die Genauigkeit der Kontextbildung unter 95 % deutet auf Halluzinationsprobleme hin, die eine sofortige Verfeinerung oder einen besseren Kontextabruf erfordern.
Wiedergabelücken bei Plattformereignissen: Anzahl der verpassten oder nicht zugestellten Ereignisse, beispielsweise eines Abonnenten offline nach dem Aufbewahrungsfenster. Zero gaps ist ein positives Signal für eine gesunde ereignisgesteuerte Architektur. Lücken geben Abonnentenprobleme, Fehler bei der Ereignisveröffentlichung oder Kapazitätsbeschränkungen an. Verfolgen Sie diese Lücken mit dem oben beschriebenen abonnentenseitigen Protokollierungsmuster und zeichnen Sie die replayId und die Korrelations-ID jedes Ereignisses in einem benutzerdefinierten Objekt auf.

Zuverlässige Agenten können auf Fehler im Voraus ausgelegt werden – sie definieren SLIs/SLOs, kontextbezogene Handhabungen, bei denen die Obergrenze berücksichtigt wird, und mehrstufige Ausweichketten, bevor sie erstellt werden, statt sie danach zu aktivieren. Layer-Leistungsschalter und Plattformereignis-basierte Wiederholungs- und Prüfpunktlogik, damit Workflows automatisch wiederhergestellt werden, wobei die menschliche Übergabe das letzte Mittel ist. Validieren Sie dieses Design durch systematische Last-, Fehlerinjektions- und Chaostests und überwachen Sie dann weiterhin dieselben SLIs in der Produktion, um sicherzustellen, dass es im Laufe der Zeit Bestand hat.

Die Zuverlässigkeitsempfehlung in der Hauptsäule “Zuverlässigkeit” gilt für Agenten mit plattformspezifischen Überlegungen, die hier behandelt werden. Erfolgreiche Agentenarchitekturen balancieren autonome Funktionen mit angemessener Übersicht, wodurch die Selbstwiederherstellung nach vorübergehenden Fehlern ermöglicht wird und gleichzeitig die Eskalation erfolgt, wenn die Konfidenz sinkt oder Kundenvorgänge auftreten.

Teilen Sie uns Ihr Feedback zum Well-Architected Framework mit.