View a markdown version of this page

为代理使用隔离会话 - Amazon Bedrock AgentCore
了解短暂的背景扩展对话和多步骤工作流程AgentCore 运行时会话生命周期如何使用会话按协议列出的会话标头

为代理使用隔离会话

Amazon Bedrock AgentCore Runtime 允许您隔离每个用户会话，并在用户会话中的多次调用中安全地重复使用上下文。由于 AI 代理工作负载具有独特的操作特性，会话隔离对于 AI 代理工作负载至关重要：

  • 执行环境完全分离： AgentCore Runtime 中的每个用户会话都会收到自己的专用 microVM，其中包含独立的计算、内存和文件系统资源。这可以防止一个用户的代理访问另一个用户的数据。会话完成后，整个 microVM 将被终止并清理内存以删除所有会话数据，从而消除跨会话污染风险。

  • 状态推理流程：与无状态函数不同，AI 代理在整个执行周期中保持复杂的上下文状态，而不仅仅是用于多回合对话的简单消息历史记录。 AgentCore Runtime 可在会话中安全地保留此状态，同时确保不同用户之间的完全隔离，从而在不影响数据边界的情况下实现个性化的代理体验。

  • 特权工具操作：AI 代理通过访问各种资源的集成工具代表用户执行特权操作。 AgentCore Runtime 的隔离模型可确保这些工具操作维护适当的安全环境，并防止不同用户会话之间的凭据共享或权限升级。

  • 非确定性流程的确定性安全：由于基础模型的概率性质，AI 代理行为可能是非确定性的。 AgentCore 无论代理执行模式如何，Runtime 都提供一致的确定性隔离边界，从而提供企业部署所需的可预测安全属性。

注意

AgentCore 不强制执行会话到用户的映射-您的客户端后端应维护用户与其会话 ID 之间的关系。此外，您的客户端后端应实现用户到会话生命周期管理的逻辑，例如每个用户的最大会话数。有关完整的会话隔离指南，请参阅 AgentCore Runtime 安全最佳实践。

主题

了解短暂的背景

默认情况下，与会话关联的计算 (microVM) 是短暂的。存储在内存中或写入磁盘的任何数据仅在计算生命周期内保留。这包括对话历史记录、用户首选项、中间计算结果以及您的代理维护的任何其他状态信息。

要在会话 stop/resume 周期中保留文件系统数据，请配置会话存储，即计算终止后仍然存在的永久目录。参见 AgentCore Runtime 的文件系统配置。

对于需要在会话生命周期之后保留的结构化数据（例如用户对话历史记录、学习偏好或重要见解），请使用 AgentCore Memory。该服务提供专门为代理工作负载设计的永久存储，具有短期和长期内存功能。

扩展对话和多步骤工作流程

与每次请求后终止的传统无服务器函数不同， AgentCore 它支持由每个生命周期持续长达 8 小时的临时计算支持的隔离会话。这简化了多步骤代理工作流程的构建，因为您可以对同一个环境进行多次调用，每次调用都建立在先前交互建立的上下文之上。既可以用于代理推理，也可以InvokeAgentRuntime用于在同一个会话中执行确定性的 shell 命令。InvokeAgentRuntimeCommand

AgentCore 运行时会话生命周期

会话创建

在第一次调用时会创建一个新的会话，其运行时间由您的应用程序SessionId 提供。 AgentCore 运行时为每个会话预置一个专用的执行环境 (microVM)。在调用同一会话之间，上下文会被保留。两者都在InvokeAgentRuntime同一个会话上InvokeAgentRuntimeCommand运行 — 命令看到的容器、文件系统和环境与代理相同。

会话状态

会话状态由计算生命周期决定，可以是以下状态之一：

  • 活动：要么处理同步请求，要么执行命令，要么执行后台任务。根据对运行时会话的调用，自动跟踪同步调用和命令执行活动。代理代码通过在 ping 中以 “HealthyBusy” 状态进行响应，从而传达后台任务。

  • 空闲：未处理任何请求或后台任务时。会话已完成处理，但仍可用于将来的调用。

  • 已停止：为会话配置的计算 (microVM) 已终止，会话已停止。这可能是由于不活动（默认为 15 分钟）、已达到最大计算生命周期（默认为 8 小时）、调用 StopRuntimeSessionAPI 后显式停止，或者根据运行状况检查认为计算不健康。下次调用时，会话将转换回活动状态，并配置新的计算，其生命周期配置相同（即空闲RuntimeSessionTimeout 和 maxLifetime 最多可延长 8 小时）。在删除 AgentCore 运行时 ARN 之前，会话本身一直有效。如果运行时配置了会话存储，则配置的装载路径上的文件系统数据会跨 stop/resume 周期保留。参见 AgentCore Runtime 的文件系统配置。

如何使用会话

要有效使用会话，请执行以下操作：

  • 为每个用户或对话生成一个至少包含 33 个字符的唯一会话 ID

  • 为所有相关调用传递相同的会话 ID

  • 为不同的用户或对话使用不同的会话 ID

示例：使用会话进行对话 

# 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()
)

通过SessionId 对相关调用使用相同的运行时，可以确保在整个对话中保持上下文，从而使您的代理能够提供基于先前交互的连贯响应。

按协议列出的会话标头

调用代理时，请包括相应的会话标头，以确保请求被路由到同一个 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 粘性。