Projektübergreifende Grenzen

Mit projektübergreifenden Verwaltungsgrenzen (oder Grenzen) können Sie KI-Agenten, MCP-Server (Model Context Protocol) und Tools in mehreren Google Cloud -Projekten finden, verwalten und steuern. Agent Registry wird standardmäßig in einem einzelnen Governance-Projekt ausgeführt. Wenn Sie jedoch eine Verwaltungsgrenze in Resource Manager konfigurieren, kann ein zentrales Verwaltungsprojekt KI-Agenten, MCP-Server und Tools über verteilte Mitgliedsprojekte hinweg aggregieren. Wenn Sie wissen, wie Verwaltungsgrenzen Projektrollen, Ressourcenaggregation und Zugriffssteuerung strukturieren, können Sie skalierbare Topologien mit mehreren Projekten entwerfen.

Informationen zum Konfigurieren einer Verwaltungsgrenze finden Sie unter Verwaltungsgrenze für mehrere Projekte konfigurieren.

Boundary-Modell

Sie definieren eine Verwaltungsgrenze für einen Ordner oder eine Organisation in Resource Manager:

  • Ordner- oder organisationsweite Begrenzung: Wenn Sie eine Begrenzung für einen Ordner oder eine Organisation erstellen, ohne einen Tag-Filter zu konfigurieren, enthält die Begrenzung standardmäßig alle untergeordneten Projekte in diesem Ordner oder dieser Organisation als Mitgliedsprojekte.
  • Nach Tags gefilterte Grenzen (optional): Optional können Sie untergeordnete Projekte in einem Ordner oder einer Organisation in mehrere Grenzen aufteilen. Dazu filtern Sie die Mitgliedschaft in Grenzen mithilfe von Resource Manager-Tags. Sie können beispielsweise prod- und dev-Umgebungen trennen. Sie hängen Tags an dieGoogle Cloud -Projekte an, die Sie in die einzelnen Grenzen aufnehmen möchten. Wenn ein untergeordnetes Projekt im Ordner oder in der Organisation ein Tag hat, das mit dem Grenzfilter übereinstimmt, wird dieses Projekt zu einem Mitgliedsprojekt der Verwaltungsgrenze.

Wenn Sie Tags verwenden, um Verwaltungsgrenzen zu partitionieren, bieten Tags die folgenden Vorteile:

  • Dynamische, automatisierte Registrierung: In Cloud-Umgebungen werden Projekte häufig geändert. Wenn Sie ein Projekt mit einem registrierten Tag-Wert wie env=prod taggen, fügt Agent Registry dieses Projekt automatisch als Mitgliedsprojekt in die Grenze ein, ohne dass manuelle Aktualisierungen der Grenzdefinitionen erforderlich sind.
  • Entkopplung von Ordnerhierarchien: Resource Manager-Ordnerstrukturen sind in der Regel für Abrechnungs- oder Geschäftszwecke organisiert. Tags entkoppeln Grenzdefinitionen von physischen Ordnerhierarchien, sodass Sie ordnerübergreifende Verwaltungsperimeter in einem übergeordneten Ordner oder einer übergeordneten Organisation einrichten können.
  • Übernahme und Skalierbarkeit: Tags, die auf eine Organisation oder einen Ordner angewendet werden, werden automatisch in der Ressourcenhierarchie an untergeordnete Ordner und Projekte weitergegeben. Mit diesem Vererbungsmodell können Sie ganze Zweige Ihres Ressourcenbaums mit einer einzigen Tag-Zuweisung registrieren.
  • Zentralisierte Governance: Tags werden durch zentralisierte IAM-Berechtigungen (Identity and Access Management) gesteuert. Wenn Sie Tags verwenden, um Verwaltungsgrenzen zu definieren, können Sie verhindern, dass einzelne Nutzer Projekte willkürlich hinzufügen oder entfernen.

Architektur und wichtige Ressourcen

