Agentforce Leitfaden: Zuverlässiges Agentenverhalten erreichen – ein Framework für 6 Ebenen des Determinismus

Olfa Kharrat, Director of Product Management - Agentforce
Reinier van Leuken, Senior Director of Product Management - Agentforce

_{Ab April 2026 werden Themen nun alsUnter-Agents und die Themenauswahl als Agent Router bezeichnet. An der Funktionalität ändert sich nichts. Während dieser Umstellungsphase können in unserer Dokumentation und Benutzeroberfläche sowohl die neuen als auch die bisherigen Bezeichnungen vorkommen.}

Vertrauen ist seit der Gründung von Salesforce im Jahr 1999 der wichtigste Wert des Unternehmens, das Pionierarbeit bei der Entwicklung eines neuen Technologiemodells für Cloud Computing und SaaS geleistet hat. Unternehmen schenken Salesforce ihr Vertrauen, indem sie wertvolle Unternehmensdaten in der Cloud speichern. Sie wissen, dass diese Daten sicher sind und durch geeignete Zugriffskontrollen geschützt werden. Das ist auch heute noch ein entscheidender Faktor, aber im Zeitalter der agentenbasierten KI ist die Definition von Vertrauen noch weiter gefasst. Angesichts der Tatsache, dass Unternehmen zunehmend auf autonome Agenten zurückgreifen, um wichtige Geschäftsfunktionen auszuführen, müssen diese Agenten zu vertrauenswürdigen Geschäftspartnern werden, deren Arbeit präzise, relevant und vor allem zuverlässig ist.

Wie erstellt man also einen zuverlässigen Agenten? Zuverlässigkeit bedeutet in der Regel, dass bei gleicher Eingabe immer das gleiche Ergebnis herauskommt. Allerdings funktioniert das Agenten nicht unbedingt so, da sie auf großen Sprachmodellen (LLMs) basieren, die von Natur aus nicht deterministisch sind. Das gibt den Agenten die Flexibilität, kreative Lösungen zu entwickeln, die auf bestimmte Umstände zugeschnitten sind, ohne dass sie jede Bedingung oder Situation, mit der sie konfrontiert werden, explizit programmieren müssen. Agenten benötigen jedoch auch Governance, damit sie die geschäftlichen Anforderungen erfüllen und die betrieblichen Richtlinien einhalten können. Bei der Ausführung von Geschäftsprozessen müssen sie Zuverlässigkeit unter Beweis stellen und Geschäftsergebnisse erzielen, die deterministischen Einschränkungen entsprechen. Der Determinismus erzwingt eine Starrheit und Disziplin, die im Widerspruch zur Autonomie und Fluidität steht, die Agenten bieten. Daher liegt der Schlüssel zur erfolgreichen Erstellung von Agenten darin, das richtige Gleichgewicht zwischen kreativer Flexibilität und Unternehmenskontrolle zu finden.

Dieses Dokument behandelt wichtige Überlegungen zur Entwicklung zuverlässiger Agenten. Es definiert sechs agentengesteuerte Ebenen und bietet Best Practices zum Wahren der Kontrolle über das agentengesteuerte Verhalten auf jeder dieser Ebene. Die Anleitung beschreibt die Funktionsweise der Agentforce Inferenzmaschine. Mit dem Wachstum von Agentforce wird dieses Dokument aktualisiert, um die neuesten Best Practices widerzuspiegeln.

Dieses Dokument setzt grundlegende Kenntnisse im Entwerfen und Erstellen von Agentforce-Agenten voraus. Für eine Einführung in Agentforce empfehlen wir Folgendes:

• Sehen Sie sich die Ressourcen auf agentforce.com an.
• Folgen Sie dem Trail Agentblazer-Champion werden . Dieser Trail befasst sich mit den Kernkonzepten der KI und hilft Ihnen dabei, einen einfachen Agent für wichtige Aufgaben zu erstellen.
• Weitere Informationen finden Sie unter Agentforce auf help.salesforce.com , insbesondere unter Design und Implementierung von Agenten . Diese Lernkarte führt Sie durch alle wichtigen Schritte des Lebenszyklus, von der Konzeption Ihrer Lösung über die Einrichtung und Konfiguration Ihres Agenten bis hin zum Testen, Bereitstellen und Überwachen.

Zum besseren Verständnis des agentenbasierten Verhaltens vergleichen wir zunächst Agenten mit ihren starren Gegenstücken: Chatbots.

Chatbots: Strenge Regelbefolger

Chatbots folgen vorgegebenen Entscheidungsbäumen, die die Dialoge strukturieren, an denen sie teilnehmen können. Die Durchquerung dieser Entscheidungsbäume basiert auf den Antworten der Nutzer:innen. Diese Antwort kann eine Auswahl aus einer vorgegebenen Reihe von Optionen sein oder eine Freitextantwort. Im Fall einer Freitextantwort wird ein Vorhersagemodell für die Klassifizierung des Intents verwendet. Diese Bäume stellen alle möglichen Unterhaltungsverläufe dar und legen die Antworten des Chatbots bei jedem Schritt fest. Das Verhalten des Chatbots wird streng durch voreingestellte Regeln bestimmt. Wenn die Eingabe Von Nutzer:innen nicht mit einem erkannten Pfad übereinstimmt oder wenn das Vorhersagemodell nicht darauf trainiert wurde, eine bestimmte Absicht zu erkennen, kann der Chatbot nicht angemessen reagieren.

Agenten: Adaptiv und intuitiv

Im Gegensatz dazu nutzen Agenten die Leistungsfähigkeit von LLMs und deren fortschrittliche Fähigkeiten in der natürlichen Sprachverarbeitung (NLP). LLMs ermöglichen es Agenten, die Absicht hinter der Eingabe von Nutzer:innen zu verstehen, selbst wenn diese auf unerwartete Weise formuliert ist. Basierend auf seinem Verständnis des Intents kann der Agent aus einer Reihe von Möglichkeiten die am besten geeignete Aktion auswählen. Ein Agent kann sogar völlig neue Antworten formulieren. Diese Flexibilität und Anpassungsfähigkeit unterscheidet Agenten von ihren Chatbot-Kollegen.

Eine kulinarische Analogie

Der Unterschied zwischen Chatbots und Agenten lässt sich mit dem Kontrast zwischen einem Kochanfänger und einem erfahrenen Koch vergleichen.

• Der Kochanfänger (Chatbot) ist stark auf ein ausführliches Rezept mit genauen Mengenangaben, Schritt-für-Schritt-Anleitungen und spezifischen Garzeiten angewiesen. Jede Abweichung vom Rezept führt zu einer kulinarischen Katastrophe. Entsprechend muss ein Chatbot innerhalb der Grenzen seines vorprogrammierten Entscheidungsbaums funktionieren.
• Der erfahrene Koch (Agent) verfügt über jahrelange kulinarische Erfahrung und Intuition. Mit einem allgemeinen Verständnis Ihrer Vorlieben und einer kurzen Beschreibung der verfügbaren Zutaten kann ein Agent eine köstliche Mahlzeit zubereiten, die Ihren Bedürfnissen entspricht. Die genauen Schritte können jedes Mal variieren, und jede Version des Gerichts kann geringfügige Unterschiede aufweisen, aber das Gesamtergebnis ist durchweg zufriedenstellend. Ebenso kann ein Agent seine Vorgehensweise an den Kontext und die Absicht der Eingabe von Nutzer:innen anpassen, was zu einer erfolgreichen Interaktion führt.

Ein Agent kann seine Vorgehensweise entsprechend dem Kontext und des Intents der Eingabe von Nutzer:innen anpassen, was zu einer erfolgreichen Interaktion führt.

Eine Besonderheit der Intelligenz eines Agenten liegt in seiner Fähigkeit, die am besten geeigneten Aktionen zum richtigen Zeitpunkt zu koordinieren und auszulösen. Diese Flexibilität macht es überflüssig, jede mögliche Interaktion von Nutzer:innen ausführlich zu programmieren.

In Agentforce umfasst das Erstellen eines Agents Unter-Agents (früher Themen), Aktionen sowie Anweisungen und Beschreibungen in natürlicher Sprache.

Unter-Agents

Unter-Agents sind die „zu erledigenden Aufgaben“ des Agent. Unter-Agents verfügen über Attribute wie eine Klassifizierungsbeschreibung, einen Umfang und Anweisungen, die jeden Auftrag und dessen Ausführung definieren. Unter-Agents enthalten Aktionen, die der Agent ausführen kann, sowie Anweisungen, die festlegen, wie diese Aktionen ausgeführt werden.

Aktionen

Aktion ist eine vordefinierte Aufgabe, die der Agent ausführen kann, um seine Arbeit zu erledigen. Es gibt fünf verschiedene Arten von Aktionen:

• Apex-Code ausführen
• Eine API aufrufen
• Einen Flow ausführen
• Eine LLM-Antwort auf eine Eingabeaufforderungsvorlage erhalten
• Ein Vorhersagemodell aufrufen

Anweisungen und Beschreibungen in natürlicher Sprache

Die Definition eines Agents enthält Anweisungen in natürlicher Sprache, die die Ressourcen des Agents beschreiben und die Richtlinien festlegen, innerhalb derer er arbeiten muss. Die Anweisungen sind für Handlungen und Unter-Agents verfasst.

• Aktionen. Eine Aktion enthält:
  • Anweisungen, die beschreiben, was die Aktion bewirkt, und die der Inferenzmaschine mitteilen, wann diese Aktion ausgeführt werden soll.
  • Eingaben mit einer Beschreibung in natürlicher Sprache, damit der Agent sie vorbereiten kann.
  • Ausgaben mit einer Beschreibung in natürlicher Sprache, wie sie formatiert und verwendet werden sollen.
• Unter-Agent. Ein Unter-Agent enthält Anweisungen, die festlegen, wie seine Aktionen auf einer höheren Ebene ausgeführt werden sollen. Beispielsweise können Anweisungen Leitlinien zum Tonfall, zur gewünschten Abfolge von Handlungen, zu möglichen Voraussetzungen oder dazu enthalten, wann Unterhaltungen an Menschen eskaliert werden sollen. Der Unter-Agent enthält auch eine Klassifizierungsbeschreibung und eine Abgrenzung des Anwendungsbereichs. Insgesamt wird so sichergestellt, dass der Agent im Rahmen seiner definierten Rolle bleibt und die Aufgabe ausführt.
• Daten. Agenten benötigen Daten, um ihre Arbeit erfolgreich ausführen zu können. Daten können strukturiert sein, wie beispielsweise CRM-Daten, oder unstrukturiert, wie beispielsweise Wissensartikel von Unternehmen. Agenten greifen über Aktionseingaben auf Daten zu. Beispielsweise kann eine Aktion einen Prompt-Template aufrufen, der auf CRM-Daten zur Kontextbildung basiert oder mithilfe von Techniken zur Abruf-erweiterten Generierung (RAG) um unstrukturierte Daten ergänzt wird.

Diese verschiedenen Bausteine helfen einem Agenten, wenn sie korrekt aufgebaut sind, seinen beabsichtigten Zweck zu erfüllen und dabei innerhalb der entsprechenden Grenzen zu operieren.

Die Inferenzmaschine von Agentforce orchestriert diese Bausteine zu einem korrekten agentengesteuerten Verhalten. Sie nutzt die in Unter-Agents und Aktionen definierten Anweisungen und Beschreibungen in natürlicher Sprache. Kernstück ist ein neuartiges Inferenzmodell namens ReAct, das 2022 von Yao et al vorgestellt wurde. Dieses Paradigma ahmt das menschliche Aufgabenmanagement nach, indem es über ein Problem eine Inferenz zieht, Aktion ergreift, die Ergebnisse der Aktion beobachtet und den Zyklus bis zur Fertigstellung der Aufgabe wiederholt.

Salesforce-Agenten folgen diesem Paradigma:

1. Inferenz: Die Absicht der Nutzer:innen verstehen und mit dem richtigen Unter-Agent und den richtigen Aktionen in Einklang bringen.
2. Handeln: Die richtige Aktionskette starten.
3. Beobachten: Bewerten der Aktionsergebnisse anhand des Intents der Nutzer:innen. Wenn die Absicht nicht erfüllt ist, die Inferenz anhand des bisher erzielten Ergebnisses und anhand der Unter-Agent-/Aktionsanweisungen und Beschreibungen fortsetzen. Wenn die Absicht erfüllt ist, die endgültige Antwort unter Beachtung möglicher Formatierungsanweisungen geben.
4. Wiederholen: Diese Schritte iterieren, bis der letzte angewiesene Schritt erreicht ist.

Die Inferenzmaschine verwendet LLMs bei jedem Inferenz- und Beobachtungsschritt. Je nach Aktion können auch LLMs im Schritt „Handeln“ verwendet werden.

In diesem Abschnitt wird ein mehrschichtiger Ansatz zur Verbesserung des Determinismus von Agenten beschrieben. Jede Stufe baut auf der vorherigen auf, wobei die Komplexität und die Fähigkeiten zunehmen, wodurch mehr Kontrolle über das Verhalten des Agenten erreicht wird.

Die erste Ebene konzentriert sich darauf, Agents in die Lage zu versetzen, relevante Unter-Agents autonom zu identifizieren und dann anhand von Zielen statt expliziten Anweisungen geeignete Aktionen auszuwählen. Der Kernmechanismus besteht darin, anhand eines Kontextverständnisses auf Benutzereingaben zu reagieren. Obwohl technisch gesehen jeder Aktionstyp hinzugefügt werden kann, gehen wir auf dieser Ebene davon aus, dass es sich um Prompt-Aktionen handelt. Unter-Agents ohne Anweisungen mit Prompt-Aktionen bieten eine schnelle und effiziente Möglichkeit, häufig gestellte Fragen zu beantworten.

Auf dieser Stufe liegt der Schwerpunkt darauf, durch dynamisches Verständnis ein Grundniveau an Reaktionsfähigkeit und Autonomie der Agenten zu etablieren.

