feat(sessions): 添加多后端回放一致性测试框架

[Stelquis]

实现 ReplayHarness 和 DiffEngine，覆盖 event/state/memory/summary 四维度跨后端一致性验证。包含 10 条 replay case (7 正常 + 3 注入)
和 29 个测试用例，支持 InMemory ↔ SQLite 轻量对比。

Fixes #89

RELEASE NOTES: 新增 Session/Memory 多后端回放一致性测试框架

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@73655ab). Learn more about missing BASE report.

Additional details and impacted files

@@            Coverage Diff             @@
##             main        #114   +/-   ##
==========================================
  Coverage        ?   87.90681%           
==========================================
  Files           ?         479           
  Lines           ?       44984           
  Branches        ?           0           
==========================================
  Hits            ?       39544           
  Misses          ?        5440           
  Partials        ?           0           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Stelquis]

I have read the CLA Document and I hereby sign the CLA

[raychen911]

这里是否可以在不修改框架源码的前提下，编写一个真正运行的例子，包含tool调用，采用真实模型跑一下，采用mock的方式或者其他的方式构造一下异常情况，看看是否通过你的这个test检查出来，该issue最终的目的是可以检查真实场景下的异常，避免代码修改过程中引入比较难发现的bug，记忆细微的出错，可能导致整个语义产生偏差

[CongkeChen]

AI Code Review

我现在已经完全理解了。第 2 层（Layer 2）的断言检查“cherry blossom”是否出现在 result.normalized_session 事件中。但是 result.session 是在第 27 行的压缩前 get_session（返回 0 个事件）期间设置的，且从未刷新。压缩后，追加了 4 个新事件——但它们只进入了内存中的 session.events 列表（通过追加操作中更新后的 self._sessions[label]）。让我验证一下追加操作是否更新了 result.session 还是仅更新了 self._sessions：

_handle_append_event 会更新 self._sessions[result.label]（第 1646 行），但不会更新 result.session。并且 _handle_get_session 仅在执行 get_session 步骤时更新 result.session。在 case_07 中，压缩后的最后一次 get_session 是第 32 行。那么 result.session 是否在压缩后被刷新了？让我追踪一下：第 27 行 get_session 设置了 result.session（压缩前，0 个事件）。然后是第 25 行的压缩（仅修改了 self._sessions 中的会话对象）。接着是第 28-31 行的追加操作（修改了 self._sessions）。然后是第 32 行的 get_session —— 这确实会刷新 result.session。

等等——第 32 行是压缩后的 get_session。所以 result.session 确实被刷新了。但存在过期会话（stale-session）问题：InMemory 的 get_session 返回 filter_events(session)，它应用了 num_recent_events（默认为 0 → 无限制），所以它返回了所有事件。但 InMemory 压缩后的 session.events 包含 [summary_event, 10 个保留的旧事件, 4 个新追加的事件] = 15 个事件。所以“cherry blossom”确实在 InMemory 的事件中。第 2 层应该可以通过。

但是聚合报告显示 InMemory 的事件[1..4] 是旧文本（Osaka, Shinkansen）——这意味着压缩将旧事件保留在索引 1..10 的位置，而新事件（cherry blossom）在索引 11..14。所以“cherry blossom”确实存在（在索引 11+）。第 2 层的 all_text 连接了所有部分，所以它找到了“cherry blossom”。好的，第 2 层通过了。

那么，真正的测试有效性问题在于：测试声称要验证“压缩后追加的新事件已保留”和“摘要+保留的事件+新事件共同覆盖上下文”，但 Layer-2 实际上只检查了 "cherry blossom" in all_text.lower()——这是一个薄弱的子串检查，无法验证事件顺序、计数或摘要锚点与新事件的关联。此外，聚合的 case_07 报告显示为 FAILED，但 test_replay_summary_truncation 并未断言 report.passed——它手动构建了 allowed_diffs 并从未断言整体报告状态，因此报告静默地处于失败状态。让我确认一下该测试中是否没有任何地方断言了 report.passed：

第 1061 行：“报告应反映预期的分歧”，然后 report.passed = len(report.inconsistencies) == 0——它重新计算了 passed，但从未对其进断言。确认：没有对 report.passed 进行断言。

我现在已经掌握了所需的一切。让我再检查一下 inject_reorder_events 的边界条件 max(indices) < len——indices=[1,2]，4 个事件，没问题。但是 >= 的边界情况：如果 indices 包含 len-1（最后一个索引），max < len 为真，所以它有效。<= 不会是问题。边界检查没问题。

