AWS fügt Amazon Bedrock AgentCore Runtime Session-Endpunkte für Live-Vorschauen von Apps hinzu
AWS hat Session-Endpunkte in der Amazon Bedrock AgentCore Runtime eingeführt, mit denen Entwickler Webanwendungen in ihrem Browser ansehen können, während ein Coding-Agent sie erstellt.
Kurze Antwort
Was hat AWS für die Vorschau von Coding-Agent-Ergebnissen in Amazon Bedrock AgentCore angekündigt?
AWS erklärte, die Amazon Bedrock AgentCore Runtime unterstütze nun Session-Endpunkte – authentifizierte URLs, mit denen Entwickler eine Webanwendung, die ein Coding-Agent innerhalb einer isolierten Session erstellt, direkt in ihrem Browser öffnen können. Die Endpunkte leiten HTTP- und WebSocket-Datenverkehr an die vom Entwickler freigegebenen Ports weiter, sodass Änderungen ohne separaten Deployment-Schritt sichtbar werden.
Das Wichtigste
- AWS hat Session-Endpunkte eingeführt, eine Funktion der Amazon Bedrock AgentCore Runtime, mit der Entwickler eine Webanwendung, die innerhalb der Session eines Agents läuft, direkt im Browser öffnen können.
- Jede Agent-Session läuft in ihrer eigenen isolierten MicroVM, und Entwickler legen fest, welche Ports ein Session-Endpunkt erreichen darf – ein bis fünf Einträge innerhalb des Bereichs 8000-12000 – indem sie beim Aufruf von CreateAgentRuntime den Parameter allowedPorts setzen.
- AWS erklärte, jede Anfrage über einen Session-Endpunkt werde authentifiziert, mittels SigV4-Signaturen bei Runtimes, die auf IAM setzen, oder mittels Bearer-Token bei Runtimes mit JWT-Autorisierung.
- AWS veröffentlichte im GitHub-Repository agentcore-samples ein Beispiel, das einen Coding-Agent zeigt, der eine Vite-Website in seiner Session am Laufen hält, sodass Änderungen im Browser erscheinen, während der Agent Dateien bearbeitet.
- AWS erklärte, ein Session-Endpunkt sei auf eine einzelne Session beschränkt und für das Erstellen, Testen und Überprüfen von Agent-Ergebnissen gedacht, nicht für die Bereitstellung von Apps für Endnutzer, wofür ein separater Hosting-Dienst wie AWS Amplify Hosting erforderlich sei.
Was AWS angekündigt hat
Amazon Web Services erklärte, die Amazon Bedrock AgentCore Runtime unterstütze nun eine Funktion namens Session-Endpunkte, mit der Entwickler eine Webanwendung, die ein Coding-Agent erstellt, direkt im eigenen Browser öffnen und damit interagieren können, während der Agent noch daran arbeitet.
Laut AWS führt die AgentCore Runtime jede Agent-Session bereits in einer eigenen isolierten MicroVM aus. Session-Endpunkte fügen dieser Session eine authentifizierte URL hinzu, die HTTP-Methode, Pfad, Query-String und Body jeder Anfrage sowie WebSocket-Verbindungen an die vom Entwickler freigegebenen Ports weiterleitet. Dadurch könne ein Entwickler zusehen, wie sich eine Seite aktualisiert, sobald der Agent jede Datei speichert, anstatt zu warten, bis die App vor jeder Überprüfung herauskopiert und anderswo bereitgestellt wird.
Wie Session-Endpunkte funktionieren
AWS beschrieb sechs Details, die das Funktionieren von Session-Endpunkten bestimmen:
- Portauswahl: Entwickler legen beim Aufruf von
CreateAgentRuntimeeinen ParameterallowedPortsfest und geben dabei ein bis fünf Einträge an, jeweils einen einzelnen Port oder einen Bereich innerhalb von 8000-12000, ausgenommen reservierte Plattform-Ports. AWS wies darauf hin, dass die Freigabe eines Ports keinen Server startet; die Anwendung muss selbst darauf lauschen, gebunden an0.0.0.0. - URL-Übermittlung: Die Antwort von
InvokeAgentRuntimeenthält die Endpunkt-URL im HeaderX-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url, den SDKs mit entsprechender Unterstützung alssessionEndpointUrlbereitstellen. - Authentifizierung: Bei Runtimes, die AWS IAM verwenden, trägt laut AWS jede HTTP-Anfrage, jeder HTTP/2-Stream und jeder WebSocket-Handshake eine Signatur der Version 4, und der Aufrufer benötigt die Berechtigung
bedrock-agentcore:InvokeAgentRuntimeProxy. Bei Runtimes mit JWT-Autorisierung trägt jede Anfrage stattdessen ein Bearer-Token. - Port-Routing über den Hostnamen: AWS erklärte, der Client verbinde sich stets über Port 443, und ein Präfix im Hostnamen wähle den Zielport innerhalb der Session aus.
- Protokollunterstützung: Laut AWS übertragen die Endpunkte HTTP/1.1-, HTTP/2- (einschließlich Server-Sent Events und gRPC) und WebSocket-Datenverkehr.
- Session-Geltungsbereich: AWS erklärte, die URL erfordere bei jeder Anfrage Anmeldedaten und sei nur für die Dauer der Session gültig; sie sei für das Erstellen, Testen und Überprüfen von Agent-Ergebnissen gedacht. Um eine App Endnutzern bereitzustellen, sollten Entwickler sie laut AWS bei einem Hosting-Dienst wie AWS Amplify Hosting deployen.
AWS erklärte zudem, da ein Browser von sich aus keine SigV4-Signatur oder ein Bearer-Token anhängen kann, könne der Session-Endpunkt-Client im SDK bedrock-agentcore einen lokalen Endpunkt auf dem Rechner des Entwicklers öffnen, der jeder Anfrage und jedem WebSocket-Handshake Anmeldedaten hinzufügt, bevor diese an den Browser weitergeleitet werden.
AWS unterschied den Session-Endpunkt vom Runtime-Endpunkt, den die AgentCore Runtime bereits bereitstellt. Ein Runtime-Endpunkt, etwa DEFAULT, steuert, welche Version eines Agents Aufrufer erreichen, und erlaubt Entwicklern, separate Versionen für Entwicklung und Produktion vorzuhalten. Ein Session-Endpunkt hingegen spiegelt jeweils die Version des Agents wider, die in dieser konkreten Session läuft, und funktioniert nicht mehr, sobald die Session endet.
Der Beispiel-Durchlauf
AWS veröffentlichte ein Beispiel mit vier Teilen: einem Coding-Agent, der auf Port 8080 läuft und mithilfe von List-, Read-, Write- und Edit-Tools die Dateien einer Website bearbeitet; einem Vite-Entwicklungsserver auf Port 8090, den der Agent startet, der die Website ausliefert und gespeicherte Änderungen über seinen Hot-Reload-WebSocket an den Browser überträgt; einer lokalen PreviewApp, die eine Vorschauseite bereitstellt, Prompts an InvokeAgentRuntime sendet und einen lokalen Endpunkt für die Website öffnet; sowie der Vorschauseite selbst, die die Website über den lokalen und den Session-Endpunkt lädt und dabei Prompts an den Agent sendet. Das vollständige Beispiel, einschließlich des Notebooks, dem der Beitrag folgt, befindet sich im Ordner 14-remote-access des GitHub-Repositorys agentcore-samples.
Quelle: AWS Machine Learning Blog, "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime", veröffentlicht am 30. Oktober 2026.
Häufige Fragen
- Was ist ein Session-Endpunkt in der Amazon Bedrock AgentCore Runtime?
- AWS beschreibt ihn als authentifizierte URL, die an eine einzelne Agent-Session gebunden ist und HTTP-Anfragen sowie WebSocket-Verbindungen an die vom Entwickler freigegebenen Ports weiterleitet, sodass ein Entwickler eine vom Agent erstellte App im eigenen Browser öffnen kann.
- Wie sichert AWS den Datenverkehr über Session-Endpunkte ab?
- AWS erklärte, jede Anfrage werde authentifiziert: Runtimes mit IAM erfordern eine SigV4-Signatur sowie die Berechtigung bedrock-agentcore:InvokeAgentRuntimeProxy, während Runtimes mit JWT-Autorisierung bei jeder Anfrage ein Bearer-Token verlangen.
- Kann ein Session-Endpunkt verwendet werden, um eine App Endnutzern bereitzustellen?
- Nein. AWS erklärte, die Session-Endpunkt-URL gelte nur für die Dauer der Session und sei für das Erstellen, Testen und Überprüfen von Agent-Ergebnissen gedacht; um eine App Nutzern bereitzustellen, müsse sie bei einem separaten Hosting-Dienst wie AWS Amplify Hosting deployt werden.
- Wo finden Entwickler Beispielcode für diese Funktion?
- AWS verwies auf den Ordner 14-remote-access im GitHub-Repository agentcore-samples, der ein Notebook enthält, das einen Coding-Agent zeigt, der eine Vite-Website für eine Live-Vorschau in seiner Session am Laufen hält.