Zur Navigation springen
KonfigurierenAgentenverhaltenVerfahren

Strukturierte Verfahren

Eine feste Abfolge typisierter Schritte, die Ihr Agent jedes Mal gleich ausführt

Übersicht

Ein strukturiertes Verfahren ist ein Verfahren, das eine feste Abfolge von Schritten ausführt. Ein freies Verfahren besteht aus Anweisungen in natürlicher Sprache, die der Agent interpretiert und an die Situation anpasst. Ein strukturiertes Verfahren ist eine geordnete Liste typisierter Schritte, die der Agent immer in dieser Reihenfolge ausführt, wenn das Verfahren zutrifft.

Verwenden Sie ein strukturiertes Verfahren, wenn bestimmte Schritte bei jedem Anruf gleich ablaufen müssen: etwa zur Überprüfung der Identität eines Anrufers, zur Eskalation eines Tickets oder zur Entgegennahme einer Zahlung. Sie erstellen es als kurze Liste von Schritten in einfacher Sprache.

Wie jedes Verfahren hat auch ein strukturiertes Verfahren einen Auslöser, der beschreibt, wann es gilt. Wenn eine Unterhaltung dem Auslöser entspricht, führt der Agent die Schritte des Verfahrens der Reihe nach aus und kehrt dann zur übrigen Unterhaltung zurück.

Editor für strukturierte Verfahren

Wann Sie ein strukturiertes Verfahren verwenden sollten

Verwenden Sie ein strukturiertes Verfahren, wenn bestimmte Schritte jedes Mal gleich ausgeführt werden müssen, Sie diese aber dennoch schnell als einfache Schritte erstellen möchten. Strukturierte Verfahren sind einfacher zu erstellen als ein Workflow, aber weniger ausdrucksstark. Einen Vergleich mit freien Verfahren, Workflows und dem System-Prompt finden Sie unter Wann Verfahren verwendet werden sollten.

Aufbau eines strukturierten Verfahrens

Ein strukturiertes Verfahren besteht aus drei Teilen: einem Namen, einem Auslöser und einer geordneten Liste von Schritten.

Name

Eine kurze Bezeichnung, die das Verfahren im Dashboard identifiziert. Der Name wird nie an das LLM gesendet und beeinflusst daher nicht das Verhalten des Agenten.

Auslöser

Eine Beschreibung in einfacher Sprache, wann der Agent dieses Verfahren ausführen soll, zum Beispiel Wenn der Nutzer die Erstattung einer Bestellung anfordert. Der Agent gleicht die Absicht des Nutzers mit dem Auslöser jedes Verfahrens ab und führt das passende aus. Deshalb sollten Auslöser konkret und eindeutig sein. Der Agent sieht nur den Text des Auslösers, nie den Namen oder die ID des Verfahrens. Ein Auslöser funktioniert wie bei jedem Verfahren. Weitere Informationen finden Sie unter Auslöser schreiben.

Lassen Sie den Auslöser leer, um das Verfahren zu einem Unterverfahren zu machen, das nur ausgeführt wird, wenn ein anderes Verfahren es aufruft.

Schritte

Der Verfahrensinhalt ist eine geordnete Liste typisierter Schritte. Es gibt mehrere Schritttypen, die Sie kombinieren, um die Aufgabe zu beschreiben.

SchrittFunktion
AskFragt den Nutzer nach Informationen und wartet. Fragt weiter, bis der Nutzer antwortet. Dies ist der einzige Schritt, der auf den Nutzer wartet.
TellLässt den Agenten etwas mit eigenen Worten vermitteln und fährt dann mit dem nächsten Schritt fort.
SayLässt den Agenten eine exakte Nachricht Wort für Wort sprechen und fährt dann mit dem nächsten Schritt fort. Ein Say-Schritt kann für jede vom Agenten unterstützte Sprache eine separat konfigurierte Übersetzung enthalten.
ToolRuft ein bestimmtes Tool auf. Sie können dem LLM in einfacher Sprache erklären, wie das Tool aufgerufen wird, oder Parameterwerte explizit festlegen, wenn maximale Deterministik erforderlich ist. Sie können auch Schritte definieren, die bei einem fehlgeschlagenen Tool-Aufruf ausgeführt werden.
IfWertet eine oder mehrere Bedingungen der Reihe nach aus und führt die Schritte der ersten Übereinstimmung aus. Ein optionales Else wird ausgeführt, wenn nichts zutrifft.
Sub-procedureFührt ein anderes strukturiertes Verfahren aus. Nach Abschluss seiner Schritte kehrt die Steuerung zum nächsten Schritt in diesem aufrufenden Verfahren zurück.
System toolFührt eine integrierte Systemaktion aus. Derzeit wird nur das Beenden des Anrufs unterstützt.
RetryFührt den Fehlerhandler eines Tool-Schritts einschließlich Tool-Aufruf bis zu dreimal erneut aus. Nur innerhalb des Fehlerhandlers eines Tool-Schritts verfügbar.