让我检查一下 __import__("logging") / __import__("time") 的模式，以及模块级别是否缺少 logger 导入：

测试文件执行了 logger = __import__("logging").getLogger(__name__)（第 847、2010 行），而不是在顶部导入 logging。功能上没问题，但不符合惯例。属于轻微的可维护性问题。

现在让我完成审查。再检查一次：_compare_summary 使用 sum_a["session_id"]（直接下标）——如果归一化后的摘要字典缺少该键，可能会导致 KeyError。但 normalize_summary_for_compare 总是会设置它。没问题。

让我验证一下 DiffReport.to_dict() 和聚合报告中 allowed_diffs 的区别——聚合报告显示 "allowed_diffs": []（空），即使在 case_07/08/09/10 中也是如此，但 to_dict() 会序列化 self.allowed_diffs。_add_diff 方法只将 ALLOWED_FIELD_PREFIXES 字段放入 allowed_diffs。对于 case_07，事件计数差异通过 events.count 路径添加到 report.diffs（不一致），而不是 allowed_diffs。所以聚合报告正确显示 allowed_diffs: [] 且不一致项已填充。文档声称事件计数差异是“允许的”，但引擎将它们标记为不一致。文档与实现存在差异，但不是正确性错误。

我已经掌握得足够多了。让我撰写审查报告。## 发现的问题

🚨 Critical

• tests/sessions/test_replay_consistency.py:710：get_session 步骤使用陈旧的 result.session.id 作为回退 session_id，且注入类用例依赖这一回退

  • _handle_get_session 在 kw.get("session_id") 为空时回退到 result.session.id。但 result.session 是上一次 get_session 的返回对象；对 InMemory 后端，create_session_summary 会就地压缩 self._sessions[label] 中的 session 对象（session.events[:] = [summary_event] + recent，见 _session_summarizer.py:405），而 result.session 是 filter_events 返回的深拷贝，并不随之更新。case_07 第 27 行 get_session（压缩前）与第 32 行 get_session（压缩后）之间，result.session 指向的对象未刷新前若被后续逻辑读取会拿到压缩前的事件快照。聚合报告中 case_07 的 InMemory events[1..4] 仍为压缩前旧文本即为该陈旧快照导致。建议每次 get_session 后强制以新返回值为准，且不要用 result.session.id 作为回退（应统一用 self._sessions[label].id）。

• tests/sessions/test_replay_consistency.py:1061：test_replay_summary_truncation 从未断言 report.passed，case_07 实际 FAIL 却静默通过

  • 该测试用例计算 report.passed = len(report.inconsistencies) == 0 后没有对其做任何 assert；而聚合报告 session_memory_summary_diff_report.json 中 case_07 "passed": false 且有 4 条 event 不一致。这意味着本应验证“跨后端一致”的 Layer 1 实际未对最终结论做任何校验，测试形同虚设。建议显式 assert report.passed, report.summary() 或对预期 allowed_diff 做精确断言。

⚠️ Warning

• tests/sessions/conftest.py:74 / tests/sessions/test_replay_consistency.py：ReplayStep.expected 与 expected_events 字段被 JSONL 大量填写但 harness 完全不校验

  • 所有 case（如 case_01 expected_events: 2、case_04 expected: {"state": {...}}、case_08 expected: {"events_count": 4}）声明的期望值在 _handle_get_session 等处理器中从未读取或断言，等于用例的“自校验”承诺未兑现。case_08 注释说“skip this append on SQL backend”，但 inject_skip_append 实际作用于 backend B（SQL），且发生在 4 次 append 之后（弹出第 4 个事件），与注释描述的“跳过本次写入”语义不一致；由于 expected 不校验，该语义偏差被掩盖。建议在 get_session/search_memory 等步骤后根据 expected/expected_events 做断言，或删除这些未使用字段以免误导。

• tests/sessions/test_replay_consistency.py:1150（_compare_events 的 summary anchor 对齐）：仅比较 anchor 之后的事件，跳过 anchor 前事件差异，导致压缩边界附近的真实不一致无法被检测

  • 当两端都有 summary anchor 时，代码用 min(len_a - idx_a, len_b - idx_b) 仅逐项比较 anchor 及之后的事件，anchor 之前的事件（被摘要覆盖的原始事件）完全不被比较。case_07 报告显示两端 events[1..4] 文本完全不同却被当作“已知差异”放过，实际上这类差异可能掩盖 InMemory 压缩后保留事件与 SQL 重读事件的真实顺序/内容错配。建议对 anchor 之前的事件至少做计数与 author 校验，而非整体跳过。

