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

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.

Tooltests

Nachdem Sie ein Tool erstellt haben, können Sie mit der Tooltestfunktion prüfen, ob es funktioniert. Klicken Sie beim Aufrufen eines Tools über dem Toolbereich 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 Ausgabe ansehen , um die korrekte Tool-Ausgabe zu prüfen.

Sie können die Tooltestfunktion 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.

Die unterstützten integrierten Tools sind:

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

Ihr Agent ist so optimiert, dass er ermittelt, wie und wann diese Tools aufgerufen werden sollen. Sie können jedoch zusätzliche Beispiele für Ihre Anwendungsfälle bereitstellen.

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 eine Verbindung zu einer externen API herstellen, indem er ein OpenAPI-Tool mit dem OpenAPI Schema verwendet. Standardmäßig ruft der Agent die API in Ihrem Namen auf.

Sie können mit der Funktion „Tool testen“ auf der Toolseite 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 auf der Clientseite 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 Schematyp für Parameter verwenden. Mit diesem Schematyp für Parameter 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 und array. Der Typ object wird noch nicht unterstützt.
Derzeit können Sie im Beispiel-Editor der Konsole keine Abfrageparameter angeben.
Anfrage- und Antworttext müssen leer oder JSON sein.

Schemaerstellung für OpenAPI-Tools

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

Eine URL der Anfrage
Eine HTTP-Methode (GET, POST usw.)
Beispieleingabe
Beispielausgabe
Eine Textaufforderung, die das Tool beschreibt

Sobald das Schema generiert wurde, können Sie es nach Bedarf bearbeiten und manuell zusätzliche URLs und Methoden hinzufügen.

API-Authentifizierung für OpenAPI-Tools

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

Authentifizierung des Dialogflow-Dienst-Agents

Dialogflow kann mit dem Dialogflow-Dienst-Agentein ID-Tokengenerieren. Das Token wird im 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 die Rollen „Cloud Functions-Aufrufer“ (roles/cloudfunctions.invoker) und „Cloud Run-Aufrufer“ (roles/run.invoker) für service-agent-project-number@gcp-sa-dialogflowiam.gserviceaccount.com gewährt haben. Wenn sich die Cloud Run-Funktionen und Cloud Run-Dienste im selben Ressourcenprojekt, befinden, ist keine zusätzliche IAM-Berechtigung erforderlich, um sie aufzurufen.

Authentifizierung des Dienstkontos

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 ihnen Zugriff auf Ressourcen in Ihrem Projekt gewähren, indem Sie ihnen eine Rolle zuweisen, wie Sie es auch für jedes andere Hauptkonto tun würden. Mit der E-Mail-Adresse des Dienstkontos wird ein Zugriffstoken generiert , 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 Dialogflow CX Tokens generieren kann, 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, der das Tool hostet.

API-Schlüssel

Sie können die API-Schlüsselauthentifizierung konfigurieren, indem Sie den Schlüsselnamen, den Anfragespeicherort (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 mit Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine API-Schlüssel mit Rohwerten mehr.

OAuth

Der OAuth-Clientanmeldedatenablauf wird für die Server-zu-Server-Authentifizierung unterstützt:
- Dieser Ablauf kann verwendet werden, wenn die Vertex AI Agent Builder-Konsole der Ressourceninhaber ist und keine Endnutzerautorisierung erforderlich ist.
- Client-ID, Clientschlüssel und Token-Endpunkt vom OAuth-Anbieter müssen in Dialogflow konfiguriert werden.
  - Wir empfehlen, den Clientschlüssel mit Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine Clientschlüssel mit Rohwerten 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 Autorisierungscodeablauf und den PKCE-Ablauf:
1. Sie müssen eine eigene Anmelde-UI implementieren und das Zugriffstoken auf der Clientseite abrufen.
2. Sie haben dann folgende Möglichkeiten:
  
  a. Verwenden Sie die Authentifizierungsoption „Inhabertoken“, um das Token an das OpenAPI-Tool zu übergeben. Dialogflow fügt dieses Token beim Aufrufen des Tools in den Autorisierungsheader ein.
  
  b. Verwenden Sie das Funktionstool, um das Tool selbst auf der Clientseite aufzurufen und das Toolaufrufergebnis an Dialogflow zu übergeben.

Inhabertoken

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

Weisen Sie dem Sitzungsparameter zur Laufzeit das Inhabertoken zu:

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

Wenn Sie ein statisches Token konfigurieren müssen, anstatt das Token von einem Sitzungsparameter abzurufen, empfehlen wir, das Token mit Secret Manager bereitzustellen. Nach dem 15. August 2025 enthalten exportierte Agents keine Inhabertokens mit Rohwerten 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. Nach der Einrichtung wird dieses Clientzertifikat bei der gegenseitigen TLS-Authentifizierung 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 Inhabertoken verwenden, können Sie die Anmeldedaten mit Secret Manager als Secrets speichern. So authentifizieren Sie Ihr Tool mit Secrets:

Erstellen Sie ein Secret falls noch nicht geschehen.
Gewähren Sie Dialogflow-Dienst-Agent die Rolle Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) für das neue Secret.
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 gerade hinzugefügten Secret-Version. Das Namensformat ist projects/{project_id}/secrets/{secret_id}/versions/{version_id}".
Öffnen Sie den Bildschirm zum Bearbeiten des Tools und gehen Sie so vor:
- Wenn Sie OAuth verwenden, wählen Sie OAuth als Authentifizierungstyp aus und klicken Sie 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 Inhabertoken verwenden, wählen Sie Inhabertoken als Authentifizierungstyp, dann klicken Sie unter Inhabertoken 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-Tools