Menü für Schritttypen strukturierter Verfahren

Nicht jeder Schritt kann überall verwendet werden. Innerhalb eines If-Zweigs können Sie jeden Schritt außer einem weiteren If oder Retry verwenden. Innerhalb des Fehlerhandlers eines Tool-Schritts können Sie jeden Schritt außer If oder einem weiteren Tool verwenden.

API-Referenz für Schritte

Der content eines strukturierten Verfahrens ist ein JSON-kodiertes Dokument mit einem steps-Array. Jeder Schritt ist ein Objekt, das durch seinen type identifiziert wird. Der Auslöser ist ein separates Feld der obersten Ebene des Verfahrens und nicht Teil von content. API- und SDK-Payloads verwenden type: "deterministic" für das Verfahren selbst.

Ask

Ein Ask-Schritt weist den Agenten an, Informationen anzufordern und zu warten, bis der Nutzer eine passende Antwort gibt.

  • API-Typ: ask
  • instruction: Erforderlicher, nicht leerer String.
{
  "type": "ask",
  "instruction": "Ask the user for their order ID."
}

Tell

Ein Tell-Schritt weist den Agenten an, eine einzelne Nachricht mit eigenen Worten zu erzeugen. Er wartet nicht auf eine Nutzerantwort, bevor er fortfährt.

  • API-Typ: tell
  • instruction: Erforderlicher, nicht leerer String.
{
  "type": "tell",
  "instruction": "Explain that the refund normally takes five to ten business days."
}

Say

Ein Say-Schritt spricht den bereitgestellten Text genau wie geschrieben und fährt dann fort. Geben Sie message_translations an, um dem Agenten für jede weitere unterstützte Sprache eine exakte Nachricht zu geben, die nach Sprachcode gruppiert ist.

  • API-Typ: say
  • message: Erforderlicher, nicht leerer String.
  • message_translations: Optionales Objekt, das einen Sprachcode { "value": "..." } zuordnet.
{
  "type": "say",
  "message": "Your refund has been submitted.",
  "message_translations": {
    "es": { "value": "Su reembolso ha sido enviado." }
  }
}

If, else if und else

Ein If-Schritt enthält einen oder mehrere geordnete bedingte Zweige. Der erste passende Zweig wird ausgeführt. Das optionale fallback-Array ist der Else-Zweig.

  • API-Typ: branch
  • branches: Erforderliche, nicht leere Liste bedingter Zweige.
  • fallback: Optionale Liste von Else-Schritten.
  • Jeder Zweig benötigt eine condition und eine nicht leere steps-Liste.
{
  "type": "branch",
  "branches": [
    {
      "condition": {
        "type": "llm",
        "condition": "The user is on an annual plan."
      },
      "steps": [
        {
          "type": "say",
          "message": "Your annual plan is eligible for a prorated refund."
        }
      ]
    }
  ],
  "fallback": [
    {
      "type": "tell",
      "instruction": "Explain that the account's plan could not be determined."
    }
  ]
}

Dies verhält sich wie if/else-if/else:

  1. Bedingungen werden der Reihe nach ausgewertet.
  2. Der erste passende Zweig wird ausgeführt.
  3. Wenn keine Bedingung zutrifft, wird fallback ausgeführt.
  4. Nach Abschluss eines Zweigs kehrt das Verfahren zur Hauptsequenz zurück.

Das obige Beispiel verwendet eine Textbedingung, die das Modell in natürlicher Sprache auswertet. Bedingungen können auch Ausdrücke über dynamische Variablen sein:

{
  "type": "expression",
  "expression": {
    "type": "eq_operator",
    "left": {
      "type": "dynamic_variable",
      "name": "plan_tier"
    },
    "right": {
      "type": "string_literal",
      "value": "annual"
    }
  }
}