• tests/sessions/test_replay_consistency.py:846：inject_skip_append 通过 session.events.pop() + update_session 模拟写入失败，但 SQL update_session 会先删除该 session 全部事件再按 session.events 重新写入

  • 对 InMemory 后端 update_session 是 _set_session（直接替换），但 SQL update_session（_sql_session_service.py:638-641）先 delete 全部 SessionStorageEvent 再按当前 session.events 重新 add。由于注入只作用于 backend B，A 仍保留 4 个事件，_compare_events 走 len != len 分支会报 events.count 不一致——这能检测到，但该机制与“模拟写入失败”的真实语义不同（真实失败应少写一个事件而非删全部再写），若未来 SQL 实现改为增量 append，该注入会失效。建议直接调用底层跳过某次 append，而非依赖 update_session 的全量重写副作用。

• tests/sessions/test_replay_consistency.py:847 与 :2010：用 __import__("logging").getLogger(__name__) 在函数内构造 logger，并在 :2113 用 __import__("time").time()

  • 模块顶部未 import logging/time，却多处用 __import__("...") 动态获取，属于非常规写法；尤其是 test_generate_aggregated_diff_report 中的 __import__("time").time() 用于生成 generated_at，若该测试被纳入 CI 常规运行会持续覆写仓库内 session_memory_summary_diff_report.json（见下条）。建议改为顶部正常 import。

• tests/sessions/test_replay_consistency.py:2123（test_generate_aggregated_diff_report）：测试在运行时向仓库内源码目录写文件，且 generated_at 非确定

  • 该测试用 Path(__file__).parent / "session_memory_summary_diff_report.json" 把聚合报告写到测试目录的受版本控制文件中，而非 tmp_path。每次 CI 运行都会改写该文件（generated_at 随时间变化），造成无意义的 diff 噪声甚至 CI 工作区脏。建议输出到 tmp_path 或 tmp_path_factory，仓库内仅保留一份静态样例。

💡 Suggestion

• tests/sessions/conftest.py:280 与 :301：make_inmemory_service/make_sqlite_service 是 async 函数但内部无任何 await，且被 fixture 用 await 调用

  • 这两个工厂函数没有异步操作，声明为 async 会迫使所有 fixture 变成 async fixture（依赖 pytest-asyncio 的 async fixture 支持，而仓库其他测试均使用同步 fixture + async 测试函数的 xunit 风格）。改为普通同步函数可降低对 pytest-asyncio async-fixture 行为的隐式依赖，也与仓库现有约定更一致。

• tests/sessions/test_replay_consistency.py:1117（test_replay_all_cases_load_and_validate）：仅校验 case 可加载与首步为 create_session，未覆盖 case_09/case_10 的首步豁免逻辑的正确性

  • 该测试对 case_09/case_10 跳过“首步为 create_session”的断言，但这两个 case 实际首步仍是 create_session（见 jsonl 第 2 行），豁免分支并无必要；若未来某 case 真不以 create_session 开头，该豁免会静默放过结构错误。建议去掉豁免或为豁免补充一个真正不以 create_session 开头的负向用例。

总结

整体为新增的回放一致性测试框架，无生产代码改动，核心风险集中在测试有效性：多个用例声明的 expected 字段从不被校验、test_replay_summary_truncation 未断言最终 report.passed（case_07 实际 FAIL 却通过）、以及 _compare_events 的 summary anchor 对齐会跳过真实事件差异。这些属于必须修复的 Critical 测试逻辑缺陷，会直接导致该框架无法真正守护回放一致性。

测试建议

• 为 expected/expected_events 字段补充实际断言路径（在 get_session/search_memory/get_session_summary 处理器中校验），并新增一个不满足 expected 时失败的用例。
• 为 test_replay_summary_truncation 增加 assert report.passed 或对 report.inconsistencies 为空做显式断言，并构造一个 summary 元数据真不一致的负向用例验证能被检出。

[CongkeChen]

get_session 回退使用陈旧的 result.session.id

