Confini tra progetti

Anteprima

Questo prodotto o funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

I confini di gestione tra progetti (o confini) ti consentono di scoprire, gestire e controllare gli agenti AI, i server Model Context Protocol (MCP) e gli strumenti in più progetti Google Cloud . Per impostazione predefinita, Agent Registry opera all'interno di un singolo progetto di governance, ma la configurazione di un confine di gestione in Resource Manager consente a un progetto di gestione centrale di aggregare agenti, server MCP e strumenti tra progetti membri distribuiti. Comprendere in che modo i confini di gestione strutturano i ruoli dei progetti, l'aggregazione delle risorse e controllo dell'accesso ti aiuta a progettare topologie multiprogetto scalabili.

Per configurare un confine di gestione, consulta Configura un confine di gestione per più progetti.

Modello di confine

Puoi definire un confine di gestione su una cartella o un'organizzazione in Resource Manager:

• Confine a livello di cartella o di organizzazione: per impostazione predefinita, se crei un confine su una cartella o un'organizzazione senza configurare un filtro dei tag, il confine include tutti i progetti figlio in quella cartella o organizzazione come progetti membri.
• Confini filtrati per tag (facoltativo): facoltativamente, per suddividere i progetti figlio in una cartella o un'organizzazione in più confini, puoi filtrare l'appartenenza ai confini utilizzando i tag di Resource Manager. Ad esempio, puoi separare gli ambienti prod e dev. Collega i tag ai progettiGoogle Cloud che vuoi includere in ogni confine. Quando un progetto figlio nella cartella o nell'organizzazione ha un tag che corrisponde al filtro del confine, il progetto diventa un progetto membro del confine di gestione.

Quando utilizzi i tag per suddividere i confini di gestione, i tag offrono i seguenti vantaggi:

• Registrazione dinamica e automatizzata: gli ambienti cloud modificano spesso i progetti. Quando aggiungi un tag a un progetto con un valore del tag registrato, ad esempio env=prod, Agent Registry include automaticamente quel progetto come progetto membro nel confine senza richiedere aggiornamenti manuali alle definizioni dei confini.
• Disaccoppiamento dalle gerarchie di cartelle: le strutture delle cartelle di Resource Manager sono solitamente organizzate per scopi di fatturazione o aziendali. I tag separano le definizioni dei confini dalle gerarchie delle cartelle fisiche, consentendoti di stabilire perimetri di gestione tra cartelle in una cartella o un'organizzazione principale.
• Ereditarietà e scalabilità: i tag applicati a un'organizzazione o a una cartella vengono propagati automaticamente nella gerarchia delle risorse alle cartelle e ai progetti figlio. Questo modello di ereditarietà ti consente di registrare interi rami dell'albero delle risorse con un'unica assegnazione di tag.
• Governance centralizzata: i tag sono regolati da autorizzazioni Identity and Access Management (IAM) centralizzate. Utilizzando i tag per definire i confini di gestione, puoi impedire ai singoli utenti di aggiungere o rimuovere arbitrariamente progetti dal confine.

Architettura e risorse principali

Un confine di gestione tra progetti si basa sulle seguenti risorse di Resource Manager:

• Configurazione del confine (risorsa BoundaryConfig): una risorsa di configurazione su un'organizzazione o una cartella in Resource Manager che stabilisce le regole di partizionamento del confine in quella cartella o organizzazione. Se non imposti una chiave tag sulla risorsa BoundaryConfig, l'organizzazione o la cartella supporta un unico confine che include tutti i progetti figlio. Per suddividere i progetti figlio in più confini filtrati per tag, la risorsa BoundaryConfig specifica la singola chiave tag della risorsa, ad esempio 123456789012/env, utilizzata per valutare l'appartenenza dei progetti a quella cartella o organizzazione.

• Confine (risorsa Boundary): un perimetro di progetti membri in un'organizzazione o una cartella. Senza un filtro dei tag, il confine include tutti i progetti secondari nell'organizzazione o nella cartella principale. Quando configuri una chiave tag sulla risorsa BoundaryConfig padre, la risorsa Boundary specifica un filtro del valore del tag, ad esempio env=prod, e i progetti figlio che ereditano o collegano quel valore del tag appartengono automaticamente al confine. Poiché la risorsa BoundaryConfig di un elemento padre utilizza una singola chiave tag e un progetto può avere un solo valore tag effettivo per chiave tag, un progetto può appartenere al massimo a un confine per cartella o organizzazione padre.

