Agent bereitstellen

So stellen Sie einen Agenten in Vertex AI Agent Engine bereit:

  1. Agent für die Bereitstellung konfigurieren
  2. AgentEngine-Instanz erstellen
  3. Bereitgestelltem Agent Berechtigungen erteilen
  4. Agent-Ressourcen-ID abrufen

Sie können auch Agent Starter Pack-Vorlagen für die Bereitstellung verwenden.

Hinweise

Bevor Sie einen Agent bereitstellen, müssen Sie die folgenden Aufgaben ausführen:

  1. Richten Sie die Umgebung ein.
  2. Agent entwickeln

Agent für die Bereitstellung konfigurieren

Sie können die folgenden optionalen Konfigurationen vornehmen:

Paketanforderungen definieren

Geben Sie die Menge der Pakete an, die für die Bereitstellung des Agents erforderlich sind. Die Gruppe von Paketen kann entweder eine Liste von Elementen sein, die von pip installiert werden sollen, oder der Pfad zu einer Datei, die dem Requirements File Format entspricht. Beachten Sie die folgenden Best Practices:

  1. Pinnen Sie Ihre Paketversionen für reproduzierbare Builds. Zu den gängigen Paketen, die Sie im Blick behalten sollten, gehören: google-cloud-aiplatform, cloudpickle, langchain, langchain-core, langchain-google-vertexai und pydantic.

  2. Minimieren Sie die Anzahl der Abhängigkeiten in Ihrem Agent. Dadurch wird die Anzahl der funktionsgefährdenden Änderungen beim Aktualisieren Ihrer Abhängigkeiten und Ihres Agents reduziert.

Wenn der Agent keine Abhängigkeiten hat, können Sie requirements auf None setzen:

requirements = None

Wenn der Agent eine frameworkspezifische Vorlage verwendet, sollten Sie bei der Entwicklung des Agents die importierte SDK-Version angeben, z. B. 1.77.0.

ADK 

requirements = [
    "google-cloud-aiplatform[agent_engines,adk]",
    # any other dependencies
]

LangChain 

requirements = [
    "google-cloud-aiplatform[agent_engines,langchain]",
    # any other dependencies
]

LangGraph 

requirements = [
    "google-cloud-aiplatform[agent_engines,langgraph]",
    # any other dependencies
]

AG2 

requirements = [
    "google-cloud-aiplatform[agent_engines,ag2]",
    # any other dependencies
]

LlamaIndex

Die folgende Anleitung gilt für die LlamaIndex-Abfragepipeline:

requirements = [
    "google-cloud-aiplatform[agent_engines,llama_index]",
    # any other dependencies
]

Mit dem Paket requirements haben Sie außerdem folgende Möglichkeiten:

  • Obergrenze für die Version eines bestimmten Pakets festlegen oder die Version eines bestimmten Pakets fixieren (z. B. google-cloud-aiplatform):

    requirements = [
    # See https://pypi.org/project/google-cloud-aiplatform for the latest version.
    "google-cloud-aiplatform[agent_engines,adk]==1.88.0",
]

  • Zusätzliche Pakete und Einschränkungen hinzufügen:

    requirements = [
    "google-cloud-aiplatform[agent_engines,adk]==1.88.0",
    "cloudpickle==3.0", # new
]

  • Auf die Version eines Pakets in einem GitHub-Branch oder einer Pull-Anfrage verweisen:

    requirements = [
    "google-cloud-aiplatform[agent_engines,adk] @ git+https://github.com/googleapis/python-aiplatform.git@BRANCH_NAME", # new
    "cloudpickle==3.0",
]

  • Führen Sie die Liste der Anforderungen in einer Datei (z. B. path/to/requirements.txt):

    requirements = "path/to/requirements.txt"

    Dabei ist path/to/requirements.txt eine Textdatei, die dem Anforderungsdateiformat entspricht. Beispiel:

    google-cloud-aiplatform[agent_engines,adk]
cloudpickle==3.0

Zusätzliche Pakete definieren

Sie können lokale Dateien oder Verzeichnisse einfügen, die erforderliche lokale Python-Quelldateien enthalten. Im Vergleich zu Paketanforderungen können Sie so private Dienstprogramme verwenden, die Sie entwickelt haben und die sonst nicht auf PyPI oder GitHub verfügbar sind.