Eine projektübergreifende Verwaltungsgrenze basiert auf den folgenden Resource Manager-Ressourcen:

  • Grenzkonfiguration (BoundaryConfig-Ressource): Eine Konfigurationsressource für eine Organisation oder einen Ordner in Resource Manager, die die Regeln für die Grenzpartitionierung in diesem Ordner oder dieser Organisation festlegt. Wenn Sie keinen Tag-Schlüssel für die BoundaryConfig-Ressource festlegen, unterstützt die Organisation oder der Ordner eine einzelne Grenze, die alle untergeordneten Projekte umfasst. Wenn Sie untergeordnete Projekte in mehrere taggefilterte Grenzen aufteilen möchten, gibt die Ressource BoundaryConfig den einzelnen Ressourcentagschlüssel an, z. B. 123456789012/env, der zur Bewertung der Projektmitgliedschaft in diesem Ordner oder dieser Organisation verwendet wird.

  • Grenze (Boundary-Ressource): Ein Perimeter von Mitgliedsprojekten in einer Organisation oder einem Ordner. Ohne Tag-Filter umfasst die Grenze alle untergeordneten Projekte in der übergeordneten Organisation oder im übergeordneten Ordner. Wenn Sie einen Tag-Schlüssel für die übergeordnete BoundaryConfig-Ressource konfigurieren, gibt die Boundary-Ressource einen Tag-Wertfilter wie env=prod an. Untergeordnete Projekte, die diesen Tag-Wert übernehmen oder anhängen, gehören automatisch zur Grenze. Da die BoundaryConfig-Ressource eines übergeordneten Elements einen einzelnen Tag-Schlüssel verwendet und ein Projekt nur einen effektiven Tag-Wert pro Tag-Schlüssel haben kann, kann ein Projekt höchstens zu einer Grenze pro übergeordnetem Ordner oder übergeordneter Organisation gehören.

  • Funktionskonfiguration (CapabilityConfig-Ressource): Eine Ressource, die für eine Organisation, einen Ordner oder ein Projekt definiert ist. Auf Organisations- oder Ordnerebene werden ein oder mehrere Bereiche an ein dediziertes Verwaltungsprojekt gebunden und die Verwaltungsfunktionen angegeben, die für diese Bereiche aktiviert sind. Auf Projektebene ermöglicht sie Verwaltungsfunktionen für ein einzelnes eigenständiges Projekt ohne Grenzen. Für die Agent Registry konfigurieren Sie die Funktion AGENT_MANAGEMENT (Google Cloud CLI: agent-management), die eine zentrale Komponentenerkennung, Such-Roll-ups und projektübergreifende Governance in der Agent Registry ermöglicht und agentregistry.googleapis.com automatisch im Verwaltungsprojekt aktiviert.

Weitere Informationen zu diesen Resource Manager-Ressourcen finden Sie unter Übersicht über Verwaltungsgrenzen und -funktionen.

Das folgende Diagramm zeigt, wie Resource Manager-Ressourcen Mitgliedsprojekte mit einem zentralen Verwaltungsprojekt verbinden:

Diagramm, das zeigt, wie Cloud Resource Manager-Ressourcen Mitgliedsprojekte mit einem zentralen Verwaltungsprojekt verknüpfen.
Abbildung 1. Architektur einer projektübergreifenden Verwaltungsgrenze, die Mitgliedsprojekte mit einem zentralen Verwaltungsprojekt verbindet.

Verwaltung mehrerer Projekte

Eine Verwaltungsgrenze trennt die administrative Governance von der Compute-Ausführung über zwei verschiedene Projektrollen: ein zentrales Verwaltungsprojekt und ein oder mehrere Mitgliedsprojekte.

Diese entkoppelte Struktur erzwingt die Isolation von Mandanten. Teams erstellen und stellen KI-Agenten in ihren jeweiligen Mitgliedsprojekten bereit, ohne direkten Zugriff auf andere Mitgliedsprojekte zu benötigen. Administratoren und Orchestratoren behalten über die Verwaltungsgrenze des Verwaltungsprojekts hinweg eine einheitliche Sicht.