OpenAPI-Tools werden in den privaten Netzwerkzugriff von Service Directory 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 Dialogflow-Dienst-Agent Dienstkonto 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 Sitzungsparameter für OpenAPI-Tools

Die Eingaben für OpenAPI-Tools werden aus der Unterhaltung der Nutzer 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 wurden, oder als Abfrageparametereingabe zusammen mit der Nutzereingabe bereitgestellt werden.

Der Sitzungsparameter, der als Eingabe übergeben werden muss, kann als

     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.

Standardwerte für OpenAPI-Tools

Im Open API-Schema können Standardwerte angegeben werden. Die Standardwerte werden nur verwendet, wenn für diesen Parameter oder diese Eigenschaft kein vom LLM generierter Eingabewert oder kein auf Sitzungsparametern basierender Eingabewert vorhanden ist.

Die Standardwerte können wie folgt als Teil des Schemas 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 vom LLM generierter Wert, kein Sitzungsparameterwert und kein Standardwert vorhanden ist, wird die Eingabe nicht angegeben.

Datenspeicher-Tools

Informationen zur Verwendung von Datenspeicher-Tools mit einem Playbook finden Sie in der Dokumentation zu Datenspeicher-Tools.

Connector-Tools

Connector-Tools können von einem Agent verwendet werden, um Aktionen mit Ihren in Integration Connectorskonfigurierten Verbindungen auszuführen. Jedes Connector-Tool ist 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 für die Verwendung durch Ihren Agent zu gruppieren.

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

Beispiele sollten verwendet werden, um die Nutzung 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 sie mit Ihrem Agent verbinden möchten, rufen Sie die Tools > Erstellen auf, wählen Sie den Tooltyp Connector und den gewünschten Connectortyp aus und klicken Sie auf die Schaltfläche Verbindung erstellen. Dadurch gelangen Sie zur Erstellung von Integration Connectors, wobei eine Reihe von Feldern bereits ausgefüllt ist.

Alternativ können Sie zu Integration Connectors navigieren und der Anleitung folgen, um eine Verbindung zu erstellen.

Connector-Aktionen

Für jedes Connector-Tool gibt es zwei Arten von Aktionen, die Ihrem Agent zur Verfügung gestellt 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. Bei BigQuery sind das Tabellen, bei Salesforce Objekte wie „Bestellung“ oder „Fall“.

Sie können CRUD-Vorgänge für jede Entität ausführen:
- Erstellen: Erstellt eine Entität mit angegebenen Feldwerten
- Auflisten: Filterbasierte Suche nach Entitätsinstanzen
- Aktualisieren: Filterbasierte Methode zum Ändern von Entitätsfeldwerten
- Löschen: Löscht eine Entität
- Abrufen : Ruft eine einzelne Entität mit der entityId ab
Hinweis: Der Vorgang „Abrufen“ kann nur verwendet werden, um einen einzelnen Datensatz aus einer Entität mit einem Primärschlüssel abzurufen. Oft ist es praktischer, den Vorgang „Auflisten“ 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 'ExecuteCustomQuery' Aktion, mit der eine SQL-Abfrage für die Datenquelle ausgeführt werden kann. Dabei kann auf jede der Datenquellenentitäten als Tabelle verwiesen werden. Eine Liste der unterstützten Connectors finden Sie hier.

Zusätzliche Aktionen unterscheiden sich 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 Eingabe- oder Ausgabefelder für die Aktion Ihres Connector-Tools auswählen, können Sie die Komplexität dieser Aktionen für den Agent begrenzen.

Wenn Sie beispielsweise nur eine Entität mit einer Teilmenge ihrer Felder erstellen müssen, vereinfacht die Konfiguration dieser Felder in Ihrer Aktion die Aktion für den Agent.

Durch die Angabe einer Reihe von Ausgabefeldern wird die Größe der Toolantwort reduziert (hilfreich, wenn Tokenlimits ein Problem darstellen) und die Verarbeitung der Ausgabe durch den Agent vereinfacht, da nur die relevanten Felder angezeigt werden.

Authentifizierung

Wenn die von Ihnen verwendete Verbindung so konfiguriert ist, dass die Authentifizierung überschrieben werden kann, 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, um sie für die Authentifizierung zu verwenden, wenn die Aktionen des Tools aufgerufen werden.

Funktionstools

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

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 zur Intent-Erkennung enthält den Namen des Tools sowie Eingabeargumente. Diese Sitzung wird pausiert, bis eine weitere Anfrage zur Intent-Erkennung mit dem Toolergebnis eingeht.
Ihr Clientcode ruft das Tool auf.
Ihr Clientcode sendet eine weitere Anfrage zur Intent-Erkennung, die das Toolergebnis als Ausgabeargumente bereitstellt.

Das folgende Beispiel zeigt das Eingabe- und Ausgabeschema eines Funktionstools:

{
  "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 zur 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 zur Intent-Erkennung, die das Toolergebnis enthält:

{
  "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 Datenspeicher-Tools auf der Clientseite ausgeführt werden, indem beim Interagieren mit der Sitzung eine API-Überschreibung angewendet wird.

Beispiel:

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