Límites entre proyectos

Vista previa

Este producto o función está sujeto a las "Condiciones de la Oferta de la Fase Previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles “tal como están” y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Los límites de administración entre proyectos (o límites) te permiten descubrir, administrar y controlar agentes de IA, servidores del Protocolo de contexto del modelo (MCP) y herramientas en varios proyectos de Google Cloud . Agent Registry opera dentro de un solo proyecto de administración de forma predeterminada, pero configurar un límite de administración en Resource Manager permite que un proyecto de administración central agregue agentes, servidores de MCP y herramientas en proyectos de miembros distribuidos. Comprender cómo los límites de administración estructuran los roles del proyecto, la agregación de recursos y el control de acceso te ayuda a diseñar topologías de varios proyectos escalables.

Para configurar un límite de administración, consulta Configura un límite de administración para varios proyectos.

Modelo de límites

Define un límite de administración en una carpeta o una organización en Resource Manager:

• Límite de toda la carpeta o de toda la organización: De forma predeterminada, si creas un límite en una carpeta o una organización sin configurar un filtro de etiquetas, el límite incluye todos los proyectos secundarios de esa carpeta u organización como proyectos miembros.
• Límites filtrados por etiquetas (opcional): De manera opcional, para particionar proyectos secundarios en una carpeta o una organización en varios límites, puedes filtrar la membresía de límites con etiquetas de Resource Manager. Por ejemplo, puedes separar los entornos de prod y dev. Adjuntas etiquetas a los proyectos deGoogle Cloud que quieres incluir en cada límite. Cuando un proyecto secundario de la carpeta o la organización tiene una etiqueta que coincide con el filtro de límite, ese proyecto se convierte en un proyecto miembro del límite de administración.

Cuando usas etiquetas para particionar los límites de administración, las etiquetas proporcionan los siguientes beneficios:

• Inscripción dinámica y automatizada: Los entornos de nube modifican con frecuencia los proyectos. Cuando etiquetas un proyecto con un valor de etiqueta inscrito, como env=prod, Agent Registry incluye automáticamente ese proyecto como un proyecto miembro en el límite sin necesidad de actualizar manualmente las definiciones de límite.
• Desvinculación de las jerarquías de carpetas: Las estructuras de carpetas de Resource Manager suelen organizarse con fines de facturación o empresariales. Las etiquetas desvinculan las definiciones de límites de las jerarquías de carpetas físicas, lo que te permite establecer perímetros de administración entre carpetas en una organización o carpeta superior.
• Herencia y escalabilidad: Las etiquetas aplicadas a una organización o carpeta se propagan automáticamente por la jerarquía de recursos a las carpetas y los proyectos secundarios. Este modelo de herencia te permite inscribir ramas completas de tu árbol de recursos con una sola asignación de etiqueta.
• Administración centralizada: Las etiquetas se rigen por permisos centralizados de Identity and Access Management (IAM). Si usas etiquetas para definir los límites de administración, puedes evitar que los usuarios individuales agreguen o quiten proyectos del límite de forma arbitraria.

Arquitectura y recursos clave

Un límite de administración entre proyectos se basa en los siguientes recursos de Resource Manager:

• Configuración de límites (recurso BoundaryConfig): Es un recurso de configuración en una organización o carpeta de Resource Manager que establece las reglas de partición de límites en esa carpeta u organización. Si no estableces una clave de etiqueta en el recurso BoundaryConfig, la organización o carpeta admite un solo límite que incluye todos sus proyectos secundarios. Para particionar los proyectos secundarios en varios límites filtrados por etiquetas, el recurso BoundaryConfig especifica la clave de etiqueta de recurso única, como 123456789012/env, que se usa para evaluar la membresía del proyecto en esa carpeta u organización.

• Límite (recurso Boundary): Es un perímetro de proyectos miembros en una organización o carpeta. Sin un filtro de etiquetas, el límite incluye todos los proyectos secundarios de la organización o carpeta superior. Cuando configuras una clave de etiqueta en el recurso BoundaryConfig superior, el recurso Boundary especifica un filtro de valor de etiqueta, como env=prod, y los proyectos secundarios que heredan o adjuntan ese valor de etiqueta pertenecen al límite de forma automática. Debido a que el recurso BoundaryConfig de un elemento superior usa una sola clave de etiqueta y un proyecto puede tener solo un valor de etiqueta efectivo por clave de etiqueta, un proyecto puede pertenecer como máximo a un límite por carpeta o organización superior.

