Overview
Esta página enumera las limitaciones que se aplican al motor del agente de MongoDB Atlas durante la versión preliminar pública. Cada limitación también aparece en la página que describe la función afectada.
Importante
Limitaciones de la vista previa pública
El motor de agentes Atlas de MongoDB se encuentra en vista previa pública. MongoDB no recomienda ejecutar cargas de trabajo de producción en la plataforma y no proporciona acuerdos de nivel de servicio (SLA) ni objetivos de nivel de servicio (SLO) para la disponibilidad de la plataforma durante la vista previa pública.
Escalabilidad y concurrencia
El motor de agentes de Atlas no escala automáticamente las implementaciones de agentes. El campo scaling.replicas del archivo agent.yaml establece un número fijo de entornos aislados (sandboxes), y cada sesión reserva un entorno aislado para agentes y otro para herramientas durante su vida útil. Por lo tanto, este campo determina el número de sesiones que una implementación puede atender simultáneamente.
El campo scaling.replicas acepta un valor entre 1 y 512, y por defecto toma el valor 4 si se omite. Cuando todos los entornos aislados están reservados, una nueva solicitud de invocación falla con un error pool full.
El límite de entornos aislados concurrentes 512 se aplica al Motor de Orquestación, que está vinculado a un proyecto y puede dar servicio a más de un agente. Los valores scaling.replicas de todos los agentes de un proyecto se contabilizan para el mismo límite. Para ejecutar más entornos aislados de los que permite un proyecto, distribuya los agentes entre varios proyectos.
Para evitar que las solicitudes de invocación agoten el grupo de sesiones, reutilice los ID de sesión entre las solicitudes. Las solicitudes que comparten un ID de sesión reutilizan una reserva, pero las que no lo incluyen utilizan un nuevo par de entornos aislados. Un ID de sesión debe tener entre 1 y 128 caracteres y puede contener letras, números, guiones bajos (_) y guiones (-). Pase el ID de sesión en la opción --session del comando agentengine invoke o en el encabezado X-Session-ID de una solicitud de API.
Si sus solicitudes de invocación requieren aislamiento por sesión, no puede reutilizar un ID de sesión. Para atender más sesiones simultáneamente, aumente el valor de scaling.replicas o reduzca los valores de scaling.agent_idle_ttl_seconds y scaling.tool_idle_ttl_seconds para que las sesiones inactivas liberen sus entornos aislados antes.
Dado que Atlas Agent Engine captura los valores de scaling durante la compilación, debe compilar e implementar el agente nuevamente para que los cambios surtan efecto. Para obtener más información sobre estos campos, consulte la Referencia del contrato del agente.
Capacidad del motor de orquestación
Un motor de orquestación puede atender hasta 50 solicitudes concurrentes por segundo en todos los agentes de su proyecto.
Si su carga de trabajo requiere una mayor concurrencia, cree un nuevo proyecto e implemente los agentes adicionales en ese proyecto, o póngase en contacto con el soporte técnico de MongoDB para obtener ayuda.
Recursos informáticos
No se pueden configurar los recursos informáticos para un agente ni para el motor de orquestación. Cada agente dispone de 0.5 vCPU y 2 GB de memoria, y cada motor de orquestación dispone de 0.5 vCPU y 512 MB de memoria. Estos valores son fijos y no varían con la carga de trabajo.
Si su carga de trabajo requiere una asignación de recursos diferente, póngase en contacto con el soporte técnico de MongoDB para obtener ayuda.
Construcciones de agentes
La plataforma impone los siguientes límites de compilación para cada proyecto:
Limit | Valor |
|---|---|
Compilaciones activas simultáneas | 10 |
Construcciones diarias durante un período continuo de 24 horas | 100 |
Si superas un límite de compilación, la solicitud devuelve un error 400 Bad Request con un mensaje RESOURCE_LIMIT_EXCEEDED.
Para obtener más información sobre cómo crear e implementar un agente,consulte Implementar su compilación.
Integración de la aplicación GitHub
La aplicación Atlas Agent Engine para GitHub no está disponible durante la vista previa pública. No puedes instalar la aplicación en tu organización de GitHub, por lo que no puedes usar el flujo Connect Repository en la interfaz de usuario de Atlas Agent Engine, crear un espacio de trabajo desde un repositorio de GitHub ni recibir eventos de webhook de la aplicación de GitHub.
Para crear e implementar un espacio de trabajo durante la vista previa pública, ejecute el comando agentengine deploy desde una copia local de su repositorio.
Para aprender a realizar la implementación desde un clon local, consulte la sección Implementar su compilación.
Secretos
La plataforma impone los siguientes límites a los secretos:
Alcance | Limit |
|---|---|
Por proyecto | 100 |
Por espacio de trabajo | 100 |
Si superas un límite secreto, la solicitud devuelve un error 400 Bad Request con un mensaje RESOURCE_LIMIT_EXCEEDED.
Para obtener información sobre cómo configurar, leer y eliminar secretos, consulte la sección "Aprovisionamiento de secretos en la nube".
Recursos para la organización, los proyectos y el espacio de trabajo
Cada organización puede tener hasta 100 cuentas de servicio de organización. Si supera este límite, la solicitud devuelve un error 400 Bad Request con un mensaje RESOURCE_LIMIT_EXCEEDED.
La siguiente tabla enumera los límites de recursos para cada proyecto:
Resource | Limit |
|---|---|
Espacios de trabajo | 25 |
API keys | 100 |
Proveedores de credenciales | 100 |
Cuentas de servicio de proyectos | 100 |
Si supera un límite de recursos, la solicitud devuelve un error 400 Bad Request con un mensaje RESOURCE_LIMIT_EXCEEDED.
Para obtener información sobre cómo administrar estos recursos,consulte Ver organizaciones y Administrar organizaciones, proyectos y espacios de trabajo.
Estabilidad de la API pública
Nota
Estabilidad de la API durante la vista previa pública
La API pública de Atlas Agent Engine está sujeta a cambios durante la versión preliminar pública. Los puntos finales, los formatos de solicitud y los formatos de respuesta podrían cambiar sin una ruta de migración compatible con versiones anteriores. Fije la versión de la CLI agentengine de la que depende su automatización y revise las notas de la versión antes de actualizar.
Para obtener información sobre las credenciales que autentican las solicitudes de API, consulte la sección "Administrar claves de API y cuentas de servicio".
Cuentas de servicio
Cuando una cuenta de servicio invoca un agente implementado, el motor de agentes de Atlas utiliza la identidad de la propia cuenta de servicio como identidad de memoria en tiempo de ejecución. La plataforma ignora cualquier valor user_id del usuario final que proporcione la solicitud de invocación o el indicador agentengine invoke --user-id.
Las operaciones automáticas de grabación, extracción, consolidación y app.memory utilizan esta identidad resuelta. Como resultado, las invocaciones que se autentican a través de la misma cuenta de servicio comparten un ámbito de usuario de memoria.
Esta limitación se aplica únicamente a los agentes desplegados que invoca una cuenta de servicio. El servicio de memoria independiente, con ámbito de proyecto, no se ve afectado. Este servicio continúa aceptando valores explícitos de user_id y session_id del emisor.
Para aislar la memoria por usuario final, llame al servicio de memoria independiente desde su aplicación y pase los valores user_id y session_id explícitos en cada llamada. Para obtener más información, consulte la sección "Uso del servicio de memoria independiente".
Para obtener información sobre cómo autenticar una aplicación mediante una cuenta de servicio, consulte Autenticar con una cuenta de servicio.
Seguridad
Acceso secreto
Los agentes tienen acceso a todos los secretos de su proyecto. Por defecto, los nuevos secretos se añaden a nivel de proyecto, no a nivel de espacio de trabajo. Los agentes que implemente en un proyecto existente pueden acceder a todos los secretos del proyecto, incluido el MONGODB_URI que utilizan otros agentes.
Para restringir un secreto a un solo espacio de trabajo, agregue la bandera --workspace-scope cuando llame al comando agentengine secret set.
Acceso a la base de datos
Cuando se utiliza el comando agentengine atlas setup para crear una conexión Atlas, la conexión otorga acceso readWriteAnyDatabase en el clúster de destino.
Si necesita acceso a la base de datos con un alcance más restringido, cree manualmente un usuario de base de datos en Atlas. A continuación, configure un secreto de espacio de trabajo MONGODB_URI con credenciales que tengan acceso a las bases de datos MDB_AGENTIC_STORE_DB y MONGOMEM_DB_NAME.
Aislamiento de agentes
Todos los agentes implementados en un proyecto comparten el mismo motor de orquestación o plano de control de agentes. El motor de orquestación no impone autenticación ni autorización a los agentes que realizan las llamadas.
Si necesita un mayor aislamiento de los agentes, implemente sus agentes en proyectos independientes.
Aislamiento de herramientas
Las herramientas se ejecutan de forma predeterminada en el entorno aislado del agente. Para ejecutar una herramienta en el entorno aislado de herramientas, inclúyala en el campo sandboxes.tool.tools de su archivo agent.yaml. Puede indicar el nombre de la herramienta o un patrón glob que coincida con él. Las herramientas que requieren credenciales delegadas solo pueden ejecutarse en el entorno aislado de herramientas.
El entorno aislado del agente y el entorno aislado de la herramienta aíslan sus cargas de trabajo entre sí. Por ejemplo, las herramientas en el entorno aislado de la herramienta se ejecutan de forma independiente del flujo de control del agente en el entorno aislado del agente. Sin embargo, las herramientas que se ejecutan en el mismo entorno aislado no están aisladas entre sí.
Las herramientas en el mismo entorno aislado pueden acceder a todos los secretos y destinos de salida que configure para dicho entorno. El motor del agente Atlas no limita el acceso a los secretos ni a la red a herramientas individuales. Las herramientas que se ejecutan en el entorno aislado del agente también comparten los secretos y destinos de salida de dicho entorno con el código de su agente. Si su agente requiere aislamiento entre herramientas, no considere ningún entorno aislado como un límite de seguridad independiente para cada herramienta.
Si su agente utiliza un entorno aislado de herramientas, cada sesión reserva uno mientras esté activa. Todas las llamadas a herramientas que el motor del agente de Atlas dirige a dicho entorno se ejecutan en él. El motor del agente de Atlas no crea un nuevo entorno aislado para cada llamada. Si una sesión permanece inactiva durante más tiempo que el valor scaling.tool_idle_ttl_seconds, el motor del agente de Atlas libera su entorno aislado. Cuando la sesión vuelve a estar activa, utiliza un nuevo entorno aislado.
Para configurar los secretos del entorno aislado y los destinos de salida, consulte Esquema YAML del agente y Administración de políticas de salida de red.