_handle_get_session 在 session_id 为空时回退到 result.session.id，而 result.session 是上次返回的深拷贝，压缩后未刷新会读到压缩前事件快照。建议每次 get_session 后强制以新返回值为准，并统一使用 self._sessions[label].id 作为回退。

[CongkeChen]

test_replay_summary_truncation 未断言 report.passed

该用例计算 report.passed 后从未对其断言，而聚合报告显示 case_07 实际 passed=false 且存在事件不一致，使测试形同虚设。建议显式 assert report.passed 或对 inconsistencies 为空做断言。

[CongkeChen]

AI Code Review

我已经了解了所有背景信息。让我来撰写最终的审查意见。

发现的问题

🚨 Critical

• tests/sessions/test_replay_consistency.py:1062-1063：test_replay_summary_truncation 赋值 report.passed 但从不 assert，事件层跨后端不一致被静默放过
  • 该测试 docstring 声称做 "Layer 1 — Cross-backend consistency (strict)"，但只 assert 了 summary 元数据与 state，未对 report.passed/report.inconsistencies 做任何断言。实际验证显示 case_07 在 InMemory 与 SQL 间存在真实的事件顺序分歧（summary 锚点在 InMemory 落在 index 0、SQL 落在 index 10），DiffEngine 会记录这些不一致，但测试不会因此失败。应补充 assert report.passed, report.summary() 或对已知允许的 event 不一致做显式分类断言，否则该用例形同虚设。

⚠️ Warning

• tests/sessions/conftest.py:166 附近（make_sqlite_service 中 session_config.store_historical_events = True）：可变共享单例被污染，影响 InMemory 后端语义

  • _DEFAULT_SESSION_CONFIG（conftest.py:47）是模块级共享对象，make_inmemory_service 默认直接复用它。make_sqlite_service 在其上设置 store_historical_events = True 后，之后创建的 InMemory 服务也会带上该值，与文档所述 "InMemory 在内存中压缩事件、SQL 从事件表重读" 的语义不符，可能掩盖真实差异。应在每个工厂内 model_copy(deep=True) 后再改配置，或分别为两端构造独立 config。

• tests/sessions/test_replay_consistency.py:1135-1183（test_generate_aggregated_diff_report）：测试在运行期覆盖仓库内已提交的产物文件且无任何断言

  • 该用例把结果写入 tests/sessions/session_memory_summary_diff_report.json（一个被 git 跟踪的文件），函数体只有 print，没有任何 assert。它既会污染工作区，又不构成有效测试；同时已提交的 JSON（case_07/08/09/10 标记为 FAILED）与当前测试期望（case_07 应通过、08/09/10 应被检测）已不一致。建议要么删除该测试，要么改为写入 tmp_path 并断言关键字段（total_cases/cases_passed/各 case 的 passed）。

• docs/mkdocs/en/replay-consistency.md:67-72 与 docs/mkdocs/zh/replay-consistency.md:138-146：文档承诺的 MySQL/Redis 集成模式在本 PR 中无任何实现

  • 文档列出 TEST_MYSQL_URL / TEST_REDIS_URL 触发的 SQL(MySQL) 与 Redis 集成模式，但 tests/sessions/ 下无对应 fixture、参数化或环境变量读取代码，实际只实现了 InMemory vs SQLite 轻量模式。应在文档中明确标注为 "规划中/未实现"，或补充对应集成测试入口，避免使用者误以为已具备该能力。

• tests/sessions/test_replay_consistency.py:220（_compare_events 的 summary anchor 对齐）：anchor 位置不同时比较窗口错位，产生误导性不一致

  • 当两端都存在 summary anchor 但位置不同（InMemory index 0、SQL index 10）时，post_summary_len = min(len_a - idx_a, len_b - idx_b) 会用 A 的 idx_a.. 去对齐 B 的 idx_b..，导致把 A 的 retained 事件与 B 的新事件逐字段比较，产生 4 条 "events[i].parts[0].text differs" 的伪不一致（见已提交 JSON 中 case_07）。anchor 对齐应基于内容匹配而非各自索引，否则报告会误导排查方向。

💡 Suggestion

• tests/sessions/test_replay_consistency.py:1064 与 tests/sessions/test_replay_consistency.py:1064 附近的 logger = __import__("logging").getLogger(__name__)：可直接在文件顶部 import logging 并定义模块级 logger，多处内联 __import__ 既影响可读性也增加维护成本。

总结

