Soluciona problemas de implementación de un agente

En este documento, se describe cómo resolver errores que puedes encontrar cuando implementas un agente en Agent Runtime. Abarca una variedad de problemas comunes, como errores de serialización, errores de permisos y violaciones de límites de VPC-SC.

Nota: Para buscar y filtrar los registros de errores del agente, usa el Explorador de registros, selecciona RESOURCE TYPE para "Vertex AI Reasoning Engine" y elige el valor de RESOURCE CONTAINER (es decir, el número de proyecto) y el valor de REASONING ENGINE ID correspondientes.

Errores de plantilla compilada previamente

Si tienes problemas con la plantilla de LangchainAgent durante la implementación, puede deberse a uno de los problemas en esta sección.

Errores internos del servidor

Problema:

Recibes un mensaje de error similar al siguiente:

InternalServerError: 500 Revision YYY is not ready and cannot serve traffic.

Lamentablemente, este es un error genérico para cualquier problema con el contenedor en el entorno de ejecución y la posible causa es uno de los tantos errores que pueden estar ocurriendo.

Causas posibles

  • Estado no sincronizado en LangchainAgent. Esto podría suceder si .set_up() se llamó en un LangchainAgent antes de implementar el agente.
  • Versiones de paquete incoherentes. Esto podría ocurrir si los paquetes instalados en el entorno de desarrollo son diferentes de los paquetes instalados en el entorno remoto en Agent Runtime.

Soluciones recomendadas

  • Estado no sincronizado en LangchainAgent. Crea una instancia nueva de LangchainAgent o quita agent.set_up() del código antes de implementar el agente.
  • Las especificaciones del paquete no son coherentes. Consulta la sección sobre solución de errores de serialización.

Errores de serialización

En general, es importante asegurarse de que los entornos "local" y "remoto" estén sincronizados cuando se implementa el agente. Para garantizar esto, puedes especificar requirements= cuando implementes el agente.

Si tienes problemas con la serialización (errores relacionados con "pickle" o "pickling" son sinónimos de “serialización”), podría deberse a uno de los problemas que se describen en esta sección.

Versión de Pydantic

Problema:

Recibes un mensaje de error similar al siguiente:

PicklingError: Can't pickle <cyfunction str_validator at 0x7ca030133d30>: it's
not the same object as pydantic.validators.str_validator

Causa posible:

Esto puede suceder si tu paquete pydantic es anterior a la versión 2.6.4. Para verificar qué versión estás usando, ejecuta el siguiente comando en la terminal:

pip show pydantic

Solución recomendada:

Actualiza el paquete mediante la ejecución del siguiente comando en la terminal:

pip install pydantic --upgrade

Ejecuta el siguiente comando en tu terminal para verificar que estés usando la versión 2.6.4 o posterior:

pip show pydantic

Si estás en una instancia de notebook (por ejemplo, Jupyter, Colab o Workbench), es posible que debas reiniciar tu entorno de ejecución para usar los paquetes actualizados.

Versión de Cloudpickle

Problema:

Recibes un mensaje de error similar al siguiente:

AttributeError: Can't get attribute '_class_setstate' on <module 'cloudpickle.cloudpickle'
from '/usr/local/lib/python3.10/site-packages/cloudpickle/cloudpickle.py'>

Causa posible:

Esto puede suceder si la versión de tu paquete cloudpickle es diferente en el entorno de desarrollo y el de implementación. Para comprobar qué versión usas en desarrollo, ejecuta el siguiente comando en la terminal:

pip show cloudpickle

Solución recomendada:

Implementa la misma versión de cloudpickle en ambos entornos, como tu entorno de desarrollo local y el agente implementado de forma remota. Para ello, especifica requirements= cuando implementes el agente.

Errores internos del servidor

Problema:

Recibes un mensaje de error similar al siguiente:

InternalServerError: 500 Revision YYY is not ready and cannot serve traffic.

Causa posible:

Esto podría suceder si sys_version= es diferente del entorno de desarrollo cuando implementas el agente.

Solución recomendada:

Después de implementar el agente, considera quitar sys_version= de los argumentos de entrada. Si los problemas persisten, envía un informe de errores.

Errores del bucket de Cloud Storage

Si tienes problemas con el bucket de etapa de pruebas de Cloud Storage que se usa en el momento de la implementación para recopilar y subir tu agente, puede deberse a uno de los siguientes problemas:

Errores de permisos

Solución recomendada:

Si deseas usar un bucket preexistente, asegúrate de que la principal que está autenticada para usar Agent Platform (ya sea tú mismo o una cuenta de servicio) tenga acceso Storage Admin al bucket y otórgale permisos a la cuenta de servicio.

Como alternativa, puedes especificar un bucket nuevo cuando implementes el agente, y el SDK creará el bucket con los permisos necesarios.

Si los problemas persisten, envía un informe de errores.

No se creó el subdirectorio del bucket de Cloud Storage

Problema:

Recibes un mensaje de error similar al siguiente:

NotFound: 404 Can not copy from \"gs://[LOCATION]-*/agent_engine/agent_engine.pkl\" to \"gs://*/code.pkl\", check if the source object and target bucket exist.