Wenn für den Agent keine zusätzlichen Pakete erforderlich sind, können Sie extra_packages auf None festlegen:

extra_packages = None

Mit extra_packages haben Sie auch folgende Möglichkeiten:

  • Eine einzelne Datei einfügen (z. B. agents/agent.py):

    extra_packages = ["agents/agent.py"]

  • So nehmen Sie alle Dateien in einem gesamten Verzeichnis auf (z. B. agents/):

    extra_packages = ["agents"] # directory that includes agents/agent.py

  • Geben Sie Python-Rad-Binärdateien an (z. B. path/to/python_package.whl):

    requirements = [
    "google-cloud-aiplatform[agent_engines,adk]",
    "cloudpickle==3.0",
    "python_package.whl",  # install from the whl file that was uploaded
]
extra_packages = ["path/to/python_package.whl"]  # bundle the whl file for uploading

Umgebungsvariablen definieren

Wenn Ihr Agent von Umgebungsvariablen abhängt, können Sie diese im Argument env_vars= angeben. Wenn der Agent nicht von Umgebungsvariablen abhängig ist, können Sie ihn auf None festlegen:

env_vars = None

Es gibt verschiedene Möglichkeiten, die Umgebungsvariablen anzugeben:

Wörterbuch 

env_vars = {
  "VARIABLE_1": "VALUE_1",
  "VARIABLE_2": "VALUE_2",
}
# These environment variables will become available in Vertex AI Agent Engine
# through `os.environ`, e.g.
#
#   import os
#   os.environ["VARIABLE_1"] # will have the value "VALUE_1"
#
# and
#
#   os.environ["VARIABLE_2"] # will have the value "VALUE_2"
#

Wenn Sie auf ein Secret in Secret Manager verweisen und es als Umgebungsvariable (z. B. CLOUD_SQL_CREDENTIALS_SECRET) verfügbar sein soll, folgen Sie zuerst der Anleitung zum Erstellen eines Secrets für CLOUD_SQL_CREDENTIALS_SECRET in Ihrem Projekt, bevor Sie die Umgebungsvariablen so angeben:

env_vars = {
  # ... (other environment variables and their values)
  "CLOUD_SQL_CREDENTIALS_SECRET": {"secret": "SECRET_ID", "version": "SECRET_VERSION_ID"},
}

Dabei gilt:

  • SECRET_VERSION_ID ist die ID der Secret-Version.
  • SECRET_ID ist die ID des Secrets.

Im Agent-Code können Sie dann so auf das Secret verweisen:

secret = os.environ.get("CLOUD_SQL_CREDENTIALS_SECRET")
if secret:
  # Secrets are stored as strings, so use json.loads to parse JSON payloads.
  return json.loads(secret)

Liste 

env_vars = ["VARIABLE_1", "VARIABLE_2"]
# This corresponds to the following code snippet:
#
#   import os
#
#   env_vars = {
#     "VARIABLE_1": os.environ["VARIABLE_1"],
#     "VARIABLE_2": os.environ["VARIABLE_2"],
#   }

Benutzerdefinierte Ressourcenkontrollen definieren

Sie können Laufzeitressourcen für den Agenten festlegen, z. B. die Mindest- und Höchstanzahl von Anwendungsinstanzen, Ressourcenlimits für jeden Container und die Parallelität für jeden Container.

  • min_instances: Die Mindestanzahl der Anwendungsinstanzen, die jederzeit ausgeführt werden sollen, mit einem Bereich von [0, 10]. Der Standardwert ist 1.

  • max_instances: Die maximale Anzahl von Anwendungsinstanzen, die gestartet werden können, um mehr Traffic zu bewältigen. Der Bereich liegt zwischen [1, 1000]. Der Standardwert ist 100. Wenn VPC-SC oder PSC-I aktiviert ist, liegt der zulässige Bereich bei [1, 100].

  • resource_limits: Ressourcenlimits für jeden Container. Es werden nur cpu- und memory-Schlüssel unterstützt. Der Standardwert ist {"cpu": "4", "memory": "4Gi"}.

    • Die einzigen unterstützten Werte für cpu sind „1“, „2“, „4“, „6“ und „8“. Weitere Informationen finden Sie unter CPU-Zuweisung konfigurieren.

    • Die einzigen unterstützten Werte für memory sind „1Gi“, „2Gi“ … „32Gi“.

    • Informationen zur erforderlichen CPU für verschiedene Speicherwerte finden Sie unter Arbeitsspeicherlimits konfigurieren.

  • container_concurrency: Gleichzeitigkeit für jeden Container und Agent-Server. Der empfohlene Wert ist 2 * cpu + 1. Der Standardwert ist 9.