Aufbauend auf der Grundlage der anweisungsfreien Aktionsauswahl werden in dieser Stufe explizite Anweisungen eingeführt, um das Verhalten des Agenten zu steuern. Durch das Hinzufügen präziser Anweisungen lässt sich besser steuern, wie Agenten auf verschiedene Situationen reagieren. Anweisungen an Agenten können in Form von Regeln, Richtlinien, Leitlinien und Beispielen formuliert werden. Diese geben dem Agenten konkrete Anweisungen, wie er mit verschiedenen Themen umgehen, Aktionen ausführen und deren Ergebnisse verarbeiten soll. Das Ziel dieser Stufe ist es, den Agenten klare Anweisungen zu geben, um die Konsistenz zu erhöhen und die Einhaltung der Unternehmensrichtlinien und -prozesse zu verbessern.

Kontextbildung beinhaltet die Verknüpfung des Verständnisses und der Reaktionen des Agenten mit externen Wissensquellen. Durch die Kontextbildung wird sichergestellt, dass die vom Agenten bereitgestellten Informationen genauer, aktueller und relevanter sind. Diese Ebene integriert den Zugriff auf Datenbanken, Knowledge Bases und andere Informationsspeicher. Die Kontextbildung der Antworten des Agenten anhand verifizierter Daten erhöht dessen Zuverlässigkeit und Vertrauenswürdigkeit.

Diese Ebene erweitert die Fähigkeit für Agenten, mit Variablen zu arbeiten. Dank Variablen können Agenten Interaktionen personalisieren, den Kontext über mehrere Interaktionen hinweg beibehalten und ihr Verhalten dynamisch anpassen, basierend auf spezifischen Datenpunkten, die während der Agentensitzung gespeichert werden. Beispielsweise könnte ein Agent die Präferenzen von Nutzer:innen, Bestelldetails und andere relevante Informationen erfassen und diese Daten dann zur individuellen Gestaltung der Interaktion nutzen. Mit Variablen sind Agenten besser in der Lage, komplexere, stärker vorgegebene und personalisiertere Interaktionen zu bewältigen.

In diesem Schritt wird der Agent in die Kernfunktionen von Salesforce integriert: Apex, APIs und Flow. Durch die Integration kann der Agent komplexe Aktionen innerhalb des Salesforce-Ökosystems ausführen, z. B. auf Daten zugreifen und diese bearbeiten, Workflows auslösen und mit anderen Systemen interagieren.

• Apex bietet programmatische Kontrolle.
• APIs ermöglichen eine nahtlose Integration mit anderen Anwendungen
• Flows ermöglichen die Automatisierung komplexer Geschäftsprozesse.

Diese Stufe verwandelt den Agenten in ein leistungsstarkes Tool, das komplexe Aufgaben ausführen und direkt zu den Geschäftsergebnissen beitragen kann.

Aufbauend auf den technischen Integrationen der Ebene 5 bringt diese letzte Ebene deterministische Inferenz ein, um die Lücke zwischen probabilistischer KI und starrer Geschäftslogik zu schließen. Die bisherigen Stufen sind bei der Entscheidung über die Auswahl des passenden Tools auf das LLM angewiesen. Mit dem Agentenskript hingegen können Sie den Inferenzprozess selbst „programmieren“. Siekönnen ein Canvas im Dokumentstil oder direkt Code verwenden, um unveränderliche Pfade (z. B. obligatorische Authentifizierungsgates, bedingte Verzweigungen nach dem „wenn/sonst“-Prinzip oder erzwungene Übergänge von Unter-Agents) zu definieren, denen der Agent unabhängig von der Benutzereingabe folgen muss. Mit diesem hybriden Inferenzansatz stellen Sie der dialogorientierten Flexibilität eines LLM jeweils eine Ebene der garantierten Ausführung vor und nach. Die 6. Ebene verwandelt den Agenten in einen Zero Trust-Partner für Unternehmen, der hohe Anforderungen an Konformität, gesetzliche Offenlegungspflichten und komplexe mehrstufige Abhängigkeiten absolut präzise bewältigen kann.

Ausgehend von einer Grundlinie der Reaktionsfähigkeit und Autonomie von Agents betrachten Sie einen Agent, der nur aus Unter-Agents und Aktionen mit den entsprechenden Beschreibungen besteht. Anhand dieses Beispiel-Agent können wir die verschiedenen Schritte der Inferenzmaschine vorstellen und zeigen, wie sie diese Beschreibungen nutzt, um die richtigen Unter-Agents und anschließend die auszuführenden Aktionen auszuwählen. Durch Weglassen der Unter-Agent-Anweisungen aus diesem Beispiel können wir beobachten, dass Agents in dieser ersten Ebene im Vergleich zu Agents in höheren Ebenen den größten Freiheitsgrad haben. In Stufe eins kann der Agent völlig frei die Aktion auswählen, die er für angemessen hält, und zwar ausschließlich auf der Grundlage der laufenden Konversation.

Überdenken Sie die folgenden Überlegungen zur Inferenzmaschine:

• Die Konfigurationseinstellungen sind für das LLM der Inferenzmaschine festgelegt. Agent Builder können sie nicht ändern. Derzeit kann der Agent Builder für die Inferenz zwischen einem LLM von OpenAI oder einem LLM von Anthropic wählen, das auf der Salesforce-Infrastruktur gehostet wird. Dies kann sich jedoch ändern, wenn weitere Modelle hinzugefügt werden.
• Standardverlauf der Inferenzmaschine: Wann immer eine Anfrage an die Inferenzmaschine gestellt wird (Schritte 2–5), ruft diese automatisch den Verlauf der letzten Anfragen und Antworten ab. Dadurch wird sichergestellt, dass der Konversationskontext für die Inferenzmaschine erhalten bleibt. Zusätzlich zu den Kundeninteraktionen umfassen diese Aufrufe an das Planungs-LLM auch Aufrufe an das Inferenzmaschinen-LLM für andere Anfragen, wie beispielsweise die Auswahl von Unter-Agents.

Die Inferenz umfasst vier Hauptschritte:

1. Auswahl von Unter-Agents
2. Aktionsauswahl
3. Agenten-basierte Schleife
4. Prüfung der Kontextbildung

Die Unter-Agents sind so konzipiert, dass sie die Genauigkeit verbessern, mit der Agents die richtige Aktion oder Abfolge von Aktionen klassifizieren. Jeder Unter-Agent sollte aus semantisch unterschiedlichen Aktionen bestehen, die alle zu einer prägnanten Beschreibung von Unter-Agents gehören können und somit zu einer ähnlichen Agentenfunktion gehören.

Der richtige Unter-Agent wird vom Inferenzmaschinen-LLM ausgewählt (Schritt 2-3 des Diagramms). Es wählt den Unter-Agent aus, dessen Klassifizierungsbeschreibung am ehesten mit der letzten Äußerung übereinstimmt, indem er einen unter-Agent-Prompt verwendet. Dieser Unter-Agent-Prompt enthält die Klassifizierungsbeschreibungen aller Unter-Agents und den Unterhaltungsverlauf. Zusätzlich zu Äußerungen und Antworten von Agents umfasst der Unterhaltungsverlauf auch ausgeführte Aktionen und deren Ergebnisse. Darüber hinaus enthält der Prompt wichtige Anweisungen, die eine Analyse im Kontext des Unterhaltungsverlaufs vorschreiben und vom LLM verlangen, seinen Denkprozess offenzulegen.

Weitere Überlegungen:

• Neben den sichtbaren Unter-Agents existiert automatisch ein zusätzlicher, versteckter Unter-Agent für „Off-Topic“-Äußerungen. Dieser Unter-Agent wird ausgewählt, wenn kein anderer vorhandener Unter-Agent mit der Äußerung übereinstimmt. Dies hilft dem Agents, Fehlklassifizierungen zu vermeiden. Dieser Unter-Agent verfügt über keine Aktionen. Er dient lediglich dazu, der Infernzmaschine dabei zu helfen, später eine angemessene Antwort zu formulieren.
• In dem Unter-Agent-Prompt werden nur der Name und die Klassifizierungsbeschreibung des Unter-Agent verwendet.
• Das Inferenzmaschinen-LLM kann jeweils nur einen Unter-Agent auswählen.
• Unterhaltungen können unerwartete Wendungen nehmen. Bei jedem Empfang einer Äußerung fährt die Inferenzmaschine mit dem Schritt der Auswahl des Unter-Agents fort, was bedeutet, dass bei jeder neuen Äußerung ein neuer Unter-Agent ausgewählt werden kann.

Unter-Agents haben zwei Ziele:

1. Reduzieren des Risikos, die Inferenzmaschine zu verwirren, indem Aktionen gruppiert werden, wodurch vermieden wird, dass sie die falschen Aktionen auswählt.
2. Die Auswahl und Ausführung von Aktionen mit Anweisungen leiten (mehr dazu in Ebene Zwei: Agentenbasierte Kontrolle: Anweisungen hinzufügen.

Durch die sorgfältige Organisation der Fähigkeiten der Agents in klar definierte Unter-Agents, die aus miteinander verbundenen Aktionen bestehen, arbeiten die Agents effektiver und vorhersehbarer und lassen sich leichter aktualisieren und erweitern. Es gibt zwei mögliche Ansätze zum Aufbau von Unter-Agents: Top-down und Bottom-up.

• Beim Top-Down-Ansatz werden zunächst Unter-Agents als übergeordnete Aufgaben definiert, die vom Agent zu erledigen sind, und anschließend werden die einzelnen Aktionen für diese Unter-Agents festgelegt.
• Beim Bottom-up-Ansatz werden zunächst alle einzelnen Maßnahmen definiert, die dann zu Unter-Agents zusammengefasst werden.

Beide Ansätze führen zu guten Ergebnissen, wenn sie richtig befolgt werden.

Bottom-Up-Ansatz

Dieser Abschnitt führt Sie durch den Bottom-up-Ansatz, da dieser eng mit den Gründen zusammenhängt, warum die Inferenzmaschine zunächst Unter-Agents benötigt.

Schritt 1: Auflisten aller Agent-Aktionen

Beginnen Sie damit, alle spezifischen Aktionen aufzulisten, die der Agent ausführen können sollte. In dieser Phase ist es besser, sehr konkret zu sein, als zu allgemein. Vermeiden Sie es, Aktionen vorzeitig zu gruppieren oder zu vereinfachen. Das Ziel ist es, einen umfassenden und detaillierten Überblick über die Möglichkeiten des Agenten zu schaffen.

Bei einem Serviceagent könnte die erste Liste beispielsweise Folgendes enthalten:

• Bestellung zurücksenden: Wird verwendet, um den Rückgabeprozess für eine Bestellung zu initiieren.
• Verfügbarkeit des Bestands prüfen: Wird verwendet, um zu überprüfen, ob ein Produkt auf Lager ist.
• Richtlinien für den Produktaustausch prüfen: Dient zum Abrufen von Informationen über Austauschregeln.
• Fragen mit Wissen beantworten: Wird verwendet, um allgemeine oder FAQ-ähnliche Fragen zu beantworten.
• Werbeaktionen prüfen: Wird verwendet, um nach verfügbaren Werbeaktionen oder Rabatten zu suchen.
• Lieferdatum prognostizieren: Wird verwendet, um das erwartete Lieferdatum/-Uhrzeit zu schätzen.
• Bestellstatus prüfen: Wird verwendet, um den aktuellen Status der Bestellung eines Kunden zu ermitteln.
• Kundenbestellungen suchen: Dient zum Abrufen aller vergangenen oder aktiven Bestellungen eines bestimmten Kunden.
• Technische Probleme beheben: Wird verwendet, um technische Probleme mit einem Produkt oder einer Dienstleistung zu lösen.
• Kundenbestellungsbedingungen finden: Alle Bedingungen für eine Bestellung abrufen.
• Kundenressourcen suchen: Dient zum Identifizieren oder Abrufen von Assets, die mit einem Kunden verknüpft sind.
• Lieferadresse ändern.

Beachten Sie, dass eine Aktion wie „Kundenbeschwerden lösen“ zu weit gefasst ist. Aktion sollte die feinste Granularität im Verhalten eines Agenten darstellen. Beschwerden können vielfältig sein, und verschiedene Aktionen decken sie bereits ab:

• Probleme nach der Lieferung, wie z. B. die Fehlerbehebung beschädigter oder fehlerhafter Produkte, werden bereits durch „technische Probleme beheben“ abgedeckt.)
• Probleme vor der Auslieferung, wie fehlende Lieferungen, die Notwendigkeit, Liefertermine zu ändern oder Bestellungen zu ändern, werden bereits durch Aktionen wie „Bestellstatus überprüfen“, „Lieferdatum vorhersagen“ oder „Bestellung zurücksenden“ abgedeckt.
• Allgemeine Kundenanliegen wie Richtlinienanfragen werden bereits durch „Fragen mit Wissen beantworten“ oder „Richtlinien für den Produktaustausch überprüfen“ abgedeckt.

Schritt 2: Markieren Sie Aktionspaare (oder Multiples), die möglicherweise zu Verwirrung führen

Markieren Sie Aktionen, die sich in ihrer Art ähneln, da sie zu Verwirrung für die Inferenzmaschine führen können. Ihre Beschreibungen unterscheiden sich semantisch nicht ausreichend, sodass die Infernzmaschine nicht weiß, welche Aktion in Schritt 5 ausgewählt werden soll.

Beispielsweise haben „Technische Probleme beheben“ und „Fragen mit Wissen beantworten“ ähnliche Beschreibungen, können jedoch in ihrer Funktionalität erheblich voneinander abweichen. Die Markierung solcher semantischer Überschneidungen hilft dabei, zu ermitteln, welche Aktionen über mehrere Unter-Agents hinweg getrennt werden müssen.

Schritt 3: Erstellen Sie erste Gruppierungen von Aktionen nach Unter-Agents