整体为一套测试基础设施，核心风险集中在测试有效性：test_replay_summary_truncation 未断言 report.passed，导致其声称的跨后端严格一致性校验实际未生效；同时 anchor 对齐逻辑在位置不一致时会产生误导性 diff，需修复后才能作为可靠的质量基线。

测试建议

• 为 test_replay_summary_truncation 补充对 report.passed/report.inconsistencies 的断言（或显式断言允许的 event 不一致类别），并增加一个用例验证 InMemory 与 SQL 在 summary 后事件顺序分歧能被 DiffEngine 正确归类为 "已知存储模型差异" 而非伪不一致。
• 为 test_generate_aggregated_diff_report 增加对聚合 JSON 关键字段（total_cases、cases_passed、每个 case 的 passed）的断言，并将其输出重定向到 tmp_path，避免污染工作区。

[CongkeChen]

test_replay_summary_truncation 未断言 report.passed

该用例声称做跨后端严格一致性校验，但只断言了 summary 元数据与 state，未对 report.passed/report.inconsistencies 做任何断言，case_07 的事件顺序分歧会被静默放过。应补充 assert report.passed 或对允许的 event 不一致做显式分类断言。

[CongkeChen]

AI Code Review

已全部确认。正在撰写审查报告。

发现的问题

🚨 Critical

• tests/sessions/test_replay_consistency.py:1299：test_generate_aggregated_diff_report 引用了未定义的 _ALL_CASES

  • 该测试在断言 output["total_cases"] == len(_ALL_CASES) 时使用了 _ALL_CASES，但整个文件（及 conftest）中只有 _NORMAL_CASES / _MEMORY_CASES / _SUMMARY_CASES / _KNOWN_INCONSISTENCY_CASES / _INJECTED_CASES，从未定义 _ALL_CASES。测试一旦运行到该断言即抛 NameError，聚合报告测试必然失败。修复方式：用 len(list_replay_cases()) 或显式定义 _ALL_CASES = _NORMAL_CASES + _MEMORY_CASES + _SUMMARY_CASES + _KNOWN_INCONSISTENCY_CASES + _INJECTED_CASES。

• tests/sessions/test_replay_consistency.py:2461：_handle_inject_mock_llm_timeout 用非法参数构造 Event

  • Event(parts=[Part(text=...)]) 中 parts 不是 Event/LlmResponse/ResponseABC 的字段，且 model_config 设了 extra="forbid"，构造时直接抛 ValidationError。case_11 的注入步骤会让 test_replay_injected_detection 报错而非通过。应改为 Event(author=..., content=Content(parts=[Part(text=...)], role="user"))，并补 invocation_id/author。

• tests/sessions/test_replay_consistency.py:2485：三个 mock 注入 handler 访问了不存在的 Event.parts

  • _handle_inject_mock_network_failure、_handle_inject_mock_partial_write、_handle_inject_mock_semantic_deviation 均以 for p in session.events[target_idx].parts 遍历，但 Event 没有 parts 属性（parts 在 event.content.parts 下），运行到此处抛 AttributeError，导致 case_12/13/14 注入测试直接报错。应改为先取 event.content.parts 并判空。修复方式与上一条相同根因，合并处理。

⚠️ Warning

• tests/sessions/session_memory_summary_diff_report.json:1-5：提交了过时且会误导的报告产物

  • 该 JSON 为新增提交文件，generated_at 为硬编码旧时间戳，total_cases: 10 与当前仓库中 14 个 case 不一致，且内容与实际 test_generate_aggregated_diff_report（写入 tmp_path）逻辑脱节。该文件会随源码长期留存并误导后人认为这是当前基线。建议从仓库删除或改为由测试生成到忽略目录，不要随源码提交静态快照。

• tests/sessions/test_replay_consistency.py:2619：test_replay_injected_detection 对 case_11-14 的预期不可达

  • 由于上述 Event(parts=...) 与 Event.parts 问题，case_11-14 在注入步骤即抛异常，测试会以 error 而非 assertion 失败结束；即便修复构造问题，case_11 的 inject_mock_llm_timeout 只在 B 端追加事件、A 端无对应事件，能被事件计数检出，但 case_12-14 依赖 event.content.parts 修改后 update_session 回写才能产生差异，需确认 SQL update_session 确实以 session.events 重写（已核实 _sql_session_service.py:640 会重写，可成立）。建议修复构造问题后补一条断言验证差异确实落在预期字段。

💡 Suggestion

