03. Tutoriel : un agent dans un AUTRE projet, utilisable dans le chat Gemini Enterprise
12 min read
This content is not translated yet. Showing the original version.
Pour qui : toute personne qui veut le faire une première fois à la main, dans la console Google Cloud.
Résultat : un agent déployé dans un projet B apparaît dans l'app Gemini Enterprise du projet A, et répond normalement
dans le chat.
On utilise uniquement la console et Cloud Shell. Faites d'abord le tutoriel 02 (même projet) :
ce document ne décrit que ce qui change quand l'agent vit dans un autre projet, et les deux méthodes en plus
(Cloud Run + A2A, Agent Registry + Agent Gateway).
PROJET A : "acme-ge-demo" PROJET B : "acme-agents-demo"
┌──────────────────────────────────┐ ┌────────────────────────────────────────────┐
│ App Gemini Enterprise (eu) │ │ Méthode 1 : Agent Runtime (Vertex AI) │
│ ├─ chat des utilisateurs │──── appelle ─▶│ Méthode 2 : Cloud Run + A2A │
│ └─ Agents : stock (x3 méthodes) │ │ Méthode 3 : via Agent Registry + Gateway │
│ Compte de service GE : │ │ IAM : droits donnés AU compte GE du projet A│
│ service-NUM_A@gcp-sa-discovery… │ └────────────────────────────────────────────┘
└──────────────────────────────────┘
Un compte Google d'entreprise (Workspace ou Cloud Identity), pas un Gmail
Gemini Enterprise est réservé aux organisations
Une organisation Google Cloud et un compte de facturation
Les deux projets doivent être rattachés à l'organisation et facturés
Rôles : Project Creator, Billing Account User ; puis Owner sur les deux projets (en démo)
Créer les projets, activer les services, poser les droits
Des licences Gemini Enterprise (ou un essai)
Pour utiliser le chat
Dans tout le guide, remplacez :
acme-ge-demo par l'ID de votre projet A, et NUM_A par son numéro (page d'accueil du projet, carte Informations sur le projet) ;
acme-agents-demo par l'ID du projet B, et NUM_B par son numéro.
Étape 1 : projet A : l'app et son compte de service
Créer (si besoin) le projet A et l'app Gemini Enterprise en eu, l'identité et les testeurs :
tutoriel 02, étape 1.
Noter le compte de service de Gemini Enterprise du projet A. C'est lui qui appellera l'agent du projet B, et c'est
à lui que le projet B donnera des droits :
dans Cloud Shell : gcloud config set project acme-agents-demo (projet B) ;
les exemples ci-dessous utilisent un agent stock_agent (code dans le dépôt : agents/specialist/stock_agent). L'agent
conges_agent du tutoriel 02 convient tout aussi bien : remplacez simplement le nom du dossier.
Méthode 1 : Agent Runtime (Vertex AI)
Le principe : Google héberge l'agent (pas de serveur à gérer), avec des sessions et des journaux. Gemini Enterprise
l'appelle par son nom de ressource.
M1.1 Déployer l'agent (projet B)
cd ~/agentsadk deploy agent_engine --project=acme-agents-demo --region=europe-west1 \ --display_name="stock-agent" --description="Stock d'un article par magasin" stock_agent
Durée : 5 à 10 minutes. À la fin, la commande affiche le nom de ressource :
projects/NUM_B/locations/europe-west1/reasoningEngines/1234567890.
Dans la console : 🔎 « Agent Runtime » (menu Agent Platform → Déploiements) → stock-agent apparaît.
Cliquer dessus : onglets Playground (pour tester), Journaux, Sessions. Copier le nom de la ressource.
Pourquoi europe-west1 : l'app est en eu. Google n'accepte que des agents en europe-* pour une app eu.
M1.2 Autoriser Gemini Enterprise (projet A) dans le projet B
C'est l'étape qu'on oublie. Sans elle, l'agent s'ajoute, mais ne répond pas dans le chat.
Sélectionner le projet B → 🔎 « IAM » → Accorder l'accès.
Nouveaux comptes principaux : service-NUM_A@gcp-sa-discoveryengine.iam.gserviceaccount.com (le compte de l'app,
donc du projet A).
Rôle : Discovery Engine Service Agent (roles/discoveryengine.serviceAgent).
Enregistrer.
Si la console refuse de sélectionner un rôle d'« agent de service », utiliser Cloud Shell :
Identique au tutoriel 02, étape 6, dans le projet A, avec le nom de
ressource de l'agent du projet B (projects/NUM_B/locations/europe-west1/reasoningEngines/…).
Le principe : l'agent tourne dans un conteneur Cloud Run et parle le protocole ouvert A2A. Il publie une carte
d'agent (JSON), que l'on colle dans Gemini Enterprise. Gemini Enterprise appelle le service avec un jeton de son compte
de service : le service reste privé.
M2.1 Préparer la carte d'agent (projet B)
L'adresse d'un service Cloud Run est prévisible : https://NOM-NUM_B.REGION.run.app. ADK expose l'agent A2A sous
/a2a/<dossier>.
cd ~/agentsNUM_B=$(gcloud projects describe acme-agents-demo --format='value(projectNumber)')URL="https://stock-agent-a2a-$NUM_B.europe-west1.run.app/a2a/stock_agent"cat > stock_agent/agent.json <<EOF{ "protocolVersion": "0.3", "name": "stock_agent", "description": "Donne le stock d'un article Acme par magasin, à partir de son code article.", "url": "$URL", "preferredTransport": "JSONRPC", "version": "1.0.0", "capabilities": {"streaming": true}, "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"], "skills": [{"id": "stock", "name": "Stock magasin", "description": "Stock d'un article par magasin", "tags": ["stock", "magasin"], "examples": ["Stock de 8771234 ?"]}]}EOFcat stock_agent/agent.json
Tout ce qui suit -- est transmis à gcloud run deploy. --no-allow-unauthenticated signifie : pas d'accès public.
Durée : 5 à 10 minutes (construction du conteneur).
Vérifier la carte, avec votre propre jeton. Le serveur ADK la renvoie dans le format A2A le plus récent, et il accepte aussi les appels v0.3 (message/send) qu'utilise Gemini Enterprise (vérifié en local avec ADK 2.10 / a2a-sdk 1.2) :
Dans la console : 🔎 « Cloud Run » → stock-agent-a2a → l'URL affichée doit être https://stock-agent-a2a-NUM_B.europe-west1.run.app.
Si elle est différente (ancien format d'URL), corriger url dans agent.json et redéployer.
M2.3 Autoriser Gemini Enterprise à appeler le service
Projet B → 🔎 « Cloud Run » → cliquer sur stock-agent-a2a → onglet Sécurité (ou Autorisations selon la
version) → Ajouter un compte principal.
Compte : service-NUM_A@gcp-sa-discoveryengine.iam.gserviceaccount.com.
Rôle : Demandeur Cloud Run (Cloud Run Invoker, roles/run.invoker) → Enregistrer.
On donne le droit sur ce service uniquement, pas sur tout le projet B.
M2.4 Ajouter l'agent dans l'app (projet A)
Projet A → Gemini Enterprise → l'app → Agents → Ajouter un agent → Agent personnalisé via A2A → Ajouter.
Coller le contenu de agent.json (le JSON, pas l'URL).
Prévisualiser les détails de l'agent → vérifier le nom, la description, les compétences → Suivant.
Authentification : ignorer (le jeton du compte Gemini Enterprise suffit pour Cloud Run).
Terminer.
À savoir :
un agent A2A ajouté ainsi n'est pas filtré par le Model Armor de l'app ;
il ne passe pas par Agent Gateway.
En production, il doit donc se filtrer lui-même (plugin Model Armor dans son code).
Méthode 3 : Agent Registry + Agent Gateway
Le principe : au lieu d'ajouter l'agent « en direct », l'app le prend dans un catalogue (Agent Registry), et tous les
appels passent par un poste de contrôle (Agent Gateway) qui refuse tout ce qui n'est pas autorisé.
C'est la méthode cible pour une gouvernance centrale. Elle demande plus de mise en place.
M3.1 Règles à respecter (app eu)
Élément
Valeur imposée
Agent Gateway
Région europe-west1
Registre utilisé pour l'import
europe-west1 (ou eu)
L'app
Liée à la passerelle avant l'import
M3.2 Mettre l'agent du projet B dans le registre du projet A
Le plus simple et le plus sûr en multi-projets : déclarer l'agent du projet B dans le registre du projet A (celui de
l'app).
Projet A → activer Agent Registry API, Network Services API, IAP API.
🔎 « Agent Registry » → région europe-west1 → Enregistrer (Register) → type Agent.
Nom stock-agent-b, description, spécification Carte d'agent A2A : coller le JSON de la méthode 2 (son url pointe
vers le Cloud Run du projet B).
Enregistrer.
Les agents Agent Runtime du projet B sont déjà dans le registre du projet B, automatiquement. Les importer
directement depuis ce registre dans une app du projet A dépend de la liaison passerelle ↔ registre d'un autre projet :
point à valider. La déclaration dans le registre du projet A fonctionne dans tous les cas.
🔎 « Agent Registry » → stock-agent-b → Autorisations → Ajouter un compte principal :
service-NUM_A@gcp-sa-discoveryengine.iam.gserviceaccount.com → rôle IAP-secured Egressor (roles/iap.egressor).
Et, comme en M2.3, Cloud Run Invoker sur le service du projet B pour ce même compte.
M3.5 Lier la passerelle à l'app, puis importer
Projet A → Gemini Enterprise → l'app → Sécurité → Configuration → Configuration Agent Gateway :
projects/acme-ge-demo/locations/europe-west1/agentGateways/ge-egress → Enregistrer.
⚠ À partir de là, tout le trafic de l'app passe par la passerelle, y compris les appels au modèle.
L'app → Agents → Ajouter un agent → choisir stock-agent-b dans la liste du registre → Ajouter →
authentification : ignorer → terminer.
Étape 6 : donner l'accès et tester dans le chat
Identique au tutoriel 02, étape 7 (rôle Agent User au
groupe, test dans l'app web). Seule différence : les traces de l'agent sont dans le projet B.
6.1 Voir ce qui s'est passé (projet B)
Méthode
Où regarder
1
🔎 « Agent Runtime » → l'agent → Journaux et Sessions (une session par conversation)
2
🔎 « Cloud Run » → le service → Journaux (requête POST /a2a/stock_agent, code 200)
3
Journaux de l'Agent Gateway (projet A) + ceux de la méthode 1 ou 2
Étape 7 : dépannage
Symptôme dans le chat
Cause la plus fréquente
Correction
L'agent n'apparaît pas dans la liste
Pas de rôle Agent User pour l'utilisateur, ou pas de licence