Sobald die Aktionen klar definiert sind und ihre semantischen Überschneidungen identifiziert wurden, können die Aktionen in vorläufige Unter-Agents gruppiert werden. Ein Unter-Agent ist eine logische Kategorie der Funktionalität – eine Gruppierung von Aktionen, die zusammen eine zusammenhängende Fähigkeit oder Fertigkeit des Agent darstellen.

Beim Erstellen dieser Gruppierungen gilt Folgendes:

• Semantische Überschneidungen vermeiden, indem nur die erforderliche Mindestanzahl an Unter-Agents verwendet wird.
• Sicherstellen, dass jeder Unter-Agent Aktionen enthält, die sinnvoll miteinander verbunden sind.
• Sicherstellen, dass unterstützende Aktionen, die in einer Kette ausgeführt werden müssen, im selben Unter-Agent vorhanden sind.

Hier ist ein Beispiel für eine erste Gruppierung für einen Serviceagent:

Unter-Agent 1:

• Eine Bestellung zurücksenden
• Bestandsverfügbarkeit prüfen
• Produktumtauschrichtlinien überprüfen
• Werbeaktionen prüfen
• Liefertermin prognostizieren
• Kundenbestellungsbedingungen finden
• Bestellstatus überprüfen
• Kundenbestellungen finden
• Kundendatenbestände finden
• Fragen mit Wissen beantworten
• Lieferadresse ändern

Unter-Agent 2:

• Technische Probleme beheben
• Kundendatenbestände finden

Schritt 4: Verfassen Sie Klassifizierungsbeschreibungen für Unter-Agents und teilen Sie Unter-Agents bei Bedarf auf

Nachdem die erste Gruppierung vorgenommen wurde, werden Klassifizierungsbeschreibungen für die einzelnen Unter-Agents erstellt.

• Bei Unter-Agent 2 in unserem Beispiel geht es eindeutig um technische Probleme mit Produkten.
• Unter-Agent 1 wiederum deckt einen breiteren Bereich ab. Es geht hauptsächlich um die Auftragsverwaltung, aber es enthält auch einige Aktionen, die nichts mit der Auftragsverwaltung zu tun haben, wie z. B. die Überprüfung auf Werbeaktionen und das Beantworten von Fragen mit Wissen. Unter-Agent 1 kann nicht klar und prägnant in einem einzigen Satz beschrieben werden, daher sollte der Unter-Agent in verschiedene Unter-Agents unterteilt werden.

Nach der Verfeinerung erhalten wir:

• Unter-Agent 1: Auftragsverwaltung: Beschreibt Aktionen im Zusammenhang mit der Verwaltung und Änderung von Kund:innen-Aufträgen und der damit verbundenen Logistik, mit Ausnahme von Aktionen im Zusammenhang mit Umtausch und Rückgabe.
  • Bestandsverfügbarkeit prüfen Bestimmen, ob ein Produkt auf Lager ist.
  • Lieferdatum vorhersagen: Schätzen, wann eine Bestellung eintrifft.
  • Bestellstatus prüfen: Status einer Bestellung von Kund:innen ermitteln.
  • Kundenbestellungen suchen: Alle Bestellungen von Kund:innen abrufen.
  • Lieferadresse ändern.
• Unter-Agent 2: Troubleshooting
  • Kundendatenbestände finden: Registrierten Geräte oder Produkte der Kund:innen abrufen.
  • Technische Probleme beheben: Technische Unterstützung oder Diagnosen bieten.
• Unter-Agent 3: Umtausch: Beschreibt Aktionen im Zusammenhang mit Bestellungsumtausch und -Rücksendung.
  • Bestellung zurücksenden: Rückgabeprozess für Bestellungen starten.
  • Richtlinien für den Produktaustausch prüfen: Regeln für den Austausch von Produkten angeben.
  • Kundenbestellungen suchen: Alle Bestellungen von Kund:innen abrufen.
  • Kundenbestellungsbedingungen finden: alle Bedingungen für eine Bestellung abrufen
• Unter-Agent 4: Produktsupport: Beschreibt Querschnittsaktionen, die zum Abrufen und Weiterleiten von Informationen verwendet werden.
  • Fragen mit Wissen beantworten: Allgemeine Kundenanfragen mithilfe von Knowledge Base-Informationen beantworten.
  • Werbeaktionen prüfen: Aktuelle Werbeaktionen oder Rabatte aufzeigen.

Zur Erinnerung: Erstellen Sie zunächst eine umfassende Liste aller möglichen Aktionen und markieren Sie dann semantische Überschneidungen zwischen diesen Aktionen. Erstellen Sie anschließend eine Reihe von Unter-Agents, die mindestens alle semantischen Überschneidungen auflösen (damit die Inferenzmaschine nicht innerhalb eines Unter-Agents verwirrt wird). Schreiben Sie dann die Klassifizierungsbeschreibung für jeden Unter-Agent. Sollten die Unter-Agents einen zu weit gefassten Anwendungsbereich haben, teilen Sie sie in detailliertere Unter-Agents auf. Durch die Umsetzung dieser Leitlinien können Sie einen Agent erstellen, der nicht nur gut funktioniert, sondern auch leicht zu warten und zu erweitern ist.

Diese Struktur bietet Support für eine bessere Inferenz, eine genauere Ausführung und klarere Entscheidungsgrenzen innerhalb des Verhaltens des Agenten. Darüber hinaus stützt sie sich auf die Zusammenarbeit zwischen Designern, Ingenieuren und Fachexperten, um die Fähigkeiten des Agenten transparenter und modularer zu gestalten.

Weitere Überlegungen für eine effektive Erstellung von Unter-Agents

• Optimale Anzahl von Unter-Agents: Zur Verbesserung der Leistung von LLMs bei der Klassifizierung des richtigen Unter-Agents ist es im Allgemeinen ratsam, nicht mehr als 10 Unter-Agents zu verwenden. Aber das ist nur eine Faustregel. Darüber hinaus sollte jeder Unter-Agent eine klare und eindeutige Beschreibung haben. Letztendlich hängt die optimale Anzahl von Unter-Agents von der semantischen Distanz zwischen den Beschreibungen der Unter-Agent-Klassifizierung ab. Wenn sich die Klassifikationsbeschreibungen der Unter-Agents stark unterscheiden, wird das Risiko von Unter-Agent-Überschneidungen minimiert. Weitere Best Practices zur Vermeidung von Überschneidungen zwischen Unter-Agents werden hier beschrieben.
• Finden Sie ein Gleichgewicht zwischen Größe und Übersichtlichkeit der Unter-Agents: Auch wenn es im Allgemeinen vorteilhaft ist, kleine Unter-Agents in Bezug auf Aktionen und Anweisungen zu haben, um die Klassifizierung zu vereinfachen, kann die Erstellung zu vieler Unter-Agents mit sehr ähnlichen Beschreibungen zu Verwirrung führen, genauso wie semantische Überschneidungen zwischen Aktionen zu Fehlklassifizierungen führen. Daher ist es wichtig, über klar semantisch differenzierte Beschreibungen von Unter-Agents zu verfügen. Sie können LLMs verwenden, um diese gut differenzierten Klassifizierungen zu erstellen.
• Standardsprache und kontextbezogene Klarheit: LLMS kennen möglicherweise keine spezifischen Unternehmens- oder Geschäftsbedeutungen und Abkürzungen. Verwenden Sie eine Standardsprache oder erklären Sie die Bedeutung von Wörtern in Ihrem spezifischen Kontext sehr deutlich.
• Im Unter-Agent-Prompt werden nur der Name des Unter-Agent und die Beschreibung gesendet. Daher hat eine Änderung des Umfangs oder der Vorgaben des Unter-Agents keinen Einfluss auf die Unter-Agent-Auswahl.

Beispiel in Aktion

Stellen Sie sich vor, ein:e Servicemitarbeiter:in erhält eine Garantieanfrage für eine Uhr. Das Garantieproblem scheint nicht mit dem Austausch oder Support des Produkts zusammenzuhängen. Die Auftragsverwaltung scheint der geeignetste Unter-Agent zu sein, um dieser Anfrage gerecht zu werden. Daher wird der letztere Unter-Agent von der Inferenzmaschine als das wahrscheinlichste ausgewählt, um die Anforderung zu erfüllen.

Nach der Unter-Agent-Auswahl wählt die Inferenzmaschine die richtigen Aktionen aus dem ausgewählten Unter-Agent aus, die ausgeführt werden sollen. Auch hierfür ist das Inferenzmaschinen-LLM verantwortlich, das einen anderen Prompt namens „Beobachtungs-Prompt” verwendet. Der Zweck des Beobachtungs-Prompts besteht darin, den nächsten Inferenz-Schritt zu ermitteln. Der nächste Schritt kann einer der folgenden sein:

• Starten einer Aktion
• Anfordern von Aktionseingaben von Nutzer:innen
• Klärung der Anfrage von Nutzer:innen anfordern
• Senden der endgültigen Antwort an die Nutzer:innen (Erfüllen der Anfrage der Nutzer:innen), sobald die Aktion abgeschlossen ist (weitere Details siehe Schritt 3 der Inferenz)

Die Eingabe für den Beobachtungs-Prompt wird aus allen Beschreibungen aller Aktionen aus dem Unter-Agent sowie aus dem Unterhaltungsverlauf gebildet.

Best Practices für das Aktionsdesign

Aktion ist eine vordefinierte Aufgabe, die der Agent ausführen kann, um seine Arbeit zu erledigen. Aktion ist die feinkörnigste Definition von Arbeit. Es gibt fünf verschiedene Arten von Agentenaktionen: (1) Apex-Code ausführen, (2) eine API aufrufen, (3) einen Flow ausführen, (4) eine LLM-Antwort auf eine Eingabeaufforderungsvorlage erhalten und (5) ein Vorhersagemodell aufrufen. Die meisten dieser Aktionen können deterministisch sein. Eine Ausnahme besteht darin, eine Antwort auf eine Prompt-Vorlage zu erhalten (vorausgesetzt, dass das externe System, die Flow- oder die Apex-Aktion keine probabilistischen Elemente wie Prompt-Aufrufe enthält). Wir behandeln diese Probleme auf der fünften Ebene der agentenbasierten Kontrolle.

1. Lenken des agentengesteuerten Verhaltens in Prompt-Aktionen: Es gibt zwei Möglichkeiten, die Kontrolle über das Verhalten des Agenten in Prompt-Aktionen zu erzwingen: (1) Fügen Sie der Prompt-Vorlage durch Prompt Engineering weitere Anweisungen hinzu und (2) konfigurieren Sie die Hyperparameter des LLM, das die Prompt-Antwort generiert, insbesondere die Temperatur (siehe Dokumentation ). Durch Absenken der Temperatur wird die Variabilität der generierten Reaktionen reduziert, was deren Wiederholbarkeit und die Zuverlässigkeit der Agenten erhöht.
2. Optimale Anzahl von Aktionen innerhalb eines einzelnen Unter-Agents: Ähnlich wie bei der maximalen Anzahl von Unter-Agents sollte die Anzahl der Aktionen innerhalb eines Unter-Agent 10 nicht überschreiten. Aber auch dies ist eine Faustregel. Der eigentliche Faktor ist der semantische Abstand zwischen den Aktionen. Wenn Aktionen durch ihre Beschreibung deutlich zu unterscheiden sind, kann diese Zahl größer sein. Es gibt jedoch keine numerische Kennzahl für die semantische Entfernung. Dies hängt von der Interpretation des Agent Builders ab. Je größer der Bedeutungsunterschied zwischen den Aktionsbeschreibungen ist, desto größer ist der semantische Abstand. Überschneidungen sollten hier konsequent vermieden werden.
3. Aktionsbeschreibungen: Anders als der Name vermuten lässt, dient die „Aktionsanweisung“ als Anweisung für das Inferenzmaschinen-LLM zur Auswahl der richtigen Aktion des jeweiligen Unter-Agents. Beachten Sie, dass die Verwendung semantisch eindeutiger Aktionsbeschreibungen die Qualität ihrer Klassifizierungen erheblich verbessern kann. Lesen Sie diese Beschreibungen sorgfältig durch und vergleichen Sie insbesondere alle Aktionsbeschreibungen, die zu einem Unter-Agent gehören.

Beispiel in Aktion

Fahren wir mit dem vorherigen Beispiel fort, in dem ein Service-Agent eine Frage zur Garantierichtlinie für eine Uhr erhalten hat. Nach Auswahl des Unter-Agents „Auftragsverwaltung“ wird die wahrscheinlichste Aktion ausgewählt. Da es sich um den Unter-Agent „Auftragsverwaltung“ handelt, ist der erste logische Schritt, den Auftrag zu suchen (wozu sonst sollte man Garantieinformationen abrufen?), indem Sie die Aktion „Auftrag suchen” starten.

Eine Nutzeräußerung kann die Ausführung mehrerer Aktionen auslösen, bevor eine Antwort an die Nutzer:innen zurückgesendet wird. Dies ist auf die Agenten-basierte Schleife zurückzuführen, die so lange die nächstbeste Aktion auswählt und ausführt, bis eine der folgenden Bedingungen erfüllt ist:

• Das Inferenzmaschinen-LLM stellt fest, dass die Anfrage vollständig ist. In diesem Fall stellt sie fest, dass die Anfrage der Nutzer:innen durch die Antwort erfüllt wird. Beachten Sie, dass ein Teil dieser Überprüfung eine Kontextbildung umfasst, bei der überprüft wird, ob die Reaktion in den Ausgaben der Aktion geerdet ist. Die Antwort sollte keine Informationen enthalten, die vom Infernzmaschinen-LLM erfunden wurden, da dies zu Halluzinationen oder anderweitig falschen Antworten führen kann.
• Es werden keine geeigneten Aktionen mehr gefunden.
• Die maximal zulässigen LLM-Aufrufe für den aktuellen Schritt sind erreicht. Diese Zahl wird von der Inferenzmaschine selbst festgelegt.