• Configuración de capacidad (recurso CapabilityConfig): Es un recurso definido en una organización, una carpeta o un proyecto. A nivel de organización o carpeta, vincula uno o más límites a un proyecto de administración dedicado y especifica las capacidades de administración habilitadas en esos límites. A nivel de proyecto, habilita las capacidades de administración para un solo proyecto independiente sin límites. Para Agent Registry, configura la capacidad AGENT_MANAGEMENT (Google Cloud CLI: agent-management), que habilita el descubrimiento centralizado de componentes, los resúmenes de búsqueda y la administración entre proyectos en Agent Registry, y habilita automáticamente agentregistry.googleapis.com en el proyecto de administración.

Para obtener más información sobre estos recursos de Resource Manager, consulta Descripción general de los límites y las capacidades de administración.

En el siguiente diagrama, se ilustra cómo los recursos de Resource Manager conectan los proyectos miembros con un proyecto de administración central:

Figura 1: Arquitectura de un límite de administración entre proyectos que conecta proyectos miembros con un proyecto de administración central.

Administración de varios proyectos

Un límite de administración separa la administración de la ejecución de procesamiento en dos roles de proyecto distintos: un proyecto de administración central y uno o más proyectos de miembros.

Esta estructura desacoplada aplica el aislamiento multiusuario. Los equipos compilan e implementan agentes en sus respectivos proyectos de miembros sin necesidad de acceder directamente a otros proyectos de miembros, y los administradores y coordinadores mantienen una visibilidad unificada en todo el límite de administración desde el proyecto de administración.

Proyecto de administración

Un proyecto de administración es un proyecto de Google Cloud que funciona como el proyecto de administración central para un límite de administración. Centraliza la configuración de la API, el control de acceso, la facturación, el consumo de cuotas y los metadatos de componentes agregados en todo el límite sin necesidad de alojar entornos de ejecución de procesamiento subyacentes.

En Agent Registry, el proyecto de administración realiza las siguientes funciones:

• Vinculación de límites y capacidades: Se asocia con uno o más límites en Resource Manager a través de un recurso CapabilityConfig con la capacidad AGENT_MANAGEMENT habilitada. Para conocer los pasos de configuración, consulta Configura límites de administración.
• Descubrimiento y búsqueda centralizados: Sirve como el proyecto de destino para las solicitudes de búsqueda y lista entre proyectos, lo que permite que los organizadores, los desarrolladores y las aplicaciones cliente interactúen con los agentes, los servidores de MCP y las herramientas descubiertos automáticamente en todos los proyectos miembros del límite.
• Registro de recursos en todo el límite: Aloja recursos de Service registrados de forma manual, como agentes personalizados, servidores de MCP externos y endpoints, y recursos de Binding cuando quieras que esos recursos sean visibles en todo el límite de administración.
• Administración centralizada de APIs, facturación y cuotas: Consolida la activación de la API de Agent Registry, la asignación de cuotas y la facturación para las operaciones de descubrimiento y administración a nivel de límite.

Cuando configuras un recurso CapabilityConfig en una carpeta o una organización en Resource Manager, puedes aprovisionar tu proyecto de administración de una de las siguientes maneras:

• Proyecto de administración autoadministrado: Designas un proyecto deGoogle Cloud existente que administras pasando la marca --management-project cuando creas el recurso CapabilityConfig. El proyecto debe residir directamente en la misma carpeta o organización superior que el recurso CapabilityConfig y no puede servir como un proyecto de administración para otro recurso CapabilityConfig. Si más adelante borras el recurso CapabilityConfig, Resource Manager conservará tu proyecto autoadministrado y lo revertirá a un proyecto estándar.
• Proyecto de administración gestionado por Google: Omites la marca --management-project cuando creas el recurso CapabilityConfig, y Resource Manager crea y administra automáticamente un proyecto nuevo para ti en la carpeta u organización superior. El proyecto generado tiene un prefijo de ID del proyecto de google-mpf o google-mpo. Si luego borras el recurso CapabilityConfig, Resource Manager borrará este proyecto administrado por Google.

En ambos casos, crear el recurso CapabilityConfig con agent-management habilita automáticamente agentregistry.googleapis.com en el proyecto de administración.

Proyectos de miembros

Los proyectos miembros son los proyectos de Google Cloud que pertenecen a un límite de administración. Pueden ser todos los proyectos secundarios de la carpeta o la organización superior del límite, o los proyectos secundarios que coincidan con un filtro de etiqueta de límite opcional, como env=prod. Los agentes, los servidores de MCP y las herramientas que se descubren automáticamente se ejecutan en los proyectos miembros.