• Configurazione delle funzionalità (risorsa CapabilityConfig): una risorsa definita in un'organizzazione, una cartella o un progetto. A livello di organizzazione o cartella, associa uno o più confini a un progetto di gestione dedicato e specifica le funzionalità di gestione abilitate in questi confini. A livello di progetto, abilita le funzionalità di gestione per un singolo progetto autonomo senza confini. Per Agent Registry, configura la funzionalità AGENT_MANAGEMENT (Google Cloud CLI: agent-management), che consente il rilevamento centralizzato dei componenti, i rollup di ricerca e la governance tra progetti in Agent Registry e attiva automaticamente agentregistry.googleapis.com nel progetto di gestione.

Per saperne di più su queste risorse di Resource Manager, consulta la panoramica dei limiti e delle funzionalità di gestione.

Il seguente diagramma illustra in che modo le risorse di Resource Manager collegano i progetti membri a un progetto di gestione centrale:

Figura 1. Architettura di un confine di gestione tra progetti che collega i progetti membri a un progetto di gestione centrale.

Gestione di più progetti

Un confine di gestione separa la governance amministrativa dall'esecuzione del computing in due ruoli di progetto distinti: un progetto di gestione centrale e uno o più progetti membri.

Questa struttura disaccoppiata applica l'isolamento multi-tenant. I team creano ed eseguono il deployment degli agenti nei rispettivi progetti membri senza richiedere l'accesso diretto ad altri progetti membri, mentre gli amministratori e gli orchestratori mantengono una visibilità unificata oltre il confine di gestione dal progetto di gestione.

Progetto di gestione

Un progetto di gestione è un progetto Google Cloud che funge da progetto di governance centrale per un confine di gestione. Centralizza la configurazione delle API, il controllo dell'accesso, la fatturazione, il consumo delle quote e i metadati dei componenti aggregati oltre il confine senza dover ospitare runtime di computing sottostanti.

In Agent Registry, il progetto di gestione svolge le seguenti funzioni:

• Binding di confine e funzionalità: si associa a uno o più confini in Resource Manager tramite una risorsa CapabilityConfig con la funzionalità AGENT_MANAGEMENT abilitata. Per i passaggi di configurazione, consulta Configura i confini di gestione.
• Rilevamento e ricerca centralizzati: funge da progetto di destinazione per le richieste di ricerca e di elenco tra progetti, consentendo a orchestratori, sviluppatori e applicazioni client di interagire con agenti, server MCP e strumenti rilevati automaticamente in tutti i progetti membri all'interno del confine.
• Registrazione delle risorse a livello di confine: ospita le risorse Service registrate manualmente, come agenti personalizzati, server MCP esterni ed endpoint, e le risorse Binding quando vuoi che siano visibili all'interno del confine di gestione.
• Gestione centralizzata di API, fatturazione e quote: consolida l'attivazione dell'API Agent Registry, l'allocazione delle quote e la fatturazione per le operazioni di rilevamento e governance a livello di confine.

Quando configuri una risorsa CapabilityConfig su una cartella o un'organizzazione in Resource Manager, puoi eseguire il provisioning del progetto di gestione in uno dei seguenti modi:

• Progetto di gestione autogestito: designi un progettoGoogle Cloud esistente che gestisci passando il flag--management-projectquando crei la risorsaCapabilityConfig. Il progetto deve risiedere direttamente nella stessa cartella o organizzazione padre della risorsa CapabilityConfig e non può già fungere da progetto di gestione per un'altra risorsa CapabilityConfig. Se in un secondo momento elimini la risorsa CapabilityConfig, Resource Manager conserva il progetto autogestito e lo ripristina come progetto standard.
• Progetto di gestione gestito da Google: ometti il flag --management-project quando crei la risorsa CapabilityConfig e Resource Manager crea e gestisce automaticamente un nuovo progetto per te nella cartella o nell'organizzazione principale. Il progetto generato ha un prefisso dell'ID progetto google-mpf o google-mpo. Se in un secondo momento elimini la risorsa CapabilityConfig, Resource Manager elimina questo progetto gestito da Google.

In entrambi i casi, la creazione della risorsa CapabilityConfig con agent-management attiva automaticamente agentregistry.googleapis.com nel progetto di gestione.

Progetti dei membri

I progetti membri sono i progetti Google Cloud che appartengono a un confine di gestione. Possono essere tutti i progetti figlio nella cartella o nell'organizzazione padre del confine o i progetti figlio che corrispondono a un filtro facoltativo dei tag del confine, ad esempio env=prod. Gli agenti, i server MCP e gli strumenti rilevati automaticamente vengono eseguiti nei progetti membri.

