Einige Produkte und Funktionen werden derzeit umbenannt. Auch die Funktionen für generative Playbooks und Abläufe werden zu einer einzigen konsolidierten Console migriert. Weitere Informationen

Diese Seite wurde von der Cloud Translation API übersetzt.

Playbook-Tools

Mit Tools können Sie Playbooks mit externen Systemen verbinden. Diese Systeme können das Wissen von Playbooks erweitern und ihnen ermöglichen, komplexe Aufgaben effizient auszuführen.

Sie können integrierte Tools verwenden oder benutzerdefinierte Tools erstellen, die Ihren Anforderungen entsprechen.

Tool-Tests

Nachdem Sie ein Tool erstellt haben, können Sie mit der Tool-Testfunktion prüfen, ob es funktioniert. Klicken Sie beim Aufrufen eines Tools über dem Tool-Bereich auf die Schaltfläche Testen. Dadurch wird das Tool für die Eingabe im Simulator geöffnet. Geben Sie die Tool-Eingabe an und klicken Sie dann auf View Output (Ausgabe ansehen), um die korrekte Tool-Ausgabe zu überprüfen.

Sie können die Funktion zum Testen von Tools auch verwenden, wenn Sie einem Beispiel ein Tool hinzufügen.

Integrierte Tools

Integrierte Tools werden von Google gehostet. Sie können diese Tools in Agents aktivieren, ohne dass eine manuelle Konfiguration erforderlich ist.

Folgende integrierte Tools werden unterstützt:

Code Interpreter: Ein von Google entwickeltes Tool, das die Möglichkeit zur Codegenerierung und ‑ausführung bietet und es dem Nutzer ermöglicht, verschiedene Aufgaben auszuführen, darunter Datenanalyse, Datenvisualisierung, Textverarbeitung, Lösen von Gleichungen oder Optimierungsproblemen.

Ihr Agent ist darauf optimiert, zu bestimmen, wie und wann diese Tools aufgerufen werden sollen. Sie können jedoch zusätzliche Beispiele für Ihre Anwendungsfälle angeben.

Beispiele sollten ein Schema wie das folgende haben:

{
  "toolUse": {
    "tool": "projects/PROJECT_ID/locations/LOCATION_ID/agents/AGENT_ID/tools/df-code-interpreter-tool",
    "action": "generate_and_execute",
    "inputParameters": [
      {
        "name": "generate_and_execute input",
        "value": "4 + 4"
      }
    ],
    "outputParameters": [
      {
        "name": "generate_and_execute output",
        "value": {
          "output_files": [
            {
              "name": "",
              "contents": ""
            }
          ],
          "execution_result": "8",
          "execution_error": "",
          "generated_code": "GENERATED_CODE"
        }
      }
    ]
  }
}

OpenAPI-Tools

Ein Agent kann über ein OpenAPI-Tool eine Verbindung zu einer externen API herstellen, indem er das OpenAPI-Schema bereitstellt. Standardmäßig ruft der Agent die API in Ihrem Namen auf.

Mit der Testtool-Funktion auf der Tool-Seite können Sie prüfen, ob das Tool richtig eingerichtet ist. Diese Funktion ist auch in der Beispielansicht verfügbar, wenn Sie dem Beispiel einen Toolaufruf hinzufügen.

Alternativ können Sie OpenAPI-Tools clientseitig ausführen.

Beispielschema:

openapi: 3.0.0
info:
  title: Simple Pets API
  version: 1.0.0
servers:
  - url: 'https://api.pet-service-example.com/v1'
paths:
  /pets/{petId}:
    get:
      summary: Return a pet by ID.
      operationId: getPet
      parameters:
        - in: path
          name: petId
          required: true
          description: Pet id
          schema:
            type: integer
      responses:
        200:
          description: OK
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      parameters:
        - name: petName
          in: query
          required: false
          description: Pet name
          schema:
            type: string
        - name: label
          in: query
          description: Pet label
          style: form
          explode: true
          required: false
          schema:
            type: array
            items:
              type: string
        - name: X-OWNER
          in: header
          description: Optional pet owner provided in the HTTP header
          required: false
          schema:
            type: string
        - name: X-SESSION
          in: header
          description: Dialogflow session id
          required: false
          schema:
            $ref: "@dialogflow/sessionId"
      responses:
        '200':
          description: An array of pets
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Pet'
    post:
      summary: Create a new pet
      operationId: createPet
      requestBody:
        description: Pet to add to the store
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Pet'
      responses:
        '201':
          description: Pet created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Pet'