• examples/replay_consistency_demo/replay_consistency_demo.py:685：main() 用 asyncio.gather 并发跑 4 个 scenario，但每个 scenario 内部对各自的 SQLite :memory: 引擎独立、无共享状态，并发仅增加复杂度而无收益，且异常排查更难。可按顺序执行以保持输出顺序与报错栈清晰。

总结

存在两处必须修复的 Critical：_ALL_CASES 未定义导致聚合报告测试必崩，以及 case_11-14 的 mock 注入 handler 误用 Event(parts=...) 与 Event.parts 导致 4 个注入测试报错。修复后框架才能正常跑通；另建议清理已提交的过时 diff 报告 JSON。

测试建议

• 修复 Critical 后，新增针对 _handle_inject_mock_* 的单元测试：构造一个含 content.parts 的事件，验证 network_failure/partial_write/semantic_deviation 能正确修改目标 part 文本并经 update_session 回写后仍可见，避免再次回归到 Event.parts 这类属性误用。

[CongkeChen]

引用未定义的 _ALL_CASES

test_generate_aggregated_diff_report 断言使用了从未定义的 _ALL_CASES，运行即抛 NameError，聚合报告测试必然失败。改用 len(list_replay_cases()) 或显式定义 _ALL_CASES。

[helloopenworld]

AI Code Review

确认 — report.passed 在 1183 行被重新赋值，但从未进行断言（asserted）。该测试仅检查 critical_inconsistencies == 0，因此任何非关键的不一致项都会被静默容忍。这是一个测试有效性方面的漏洞。

现在我已经掌握了所有信息。让我来撰写最终的审查意见。

发现的问题

⚠️ Warning

• tests/sessions/conftest.py:371-372 与 tests/sessions/conftest.py:394-395：full_backend_pair / full_backend_pair_with_summary fixture 未关闭 InMemoryMemoryService

  • 两个 fixture 都以 MemoryServiceConfig(enabled=True) 构造 InMemoryMemoryService，其 __init__ 会启动后台清理任务，但 teardown 只 close() 了 session service，没有 await mem.close()。会导致 pytest-asyncio 报 "Task was destroyed but it is pending" / 事件循环泄漏告警，建议在 teardown 中补 await inmem_memory.close() 与 await sqlite_memory.close()。

• tests/sessions/conftest.py:73-74：ReplayStep.expected / expected_events 字段被加载但全程未被校验

  • JSONL 中大量写入 "expected": {"events_count": ...} 和 "expected_events": N（如 case_07_summary_truncate.jsonl 的 expected_events: 0，压缩后实际仍有事件），但 ReplayHarness 从不读取这两个字段。意味着这些期望形同虚设，错误的期望值（如 expected_events: 0）无法被发现。建议在 get_session handler 中对 step.expected_events / step.expected 做断言，否则应删除字段避免误导。

• examples/replay_consistency_demo/.env.example:7：声称 .env 已在 .gitignore 中，但实际并未忽略

  • 该文件注释写明 "The .env file is already in .gitignore"，而仓库 .gitignore 只包含 .venv/venv，无 .env 条目。开发者按示例创建 .env（含 DEEPSEEK_API_KEY）后存在被提交泄露凭证的风险，建议在 .gitignore 中补充 .env。