Verwaltungsprojekt

Ein Verwaltungsprojekt ist ein Google Cloud -Projekt, das als zentrales Governance-Projekt für eine Verwaltungsgrenze dient. Sie zentralisiert die API-Konfiguration, die Zugriffssteuerung, die Abrechnung, den Kontingentverbrauch und die aggregierten Komponentenmetadaten über die Grenze hinweg, ohne dass zugrunde liegende Computing-Laufzeiten gehostet werden müssen.

In der Agent Registry übernimmt das Verwaltungsprojekt die folgenden Funktionen:

  • Grenz- und Funktionsbindung: Wird über eine CapabilityConfig-Ressource mit aktivierter AGENT_MANAGEMENT-Funktion mit einer oder mehreren Grenzen in Resource Manager verknüpft. Die Konfigurationsschritte finden Sie unter Verwaltungsgrenzen konfigurieren.
  • Zentrale Erkennung und Suche: Dient als Zielprojekt für projektübergreifende Listen- und Suchanfragen. So können Orchestratoren, Entwickler und Clientanwendungen mit automatisch erkannten KI-Agenten, MCP-Servern und Tools in allen Mitgliedsprojekten innerhalb der Grenze interagieren.
  • Grenzweite Ressourcenregistrierung: Hostet manuell registrierte Service-Ressourcen wie benutzerdefinierte Agenten, externe MCP-Server und Endpunkte sowie Binding-Ressourcen, wenn diese Ressourcen über die Verwaltungsgrenze hinweg sichtbar sein sollen.
  • Zentrale API-, Abrechnungs- und Kontingentverwaltung: Konsolidiert die Aktivierung der Agent Registry API, die Kontingentzuweisung und die Abrechnung für Erkennungs- und Governance-Vorgänge auf Grenzebene.

Wenn Sie eine CapabilityConfig-Ressource für einen Ordner oder eine Organisation in Resource Manager konfigurieren, können Sie Ihr Verwaltungsprojekt auf eine der folgenden Arten bereitstellen:

  • Selbstverwaltetes Verwaltungsprojekt: Sie legen ein vorhandenesGoogle Cloud -Projekt fest, das Sie verwalten, indem Sie beim Erstellen der CapabilityConfig-Ressource das Flag --management-project übergeben. Das Projekt muss sich direkt im selben übergeordneten Ordner oder in derselben Organisation wie die CapabilityConfig-Ressource befinden und darf nicht bereits als Verwaltungsprojekt für eine andere CapabilityConfig-Ressource dienen. Wenn Sie die Ressource CapabilityConfig später löschen, behält Resource Manager Ihr selbstverwaltetes Projekt bei und setzt es auf ein Standardprojekt zurück.
  • Von Google verwaltetes Verwaltungsprojekt: Sie lassen das Flag --management-project beim Erstellen der Ressource CapabilityConfig weg und Resource Manager erstellt und verwaltet automatisch ein neues Projekt für Sie im übergeordneten Ordner oder in der übergeordneten Organisation. Das generierte Projekt hat das Projekt-ID-Präfix google-mpf oder google-mpo. Wenn Sie die Ressource CapabilityConfig später löschen, löscht Resource Manager dieses von Google verwaltete Projekt.

In beiden Fällen wird durch das Erstellen der CapabilityConfig-Ressource mit agent-management automatisch agentregistry.googleapis.com im Verwaltungsprojekt aktiviert.

Mitgliedsprojekte

Mitgliedsprojekte sind die Google Cloud -Projekte, die zu einer Verwaltungsgrenze gehören. Dies können entweder alle untergeordneten Projekte im übergeordneten Ordner oder in der übergeordneten Organisation der Begrenzung oder die untergeordneten Projekte sein, die einem optionalen Begrenzungs-Tag-Filter wie env=prod entsprechen. Automatisch erkannte Agenten, MCP-Server und Tools werden in Mitgliedsprojekten ausgeführt.