Eine Ausdrucksbedingung prüft dynamische Variablen, die durch Tool-Ergebnisse gefüllt oder beim Start der Unterhaltung festgelegt werden. Sie kann die letzte Antwort des Nutzers nicht lesen. Verwenden Sie eine Textbedingung, um nach dem Gesagten des Nutzers zu verzweigen.

Alle Zweige eines If-Schritts müssen denselben Bedingungstyp verwenden: entweder llm oder expression.

Tool

Ein Tool-Schritt ruft ein bestimmtes Tool auf.

  • API-Typ: tool_call
  • tool_id: Erforderliche, nicht leere Tool-ID. Das Tool muss mit dem Agenten verknüpft sein.
  • tool_name: Erforderlicher Tool-Name, der dem Tool entspricht.
  • instruction: Optionale Anweisung, die beschreibt, wie das Tool aufgerufen wird.
  • schema_overrides: Optionale feste Werte für die Parameter des Tools.
  • on_failure: Optionaler Fehlerhandler.
{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "instruction": "Look up the order using the order ID provided by the user."
}

Feste Parameterwerte

Verwenden Sie schema_overrides, wenn ein Parameter immer einen bestimmten Wert haben muss. Das Modell sieht keinen überschriebenen Parameter und wählt ihn auch nicht aus. Schlüssel sind Parameterpfade im Schema des Tools; jeder Wert benennt eine Quelle:

sourceFelderVerhalten
constantconstant_valueSendet immer den angegebenen Wert.
dynamic_variabledynamic_variableSendet den aktuellen Wert der benannten dynamischen Variable.
llmprompt (optional)Lässt das Modell den Wert wählen, mit optionaler Prompt-Überschreibung.
omitLässt den Parameter im Aufruf weg.
{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "update_ticket",
  "schema_overrides": {
    "request_body.status": { "source": "constant", "constant_value": "pending" },
    "request_body.ticket_id": { "source": "dynamic_variable", "dynamic_variable": "ticket_id" }
  }
}

Fehlerbehandlung

Ohne on_failure beendet ein fehlgeschlagener Tool-Aufruf die Unterhaltung. Fügen Sie stattdessen on_failure hinzu, um Wiederherstellungsschritte auszuführen.

  • fallback: Erforderliche, nicht leere Liste von Schritten, die bei einem Tool-Fehler ausgeführt werden.
  • branches: Für bedingte Fehlerbehandlung reserviert. Lassen Sie es leer.
{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "on_failure": {
    "branches": [],
    "fallback": [
      {
        "type": "tell",
        "instruction": "Explain that the order could not be retrieved and offer to connect the user with support."
      }
    ]
  }
}

Ein Fehlerhandler kann Ask-, Tell-, Say-, Sub-procedure-, System-tool- und Retry-Schritte enthalten. Er kann keine Tool- oder If-Schritte enthalten. Nach Ausführung des Handlers fährt das Verfahren mit dem Schritt nach dem Tool-Schritt fort.

Retry

Ein Retry-Schritt führt den Fehlerhandler, der ihn enthält, einschließlich des Tool-Aufrufs erneut aus. Jeder Versuch ruft das Tool erneut auf und führt, falls es wieder fehlschlägt, jeden Schritt im Handler erneut aus. Wenn die Versuche aufgebraucht sind, endet die Unterhaltung.

  • API-Typ: retry
  • max_retries: Optionale ganze Zahl von 1 bis 3. Standardmäßig 1.
  • Der Wert zählt Versuche nach dem ursprünglichen Tool-Aufruf.
  • Retry ist nur innerhalb von on_failure gültig.
  • Retry muss der letzte Schritt in seinem Fehlerhandler sein, da spätere Schritte nicht erreichbar wären.
{
  "type": "retry",
  "max_retries": 2
}

Sub-procedure

Ein Sub-procedure-Schritt führt ein anderes strukturiertes Verfahren aus. Nach Abschluss der Schritte dieses Verfahrens kehrt die Ausführung zum Schritt nach dem Sub-procedure-Schritt zurück.

  • API-Typ: sub_procedure
  • procedure_id: Erforderliche, nicht leere Verfahrens-ID.
  • Das Ziel muss beim selben Agenten vorhanden sein.
  • Das Ziel muss ein strukturiertes Verfahren sein.
  • Ein Verfahren kann sich nicht selbst aufrufen.
{
  "type": "sub_procedure",
  "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
}

