背景和价值
项目支持 InMemory、SQL、Redis 等 Session / Memory 后端，并支持多轮对话、状态读写、事件追加、长期记忆、Session Summary 等能力。生产环境经常先用 InMemory 开发，再切换到 SQL 或 Redis。如果不同后端在同一条 Agent 轨迹下保存的事件顺序、state、memory 或 summary 不一致，就会导致回放错乱、上下文丢失、长期记忆污染、摘要覆盖错误等问题。
该题要求构建一个可复用的回放一致性框架，用同一组标准化输入驱动多个后端，并自动生成差异报告。它既是测试工具，也是后端实现质量的基准。除事件和状态外，还需要覆盖 Session Summary 的生成、保存、读取和更新语义，避免长对话压缩后出现摘要丢失或跨后端不一致。
任务描述
设计并实现一个 Session / Memory / Summary replay harness。输入一组多轮对话、工具事件、state 更新、memory 写入和 summary 更新操作，分别写入不同后端，再读取出来做规范化比较，判断事件、状态、记忆和摘要是否一致。对无法做到完全一致的字段，需要提供合理的归一化策略或差异解释。
具体要求
至少覆盖以下 replay case：
1.单轮普通对话：只有用户输入和 Agent 文本输出。
2.多轮对话：连续追加多轮 user / assistant event。
3.工具调用对话：包含 function_call 和 function_response。
4.state 更新：同一 session 内多次写入和覆盖 state。
5.memory 写入和读取：模拟用户偏好、事实记忆或历史摘要。
6.summary 生成和更新：长对话触发摘要写入后，检查 summary 内容、版本、更新时间和关联 session 是否能正确回放。
7.summary 与事件截断：模拟历史事件被 summary 压缩后，检查保留事件、摘要和后续新事件是否能共同还原上下文。
8.异常恢复：写入中途失败或重复写入后，检查后端是否出现重复事件、脏状态或错误 summary。
比较时需要注意：
●对时间戳、自动生成 id、序列化字段顺序等非业务字段做归一化。
●对确实后端相关的字段差异写入 allowed_diff，不能简单忽略所有不一致。
●对 summary 需要区分“内容语义一致”和“存储元数据一致”：摘要文本可支持规范化比较，但 session 归属、summary 版本、覆盖关系不能模糊跳过。
●支持只运行 InMemory 的轻量模式，也支持在有环境变量时运行 SQL / Redis 集成模式。
●不要求贡献者本地必须安装真实 Redis / MySQL，但需要提供 mock、sqlite 或跳过策略。
交付物
●tests/sessions/test_replay_consistency.py 或等价测试框架。
●replay_cases/*.jsonl 或 Python fixture，描述标准输入轨迹。
●session_memory_summary_diff_report.json：记录每个后端、每个 case 的事件、state、memory、summary 差异。
●一份 150 – 300 字设计说明，解释归一化策略、summary 比较策略、允许差异和后端接入方式。
验收标准
1.至少支持 InMemory 与一个持久化后端或模拟持久化后端的对比。
2.公开提供的 10 条 replay case 必须 100% 检测出人为注入的不一致。
3.正常 case 误报率 ≤ 5%。
4.summary 丢失、summary 覆盖错误、summary 归属 session 错误三类问题检出率必须达到 100%。
5.差异报告必须能定位到 session id、event index 或 summary id、字段路径和两个后端的值。
6.轻量模式完整运行耗时 ≤ 30 秒；集成模式可通过环境变量开启或跳过。
本issue为2026犀牛鸟开源人才培养活动专属issue，仅供已报名参与犀牛鸟活动的同学认领
【认领时间】7月1日～7月31日（7月1日前认领视为无效❗）
【认领方式】在本issue评论区回复“已认领本任务”，即视为认领成功
【活动报名】需提前完成犀牛鸟报名问卷，问卷将用于活动登记和奖励发放：https://wj.qq.com/s2/26888567/gh2q
背景和价值
项目支持 InMemory、SQL、Redis 等 Session / Memory 后端，并支持多轮对话、状态读写、事件追加、长期记忆、Session Summary 等能力。生产环境经常先用 InMemory 开发，再切换到 SQL 或 Redis。如果不同后端在同一条 Agent 轨迹下保存的事件顺序、state、memory 或 summary 不一致，就会导致回放错乱、上下文丢失、长期记忆污染、摘要覆盖错误等问题。
该题要求构建一个可复用的回放一致性框架，用同一组标准化输入驱动多个后端，并自动生成差异报告。它既是测试工具，也是后端实现质量的基准。除事件和状态外，还需要覆盖 Session Summary 的生成、保存、读取和更新语义，避免长对话压缩后出现摘要丢失或跨后端不一致。
任务描述
设计并实现一个 Session / Memory / Summary replay harness。输入一组多轮对话、工具事件、state 更新、memory 写入和 summary 更新操作，分别写入不同后端，再读取出来做规范化比较，判断事件、状态、记忆和摘要是否一致。对无法做到完全一致的字段，需要提供合理的归一化策略或差异解释。
具体要求
至少覆盖以下 replay case：
1.单轮普通对话：只有用户输入和 Agent 文本输出。
2.多轮对话：连续追加多轮 user / assistant event。
3.工具调用对话：包含 function_call 和 function_response。
4.state 更新：同一 session 内多次写入和覆盖 state。
5.memory 写入和读取：模拟用户偏好、事实记忆或历史摘要。
6.summary 生成和更新：长对话触发摘要写入后，检查 summary 内容、版本、更新时间和关联 session 是否能正确回放。
7.summary 与事件截断：模拟历史事件被 summary 压缩后，检查保留事件、摘要和后续新事件是否能共同还原上下文。
8.异常恢复：写入中途失败或重复写入后，检查后端是否出现重复事件、脏状态或错误 summary。
比较时需要注意：
●对时间戳、自动生成 id、序列化字段顺序等非业务字段做归一化。
●对确实后端相关的字段差异写入 allowed_diff，不能简单忽略所有不一致。
●对 summary 需要区分“内容语义一致”和“存储元数据一致”：摘要文本可支持规范化比较，但 session 归属、summary 版本、覆盖关系不能模糊跳过。
●支持只运行 InMemory 的轻量模式，也支持在有环境变量时运行 SQL / Redis 集成模式。
●不要求贡献者本地必须安装真实 Redis / MySQL，但需要提供 mock、sqlite 或跳过策略。
交付物
●tests/sessions/test_replay_consistency.py 或等价测试框架。
●replay_cases/*.jsonl 或 Python fixture，描述标准输入轨迹。
●session_memory_summary_diff_report.json：记录每个后端、每个 case 的事件、state、memory、summary 差异。
●一份 150 – 300 字设计说明，解释归一化策略、summary 比较策略、允许差异和后端接入方式。
验收标准
1.至少支持 InMemory 与一个持久化后端或模拟持久化后端的对比。
2.公开提供的 10 条 replay case 必须 100% 检测出人为注入的不一致。
3.正常 case 误报率 ≤ 5%。
4.summary 丢失、summary 覆盖错误、summary 归属 session 错误三类问题检出率必须达到 100%。
5.差异报告必须能定位到 session id、event index 或 summary id、字段路径和两个后端的值。
6.轻量模式完整运行耗时 ≤ 30 秒；集成模式可通过环境变量开启或跳过。
本issue为2026犀牛鸟开源人才培养活动专属issue，仅供已报名参与犀牛鸟活动的同学认领
【认领时间】7月1日～7月31日（7月1日前认领视为无效❗）
【认领方式】在本issue评论区回复“已认领本任务”，即视为认领成功
【活动报名】需提前完成犀牛鸟报名问卷，问卷将用于活动登记和奖励发放：https://wj.qq.com/s2/26888567/gh2q