Amazon展示了一个在编程智能体修改项目文件时实时查看网页应用的示例。这个方案建立在Amazon Bedrock AgentCore runtime之上。每个智能体会话都运行在各自隔离的microVM中，而Session端点则为该会话内明确获准的端口提供经过身份验证的访问。这里的访问范围与某一个会话绑定，并不是面向所有会话的通用入口。

该结构把通信分成两条用途不同的路径。InvokeAgentRuntime用于直接访问智能体本身；与智能体一起运行在同一会话中的其他服务，例如开发用网页服务器或状态路由，则可以通过Session端点访问，但前提是相应端口已经明确列入runtime配置。这个区分也是理解示例中三个端口各自职责的基础。

配置允许访问的端口

创建agent runtime时，allowedPorts可以接收一至五个单独端口或端口范围。所选端口必须位于8000至12000之间，同时不能包含平台保留的端口。要通过这种方式提供服务，端口上的应用还必须监听0.0.0.0。因此，仅仅启动一个进程并不足以让浏览器通过Session端点访问它；监听地址和允许端口配置都必须符合要求。

InvokeAgentRuntime会在X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url响应头中返回Session端点URL。支持这一功能的SDK会把同一数值公开为sessionEndpointUrl。客户端由此获得当前会话对应的入口，再利用该入口访问已经获准的辅助服务。

这个URL严格限定于一个会话。每一次请求都需要携带凭证，当该会话结束后，端点也会停止工作。因此，Session端点既受到允许端口列表的限制，也受到会话生命周期的限制。客户端所使用的应当是当前会话返回的地址，而不能把它当作脱离会话长期存在的固定地址。

IAM、JWT与每次请求的身份验证

如果runtime使用IAM授权，那么发往Session端点的HTTP请求、HTTP/2流以及WebSocket握手都需要SigV4签名。调用方还必须拥有bedrock-agentcore:InvokeAgentRuntimeProxy权限。身份验证并不只发生在首次获得端点时，而是适用于经由该端点发送的每一个请求和连接建立过程。

如果runtime采用入站JWT authorizer，要求则不同：客户端使用bearer token，而不是IAM场景中的SigV4签名。两种授权方式对应不同的凭证形式，但共同点是Session端点不会接受没有凭证的访问。浏览器流量、HTTP/2通信以及WebSocket建立连接时，都需要遵循runtime选定的授权模式。

可承载的通信类型

Session端点能够传递HTTP/1.1和HTTP/2流量，其中包括server-sent events与gRPC，同时也支持WebSocket连接。这意味着示例不仅可以通过普通HTTP显示网页内容，也可以维持开发服务器用于实时通知的WebSocket连接。网页资源与热更新通信因而能够通过同一个会话范围内的访问机制传递。

bedrock-agentcore SDK提供了Session端点客户端，它可以在用户环境中公开一个本地端点。该客户端会先为浏览器请求和WebSocket握手添加凭证，再把流量转发到远端Session端点。浏览器连接的是本地地址，而进入AgentCore会话所要求的身份验证与转发工作由这个客户端处理。

这一安排对于浏览器场景尤其具体：本地端点并没有取消远端端点的凭证要求，而是在转发前补充所需凭证。远端Session端点仍然按会话、端口和授权方式检查访问；本地客户端则承担把浏览器通信转换成已认证转发流量的角色。

示例中的三个端口

在Amazon给出的示例中，编程智能体运行在端口8080，Vite开发服务器运行在端口8090，智能体还在端口8081提供一条状态路由。虽然这三个服务都与同一示例相关，但它们并不全部通过Session端点暴露。

Session端点的允许列表只包含8090和8081。端口8080被有意省略，因为InvokeAgentRuntime可以直接访问智能体，不需要通过Session端点。换言之，8080属于智能体调用路径，而Vite服务和状态路由所在的另外两个端口属于会话范围内的代理访问路径。