remote_agent = agent_engines.create(
    local_agent,
    # ... other configs
    min_instances=1,
    max_instances=10,
    resource_limits={"cpu": "4", "memory": "8Gi"},
    container_concurrency=9,
)

Build-Optionen definieren

Sie können Build-Optionen für den Agent angeben, z. B. Installationsskripts, die beim Erstellen des Container-Images des Agents ausgeführt werden sollen. Das ist nützlich, um Systemabhängigkeiten (z. B. gcloud cli, npx) oder andere benutzerdefinierte Setups zu installieren. Die Skripts werden mit Root-Berechtigungen ausgeführt.

Wenn Sie Installationsskripts verwenden möchten, erstellen Sie ein Verzeichnis mit dem Namen installation_scripts und legen Sie Ihre Shell-Skripts in diesem Verzeichnis ab:

.
├── ...
└── installation_scripts/
    └── install.sh

Geben Sie als Nächstes das Verzeichnis installation_scripts in extra_packages und die Skriptpfade in build_options an:

extra_packages = [..., "installation_scripts/install.sh"]
build_options = {"installation_scripts": ["installation_scripts/install.sh"]}

Sie können eines der folgenden gängigen Installationsskripts verwenden:

install_npx.sh 

#!/bin/bash

# Exit immediately if a command exits with a non-zero status.
set -e

echo "--- Installing System-Wide Node.js v20.x ---"

# 1. Install prerequisites
apt-get update
apt-get install -y ca-certificates curl gnupg

# 2. Add the NodeSource repository GPG key
mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

# 3. Add the NodeSource repository for Node.js v20
NODE_MAJOR=20
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | tee /etc/apt/sources.list.d/nodesource.list

# 4. Update package lists again and install Node.js
apt-get update
apt-get install nodejs -y

echo "--- System-wide Node.js installation complete ---"
echo "Verifying versions:"

# These commands will now work for ANY user because node and npx
# are installed in /usr/bin/ which is in everyone's default PATH.
node -v
npm -v
npx -v

install_uvx.sh 

#!/bin/bash

# Exit immediately if a command exits with a non-zero status.
set -e

echo "Starting setup..."

# Install uv
apt-get update
apt-get install -y curl
curl -LsSf https://astral.sh/uv/install.sh | env UV_INSTALL_DIR="/usr/local/bin" sh

# These commands will now work for ANY user because uv and uvx
# are installed in /usr/local/bin/ which is in everyone's default PATH.
uv --version
uvx --version

install_gcloud_cli.sh 

#!/bin/bash

# Exit immediately if a command exits with a non-zero status.
set -e

apt-get install -y curl gpg
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
apt-get update -y && apt-get install google-cloud-cli -y

gcloud --version

Cloud Storage-Ordner definieren

Staging-Artefakte werden überschrieben, wenn sie einem vorhandenen Ordner in einem Cloud Storage-Bucket entsprechen. Bei Bedarf können Sie den Cloud Storage-Ordner für die Staging-Artefakte angeben. Sie können gcs_dir_name auf None festlegen, wenn Sie nichts dagegen haben, dass die Dateien im Standardordner möglicherweise überschrieben werden:

gcs_dir_name = None

Damit die Dateien nicht überschrieben werden (z. B. für verschiedene Umgebungen wie Entwicklung, Staging und Produktion), können Sie einen entsprechenden Ordner einrichten und den Ordner angeben, in dem das Artefakt bereitgestellt werden soll:

gcs_dir_name = "dev" # or "staging" or "prod"

Wenn Sie Kollisionen vermeiden möchten oder müssen, können Sie eine zufällige uuid generieren:

import uuid
gcs_dir_name = str(uuid.uuid4())

Ressourcenmetadaten konfigurieren

Sie können Metadaten für die ReasoningEngine-Ressource festlegen:

display_name = "Currency Exchange Rate Agent (Staging)"

description = """
An agent that has access to tools for looking up the exchange rate.

If you run into any issues, please contact the dev team.
"""

