Use sessões isoladas para agentes
O Amazon Bedrock AgentCore Runtime permite isolar cada sessão de usuário e reutilizar com segurança o contexto em várias invocações em uma sessão de usuário. O isolamento da sessão é fundamental para as cargas de trabalho dos agentes de IA devido às suas características operacionais exclusivas:
-
Separação completa do ambiente de execução: cada sessão de usuário no AgentCore Runtime recebe sua própria microVM dedicada com recursos isolados de computação, memória e sistema de arquivos. Isso impede que o agente de um usuário acesse os dados de outro usuário. Após a conclusão da sessão, toda a microVM é encerrada e a memória é higienizada para remover todos os dados da sessão, eliminando os riscos de contaminação entre sessões.
-
Processos de raciocínio com estado: ao contrário das funções sem estado, os agentes de IA mantêm um estado contextual complexo durante todo o ciclo de execução, além do simples histórico de mensagens para conversas em vários turnos. AgentCore O tempo de execução preserva esse estado com segurança em uma sessão, ao mesmo tempo em que garante o isolamento completo entre diferentes usuários, permitindo experiências personalizadas dos agentes sem comprometer os limites dos dados.
-
Operações privilegiadas de ferramentas: agentes de IA realizam operações privilegiadas em nome dos usuários por meio de ferramentas integradas que acessam vários recursos. AgentCore O modelo de isolamento do Runtime garante que essas operações da ferramenta mantenham contextos de segurança adequados e evite o compartilhamento de credenciais ou o escalonamento de permissões entre diferentes sessões de usuário.
-
Segurança determinística para processos não determinísticos: o comportamento do agente de IA pode ser não determinístico devido à natureza probabilística dos modelos básicos. AgentCore O Runtime fornece limites de isolamento consistentes e determinísticos, independentemente dos padrões de execução do agente, fornecendo as propriedades de segurança previsíveis necessárias para implantações corporativas.
nota
AgentCore não impõe mapeamentos de sessão para usuário - o back-end do seu cliente deve manter o relacionamento entre os usuários e seus IDs de sessão. Além disso, o back-end do seu cliente deve implementar uma lógica para o gerenciamento do ciclo de vida do usuário para a sessão, como o número máximo de sessões por usuário. Para obter orientações completas sobre isolamento de sessões, consulte Melhores práticas de segurança para o AgentCore Runtime.
Compreendendo o contexto efêmero
Por padrão, a computação (microVM) associada a uma sessão é efêmera. Todos os dados armazenados na memória ou gravados em disco persistem somente durante o ciclo de vida da computação. Isso inclui histórico de conversas, preferências do usuário, resultados de cálculos intermediários e qualquer outra informação de estado que seu agente mantenha.
Para manter os dados do sistema de arquivos em todos os stop/resume ciclos de sessão, configure o armazenamento da sessão — um diretório persistente que sobrevive ao término da computação. Consulte Configurações do sistema de arquivos para AgentCore Runtime.
Para dados estruturados que precisam ser retidos além da vida útil da sessão (como histórico de conversas do usuário, preferências aprendidas ou informações importantes), use AgentCore Memória. Esse serviço fornece armazenamento persistente específico, projetado especificamente para cargas de trabalho de agentes, com recursos de memória de curto e longo prazo.
Conversas estendidas e fluxos de trabalho em várias etapas
Ao contrário das funções sem servidor tradicionais que terminam após cada solicitação, AgentCore oferece suporte a sessões isoladas apoiadas por computações efêmeras que duram até 8 horas por ciclo de vida. Isso simplifica a criação de fluxos de trabalho agentes de várias etapas, pois você pode fazer várias chamadas para o mesmo ambiente, com cada invocação baseada no contexto estabelecido pelas interações anteriores. Você pode usar tanto InvokeAgentRuntime para o raciocínio do agente quanto InvokeAgentRuntimeCommand para a execução determinística do comando shell na mesma sessão.
AgentCore Ciclo de vida da sessão em tempo de execução
Criação de sessão
Uma nova sessão é criada na primeira chamada com um tempo de execução exclusivo SessionId fornecido pelo seu aplicativo. AgentCore O Runtime provisiona um ambiente de execução dedicado (microVM) para cada sessão. O contexto é preservado entre as invocações para a mesma sessão. Ambos InvokeAgentRuntime InvokeAgentRuntimeCommand operam na mesma sessão — um comando vê o mesmo contêiner, sistema de arquivos e ambiente do agente.
Estados da sessão
O estado da sessão é determinado pelo ciclo de vida da computação e pode ser um dos seguintes:
-
Ativo: processando uma solicitação de sincronização, executando um comando ou executando tarefas em segundo plano. A invocação de sincronização e a atividade de execução de comandos são rastreadas automaticamente com base nas invocações de uma sessão de tempo de execução. As tarefas em segundo plano são comunicadas pelo código do agente, respondendo com o status "HealthyBusy" nos pings.
-
Ocioso: quando não está processando nenhuma solicitação ou tarefa em segundo plano. O processamento da sessão foi concluído, mas permanece disponível para futuras invocações.
-
Interrompido: a computação (microVM) provisionada para a sessão foi encerrada e a sessão foi interrompida. Isso pode ocorrer devido à inatividade (padrão 15 minutos), ao alcance da vida útil máxima da computação (padrão de 8 horas), a uma interrupção explícita ao invocar a StopRuntimeSessionAPI ou se a computação for considerada não íntegra com base nas verificações de integridade. A sessão volta para Ativa na próxima invocação e uma nova computação é provisionada, com a mesma configuração de ciclo de vida (ou seja, ociosa RuntimeSessionTimeout e MaxLifetime, que pode durar até mais 8 horas). A sessão em si permanece válida até que o ARN do AgentCore Runtime seja excluído. Se o tempo de execução for configurado com armazenamento de sessão, os dados do sistema de arquivos no caminho de montagem configurado persistirão em todos os ciclos. stop/resume Consulte Configurações do sistema de arquivos para AgentCore Runtime.
Como usar as sessões
Para usar as sessões de forma eficaz:
-
Gere um ID de sessão exclusivo para cada usuário ou conversa com pelo menos 33 caracteres
-
Passe o mesmo ID de sessão para todas as invocações relacionadas
-
Use IDs de sessão diferentes para diferentes usuários ou conversas
Exemplo de uso de sessões para uma conversa
# First message in a conversation response1 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "Tell me about AWS"}).encode() ) # Follow-up message in the same conversation reuses the runtimeSessionId. response2 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "How does it compare to other cloud providers"}).encode() )
Ao usar o mesmo tempo de execução SessionId para invocações relacionadas, você garante que o contexto seja mantido em toda a conversa, permitindo que seu agente forneça respostas coerentes baseadas em interações anteriores.
Cabeçalhos de sessão por protocolo
Ao invocar agentes, inclua o cabeçalho de sessão apropriado para garantir que as solicitações sejam roteadas para a mesma microVM. O cabeçalho depende do protocolo configurado do seu agente:
| Protocolo | cabeçalho da sessão |
|---|---|
|
MCP |
|
|
HTTP |
|
|
A2A |
|
|
AG-UI |
|
Fixação da microVM: o Amazon Bedrock AgentCore usa o cabeçalho da sessão para rotear solicitações para a mesma instância da microVM. Os clientes devem capturar o ID da sessão retornado na resposta e incluí-lo em todas as solicitações subsequentes para garantir a afinidade da sessão. Sem um ID de sessão consistente, cada solicitação pode ser roteada para uma nova microVM, o que pode resultar em latência adicional devido a inícios a frio.
Para detalhes específicos do protocolo MCP, incluindo modos sem estado e com estado, consulte Gerenciamento de sessões MCP e aderência de microVM.
