Agentische Zuverlässigkeitsmuster
Weitere Informationen zu Well-Architected Reliability → Agentic Enterprise Reliability (Wohlüberlegte Zuverlässigkeit)
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Plattform-Cache | ✅ Implementieren Sie Leistungsschalter, die den LLM-Serviceintegritätsstatus im Plattform-Cache für Echtzeitlesungen mit geringer Latenz verfolgen, unterstützt durch benutzerdefinierte Metadatentypen für Schwellenwerte und Konfiguration. Da der Plattform-Cache die beste Leistung bietet, sollten Sie den offenen/ausgelösten Status in einem dauerhaften Speicher (z. B. einem benutzerdefinierten Objekt) beibehalten und nicht nur im Cache. Öffnen des Schaltkreises für einen abgestimmten Fehlerschwellenwert (beispielsweise fünf aufeinanderfolgende Rückschlussfehler) und Weiterleiten zu Ausweichmustern |
| Plattform | Plattform-Cache | ✅ Speichern validierter Antwortschemas im Plattform-Cache für eine schnelle Validierung von Agentenantworten anhand der erwarteten Struktur |
| Agentforce | Aufforderungsvorlage | ✅ Wenn die Antwortvalidierung fehlschlägt, versuchen Sie es mit verfeinerten Eingabeaufforderungen, einschließlich des Validierungsfehlers und eines Beispiels der richtigen Struktur (maximal 3-5 Wiederholungen) |
| Agentforce | Sitzungsverfolgung | ✅ Verwenden von Agentforce Session Tracing-Erklärungsverfolgungen, um den Pfad der Agentenerläuterung zu überprüfen und Halluzinationen in ihren Ausgaben zu erkennen |
| Data 360 | Vektorsuche | ✅ Agenten auffordern, Data 360-Vektorsuchquellen zu zitieren, damit Ansprüche vor der Ausführung der Aktion auf abgerufene Quellen verwiesen werden können |
| Plattform | Proactive Monitoring | ✅ Bei Accounts mit dem Anspruch “Signature Success” (Signaturerfolg) sollten Sie sich auf Proactive Monitoring verlassen, bei dem Salesforce-Mitarbeiter die Organisation auf neu auftretende Probleme überwachen. Es handelt sich nicht um eine Self-Service-konfigurierbare Benachrichtigung. |
| Plattform | Skalierungscenter | ✅ Verwenden Sie das Skalierungscenter, um bestimmte Agentenvorgänge zu identifizieren, die sich den Obergrenzen nähern |
| Agentforce | Aktion | ✅ Implementieren der Paginierung in Agentenaktionen zum Abrufen großer Datensatzsammlungen |
| Agentforce | Aktion | ✅ Entwerfen von Agentenaktionen mit harten Obergrenzen (maximal 200 untergeordnete Elemente pro übergeordnetem Element) und Implementieren von Stichprobenstrategien bei Überschreitung der Obergrenzen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Benutzerdefinierte Metadatentypen | ⚠️ Zulassen unbegrenzter Wiederholungen von Rückschlüssen ohne Leistungsschalter, Erstellen unbegrenzter Wiederholungsschleifen, wenn der LLM-Service beeinträchtigt wird |
| Agentforce | Aufforderungsvorlage | ⚠️ Wiederholen fehlgeschlagener Agentenantworten ohne Einbeziehung des Validierungsfehlers und der erwarteten Struktur in die Aufforderung zur Wiederholung |
| Agentforce | Aktion | ⚠️ Ermöglichen, dass Agenten unbegrenzten Kontext (z. B. “gesamter Verlauf”) anfordern können, ohne dass strenge Obergrenzen für untergeordnete Elemente pro übergeordnetem Datensatz gelten |
| Agentforce | Aktion | ⚠️ Entwerfen von Agentenaktionen, die große Datensatzsammlungen ohne Paginierung abrufen und zu Spitzen bei Obergrenzen führen |
| Einstein | Trust Layer | ⚠️ Antworten von vertrauenswürdigen Agenten ohne Querverweise auf Ansprüche in Bezug auf Datenquellen mit Kontextbildung, sodass Halluzinationen die Ausführung von Aktionen erreichen |
| Plattform | Organisation | ⚠️ Behandeln der LLM-Serviceverfügbarkeit als identisch mit der Salesforce Platform-Verfügbarkeit, statt sie als separate Abhängigkeit zu überwachen |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Agentforce | Agentenkonfiguration | ✅ Design mehrstufige Ausweichketten: Vollkontextagent → Agent mit reduziertem Kontext → deterministisches Regelmodul → menschliche Übergabe über Omnikanal |
| Agentforce | Agentenkonfiguration | ✅ Konfigurieren eines sekundären Agenten mit komprimiertem Kontext (letzte 30 Tage im Vergleich zum gesamten Verlauf, die besten 5 Vektorsuchergebnisse im Vergleich zu den besten 20), um die Fehlerwahrscheinlichkeit zu reduzieren |
| Plattform | Flow | ✅ Implementieren von Ausweichlogik in Orchestrierungs-Flows oder Apex, die durch Plattformereignisse ausgelöst werden, und Protokollieren der erfolgreichen Klasse für die Sichtbarkeit von Fehlermustern |
| Plattform | Flow | ✅ Erstellen einer deterministischen Flow- oder Apex-Logik, die häufige Szenarien als Ausweichlösung verarbeitet, wenn die Agentenüberlegungen fehlschlagen (z. B. Standardvalidierungsregeln, regelbasierte Bewertungsberechnung) |
| Agentforce | Omnikanal | ✅ Konfigurieren der fertigkeitsbasierten Weiterleitung für die menschliche Übergabe, um sicherzustellen, dass Eskalationen die entsprechende Expertise erreichen |
| Agentforce | Omnikanal | ✅ Übergeben des vollständigen Unterhaltungskontexts an die menschliche Warteschlange, einschließlich versuchter Strategien, Agentenkonfidenzbewertungen und Fehlerursachen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Agentforce | Agentenkonfiguration | ⚠️ Entwerfen von Agenten mit einem einzelnen Ausführungspfad, der vollständig fehlschlägt, wenn eine Komponente beeinträchtigt wird |
| Agentforce | Agentenkonfiguration | ⚠️ Verwenden derselben Vollkontextagentenkonfiguration für Ausweichversuche statt schrittweisen Vereinfachen des Kontexts |
| Agentforce | Omnikanal | ⚠️ Weiterleitung an eine menschliche Übergabe ohne Weitergabe von Unterhaltungskontext, versuchten Strategien oder Fehlerursachen, wodurch der Agent gezwungen wird, von Grund auf neu zu beginnen |
| Plattform | Flow | ⚠️ Nicht protokolliert, welche Ausweichstufe erfolgreich war, wodurch der Einblick in Fehlermuster und die Effektivität des Ausweichvorgangs verloren geht |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Plattformereignisse | ✅ Veröffentlichen von Prüfpunktereignissen nach jedem erfolgreichen Schritt in mehrstufigen Agenten-Workflows, Speichern der Korrelations-ID, der abgeschlossenen Schritte und des für die Fortsetzung erforderlichen Status in der Ereignisnutzlast |
| Plattform | Plattformereignisse | ✅ Entwerfen von Agenten-Workflows als lose gekoppelte Ereignisketten, bei denen jeder Agent fehlschlagen und es unabhängig wiederholen kann, ohne den gesamten Workflow zu blockieren |
| Plattform | Plattformereignisse | ✅ Implementieren von Wiederholungswarteschlangen mit exponentiellen Backoff-Verzögerungen (30 Sekunden, 2 Minuten, 8 Minuten, 30 Minuten) mithilfe von Plattformereignissen mit Wiederholungsanzahl in der Nutzlast |
| Plattform | Plattformereignisse | ✅ Weiterleiten an Warteschlange mit toten Briefen und Warnungen nach maximalen Wiederholungen (in der Regel 5) |
| Plattform | Plattformereignisse | ✅ Korrelations-ID in alle zugehörigen Ereignisse einschließen; Verwenden der API für die Plattformereigniswiedergabe zum Rekonstruieren des vollständigen Workflow-Verlaufs für das Debuggen |
| Plattform | Plattformereignisse | ✅ Nutzen Sie das 72-Stunden-Aufbewahrungsfenster für Plattformereignisse mit hohem Volumen (Ereignisse mit Standardvolumen werden 24 Stunden lang beibehalten), um Warteschlangen für Wiederholungen durch Organisationswartungszeitfenster oder Bereitstellungsausfallzeiten beizubehalten |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Plattformereignisse | ⚠️ Erstellen von Agenten-Workflows mit mehreren Schritten ohne Prüfpunkt, die eine vollständige erneute Ausführung erfordern, wenn ein Zwischenschritt fehlschlägt |
| Plattform | Plattformereignisse | ⚠️ Wiederholen fehlgeschlagener Agentenanforderungen ohne exponentielles Backoff, was zu donnernden Herdeneffekten bei der Wiederherstellung von Services führt |
| Plattform | Plattformereignisse | ⚠️ Entwerfen eng gekoppelter sequenzieller Workflows, bei denen ein einzelner Agent die gesamte nachgelagerte Verarbeitung blockiert |
| Plattform | Plattformereignisse | ⚠️ Auslassen von Korrelations-IDs aus Ereignissen, wodurch die vollständige Workflow-Ausführung nicht verfolgt und debuggt werden kann |
| Plattform | Plattformereignisse | ⚠️ Unbegrenzte Wiederholung ohne maximale Anzahl von Wiederholungen oder Warteschlange mit totem Brief, Nutzung von Plattformressourcen bei dauerhaft fehlgeschlagenen Vorgängen |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Apex | ✅ Verwenden Sie Batch Apex für Agentenvorgänge, die mehr als 1.000 Datensätze analysieren, und nutzen Sie dabei asynchrone Obergrenzen (200 SOQL-Abfragen, 150 DML-Vorgänge, 60s CPU pro Ausführung). |
| Plattform | Apex | ✅ Verwenden von warteschlangenfähigen Apex-Ketten für Agenten-Workflows mit mehreren Schritten, die mehrere externe API-Aufrufe oder eine längere Verarbeitungszeit erfordern; Verfolgen des Fortschritts in benutzerdefinierten Objekten zum Aktivieren der Fortsetzung bei Fehlern |
| Plattform | Apex | ✅ Verwenden Sie @future-Methoden für einfache Vorgänge von Agenten, bei denen Fehler tolerierbar sind (Benachrichtigungen, externe Protokollierung, nicht dringende Aktualisierungen). |
| Plattform | Apex Jobs | ✅ Überwachen der asynchronen Verarbeitungskapazität über die Seite “Apex Aufträge” (Setup → Apex Aufträge) und die flexible Apex Warteschlange: maximale Anzahl von 5 gleichzeitigen Batchaufträgen (zusätzliche Aufträge in der Warteschlange “Flexibel”, bis zu 100 im Status “Halten”) und die organisationsweite tägliche Obergrenze für asynchrone Apex-Ausführungen (DailyAsyncApexExecutions) – die 250.000- oder 200-fache Anzahl an Benutzerlizenzen pro 24 Stunden –, die in Batch, Queueable, Future und Scheduled Apex freigegeben werden |
| Plattform | Organisation | ✅ Benachrichtigung, wenn sich die Obergrenzen für den asynchronen Verbrauch nähern und eine proaktive Kapazitätsverwaltung ermöglicht wird, bevor die Agentenverarbeitung blockiert wird |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Apex | ⚠️ Verarbeiten von mehr als 1.000 Datensätzen in synchronen Agententransaktionen anstelle von Batch Apex, wobei die Obergrenze von 100 SOQL-Abfragen bereits nach wenigen Datensätzen erreicht wird |
| Plattform | Apex | ⚠️ Verwenden von Queueable-Ketten ohne Verfolgung des Fortschritts in benutzerdefinierten Objekten, wodurch verhindert wird, dass die Funktion “Fortsetzung bei Fehler” fortgesetzt wird |
| Plattform | Organisation | ⚠️ Keine Überwachung der Obergrenze von 5 gleichzeitigen Batchaufträgen oder der Obergrenze für die gemeinsame tägliche asynchrone Apex-Ausführung (DailyAsyncApexExecutions – die größere der 250.000 oder 200 × Benutzerlizenzen pro 24 Stunden in Batch, Queueable, Future und Scheduled Apex), was dazu führt, dass die Agentenverarbeitung stillschweigend in die Warteschlange gestellt wird oder fehlschlägt |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Organisation | ✅ Laden Sie die Leistung von Testagenten in der Full Copy Sandbox mit Datenvolumen im Produktionsmaßstab; simulieren Sie gleichzeitige Unterhaltungen entsprechend der Spitzenanforderung |
| Plattform | Organisation | ✅ Messen Sie die Latenz von p95 und p99 unter Last, um die Leistungsverschlechterung unter Stress zu identifizieren. Validieren Sie, dass der Verbrauch der Reglerobergrenze unter den Schwellenwerten bei Spitzenlast bleibt |
| Agentforce | Agentenkonfiguration | ✅ Fehlerinjektion durchführen: Simulieren von LLM-Rückschlussfehlern in der Serviceebene, die Ihr Leistungsschalter überwacht, Einschleusen von SOQL-Ausnahmen beim Testen von Fehlern, Beschädigen von Antworten beim Testen von Validierungslogik |
| Agentforce | Agentenkonfiguration | ✅ Einführung einer Datenverzerrung (Accounts mit mehr als 10.000 untergeordneten Elementen) während des Tests zur Validierung der Paginierungslogik bei der Verarbeitung von Worst-Case-Szenarien |
| Plattform | Plattformereignisse | ✅ Chaos Engineering durchführen: Zufallsprinzip zum Deaktivieren von Plattformereignis-Abonnenten, die die Wiederherstellung der erneuten Wiedergabe testen, Beenden asynchroner Aufträge während der Ausführung Testpunkt Neustart |
| Plattform | Organisation | ✅ Planen regelmäßiger Chaostage in Staging-Umgebungen, um die Resilienz bei der Weiterentwicklung von Agenten aufrechtzuerhalten |
| Plattform | Organisation | ✅ Führen Sie langfristige Stabilitätstests (72+ Stunden) für zeitabhängige Fehler aus: Anhäufen von Fehlern und allmähliche Verschlechterung der Leistung |
| Plattform | Organisation | ✅ Verfolgen von CPU-Zeittrends und Heap-Verbrauch über längere Zeiträume und Erkennen einer allmählichen Verschlechterung der Kontextverwaltung |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Lasttests in der Teilkopie-Sandbox mit reduziertem Datenvolumen bieten irreführende Sicherheit, da sich das Datenvolumen direkt auf die Agentenleistung auswirkt |
| Agentforce | Agentenkonfiguration | ⚠️ Testen Sie nur glückliche Pfade, ohne bewusst Fehler bei der Validierung von Leistungsschaltern, Wiederholungslogik und Zeitüberschreitungsverarbeitung einzuführen |
| Plattform | Organisation | ⚠️ Nur Kurzzeittests ausführen, fehlende zeitabhängige Fehler (akkumulierte Fehler, allmähliche Verschlechterung), die nur bei anhaltendem Betrieb von mehr als 72 Stunden auftreten |
| Plattform | Plattformereignisse | ⚠️ Testen Sie niemals die Wiederherstellung oder den Neustart von Prüfpunkten für Plattformereignisse, sodass Resilienzmechanismen unvalidiert bleiben |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Unternehmen | Dokumentation | ✅ Einrichten von SLOs vor dem Erstellen von Agenten, nicht nach Produktionsfehlern; Definieren von Zielen für die Unterhaltungserfolgsrate (in der Regel 95-99 %) pro Agententyp |
| Plattform | Organisation | ✅ Verfolgen Sie die Unterhaltungserfolgsrate als Kennzahl für die primäre Agentenzuverlässigkeit: Prozentsatz der Unterhaltungen, die ohne Fehler oder Zeitüberschreitungen abgeschlossen werden. Zählen Sie eine anmutige Übergabe an einen Menschen als Erfolg, da die Eskalation die geplante letzte Ausweichstufe ist. Zählen Sie nur fehlgeschlagene oder unbeabsichtigte Eskalationen auf die Kennzahl an. |
| Plattform | Organisation | ✅ Verfolgen Sie die Erfolgsrate getrennt nach Agententyp und Anwendungsfall, da sich die Erfolgskriterien zwischen Agentenzwecken unterscheiden |
| Plattform | Organisation | ✅ Berechnen der mittleren Zeit zwischen Ausfällen (MTBF) pro Agententyp, um die am wenigsten zuverlässigen Agenten zu identifizieren, die Optimierungsinvestitionen erfordern |
| Plattform | Organisation | ✅ Mean Time to Recovery (MTTR) messen; Automatisieren der Wiederherstellung über Plattformereigniswiedergabe und Leistungsschalter für eine viel schnellere, weniger fehleranfällige Wiederherstellung als manuelle Intervention |
| Einstein | Trust Layer | ✅ Beispiel für zufällige Agentenantworten zur Validierung von Ansprüchen in Bezug auf Data 360-Quellen zur Messung der Grounding-Genauigkeit; Untersuchen, wann die Genauigkeit unter 95 % fällt |
| Plattform | Plattformereignisse | ✅ Überwachen von Plattformereignis-Wiedergabelücken (übersehene oder nicht zugestellte Ereignisse) über ein abonnentenseitiges Protokollierungsmuster, das die ReplayId und die Korrelations-ID jedes Ereignisses in einem benutzerdefinierten Objekt aufzeichnet |
| Plattform | Organisation | ✅ Benachrichtigen von Vorgängen, wenn ein SLI unter den definierten SLO-Schwellenwert fällt |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Unternehmen | Dokumentation | ⚠️ Erstellen von Agenten, ohne zuerst SLOs zu definieren, und Einrichten von Zuverlässigkeitszielen erst nach Produktionsausfällen |
| Plattform | Organisation | ⚠️ Verwenden einer einzelnen aggregierten Erfolgsrate über alle Agententypen hinweg statt einer separaten Verfolgung nach Agententyp und Anwendungsfall |
| Plattform | Organisation | ⚠️ Verlassen Sie sich ausschließlich auf die traditionelle Salesforce-Überwachung (Trust.salesforce.com), ohne agentenspezifische SLIs wie Unterhaltungserfolgsrate, MTBF, MTTR und Grounding-Genauigkeit zu verfolgen |
| Plattform | Organisation | ⚠️ Erfordernis eines manuellen Eingreifens bei allen Agentenfehlern anstelle der automatisierten Wiederherstellung mit Plattformereigniswiedergabe und Leistungsschaltern |
| Einstein | Trust Layer | ⚠️ Niemals Probennahme von Agentenantworten zur Validierung der Erdungsgenauigkeit, wodurch Halluzinationen in der Produktion unentdeckt bleiben |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Agentforce | Agentenkonfiguration | ✅ Entwerfen von Wiederholungsmustern, Ausweichketten und Eskalationsschwellenwerten in Agenten-Workflows vom ursprünglichen Entwurf an und nicht als nachträgliche Überlegungen |
| Agentforce | Aktion | ✅ Bulkify context preparation and paginate large record collections in agent actions (Kontextvorbereitung per Massenvorgang vereinfachen und große Datensatzsammlungen in Agentenaktionen paginieren) |
| Plattform | Plattform-Cache | ✅ Cache häufig aufgerufener Referenzdaten im Plattform-Cache reduziert redundante Abfragen während der Agentenkontextvorbereitung |
| Plattform | Skalierungscenter | ✅ Verwenden Sie das Skalierungscenter, um ressourcenintensive Agentenvorgänge zu identifizieren, die optimiert werden müssen |
| Plattform | Plattformereignisse | ✅ Entwerfen von sich selbst wiederherstellenden Workflows mithilfe von Plattformereignissen als dauerhafte Wiederholungswarteschlangen mit Leistungsschaltern zum Schutz externer Abhängigkeiten |
| Agentforce | Agentenkonfiguration | ✅ Nehmen Sie immer die menschliche Übergabe als endgültigen Ausweg in die Abbaukette jedes Agenten auf |
| Plattform | Organisation | ✅ Agenten-SLIs kontinuierlich überwachen, wenn Kennzahlen unter SLOs fallen |
| Agentforce | Agentenkonfiguration | ✅ Abwägen autonomer Funktionen mit der entsprechenden Aufsicht: Aktivieren der Selbstwiederherstellung nach vorübergehenden Fehlern bei gleichzeitiger Eskalation, wenn die Konfidenz sinkt oder Kundenvorgänge auftreten |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Agentforce | Agentenkonfiguration | ⚠️ Hinzufügen von Zuverlässigkeitsmechanismen (Wiederholung, Ausweichmanöver, Eskalation) als Nachgedanken, statt sie von Anfang an zu entwerfen |
| Agentforce | Aktion | ⚠️ Keine Massenvorbereitung des Kontexts, was zu Fehlern bei der Obergrenze unter realen Abfragemustern führt |
| Plattform | Organisation | ⚠️ API-Verbrauch und Plattformereigniszuteilung nicht proaktiv überwachen und Obergrenzen nur erkennen, wenn Agenten fehlschlagen |
| Agentforce | Agentenkonfiguration | ⚠️ Entwerfen von Agentenketten ohne menschliche Übergabe als endgültiges Ausweichmanöver, sodass kein Wiederherstellungspfad verbleibt, wenn alle automatisierten Optionen erschöpft sind |
| Agentforce | Agentenkonfiguration | ⚠️ Gewähren eines vollständig autonomen Betriebs für Agenten ohne Eskalationsschwellenwerte für Situationen mit niedrigem Vertrauen oder Randfälle |