Isolierte Sitzungen für Agenten verwenden

Mit Amazon Bedrock AgentCore Runtime können Sie jede Benutzersitzung isolieren und den Kontext sicher für mehrere Aufrufe in einer Benutzersitzung wiederverwenden. Die Sitzungsisolierung ist für die Workloads von KI-Agenten aufgrund ihrer einzigartigen betrieblichen Eigenschaften von entscheidender Bedeutung:

Verstehen des kurzlebigen Kontextes

Standardmäßig ist die Rechenleistung (MicroVM), die einer Sitzung zugeordnet ist, kurzlebig. Alle Daten, die im Arbeitsspeicher gespeichert oder auf die Festplatte geschrieben werden, bleiben nur für den gesamten Rechenlebenszyklus bestehen. Dazu gehören der Konversationsverlauf, Benutzereinstellungen, Zwischenergebnisse der Berechnung und alle anderen Statusinformationen, die Ihr Agent verwaltet.

Um Dateisystemdaten über stop/resume Sitzungszyklen hinweg beizubehalten, konfigurieren Sie den Sitzungsspeicher — ein persistentes Verzeichnis, das die Beendigung der Rechenleistung übersteht. Siehe Dateisystemkonfigurationen für Runtime. AgentCore

Verwenden Sie AgentCore Memory für strukturierte Daten, die über die Dauer der Sitzung hinaus aufbewahrt werden müssen (z. B. Konversationsverlauf von Benutzern, erlernte Einstellungen oder wichtige Erkenntnisse). Dieser Service bietet speziell für die Workloads von Agenten entwickelten persistenten Speicher, der sowohl Kurzzeit- als auch Langzeitspeicherfunktionen bietet.

Erweiterte Konversationen und mehrstufige Workflows

Im Gegensatz zu herkömmlichen serverlosen Funktionen, die nach jeder Anfrage beendet werden, werden isolierte Sitzungen AgentCore unterstützt, die auf kurzlebigen Rechenoperationen basieren und bis zu 8 Stunden pro Lebenszyklus dauern. Dies vereinfacht die Erstellung mehrstufiger agentischer Workflows, da Sie mehrere Aufrufe an dieselbe Umgebung tätigen können, wobei jeder Aufruf auf dem Kontext aufbaut, der durch vorherige Interaktionen festgelegt wurde. Sie können sowohl InvokeAgentRuntime für die Argumentation der Agenten als auch für die deterministische Ausführung InvokeAgentRuntimeCommand von Shell-Befehlen innerhalb derselben Sitzung verwenden.

AgentCore Lebenszyklus einer Runtime-Sitzung

Erstellung einer Sitzung

Beim ersten Aufruf wird eine neue Sitzung mit einer eindeutigen Laufzeit erstellt, die von Ihrer Anwendung SessionId bereitgestellt wird. AgentCore Runtime stellt für jede Sitzung eine dedizierte Ausführungsumgebung (MicroVM) bereit. Der Kontext wird zwischen Aufrufen derselben Sitzung beibehalten. Beide InvokeAgentRuntime InvokeAgentRuntimeCommand arbeiten in derselben Sitzung — ein Befehl sieht denselben Container, dasselbe Dateisystem und dieselbe Umgebung wie der Agent.

Sitzungsstatus

Der Sitzungsstatus wird durch den Rechenlebenszyklus bestimmt und kann einer der folgenden sein:

Wie benutzt man Sessions

Um Sitzungen effektiv zu nutzen:

Beispiel für die Verwendung von Sitzungen für eine Konversation

# 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()
)

Indem Sie dieselbe Laufzeit SessionId für verwandte Aufrufe verwenden, stellen Sie sicher, dass der Kontext während der gesamten Konversation erhalten bleibt, sodass Ihr Agent kohärente Antworten geben kann, die auf früheren Interaktionen aufbauen.

Sitzungskopfzeilen nach Protokoll

Geben Sie beim Aufrufen von Agenten den entsprechenden Sitzungsheader an, um sicherzustellen, dass Anfragen an dieselbe MicroVM weitergeleitet werden. Der Header hängt vom konfigurierten Protokoll Ihres Agenten ab:

MicroVM-Sperrfähigkeit: Amazon Bedrock AgentCore verwendet den Sitzungsheader, um Anfragen an dieselbe MicroVM-Instanz weiterzuleiten. Kunden müssen die in der Antwort zurückgegebene Sitzungs-ID erfassen und sie in alle nachfolgenden Anfragen aufnehmen, um die Sitzungsaffinität sicherzustellen. Ohne eine konsistente Sitzungs-ID kann jede Anfrage an eine neue MicroVM weitergeleitet werden, was zu zusätzlicher Latenz aufgrund von Kaltstarts führen kann.

Einzelheiten zum MCP-Protokoll, einschließlich statusloser und statusbehafteter Modi, finden Sie unter MCP-Sitzungsverwaltung und microVM-Stickiness.