AWS 推出 AgentCore Session endpoints：讓程式碼代理邊改、邊在瀏覽器即時預覽網頁應用

發生了什麼事

AWS 在 2026 年 10 月 30 日發表部落格文章，介紹 Amazon Bedrock AgentCore runtime 的 Session endpoints。「程式碼代理」是能自行撰寫、修改程式的 AI；代理每次執行任務的一段工作期間稱為「工作階段」(session)。AWS 指出，AgentCore runtime 會讓每個工作階段在各自獨立的 microVM（一種輕量、彼此隔離的虛擬機器）中執行；Session endpoints 則讓使用者能從自己的瀏覽器開啟該工作階段中運行的應用程式。

AWS 說明的背景是：若應用程式必須先複製出去、部署到別處，每次修改都要等部署，審查速度就會被拖慢；若應用程式持續在代理編輯的地方運行，每次修改幾秒內就能在瀏覽器中看到。

AWS 的示範是一個程式碼代理：使用者要求把網站改成深色主題，代理儲存樣式表後，瀏覽器中的網站不必重新整理就更新了。以下內容均為 AWS 的說法。

運作方式與限制

據 AWS 說明，Session endpoints 為每個工作階段提供一個需驗證的網址，會把每個請求的 HTTP 方法、路徑、查詢字串與內容，以及 WebSocket 連線（一種讓伺服器能主動把更新推送給瀏覽器的長時間連線），轉送到使用者允許的連接埠。連接埠（port）可理解為同一台機器上不同服務的「門牌號碼」。

• 連接埠：AWS 表示，建立 runtime 時以 allowedPorts 設定，共 1 至 5 項，每項為單一連接埠或 8000–12000 範圍內的區間，並排除平台保留連接埠；應用程式本身必須在該連接埠監聽並綁定 0.0.0.0。
• 網址：AWS 表示，網址會放在 InvokeAgentRuntime 回應的標頭中。
• 驗證：AWS 表示，使用 IAM（AWS 的身分與存取權限管理服務）的 runtime，每個請求都要帶 SigV4 簽章（AWS 用來證明請求者身分的簽名方式），呼叫者也需要 bedrock-agentcore:InvokeAgentRuntimeProxy 權限；使用 JWT 授權的 runtime 則帶 bearer token（一種存取憑證）。AWS 強調，知道網址並不等於取得存取權。
• 範圍：AWS 表示，網址僅限單一工作階段，工作階段結束即失效；要對外提供服務，應部署到 AWS Amplify Hosting 等託管服務。
• 本機端點：AWS 表示，瀏覽器無法自行為頁面請求加上簽章或 token，因此 bedrock-agentcore SDK 的客戶端可在本機開一個端點，替請求補上憑證再轉送。

AWS 也區分了 Session endpoint 與原本就有的 runtime endpoint：後者是呼叫代理本身的入口，前者則用來查看代理在工作階段裡跑出來的東西。

對開發團隊的意義

對開發團隊而言，這代表審查 AI 代理產出的網頁原型時，可以在代理工作的同一環境中直接看到結果，不必每次先部署。AWS 也提醒，這個功能用於建置、測試與審查，不是對終端使用者提供服務的方式。

AWS 還提到若其他人也能對程式碼代理下指令，可考慮使用 Amazon Bedrock Guardrails 過濾有害的指令與回應，並在發佈前審查代理的修改。AWS 稱示範代理的檔案工具會拒絕網站資料夾以外的路徑。

請求被拒絕時會看到什麼

AWS 另表示，請求會在 AWS CloudTrail 記錄為 InvokeAgentRuntimeProxy 事件；runtime 在轉送前會移除自己的驗證標頭，網站不會收到使用者的簽章。

適用條件與已知限制

• AWS 表示，Session endpoints 適用於 microVM runtime，不支援 Instances 運算類型。
• AWS 表示，網址透過公開 HTTPS 存取，入站連線不支援 AWS PrivateLink。
• AWS 的示範需要：提供 Session endpoints 的 AWS 區域中的帳戶、Python 3.10 以上、bedrock-agentcore 1.25.2 以上、boto3 1.43.122 以上、Node.js 22 以上，以及 Amazon Bedrock 中的 Claude Haiku 5.5 存取權。
• AWS 在 agentcore-samples GitHub 儲存庫提供完整範例與筆記本；為避免持續計費，AWS 建議結束後停止預覽並刪除範例建立的 runtime、上傳的程式碼與 IAM 角色。

查看同分類最新消息

• AI 新聞與趨勢