[Feature Request] 提议实现基于哈希的通用会话恢复

[2256593769]

提案概述

提议在项目中引入一套通用的历史记录哈希映射系统。

这可以利用官方的token缓存来提升回复速度，我曾在DeepSeek-Free-API中实现过该功能，经测试可以提升响应速度(尤其是开始阶段的字节填充速度)并显著减少账号被限速的概率(毕竟减少了官方服务器的计算量，降低了官方服务器的压力)

核心实现逻辑

1.通用的归一化工具

建立一个通用的归一化工具，将输入的 messages 数组转换为唯一的哈希指纹：

• 逻辑：对历史消息序列进行格式化拼接（排除最新的 User Prompt），并计算 MD5/SHA 值。
• 作用：作为查找既有会话状态的全局唯一索引。

2. 通用状态缓存层

在 CacheManager 基础上，构建一个专用的会话状态存储：

• 存储内容：Map<HistoryHash, { providerId, sessionId, lastMessageId, accountToken }>。
• 机制：支持跨提供商的状态存储，能够根据对话的“指纹”找回其在后端对应的精准位置。

3. 工作流程

为会话引入以下标准化流程：

前置路由

• 适配器在发起请求前，计算去除最新用户回复的当前对话背景的哈希。
• 从缓存层查询是否已有对应的后端节点（即该对话历史是否曾被处理过）。
• 若命中，则自动将缓存中的 sessionId 和 lastMessageId 注入到提供商特定的请求参数中（如 DeepSeek 的 parent_message_id 或 Kimi 的 chat_id）。

状态捕获

• 在流式响应或非流式响应结束时，提取提供商返回的最新 message_id 和 session_id。
• 将“当前完整对话历史”的哈希作为 Key，将最新的状态存入缓存。

适用范围

该机制可作为通用中间件或基类逻辑，适用于：

• DeepSeek (利用 parent_message_id)
• Kimi (利用 chat_id 与 parentId)
• GLM/ZhipuAI (利用 conversation_id)
• Minimax/Mimo 等其他具备会话 ID 概念的 Web 接口