System tool

Ein System-tool-Schritt führt eine integrierte Systemaktion aus.

  • API-Typ: system_tool
  • system_tool_name: Erforderlicher Name des System-Tools.
  • Derzeit wird nur end_call unterstützt. Weitere System-Tools können später hinzugefügt werden.
  • Da end_call abschließend ist, muss es der letzte Schritt in seiner enthaltenden Sequenz, seinem Zweig oder Fehlerhandler sein.
{
  "type": "system_tool",
  "system_tool_name": "end_call"
}

Validierungsregeln

Beim Veröffentlichen des Agenten oder Speichern des Agent-Entwurfs wird ein strukturiertes Verfahren abgelehnt, das gegen eine dieser Regeln verstößt. Der Fehler benennt den fehlerhaften Schritt anhand seines Pfads.

  • Zwei If-Schritte dürfen nicht direkt hintereinander stehen.
  • If-Schritte dürfen nicht verschachtelt werden.
  • Ein If-Schritt mit Ausdrucksbedingungen darf nicht direkt auf einen Ask-Schritt folgen.
  • Alle Bedingungen eines If-Schritts müssen denselben Typ haben: entweder llm oder expression.
  • Retry darf nur innerhalb von on_failure erscheinen und muss dort der letzte Schritt sein.
  • end_call muss der letzte Schritt in jeder Liste sein, in der es erscheint.
  • Das fallback eines Fehlerhandlers muss mindestens einen Schritt enthalten.
  • Ein Sub-procedure muss auf ein vorhandenes strukturiertes Verfahren beim selben Agenten zeigen und darf nicht auf sich selbst verweisen.
  • tool_id muss ein Tool des Agenten sein, tool_name muss übereinstimmen und schema_overrides muss dem Schema des Tools entsprechen.
  • Die steps-Liste, jede instruction und jede message dürfen nicht leer sein.

Informationen zum Umstrukturieren eines Verfahrens, das gegen eine dieser Regeln verstößt, finden Sie unter Best Practices.

Vollständiges API-Beispiel

Dieses Beispiel verarbeitet eine Bestellstornierung anhand des Versandstatus. Es legt einen Tool-Parameter fest, behandelt einen fehlgeschlagenen Tool-Aufruf, ruft ein weiteres strukturiertes Verfahren auf und beendet dann den Anruf.

{
  "steps": [
    {
      "type": "ask",
      "instruction": "Ask the user for their order ID."
    },
    {
      "type": "branch",
      "branches": [
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has already shipped."
          },
          "steps": [
            {
              "type": "tell",
              "instruction": "Explain that shipped orders must be returned before they can be refunded."
            }
          ]
        },
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has not shipped."
          },
          "steps": [
            {
              "type": "tool_call",
              "tool_id": "tool_abc123",
              "tool_name": "cancel_order",
              "instruction": "Cancel the order using the order ID provided by the user.",
              "schema_overrides": {
                "request_body.notify_customer": { "source": "constant", "constant_value": true }
              },
              "on_failure": {
                "branches": [],
                "fallback": [
                  {
                    "type": "tell",
                    "instruction": "Apologize that the cancellation did not go through and say you will try once more."
                  },
                  {
                    "type": "retry",
                    "max_retries": 1
                  }
                ]
              }
            }
          ]
        }
      ],
      "fallback": [
        {
          "type": "ask",
          "instruction": "Ask whether the order has already shipped."
        }
      ]
    },
    {
      "type": "sub_procedure",
      "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
    },
    {
      "type": "say",
      "message": "Thank you for contacting us. Goodbye.",
      "message_translations": {
        "es": { "value": "Gracias por contactarnos. Adiós." }
      }
    },
    {
      "type": "system_tool",
      "system_tool_name": "end_call"
    }
  ]
}

So wird ein strukturiertes Verfahren ausgeführt

Das Umwandeln der Schritte eines strukturierten Verfahrens in die Form, die der Agent ausführt, wird als Kompilieren bezeichnet. Die Plattform kompiliert jedes strukturierte Verfahren, wenn der Agent-Entwurf gespeichert oder der Agent veröffentlicht wird. Autoren kompilieren nie selbst etwas.