Eine vollständige Liste der Parameter finden Sie in der API-Referenz.

Benutzerdefiniertes Dienstkonto konfigurieren

Sie können ein benutzerdefiniertes Dienstkonto als Identität Ihres bereitgestellten Agents konfigurieren, anstatt die Standardidentität zu verwenden.

Geben Sie dazu die E-Mail-Adresse Ihres benutzerdefinierten Dienstkontos als service_account an, wenn Sie die Agent Engine-Instanz erstellen oder aktualisieren, z. B.:

# Create a new instance
agent_engines.create(
  local_agent=<my-agent>,
  service_account="my-custom-service-account@my-project.iam.gserviceaccount.com",
  ...
)

# Update an existing instance
resource_name = "projects/{project_id}/locations/{location}/reasoningEngines/{reasoning_engine_id}"
agent_engines.update(
  resource_name,
  service_account="my-new-custom-service-account@my-project.iam.gserviceaccount.com",
  ...
)

Private Service Connect-Schnittstelle konfigurieren

Vertex AI Agent Engine unterstützt Private Service Connect-Schnittstellen und DNS-Peering für privaten und sicheren Egress-Traffic.

Vorteile von Private Service Connect-Schnittstellen

Ihr Agent wird in einem sicheren, von Google verwalteten Netzwerk ohne Zugriff auf Ihr VPC-Netzwerk (Virtual Private Cloud) bereitgestellt. Eine PSC-Schnittstelle stellt eine private und sichere Brücke zu Ihrem Netzwerk dar. Sie ist daher die empfohlene Lösung für die Interaktion mit privat gehosteten Diensten in Ihren VPC-, On-Premise- und Multicloud-Umgebungen.

Diese Verbindung bietet nicht nur privaten Zugriff, sondern ist auch erforderlich, um den Internetzugriff bei Verwendung von VPC Service Controls zu ermöglichen. Weitere Informationen finden Sie unter Auf das öffentliche Internet zugreifen.

So funktioniert's

Wenn Sie eine PSC-Schnittstelle konfigurieren, stellt Agent Engine eine Schnittstelle in einem Google-eigenen Mandantenprojekt bereit, in dem Ihr Agent ausgeführt wird. Diese Schnittstelle wird direkt mit einem Netzwerkanhang in Ihrem Projekt verbunden. Der gesamte Traffic zwischen Ihrem Agent und Ihrer VPC wird sicher im Google-Netzwerk übertragen und durchläuft niemals das öffentliche Internet.

Auf das öffentliche Internet zugreifen

Ob der Agent auf das öffentliche Internet zugreifen kann, hängt von der Sicherheitskonfiguration Ihres Projekts ab, insbesondere davon, ob Sie VPC Service Controls verwenden.

Standardverhalten (ohne VPC Service Controls)
  • Wenn Sie Ihren Agent nur mit einer PSC-Schnittstelle konfigurieren, behält er seinen Standard-Internetzugriff bei. Dieser ausgehende Traffic wird direkt aus der sicheren, von Google verwalteten Umgebung geleitet, in der Ihr Agent ausgeführt wird.
Mit VPC Service Controls
  • Wenn Ihr Projekt Teil eines VPC Service Controls-Perimeters ist, wird der standardmäßige Internetzugriff des Agents durch den Perimeter blockiert, um Daten-Exfiltration zu verhindern. Damit der Agent in diesem Szenario auf das öffentliche Internet zugreifen kann, müssen Sie explizit einen sicheren Pfad für ausgehenden Traffic konfigurieren, der Traffic über Ihre VPC weiterleitet. Die empfohlene Methode hierfür ist, einen Proxyserver in Ihrem VPC-Perimeter einzurichten und ein Cloud NAT-Gateway zu erstellen, damit die Proxy-VM auf das Internet zugreifen kann.

Hinweise

Wenn Sie private Verbindungen für Ihren bereitgestellten Agenten über die Private Service Connect-Schnittstelle aktivieren möchten, müssen Sie ein VPC-Netzwerk, ein Subnetzwerk und einen Netzwerkanhang in Ihrem Nutzerprojekt einrichten.

Anforderungen an Subnetzwerk-IP-Bereiche

Agent Engine empfiehlt ein /28-Subnetzwerk.