Los proyectos miembros conservan sus propios recursos de procesamiento locales, como los motores de razonamiento de Agent Runtime, los servicios de Cloud Run o los clústeres de GKE. Los recursos descubiertos automáticamente se transfieren de forma local dentro de cada proyecto miembro y se agregan al proyecto de administración cuando enumeras o buscas en el registro. Por el contrario, los recursos registrados de forma manual que creas en un proyecto miembro solo son visibles cuando envías una solicitud a ese proyecto miembro individual.

La asociación de proyectos miembros con un proyecto de administración en un límite está sujeta a los límites del sistema. Si se supera este límite, se pueden producir errores de resumen. Para obtener más información, consulta Cuotas y límites del sistema.

Registro y resumen

El descubrimiento entre proyectos en el Registro de agentes distingue entre los recursos descubiertos automáticamente que se implementan en los proyectos miembros y los recursos registrados de forma manual que se limitan al proyecto en el que se crean.

Recursos detectados y registrados automáticamente

La forma en que se define el alcance de un recurso en un límite de administración depende de cómo se registra:

• Agentes y servidores de MCP detectados automáticamente: Los recursos compatibles implementados en proyectos miembros, como los motores de razonamiento de Agent Runtime, los servicios de Cloud Run y las implementaciones de GKE, se transfieren automáticamente al proyecto miembro en el que se implementan y se agregan al proyecto de administración.

• Recursos y vinculaciones registrados de forma manual: Los recursos de Service registrados de forma manual, como los agentes personalizados, los servidores de MCP externos, los endpoints y los recursos de Binding, tienen como alcance el proyecto en el que se crean:

  • Créalas en el proyecto de administración si quieres que sean visibles en todo el límite de administración.
  • Créalas en un proyecto miembro si deseas que solo sean visibles dentro de ese proyecto miembro.

• Habilidades, publicadores y aplicaciones de IA independientes: Los recursos personalizados independientes Skill, SkillRevision, Publisher y AiApplication se limitan al proyecto en el que se crean y no se agregan en los proyectos miembros de un límite de administración. Registra habilidades independientes personalizadas y aplicaciones de IA en el proyecto en el que tus agentes o desarrolladores necesiten descubrirlas. Las habilidades independientes administradas por Google se pueden descubrir en cualquier proyecto automáticamente.

Resumen de consultas centralizado

La forma en que el Registro de agentes define el alcance de las ubicaciones depende de si consultas un proyecto de administración independiente, un proyecto miembro o un proyecto de administración en un límite de administración:

• Proyectos de administración independientes y proyectos de miembros: Las consultas en una ubicación compatible con el registro de agentes, como us-central1, europe-west1, us, eu o global, solo devuelven recursos en esa ubicación para ese proyecto único, sin un resumen entre proyectos.

• Proyecto de administración: Cuando habilitas un recurso CapabilityConfig con agent-management en un proyecto de administración, el resumen entre proyectos es compatible en todas las ubicaciones compatibles con el registro de agentes. Cuando consultas una ubicación en el proyecto de administración, se agregan recursos en esa misma ubicación en el proyecto de administración y en todos los proyectos miembros del límite de administración. Este resumen no incluye recursos de diferentes ubicaciones:

  • Regiones individuales: Las consultas en una sola región, como us-central1 o europe-west1, agregan agentes detectados automáticamente y servidores de MCP implementados en esa región única en el proyecto de administración y sus proyectos miembros, junto con los recursos Service y Binding creados en esa región en el proyecto de administración.
  • Multirregiones: Las consultas en una multirregión, como us o eu, agregan agentes y servidores de MCP detectados automáticamente que se implementan en esa multirregión en el proyecto de administración y sus proyectos miembros. Las consultas en multirregiones no agregan recursos implementados en regiones individuales.
  • Global: Las consultas en la ubicación global agregan agentes y servidores de MCP descubiertos automáticamente que se implementan en global en el proyecto de administración y sus proyectos miembros, junto con los recursos Service y Binding creados en global en el proyecto de administración. Las consultas en global no agregan recursos implementados en multirregiones o regiones únicas.

Cuando enumeras, buscas o recuperas componentes de agentes en una ubicación del proyecto de administración, el Registro de agentes realiza los siguientes pasos:

1. Identifica todos los proyectos miembros asociados con el proyecto de administración a través del recurso CapabilityConfig activo.
2. Consulta los agentes y servidores de MCP detectados automáticamente en esa ubicación en el proyecto de administración y cada proyecto miembro, junto con cualquier recurso Service registrado manualmente que se haya creado en esa ubicación en el proyecto de administración.
3. Agrega recursos que coinciden en un conjunto de resultados unificado.
4. Te devuelve los resultados agregados.