Wenn die Anfrage des Nutzers dem Auslöser eines Verfahrens entspricht, tritt die Plattform in das Verfahren ein und führt seine Schritte der Reihe nach aus. Innerhalb des strukturierten Verfahrens konzentriert sich der Agent auf jeden Schritt einzeln. Wenn er das Ende erreicht, gibt die Plattform die Steuerung an die übrige Unterhaltung zurück.

Workflow-Kanten können nicht mit einem strukturierten Verfahren verbunden werden. Verwenden Sie einen Sub-procedure-Schritt, um strukturierte Verfahren zu verketten. Die Plattform verwaltet den Einstieg durch einen passenden Auslöser und den Abschluss, einschließlich der Rückgabe der Steuerung an den Workflow-Knoten, an dem das Verfahren gestartet wurde.

Die folgenden Regeln beschreiben das Verhalten der Schritte zur Laufzeit.

Jeder Schritt außer Ask wird sofort ausgeführt, und die Steuerung geht innerhalb desselben Turns zum nächsten Schritt. Ein Tell- oder Say-Schritt übermittelt seine Nachricht und fährt fort. Es gibt außer Ask keinen Schritt, der die Unterhaltung pausiert, und keinen Schritt, der den aktuellen Turn beendet. Wenn Sie Eingaben des Nutzers benötigen, verwenden Sie einen Ask-Schritt. Wenn die Unterhaltung enden soll, verwenden Sie das System-Tool end_call.

Wenn der letzte Schritt abgeschlossen ist, endet das Verfahren und der Agent kehrt zur übrigen Unterhaltung zurück, während der Turn offen bleibt. Er kann also noch mehr sagen. Wenn ein Unterverfahren abgeschlossen ist, kehrt die Steuerung zum nächsten Schritt des Verfahrens zurück, das es aufgerufen hat.

Ein Tool-Schritt kann nicht nach einem Statuscode oder dem Antworttext verzweigen. Wenn das Tool erfolgreich ist, wird das Verfahren fortgesetzt. Wenn es fehlschlägt und der Schritt keinen Fehlerhandler hat, endet die Unterhaltung. Hat er einen, werden die Schritte des Handlers ausgeführt und das Verfahren fährt mit dem nächsten Schritt fort. Ein Retry im Handler führt das Tool erneut aus und bei einem weiteren Fehlschlag jeden Schritt im Handler, bis das Tool erfolgreich ist oder die Versuche aufgebraucht sind. Sind sie aufgebraucht, endet die Unterhaltung.

Bedingungen werden der Reihe nach ausgewertet, und die erste Übereinstimmung wird ausgeführt. Der Else-Zweig wird ausgeführt, wenn nichts zutrifft. Gibt es kein Else und trifft nichts zu, fährt das Verfahren mit dem Schritt nach dem If fort. Ein nicht behandelter Fall ist kein Fehler.

Keine Entscheidung innerhalb eines If-Zweigs wird von späteren Schritten gespeichert. Wenn etwas, das in einem Zweig gelernt wurde, später benötigt wird, speichern Sie es explizit mit einem Tool-Aufruf oder einer dynamischen Variable.

Nur Tool-Schritte können Tools aufrufen. Sie müssen einem Ask-, Tell- oder Say-Schritt nicht mitteilen, dass er keine Tools aufrufen soll; das kann er nicht.

Ein strukturiertes Verfahren verwalten

Öffnen Sie Ihren Agenten im Dashboard und wählen Sie dann Verfahren. Verwenden Sie +, um ein strukturiertes Verfahren zu erstellen. Fügen Sie einen Auslöser hinzu, wählen Sie für jeden Schritt einen Typ und veröffentlichen Sie die Änderungen am Agenten.

Das Dashboard validiert strukturierte Verfahren während der Bearbeitung. Wenn ein Verfahren gegen eine Validierungsregel verstößt, zeigt die Schaltfläche Veröffentlichen einen Fehlerstatus, der Tab Verfahren ein Fehler-Badge und die Vorschau kann erst gestartet werden, wenn das Verfahren korrigiert wurde. Wählen Sie die Fehleranzeige aus, um zu sehen, welches Verfahren und welcher Schritt betroffen ist.