Das Subnetz der Netzwerkverbindung unterstützt RFC 1918- und Nicht-RFC 1918-Adressen, mit Ausnahme der Subnetze 100.64.0.0/10 und 240.0.0.0/4. Agent Engine kann nur eine Verbindung zu RFC 1918-IP-Adressbereichen herstellen, die über das angegebene Netzwerk geroutet werden können. Die Agent Engine kann keine privat verwendete öffentliche IP-Adresse oder die folgenden Bereiche außerhalb von RFC 1918 erreichen:

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

Weitere Informationen zur Einrichtung finden Sie unter Private Service Connect-Schnittstelle einrichten.

Mit freigegebene VPC verwenden

Sie können die Private Service Connect-Schnittstelle mit einer freigegebene VPC-Architektur verwenden. So können Sie Ihre Agent Engine in einem Dienstprojekt erstellen und gleichzeitig ein Netzwerk aus einem zentralen Hostprojekt nutzen.

Wenn Sie PSC-I in einer freigegebene VPC-Umgebung einrichten, erstellen Sie das Subnetz im Hostprojekt und dann den Netzwerk-Anhang im Dienstprojekt.

Damit das Dienstprojekt das Netzwerk des Hostprojekts verwenden kann, müssen Sie die entsprechende IAM-Berechtigung erteilen. Der Vertex AI-Dienst-Agent aus Ihrem Dienstprojekt benötigt die Rolle „Compute Network User“ (roles/compute.networkUser) für das Hostprojekt.

Agents mit Private Service Connect-Schnittstelle bereitstellen

Nachdem der Netzwerkanhang eingerichtet wurde, können Sie ihn beim Erstellen der AgentEngine-Instanz angeben.

remote_agent = agent_engines.create(
    agent_engine=local_agent,
    psc_interface_config={
      "network_attachment": "NETWORK_ATTACHMENT",
    },
)

Dabei gilt:

  • NETWORK_ATTACHMENT ist der Name oder vollständige Pfad des von Ihnen erstellten Netzwerkanhangs.

Netzwerkanhänge mit mehreren Agents verwenden

Sie können flexibel entscheiden, wie Ihre Agents Netzwerkressourcen gemeinsam nutzen. Sie können mehrere Agents so konfigurieren, dass sie entweder einen einzelnen, freigegebenen Netzwerkanhang oder eindeutige, dedizierte Netzwerkanhänge verwenden.

Wenn Sie einen freigegebenen Netzwerkanhang verwenden möchten, geben Sie für jeden erstellten Agent denselben Netzwerkanhang im psc_interface_config an.

DNS-Peering

Während die Private Service Connect-Schnittstelle den sicheren Netzwerkpfad bereitstellt, bietet DNS-Peering den Mechanismus zur Diensterkennung. Bei PSC-I müssen Sie weiterhin die spezifische IP-Adresse des Dienstes im VPC-Netzwerk kennen. Sie können zwar über die internen IP-Adressen eine Verbindung zu Diensten herstellen, dies wird jedoch für Produktionssysteme, in denen sich IP-Adressen ändern können, nicht empfohlen. Mit DNS-Peering kann der bereitgestellte Agent über stabile, für Menschen lesbare DNS-Namen anstelle von IP-Adressen eine Verbindung zu Diensten in Ihrem VPC-Netzwerk herstellen. Mit DNS-Peering können die bereitgestellten Agents DNS-Namen mithilfe der Einträge aus einer privaten Cloud DNS-Zone in Ihrer VPC auflösen. Weitere Informationen finden Sie unter Privates DNS-Peering einrichten.

Nachdem das private DNS-Peering eingerichtet wurde, können Sie es beim Erstellen der AgentEngine-Instanz angeben.

remote_agent = agent_engines.create(
    agent_engine=local_agent,
    psc_interface_config={
      "network_attachment": "NETWORK_ATTACHMENT",
      "dns_peering_configs": [
        {
          "domain": "DOMAIN_SUFFIX",
          "target_project": "TARGET_PROJECT",
          "target_network": "TARGET_NETWORK",
        }
      ],
    },
)

Dabei gilt:

  • NETWORK_ATTACHMENT ist der Name oder vollständige Pfad des von Ihnen erstellten Netzwerkanhangs.
  • DOMAIN_SUFFIX ist der DNS-Name der privaten Cloud DNS-Zone, die Sie beim Einrichten des privaten DNS-Peerings erstellt haben.
  • TARGET_PROJECT ist das Projekt, in dem das VPC-Netzwerk gehostet wird.
  • TARGET_NETWORK ist der Name des VPC-Netzwerk.