I progetti membri mantengono le proprie risorse di computing locali, come i motori di ragionamento Agent Runtime, i servizi Cloud Run o i cluster GKE. Le risorse rilevate automaticamente vengono importate localmente all'interno di ogni progetto membro e aggregate nel progetto di gestione quando elenchi o cerchi nel registry. Al contrario, le risorse registrate manualmente che crei in un progetto membro sono visibili solo quando invii una richiesta a quel singolo progetto membro.

L'associazione di progetti membri a un progetto di gestione in un confine è soggetta ai limiti di sistema. Il superamento di questo limite può causare errori di aggregazione. Per saperne di più, consulta Quote e limiti di sistema.

Registrazione e aggregazione

Il rilevamento tra progetti in Agent Registry distingue tra le risorse rilevate automaticamente di cui è stato eseguito il deployment nei progetti membri e le risorse registrate manualmente con ambito nel progetto in cui vengono create.

Risorse rilevate e registrate automaticamente

L'ambito di una risorsa all'interno di un confine di gestione dipende dal modo in cui viene registrata:

• Agenti e server MCP rilevati automaticamente: il deployment delle risorse supportate viene eseguito nei progetti membri, ad esempio i motori di ragionamento di Agent Runtime, i servizi Cloud Run e i deployment GKE, vengono importati automaticamente nel progetto membro in cui viene eseguito il deployment e aggregati nel progetto di gestione.

• Risorse e associazioni registrate manualmente: le risorse Service registrate manualmente, come agenti personalizzati, server MCP esterni, endpoint e risorse Binding, hanno come ambito il progetto in cui vengono create:

  • Creale nel progetto di gestione se vuoi che siano visibili oltre il confine di gestione.
  • Creale in un progetto membro se vuoi che siano visibili solo all'interno di quel singolo progetto membro.

• Skill, publisher e applicazioni AI autonomi: le risorse autonome personalizzate Skill, SkillRevision, Publisher e AiApplication hanno come ambito il progetto in cui vengono create e non vengono aggregate tra i progetti membri in un confine di gestione. Registra skill autonome personalizzate e applicazioni di AI nel progetto in cui i tuoi agenti o sviluppatori devono scoprirle. Le skill autonome gestite da Google sono rilevabili automaticamente in qualsiasi progetto.

Rollup centralizzato delle query

Il modo in cui Agent Registry definisce l'ambito delle località dipende dal fatto che tu esegua una query su un progetto di governance autonomo o su un progetto membro o di gestione in un confine di gestione:

• Progetti di governance autonomi e progetti membri: le query in una località supportata dal registro degli agenti, come us-central1, europe-west1, us, eu o global, restituiscono solo le risorse in quella località per quel singolo progetto, senza aggregazione tra progetti.

• Progetto di gestione: quando abiliti una risorsa CapabilityConfig con agent-management in un progetto di gestione, il rollup tra progetti è supportato in tutte le località supportate da Agent Registry. L'esecuzione di query su una località nel progetto di gestione aggrega le risorse nella stessa località nel progetto di gestione e in tutti i progetti membri nel confine di gestione. Questo rollup non include risorse in località diverse:

  • Singole regioni: le query in una singola regione, ad esempio us-central1 o europe-west1, aggregano gli agenti e i server MCP rilevati automaticamente di cui è stato eseguito il deployment in quella singola regione nel progetto di gestione e nei relativi progetti membri, insieme alle risorse Service e Binding create in quella regione nel progetto di gestione.
  • Multiregione: le query in una multiregione, ad esempio us o eu, aggregano gli agenti rilevati automaticamente e i server MCP di cui è stato eseguito il deployment in quella multiregione nel progetto di gestione e nei relativi progetti membri. Le query multiregione non aggregano le risorse di cui è stato eseguito il deployment in singole regioni.
  • Globale: le query nella località global aggregano gli agenti e i server MCP rilevati automaticamente di cui è stato eseguito il deployment in global nel progetto di gestione e nei relativi progetti membri, insieme alle risorse Service e Binding create in global nel progetto di gestione. Le query in global non aggregano le risorse di cui è stato eseguito il deployment in più regioni o in singole regioni.

Quando elenchi, cerchi o recuperi componenti agentici in una località del progetto di gestione, Agent Registry esegue i seguenti passaggi:

1. Identifica tutti i progetti membri associati al progetto di gestione tramite la risorsa CapabilityConfig attiva.
2. Esegue query sugli agenti e sui server MCP rilevati automaticamente in quella località nel progetto di gestione e in ogni progetto membro, insieme a tutte le risorse Service registrate manualmente create in quella località nel progetto di gestione.
3. Aggrega le risorse corrispondenti in un set di risultati unificato.
4. Restituisce i risultati aggregati.