Editor für strukturierte Verfahren mit der Schaltfläche „Veröffentlichen“ im Fehlerstatus und einem Badge „1 Fehler“

Dialog mit Validierungsdetails, der das fehlerhafte Verfahren und den Schritt auflistet, für den eine Nachricht erforderlich ist

Best Practices

Jeder Schritttyp erzwingt bereits sein eigenes Verhalten, daher müssen Sie es selten explizit beschreiben. Formulieren Sie die Absicht jedes Schritts und überlassen Sie dem Schritttyp den Rest. Die folgenden Hinweise decken die Fälle ab, die Sie korrekt umsetzen sollten.

Um eine strukturierte Prozedur zu testen, folgen Sie Eine Prozedur iterieren.

Schritttypen auswählen

Ein Ask-Schritt wartet auf eine Antwort. Wenn Sie mehrere Fragen in einer Anweisung bündeln, überspringt oder kombiniert der Agent häufig einige davon. Verwenden Sie einen Ask-Schritt pro Information.

Ein Tell-Schritt übermittelt seine Nachricht und fährt fort, ohne zu warten. Ein als Frage formulierter Tell-Schritt erhält nie eine Antwort. Wenn ein Schritt eine Antwort des Nutzers benötigt, ist es ein Ask-Schritt.

Ein Ask-Schritt fährt fort, sobald er eine passende Antwort erhalten hat. Wenn aus der Frage nicht klar hervorgeht, was als Antwort gilt, geben Sie dies in der Anweisung an, zum Beispiel _Fragen Sie nach der Bestell-ID; eine gültige ID hat acht Ziffern _.

Verwenden Sie einen Tell-Schritt, wenn der Agent die Nachricht selbst formulieren soll, und einen Say-Schritt, wenn die Formulierung wörtlich übernommen oder übersetzt werden muss. Beide übermitteln genau eine Nachricht, daher müssen Sie einem Schritt nicht mitteilen, dass er eine einzelne Nachricht senden soll.

Ask-, Tell- und Say-Schritte können keine Tools aufrufen. Keine Tools aufrufen in diese Schritte zu schreiben, fügt der Anweisung nur Rauschen hinzu, ohne das Verhalten zu ändern.

Die Prozedur strukturieren

Zwei If-Schritte können nicht direkt hintereinander platziert werden. Einen nicht zusammenhängenden Tell- oder Say-Schritt dazwischen einzufügen, um die Regel zu erfüllen, führt dazu, dass der Agent etwas sagt, was er nicht sagen sollte. Integrieren Sie stattdessen die zweite Entscheidung als zusätzliche Else-if-Zweige in das erste If oder verschieben Sie sie in eine Unterprozedur.

If-Schritte können nicht verschachtelt werden. Wenn eine Entscheidung von einer anderen abhängt, legen Sie die innere Entscheidung in eine eigene strukturierte Prozedur und rufen Sie sie mit einem Sub-procedure-Schritt aus dem Zweig auf, der sie benötigt.

Ein If-Schritt ohne Else fährt mit dem nächsten Schritt fort, wenn nichts zutrifft. Wenn der nicht übereinstimmende Fall sich anders verhalten soll, fügen Sie dafür einen Else-Zweig hinzu.

Entscheidungen innerhalb eines If-Zweigs werden danach nicht gespeichert. Wenn ein späterer Schritt von etwas abhängt, das in einem Zweig ermittelt wurde, speichern Sie es innerhalb des Zweigs mit einem Tool-Aufruf oder einer dynamischen Variable.

Ausdrucksbedingungen prüfen dynamische Variablen. Platzieren Sie einen If-Schritt, der sie verwendet, direkt nach dem Tool- Schritt, der diese Variablen setzt. Um anhand der Nutzeraussage zu verzweigen, verwenden Sie eine Textbedingung.

Wenn mehrere strukturierte Prozeduren dieselbe Sequenz teilen, etwa die Eskalation an einen Menschen, legen Sie sie in eine strukturierte Prozedur mit einem leeren Trigger und rufen Sie sie jeweils auf. Kopierte Sequenzen entwickeln sich mit der Zeit auseinander.

Mit Tools arbeiten

Ein Tool-Schritt ruft sein Tool immer auf. Eine in der Anweisung formulierte Bedingung wie diesen Schritt überspringen, wenn das Ticket bereits markiert ist kann den Aufruf nicht verhindern. Wenn der Aufruf nicht immer erfolgen soll, platzieren Sie die Bedingung in einem If-Schritt vor dem Tool-Schritt.

