A colaboração entre múltiplos agentes passa a dispor de computação persistente no Bedrock AgentCore
Página inicial do InfoQ Notícias A colaboração entre múltiplos agentes passa a dispor de computação persistente no Bedrock AgentCore
DevOps A colaboração entre múltiplos agentes ganha capacidade de computação persistente no Bedrock AgentCore19 de agosto de 2026 4 min de leitura
por
-
Matt Saunders
Siga-nos no
YouTube 232 mil seguidores LinkedIn 26 mil seguidores Instagram Novo RSS 19 mil leitores X 57,1 mil seguidores Facebook 21 mil gostos Bluesky Novo Ouvir este artigo - 0:00 Áudio pronto para reproduzir O seu navegador não suporta o elemento de áudio. 0:00 0:00 Normal 1,25x 1,5x Gosto- Lista de leitura
A Amazon Web Services apresentou as instâncias de tempo de execução no blogue de notícias do Bedrock AgentCore, adicionando uma segunda opção de computação que executa agentes no Amazon EC2 gerido numa conta de cliente, mantendo as APIs, a identidade e o modelo de observabilidade existentes do AgentCore. Esta funcionalidade destina-se a equipas cujos agentes já não se enquadram perfeitamente no limite de oito horas da microVM com que o AgentCore foi lançado, com base em sessões sem servidor (serverless) baseadas em microVM.
No anúncio, o principal defensor dos programadores, Sebastien Stormacq, explica que as instâncias de tempo de execução proporcionam aos agentes sessões persistentes suportadas pelo EC2 que podem decorrer até catorze dias, com sistemas de ficheiros partilhados, tipos de instâncias aceleradas por GPU e suporte para Python e imagens de contentores. É possível implementar vários agentes num único ambiente de execução e colaborar no mesmo anfitrião através de um diretório de sessão partilhado, em vez de chamarem as APIs uns dos outros a cada transferência. Stormacq observa que as equipas podem integrar frameworks como o CrewAI, LangGraph, LlamaIndex e Strands sem alterar o seu modelo de empacotamento, utilizando um simples decorador @app.entrypoint e um ficheiro zip ou uma imagem de contentor.
As instâncias do ambiente de execução tratam de tudo isso por si, ao mesmo tempo que se integram com as mesmas APIs do AgentCore, controlos de identidade e observabilidade que já utiliza com as microVMs do AgentCore Runtime.
— Sebastien Stormacq
A publicação no blogue utiliza um exemplo que ilustra o padrão de colaboração multiagente para o qual as instâncias de tempo de execução foram concebidas, em que vários agentes especializados operam num diretório de trabalho comum para código, testes, documentação e artefactos de segurança.
A AWS posiciona as instâncias de tempo de execução como complementares às microVMs, em vez de uma substituição, e incentiva topologias mistas, nas quais um agente orquestrador em microVMs distribui tarefas de longa duração para trabalhadores nas instâncias. O InfoQ tem vindo a acompanhar a evolução da funcionalidade AgentCore da AWS, desde o lançamento original do AgentCore, passando pelo suporte ao protocolo «Agent-to-Agent» para fluxos de trabalho multiagente interoperáveis, até ao Agent Registry e à plataforma de referência Loom para implementações de agentes geridas.
Algumas novidades que devem agradar aos programadores de agentes: os vossos agentes podem chamar-se uns aos outros como ferramentas dentro de uma sessão partilhada, iterando de forma autónoma até que a tarefa esteja concluída. Sebastien Stormacq
Um guia de engenharia da Enkompass aprofunda a nova primitiva de fornecedor de capacidade que sustenta as instâncias de tempo de execução. Um fornecedor de capacidade define as famílias de instâncias permitidas, o sistema operativo, a rede e o armazenamento, e funciona como um contrato entre os agentes e a capacidade do EC2 que o AgentCore irá provisionar, atualizar e dimensionar em seu nome. As equipas definem limites, tais como o número mínimo e máximo de instâncias e a utilização alvo, e, em seguida, associam um ou mais ambientes de execução de agentes a esse fornecedor com um tempo de vida da sessão de até catorze dias, evitando a necessidade de gerir diretamente grupos de Auto Scaling, modelos de lançamento ou pipelines de AMI.
A Enkompass salienta também que as instâncias de tempo de execução são mais adequadas para cargas de trabalho que necessitem de mais de oito horas de tempo de execução contínuo, que requeiram GPUs ou grandes quantidades de memória, ou que beneficiem da co-localização de vários agentes no mesmo anfitrião para uma colaboração estreita. O runtime baseado em microVM continua a ser a escolha predefinida para agentes de curta duração, com picos de tráfego e do tipo «pedido-resposta», porque arranca rapidamente, isola as sessões e cobra por segundo com base na utilização real da CPU e no pico de memória até oito horas. O guia prevê que a maioria das organizações utilize ambos os modelos em paralelo, colocando o tráfego de elevado volume e curta duração nas microVMs e reservando instâncias para um conjunto mais restrito de cargas de trabalho de longa duração, com estado ou com uso intensivo de aceleradores, que anteriormente obrigavam as equipas a manter frotas EC2 separadas.
Uma análise de custos da eCorpIT centra-se nas compensações financeiras entre instâncias de tempo de execução e microVMs. As instâncias de tempo de execução são faturadas às tarifas padrão do EC2 para o tipo de instância escolhido na conta do cliente, acrescidas de uma taxa de gestão. Em contrapartida, as microVMs são cobradas por hora de vCPU e por GB-hora, sem qualquer taxa de gestão separada, e podem revelar-se mais económicas para agentes com baixa utilização sustentada da CPU e longos períodos de inatividade. A análise de custos sugere um ponto de equilíbrio em cerca de 24% de utilização sustentada da CPU para as instâncias de tempo de execução, antes de quaisquer descontos do Savings Plan. Como as instâncias de tempo de execução são executadas na conta do cliente, os descontos de compromisso do EC2, tais como os Planos de Poupança e as Instâncias Reservadas, aplicam-se à parte de computação, mas não à taxa de gestão. O artigo defende que a colocalização de vários agentes num único anfitrião e o encerramento das sessões quando o trabalho estiver concluído são as principais alavancas para manter os custos baseados em instâncias sob controlo.
As reações da comunidade destacaram estes pontos de integração. Uma breve análise no Four Signals descreve as instâncias de tempo de execução como um importante lançamento de infraestrutura alinhado com o surgimento de plataformas de orquestração de agentes e destaca o padrão híbrido de orquestradores de microVM a distribuir trabalho a trabalhadores baseados em instâncias. Um resumo no daily.dev destaca o limite de catorze dias para as sessões, os sistemas de ficheiros partilhados e o suporte a frameworks de agentes populares como benefícios práticos essenciais para as equipas de desenvolvimento. No LinkedIn, o engenheiro Kosti Vasilakakis observou que as instâncias de tempo de execução reutilizam as mesmas APIs do AgentCore e o modelo de fixação de sessões que as equipas existentes já utilizam, reduzindo o atrito na adoção do novo tipo de computação.
A Microsoft adotou uma abordagem semelhante através dos agentes alojados no Azure Foundry. Estes provisionam «sandboxes» de máquinas virtuais por sessão com diretórios principais persistentes e armazenamento de ficheiros, restaurando o estado automaticamente quando as sessões são retomadas após períodos de inatividade ou reinícios. A documentação descreve como o serviço suporta execuções com múltiplos agentes com ciclos de vida geridos no Teams e no Microsoft 365 Copilot.
A documentação da AWS está disponível na página de instâncias de tempo de execução do AgentCore.