Aktionen unterliegen keinem bestimmten Timeout. So vermeiden Sie Unterbrechungen, wenn die Ausführungszeiten von Aktionen je nach Komplexität variieren. Einige Aktionen sind einfach komplexer auszuführen als andere.

Beispiel in Aktion

Nach dem Start einer Auftragssuche wertet die Inferenzmaschine die bisher generierte Antwort aus und entscheidet dann, dass weitere Schritte erforderlich sind, bevor eine Antwort an die Nutzer:innen zurückgesendet werden kann. Es geht darum, die Garantiebestimmungen nachzuschlagen, da die Bestellung nun im Unterhaltungsverlauf vorhanden ist.

Dabei stellt der Agent jedoch fest, dass der/die Kund:in tatsächlich zwei Uhren gekauft hat, die durch die Aktion „Bestellsuche“ abgerufen wurden. Daher entscheidet die Inferenzmaschine in der Agenten-basierten Schleife nun, die Kund:innen zu bitten, anzugeben, für welche Uhr er Garantieinformationen benötigt.

Overscripting vermeiden

Vermeiden Sie es, den Agenten zu genau vorzuschreiben, wie sie mit den Nutzer:innen eine Unterhaltung führen sollen. Übermäßiges Skripting kann die Fähigkeit eines Agenten beeinträchtigen, eine Beziehung aufzubauen, die individuellen Anforderungen der Nutzer:innen zu verstehen und in Echtzeit effektiv auf dynamische Umstände zu reagieren. Außerdem können langwierige Anweisungen dazu führen, dass der Agent langsamer reagiert und die Inferzinfmaschine verwirrt wird. Determinismus über Anweisungen zu erzwingen, ist nicht der bevorzugte Ansatz.

Was Sie nicht tun sollten

Beispielsweise muss ein Agent nicht darauf hingewiesen werden, in Antworten auf Serviceanfragen nicht auf Wettbewerber Bezug zu nehmen. Dies kann zu unerwünschtem Verhalten führen, da der Agent sich auch weigern kann, Fragen zur Integration mit einem Anbieter zu beantworten, der gleichzeitig ein Wettbewerber ist. Stattdessen könnte die Anweisung etwa lauten: „Wenn du über Wettbewerber sprichst, antworte im besten Interesse des Unternehmens.“ Dadurch werden restriktive, bedingte Anweisungen wie „Erwähnee den Wettbewerber xyz nur im Fall …“ vermieden und stattdessen die Inferenz des LLM genutzt. Dieses Beispiel zeigt, wie Anweisungen auf einer allgemeineren, abstrakteren Ebene gegeben werden können, ähnlich wie menschliche Service-Mitarbeiter:innen nach ihrer Einstellung geschult werden.

Schauen wir uns einige weitere Beispiele an, wie Sie nicht tun sollten. Dies sind einige schlechte Anweisungen, die einem Serviceagent gegeben wurden, der Bewerber:innenprofile auf einer Jobbörse bearbeitet. Diese Anweisungen versuchen, jede mögliche Äußerung von Kund:innen zu antizipieren und sollten daher vermieden werden:

Anweisung 1: Der Agent erhält die folgende Äußerung: „Kann ich ein Bild zu meinem Profil hinzufügen?“ Frage die Kund:innen dann sofort: „Was ist Ihr Profiltyp?“

Anweisung 2: Wenn Kund:innen ein Premium-Profil angeben, antworte mit „Ich werde Ihre Vertragsdetails überprüfen“, suche dann nach den Vertragsdetails und überprüfe, ob vereinbart wurde, dass sie das Profilbild aktualisieren können.

Wenn vereinbart wurde, dass Bewerber:innen dies tun können, antworte mit „Ja, das ist möglich. Ich werde das für Sie aktualisieren. Können Sie Ihr neues Foto zur Verfügung stellen?“ Aktualisiere das Bewerber:innen-Profil entsprechend nach Eingang des Fotos. Wenn der Vertrag keine Änderungen am Profilbild enthält, sage: „Tut mir leid, das ist nicht möglich. Ich leite Sie an einen Menschen weiter.“

Anweisung 3: Nicht-Premium-Profil: Wenn Kund:innen ein nicht-Premium-Profil angeben, antworte mit „Ihr Bild kann nicht aktualisiert werden. Wenn Sie das tun möchten, lassen Sie es mich wissen und ich werde Sie an einen Menschen weiterleiten.“

Anweisung 4: Wenn der Profiltyp unklar ist, antworte mit „Ich konnte Ihren Profiltyp nichtermitteln“.

Was Sie stattdessen tun sollten

Anstelle dieser Art von Mikromanagement sollten Sie einen flexibleren Ansatz verfolgen, der das Verhalten und die Vorgehensweise der Agenten vorgibt. Beachten Sie die folgenden Best Practices:

1. Verwenden Sie RAG/ Knowledge-Aktionen für Richtlinien und Regeln, die in Wissensartikeln enthalten sind (anstatt sie als Anweisungen zu schreiben). Die relevanten Informationen werden zum richtigen Zeitpunkt abgerufen. Für das obige Beispiel bedeutet dies, dass ein Wissensartikel mit dem Titel „Bildaktualisierung“ Folgendes enthalten sollte: „Nur Bewerber:innen mit einem Premium-Profil, deren Vertrag Bildänderungen zulässt, können ihr Bild aktualisieren.“
2. Skizzieren Sie die wichtigsten Leitlinien und Leitplanken einzeln, unabhängig von der Unterhaltung. Geben Sie Agenten eine klare und prägnante Erklärung des erwarteten Verhaltens oder der fraglichen Vorgehensweise.

Basierend auf diesen Best Practices könnten bessere Anweisungen wie folgt aussehen:

Anweisung 1: : „Verwende Knowledge-Aktionen, um Richtlinien für den Fall zu überprüfen, dass Kontoänderungen angefordert werden.“

Anweisung 2: : „Antworte nicht auf Fragen, für die keine anwendbare Richtlinie gefunden werden konnte.“

Die Anwendung der obigen Richtlinien kann die Agenten-Ergebnisse verbessern. Wenn Kund:innen nun den Agenten um eine Profiländerung bitten, versteht der Agent, dass er die erforderliche Richtlinie aus der Knowledge Base abrufen, die abgerufenen Regeln interpretieren, diese Regeln auf den Kontext anwenden und schließlich dem Kunden antworten muss. Im Gegensatz zum „Overscripting“ ist dieser Verhaltensansatz viel allgemeiner und breiter anwendbar. Ohne jede mögliche Unterhaltung ausformulieren zu müssen, kann der Agent nun flexibel mit dem gewünschten Verhalten auf ein breiteres Spektrum an Unterhaltungsthemen reagieren.

Aktionssequenz erzwingen (gilt nicht für Agentenskript)

Der Beobachtungs-Prompt enthält Anweisungen und Beschreibungen der Aktionen, jedoch ohne festgelegte Reihenfolge. Wenn die Reihenfolge der Aktionen entscheidend ist, muss dies in derselben Anweisung ausdrücklich angegeben werden. Beachten Sie, dass wir mit Agentenskript dank Übergängen eine Reihenfolge der Ausführungen erzwingen können. Dies wird im sechsten Kapitel näher erläutert.

Fahren wir mit dem Beispiel von Agenten auf Recruiting-Websites fort. Der Agent sollte in der Lage sein, die Planung von Vorstellungsgesprächen mit der entsprechenden Person, die das Vorstellungsgespräch führt, zu übernehmen. Dazu sollte der Agent zunächst die Verfügbarkeit der Personalverantwortlichen prüfen und den Bewerber:innen dann drei mögliche Termine vorschlagen.

In diesem Fall sollten die Anweisungen, um die Reihenfolge der Ausführung beizubehalten, nicht in separaten Feldern stehen:

1. Anweisung 1: Überprüfe die Verfügbarkeit der Personalverantwortlichen für das Vorstellungsgespräch.
2. Anweisung 2: Schlage den Bewerber:innen dann geeignete Termine vor.

Diese Anweisungen funktionieren nicht, da die Inferenzmaschine nicht weiß, worauf sich die Aussage „Dann“ in Anweisung 2 bezieht. Das liegt daran, dass die Anweisungen als Gruppe und nicht in einer bestimmten Reihenfolge an die Inferenzmaschine gesendet werden.

Stattdessen sollten sequenzdefinierende Anweisungen zu einer einzigen Anweisung zusammengefasst und wie folgt geschrieben werden:

1. Anweisung 1: Überprüfe die Verfügbarkeit der Personalverantwortlichen für das Vorstellungsgespräch. Schlage den Bewerber:innen dann geeignete Termine vor.

Ausgabe von Aktionen ohne Neuschreiben erzwingen

Die Inferenzmaschine ist selbst ein LLM. Sie ist dafür verantwortlich, die endgültige Antwort gemäß der Agenten-basierten Schleife zu generieren. Dieser Ansatz ist erforderlich, um Anweisungen des Agenten durchzusetzen, die Leitplanken für die Generierung von Antworten bieten, oder um die Ergebnisse mehrerer Aktionen, die Teil der Agenten-basierten Schleife waren, zu kombinieren, um die Benutzeranforderung zu erfüllen.

Wenn jedoch davon ausgegangen wird, dass nur eine Prompt-Aktion ausgeführt wurde, kann eine Anweisung implementiert werden, die den Agenten anweist, die Ausgabe einer Aktion niemals zu ändern. Dadurch wird ein vorhersehbareres und zuverlässigeres Verhalten der Agenten gewährleistet.

Die strikte Einhaltung dieser Vorgaben in genehmigten Prompt-Vorlagen ist in bestimmten Szenarien von entscheidender Bedeutung, insbesondere wenn Konsistenz, Compliance und vordefinierte Nachrichten wichtig sind. Dies sind zwei Beispiele:

• Regulierte Branchen: Unternehmen, die in stark regulierten Branchen (wie Finanzen, Gesundheitswesen oder Rechtswesen) tätig sind, benötigen oft eine strenge Kontrolle über die gesamte Kommunikation mit Kund:innen. Genehmigte Eingabeaufforderungsvorlagen stellen sicher, dass die Antworten den gesetzlichen und regulatorischen Anforderungen entsprechen, wodurch das Risiko von Fehlinterpretationen, Haftungsansprüchen oder der Verbreitung unrichtiger Informationen minimiert wird.
• Vorab getestete und validierte Antworten: Wenn Eingabeaufforderungsvorlagen strengen Tests und Validierungen unterzogen wurden, um Genauigkeit, Wirksamkeit und die gewünschten Ergebnisse sicherzustellen. Abweichungen von diesen Vorlagen können deren Wirksamkeit und Wert beeinträchtigen. Die strikte Einhaltung garantiert, dass die bewährten Botschaften konsistent vermittelt werden.

Diese Anweisung schränkt die Freiheit des Agenten ein, das Ergebnis von Aktionen zu ändern. Stellen Sie sicher, dass die Anweisung auf die Ausgabe der Eingabeaufforderungsvorlage (z. B. „promptResponse“) verweist, wie in diesem Plan Tracer gezeigt.

In diesem Fall kann die Anweisung also lauten:

„ Ausgabe von promptResponse nicht ändern, unabhängig vom Kanal des Agenten. “

Einschränkungen bei der Durchsetzung strikter Einhaltung:

Wenn eine Interaktion mehrere unterschiedliche Aktionen des Agenten erfordert, ist die strikte Einhaltung einer einzigen Vorlage nicht durchführbar. In diesem Szenario muss die Inferenzmaschine diese Aktionen zu einer einzigen Antwort zusammenfassen und daher jede einzelne Aktion ändern.

Optimale Anzahl von Anweisungen

Basierend auf den allgemeinen LLM-Eigenschaften liegt die Zielanzahl der Anweisungen zwischen 5 und 10, abhängig von der Komplexität der Anweisungen und der Interaktion zwischen den Anweisungen. Diese Eigenschaften der Anweisungen beeinflussen die Anzahl der Anweisungen, denen die Inferenzmaschine folgen kann:

• Klarheit und Spezifität: Klar definierte Regeln sind einfacher zu befolgen.
• Konflikte zwischen Regeln: Wenn Regeln einander widersprechen, ist zusätzliche Logik erforderlich, um sie zu lösen.
• Länge und Komplexität: Wenn jede Regel eine tiefe Inferenz erfordert, sollten Sie in Erwägung ziehen, sie in kleinere Anweisungen aufzuteilen.

Wenn eine Anweisung unbedingt befolgt werden muss, fügen Sie Begriffe hinzu, die deren Wichtigkeit widerspiegeln:

• Dringlichkeit und Wichtigkeit (sofort, dringend, kritisch, essentiell, obligatorisch)
• Autorität und Durchsetzung (erforderlich, obligatorisch, streng durchgesetzt)
• Konsequenzen und Warnungen (Verstöße führen zu, Nichteinhaltung führt zu, Nichteinhaltung kann zur Folge haben, es gelten strenge Strafen, Nulltoleranz)
• Klarheit und Direktheit (muss, verboten, verboten, nicht erlaubt, immer/nie)

Die Kontextbildung von Antworten anhand von Daten verbessert die Zuverlässigkeit und Vertrauenswürdigkeit von Agenten erheblich. Kontextbasierte Antworten beruhen auf Fakten und nicht auf Spekulationen oder veraltetem Wissen. Abruf-erweiterte Generierung (RAG) ist eine weit verbreitete Technik, die es einem Agenten ermöglicht, auf eine Wissensdatenbank zuzugreifen und diese zu nutzen, um genauere und kontextbezogenere Antworten zu formulieren. Basierend auf der Anfrage von Benutzenden ruft ein Agent mithilfe von RAG relevante Informationen aus geeigneten Datenquellen ab und ergänzt den Prompt mit diesen Informationen, bevor er ihn an das LLM übermittelt. Ein Agent, der RAG verwendet, zeichnet sich durch eine höhere Qualität, Genauigkeit und allgemeine Nützlichkeit der Agenteninteraktionen aus, was das Vertrauen und die Zufriedenheit der Benutzenden erhöht. Best Practices für RAG werden ausführlich in einem öffentlich zugänglichen Whitepaper mit dem Titel Agentforce und RAG: Best Practices für bessere Agenten beschrieben.