Mitgliedsprojekte behalten ihre eigenen lokalen Rechenressourcen, z. B. Agent Runtime-Reasoning-Engines, Cloud Run-Dienste oder GKE-Cluster. Automatisch erkannte Ressourcen werden lokal in jedem Mitgliedsprojekt aufgenommen und im Verwaltungsprojekt zusammengefasst, wenn Sie die Registry auflisten oder durchsuchen. Manuell registrierte Ressourcen, die Sie in einem Mitgliedsprojekt erstellen, sind dagegen nur sichtbar, wenn Sie eine Anfrage an dieses einzelne Mitgliedsprojekt senden.

Die Verknüpfung von Mitgliedsprojekten mit einem Verwaltungsprojekt in einer Begrenzung unterliegt Systemlimits. Das Überschreiten dieses Limits kann zu Rollup-Fehlern führen. Weitere Informationen finden Sie unter Kontingente und Systemlimits.

Registrierung und Rollup

Bei der projektübergreifenden Erkennung in der Agent Registry wird zwischen automatisch erkannten Ressourcen, die in Mitgliedsprojekten bereitgestellt werden, und manuell registrierten Ressourcen unterschieden, die auf das Projekt beschränkt sind, in dem sie erstellt werden.

Automatisch erkannte und registrierte Ressourcen

Wie eine Ressource über eine Verwaltungsgrenze hinweg definiert wird, hängt davon ab, wie sie registriert ist:

  • Automatisch erkannte KI-Agenten und MCP-Server: Unterstützte Ressourcen, die in Mitgliedsprojekten bereitgestellt werden, z. B. Agent Runtime-Reasoning-Engines, Cloud Run-Dienste und GKE-Bereitstellungen, werden automatisch in das Mitgliedsprojekt aufgenommen, in dem sie bereitgestellt werden, und im Verwaltungsprojekt zusammengefasst.

  • Manuell registrierte Ressourcen und Bindungen: Manuell registrierte Service-Ressourcen wie benutzerdefinierte KI-Agenten, externe MCP-Server, Endpunkte und Binding-Ressourcen sind auf das Projekt beschränkt, in dem sie erstellt werden:

    • Erstellen Sie sie im Verwaltungsprojekt, wenn sie über die Verwaltungsgrenze hinweg sichtbar sein sollen.
    • Erstellen Sie sie in einem Mitgliedsprojekt, wenn sie nur innerhalb dieses einzelnen Mitgliedsprojekts sichtbar sein sollen.

  • Eigenständige Skills, Publisher und KI-Anwendungen: Benutzerdefinierte eigenständige Skill-, SkillRevision-, Publisher- und AiApplication-Ressourcen sind auf das Projekt beschränkt, in dem sie erstellt werden, und werden nicht über Mitgliedsprojekte in einer Verwaltungsgrenze hinweg aggregiert. Registrieren Sie benutzerdefinierte eigenständige Skills und KI-Anwendungen in dem Projekt, in dem Ihre KI-Agenten oder Entwickler sie finden müssen. Von Google verwaltete eigenständige Skills sind in jedem Projekt automatisch auffindbar.

Zentralisiertes Abfrage-Roll-up

