View a markdown version of this page

为代理使用隔离会话 - 亚马逊基岩 AgentCore
了解短暂的背景扩展对话和多步骤工作流程AgentCore 运行时会话生命周期如何使用会话按协议划分的会话标头

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

为代理使用隔离会话

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

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

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

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

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

注意

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

主题

了解短暂的背景

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

要在会话 stop/resume 周期中保存文件系统数据，请配置会话存储，即计算终止后仍能生存的永久目录。请参阅 AgentCore 运行时的文件系统配置。

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

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

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

AgentCore 运行时会话生命周期

会话创建

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

会话状态

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

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

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

  • 已停止：为会话配置的计算 (microVM) 已终止，会话已停止。这可能是由于不活动（默认 15 分钟）、达到最长计算寿命（默认为 8 小时）、调用 StopRuntimeSession API 明确停止或者根据运行状况检查认为计算运行状况不佳而发生。在下次调用时，会话将转换回活动状态，并使用相同的生命周期配置（即空闲RuntimeSessionTimeout 和 maxLifetime 最多可再配置 8 小时）配置新的计算。在删除 AgentCore 运行时 ARN 之前，会话本身仍然有效。如果运行时配置了会话存储，则配置的挂载路径上的文件系统数据会跨 stop/resume 周期保存。请参阅 AgentCore 运行时的文件系统配置。

注意

当服务提供或中断会话时，针对同一会话的第二项操作会返回可重试的 HTTP 409 () RetryableConflictException。Session operation in progress, please retry这个窗口很简短。 Already-running 会话不受影响。使用短暂的指数退避重试。

如何使用会话

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

  • 为每个用户或对话生成一个包含至少 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

微虚拟机粘性：Amazon Bedrock AgentCore 使用会话标头将请求路由到同一个微虚拟机实例。客户端必须捕获响应中返回的会话 ID，并将其包含在所有后续请求中，以确保会话关联性。如果没有一致的会话 ID，每个请求都可能被路由到新的 microVM，这可能会由于冷启动而导致延迟延长。

有关 MCP 协议的详细信息，包括无状态和有状态模式，请参阅 MCP 会话管理和微虚拟机粘性。