Vom Kunden verwaltete Verschlüsselungsschlüssel konfigurieren

Sie können einen benutzerdefinierten Schlüssel verwenden, um die ruhenden Daten Ihres Agents zu verschlüsseln. Weitere Informationen finden Sie unter Agent Engine – Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

Wenn Sie den benutzerdefinierten Schlüssel (CMEK) für Ihren Agenten konfigurieren möchten, müssen Sie beim Erstellen der Agent Engine-Instanz den Ressourcennamen des Schlüssels für den Parameter encryption_spec angeben.

# The fully qualified key name
kms_key_name = "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME"

remote_agent = agent_engines.create(
    local_agent,
    # ... other parameters
    encryption_spec={"kms_key_name": kms_key_name},
)

AgentEngine-Instanz erstellen

Wenn Sie den Agent in Vertex AI bereitstellen möchten, verwenden Sie agent_engines.create, um das local_agent-Objekt zusammen mit allen optionalen Konfigurationen zu übergeben:

remote_agent = agent_engines.create(
    local_agent,                     # Optional.
    requirements=requirements,       # Optional.
    extra_packages=extra_packages,   # Optional.
    gcs_dir_name=gcs_dir_name,       # Optional.
    display_name=display_name,       # Optional.
    description=description,         # Optional.
    env_vars=env_vars,               # Optional.
    build_options=build_options,     # Optional.
    service_account=service_account, # Optional.
    min_instances=min_instances,     # Optional.
    max_instances=max_instances,     # Optional.
    resource_limits=resource_limits, # Optional.
    container_concurrency=container_concurrency, # Optional
    encryption_spec=encryption_spec, # Optional.
)

Die Bereitstellung dauert einige Minuten. In dieser Zeit werden im Hintergrund die folgenden Schritte ausgeführt:

  1. Ein Bundle der folgenden Artefakte wird lokal generiert:

    • *.pkl ist eine Pickle-Datei, die dem lokalen Agenten entspricht.
    • requirements.txt – eine Textdatei mit den Paketanforderungen.
    • dependencies.tar.gz eine TAR-Datei mit allen zusätzlichen Paketen.

  2. Das Bundle wird in Cloud Storage (im entsprechenden Ordner) hochgeladen, um die Artefakte bereitzustellen.

  3. Die Cloud Storage-URIs für die jeweiligen Artefakte werden in der PackageSpec angegeben.

  4. Der Vertex AI Agent Engine-Dienst empfängt die Anfrage, erstellt Container und startet HTTP-Server im Backend.

Die Bereitstellungslatenz hängt von der Gesamtzeit ab, die für die Installation der erforderlichen Pakete benötigt wird. Nach der Bereitstellung entspricht remote_agent einer Instanz von local_agent, die auf Vertex AI ausgeführt wird und abgefragt oder gelöscht werden kann. Es ist von lokalen Instanzen des Agents getrennt.

Berechtigungen für den bereitgestellten Agent erteilen

Wenn dem bereitgestellten Agent zusätzliche Berechtigungen erteilt werden müssen, folgen Sie der Anleitung unter Identität und Berechtigungen für Ihren Agent einrichten.

Wenn Sie Secrets als Umgebungsvariablen definiert haben, müssen Sie die folgende Berechtigung erteilen:

  • Zugriffsperson für Secret Manager-Secret (roles/secretmanager.secretAccessor)

Agent-Ressourcen-ID abrufen

Jeder bereitgestellte Agent hat eine eindeutige Kennung. Führen Sie den folgenden Befehl aus, um die resource_name-ID für Ihren bereitgestellten Agent abzurufen:

remote_agent.resource_name

Die Antwort sollte in etwa so aussehen:

"projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/RESOURCE_ID"

Dabei gilt:

  • PROJECT_ID ist die Google Cloud Projekt-ID, in der der bereitgestellte Agent ausgeführt wird.

  • LOCATION ist die Region, in der der bereitgestellte Agent ausgeführt wird.

  • RESOURCE_ID ist die ID des bereitgestellten Agents als reasoningEngine-Ressource.

Nächste Schritte