Knowledge und Anweisungen im Vergleich

Die Unterscheidung zwischen Knowledge und Anweisungen ist wichtig, um das richtige Gleichgewicht zwischen Anleitung und Flexibilität zu finden, da sie unterschiedliche Zwecke – Erfüllung – erfüllen:

• Knowledge: Stellen Sie sich Knowledge als eine Bibliothek mit Büchern vor, auf die der Agent bei der Generierung seiner Antworten Zugriff hat. Beispiele hierfür sind Dokumente, Wissensartikel und Whitepaper. Beachten Sie, dass diese Richtlinien und allgemeine Unternehmensregeln enthalten können. Knowledge kann sich auch auf Transaktionsdateien beziehen, wie E-Mails, Transkriptionen von Anrufen und sogar die Historie von (Agenten-)Unterhaltungen. Schließlich umfasst Knowledge auch Langtextfelder in strukturierten Daten. Knowledge wird dem Agenten in der Regel über Abruf-erweiterte Generierung (RAG) zur Verfügung gestellt.
• Anweisungen: Betrachten Sie Anweisungen als einen Mindestkatalog von Regeln, die dem Agenten verdeutlichen, wann er welche Aktion ausführen soll. Anweisungen können auch Leitplanken für die gesamte Unterhaltung setzen, wie beispielsweise den erforderlichen Tonfall. Oft können Anweisungen prägnanter und flexibler gestaltet werden, ohne Klarheit odes Intents zu beeinträchtigen. Anstatt ein starres Skript mit spezifischen Antworten für jedes mögliche Kund:innen-Szenario bereitzustellen, sollten Sie allgemeine Richtlinien und Grundsätze implementieren, die dem Agent helfen, in verschiedenen Situationen die richtigen Aktionen zu ergreifen.

Abruf-erweiterte Generierung (RAG)

Abruf-erweiterte Generierung (RAG) fungiert als intelligente Datenschicht für Knowledge. Agenten erhalten Zugriff auf Informationen in verschiedenen Formaten und relevante Textfragmente zur Beantwortung von Fragen. Mit Abruf-erweiterter Generierung (RAG) können Agenten genauere LLM-Antworten erhalten, ohne die LLM-Prompt mit überflüssigen Inhalten zu überladen oder ihr Kontextfenster zu überschreiten.

Zur Laufzeit führt die abruf-erweiterte Generierung (RAG) drei Schritte aus:

1. Abruf: Das KI-System durchsucht eine große Datenbank oder Knowledge, um relevante Informationen für den LLM-Prompt zu sammeln. Dies geschieht mithilfe der semantischen Suche, einer im Vergleich zur herkömmlichen keywordbasierten Suche ausgefeilteren Technik. Im Gegensatz zur Stichwortsuche, die exakte Begriffe abgleicht, versteht die semantische Suche die Bedeutung oder den Kontext hinter den Wörtern. Der Abruf ermittelt relevante Informationen auf der Grundlage von Konzepten oder Beziehungen zwischen Begriffen, anstatt nur nach exakten Wortübereinstimmungen zu suchen. Auch die Stichwortsuche kann bei diesem Abrufprozess eine Rolle spielen und die semantische Suche durch Stichwortabgleich für bestimmte Fachbegriffe oder Namen verstärken. Dieser Suchtyp wird als hybride Suche bezeichnet.
2. Erweiterung: Die abgerufenen Informationen werden dem Prompt hinzugefügt.
3. Generierung: Der LLM generiert dank des mit Abruf-erweitertem Knowledge angereicherten Prompts eine kontextbezogene und genauere Antwort.

In Agentforce kann die abruf-erweiterte Generierung (RAG) mit oder ohne Eingabeaufforderungsvorlage verwendet werden:

1. Prompt-basierte Abruf-erweiterte Generierung (RAG): Bei diesem Ansatz befinden sich die Anweisungen, die festlegen, wie die Antwort generiert werden soll, in den Prompt-Anweisungen in einer Eingabeaufforderungsvorlage. In diesem Fall hängt die Antwort vollständig davon ab, was das LLM generiert. Abgesehen von den Prompt-Anweisungen gibt es Möglichkeiten, die Antwort zu beeinflussen, beispielsweise über die LLM-Konfigurationseinstellungen in Einstein Studio, aber das Ergebnis ist dennoch nicht deterministisch.
2. Inferenzmaschine-basierte Abruf-erweiterte Generierung (RAG): Statt eine Eingabeaufforderungsvorlage zu verwenden, verwendet der Agent eine Aktion, die Chunks (über einen Flow oder eine Apex-Klasse) abruft und sie in einer Variablen speichert (siehe nächsten Abschnitt). Bei diesem Ansatz generiert die Infernzine-Maschine (anstelle des LLM) direkt Antworten, die durch Kontextbildung auf den abgerufenen Daten erfolgen. Die Anweisungen, die die Generierung von Antworten regeln, sind Agentenanweisungen und keine Eingabeaufforderungsvorlage. Die Variable, die den abgerufenen Inhalt enthält, kann weiterhin explizit als Eingabe an eine Aktion übergeben werden. Es kann auch an die Inferenzmaschine übergeben werden, indem ihr Standardzugriff auf den Inhalt der Variablen gewährt wird. Dieser Ansatz hat Vor- und Nachteile. Es besteht möglicherweise das Risiko, dass die Inferenzmaschine mit Inhalten und Verantwortung überlastet wird. Darüber hinaus sind die Parameter des Inferenzmaschinen-LLM im Gegensatz zu einem Prompt nicht konfigurierbar. Andererseits kann die Inferenzmaschine ihre Antwort sowohl anhand der abgerufenen Teile als auch anhand der Unterhaltung generieren.

Die empfohlene Methode ist Option 1. Sie reduziert die Anzahl der Aufgaben, die die Inferenzmaschine ausführen muss, und verbessert dadurch die Qualität ihrer Antworten. Im nächsten Abschnitt geht es um eine Ausnahme von dieser Regel, bei der der Inhalt während der gesamten Unterhaltung erhalten bleibt und daher explizit einer Aktion zugeordnet wird.

Best Practices für Abruf-erweiterte Generierung (RAG)

• Vermeiden von Anweisungsskripten für Abruf-erweiterte Generierung (RAG): Anstatt Anweisungen direkt mit bestimmten Artikeln für bestimmte Fragen zu verknüpfen, nutzen Sie die Intelligenz von Abruf-erweiterter Generierung (RAG), um dynamisch die relevanteste Datenquelle und das präziseste Textfragment zu finden. Der Abgleichprozess von RAG basiert auf einem umfassenden Verständnis der Frage und nicht nur auf einer exakten Zuordnung von Frage und Quelle.
• Unter-Agents konsolidieren: Gruppieren Sie verwandte Fragenkategorien unter einem einzigen Unter-Agent. Abruf-erweiterte Generierung (RAG) kann relevante Antworten anhand des Fragetyps selbst innerhalb eines breiteren Themenbereichs effektiv identifizieren. Beispielsweise können Produktprobleme wie Wartungs- und Akku-Probleme zu einem umfassenderen Unter-Agent zusammengefasst werden.
• Speichern der RAG-Ausgabe in einer Variablen: Wenn die Anzahl der Interaktionsgrenzen erreicht sein könnte, speichern Sie die RAG-Ausgabe in einer Variablen. Dadurch bleiben die Informationen für Kontrolle von Agenteninteraktionen über den Standardgrenzwert hinaus zugänglich. Ein Beispiel hierfür wird im nächsten Abschnitt aufgeführt.

Bestimmte Geschäftsprozesse erfordern eine noch vorhersehbarere Ausführung, z. B. das Erzwingen einer bestimmten Aktionssequenz oder Bedingungen für das Auslösen von Aktionen oder Unter-Agents.

Um dieses deterministische Verhalten zu erreichen, können Variablen verwendet werden. Variablen fungieren als strukturierte Form des kurzfristigen Agentengedächtnisses, das als Aktionseingaben oder -ausgaben dienen kann. Darüber hinaus kann der Zustand einer Variablen das Auslösen bestimmter Unter-Agents und Aktionen steuern.

Wege, wie Variablen die Determination unterstützen

Variablen können auf folgende Weise dazu beitragen, einen geführten Determinismus von Agenten zu erreichen:

1. Persistente dynamische Kontextbildung: Variablen ermöglichen es Agenten, ihr Verständnis der Welt kontinuierlich zu aktualisieren und gleichzeitig wichtige Informationen beizubehalten, die von nachfolgenden Interaktionen unberührt bleiben. Diese Methode stellt sicher, dass wichtige Informationen, bei denen es sich um unstrukturierte Daten handeln kann, die über RAG abgerufen werden, oder um strukturierte Daten wie Nutzerprofilinformationen, während der gesamten Unterhaltung unabhängig von deren Länge erhalten bleiben.
2. Ein-/Ausgaben für Aktionen: Variablen können sowohl als Eingabe als auch als Ausgabe für Aktionen verwendet werden. Die Aktion bezieht sich explizit auf Variablen, und die Ausführung der Aktion hängt nicht von der Inferenzmaschine für die Festlegung dieser Ein- und Ausgänge ab, was den Determinismus des Agenten erhöht.
3. Filterung: Variablen können verwendet werden, um die bedingte Ausführung von Aktionen oder Unter-Agents zu bestimmen. Variablen ermöglichen einen spezifischen Informationsfluss zwischen Aktionen und Determinismus bei der Ausführung von Aktionen. Diese Funktion ist besonders wichtig für Sicherheitsregeln, bei denen Aktionen nicht initiiert werden können, wenn bestimmte Eingabevariablen, wie z. B. E-Mail-Adressen, nicht überprüft wurden.

Variablentypen in Agentforce

Agentforce hat zwei Arten von Variablen:

• Kontextvariablen sind vom System generierte Variablen, die Informationen über die Nutzer:innen und die Unterhaltungen enthalten.
• Benutzerdefinierte Variablen können von Nutzer:innen instanziiert werden. Sie enthalten jede Art von Informationen, die für eine der drei Möglichkeiten verwendet werden, wie Variablen den Determinismus unterstützen.

Variablentypen unterstützen die folgenden Funktionen:

Schauen wir uns die Variablen genauer an, indem wir ein Beispiel für einen Anwendungsfall geben: Einen Agenten für die Fehlerbehebung mit Kundenkontakt. In diesem Beispiel werden Variablen für alle drei Zwecke verwendet: persistente dynamische Kontextbildung, Aktionsein-/ausgaben und Filterung.

In diesem Beispiel hilft der Agent Kund:innen, ein technisches Geräteproblem zu beheben. Die Fehlerbehebung umfasst in der Regel mehrere Schritte. Der Agent sollte eine Service-Experience bieten, die die Arbeit von menschlichen Servicemitarbeiter:innen nachahmt. Dazu sollte der Agent den Kund:innen nicht alle Schritte zur Fehlerbehebung auf einmal bereitstellen. Stattdessen sollte er Schritt-für-Schritt-Anweisungen bieten, zusammen mit der Möglichkeit, zwischen den Schritten zu navigieren (einschließlich der Rückkehr zu zuvor behandelten Schritten), je nachdem, wie die Kund:innen reagieren.

Eine Herausforderung dabei ist die Fähigkeit des Agenten, alle Schritte zur Fehlerbehebung während der gesamten Unterhaltung im Gedächtnis zu behalten. Angesichts des begrenzten Speichers des Agenten aufgrund der begrenzten Anzahl von Interaktionen, die er speichern kann, können diese Schritte aus dem Kontext für die Inferenzmaschine entfernt werden, wenn die Unterhaltung zu lang wird.

Die Lösung für dieses Problem besteht darin, eine Variable zu verwenden, um die Inferenzmaschine dynamisch über alle Schritte der Fehlerbehebung hinweg zu Kontextbildung zu verwenden. Durch das Abrufen der Informationen und deren Speicherung in einer Variablen bleiben diese während der gesamten Unterhaltung verfügbar und können aktualisiert werden. Die Inferenzmaschine verwendet die in dieser Variablen gespeicherten Informationen für die dynamische Kontextbildung.

In diesem Beispiel enthält ein Unter-Agent zwei Aktionen. Diese beiden Aktionen sind erforderlich, um einen konsistenten Datenfluss aufrechtzuerhalten. Die erste Aktion wird verwendet, um die Variable zu füllen, die alle Schritte zur Fehlerbehebung enthält. Bei der zweiten Aktion wird diese Variable während der Fehlerbehebung selbst verwendet.

1. Aktion 1: „Problemlösungsschritte auffüllen“. Dies ist die erste Aktion, die durch die erste Einführung des Agenten in das Problem ausgelöst wird. Sie nutzt Abruf-erweiterte Generierung (RAG), um alle notwendigen Lösungsschritte aus einer indexierten Knowledge Base zu extrahieren. Die Aktion speichert die resultierende Ausgabe in einer Variablen namens „Lösungsschritte“.
2. Aktion 2: „Verwenden während der Lösung eines Problems“. Dies ist eine Aktion, die auf einem Prompt basiert, der den wahrscheinlichsten nächsten Schritt zur Fehlerbehebung ausgibt, der während des Fehlerbehebungsprozesses verwendet werden soll. Der Agent wird angewiesen, diese Aktion zu verwenden, während er gerade dabei ist, ein Problem zu lösen.

