Multi-Turn conversations

📚 学习笔记：维护多轮对话上下文 (Maintaining Multi-Turn Conversation Context)

核心概念：

• API 的无状态性 (Stateless Nature):
• Bedrock 和 Cloud 服务本身不存储任何用户发送的消息或模型返回的响应。
• 这意味着模型不会自动记住之前的对话内容。

• 手动维护上下文 (Manual Context Management):
• 若要实现多轮对话（即保持对话的连贯性/上下文），开发者必须在代码中手动维护一个包含所有历史消息的列表。
• 每次发送后续请求时，必须将整个历史消息列表提供给 API。

对话流程与实现 (Conversation Flow and Implementation):

• 基本流程：
• 发送初始用户消息 (User Message)。
• 接收模型响应 (Assistant Response)。
• 将该响应追加到消息列表中。
• 发送下一轮用户消息 (User Message)。
• 将完整的历史消息列表再次发送给 API。
• 重复步骤 2-5，直到对话结束。

• 代码辅助工具 (Helper Functions):
• 建议使用辅助函数（如 add_user_message 和 add_assistant_message）来简化消息的创建和列表的追加操作。
• 使用一个主函数（如 chat）来封装 API 调用，接收完整的消息列表并返回最终的文本内容。

关键规则 (Critical Rules):

• 角色交替 (Role Alternation):
• 在发送给 API 的消息列表中，用户 (User) 和助手 (Assistant) 的角色必须交替出现。
• 绝对不能出现两个连续的用户消息，也不能出现两个连续的助手消息。
• （例如：User → Assistant → User → Assistant → ... ）

Takeaways

• API（如Bedrock）是无状态的，不会自动存储或记住用户发送的消息。
• 实现多轮对话必须在代码中手动维护一个包含所有历史消息的列表。
• 每次发送新的请求时，必须将完整的历史消息列表（包括所有过往的问答）提供给API。
• 在发送给API的消息列表中，用户（User）和助手（Assistant）的角色必须严格交替出现。