components:
  schemas:
    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        owner:
          type: string
        label:
          type: array
          items:
            type: string

Optional können Sie die interne Schemareferenz @dialogflow/sessionId als Parametertyp verwenden. Bei diesem Parameter-Schematyp wird die Dialogflow-Sitzungs-ID für die aktuelle Unterhaltung als Parameterwert angegeben. Beispiel:

- name: X-SESSION
   in: header
   description: Dialogflow session id
   required: false
   schema:
     $ref: "@dialogflow/sessionId"

Einschränkungen von OpenAPI-Tools

Es gelten folgende Einschränkungen:

Unterstützte Parametertypen sind path, query und header. Der Parametertyp cookie wird noch nicht unterstützt.
Parameter, die durch das OpenAPI-Schema definiert werden, unterstützen die folgenden Datentypen: string, number, integer, boolean, array. Der Typ object wird noch nicht unterstützt.
Derzeit können Sie im Beispiel-Editor der Console keine Abfrageparameter angeben.
Anfrage- und Antworttext müssen leer oder JSON sein.

Generierung von OpenAPI-Toolschemata

Wenn Sie ein Schema bereitstellen, können Sie die Schaltfläche Gemini verwenden verwenden, um Ihr Schema mit generativer KI zu erstellen. Sie können Folgendes angeben, um die Generierung zu steuern:

Eine URL der Anfrage
Eine HTTP-Methode (GET, POST usw.)
Beispieleingabe
Beispielausgabe:
Ein Text-Prompt, der das Tool beschreibt

Nachdem die Datei generiert wurde, können Sie sie nach Bedarf bearbeiten und manuell zusätzliche URLs und Methoden hinzufügen.

OpenAPI-Tool-API-Authentifizierung

Die folgenden Authentifizierungsoptionen werden beim Aufrufen einer externen API unterstützt:

Dialogflow-Dienst-Agent-Authentifizierung

Dialogflow kann mit dem Dialogflow-Dienst-Agent ein ID-Token generieren. Das Token wird dem HTTP-Autorisierungsheader hinzugefügt, wenn Dialogflow eine externe API aufruft.

Ein ID-Token kann für den Zugriff auf Cloud Run-Funktionen und Cloud Run-Dienste verwendet werden, nachdem Sie roles/cloudfunctions.invoker und roles/run.invoker für service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com gewährt haben. Wenn sich die Cloud Run-Funktionen und Cloud Run-Dienste im selben Ressourcenprojekt befinden, benötigen Sie keine zusätzliche IAM-Berechtigung, um sie aufzurufen.

Dienstkonto-Authentifizierung

Dienstkonten können verwendet werden, um Toolanfragen bei allen Google-APIs zu authentifizieren, die dies unterstützen.

Erstellen Sie ein Dienstkonto, falls noch nicht geschehen.

Da es sich bei Dienstkonten um Hauptkonten handelt, können Sie einem Dienstkonto Zugriff auf Ressourcen in Ihrem Projekt gewähren, indem Sie ihm eine Rolle zuweisen, wie Sie es auch für jedes andere Hauptkonto tun würden. Die E-Mail-Adresse des Dienstkontos wird verwendet, um ein Zugriffstoken zu generieren, das im Authorization-Header der Toolanfrage gesendet wird.

Der Nutzer, der das Tool für die Verwendung von Dienstkonten konfiguriert, muss die folgenden Berechtigungen haben:

roles/iam.serviceAccountUser

Damit Konversations-Agents (Dialogflow CX) Tokens generieren können, muss der Dialogflow-Dienst-Agent die folgenden Berechtigungen haben:

roles/iam.serviceAccountTokenCreator

Das Dienstkonto muss außerdem Berechtigungen für den Zugriff auf den Dienst haben, auf dem das Tool gehostet wird.

API-Schlüssel