Wenn ein Parameter immer einen bestimmten Wert haben muss, legen Sie ihn mit einem constant-Override in schema_overrides fest. Eine Anweisung wie Status immer auf ausstehend setzen fordert das Modell zur Einhaltung auf; ein Override wird erzwungen und kann nicht übersprungen werden.

Ohne on_failure beendet jeder Tool-Fehler die Konversation. Fügen Sie eine Behandlung hinzu, die dem Nutzer mitteilt, was passiert ist, und den Vorgang wiederholt, eskaliert oder fortsetzt.

Ein Tool-Schritt führt nur das Tool aus; der Agent kann dabei nicht sprechen oder eine Entscheidung treffen. Um mit dem Nutzer zu sprechen oder anhand der Tool-Rückgabe zu verzweigen, fügen Sie dafür einen separaten Schritt vor oder nach dem Tool-Schritt ein.

Anweisungen schreiben

Die Prozedur steuert, was als Nächstes ausgeführt wird, und der Agent kennt spätere Schritte nicht, während er den aktuellen ausführt. Lassen Sie die Schrittfolge die Reihenfolge bestimmen.

Sätze in Schrittanweisungen wie dies ist die letzte Nachricht dieses Turns fordern den Agenten auf, eine Grenze durchzusetzen, die die Plattform nicht unterstützt. Verwenden Sie einen Ask-Schritt, um auf den Nutzer zu warten, oder das System-Tool end_call, um die Konversation zu beenden.

Tonalität, Formatierung, Verabschiedungen und Richtlinien zur Ablehnung gehören in den System Prompt. Eine Schrittanweisung sollte nur angeben, was für diesen Schritt spezifisch ist.

Prozeduren kombinieren

Die allgemeinen Hinweise zum Kombinieren von Prozeduren gelten auch für strukturierte Prozeduren. Siehe Prozeduren kombinieren auf der Seite zu Free-form-Prozeduren.

Ein Muster gilt speziell für die Kombination von Typen: Eine Free-form-Prozedur kann auf eine strukturierte Prozedur verweisen. Behalten Sie die offene Bearbeitung in einer Free-form-Prozedur bei und delegieren Sie die Teile, die jedes Mal gleich ablaufen müssen, wie Identitätsprüfung oder Eskalation, an eine strukturierte Prozedur.

Einschränkungen

  • If-Schritte können nicht verschachtelt werden, und zwei If-Schritte können nicht direkt hintereinander platziert werden.
  • Das einzige unterstützte System-Tool ist end_call.
  • Strukturierte Prozeduren können nicht auf Wissensdatenbankdokumente verweisen.
  • Es gibt keine Möglichkeit, den aktuellen Turn zu beenden, wenn eine Prozedur abgeschlossen ist; der Agent hält den Turn offen und spricht möglicherweise weiter.
  • Workflow-Kanten können nicht mit einer strukturierten Prozedur verbunden werden oder von ihr ausgehen. Verwenden Sie einen Sub-procedure-Schritt, um strukturierte Prozeduren zu verketten; Einstieg und Abschluss werden von der Plattform verwaltet.
  • Das Starten einer Prozedur erhöht die Latenz: Der Agent führt einen Tool-Aufruf aus, um sie zu starten, und durchläuft dann den generierten Workflow.

Unterstützung durch Modellanbieter

Strukturierte Prozeduren erzwingen interne Tool-Aufrufe, wenn eine Unterprozedur gestartet oder eine Prozedur abgeschlossen wird. Große Modellfamilien von OpenAI, Anthropic, Gemini und Grok unterstützen eine erzwungene Tool-Auswahl. Andere Modelle oder benutzerdefinierte Anbieter garantieren dies möglicherweise nicht, wodurch Übergänge zu Unterprozeduren oder der Abschluss von Prozeduren weniger zuverlässig sein können. Prüfen Sie die Unterstützung der erzwungenen Tool-Auswahl, wenn Sie einen anderen Modellanbieter verwenden.

Unter Prozeduren finden Sie Einschränkungen, die für alle Prozeduren gelten, einschließlich der Begrenzung der Inhaltsgröße und der Unterschiede zwischen strukturierten und Free-form-Prozeduren.