Die ursprüngliche Kundenfrage wird in beide Aktionen eingegeben. Die zweite Aktion hat einen weitere Eingabe: Den Inhalt der Variablen „Lösungsschritte“. Diese Variable wurde durch die erste Aktion festgelegt. Beachten Sie, dass die zweite Aktion die Schritte zur Fehlerbehebung nicht selbst abruft, sondern sie stattdessen als Eingabe aus der ersten Aktion über die Variable erhält. Das folgende Diagramm zeigt den Daten-Flow zwischen diesen beiden Aktionen.

Die Aktion „Während der Problemlösung verwenden“ bezieht sich immer auf die ursprünglichen Schritte zur Fehlerbehebung, die von der Aktion „Problemlösungsschritte“ abgerufen wurden. Dieser Daten-Flow stellt sicher, dass die Schritte zur Fehlerbehebung unabhängig von der Länge der Unterhaltung konsistent und stets verfügbar sind.

Um die in diesem Beispiel definierten Aktionen auszuführen, sind spezifische Anweisungen erforderlich, wie beispielsweise „Führe immer zuerst die ‚Schritte zum Ausfüllen der Lösung‘ aus“. Da die von Agenten verwendeten LLMS jedoch nicht deterministisch sind, kann dies in bestimmten Fällen zu einer anderen Reihenfolge führen. Um eine deterministische Ausführungsreihenfolge zu gewährleisten, führen wir bedingte Filter für diese Variablen ein, um die richtige Aktionsreihenfolge durchzusetzen. Der Agent liest den Wert der Variablen „Lösungsschritte“ und definiert zwei Filter, die darauf basieren, ob diese Variable einen Wert hat oder nicht.

• Die Aktion „Problemlösungsschritte“ kann nur ausgeführt werden, wenn die Variable „Lösungsschritte“ leer ist.
• „Während der Problemlösung verwenden“ kann nur ausgeführt werden, wenn die Variable „Lösungsschritte“ gefüllt ist.

Diese bedingten Filter erzwingen jetzt deterministisch die Reihenfolge der Ausführung von Aktionen: „Während der Problemlösung verwenden“ muss warten, bis „Lösungsschritte“ ihre Arbeit abgeschlossen hat, um sicherzustellen, dass die Variable „Lösungsschritte“ immer einen Wert hat.

Um die korrekte Ausführung der Aktion zu gewährleisten, ist eine dritte Aktion erforderlich, um die Variable „Lösungsschritte“ zurückzusetzen, wenn das Problem vollständig gelöst ist. Infolgedessen wird der Agent in den erforderlichen Status zurückgesetzt, um bei einem möglichen neuen, anderen Problem zu helfen. Diese dritte Aktion heißt „Lösungsvariable leeren“. Das vollständige Aktionsdiagramm ist unten dargestellt.

Variablen sind entscheidend, damit unser Agent zur Fehlerbehebung Kund:innenprobleme lösen kann, indem sie Folgendes ermöglichen:

• Persistente dynamische Kontextbildung: Variablen speichern Schritte zur Fehlerbehebung und stellen sicher, dass sie während der gesamten Unterhaltung verfügbar sind, unabhängig von der Länge oder Anzahl der Interaktionen. Dadurch wird verhindert, dass der Agent den Kontext vergisst.
• Daten-Flow: Variablen erleichtern den Daten-Flow zwischen Aktionen. Die Variable „Lösungsschritte“ speichert beispielsweise die abgerufenen Schritte zur Fehlerbehebung aus der Aktion „Problemlösungsschritte“ und stellt sie als Input für die Verwendung in der Mitte der Problemlösung bereit.
• Determinismus: Variablen können als Filter verwendet werden, um eine bestimmte Reihenfolge der Ausführung von Aktionen durchzusetzen. Beispielsweise wird die Aktion „Während der Problemlösung verwenden“ nur ausgeführt, wenn die Variable „Lösungsschritt“ gefüllt ist, um sicherzustellen, dass die Aktion „Problemlösungsschritte“ zuerst ausgeführt wird.

Im Zeitalter der generativen KI bleibt prädiktive KI von entscheidender Bedeutung, da sie die grundlegende Intelligenz bildet, die generative Fähigkeiten steuert, verbessert und kontextualisiert. Während der Schwerpunkt generativer KI auf dem Erstellen neuer Inhalte wie Texte, Bilder oder Videos liegt, treffen prädiktive Modelle Prognosen auf Grundlage von Echtzeit-Geschäftsdaten. Beispiele für Geschäftsergebnisse sind die Abwanderungswahrscheinlichkeit von Kunden, die Konversionswahrscheinlichkeit, die Wahrscheinlichkeit einer Eskalation von Kundenvorgängen, der Customer Lifetime Value und die Klassifizierung von Kundenvorgängen. Vorhersagen können dabei helfen, Benutzerbedürfnisse zu antizipieren, Ausgaben zu personalisieren, Entscheidungen zu treffen und die Relevanz von Inhalten in Echtzeit zu optimieren – alles durch die Analyse von Trends und Zahlen. In Anwendungen wie personalisiertem Lernen, Gesundheitswesen oder Finanzplanung beispielsweise sorgt prädiktive KI dafür, dass generative Ergebnisse mit individuellen Kontexten und wahrscheinlichen Zukunftsszenarien übereinstimmen. Prädiktive und generative KI bilden zusammen eine leistungsstarke Synergie, die Vorausschau mit Kreativität verbindet, um intelligentere, anpassungsfähigere und wirkungsvollere Technologielösungen voranzutreiben.

So integrieren Sie prädiktive Modellausgabe in Agenten-Workflows

Um die Ergebnisse des Vorhersagemodells in die Arbeitsabläufe der Agents zu integrieren, fügen Sie einfach Aktionen des Vorhersagemodells zu den Agentforce-Assets hinzu. Model Builder bietet die Möglichkeit, Vorhersagemodelle zu erstellen oder zu registrieren (BYO). Diese Modelle werden dann vom Agenten für Vorhersagen verwendet. Die daraus resultierenden Vorhersagen (sowie Prädiktoren) können in benutzerdefinierten Variablen gespeichert werden. Agents können diese Variablenwerte als Eingaben für bestimmte Aktionen und Unter-Agents verwenden und deren Ausführung konditionieren.

Beispiele für Anwendungsfälle, die in prädiktive Modelle integriert sind

• Segmentierung: Führen Sie eine Mehrklassenklassifizierung für die Segmentierung von Kund:innen durch und verwenden Sie das resultierende Segment, um bestimmte Aktionen zu filtern. Reservieren Sie beispielsweise Prämienaktionen für Premium-Kund:innen.
• Eskalationswahrscheinlichkeit: Prognostizieren Sie die Wahrscheinlichkeit einer Eskalation für einen Servicefall. Wenn diese Wahrscheinlichkeit einen bestimmten Schwellenwert überschreitet, lassen Sie die Ausführung von Aktionen zu, die den Fall schneller lösen, oder eskalieren Sie sie schneller an menschliche Agenten.
• CPG: Planen Sie eine Werbeaktion nur, wenn die Umsatzsteigerung (Punktzahl berechnet anhand eines Vorhersagemodells) einen bestimmten Schwellenwert überschreitet.
• Commerce: Schlagen Sie ein Produkt nur dann vor, wenn die Kaufneigung einen bestimmten Schwellenwert überschreitet.

Bestimmte Geschäftsprozesse müssen in einer genauen Reihenfolge ausgeführt werden und erfordern während der Ausführung keine Benutzereingabe. In diesem Fall kann ein vordefinierter Ablauf von Schritten über Flows, APIs oder Apex erzwungen werden. Wenn Sie einen bestehenden Flow haben, der in der Produktion verwendet wird, ist das ein guter Hinweis darauf, dass er vom Agenten für die Ausführung dieses Geschäftsprozesses beibehalten und verwendet werden kann. Alle folgenden Beispiele enthalten vordefinierte Abfolgen von Schritten, die der Agent ohne Benutzereingabe ausführen kann. Das agentenbasierte Verhalten besteht in diesem Fall darin, zu identifizieren, welcher deterministische Prozess ausgeführt werden soll, wie die erforderlichen Eingaben gesammelt und wie die Ausgaben interpretiert und verarbeitet werden.

Geschäftsprozesse mit vielen sequenziellen Schritten (mehr als drei, als Faustregel) und vielen Abhängigkeiten von Variablen werden zu komplex und umständlich, um sie mit Anweisungen durchzusetzen. In diesem Kundenvorgang ist es möglich, sie einfach mithilfe der in diesem Abschnitt aufgeführten deterministischen Aktion fest zu codieren. Beachten Sie abschließend, dass diese Implementierungen nicht deterministische Elemente enthalten können, z. B. das Aufrufen von LLMS mit aufgelösten Eingabeaufforderungsvorlagen. Daher sind sie nicht unbedingt vollständig deterministisch, End-to-End, und sie können immer noch das gewünschte Maß an Fließfähigkeit zeigen, für das Agenten bekannt sind.

Die Abfolge der Schritte in einer Marketing-Journey unterliegt festen Regeln und hängt nicht von den Eingaben der Nutzer:innen in der Unterhaltung ab. Daher kann der Flow als Agentforce-Aktion verwendet werden. Eine aufrufbare Aktion kann erstellt werden, um Hintergrund- oder ereignisausgelöste Aufgaben aus einer Lösungskomponente zu erledigen, die einen Flow oder eine Apex-Klasse aufrufen kann. Fügen Sie einer Flow- oder Apex-Klasse eine aufrufbare Aktion hinzu und geben Sie die Aufgabe an, die der Agent abschließt, sowie die Bedingungen, die den Agent auslösen. Aufrufbare Aktionen können auch die Kontextvariablen des Agenten tragen und wichtige Informationen weiterleiten.

Salesforce-Flows können verwendet werden, um Routineaufgaben zu automatisieren, z. B. das Erstellen von Folgeaufgaben, das Versenden von Erinnerungs-E-Mails oder das Aktualisieren von Datensätzen. Flows machen die Arbeit effizienter und produktiver. Agents können Flows auch mithilfe von Flow-Aktionen ausführen. Aufgrund ihres Determinismus sind Flows eine gute Möglichkeit, agentengesteuertes Verhalten zu kontrollieren, wenn ein Geschäftsprozess in einer bestimmten Sequenz ausgeführt werden muss. Ein gutes Indiz dafür, dass ein Flow besser geeignet ist, besteht darin, dass das der Unter-Agent ansonsten Anweisungen wie „Tue zunächst dies, dann das und schließlich jenes“ enthalten würde. Die Durchsetzung von Sequenzen mit mehr als drei Schritten lässt sich über Anweisungen und Variablen nur schwer verwalten.

Flows können auch nicht deterministische Elemente enthalten, indem sie Prompts aufrufen. Ein Prompt-Knoten im Flow ruft eine Prompt-Vorlage auf und sammelt die Antwort, die an andere Elemente im Flow weitergeleitet werden kann. Diese weiteren Elemente können wiederum Prompt-Knoten sein, z. B. die vorherige Antwort zusammenfassen und so eine Kette von Prompts erstellen. Dies ist besonders nützlich, wenn die Regeln für die Prompt-Verkettung durch feste Elemente definiert sind und nicht von der Benutzereingabe abhängen. Ein Beispiel hierfür ist die agentenbasierte Abruf-erweiterte Generierung (RAG), bei der eine vordefinierte Abfolge von Abrufprogrammen oder Prompts in einem Flow auf bestimmte Datenquellen in einer bestimmten Reihenfolge zugreifen kann, beispielsweise indem zunächst Daten aus dem Länderdokument eines Benutzers abgerufen werden, bevor bei Bedarf andere Quellen konsultiert werden. Dieser Kettenmechanismus setzt eine zuverlässige und geordnete Extraktion relevanter Informationen durch.

Ähnlich wie Flows sind Apex- und API-Aktionen insofern deterministisch, als eine vordefinierte Sequenz von Aktionen codiert werden kann. Diese Aktionen können nicht deterministische Elemente enthalten, z. B. das Aufrufen von Eingabeaufforderungsvorlagen oder LLM-Aufrufen. In ihrer Definition führen sie diese Schritte jedoch deterministisch aus, was die agentenbasierte Variabilität reduziert, indem sie die Aktion zur richtigen Zeit aufrufen, den erforderlichen Input sammeln und den Output verarbeiten. Diese Verantwortlichkeiten müssen immer noch durch agentenbasierte Anweisungen geregelt werden, also sind sie nicht deterministisch. APEX- und API-Aktionen sind das Pro-Code-Äquivalent zu Flow-Aktionen.

Von probabilistischer zu deterministischer Inferenz

In den Determinismusebenen 1 bis 5 haben wir die Umgebung des Agent schrittweise strukturiert. Wir haben definiert, was er leisten kann (Ebene 1, Unter-Agents), dann festgelegt, wie er sich verhalten soll (Ebene 2, Anweisungen), wir haben ihn auf Fakten gestützt (Ebene 3, Daten), wir haben seinen Zustand verwaltet (Ebene 4, Variablen) und ihm eindeutige Tools gegeben (Ebene 5, deterministische Aktionen). Die zentrale Engine für die Entscheidungsfindung blieb jedoch grundsätzlich probabilistisch. Die Inferzmaschine entschied noch selbst, welches Tool ausgewählt oder welche Frage als nächstes gestellt werden sollte. Bei dieser Entscheidung haben wir uns vollständig auf das Large Language Model (LLM) verlassen.

Ebene 6, Agentenskript, verändert diese Architektur grundlegend. Diese Stufe ermöglicht die Hardcodierung des Inferenzprozesses selbst.

Mit Agentenskript gehen wir vom Promting des Modells zum Scripting des Agenten über. Das ist keine Rückkehr zu starren Chatbots der alten Schule. Vielmehr sprechen wir von hybrider Inferenz. Damit können Sie die kreative, kommunikative Leistungsfähigkeit des LLM zwischen Schichten unveränderlicher, deterministischer Logik einbetten. Sie definieren ausdrücklich den kritischen Pfad der Ausführung (die „unbedingt erforderlichen Schritte“) und lassen dem LLM gleichzeitig bestimmte Freiräume, um das Verständnis natürlicher Sprache und die Generierung von Antworten zu übernehmen.

