Amazon Bedrock AgentCore 让编码智能体构建网页应用时支持实时预览

编码智能体已经能够生成完整的网页应用——仪表盘、产品页面、团队原型——但传统的审查方式往往需要将产物复制出来、单独部署，每一次修改都要等待一轮部署周期。Amazon Bedrock AgentCore 的 Session Endpoints 功能打破了这一瓶颈：每个会话拥有独立的认证 URL，可将 HTTP 方法、路径、查询字符串及 WebSocket 连接直接转发至用户预先允许的端口，让「提需求—看效果」的循环缩短至秒级。

Session Endpoints 的工作机制围绕六个核心细节展开。用户在调用 CreateAgentRuntime 时通过 allowedPorts 参数指定 1 至 5 个端口或端口范围（限 8000–12000 之间），会话启动后 InvokeAgentRuntime 的响应头中会携带对应的 sessionEndpointUrl。每个请求都必须附带 SigV4 签名（IAM 授权模式）或 Bearer Token（JWT 授权模式），仅知晓 URL 并不足以获得访问权限。目标端口通过主机名前缀加以区分，客户端始终连接 443 端口，由平台内部完成路由。

由于浏览器无法自动为页面请求附加 SigV4 签名，AgentCore SDK 提供了本地端点能力：开发者的浏览器访问 localhost:8088，本地端点自动为每个请求和 WebSocket 握手注入凭证后再转发至 Session Endpoint。这一设计使得整个预览体验对开发者完全透明——打开本地页面，左侧是与智能体的对话窗口，右侧是实时渲染的网页，无需任何额外配置。

示例方案由四个部分协同运作：编码智能体在会话的 8080 端口运行，配备列举、读取、写入、编辑四种文件操作工具；Vite 开发服务器在 8090 端口启动，负责提供网页服务并通过热重载 WebSocket 推送变更；本地 PreviewApp 负责将用户提示词发送至 InvokeAgentRuntime，并为 8090 端口开启本地端点；智能体则调用 Amazon Bedrock 中的 Claude Haiku 5.5 模型决策修改内容，保存文件后 Vite 立即将变更推送至浏览器。

Session Endpoints 与 AgentCore 已有的运行时端点（Runtime Endpoint）定位不同，两者相互补充。运行时端点用于管理智能体版本路由，支持开发与生产环境隔离、版本回滚等运维操作；Session Endpoints 则专注于会话内部的实时内容访问，仅在会话存续期间有效，适合构建、测试和审查阶段使用。若需将应用正式对外提供服务，官方建议部署至 AWS Amplify Hosting 等托管平台。

值得注意的是，Session Endpoints 在安全边界上做了严格限制：仅允许访问预先声明的端口，平台保留端口被排除在外，且每个请求都需经过身份验证。这种设计在保持开发灵活性的同时，避免了会话内部服务被意外暴露的风险。完整示例代码已发布于 agentcore-samples GitHub 仓库的 14-remote-access 目录，包含本文所述的完整 Notebook 流程。

要点

• Session Endpoints 为每个 AgentCore 运行时会话提供经过身份验证的专属 URL，支持将 HTTP 及 WebSocket 请求转发至指定端口，实现智能体构建过程中的网页实时预览。
• 本地端点组件自动为浏览器请求附加 SigV4 签名，开发者无需手动处理认证逻辑，即可在浏览器中直接访问会话内运行的应用。
• 该功能将编码智能体的「修改—预览」反馈循环压缩至秒级，利用 Vite 热重载机制，文件保存后页面无需手动刷新即可呈现最新效果。
• Session Endpoints 仅在会话存续期间有效，适用于开发和审查阶段；正式对外服务的应用仍需部署至 AWS Amplify Hosting 等专用托管平台。
• 每个请求均需通过 IAM SigV4 签名或 JWT Bearer Token 验证，且只能访问创建运行时时预先声明的端口，安全边界清晰可控。