Sie können die API-Schlüsselauthentifizierung konfigurieren, indem Sie den Schlüsselnamen, den Anforderungsspeicherort (Header oder Abfragestring) und den API-Schlüssel angeben, damit Dialogflow den API-Schlüssel in der Anfrage übergibt.
Wir empfehlen, den API-Schlüssel über Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine API-Schlüssel für Rohwerte mehr.

OAuth

Der OAuth-Vorgang für Clientanmeldedaten wird für die Server-zu-Server-Authentifizierung unterstützt:
- Dieser Ablauf kann verwendet werden, wenn die AI Applications Console der Ressourceninhaber ist und keine Endnutzerautorisierung erforderlich ist.
- Client-ID, Clientschlüssel und Token-Endpunkt des OAuth-Anbieters müssen in Dialogflow konfiguriert werden.
  - Wir empfehlen, das Client-Secret über Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine Clientschlüssel für Rohwerte mehr.
- Dialogflow tauscht ein OAuth-Zugriffstoken vom OAuth-Anbieter aus und übergibt es im Autorisierungsheader der Anfrage.
Für andere OAuth-Abläufe, die eine Endnutzerautorisierung erfordern, z. B. den Autorisierungscode-Ablauf und den PKCE-Ablauf:
1. Sie müssen eine eigene Anmelde-UI implementieren und das Zugriffstoken auf der Clientseite abrufen.
2. Sie haben dann die Wahl zwischen zwei Optionen:
  
  a. Verwenden Sie die Authentifizierungsoption „Inhabertoken“, um das Token an das OpenAPI-Tool zu übergeben. Dialogflow fügt dieses Token in den Autorisierungs-Header ein, wenn das Tool aufgerufen wird.
  
  b. Verwenden Sie das Funktionstool, um das Tool selbst auf Clientseite aufzurufen und das Ergebnis des Tool-Aufrufs an Dialogflow zu übergeben.

Inhabertoken

Sie können die Bearer-Authentifizierung so konfigurieren, dass das Bearer-Token dynamisch vom Client übergeben wird. Dieses Token ist im Auth-Header der Anfrage enthalten.
Beim Einrichten der Tool-Authentifizierung können Sie einen Sitzungsparameter als Bearer-Token festlegen. Verwenden Sie beispielsweise $session.params.<parameter-name-for-token>, um das Token anzugeben.

Weisen Sie zur Laufzeit das Bearer-Token dem Sitzungsparameter zu:

DetectIntentRequest {
  ...
  query_params {
    parameters {
      <parameter-name-for-token>: <the-auth-token>
    }
  }
  ...
}

Wenn Sie ein statisches Token konfigurieren müssen, anstatt das Token aus einem Sitzungsparameter abzurufen, empfehlen wir, das Token über Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine Bearer-Tokens für Rohwerte mehr.

Gegenseitige TLS-Authentifizierung

Weitere Informationen finden Sie in der Dokumentation zur gegenseitigen TLS-Authentifizierung.
Benutzerdefinierte Clientzertifikate werden unterstützt. Sie können Clientzertifikate auf Agent-Ebene auf dem Tab „Sicherheit“ in den Agent-Einstellungen einrichten. Das Zertifikat (PEM-Format) und der private Schlüssel (PEM-Format) sind Pflichtfelder. Sobald das Clientzertifikat festgelegt ist, wird es bei Mutual TLS für alle Tools und Webhooks verwendet.

Benutzerdefiniertes CA-Zertifikat

Weitere Informationen finden Sie in der Dokumentation zu benutzerdefinierten CA-Zertifikaten.

Secret Manager-Authentifizierung

Wenn Sie OAuth, API-Schlüssel oder Bearer-Tokens verwenden, können Sie die Anmeldedaten mit Secret Manager als Secrets speichern. So authentifizieren Sie Ihr Tool mithilfe von Secrets:

Erstellen Sie Ihr Secret, falls Sie noch keines haben.
Weisen Sie dem Dialogflow-Dienst-Agent die Rolle Zugriffsperson für Secret Manager-Secret (roles/secretmanager.secretAccessor) für das neue Secret zu.
Kopieren Sie die Anmeldedaten in die Zwischenablage.
Fügen Sie Ihrem Secret eine neue Secret-Version hinzu. Fügen Sie die Anmeldedaten als Secret-Wert ein.
- Lassen Sie am Ende alle Zeilenumbruchzeichen weg.
Kopieren Sie den Namen der Secret-Version, die Sie gerade hinzugefügt haben. Das Namensformat ist projects/{project_id}/secrets/{secret_id}/versions/{version_id}".
Öffnen Sie den Bearbeitungsbildschirm des Tools und gehen Sie dann so vor:
- Wenn Sie OAuth verwenden, wählen Sie OAuth als Authentifizierungstyp aus. Klicken Sie dann unter Clientschlüssel auf Secret-Version und fügen Sie den Namen der Secret-Version in das Eingabefeld Secret-Version ein.
- Wenn Sie einen API-Schlüssel verwenden, wählen Sie API-Schlüssel als Authentifizierungstyp aus und klicken Sie dann unter API-Schlüssel auf Secret-Version. Fügen Sie den Namen der Secret-Version in das Eingabefeld Secret-Version ein.
- Wenn Sie ein Bearer-Token verwenden, wählen Sie Bearer-Token als Authentifizierungstyp aus und klicken Sie dann unter Bearer-Token auf Secret-Version. Fügen Sie den Namen der Secret-Version in das Eingabefeld Secret-Version ein.
Klicken Sie auf Speichern.

Privater Netzwerkzugriff für OpenAPI-Tool

Das OpenAPI-Tool wird in privaten Service Directory-Zugriff eingebunden, sodass eine Verbindung zu API-Zielen in Ihrem VPC-Netzwerk hergestellt werden kann. Dadurch wird der Traffic innerhalb des Google Cloud-Netzwerks beibehalten und IAM sowie VPC Service Controls erzwungen.

So richten Sie ein OpenAPI-Tool ein, das auf ein privates Netzwerk ausgerichtet ist:

Folgen Sie der Anleitung unter Private Netzwerkkonfiguration für Service Directory, um Ihr VPC-Netzwerk und Ihren Service Directory-Endpunkt zu konfigurieren.
Das Dienstkonto Dialogflow-Dienst-Agent mit der folgenden Adresse muss für Ihr Agent-Projekt vorhanden sein:
```
service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
```
Gewähren Sie dem Dienstkonto Dialogflow-Dienst-Agent die folgenden IAM-Rollen:
- servicedirectory.viewer des Service Directory-Projekts
- servicedirectory.pscAuthorizedService des Netzwerkprojekts
Geben Sie beim Erstellen des Tools den Service Directory-Dienst mit dem OpenAPI-Schema und optionalen Authentifizierungsinformationen an.

Zugriff auf OpenAPI-Tool-Sitzungsparameter

Open API-Tool-Eingaben werden aus der Konversation des Nutzers mit dem LLM abgeleitet, wobei das Schema als Leitfaden dient. In einigen Fällen müssen Eingaben aus Sitzungsparametern abgeleitet werden, die während eines Ablaufs erfasst oder zusammen mit der Nutzereingabe als Abfrageparameter bereitgestellt werden.

Der Sitzungsparameter, der als Eingabe übergeben werden muss, kann so angegeben werden:

     parameters:
       - in: query
         name: petId
         required: true
         description: Pet id
         schema:
           type: integer
           x-agent-input-parameter: petId # Reads from the $session.params.petId
       - in: header
         name: X-other
         schema:
           type: string
           x-agent-input-parameter: $request.payload.header # Reads from the header specified in the request payload input
     requestBody:
       required: false
       content:
         application/json:
           schema:
             type: object
             properties:
               name:
                 type: string
                 x-agent-input-parameter: petName # Reads from the $session.params.petName
                 description: Name of the person to greet (optional).
               breed:
                 type: string
                 description: Bread of the pet.

Wenn kein solcher Sitzungsparameter verfügbar ist, wird die vom LLM generierte Eingabe an das Tool übergeben.

OpenAPI-Tool – Standardwerte

Mit dem Open API-Schema können Sie Standardwerte angeben. Die Standardwerte werden nur verwendet, wenn für diesen Parameter oder diese Eigenschaft kein LLM-generierter Eingabewert oder sitzungsparameterbasierter Eingabewert vorhanden ist.

