Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
See how MongoDB 9.0 delivers up to 2x higher throughput.
MongoDB Branding Shape
Register now >
Menu Docs

Limitações do mecanismo do agente do MongoDB Atlas

Esta página lista as limitações que se aplicam ao MongoDB Atlas Agent Engine durante a pré-visualização pública. Cada limitação também aparece na página que abrange a funcionalidade afetada.

Importante

Limitações de visualização pública

O MongoDB Atlas Agent Engine está em pré-visualização pública. O MongoDB não recomenda que você execute volumes de trabalho de produção na plataforma e não fornece acordos de nível de serviço (SLAs) ou objetivos de nível de serviço (SLOs) para disponibilidade da plataforma durante a pré-visualização pública.

O Atlas Agent Engine não dimensiona automaticamente os sistemas do agente . O campo scaling.replicas no arquivo agent.yaml define uma contagem fixa de sandbox, e cada sessão reserva uma sandbox de agente e uma sandbox de ferramenta para sua vida útil. Como resultado, este campo define o número de sessões que um sistema pode atender simultaneamente.

O campo scaling.replicas aceita um valor de 1 a 512 e padroniza para 4 quando você o omite. Quando cada sandbox é reservada, uma nova solicitação de invocação falha com um erro pool full.

O limite de sandbox simultânea 512 se aplica ao Mecanismo de orquestração, que tem como escopo um projeto e pode atender a mais de um agente. Os valores scaling.replicas de todos os agentes em um projeto contam para o mesmo teto. Para executar mais sandboxes do que um projeto permite, distribua seus agentes em vários projetos.

Para evitar que as solicitações de invocação esgotem o pool, reutilize os IDs de sessão nas solicitações. As solicitações que compartilham um ID de sessão reutilizam uma reserva, mas as solicitações que omitem um ID de sessão usam um novo par de sandboxes. Um ID de sessão deve ter 1 a 128 caracteres e pode conter letras, números, sublinhados (_) e hífens (-). Passe o ID da sessão na opção --session do comando agentengine invoke ou no cabeçalho X-Session-ID de uma solicitação de API.

Se suas solicitações de invocação exigirem isolamento por sessão, você não poderá reutilizar um ID de sessão. Para atender a mais sessões ao mesmo tempo, aumente o valor scaling.replicas ou reduza os valores scaling.agent_idle_ttl_seconds e scaling.tool_idle_ttl_seconds para que as sessões ociosas liberem suas sandboxes mais cedo.

Como o Atlas Agent Engine captura valores scaling no tempo de construção, você deve construir e distribuir o agente novamente para que uma alteração entre em vigor. Para saber mais sobre esses campos, consulte Referência do contrato do agente.

Um mecanismo de orquestração pode atender a até 50 solicitações simultâneas por segundo em todos os agentes em seu projeto.

Se o volume de trabalho exigir uma simultaneidade mais alta, crie um novo projeto e implemente os agentes adicionais nesse projeto, ou entre em contato com o suporte do MongoDB para obter ajuda.

Você não pode configurar os recursos de computação de um agente ou do Mecanismo de Orquestração. Cada agente tem 0.5 vCPU e 2 GB de memória, e cada Mecanismo de Orquestração tem 0.5 vCPU e 512 MB de memória. Esses valores são fixos e não mudam com seu volume de trabalho.

Se seu volume de trabalho exigir diferentes alocações de recursos, entre em contato com o suporte do MongoDB para obter ajuda.

A plataforma força os seguintes limites de construção para cada projeto:

Limite
Valor

Construções ativas simultâneas

10

Construções diárias durante um período contínuo de 24 horas

100

Se você exceder um limite de compilação, a solicitação retornará um erro 400 Bad Request com uma mensagem RESOURCE_LIMIT_EXCEEDED.

Para saber mais sobre como criar e implantar um agente,consulte Implantar seu build.

O aplicativo Atlas Agent Engine GitHub não está disponível durante o pré-visualização pública. Você não pode instalar o aplicativo na sua organização do GitHub, portanto, não pode usar o fluxo Connect Repository na interface do usuário do Atlas Agent Engine, criar um espaço de trabalho a partir de um repositório do GitHub ou receber eventos do webhook do aplicativo GitHub.

Para criar e implantar um espaço de trabalho durante a visualização pública, execute o comando agentengine deploy de um clone local do seu repositório.

Para saber como implantar a partir de um clone local, consulte Implantar sua compilação.

A plataforma impõe os seguintes limites aos segredos:

Escopo
Limite

Por projeto

100

Por espaço de trabalho

100

Se você exceder um limite secreto, a solicitação retornará um erro 400 Bad Request com uma mensagem RESOURCE_LIMIT_EXCEEDED.

Para saber como definir, ler e excluir segredos, consulte Provision Cloud Secrets.

Cada organização pode ter até 100 contas de serviço da organização . Se você exceder esse limite, a solicitação retornará um erro 400 Bad Request com uma mensagem RESOURCE_LIMIT_EXCEEDED.

A tabela a seguir lista os limites de recursos para cada projeto:

Resource
Limite

Espaços de trabalho

25

Chaves de API