这一端口分工说明，allowedPorts不需要重复覆盖InvokeAgentRuntime已经承担的智能体入口。示例把允许列表留给需要通过Session端点访问的辅助服务：一个用于显示开发中的网站，另一个用于提供状态路由。每一条路径都有明确用途，也分别受到相应访问机制的约束。

文件保存后如何实现热更新

当编程智能体保存修改后的文件时，Vite通过自己的热重载WebSocket发送变更。该连接经过Session端点，再经过本地端点到达浏览器。浏览器中显示的网站因此可以更新，而不需要用户手动刷新页面。这条链路把智能体对文件的修改、持续运行的Vite开发服务器以及已经认证的WebSocket通信连接起来。

在这个流程中，智能体负责保存变更，Vite负责通过热重载连接传递变更，Session端点负责把允许端口上的通信带出隔离会话，本地端点则为浏览器请求和WebSocket握手添加凭证并完成转发。网页无需刷新这一结果来自这些已说明环节的连续配合。

热更新连接仍然受到Session端点的全部边界控制。它使用的是已列入允许列表的Vite端口，WebSocket握手必须按照runtime的授权方式携带认证信息，而且该连接依赖当前会话仍然存在。会话结束后，与该会话绑定的端点不再工作。

运行示例所需的环境

Amazon列出的要求包括Python 3.10或更高版本、bedrock-agentcore 1.25.2或更高版本，以及boto3 1.43.122或更高版本。前端开发环境需要Node.js 22或更高版本并带有npm。此外，示例还需要Git、Jupyter环境，以及在Amazon Bedrock中访问Claude Haiku 5.5的权限。

这些要求覆盖了示例中的不同部分：Python相关组件包括AgentCore SDK与boto3，Vite所在的开发流程依赖Node.js和npm，示例还明确要求Git与Jupyter环境。模型方面则要求能够在Amazon Bedrock中访问指定的Claude Haiku 5.5。

拒绝访问时的行为

允许端口列表会直接控制请求能否通过。若请求指向allowedPorts之外的端口，系统会以HTTP 403 AccessDenied拒绝。没有携带凭证的请求也会得到相同类型的拒绝。这两个条件分别体现端口范围限制与身份验证要求，满足其中一个并不能替代另一个。

当拒绝来自runtime时，响应正文为空，错误代码位于响应头中。因此，面对这类拒绝，响应正文不会提供错误内容；错误标识需要从响应头取得。该行为适用于runtime作出的访问拒绝，并与HTTP 403 AccessDenied状态共同说明请求没有被允许进入目标端口。

从示例配置来看，访问辅助服务需要同时满足几项已明确的条件：应用监听0.0.0.0，端口处于规定的8000至12000范围并列入allowedPorts，没有使用平台保留端口，请求或握手携带与授权模式相符的凭证，而且对应会话仍然有效。任何端口都不会仅因进程正在运行而自动获得Session端点访问权。

完整访问链路

整个流程可以按职责理解。InvokeAgentRuntime负责联系智能体，并返回当前会话的Session端点URL。Session端点只转发配置中明确允许的辅助端口。SDK的本地客户端为浏览器HTTP请求和WebSocket握手加入所需凭证。Vite则在智能体保存文件之后，通过热重载WebSocket把变更传递给浏览器。

端口8080与8090、8081之间的区别贯穿整个方案。前者供InvokeAgentRuntime访问智能体，后两者演示Session端点对会话内服务的认证代理访问。正是这种职责分离，使示例能够在保留正常智能体调用方式的同时，把正在运行的网站与状态路由提供给会话外部的客户端。

最终呈现的是一个边界清楚的实时预览过程：每个会话位于自己的隔离microVM中，只有获准端口能通过会话专属端点访问，每次通信都要满足身份验证要求，本地客户端负责浏览器流量的凭证与转发，而Vite利用WebSocket让保存后的网页变化无需手动刷新即可显示。所有这些访问都随着所属会话结束而终止。