机器人多轮交互消息的ID化存储与高效回溯方案需求

核心设计思路 #

放弃单一Map结构，改用分层存储模型，同时引入独立的会话ID生成与绑定机制，解决ID追踪困难问题。

具体实现方案 #

1. 定义结构化会话实体 #

创建包含全链路关联信息的会话对象，替代原数组存储：

interface Session {
  sessionId: string;       // 唯一会话ID，用于用户后续交互标识
  userId: string;          // 用户标识（如Poui）
  initialRequest: string;  // 用户首次请求内容
  serviceFirstResponse: string; // 服务首次响应内容
  followUpRecords: Array<{
    userInput: string;     // 用户后续交互输入
    serviceResponse: string; // 服务对应响应内容
  }>; // 后续交互记录集合
}

2. 双Map组合存储结构 #

使用两个Map实现双向快速查询：

• userIdToSessions: 键为用户ID，值为该用户的会话列表，用于按用户回溯所有历史会话
• sessionIdToSession: 键为会话ID，值为完整会话对象，用于快速通过会话ID定位具体会话

代码示例：

// 用户ID到会话列表的映射
const userIdToSessions = new Map<string, Session[]>();
// 会话ID到会话对象的映射
const sessionIdToSession = new Map<string, Session>();

3. 会话ID生成与绑定逻辑 #

• 用户首次发消息时，生成唯一会话ID（可采用UUID、时间戳+随机字符串等规则）
• 将会话ID返回给用户，明确告知后续交互需携带该ID
• 同步将新创建的会话对象存入两个Map中

4. 交互流程处理 #

首次交互步骤

1. 接收用户消息（如Poui发送"Hi 123"）
2. 生成会话ID（如sess_20240520_1001）
3. 调用服务获取首次响应"XXX"
4. 构建会话对象并插入双Map存储
5. 向用户返回：XXX\n若需进一步交互，请在消息开头填写{sess_20240520_1001}

后续交互步骤

1. 解析用户消息，提取开头的会话ID（如从"{sess_20240520_1001} U1"中提取ID）
2. 通过sessionIdToSession快速定位对应会话对象
3. 调用服务获取二次响应"YYY"
4. 将本次交互记录添加到会话对象的followUpRecords数组
5. 向用户返回响应"YYY"

5. 方案优势 #

• 解决原单一Map的ID追踪难题：双Map结构支持按用户或会话ID双向快速查询
• 全链路信息留存：每个会话对象包含从首次请求到所有后续交互的完整记录，便于回溯排查
• 扩展性强：可轻松添加会话创建时间、超时时间等字段，支持会话过期清理、持久化存储等扩展功能

补充优化建议 #

• 增加会话超时机制：定期清理长时间未交互的会话，避免内存占用过高
• 支持持久化存储：若需跨服务重启保留会话，可将Map数据同步到Redis或数据库中

内容的提问来源于stack exchange，提问作者Poui