是的，在 AWS Bedrock 中使用多轮对话时，您需要手动管理并在每次请求时发送对话历史记录。 Bedrock 的 API 是无状态的，这意味着它不会在请求之间保留上下文。 为了保持连贯的对话，您的应用程序必须跟踪整个消息交换并将其包含在每个 API 调用中。 这种方法可确保模型具有生成相关响应所需的上下文，类似于您通过其 API 处理与 ChatGPT 等模型的对话的方式。
例如，如果您通过 Bedrock 使用 Anthropic 的 Claude 模型，您需要构建每个 API 请求以包含消息列表。 每条消息都有一个 role（例如，“用户”或“助手”）和 content（实际文本）。 假设用户问：“法国的首都是什么？” 模型回答“巴黎”。 对于下一个查询“它离伦敦有多远？”，您需要在请求中发送初始交换和新问题。 消息列表如下所示
messages = [
{"role": "user", "content": "What’s the capital of France?"},
{"role": "assistant", "content": "Paris."},
{"role": "user", "content": "How far is it from London?"}
]
这种显式的历史记录允许模型识别上下文并准确地回答。 您通常会将此列表存储在应用程序的内存、数据库或会话存储中，并在发送更新后的列表之前附加每个新的交互。
关键考虑因素包括管理令牌限制和成本。 模型具有最大上下文窗口（例如，Claude 支持高达 10 万个令牌），因此长时间的对话可能需要截断旧消息或总结历史记录。 您还需要处理历史记录超过限制的情况的错误处理。 虽然手动管理增加了代码的复杂性，但它提供了对上下文的控制。 对于无服务器应用程序，AWS Step Functions 或 DynamoDB 等工具可以帮助跟踪跨调用的对话。 Bedrock 的无状态设计使基础设施保持简单，但将上下文管理的责任转移给开发人员。