• tests/sessions/test_replay_consistency.py:1183：case_07 测试重置 report.passed 后未断言

  • test_replay_summary_truncation 在 Layer-1 比较后执行 report.passed = len(report.inconsistencies) == 0，但之后只断言 critical_inconsistencies == 0，从未断言 report.passed。任何非 events[/events. 开头以外路径... 实际上所有非 critical 的 inconsistency 都被静默容忍，测试无法反映整体一致性结论。建议补 assert report.passed, ... 或明确仅校验 critical 项的意图。

💡 Suggestion

• tests/sessions/test_replay_consistency.py:321-325：_handle_store_memory 忽略了 case 提供的 save_key / session_id kwargs，直接用 session.save_key 存储。当前 case_05 的 kwargs 恰好与 user_key(app_name, user_id) 推导值一致才工作；若 kwargs 与推导值不一致，搜索会静默返回空而测试仍可能通过。建议显式校验或使用 kwargs 中的 key，避免脆弱耦合。

总结

整体为一套新增的回放一致性测试框架与示例，逻辑设计合理、注入用例可被检测。未发现 Critical 阻塞问题；主要风险集中在 fixture 未释放内存服务后台任务、expected* 字段形同虚设、.env 未真正忽略，以及 case_07 测试结论未被断言——建议在合入前修复上述 Warning。

测试建议

• 补充断言：在 get_session handler 中校验 step.expected_events 与实际事件数，覆盖 case_07 压缩后事件数与 expected_events: 0 不符的路径，验证框架能否捕获错误期望。
• 补充一个验证 fixture teardown 不遗留后台任务的测试（或开启 pytest 的严格事件循环泄漏检查），确认 InMemoryMemoryService 被正确关闭。

[Stelquis]

这里是否可以在不修改框架源码的前提下，编写一个真正运行的例子，包含tool调用，采用真实模型跑一下，采用mock的方式或者其他的方式构造一下异常情况，看看是否通过你的这个test检查出来，该issue最终的目的是可以检查真实场景下的异常，避免代码修改过程中引入比较难发现的bug，记忆细微的出错，可能导致整个语义产生偏差。

@raychen911 感谢老师建议！在未修改框架底层源码的前提下，补充了可直接运行的端到端示例、基于 DeepSeek 的 Tool Call 链路，同时新增 4 类 Mock 异常注入用例，覆盖超时、网络截断、半写入失败、记忆语义细微篡改场景，均可通过回放差异检测捕获问题，详情如下：

端到端运行示例

文件：examples/replay_consistency_demo/replay_consistency_demo.py

# 基本模式（无需 API Key）
python replay_consistency_demo.py

# 真实模型模式（采用 DEEPSEEK_API_KEY）
export DEEPSEEK_API_KEY="sk-xxx"
python replay_consistency_demo.py --real-model

场景 1~4：模拟数据 + 异常检测（无需 API Key）

场景	做法	预期	结果
Normal	两端写入相同事件	无差异，通过	✅
Event order mismatch	SQLite 端交换事件 2 和 3 的顺序	检出 4 条 diff	✅
Text tampering	SQLite 端篡改金额文本	检出字段级差异	✅
Missing event	SQLite 端少写一条事件	检出事件数不一致	✅

场景 5：真实模型 + Tool Calling（需 DeepSeek API Key）

基于 DeepSeek v4 Flash，使用 OpenAI SDK 直接对接（遵循官方 tools 格式），走通完整工具调用流程：

User:  How's the weather in Tokyo?
Model: → get_weather({"city": "东京"})    ← 模型自主调用工具
Tool:  → 22°C, Sunny                    ← 执行工具，返回结果
Model: → 东京的天气目前是 22°C，晴天 ☀️   ← 模型生成最终回答

关键设计决策：

• 使用 OpenAI SDK 直接对接 DeepSeek，而非框架内部的 tools_dict 转换路径，确保 tool calling 真实可用
• 工具执行结果通过 tool_call_id 回传给模型，模型基于工具结果生成最终回答
• 所有事件（user/tool_call/tool_response/assistant）同时写入 InMemory 和 SQLite 后端，验证跨后端一致性

Mock 注入用例

文件：tests/sessions/replay_cases/case_11~14.jsonl

通过 inject_ handler 在 replay harness 层面实现，不侵入后端服务源码：

case_11：LLM 超时模拟

模拟场景：模型调用卡住，超时后在 session 中追加一条超时标记事件
注入方式：inject_mock_llm_timeout handler 在 B 端追加一条 system 事件
检出方式：A 端 4 个事件，B 端 5 个事件 → 事件数不一致

case_12：网络故障模拟

模拟场景：写入过程中网络中断，消息内容被截断
注入方式：inject_mock_network_failure handler 替换 B 端事件文本为错误信息
检出方式：DiffEngine 字段级比较 → events[i].parts[j].text 不一致

case_13：部分写入失败模拟

模拟场景：数据只写了一半，后半截内容丢失
注入方式：inject_mock_partial_write handler 截断 B 端事件文本
检出方式：DiffEngine 字段级比较 → events[i].parts[j].text 不一致

case_14：记忆语义偏差模拟（核心场景）

模拟场景：事件顺序正确，但内容被微妙篡改（金额 $1,500 → $15,000）
注入方式：inject_mock_semantic_deviation handler 替换 B 端事件中的金额数字
检出方式：DiffEngine 字段级比较 → events[i].parts[j].text 不一致
意义：验证框架能捕捉"记忆细微出错"——不改变事件结构，只改变语义内容