Die Standardwerte können als Teil des Schemas so angegeben werden:

     parameters:
       - in: query
         name: zipcode
         required: true
         description: Zip code to search for
         schema:
           type: integer
           default: 94043
     requestBody:
       content:
         application/json:
           schema:
             type: object
             properties:
               breed:
                 type: string
                 description: Bread of the pet.
               page_size:
                 type: integer
                 description: Number of pets to return.
                 default: 10

Wenn kein LLM-generierter Wert, kein Sitzungsparameterwert und kein Standardwert vorhanden ist, ist die Eingabe nicht angegeben.

Datenspeichertools

Informationen zur Verwendung von Datenspeichertools mit einem Playbook finden Sie in der Dokumentation zu Datenspeichertools.

Connector-Tools

Connector-Tools können von einem Agent verwendet werden, um Aktionen mit Ihren in Integration Connectors konfigurierten Verbindungen auszuführen. Jedes Connector-Tool wird mit einer einzelnen Verbindung und einer oder mehreren Aktionen konfiguriert. Bei Bedarf können mehrere Tools für eine einzelne Verbindung erstellt werden, um verschiedene Aktionen zu gruppieren, die Ihr Agent verwenden soll.

Das Connector-Tool unterstützt die folgenden Connectors-Typen:

Beispiele sollten verwendet werden, um die Verwendung von Connector-Tools durch den Agent zu verbessern, indem gezeigt wird, wie der Agent das Tool aufrufen und die Antwort verwenden sollte.

Verbindung herstellen

Wenn Sie eine Verbindung erstellen und mit Ihrem Agent verbinden möchten, rufen Sie Tools > Erstellen auf, wählen Sie den Tooltyp Connector und den gewünschten Connectortyp aus und klicken Sie auf die Schaltfläche Verbindung erstellen. Sie werden zur Erstellung von Integration Connectors weitergeleitet, wobei eine Reihe von Feldern bereits ausgefüllt ist.

Alternativ können Sie zu Integration Connectors wechseln und der Anleitung zum Erstellen einer Verbindung folgen.

Connector-Aktionen

Für jedes Connector-Tool gibt es zwei Arten von Aktionen, die für Ihren Agent verfügbar gemacht werden können (weitere Informationen finden Sie unter Entitäten, Vorgänge und Aktionen):

CRUD-Vorgänge für Entitäten

Jede Ihrer Verbindungen hat „Entitäten“, die den Objekten dieser Datenquelle entsprechen (für BigQuery sind das Tabellen, für Salesforce Objekte wie „Order“ oder „Case“).

Sie können CRUD-Vorgänge für jede Entität ausführen:
- Erstellen: Erstellt eine Entität mit den angegebenen Feldwerten.
- Liste: Filterbasierte Suche nach Entitätsinstanzen
- Aktualisieren: Filterbasierte Methode zum Ändern von Attributfeldwerten
- Löschen: Löscht eine Entität
- Mit Get wird eine einzelne Entität mit der entityId
  abgerufen.
Hinweis: Der Get-Vorgang kann nur verwendet werden, um einen einzelnen Datensatz aus einer Entität mit einem Primärschlüssel abzurufen. Häufig ist es praktischer, den List-Vorgang mit einer filterClause zu verwenden, um eine Entität abzurufen.

Weitere Informationen zu CRUD-Vorgängen für Entitäten finden Sie in der Connectors-Dokumentation.
Connectorspezifische Aktionen

Viele Connectors unterstützen die Aktion 'ExecuteCustomQuery'. Damit kann eine SQL-Abfrage für die Datenquelle ausgeführt werden, wobei auf jede der Datenquellenentitäten als Tabellen verwiesen werden kann. Hier finden Sie eine Liste der unterstützten Connectors.

Zusätzliche Aktionen variieren je nach Connectortyp. Weitere Informationen finden Sie beispielsweise unter BigQuery-Connector-Aktionen oder Salesforce-Connector-Aktionen.

Eingabe-/Ausgabefelder für CRUD-Vorgänge konfigurieren