Wie die Agent Registry den Bereich für Standorte festlegt, hängt davon ab, ob Sie ein eigenständiges Governance-Projekt oder ein Mitgliedsprojekt oder Verwaltungsprojekt in einer Verwaltungsgrenze abfragen:

  • Eigenständige Governance-Projekte und Mitgliedsprojekte: Abfragen an einem von der Agent Registry unterstützten Standort, z. B. us-central1, europe-west1, us, eu oder global, geben nur Ressourcen an diesem Standort für dieses einzelne Projekt zurück, ohne projektübergreifende Zusammenfassung.

  • Verwaltungsprojekt: Wenn Sie eine CapabilityConfig-Ressource mit agent-management in einem Verwaltungsprojekt aktivieren, wird das projektübergreifende Roll-up an allen von der Agent Registry unterstützten Standorten unterstützt. Wenn Sie einen Standort im Verwaltungsprojekt abfragen, werden Ressourcen an diesem Standort im Verwaltungsprojekt und in allen Mitgliedsprojekten innerhalb der Verwaltungsgrenze zusammengefasst. Diese Zusammenfassung enthält keine Ressourcen an verschiedenen Standorten:

    • Einzelne Regionen: Abfragen in einer einzelnen Region, z. B. us-central1 oder europe-west1, aggregieren automatisch erkannte Agents und MCP-Server, die in dieser einzelnen Region im Verwaltungsprojekt und seinen Mitgliedsprojekten bereitgestellt wurden, sowie Service- und Binding-Ressourcen, die in dieser Region im Verwaltungsprojekt erstellt wurden.
    • Multiregionen: Abfragen in einer Multiregion wie us oder eu aggregieren automatisch erkannte KI-Agenten und MCP-Server, die in dieser Multiregion im Verwaltungsprojekt und seinen Mitgliedsprojekten bereitgestellt wurden. Abfragen in Multiregionen aggregieren keine Ressourcen, die in einzelnen Regionen bereitgestellt werden.
    • Global: Abfragen am Standort global fassen automatisch erkannte Agents und MCP-Server zusammen, die in global im Verwaltungsprojekt und seinen Mitgliedsprojekten bereitgestellt wurden, zusammen mit Service- und Binding-Ressourcen, die in global im Verwaltungsprojekt erstellt wurden. Abfragen in global aggregieren keine Ressourcen, die in multiregionalen oder einzelnen Regionen bereitgestellt wurden.

Wenn Sie agentische Komponenten an einem Standort im Verwaltungsprojekt auflisten, suchen oder abrufen, führt die Agent Registry die folgenden Schritte aus:

  1. Identifiziert alle Mitgliedsprojekte, die über die aktive CapabilityConfig-Ressource mit dem Verwaltungsprojekt verknüpft sind.
  2. Fragt automatisch erkannte KI-Agenten und MCP-Server an diesem Standort im Verwaltungsprojekt und in jedem Mitgliedsprojekt ab, zusammen mit allen manuell registrierten Service-Ressourcen, die an diesem Standort im Verwaltungsprojekt erstellt wurden.
  3. Fasst übereinstimmende Ressourcen in einem einheitlichen Ergebnissatz zusammen.
  4. Gibt die aggregierten Ergebnisse an Sie zurück.

Wenn mehrere Grenzen an dieselbe CapabilityConfig-Ressource angehängt sind, fasst die Agent Registry Mitgliedsprojekte aus allen angehängten Grenzen in derselben Verwaltungsprojekt-Registry zusammen. Wenn Sie die Liste oder die Suchergebnisse im Verwaltungsprojekt auf ein einzelnes Mitgliedsprojekt beschränken möchten, übergeben Sie --filter="project_id=MEMBER_PROJECT_ID". Wenn zwei Umgebungen eine separate Sichtbarkeit erfordern, erstellen Sie für jede Grenze eine separate CapabilityConfig-Ressource und ein separates Verwaltungsprojekt.

Für die Erkennung in einem einzelnen Projekt und die projektübergreifende Erkennung werden dieselben API-Methoden verwendet. Der Umfang der Suche hängt davon ab, ob das Zielprojekt ein Mitgliedsprojekt oder ein Verwaltungsprojekt ist.

Ressourcennamen über eine Verwaltungsgrenze hinweg