Se alla stessa risorsa CapabilityConfig sono collegati più confini, Agent Registry aggrega i progetti membri di tutti i confini collegati nello stesso registry dei progetti di gestione. Per restringere l'elenco o i risultati di ricerca nel progetto di gestione a un singolo progetto membro, passa --filter="project_id=MEMBER_PROJECT_ID". Se due ambienti richiedono una visibilità separata, crea una risorsa CapabilityConfig e un progetto di gestione separati per ogni confine.

Il discovery per un singolo progetto e il discovery tra progetti utilizzano metodi API identici. L'ambito della ricerca dipende dal fatto che il progetto target sia un progetto membro o un progetto di gestione.

Nomi delle risorse oltre un confine di gestione

Quando un componente è incluso in un progetto membro, Agent Registry gli assegna un ID, ad esempio AGENT_ID o SERVER_ID. Quando elenchi, cerchi o recuperi un componente all'interno di un confine di gestione, Agent Registry conserva l'ID del componente e formatta il nome della risorsa associato in base al progetto che utilizzi:

• Progetto di gestione: quando elenchi, cerchi o recuperi i componenti utilizzando il progetto di gestione, ogni nome risorsa utilizza il progetto di gestione.
• Progetto membro: quando elenchi, cerchi o recuperi i componenti utilizzando il progetto membro in cui è stato eseguito il deployment della risorsa, ogni nome della risorsa utilizza quel progetto membro.

La tabella seguente mostra l'URL della richiesta e il nome della risorsa associata per le risorse rilevate automaticamente di cui è stato eseguito il deployment in un progetto membro:

Tipo di risorsa	Richiedi URL	Nome della risorsa associata
Agent	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
	projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID	projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
Server MCP	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID
	projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID	projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID

Il nome della risorsa associata riflette il progetto nella richiesta. Tuttavia, l'identificatore del registry e il riferimento di runtime del componente rimangono immutabili e conservano sempre il progetto membro in cui viene eseguito il workload sottostante.

Visualizzazione della topologia e flussi di traffico

Gli amministratori della piattaforma e gli AI architect possono visualizzare le relazioni tra più agenti e il traffico tra progetti utilizzando il grafico della topologia.

Il grafico della topologia visualizza le seguenti dimensioni dell'architettura:

• Correlazione del riferimento di runtime: mette in correlazione l'identificatore dell'agente logico con il relativo riferimento di runtime fisico. Questa correlazione consente agli operatori di tracciare un agente in Agent Registry direttamente al motore di ragionamento Agent Runtime, al servizio Cloud Run o al deployment GKE sottostante.
• Associazioni tra progetti: mostra le associazioni tra gli agenti orchestratore in un progetto e i server MCP o gli strumenti downstream in un altro progetto.
• Verifica del perimetro: aiuta gli amministratori a verificare che le comunicazioni degli agenti siano conformi ai perimetri dei Controlli di servizio VPC e vengano instradate attraverso gli endpoint Agent Gateway designati.

Controllo degli accessi

In un confine di gestione, concedi i ruoli di rilevamento IAM nel progetto di gestione in modo che gli utenti e gli orchestratori possano eseguire ricerche all'interno del confine senza richiedere l'accesso IAM diretto ai singoli progetti membri. Poiché le risorse Service e Binding registrate manualmente create in un progetto membro non vengono aggregate nel progetto di gestione, gli amministratori della sicurezza possono anche limitare la creazione locale di Service e Binding nei progetti membri utilizzando un vincolo della policy dell'organizzazione o una policy di negazione IAM. Quando gli agenti nei progetti membri richiamano strumenti o comunicano con gli agenti in altri progetti oltre il confine, il traffico può essere instradato attraverso un Agent Gateway centrale.

Per le risorse in un confine di gestione, le limitazioni dei Controlli di servizio VPC si applicano solo alle interazioni di Agent Registry nel progetto di gestione. Agent Registry può rilevare agenti e server MCP in tutti i progetti membri nel confine di gestione, anche se questi progetti membri non si trovano nello stesso perimetro di servizio del progetto di gestione.

Per saperne di più sui ruoli richiesti per la configurazione dei confini, l'accesso al registry e le limitazioni di scrittura dei progetti membri, consulta Ruoli per i confini di gestione tra progetti.

Passaggi successivi

• Configura i confini di gestione in Resource Manager.
• Scopri di più sul modello di dati tra progetti.
• Eseguire ricerche tra ambiti di gestione.
• Esamina Ruoli e autorizzazioni per Agent Registry.