Wenn Sie bestimmte Ein- oder Ausgabefelder für die Connector-Tool-Aktion auswählen, die verwendet werden sollen, können Sie die Komplexität dieser Aktionen für den Agenten begrenzen.

Wenn Sie beispielsweise nur eine Entität mit einer Teilmenge ihrer Felder erstellen müssen, wird die Aktion für den Agent vereinfacht, wenn Sie diese Felder in der Aktion konfigurieren.

Wenn Sie eine Reihe von Ausgabefeldern angeben, wird die Größe der Tool-Antwort reduziert. Das ist hilfreich, wenn Tokenlimits ein Problem darstellen. Außerdem wird die Verarbeitung der Ausgabe durch den Agent vereinfacht, da nur die relevanten Felder verfügbar sind.

Authentifizierung

Wenn die von Ihnen verwendete Verbindung für die Überschreibung der Authentifizierung konfiguriert ist, kann das Tool so konfiguriert werden, dass Anmeldedaten aus angegebenen Sitzungsparametern übergeben werden.

Sie als Agent-Entwickler sind dafür verantwortlich, wie diese Anmeldedaten in die Sitzungsparameter eingefügt werden. Das Tool übergibt sie automatisch an die Datenquelle, die für die Authentifizierung verwendet werden soll, wenn die Aktionen des Tools aufgerufen werden.

Funktionstools

Wenn Sie Funktionen haben, auf die über Ihren Clientcode, aber nicht über OpenAPI-Tools zugegriffen werden kann, können Sie Funktionstools verwenden. Funktionstools werden immer clientseitig ausgeführt, nicht vom Agent.

So läuft der Vorgang ab:

Ihr Clientcode sendet eine Anfrage zur Intent-Erkennung.
Der Agent erkennt, dass ein Funktionstool erforderlich ist, und die Antwort für die Intent-Erkennung enthält den Namen des Tools sowie Eingabeargumente. Diese Sitzung wird pausiert, bis eine weitere Anfrage zur Intent-Erkennung mit dem Tool-Ergebnis eingeht.
Ihr Clientcode ruft das Tool auf.
Ihr Clientcode sendet eine weitere Anfrage zur Intent-Erkennung, in der das Tool-Ergebnis als Ausgabeargumente angegeben wird.

Das folgende Beispiel zeigt das Ein- und Ausgabeschema eines Funktions-Tools:

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string",
      "description": "The city and state, for example, San Francisco, CA"
    }
  },
  "required": [
    "location"
  ]
}

{
  "type": "object",
  "properties": {
    "temperature": {
      "type": "number",
      "description": "The temperature"
    }
  }
}

Das folgende Beispiel zeigt die erste Anfrage und Antwort für die Intent-Erkennung mit REST:

HTTP method and URL:
POST https://REGION_ID-dialogflow.googleapis.com/v3/projects/PROJECT_ID/locations/LOCATION_ID/agents/AGENT_ID/sessions/SESSION_ID:detectIntent
{
  "queryInput": {
    "text": {
      "text": "what is the weather in Mountain View"
    },
    "languageCode": "en"
  }
}

{
  "queryResult": {
    "text": "what is the weather in Mountain View",
    "languageCode": "en",
    "responseMessages": [
      {
        "source": "VIRTUAL_AGENT",
        "toolCall": {
          "tool": "<tool-resource-name>",
          "action": "get-weather-tool",
          "inputParameters": {
            "location": "Mountain View"
          }
        }
      }
    ]
  }
}

Das folgende Beispiel zeigt die zweite Anfrage zum Erkennen von Intentionen, die das Tool-Ergebnis liefert:

{
  "queryInput": {
    "toolCallResult": {
      "tool": "<tool-resource-name>",
      "action": "get-weather-tool",
      "outputParameters": {
        "temperature": 28.0
      }
    },
    "languageCode": "en"
  }
}

Clientseitige Ausführung

Wie Funktionstools können auch OpenAPI- und Datenspeichertools clientseitig ausgeführt werden, indem bei der Interaktion mit der Sitzung eine API-Überschreibung angewendet wird.

Beispiel:

DetectIntentRequest {
  ...
  query_params {
    playbook_state_override {
      playbook_execution_mode: ALWAYS_CLIENT_EXECUTION
    }
  }
  ...
}