100

Fornecedores de credenciais

100

Contas de serviço do projeto

100

Se você exceder um limite de recurso, a solicitação retornará um erro 400 Bad Request com uma mensagem de RESOURCE_LIMIT_EXCEEDED.

Para saber como gerenciar esses recursos,consulte Exibir Organizações e Gerenciar Organizações, Projetos e Espaços de Trabalho.

Observação

Estabilidade da API durante a pré-visualização pública

A API pública do Atlas Agent Engine está sujeita a alterações durante a pré-visualização pública. Endpoints, formatos de solicitação e formatos de resposta podem mudar sem um caminho de migração compatível com versões anteriores. Fixe a versão do CLI do agentengine da qual sua automação depende e revise as notas de versão antes de atualizar.

Para saber mais sobre as credenciais que autenticam solicitações de API, consulte Gerenciar chaves de API e contas de serviço.

Quando uma conta de serviço invoca um agente implementado, o Atlas Agent Engine utiliza a própria identidade da conta de serviço como a identidade da memória de tempo de execução. A plataforma ignora qualquer valor user_id de usuário final que a solicitação de invocação ou o sinalizador agentengine invoke --user-id forneça.

As operações automáticas de registro, extração, consolidação e app.memory usam essa identidade resolvida. Como resultado, as invocações que autenticam por meio da mesma conta de serviço compartilham um escopo de usuário de memória.

Esta limitação se aplica apenas aos agentes implementados que uma conta de serviço invoca. O serviço de memória autônomo do, com escopo de projeto, não é afetado. Este serviço continua a aceitar valores user_id e session_id explícitos do chamador.

Para isolar a memória pelo usuário final, chame o serviço de memória autônomo do seu aplicação e passe um valor user_id e session_id explícito para cada chamada. Para saber mais, consulte Usar o serviço de memória independente.

Para saber como autenticar um aplicação usando uma conta de serviço, consulte Autenticar com uma Conta de Serviço.

Os agentes têm acesso a todos os segredos de seu projeto. Novos segredos são adicionados no nível do projeto , não no nível do espaço de trabalho, por padrão. Os agentes que você implanta em um projeto existente podem acessar todos os segredos do projeto, incluindo o MONGODB_URI que outros agentes utilizam.

Para restringir um segredo a um workspace, anexe o sinalizador --workspace-scope ao chamar o comando agentengine secret set.

Quando você utiliza o comando agentengine atlas setup para criar uma conexão Atlas , a conexão concede acesso readWriteAnyDatabase no cluster de destino.

Se você precisar de acesso ao banco de dados com um escopo mais restrito, crie manualmente um usuário de banco de dados no Atlas. Em seguida, defina um segredo de espaço de trabalho MONGODB_URI com credenciais com escopo para os bancos de dados MDB_AGENTIC_STORE_DB e MONGOMEM_DB_NAME.

Todos os agentes distribuídos em um projeto compartilham o mesmo Mecanismo de orquestração, ou plano de controle do agente . O Mecanismo de orquestração não impõe autenticação ou autorização aos agentes de chamada.

Se você precisar de um isolamento mais forte do agente , implemente seus agentes em projetos independentes.

As ferramentas são executadas na sandbox do agente por padrão. Para executar uma ferramenta na sandbox de ferramentas, liste-a no campo sandboxes.tool.tools do seu arquivo agent.yaml. Você pode listar o nome da ferramenta ou um padrão global que corresponda ao nome da ferramenta. As ferramentas que solicitam credenciais delegadas podem ser executadas somente na sandbox de ferramentas.

A sandbox do agente e a sandbox da ferramenta isolam suas cargas de trabalho umas das outras. Por exemplo, as ferramentas na sandbox de ferramentas são executadas separadamente do fluxo de controle do agente na sandbox do agente . No entanto, as ferramentas executadas na mesma sandbox não são isoladas umas das outras.

As ferramentas na mesma sandbox podem acessar todos os segredos e destinos de saída que você configura para essa sandbox. O Atlas Agent Engine não tem escopo secreto ou acesso à rede para ferramentas individuais. As ferramentas executadas na sandbox do agente também compartilham os segredos da sandbox do agente e os destinos de saída com o código do agente . Se o seu agente precisar de isolamento entre as ferramentas, não trate nenhuma das sandboxs como um limite de segurança por ferramenta.

Se o seu agente usar uma sandbox de ferramenta, cada sessão reservará uma sandbox de ferramenta enquanto a sessão estiver ativa. Todas as chamadas de ferramentas na sessão que o Mecanismo de Agente do Atlas roteia para a sandbox da ferramenta executada nessa sandbox. O Atlas Agent Engine não cria uma nova sandbox de ferramenta para cada chamada de ferramenta. Se uma sessão ficar ociosa por mais tempo que o valor scaling.tool_idle_ttl_seconds, o Atlas Agent Engine liberará sua sandbox de ferramentas. Quando a sessão fica ativa novamente, ela usa uma nova sandbox de ferramenta.

Para configurar segredos de sandbox e destinos de saída, consulte Esquema YAML do Agente e Gerenciar Políticas de Saída de Rede.