Wenn eine Komponente in einem Mitgliedsprojekt enthalten ist, weist Agent Registry ihr eine ID wie AGENT_ID oder SERVER_ID zu. Wenn Sie eine Komponente über eine Verwaltungsgrenze hinweg auflisten, suchen oder abrufen, behält die Agent Registry die ID dieser Komponente bei und formatiert den zugehörigen Ressourcennamen basierend auf dem von Ihnen verwendeten Projekt:

  • Verwaltungsprojekt: Wenn Sie Komponenten mit dem Verwaltungsprojekt auflisten, suchen oder abrufen, wird für jeden Ressourcennamen das Verwaltungsprojekt verwendet.
  • Mitgliedsprojekt: Wenn Sie Komponenten mit dem Mitgliedsprojekt auflisten, suchen oder abrufen, in dem die Ressource bereitgestellt wird, wird für jeden Ressourcennamen dieses Mitgliedsprojekt verwendet.

In der folgenden Tabelle sind die Anfrage-URL und der zugehörige Ressourcenname für automatisch erkannte Ressourcen aufgeführt, die in einem Mitgliedsprojekt bereitgestellt werden:

Ressourcentyp URL beantragen Name der verknüpften Ressource
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
MCP-Server 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

Der zugehörige Ressourcenname spiegelt das Projekt in Ihrer Anfrage wider. Die Registry-ID und die Laufzeitreferenz der Komponente bleiben jedoch unveränderlich und behalten immer das Mitgliedsprojekt bei, in dem die zugrunde liegende Arbeitslast ausgeführt wird.

Topologievisualisierung und Traffic-Flüsse

Plattformadministratoren und KI-Architekten können Multi-Agenten-Beziehungen und projektübergreifenden Traffic mithilfe des Topologie-Diagramms visualisieren.

Das Topologie-Diagramm visualisiert die folgenden Architekturdimensionen:

  • Laufzeitreferenz-Korrelation: Korreliert die logische Agent-Kennung mit ihrer physischen Laufzeitreferenz. Durch diese Verknüpfung können Operatoren einen KI-Agenten in der Agent Registry direkt auf die zugrunde liegende Reasoning Engine der Agent Runtime, den Cloud Run-Dienst oder das GKE-Deployment zurückführen.
  • Projektübergreifende Bindungen: Zeigt Bindungen zwischen Orchestrator-Agenten in einem Projekt und MCP-Servern oder nachgelagerten Tools in einem anderen Projekt an.
  • Perimeterprüfung: Hilft Administratoren, zu prüfen, ob die Agentenkommunikation den VPC Service Controls-Perimetern entspricht und über die angegebenen Agent Gateway-Endpunkte weitergeleitet wird.

Zugriffssteuerung

In einer Verwaltungsgrenze gewähren Sie IAM-Erkennungsrollen für das Verwaltungsprojekt, damit Nutzer und Orchestratoren über die Grenze hinweg suchen können, ohne direkten IAM-Zugriff auf einzelne Mitgliedsprojekte zu benötigen. Da manuell registrierte Service- und Binding-Ressourcen, die in einem Mitgliedsprojekt erstellt wurden, nicht im Verwaltungsprojekt zusammengefasst werden, können Sicherheitsadministratoren auch die lokale Erstellung von Service und Binding in Mitgliedsprojekten mithilfe einer Einschränkung für Organisationsrichtlinien oder einer IAM-Ablehnungsrichtlinie einschränken. Wenn Agenten in Mitgliedsprojekten Tools aufrufen oder mit Agenten in anderen Projekten über die Grenze hinweg kommunizieren, kann der Traffic über ein zentrales Agent Gateway geleitet werden.

Für Ressourcen in einer Verwaltungsgrenze gelten die Einschränkungen von VPC Service Controls nur für Agent Registry-Interaktionen im Verwaltungsprojekt. Agent Registry kann Agenten und MCP-Server in allen Mitgliedsprojekten innerhalb der Verwaltungsgrenze erkennen, auch wenn sich diese Mitgliedsprojekte nicht im selben Dienstperimeter wie das Verwaltungsprojekt befinden.

Weitere Informationen zu den Rollen, die für die Einrichtung von Grenzen, den Zugriff auf die Registry und die Schreibbeschränkungen für Mitgliedsprojekte erforderlich sind, finden Sie unter Rollen für projektübergreifende Verwaltungsgrenzen.

Nächste Schritte