Agents × Gemini Enterprise · 12-1
Parcours 12-1 · Acme

Des agents dans un projet, utilisés dans l'app Gemini Enterprise

Vos agents vivent dans un projet des agents (un projet Google Cloud « X »). L'app Gemini Enterprise vit dans un autre projet, le projet de l'app. Ce parcours fait le chemin complet : déployer les agents, prouver que l'app pourra les appeler, les brancher sur l'app, et les agents qui agissent avec le compte de l'utilisateur. Chaque commande et chaque résultat de cette page a été testé pour de vrai.

① Déployer12-1-1 shell · 12-1-2 Terraform · 12-1-3 console : les agents dans le projet des agents (Cloud Run A2A, Agent Runtime, Agent Registry, Dialogflow)
② Prouver12-1-5 : simuler l'appel de l'app, refusé puis accepté, sans toucher à l'app
③ Brancher12-1-4 droits et ajout · 12-1-6 console de l'app · 12-1-7 OAuth, identité, outils
Étape 0 · une fois

1. Vos valeurs

Remplissez ces champs : ils produisent votre fichier de configuration (à mettre dans config/12-1-agents-dans-projet-exp.env), et toute la page s'adapte : résultats attendus, adresses, écrans de console. Tout reste dans votre navigateur.

Le projet des agents

Console → sélecteur de projet → colonne ID (pas le nom)
Même écran, colonne Numéro (12 chiffres)
europe-west1 pour une app eu
Séparées par des espaces ; vide = tous. Clés : meteo redaction traduction taille retour identite

Le projet de l'app Gemini Enterprise

Vide tant qu'il n'y a pas d'app (déploiement seul)
Donne l'adresse du compte de l'app
Gemini Enterprise → Apps → colonne ID ; ou connecter_app.sh apps
Même écran, colonne Emplacement
Un groupe Google (groups.google.com), ou votre adresse pour un 1er test : c'est la valeur du rôle Agent User
« clé=ID_autorisation », ex. identite=acces-identite (12-1-7). Vide sinon

Votre fichier de configuration


      

Puis, dans un terminal, dans le dossier du projet (à refaire dans chaque nouveau terminal) :

cd  && source .venv/bin/activate
source scripts/config.sh config/12-1-agents-dans-projet-exp.env
Avant de taper quoi que ce soit

2. Comprendre

Deux projets, un seul sens d'appel


      

L'app appelle les agents avec son compte de service. Le projet des agents l'autorise (deux droits), puis l'app ajoute les agents. Ces droits ne donnent rien aux utilisateurs : qui peut utiliser un agent, c'est le rôle Agent User, donné dans l'app.

Les deux droits (tous dans le projet des agents)

#RôleSur quoiPour
①Demandeur Cloud Run
roles/run.invoker
Un service Cloud RunChaque agent A2A
②Agent de service Discovery Engine
roles/discoveryengine.serviceAgent
Le projet entierLes agents Agent Runtime (une fois)

Qui les donne ? Celui qui possède le projet des agents : l'équipe de l'agent. Délai : 2 à 3 minutes. Le circuit avec une équipe cliente (messages à envoyer) : 12-1-4, partie 3.5.

Les modalités : comment un agent entre dans l'app

HébergementDéployé parCe que l'app demandeDepuis un autre projet ?Droit
Cloud Run (A2A)12-1-1 / 12-1-2 / 12-1-3La carte de l'agent (JSON)✅ Oui①
Agent Runtime12-1-1 / 12-1-2 / 12-1-3Le nom de ressource projects/…/reasoningEngines/ID✅ Oui②
Agent Registry (import)Automatique / déclaré—❌ Seulement le registre du projet de l'app → 12-2—
Dialogflow12-1-1 partie 10La source projects/…/agents/ID⚠ Non documenté → projet de l'app (12-2)—

1. Le compte de l'app

Appelle l'agent (le droit d'entrer) :

2. Le compte de l'agent

Ce que l'agent fait pour lui-même : Gemini, Model Armor. Un par agent : <clé>-a2a-shell-sa…

3. L'utilisateur (OAuth)

Optionnel : agir au nom de l'utilisateur après « Autoriser » (12-1-7).

Chaque guide, étape par étape

3. Les guides

Le résumé fidèle de chaque guide, avec les commandes testées. Le détail complet (chaque option, chaque erreur) est dans le fichier Markdown indiqué en haut de chaque onglet.

Le parcours complet, guidé

4. L'exercice final

Du poste vide à l'agent utilisable dans l'app. Une étape à la fois : faites-la, comparez avec le résultat attendu, cochez, passez à la suite. La progression est gardée dans ce navigateur. Les étapes de déploiement suivent la méthode choisie en partie 1.