人工智能
预览网络应用程序在您编码 agent 时使用 Amazon Bedrock Agent Core 运行时间。
编码 agents 现在构建工作网络应用：一个仪表板，一个产品页面，一个产品团队想要尝试的原型。 审查该工作最快的方法是打开应用，使用，要求更改，并检查结果。 当应用程序持续运行agent编辑它的地方时，这个循环运行效果很好，所以每个程序在数秒内将显示在浏览器中改变。 当应用程序必须先被复制并部署在别处时，每一次更改都会等待部署，而审查会放慢到这个速度。
Amazon Bedrock Agent Core是一个在规模上构建，连接，并优化agents的平台，您可以选择agent框架和基础模型(FM). Agent Core runtime，是Amazon Bedrock Agent Core的一种能力，在自己的孤立微VM中运行每个agent会话。 有了会话结束点，您可以从自己的浏览器打开会话中运行的应用程序。 会话结束点给每个会话一个经认证的URL，将每个请求的 HTTP 方法，路径，查询字符串和正文，以及WebSocket 连接，转发到您允许的端口。 您可以在 agent 保存每个文件时观看页面更新。
在此帖子中，您会部署一个编码 agent，使其保持一个Vite网站的会话运行，然后打开一个本地网页，在左侧和右侧的直播网站进行聊天。 您要求 agent 将网站切换为暗色主题，沿袭其流入的步骤，并观看网站的更改而不更新。 最后，你看看内部发生的情况：同一会话中的第二个端口，请求的会话结束点拒绝了。
完整的样本，包括此帖子所取的笔记本，都收于代理core-samples GitHub repo的14-remote-access文件夹中。
会话终点如何工作
每个会话都得到了自己的会话终点，六个细节会塑造如何使用它。
你选择它到达哪个端口。 您在调用 CreatAgentRuntime 时设置了允许的Ports: 1–5 条目，每个条目在 8000–12000 以内单个端口或范围，不包括保留平台端口。 允许端口不会启动服务器，因此您的应用程序必须听它，绑定到 0. 0.0。
URL随会话而来。 Invoke AgentRuntime反应在X-Amzn-Bedrock-Agent Core-Runtime-Condime-Endpoint-Url标题中携带了它，SDK是它作为会话EndpointUrl所曝光的模型。
每个请求都经过认证。 对于使用AWS身份和访问管理(IAM)的运行时间，每个HTTP请求，HTTP/2流，和WebSocket握手都带有签名版本4(SigV4)的签名。 呼叫者还需要基建-代理核心：Invoke AgentRundimeProxy在运行时间及其运行时间终点。 在JSON Web Token(JWT)授权人进入的运行时间里，每个请求都携带一个无记名标志。 了解 URL 不允许访问。
主机名选择端口。 您的客户端无论目标端口在端口443上连接，主机名上的前缀选择会话内部的端口：
它带着你服务器讲的协议 HTTP/1.1和HTTP/2请求，包括服务器发送事件和gRPC，以及WebSocket连接全部通过。 这种走行道使用HTTP/1.1和WebSocket.
讨论范围为一次。 URL需要每个请求的资质，并且只能持续到会话，所以使用它来构建，测试和审查您的 agent 生产的东西。 要为您的用户服务一个应用程序，请将其部署到AWS Amplify Hosting等托管服务中。
浏览器无法在页上自行提出的要求中添加 SigV4 签名或无记名符号，因此，基建代理核心 SDK 中的会话端点客户端可以在您的机器上打开本地端点。 您的浏览器打开 http://localhost:8088，本地端点新增您对每个请求的证书和WebSocket握手后再转发。
一个会话端点不同于运行时间端点，Agent Core 运行时间已经提供。 使用运行时端点，如 DEFAULT，可以到达您的 agent，控制它的呼叫者会到达的哪个版本。 Invoke AgentRuntime呼叫通过它解决，这样就可以将开发和制作保持在不同的版本上，并在不改变呼叫者的情况下促进或回放。 使用会话结束点来查看您的 agent 会话运行情况，如网页预览。 它是一个经认证的URL，它只到达您允许的端口，与会话运行的任意版本合作，并在会话结束时停止工作。 完整的文档，请通过会话结束点引用 Connect to runtime sessions.
解决办法概述
样本有四个部分。 一个编码的agent运行在端口8080的会话中，并用四个工具来编辑网站的文件：列表，读取，写取，和编辑。 agent在8090端口启动一款Vite开发服务器，该服务器为网站服务，并推倒每个保存到浏览器的更改而在其热重装的WebSocket上。 在您的机器上，PreviewApp 为预览页服务，将您的提示发送到 InvokeAgentRuntime，并打开网站的本地端点。 如图1 显示，预览页面通过本地端点和会话端点从端口8090上的Vite开发服务器上加载网站，并通过InvokeAgentRuntime将您的提示发送到端口8080上的agent. 数字显示一个请求的步骤顺序。
在步骤一之前，PreviewApp已经叫了Invoke AgentRuntime一次开始会话，它开始agent和Vite开发服务器。 PreviewApp从该响应读取会话端点 URL，并为端口8090打开了本地端点。 图1中的编号步骤接续一项更改请求：
- 预览页的站点窗格从当地host:8088上的地方端口加载网站。 本地端点新增您对每个请求的证书和WebSocket握手，并转发到会话端点。 会话端点对照允许的Ports检查签名和端口，再将其转发到端口8090上的Vite开发服务器。 该页面保持了Vite热重装WebSocket的开通。
- 你从聊天板上发出快讯 PreviewApp将它发送给InvokeAgentRuntime，作为标准AWS API呼叫，与您AWS的资信签名，运行时间在8080端口将其交付给agent. 兹克 1Z的台阶流回聊天板
- agent在Amazon Bedrock中称Claude Haiku 5.5，以决定改变什么。
- agent读取网站文件，Vite 开发服务器为这些文件服务并观看其更改。
- 当一个文件被保存时，Vite将更改推到第1步打开的WebSocket上，然后通过会话端点和本地端点返回，并且网站的平板更新没有刷新。
- 从笔记本中，PreviewApp读取了agent在端口8081的/status路由，通过同一会话终点。 只有端口改变。
Invoke AgentRuntime在没有经过会话终点的情况下到达了agent。
先决条件
跟着走你需要：
- AWS账户位于AWS区域，可提供代理Core运行时会话端点，并配置了证书。
- 允许创建 AWS 身份和访问管理(IAM) 角色，上传到 Amazon 简单存储服务(Amazon S3)，并创建一个运行时间，加上基建代理：Invoke AgentRuntime和基建代理：Invoke AgentRuntimeProxy在该运行时间及其运行时间终点上。 详情请参考Agent Core运行时间的IAM权限。
- Python 3.10或后期，有地基-干燥剂 1.25.2或后期和硼31.43.122或后期。
- Git)，以克隆样本repo，和Jupyter环境，例如带有Jupyter扩展的JupyterLab或Visual Studio Code，以运行笔记本。
- 在Amazon Bedrock进入Claude Haiku 5.5. 关于按区域分列的模式可用性，参见按模式分列的区域可用性。
- 节点.js 22或后与npm，部署脚本用于包装agent和网站。
样本在Amazon S3中部署agent作为拉链文件，并直接为Node.js部署代码，因此不需要Docker或Amazon弹性容器注册(Amazon ECR)存储器。 会话端点与微VM运行时间配合，而不是与实例计算类型配合，会话端点URL在公共HTTPS上可以被达到。 AWS PrivateLink 不支持入境连接。
部署 agent 及其网站
首先，您要部署运行时间，您选择的配置将决定会话终点可以到达的端口。 部署脚本将 agent 捆绑在一个文件上，新增网站及其在Arm64系统的运行时间的Linux的依赖，将zip上传到Amazon S3，并创建运行时间。
以下节选从部署.py 显示中摘录了对于此帖重要的两个设置。 协议配置称，其中agent听取InvokeAgentRuntime，并允许Ports列出会话端点可以到达的端口：网站8090,agent状态路由8081. 因为Invoke AgentRuntime没有它就到达了agent。 对于端口和路径设置，请参见配置您的 agent 服务端口和引用路径。
网站的Vite配置使得开发服务器从会话终点可以到达。 它在 8090 端口听 0. 0.0，并不限制主机头( server. allowdHosts 是真实的)，因为请求是以主机名到达的，运行时间指定而不是本地主机。 会话端点在到达服务器之前认证每个请求，因此服务器不需要自己的主机检查。
要部署运行时间：
1. 将样品复制并更改为样品文件夹：
2. 从样本文件夹中打开会话端点 preview.ipynb.
3. 运行安装单元格，安装Python依赖。
4. 运行 %run 部署.py 单元格。 部署需要几分钟时间，主要是等待运行时间达到准备状态。
打开预览
随着运行时间的准备，开始预览。 一个呼叫有三件事：它开始一个会话(它开始网站)，打开一个端口8090的本地端点，并在localhost:8087上服务预览页。
内部启动 ()，使用会话端点的调用很短。 第一个Invoke AgentRuntime呼叫返回响应头的URL，会话 endpoint url读取它，会话端点客户端打开一个端口8090的本地端点：
要打开预览：
运行启动预览App的单元格。
- 在您的浏览器中打开打印链接，http://localhost:8087。
右侧的网站显示页，在会话中服务于第8090端口，左侧有建议请求的简短指南。
询问 agent 更改
现在你要求改变，看着它到达。 每个提示通过InvokeAgentRuntime到达agent. agent读取它需要的文件，写出它修改的文件，并随其发生而报告每个步骤。 当一个文件被保存时，Vite开发服务器会在其WebSocket上通过会话端点和当地端点来推动修改，网站更新到位。
请求改变：
- 在预览页上，选择把这个网站切换为深色咖啡馆色彩主题。
- 在阅读和保存文件时遵循 agent 在聊天窗格中的步骤。
- 注意现场的窗子当 agent 保存样式表时它会改变，而更改的文件来自一个横幅名称。
以下视频显示预览页面，而agent则通过多个请求工作。 选择一个建议的请求发送到agent，聊天面板列出每个文件agent读取并保存，站点面板在右侧更新时没有刷新，从黑暗主题到绿色命令前方按钮。
agent在请求时会用服务器发送的事件来回答，所以步骤流。 你可以用App.ask从 Python 发送同样的提示，它读取了来自基岩代理核心SDK的Iter events的流。 开放页以同样方式更新：
此 Python 脚本的输出应该类似于：
在同一会话中到达第二个端口
网站不是O
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime
Coding agents now build working web apps: a dashboard, a product page, a prototype that a product team wants to try. The fastest way to review that work is to open the app, use it, ask for a change, and check the result. That loop works well when the app keeps running where the agent edits it, so each change shows up in the browser within seconds. When the app must be copied out and deployed somewhere else first, every change waits for a deployment, and the review slows down to that pace.
Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with your choice of agent framework and foundation model (FM). AgentCore runtime, a capability of Amazon Bedrock AgentCore, runs each agent session in its own isolated microVM. With Session endpoints, you can open an app running in that session from your own browser. Session Endpoints give each session an authenticated URL that forwards each request’s HTTP method, path, query string, and body, and WebSocket connections, to the ports you allow. You can watch the page update as the agent saves each file.
In this post, you deploy a coding agent that keeps a Vite website running in its session, then open one local page with a chat on the left and the live website on the right. You ask the agent to switch the site to a dark color theme, follow its steps as they stream in, and watch the website change without a refresh. Finally, you look at what happens internally: a second port in the same session, and the requests the Session endpoint refuses.
The complete sample, including the notebook this post follows, is in the 14-remote-access folder of the agentcore-samples GitHub repo.
How Session endpoints work
Each session gets its own Session endpoint, and six details shape how you use it.
You choose which ports it reaches. You set allowedPorts when you call CreateAgentRuntime: 1–5 entries, each a single port or a range within 8000–12000, excluding the reserved platform ports. Allowing a port doesn’t start a server, so your application must listen on it, bound to 0.0.0.0.
The URL arrives with the session. The InvokeAgentRuntime response carries it in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header, which SDKs that model it expose as sessionEndpointUrl.
Every request is authenticated. For a runtime that uses AWS Identity and Access Management (IAM), each HTTP request, HTTP/2 stream, and WebSocket handshake carries a Signature Version 4 (SigV4) signature. The caller also needs bedrock-agentcore:InvokeAgentRuntimeProxy on the runtime and its runtime endpoint. For a runtime with an inbound JSON Web Token (JWT) authorizer, each request carries a bearer token instead. Knowing the URL doesn’t grant access.
The host name selects the port. Your client connects on port 443 regardless of the target port, and a prefix on the host name chooses the port inside the session:
It carries the protocols your server speaks. HTTP/1.1 and HTTP/2 requests, including server-sent events and gRPC, and WebSocket connections all pass through. This walkthrough uses HTTP/1.1 and WebSocket.
It’s scoped to one session. The URL needs credentials on every request and lasts only as long as the session, so use it to build, test, and review what your agent produces. To serve an app to your users, deploy it to a hosting service such as AWS Amplify Hosting.
A browser can’t add a SigV4 signature or a bearer token to the requests a page makes on its own, so the Session endpoint client in the bedrock-agentcore SDK can open a local endpoint on your machine. Your browser opens http://localhost:8088, and the local endpoint adds your credentials to each request and WebSocket handshake before forwarding it.
A Session endpoint is different from a runtime endpoint, which AgentCore runtime already provides. Use a runtime endpoint, such as DEFAULT, to reach your agent, which controls which version of it callers will reach. InvokeAgentRuntime calls resolve through it, so you can keep development and production on different versions and promote or roll back without changing callers. Use a Session endpoint to see what your agent runs in its session, such as a web preview. It’s an authenticated URL that reaches only the ports you allow, works with whichever version the session runs, and stops working when the session ends. For complete documentation, refer to Connect to runtime sessions through a session endpoint.
Solution overview
The sample has four parts. A coding agent runs in the session on port 8080 and edits the website’s files with four tools: list, read, write, and edit. The agent starts a Vite development server on port 8090, which serves the website and pushes each saved change to the browser over its hot-reload WebSocket. On your machine, PreviewApp serves the preview page, sends your prompts to InvokeAgentRuntime, and opens a local endpoint for the website. As Figure 1 shows, the preview page loads the website from the Vite development server on port 8090 through the local endpoint and the Session endpoint, and sends your prompts through InvokeAgentRuntime to the agent on port 8080. The numbers show the order of the steps for one request.
Before step 1, PreviewApp has already called InvokeAgentRuntime once to start the session, which starts the agent and the Vite development server. PreviewApp read the Session endpoint URL from that response and opened a local endpoint for port 8090. The numbered steps in Figure 1 then follow one request for a change:
- The site pane of the preview page loads the website from the local endpoint on localhost:8088. The local endpoint adds your credentials to each request and the WebSocket handshake, and forwards them to the Session endpoint. The Session endpoint checks the signature and the port against allowedPorts, then forwards them to the Vite development server on port 8090. The page keeps the Vite hot-reload WebSocket open.
- You send a prompt from the chat pane. PreviewApp sends it to InvokeAgentRuntime as a standard AWS API call signed with your AWS credentials, and the runtime delivers it to the agent on port 8080. The agent’s steps stream back to the chat pane as it works.
- The agent calls Claude Haiku 5.5 in Amazon Bedrock to decide what to change.
- The agent reads the site’s files and saves the ones it changes. The Vite development server serves those files and watches them for changes.
- When a file is saved, Vite pushes the change over the WebSocket opened in step 1, back through the Session endpoint and the local endpoint, and the site pane updates without a refresh.
- From the notebook, PreviewApp reads the agent’s /status route on port 8081 through the same Session endpoint. Only the port changes.
Port 8080 isn’t in allowedPorts, because InvokeAgentRuntime reaches the agent without going through the Session endpoint.
Prerequisites
To follow the walkthrough, you need:
- An AWS account in an AWS Region where AgentCore runtime Session endpoints are available, with credentials configured.
- Permissions to create an AWS Identity and Access Management (IAM) role, upload to Amazon Simple Storage Service (Amazon S3), and create a runtime, plus bedrock-agentcore:InvokeAgentRuntime and bedrock-agentcore:InvokeAgentRuntimeProxy on that runtime and its DEFAULT runtime endpoint. For details, refer to IAM permissions for AgentCore runtime.
- Python 3.10 or later, with bedrock-agentcore 1.25.2 or later and boto3 1.43.122 or later.
- Git, to clone the sample repo, and a Jupyter environment, such as JupyterLab or Visual Studio Code with the Jupyter extension, to run the notebook.
- Access to Claude Haiku 5.5 in Amazon Bedrock. For model availability by Region, refer to Regional availability by models.
- Node.js 22 or later with npm, which the deployment script uses to package the agent and the website.
The sample deploys the agent as a zip file in Amazon S3 with direct code deployment for Node.js, so you don’t need Docker or an Amazon Elastic Container Registry (Amazon ECR) repository. Session endpoints work with microVM runtimes, not with the Instances compute type, and Session endpoint URLs are reachable over public HTTPS. AWS PrivateLink isn’t supported for inbound connections.
Deploy the agent and its website
First, you deploy the runtime, and the configuration you choose here decides which ports the Session endpoint can reach. The deployment script bundles the agent into one file, adds the website and its dependencies for the runtime’s Linux on Arm64 system, uploads the zip to Amazon S3, and creates the runtime.
The following excerpt from deploy.py shows the two settings that matter for this post. protocolConfiguration says where the agent listens for InvokeAgentRuntime, and allowedPorts lists the ports the Session endpoint can reach: 8090 for the website and 8081 for the agent’s status route. Port 8080 isn’t in the list, because InvokeAgentRuntime reaches the agent without it. For the port and path settings, refer to Configure your agent’s serving port and invocation path.
The website’s Vite configuration makes the development server reachable from the Session endpoint. It listens on 0.0.0.0 at port 8090 and doesn’t restrict the Host header (server.allowedHosts is true), because requests arrive under a host name the runtime assigns rather than localhost. The Session endpoint authenticates every request before it reaches the server, so the server doesn’t need its own host check.
To deploy the runtime:
1. Clone the sample repo and change to the sample folder:
2. Open session_endpoints_preview.ipynb from the sample folder.
3. Run the install cell, which installs the Python dependencies.
4. Run the %run deploy.py cell. Deployment takes a few minutes, mostly waiting for the runtime to reach the READY status.
Open the preview
With the runtime ready, you start the preview. One call does three things: it starts a session (which starts the website), opens a local endpoint for port 8090, and serves the preview page on localhost:8087.
Inside start(), the calls that use Session endpoints are short. The first InvokeAgentRuntime call returns the URL in a response header, session_endpoint_url reads it, and the Session endpoint client opens a local endpoint for port 8090:
To open the preview:
- Run the cell that starts PreviewApp.
- Open the printed link, http://localhost:8087, in your browser.
The page shows the website on the right, served from port 8090 in the session, and a short guide with suggested requests on the left.
Ask the agent for a change
Now you ask for a change and watch it arrive. Each prompt goes to the agent through InvokeAgentRuntime. The agent reads the files it needs, writes the ones it changes, and reports each step as it happens. When a file is saved, the Vite development server pushes the change over its WebSocket, through the Session endpoint and the local endpoint, and the website updates in place.
To ask for a change:
- On the preview page, choose Switch this website to a dark coffee-house color theme.
- Follow the agent’s steps in the chat pane as it reads and saves files.
- Watch the site pane. It changes when the agent saves the stylesheet, and a banner names the file the change came from.
The following video shows the preview page while the agent works through several requests. Choosing a suggested request sends it to the agent, the chat pane lists each file the agent reads and saves, and the site pane on the right updates without a refresh, from the dark theme to a green Order ahead button.
The steps stream because the agent answers with server-sent events when you ask it to. You can send the same prompts from Python with app.ask, which reads the stream with iter_events from the bedrock-agentcore SDK. The open page updates in the same way:
The output of this Python script should resemble the following:
Reach a second port in the same session
The website isn’t the o
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.