View a markdown version of this page

使用客服人員的隔離工作階段 - Amazon Bedrock AgentCore
了解暫時性內容延伸對話和多步驟工作流程AgentCore 執行期工作階段生命週期如何使用工作階段依通訊協定的工作階段標頭

使用客服人員的隔離工作階段

Amazon Bedrock AgentCore 執行期可讓您隔離每個使用者工作階段，並在使用者工作階段中的多個調用中安全地重複使用內容。工作階段隔離對於 AI 代理器工作負載至關重要，因為其獨特的操作特性：

  • 完成執行環境分離：AgentCore 執行期中的每個使用者工作階段都會收到自己的專用microVM，其中包含隔離的運算、記憶體和檔案系統資源。這可防止某個使用者的代理程式存取另一個使用者的資料。工作階段完成後，會終止整個 microVM，並清理記憶體以移除所有工作階段資料，消除跨工作階段污染風險。

  • 具狀態推理程序：與無狀態函數不同，AI 代理器會在其執行週期中維持複雜的情境狀態，除了多轉對話的簡單訊息歷史記錄之外。AgentCore Runtime 會在工作階段中安全地保留此狀態，同時確保不同使用者之間的完全隔離，啟用個人化客服人員體驗，而不會犧牲資料邊界。

  • 特殊權限工具操作 ：AI 代理器透過存取各種資源的整合工具，代表使用者執行特殊權限操作。AgentCore Runtime 的隔離模型可確保這些工具操作維持適當的安全內容，並防止不同使用者工作階段之間的憑證共用或許可提升。

  • 非確定性程序的確定性安全性：由於基礎模型的概率性質，AI 代理器行為可能是非確定性的。AgentCore 執行期無論代理程式執行模式為何，都能提供一致的決定性隔離界限，提供企業部署所需的可預測安全屬性。

注意

AgentCore 不會強制執行session-to-user映射 - 您的用戶端後端應該維持使用者與其工作階段 IDs之間的關係。此外，您的用戶端後端應該實作邏輯，讓使用者進行工作階段生命週期管理，例如每個使用者的工作階段數量上限。如需完整的工作階段隔離指引，請參閱 AgentCore 執行期的安全最佳實務。

主題

了解暫時性內容

根據預設，與工作階段相關聯的運算 (microVM) 是暫時性的。儲存在記憶體中或寫入磁碟的任何資料只會在運算生命週期內持續存在。這包括對話歷史記錄、使用者偏好設定、中繼計算結果，以及您客服人員維護的任何其他狀態資訊。

若要跨工作階段停止/繼續週期保留檔案系統資料，請設定工作階段儲存 — 可承受運算終止的持久性目錄。請參閱 AgentCore 執行期的檔案系統組態。

對於需要保留超過工作階段生命週期的結構化資料 （例如使用者對話歷史記錄、學習到的偏好設定或重要洞見），請使用 AgentCore 記憶體。此服務提供專為代理程式工作負載設計的專用持久性儲存，同時具有短期和長期記憶體功能。

延伸對話和多步驟工作流程

與每次請求後終止的傳統無伺服器函數不同，AgentCore 支援由暫時性運算支援的隔離工作階段，每個生命週期最多持續 8 小時。這可簡化建置多步驟代理程式工作流程，因為您可以對相同環境進行多次呼叫，而每個調用都會根據先前互動建立的內容。您可以將 InvokeAgentRuntime用於代理程式推理，以及用於同一工作階段中的InvokeAgentRuntimeCommand確定性 shell 命令執行。

AgentCore 執行期工作階段生命週期

工作階段建立

在第一次調用時，會使用應用程式提供的唯一 runtimeSessionId 建立新的工作階段。AgentCore 執行期會為每個工作階段佈建專用執行環境 (microVM)。在對相同工作階段的調用之間保留內容。InvokeAgentRuntime 和 在相同的工作階段上InvokeAgentRuntimeCommand操作 — 命令會看到與代理程式相同的容器、檔案系統和環境。

工作階段狀態

工作階段狀態由運算生命週期決定，可以是下列其中一項：

  • 作用中 ：處理同步請求、執行命令或執行背景任務。根據對執行階段工作階段的調用，自動追蹤同步調用和命令執行活動。背景任務會透過客服人員代碼，在 ping 中以「HealthyBusy」狀態回應來傳達。

  • 閒置 ：未處理任何請求或背景任務時。工作階段已完成處理，但仍可用於未來的調用。

  • 已停止 ：為工作階段佈建的運算 (microVM) 已終止，且工作階段已停止。這可能是由於閒置 （預設 15 分鐘）、達到最大運算生命週期 （預設 8 小時）、透過叫用 StopRuntimeSession API 明確停止，或根據運作狀態檢查將運算視為運作狀態不佳。工作階段會在下次調用時轉換回作用中，並使用相同的生命週期組態佈建新的運算 （即 idleRuntimeSessionTimeout 和 maxLifetime，最多可達 8 小時）。工作階段本身會保持有效，直到刪除 AgentCore 執行期 ARN 為止。如果使用工作階段儲存體設定執行時間，則設定掛載路徑的檔案系統資料會在整個停止/繼續週期中持續存在。請參閱 AgentCore 執行期的檔案系統組態。

如何使用工作階段

若要有效使用工作階段：

  • 為每個使用者產生唯一的工作階段 ID 或使用至少 33 個字元的對話

  • 傳遞所有相關調用的相同工作階段 ID

  • 針對不同的使用者或對話使用不同的工作階段 IDs

使用對話工作階段的範例 

# First message in a conversation

response1 = agent_core_client.InvokeAgentRuntime(
   agentRuntimeArn=agent_arn,
   runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4()
   payload=json.dumps({"prompt": "Tell me about AWS"}).encode()
)

# Follow-up message in the same conversation reuses the runtimeSessionId.

response2 = agent_core_client.InvokeAgentRuntime(
   agentRuntimeArn=agent_arn,
   runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4()
   payload=json.dumps({"prompt": "How does it compare to other cloud providers"}).encode()
)

透過將相同的 runtimeSessionId 用於相關調用，您可以確保在整個對話中維護內容，讓您的客服人員能夠提供以先前互動為基礎的一致回應。

依通訊協定的工作階段標頭

呼叫客服人員時，請包含適當的工作階段標頭，以確保請求路由至相同的 microVM。標頭取決於代理程式設定的通訊協定：

通訊協定 工作階段標頭

MCP

Mcp-Session-Id

HTTP

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

A2A

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

AG-UI

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

MicroVM 黏性 ：Amazon Bedrock AgentCore 使用工作階段標頭將請求路由到相同的 microVM 執行個體。用戶端必須擷取回應中傳回的工作階段 ID，並將其包含在所有後續請求中，以確保工作階段親和性。如果沒有一致的工作階段 ID，每個請求可能會路由到新的microVM，這可能會導致因冷啟動而導致額外的延遲。

如需 MCP 通訊協定的詳細資訊，包括無狀態和有狀態模式，請參閱 MCP 工作階段管理和microVM黏性。