Beim Design von Workflows kommt es darauf an, zu vermeiden, dass LLM-basierte Agenten Skripte verwenden, nur um deterministische Logik zu ersetzen, bei der die nächsten Schritte bereits klar und festgelegt sind. Wenn ein Prozess einem vorhersehbaren Ablauf folgt, ohne dass komplexe Inferenzen zur Entschlüsselung nachfolgender Aktionen erforderlich sind, entstehen durch die Einführung eines generativen Modells unnötige Latenzzeiten, Kosten und Fehlerquellen. Für rein deterministische Prozesse, die keine Inferenzen benötigen, sind klassische Programmabläufe nach wie vor überlegen. Die Verwendung eines LLM für einfache Weiterleitungen oder lineare Übergänge ist eine überdimensionierte Lösung, die die Zuverlässigkeit eines Systems beeinträchtigt, das auch mit einem standardmäßigen Flow verwaltet werden könnte.

Als Faustregel gilt, dass agentengesteuerte Lösungen in Betracht gezogen werden sollten, wenn das System mit unstrukturierten Eingaben arbeitet, die aus unterschiedlichen, stark variierenden Quellen (möglicherweise einschließlich Eingaben aus der Unterhaltung) synthetisiert werden müssen, bevor eine Entscheidung getroffen werden kann.

Aber wie erreichen Sie dieses Maß an Kontrolle? Es gibt zwei unterschiedliche Wege, die sowohl für Business-Architekt:innen als auch für professionelle Entwickler:innen konzipiert sind.

Um den Determinismus der Ebene 6 in Ihren Agenten zu integrieren, ist es nicht zwingend erforderlich, Code zu schreiben. Salesforce bietet zwei Möglichkeiten zur Erstellung des zugrunde liegenden Agentenskripts und demokratisiert damit den Zugang zu deterministischen Inferenzen.

Für Geschäftsanalyst:innen, Administrator:innen und Low-Code-Anwender:innen ist Ebene 6 direkt im Agent Builder zugänglich.

Wir haben einen dokumentähnlichen Zeichenbereich eingeführt, die als Schnittstelle zwischen Text und Skript dient. Anstatt Code zu schreiben, formulieren Sie die Logik des Unter-Agents in strukturierter, natürlicher Sprache. Der Builder interpretiert dann Ihren Intent und kompiliert ihn im Hintergrund in Agentenskript.

• Sie schreiben: „Prüfe zunächst, ob die Bestellung älter als 30 Tage ist. Falls ja, informiere den:die Nutzer:in, dass wir keine Rücksendungen akzeptieren können, und beende die Unterhaltung höflich. Wenn nicht, frage nach dem Zustand des Artikels.“
• Das System kompiliert diese Beschreibung in natürlicher Sprache automatisch in die erforderlichen if/else-Strukturen, Variablenprüfungen und end_conversation-Befehle.

Auf diese Weise können Sie die Logik in natürlicher Sprache schreiben und von der Plattform in Code umwandeln lassen, sodass auch Nicht-Programmierer:innen strenge Sicherheitsvorkehrungen und Determinismus durchsetzen können.

Entwickler:innen, die höchste Präzision erzielen möchten, können Agentenskript auch direkt im Agent Builder schreiben. Die Arbeitsfläche mit der Beschreibung in natürlicher Sprache kann umgedreht werden, um das zugrunde liegende Skript anzuzeigen, sodass Entwickler:innen das Skript nun direkt programmieren können. Dieser Ansatz ermöglicht sogar eine hybride Autorenerfahrung: Einige Anweisungen werden in natürlicher Sprache auf der Arbeitsfläche geschrieben, während andere direkt mithilfe von Code programmiert (oder bestehende Anweisungen geändert) werden. Wenn Sie zwischen diesen beiden Erfahrungen hin und her wechseln, werden Sie feststellen, dass die beiden Modalitäten stets perfekt aufeinander abgestimmt sind.

Beide Modalitäten schöpfen das volle Potenzial von Ebene 6 aus:

• Detailliertes Tracing: Sie können die Skriptausführung schrittweise durchlaufen, um genau zu sehen, wo Variablen geändert oder Verzweigungen vorgenommen wurden.
• Komplexe Schleifenbehandlung: Verwalten Sie ausgefeilte Wiederholungslogik oder Multi-variable Zustandsänderungen, die schwer in natürlicher Sprache zu beschreiben sind.
• Versionskontrolle: Behandeln Sie das Agentenverhalten als Code, der mit Git- und CI/CD-Pipelines für die Agentenversionierung kompatibel ist.

Unabhängig davon, ob Sie das Agentenskript über den Builder generieren oder manuell schreiben, ist das Ergebnis identisch: Agentskript wird in einen Agentengraphen umgewandelt, der von der Atlas-Inferenzmaschine ausgeführt wird.

Um Ebene 6 zu meistern, ist es erforderlich, die zugrunde liegenden Mechanismen zu verstehen. Agentenskript steuert das Verhalten durch spezifische programmatische Strukturen innerhalb von Reasoning-Blöcken. Im Gegensatz zu Standard-Prompts, die Vorschläge für das LLM darstellen, handelt es sich hierbei um Befehle, die unter allen Umständen ausgeführt werden. Dies kann entweder vor, während oder nach der Inferenz geschehen, wobei es verschiedene Arten von Determinismus gibt. Zunächst betrachten wir einige dieser Muster aus allgemeiner Sicht und geben einige einfache Beispiele. Anschließend veranschaulichen wir sie anhand von Beispielen für Architekturentwürfe von skriptgesteuerten Agenten.

Auf den Ebenen 1 bis 5 haben wir gehofft, dass der Agent vor oder nach einem bestimmten Schritt im Prozess etwas unternimmt (eine Aktion ausführt). In Ebene 6 erzwingen wir dies. Alles, was in den Blöcken „before_reasoning“ und „after_reasoning“ geschrieben steht, wird immer vor bzw. nach dem Aufruf des LLM ausgeführt, damit die Inferenz auf der Grundlage der Anweisungen erfolgt. Dies kann das Ausführen anderer Aktionen, das Wechseln zu Unter-Agents, das Festlegen von Variablen usw. umfassen.

Durch die Verwendung des Befehls „run“ innerhalb der Anweisungen „before_reasoning“ eines Unter-Agent können Sie beispielsweise eine Aktion ausführen, noch bevor das LLM aufgerufen wird, um eine Antwort zu generieren. Dadurch wird sichergestellt, dass die Daten sofort verfügbar sind, wodurch Verzögerungen bei der Inferenz oder das Risiko, dass der Agent vergisst, das Tool aufzurufen, vermieden werden.

Die Skriptstruktur:

Mit bedingtem Determinismus lässt sich der Flows mithilfe von Standard-Programmierlogik steuern. Dies ist entscheidend für Compliance-Workflows, bei denen Schritte nicht übersprungen oder neu konzipiert werden können.

Die Skriptstruktur:

In diesem Beispiel erhält das LLM nie die Option, eine Genehmigung für Nicht-VIP-Nutzer:innen zu halluzinieren. Die Verzweigung wird von der Engine deterministisch ausgeführt.

Eine weitere leistungsstarke Kontrollfunktion ist die Möglichkeit, den Agent aus dem aktuellen Unter-Agent in ein anderes zu verschieben. Dadurch wird verhindert, dass der Agent in einer nicht relevanten Unterhaltung feststeckt oder abschweift.

Die Skriptstruktur:

Dieser Übergang ist kein bloßer Vorschlag. Es handelt sich um eine harte Umleitung des Ausführungsflows, die vom Wert einer Variablen abhängt. Beachten Sie, dass die Umleitung zwar hart und unumstößlich ist, innerhalb des Unter-Agents, zu dem der Agent nun gezwungen wird, jedoch wieder eine normale Inferenz stattfindet.

Darüber hinaus können Sie mit Agentenskript direkt nach Abschluss explizit einen Übergang von einer Aktion zur nächsten erzwingen. Diese Funktion stellt sicher, dass der Agent einem starren, deterministischen Flow folgt, anstatt sich bei jedem Schritt auf probabilistische oder autonome Entscheidungsfindung zu verlassen. Durch das Verketten dieser Aktionen in einer vordefinierten Sequenz können Sie sicherstellen, dass bestimmte Aufgaben in einer genauen Reihenfolge ausgeführt werden, sodass Sie die vollständige Kontrolle über die Logik und das Verhalten des Agenten erhalten.

Agentenskript gibt Ihnen direkten Lese-/Schreibzugriff auf das Kurzzeitgedächtnis (Variablen) des Agenten. Sie können Variablen explizit auf der Grundlage von Aktionsausgaben festlegen und so ein Stille-Post-Spiel verhindern, bei dem ein LLM die JSON-Ausgabe eines Tools falsch interpretieren könnte.

Die Skriptstruktur:

Wenn wir die Leistungsfähigkeit von Agentenskript vollständig verstehen wollen, dürfen wir nicht nur einzelne Befehle betrachten, sondern müssen sie in ihrem Zusammenspiel betrachten. Die folgenden Architekturmuster (abgeleitet aus unserer Sammlung von Agentenskriptvorlagen ) veranschaulichen, wie Determinismus der Ebene 6 komplexe Herausforderungen in Unternehmen löst.

Das Problem: Standard-Agenten leiden häufig unter einer Inferenz-Latenz. Sie warten darauf, dass Nutzer:innen eine Frage stellen, denken dann darüber nach, welches Tool sie verwenden sollen, fragen möglicherweise sogar nach Informationen, die bereits abgerufen werden könnten, und rufen erst dann die Aktion auf. Dies führt dazu, dass die Erfahrung stockend und unzusammenhängend ist. Das Agentenskript: Determinismus vor der Inferenz.

Wir verwenden den Befehl „run“, um Daten einzuspeisen, bevor das LLM überhaupt aktiviert wird.

Beispiel: Der Notfall-Triage-Agent. cStellen Sie sich einen Agenten vor, der eine Meldung über einen Stromausfall bearbeitet. Anstatt die Nutzer:innen nach ihrer Adresse zu fragen und darauf zu warten, führt das Skript automatisch zu Beginn der Sitzung die Befehle get_current_location_by_IP und check_grid_status aus.

Das Ergebnis: Der Agent beginnt nicht mit „wie kann ich Ihnen helfen?“ Er beginnt mit: „Ich sehe, dass Sie aus dem nördlichen Sektor anrufen, wo ein Transformatorbrand bestätigt wurde. Ich habe Ihren Haushalt bereits in die Liste für die vorrangige Behebung aufgenommen. Verfügen Sie über ein Notstromaggregat?“

Die Logik:

Lange Prompts (bei denen dem Agenten alle Regeln auf einmal mitgeteilt werden) erhöhen die Wahrscheinlichkeit von Fehlern bei der Inferenz. Der Agent vergisst Regel A, weil er sich Regel Z ansieht.

Die Agentenskript-Lösung: Just-in-Time-Anweisungseinbringen mit bedingter Kontextbildung durch eine Kombination aus Abruf-erweiterter Generierung (RAG) und bedingter Logik. Dem Agenten werden nur die Regeln angezeigt, die zum exakten Zeitpunkt der Unterhaltung gelten.

Beispiel: Festlegung von Regeln für nicht berechtigte Angebote. Warum sollten Sie dem Agenten die Regeln für die Beantragung von Kreditaufstockungen mitteilen, wenn die Bonität der Kund:innen dies von vornherein nicht zulässt?

Die Logik:

Bedingte Kontextbildung bedeutet, die Möglichkeit von Fehlern zu beseitigen, indem ablenkende Informationen vollständig entfernt werden, wenn sie nicht benötigt werden.

Das Problem: Bei einer komplexen Unterhaltung (wie beispielsweise einem Hypothekenantrag, einem Vorstellungsgespräch oder einer technischen Fehlerbehebung) verfolgt der Agent eine Liste mit Fragen, die unbedingt beantwortet werden müssen, um alle erforderlichen Informationen von den Nutzer:innen zu erfassen. Allerdings schweifen die Nutzer:innen häufig vom Thema ab. Ein Standard-Agent könnte darauf eingehen und vergessen, auf diese unverzichtbaren Fragen zurückzukommen, wodurch die Bewerbung oder die Unterhaltung unvollständig bliebe.

Das Herzstück dieses Systems ist die zustandsbehaftete Navigation, die die Unterhaltung wie eine strenge Checkliste behandelt, die vollständig abgearbeitet werden muss, bevor ein Übergang stattfinden kann.

Durch zustandsbehaftete Navigation wechselt der Agent streng nach dem aktuellen variablen Zustand zwischen Themen oder bleibt innerhalb eines Unter-Agents, bis bestimmte Bedingungen erfüllt sind. Dadurch wird verhindert, dass der Agent unzulässige Wege einschlägt, selbst wenn ein Benutzer versucht, die Unterhaltung mit Nebensächlichkeiten zu unterbrechen. Wenn Nutzer:innen beispielsweise bei einem hochriskanten Hypothekenantrag nach den Öffnungszeiten der Filiale fragen, versucht der Agent nicht nur, beim Thema zu bleiben. Stattdessen erkennt das Skript die Abweichung und kann einen erzwungenen Übergang zu einem Konformitäts-Reset-Unter-Agent auslösen. Durch die Beschränkung des Agents auf einen bestimmten „Logikraum“ ist es ihm mathematisch unmöglich, nicht genehmigte Unter-Agents zu besprechen oder eine Sitzung zu verlassen, bis alle erforderlichen Variablen erfolgreich erfasst wurden.

Beispiel: Der Wartungsinspektor; ein Agent begleitet Techniker bei einer 10-Punkte-Sicherheitsüberprüfung eines Flugzeugtriebwerks. Der Techniker sagt: „Moment, ich habe auch einen Kratzer am Rumpf bemerkt.“

