AWS 演示如何用 Amazon Bedrock AgentCore Session endpoints 边写边预览编码智能体生成的网页

发生了什么

AWS 在官方博客中介绍 Amazon Bedrock AgentCore runtime 的 Session endpoints 能力，并给出一个可运行的示例。核心问题是编码智能体已经能生成可用的网页应用，但如果每次改动都要先复制出去再部署，评审节奏就会被部署速度拖住。Session endpoints 让应用留在智能体所在的会话里运行，开发者从自己的浏览器直接打开。

每个会话获得一个带认证的 URL，它把请求的 HTTP 方法、路径、查询串、请求体和 WebSocket 连接转发到被允许的端口。端口在调用 CreateAgentRuntime 时通过 allowedPorts 声明，取值为 8000–12000 范围内的单个端口或区间，最多 5 项。客户端统一连 443，主机名前缀决定会话内的目标端口。使用 IAM 的运行时要求每个请求带 SigV4 签名，调用方还需具备 bedrock-agentcore:InvokeAgentRuntimeProxy 权限；使用 JWT 授权器的运行时则携带 bearer token。

示例分四部分：智能体在 8080 端口接收 InvokeAgentRuntime 调用，用 list、read、write、edit 四个工具改文件；Vite 开发服务器在 8090 端口提供网站并通过热重载 WebSocket 推送变更；本机的 PreviewApp 负责预览页、转发提示词并开一个本地端点；本地端点把凭据加到每个请求和 WebSocket 握手上再转发。示例中智能体调用 Claude Haiku 5.5 决定改什么，作者演示了把网站切换为深色主题、把按钮改成绿色，页面无需刷新即更新。

文章还列出拒绝情形：端口不在 allowedPorts 返回 403 AccessDenied，缺少有效凭据返回 403 或 401，端口允许但无服务监听返回 502 PortNotReachable，会话已不存在返回 404 SessionNotFound。

编辑部观察

这篇材料的价值在于把“预览”从部署流程里拆了出来。Session endpoint 与 runtime endpoint 是两种东西：后者用于让调用方稳定访问某个版本的智能体，前者只用于查看会话里跑着什么，会话结束即失效。作者明确说明它不适合直接对外服务，面向用户仍需部署到 AWS Amplify Hosting 之类的托管服务。

限制条件也写得具体：Session endpoints 只适用于 microVM 运行时，不支持 Instances 计算类型；URL 通过公网 HTTPS 可达，入站连接不支持 AWS PrivateLink；网站与智能体同处一个会话，访问控制并不把两者隔开，因此执行角色只应授予智能体实际需要的权限；若运行时替换了会话计算，已打开的连接会断开，编辑结果可能丢失，除非会话使用持久存储。

实践建议

打算试这套流程的团队，可以先核对三件事：运行时所在区域是否已提供 Session endpoints；allowedPorts 是否只列了真正需要预览的端口；执行角色是否按最小权限收敛。示例用 zip 直传 S3 部署 Node.js 代码，不需要 Docker 或 Amazon ECR，适合先做小范围验证。若提示词可能来自他人，作者建议考虑 Amazon Bedrock Guardrails 过滤，并在发布前人工复核智能体的改动。