Si se adjuntan varios límites al mismo recurso CapabilityConfig, Agent Registry agrega proyectos miembros de todos los límites adjuntos al mismo registro de proyectos de administración. Para restringir la lista o los resultados de la búsqueda en el proyecto de administración a un solo proyecto miembro, pasa --filter="project_id=MEMBER_PROJECT_ID". Si dos entornos requieren visibilidad independiente, crea un recurso CapabilityConfig y un proyecto de administración independientes para cada límite.

El descubrimiento de un solo proyecto y el descubrimiento entre proyectos usan métodos de API idénticos. El alcance de la búsqueda depende de si el proyecto de destino es un proyecto miembro o un proyecto de administración.

Nombres de recursos en un límite de administración

Cuando se incluye un componente en un proyecto miembro, el Registro de agentes le asigna un ID, como AGENT_ID o SERVER_ID. Cuando enumeras, buscas o obtienes un componente en un límite de administración, el Registro de agentes conserva el ID de ese componente y da formato al nombre del recurso asociado en función del proyecto que uses:

• Proyecto de administración: Cuando enumeras, buscas o obtienes componentes con el proyecto de administración, cada nombre de recurso usa el proyecto de administración.
• Proyecto miembro: Cuando enumeras, buscas o obtienes componentes con el proyecto miembro en el que se implementa el recurso, cada nombre de recurso usa ese proyecto miembro.

En la siguiente tabla, se muestra la URL de la solicitud y el nombre del recurso asociado para los recursos detectados automáticamente que se implementan en un proyecto miembro:

Tipo de recurso	Solicitar URL	Nombre del recurso asociado
Agente	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
Servidor de 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

El nombre del recurso asociado refleja el proyecto de tu solicitud. Sin embargo, el identificador de registro y la referencia de entorno de ejecución del componente permanecen inmutables y siempre conservan el proyecto miembro en el que se ejecuta la carga de trabajo subyacente.

Visualización de la topología y los flujos de tráfico

Los administradores de plataformas y los arquitectos de IA pueden visualizar las relaciones entre varios agentes y el tráfico entre proyectos con el grafo de topología.

En el grafo de topología, se visualizan las siguientes dimensiones de la arquitectura:

• Correlación de referencia del entorno de ejecución: Correlaciona el identificador de agente lógico con su referencia del entorno de ejecución física. Esta correlación permite a los operadores rastrear un agente en Agent Registry directamente hasta su motor de razonamiento de Agent Runtime, servicio de Cloud Run o implementación de GKE subyacentes.
• Vinculaciones entre proyectos: Muestra las vinculaciones entre los agentes de organización de un proyecto y los servidores de MCP o las herramientas descendentes de otro proyecto.
• Verificación del perímetro: Ayuda a los administradores a verificar que la comunicación del agente cumpla con los perímetros de los Controles del servicio de VPC y se enrute a través de los extremos designados de Agent Gateway.

Control de acceso

En un límite de administración, otorgas roles de descubrimiento de IAM en el proyecto de administración para que los usuarios y los organizadores puedan realizar búsquedas en el límite sin necesidad de acceso directo de IAM a los proyectos de miembros individuales. Debido a que los recursos Service y Binding registrados de forma manual que se crean en un proyecto miembro no se acumulan en el proyecto de administración, los administradores de seguridad también pueden restringir la creación local de Service y Binding en los proyectos miembros con una restricción de la política de la organización o una política de denegación de IAM. Cuando los agentes de los proyectos miembros invocan herramientas o se comunican con agentes de otros proyectos que se encuentran fuera del límite, el tráfico se puede enrutar a través de una Agent Gateway central.

Para los recursos en un límite de administración, las restricciones de los Controles del servicio de VPC se aplican solo a las interacciones de Agent Registry en el proyecto de administración. Agent Registry puede descubrir agentes y servidores de MCP en todos los proyectos miembros del límite de administración, incluso si esos proyectos miembros no están en el mismo perímetro de servicio que el proyecto de administración.

Para obtener más información sobre los roles necesarios para la configuración de límites, el acceso al registro y las restricciones de escritura de proyectos miembros, consulta Roles para los límites de administración entre proyectos.

¿Qué sigue?

• Configura los límites de administración en Resource Manager.
• Obtén más información sobre el modelo de datos entre proyectos.
• Realiza búsquedas en un límite de administración.
• Revisa los roles y permisos para Agent Registry.