Das Verhalten:

1. Der Agent erfasst den Kratzer (natürliche Sprache).
2. Er protokolliert den Kratzer in einer Variablen (Zustandsverwaltung).
3. Er weigert sich, die Sitzung zu beenden oder den Unter-Agent zu wechseln, bis er bestätigt hat: „Ich habe den Kratzer am Rumpf zur Kenntnis genommen, aber wir können erst mit der Außeninspektion fortfahren, wenn Sie die Drehmomenteinstellung am Einlassventil bestätigt haben. Wie lautete die Einstellung?“

Die Logik:

Eine geführte Unterhaltung sollte jedoch über das bloße Abarbeiten einer Liste von Fragen hinausgehen. Andernfalls wäre der Agent eher ein „verkleidetes Formular”. Sein Hauptvorteil liegt in der intelligenten Triage: Anhand von ersten Fragen werden Nutzer:innen zum richtigen Formular oder Workflow geleitet.

Der Übergang von einem einfachen Skript zu einem robusten Agentenskript macht Sinn, wenn die Komplexität zunimmt. Anstatt nur zu fragen, beginnt der Agent zu handeln: Beispielsweise kann der Agent Schritte zur Fehlerbehebung aus der Dokumentation extrahieren, interne Richtlinien durchsuchen oder API-Aufrufe an externe Systeme ausführen, um Probleme in Echtzeit zu lösen.

Mit der Einführung von Agentenskript als Ebene 6 im Determinismus-Framework verfügen Sie nun über ein vollständiges Spektrum an Kontrollmöglichkeiten, von der offenen Kreativität eines Unter-Agent der Ebene 1 bis hin zur starren, codegesteuerten Logik eines Agentenskripts der Ebene 6.

Allerdings bedeutet der Besitz eines Hammers nicht, dass jedes Problem ein Nagel ist.

Der häufigste Fehler besteht darin, zu glauben, dass „mehr gleich besser“ sei und dass Agents mittlerweile in allen Belangen vollständig per Skript gesteuert werden müssten. Das ist nicht der Fall. Die wahre Kunst der Agent-Architektur und -gestaltung liegt darin, den Determinismus richtig zu dosieren, indem genau so viel Kontrolle angewendet wird, wie zur Gewährleistung der Sicherheit erforderlich ist, ohne dabei die Flexibilität im Dialog zu opfern, die den Wert der KI überhaupt erst ausmacht. Schreiben Sie Ihre Agents nicht so stark fest, dass sie zu bloßen Chatbots verkommen.

Dieses Kapitel bietet einen Rahmen für Entscheidungen, der Ihnen dabei hilft, zu bestimmen, wann Sie sich auf die angeleitete Autonomie der Ebenen 1 bis 5 verlassen und wann Sie die vorgegebene Präzision der Ebene 6 durchsetzen sollten. Dies sind keine strengen Vorgaben, sondern eher Faustregeln, die einen kontextuellen Rahmen bieten sollen, um über die verschiedenen Optionen und Ebenen des Determinismus nachzudenken.

Zur Vereinfachung der Entscheidung können wir die sechs Ebenen in zwei unterschiedliche strategische Bereiche unterteilen:

• Die Philosophie: „Vertrauen, aber verifizieren.“ Sie geben dem Agenten das Ziel, die Daten und die Werkzeuge (die deterministisch sein können, siehe Ebene 5), aber Sie überlassen es der Infernzmaschine, den besten Weg dorthin zu finden.
• Der Mechanismus: probabilistische Inferenz. Der Agent analysiert den Intent der Nutzer:innen und wählt dynamisch das für die jeweilige Aufgabe am besten geeignete Tool aus.
• Am besten geeignet für: Erkundung, allgemeine Fragen und Antworten, Aufgaben mit geringem Risiko, breite Service-Bereiche.

In folgenden Szenarien sollten Sie auf die standardmäßigen, probabilistischen Verhaltensweisen der Ebenen 1 bis 5 zurückgreifen:

1. Der richtige Weg ist nicht immer derselbe

In vielen Unterhaltungsszenarien stellt ein starrer, fest programmierter Pfad tatsächlich einen Nachteil dar, da der korrekte Gang der Unterhaltung variabel ist. Bei dynamischen Interaktionen wie Personal Shopping oder Urlaubsplanung gibt es keine einheitliche richtige Reihenfolge: Nutzer:innen können Preis, Lage oder Ausstattung in beliebiger Reihenfolge priorisieren. In diesen Kundenvorgängen führt die Verwendung eines zustandsbehafteten Skripts zu einer frustrierenden, roboterhaften Erfahrung. Daher ist es effektiver, sich auf Anweisungen zu stützen, um die Persönlichkeit und die Ziele des Agenten zu definieren, während die Nutzer:innen den Flow steuern können. Dieser Ansatz beschleunigt auch die Markteinführung erheblich, da die Erstellung komplexer Skripte der Ebene 6 mit verschachtelten Variablen und Verzweigungen für Aufgaben wie interne HR-FAQ-Agenten oft überdimensioniert ist. Durch die Kontextbildung des Agenten in Daten und Abruf-erweiterter Generierung (RAG) können Sie auf ein umfangreiches manuelles Skript verzichten und die Abruf-Engine die Unterhaltung dynamisch auf der Grundlage Ihrer vorhandenen Knowledge Base verarbeiten lassen.

2. Skalierung durch modularen Determinismus: Vermeidung von Wartungsproblemen

Wenn der Umfang Ihres Agenten ein enormes Ausmaß erreicht, beispielsweise die Bearbeitung von 500 verschiedenen IT-Supportanfragen mit jeweils eigenen Prozessen, besteht die größte Herausforderung nicht darin, ob Sie ein einziges deterministisches Agentenskript erstellen können, sondern ob Sie dies tun sollten. Der Versuch, jede mögliche Permutation von 500 Aufgaben in einem einzigen umfangreichen Agentenskript abzubilden, führt zu erheblichen Wartungsproblemen. Bei jeder Änderung einer Richtlinie oder jedem Hinzufügen eines neuen Schrittes zur Fehlerbehebung besteht das Risiko, dass ein umfangreiches, miteinander verbundenes Logikgefüge beschädigt wird.

Die Lösung besteht darin, sich von einem monolithischen Skript zu lösen und zu deterministischen Aktionen der Ebene 5 überzugehen. Anstatt die gesamte Unterhaltung zu skripten, erstellen Sie robuste, isolierte Flows für die wichtigsten, hochwertigen Aktionen, wie das Zurücksetzen von Passwörtern oder die Entsperrung von Konten. Anschließend ermöglichen Sie es der Infernzmaschine, als eine Art Traffic-Steuerung zu fungieren, die den Intent der Nutzer:innen anhand ihrer individuellen Formulierungen erkennt und sie zur entsprechenden deterministischen Aktion weiterleitet. Mit diesem Ansatz erhalten Sie das Beste aus beiden Welten: die Zuverlässigkeit eines Skripts für kritische Aufgaben und eine flexible, skalierbare Architektur, die nicht unter ihrem eigenen Gewicht zusammenbricht, wenn Ihre Aufgabenbibliothek wächst.

• Die Philosophie: „Was auch immer du tust und welche Inferenz du auch immer anstellst, tue genau das.“ Sie definieren den Pfad. Der Agent ist die Schnittstelle zum Ausführen Ihrer Logik. Sie zwingt die Kreativität des Agenten in eine Must-do-Logik.
• Der Mechanismus: deterministische Inferenz. Das „Gehirn“ folgt einem vorab kompilierten Diagramm; das LLM wird ausschließlich für Inferenz, das Verstehen natürlicher Sprache und die Generierung von Antworten verwendet, sofern das Skript dies zulässt.
• Am besten geeignet für: Konformität, Finanztransaktionen, Diagnosebäume, Workflows mit hohem Risiko, Konformität und stark regulierte Branchen.

Innerhalb der deterministischen Pfade, die Ebene 6 vorgibt, sind alle Optionen der Ebenen 1 bis 5 weiterhin verfügbar.

Sie sollten zu Agentenskript wechseln, wenn „meistens richtig“ nicht mehr ausreichend ist.

1. Die Must-Pass-Gates (Sicherheit und Authentifizierung)

Wenn Nutzer:innen um Geldüberweisung bitten, können Sie sich nicht darauf verlassen, dass das LLM wahrscheinlich um Authentifizierung bittet. Sie brauchen eine mathematische Garantie dafür, dass der Authentifizierungs-Flow vor dem Transaktions-Flow stattfindet.

• Die Agentenskript-Lösung: Verwenden Sie „run @actions.verify_identity“ innerhalb eines „before_reasoning“-Blocks oder ganz oben in Ihrem Skript, um die Konformität zu erzwingen, bevor das LLM ein einzelnes Token generiert.

2. Regulatorische Konformität

In Branchen wie dem Gesundheitswesen oder dem Finanzwesen müssen Agenten häufig einen Haftungsausschluss wortwörtlich vorlesen oder Fragen in einer gesetzlich vorgeschriebenen Reihenfolge stellen.

• Die Lösung für das Agentenskript: Der Offenlegung hart codieren.

3. Komplexe mehrstufige Abhängigkeiten und obligatorische Aktionssequenzen

Wenn Schritt B die Ausgabe von Schritt A erfordert und Schritt C von einer Berechnung aus Schritt B abhängt, ist es riskant, sich auf ein LLM zu verlassen, um diese Variablen über den Prompt-Kontext in einem Telefonspiel weiterzugeben. Darüber hinaus muss die Reihenfolge fest programmiert werden, wenn die Ausführung einer bestimmten Aktion nach einer anderen Aktion zwingend vorgeschrieben ist.

• Die Agentenskript-Lösungen: Verwenden Sie „set @variables.x = @outputs.y“, um Daten zwischen den Schritten explizit zu verknüpfen und eine perfekte Übereinstimmung zu gewährleisten. Verwenden Sie die Anweisungen „run“ und „@utils.transition“, um die Sequenz zu programmieren.

4. Abdriften von Unter-Agents verhindern

Bei der Fehlerbehebung in kritischen Situationen (z. B. „Mein Herzschrittmacher piept“) darf der Agent nicht abgelenkt werden, wenn Nutzer:innen plötzlich fragen: „Wie ist das Wetter?“

• Die Agentenskript-Lösung: Verwenden Sie @utils.transition, um die Nutzer:innen im Unter-Agent „Notfallprotokoll“ zu halten, bis das Problem behoben ist, und deaktivieren Sie dabei ausdrücklich die Möglichkeit zum Abschweifen.

Die ausgereiftesten Agentenarchitekturen entscheiden sich nicht für das eine oder das andere, sondern verwenden Ebene 6 als Gerüst und die Ebenen 1 bis 5 als „Muskulatur“. Das sich daraus ergebende Muster entspricht dem eines deterministischen Sandwichs. Sie können Agentenskript verwenden, um den kritischen Beginn und das Ende einer Unterhaltung zu verwalten, während Sie den Mittelteil für flexible Inferenz offen lassen.

• Schritt 1 (Ebene 6): Agentenskript erzwingt die Triage und Authentifizierung.
  • Ergebnis: Nutzer:innen werden sicher identifiziert und ihr Intent wird klassifiziert.
• Schritt 2 (Ebenen 1–5): Agentenskript übergibt an einen Standard-Unter-Agent.
  • Ergebnis: Der Agent nutzt standardmäßige Abruf-erweiterte Generierung (RAG) und Aktionen, Anweisungen und möglicherweise sogar Variablen, um das Problem der Nutzer:innen flexibel zu lösen.
• Schritt 3 (Ebene 6): Der Agent erkennt, dass das Problem gelöst wurde, und wechselt zurück zum Agentenskript für die Abschlussaktionen.
  • Ergebnis: Agentscript erzwingt die Erfassung von CSAT-Werten und die Verwendung konformer Formulierungen zur Verabschiedung.

Abschließende Empfehlung: Beginnen Sie mit den Ebenen 1–5, um Geschwindigkeit und Entdeckungen zu optimieren, und überprüfen Sie Ihre Protokolle. Wenn Sie feststellen, dass der Agent Schwierigkeiten mit der Konsistenz hat, eine Abfolge nicht einhält oder Parameter falsch interpretiert, sollten Sie diesen spezifischen Workflow selektiv mit Ebene 6 verstärken.

Agentscript ist das letzte Puzzleteil zur Verwirklichung des Determinismus bei Agenten. Damit wird berücksichtigt, dass KI probabilistisch ist, während das Geschäft deterministisch ist. Durch die Verwendung von Agentenskript (entweder über die Arbeitsfläche, die die Erstellung von Agenten in natürlicher Sprache unterstützt, oder in direktem Code) schränken Sie die Intelligenz Ihres Agenten nicht ein, sondern fokussieren sie. Sie schaffen ein System, in dem die Kunst der Unterhaltung und die Wissenschaft der Prozessausführung verschmelzen, um sicherzustellen, dass Ihre wichtigsten Workflows jedes Mal genau wie vorgesehen ablaufen.

Ebene 6 steht auch für die Erkenntnis, dass autonom nicht gleichbedeutend mit unkontrolliert ist.

Seit Jahren diskutiert die Branche über Regeln versus KI, wenn es um Entscheidungsfindung und Prozessoptimierung geht. Das Lager der Befürworter:innen strenger Regeln plädierte für Vorhersehbarkeit. Das KI-Lager führte Flexibilität ins Feld. Agentscript setzt einen Schlusspunkt unter diese Debatte, indem es nachweist, dass die korrekte Architektur nicht oder ist, sondern und.

Durch die Einführung von Agentenskript entwickeln Sie hybride Agenten: Systeme, die über die starre Struktur von Code und die Flexibilität eines LLM verfügen. Die Zukunft der Unternehmens-KI liegt nicht in größeren Modellen. Es geht um eine bessere Kontrolle. Mit Agentenskript liegt diese Kontrolle nun in Ihrer Hand.