(El error 404 se produce cuando el sistema intenta realizar una copia en una carpeta que no existe).

Causa posible:

Es probable que esto se deba a un problema con la interpolación de cadenas en las versiones de google-cloud-aiplatform anteriores a la versión 1.49.0. Esto se corrigió en versiones posteriores. Para verificar qué versión de google-cloud-aiplatform estás usando, ejecuta el siguiente comando en la terminal:

pip show google-cloud-aiplatform

Solución recomendada:

Actualiza el paquete mediante la ejecución del siguiente comando en la terminal:

pip install google-cloud-aiplatform --upgrade

Verifica que estés usando la versión 1.49.0 o una posterior de google-cloud-aiplatform ejecutando el siguiente comando en la terminal:

pip show google-cloud-aiplatform

Si usas una instancia de notebook (por ejemplo, Jupyter, Colab o Workbench), quizás debas reiniciar tu entorno de ejecución antes de poder usar los paquetes actualizados.

Errores de incumplimiento de VPC-SC

Si tienes problemas con el VPC-SC, es posible que se deban a uno de los siguientes motivos:

Errores de permisos

Problema:

Recibes un mensaje de error similar al siguiente:

Reasoning Engine instance REASONING_ENGINE_ID failed to start and cannot serve traffic.

o:

Request is prohibited by organization's policy.

Causa posible:

Es probable que esto se deba a la falta de reglas de entrada obligatorias en el perímetro de VPC-SC.

Solución recomendada:

Si usas Agent Platform en un entorno de VPC-SC, debes crear una regla de entrada en tu perímetro para permitir la entrada del agente de servicio de Reasoning Engine (service-PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com) en el servicio de storage.googleapis.com y el servicio de artifactregistry.googleapis.com.

Errores de cuentas de servicio personalizadas

Si tienes problemas con las cuentas de servicio, es posible que uno de los siguientes problemas sea la causa:

Actúa como cuenta de servicio

Problema:

Recibes un mensaje de error similar al siguiente:

You do not have permission to act as service_account.

Causa posible:

Es posible que no tengas el permiso iam.serviceAccounts.actAs en la cuenta de servicio personalizada que se usa para la implementación. Ten en cuenta que, en un sistema multiagente en el que hay varias cuentas de servicio personalizadas, un autor o implementador de agentes puede actuar como algunas de las cuentas de servicio. Si usas la cuenta de servicio incorrecta, este error es el comportamiento esperado.

Además, es posible que encuentres este error si la cuenta de servicio personalizada se encuentra en un proyecto diferente del que usas para implementar el agente y la política de la organización iam.disableCrossProjectServiceAccountUsage está aplicada en el proyecto de la cuenta de servicio.

Consulta Cuenta de servicio personalizada entre proyectos para obtener la lista completa de las configuraciones necesarias para esta situación.

Solución recomendada:

Asegúrate de usar la cuenta de servicio prevista. Verifica si tienes el rol de Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en esta cuenta de servicio. De lo contrario, pídele a tu administrador que te otorgue el rol en esta cuenta de servicio.

Si te encuentras en la situación de varios proyectos, verifica si tu proyecto de cuenta de servicio tiene aplicada la política de organización iam.disableCrossProjectServiceAccountUsage. Si es así, pídele al administrador que inhabilite la política.

Servidor de metadatos no disponible

Problema:

Recibes un mensaje de error similar al siguiente:

ServiceUnavailable: 503 Getting metadata from plugin failed with error

o

Compute Engine Metadata server unavailable due to : Could not fetch URI /computeMetadata/v1/instance/service-accounts/default/token

Causa posible:

Esto puede suceder si la cuenta de servicio personalizada y tu agente se encuentran en proyectos diferentes, y el agente de servicio de AI Platform Reasoning Engine no tiene el permiso iam.serviceAccounts.getAccessToken en la cuenta de servicio personalizada.

Consulta Cuenta de servicio personalizada entre proyectos para obtener la lista completa de las configuraciones necesarias para esta situación.

Solución recomendada:

Pídele a tu administrador que le otorgue al agente de servicio de AI Platform Reasoning Engine del proyecto del agente el rol de Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en la cuenta de servicio personalizada.

El agente de servicio de AI Platform Reasoning Engine debe estar ubicado en el mismo proyecto que usas para implementar tu agente. La vinculación de IAM del otorgamiento del rol debe estar en el proyecto en el que reside la cuenta de servicio personalizada.

Errores de recursos agotados o de límite de frecuencia (error 429)

Problema:

Deployment falla con un estado Error 429 o RESOURCE_EXHAUSTED.

Causa posible:

El proyecto superó los límites de frecuencia de la API o las cuotas de solicitudes simultáneas.

Soluciones recomendadas:

  • Implementa una estrategia de retirada exponencial y reintento en los secuencias de comandos de implementación.
  • Verifica el uso actual en comparación con los límites en la Google Cloud página Cuotas de la "API de Agent Platform".
  • Reduce la frecuencia de las implementaciones simultáneas.

La región se encuentra temporalmente sin capacidad

Problema:

Deployment falla con un estado 429 o RESOURCE_EXHAUSTED y un mensaje que indica que la región alcanzó temporalmente su capacidad para una cantidad total permitida de memoria o CPU.

Causa posible:

Las implementaciones de agentes en una región se basan en un grupo de capacidad de procesamiento que Agent Runtime administra en tu nombre y que comparten todos los clientes de esa región. Cuando se agota el grupo, fallan las implementaciones nuevas en esa región hasta que se libera capacidad.

Este límite no es una de las cuotas de tu proyecto. No aparece en laGoogle Cloud página Cuotas y no se puede aumentar solicitando un incremento de cuota.

Soluciones recomendadas:

  • Realiza la implementación en otra región admitida. Esta es la forma más rápida de desbloquear una implementación.
  • Vuelve a intentarlo más tarde. Una región con capacidad completa es un problema temporal que suele resolverse por sí solo.
  • Solicita una cantidad menor de memoria o CPU para tu agente. Una implementación más pequeña puede caber dentro de la capacidad restante.
  • Comunícate con el equipo de asistencia si las implementaciones en una región siguen fallando de esta manera. Si bien no podemos aumentar el límite, tus informes nos ayudan a dirigir la capacidad a donde se necesita.

Soluciones que no se aplican:

  • Borrar los agentes existentes no libera capacidad para este límite, ya que la capacidad no la consume solo tu proyecto.
  • Solicitar un aumento de cuota no tiene ningún efecto, ya que el límite no es una cuota del proyecto.

La cantidad máxima de instancias supera el límite regional

Problema:

Deployment falla con un estado 429 o RESOURCE_EXHAUSTED y un mensaje que indica que spec.deployment_spec.max_instances supera la cantidad máxima de instancias admitidas para la CPU o la memoria solicitadas en resource_limits de la región.

Causa posible:

Cuando implementas un agente, Agent Runtime multiplica spec.deployment_spec.max_instances por cpu y memory por instancia en spec.deployment_spec.resource_limits y verifica que la asignación máxima de este único agente se ajuste al límite regional del proyecto de servicio subyacente. Si no especificas max_instances, Agent Runtime aplica un valor predeterminado (como 200), que, en las regiones con límites más bajos, puede superar la cantidad máxima de instancias admitidas cuando se multiplica por el valor cpu o memory configurado por instancia.

Soluciones recomendadas:

  • Establece spec.deployment_spec.max_instances en el valor máximo que se muestra en el mensaje de error (o menos).
  • Reduce el valor de cpu o memory por instancia en spec.deployment_spec.resource_limits.
  • Implementa el agente en otra región admitida con un límite más alto.

Soluciones que no se aplican:

  • Solicitar un aumento de la cuota en la página Google Cloud Cuotas de tu proyecto no tiene ningún efecto, ya que este límite se aplica en el proyecto de entrega administrado por Google, no en tu proyecto.
  • Borrar otros agentes de tu proyecto o volver a intentarlo sin cambiar max_instances ni resource_limits no resuelve este error, ya que la verificación evalúa la asignación máxima de la implementación única en comparación con un límite estático.

Errores de acceso a Secret Manager

Problema:

Deployment falla con un estado 400, INVALID_ARGUMENT (REASONING_ENGINE_SECRET_ACCESS_DENIED) y un mensaje similar al siguiente:

The Reasoning Engine could not access `projects/PROJECT_NUMBER/secrets/SECRET_ID/versions/VERSION_ID` referenced by `spec.deployment_spec.secret_env` (reason: FAILURE_REASON).

Causas posibles:

  • NOT_FOUND: El ID del secreto o el ID de la versión especificados en secret_env no existen en Secret Manager en el mismo proyecto que el agente implementado, o bien contienen un error tipográfico.
  • DESTROYED o DISABLED: La versión del secreto a la que se hace referencia en Secret Manager está destruida o inhabilitada.
  • PERMISSION_DENIED: La cuenta de servicio que usa el agente no tiene el rol de usuario con acceso a secretos de Secret Manager (roles/secretmanager.secretAccessor) en el secreto al que se hace referencia.

Soluciones recomendadas:

  • Para NOT_FOUND, DESTROYED o DISABLED:
    1. En la página Secret Manager del proyecto en el que implementas el agente, verifica que cada SECRET_ID y VERSION_ID a los que se hace referencia en secret_env existan y estén en el estado Habilitado.
    2. Si se inhabilitó o destruyó una versión a la que se hace referencia, habilita una versión válida o actualiza secret_env para hacer referencia a una versión habilitada.
  • Para PERMISSION_DENIED: Otorga el rol de Usuario con acceso a secretos de Secret Manager (roles/secretmanager.secretAccessor) en el secreto (o el proyecto que contiene el secreto) a la cuenta de servicio que recupera el secreto:
    • Cuenta de servicio predeterminada: Otorga el rol al agente de servicio de AI Platform Reasoning Engine (service-PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com).
    • Cuenta de servicio personalizada: Otorga el rol a la cuenta de servicio personalizada configurada en el agente.

Recursos de asistencia

Si el problema persiste, consulta nuestra guía de asistencia para obtener ayuda.