lzf_0626
3a1065ca1e
修复片段链路：重复聚合拖垮重试预算 + 从不投画像重建事件
## 结论先说：真正的根因和最初两个假设都不是同一个
你原来的判断是「第二条召回恒空、第三条传导断链」，并猜第三条是
「`record_evidence` 返回 False 时该不该补写重建事件」。查完库发现：
1. **`record_evidence` 返回 False 时数据零净变化**（幂等命中直接 return；
并发冲突把刚加的计数减回来），所以那个判断点解释不了画像停更；
2. **`memory_extraction_worker` 是有写重建事件的**（`if recorded:`），
233 条 `profile.rebuild_requested` 全 published；
3. 真正断在两处，都在 **`episode_worker`** 这条片段链路上。
## 根因一：`_touch_retry` 把「重复聚合」记成「抽取失败」（P0，已修）
`episode_worker._persist` 在 `content_hash` 命中（同一段会话被重复聚合）时调
`_touch_retry` 做 `retry_count += 1`。但 `retry_count` 的语义是**抽取失败次数**
（由 `_mark_failed` 累加），而"分片逻辑每轮重新看到同一段会话"根本不是失败。
后果是实测出来的：
episodes 待提取片段：retry_count=1405（40 条，全是客户 9001）
consume_pending 逐条件筛：
仅 status in (待提取,失败) -> 40
+ retry_count < max_retry(3) -> 0 ← 一个都不剩
+ promoted_to_ltm IS FALSE -> 40
这 40 条片段**永远不可能被选中** ⇒ 新记忆进不来 ⇒ 画像停在旧值。
（另外还观察到一次运行里它从 1405 涨到 1407 —— 常驻 Worker 每轮都在继续推高。）
**修法**：重复聚合不再触碰 `retry_count`，连 `flush` 都不做（内容没变就只是看到）。
## 根因二：片段链路从不投「画像重建」事件（已修）
`memory_extraction_worker` 写完证据会投 `profile.rebuild_requested`；
而 `episode_worker` 写完证据直接 `_mark_done` 就结束了 —— **完全没有这一步**。
所以即使片段被成功抽取，画像也不会重建。
**修法**：`episode_worker` 也捕获 `recorded` 并在为真时投同样的事件
（`trigger="episode_extraction"`）。只在 `recorded=True` 时投：幂等命中时证据与计数
都没有净变化，投一次是白跑。
## 数据修复
代码修好不会让已写进库的脏计数自己恢复 —— 那 40 条片段仍然超预算。
用 `tools` 级别的临时脚本把**确实被污染的行**重置（条件收紧为三者交集）：
extraction_status IN ('待提取','失败') AND promoted_to_ltm = 0 AND retry_count >= 3
-> 重置 40 行；之后可被 consume_pending 选中的片段从 0 恢复到 40
## 实测
- **重试预算修复**：`consume_episodes` 从"领不到任何片段"变为能领到；
分两批消费完 40 条（全部 `no_fact` —— 那些片段摘要里确实没有用户陈述，
属正常结果），待提取 40 → 0
- **重建事件修复**：那 40 条全是 `no_fact`，走不到 `if recorded:`，所以**
实测不到**。为不留下"改了但没验证"，另造了一条含用户陈述的片段：
consume_episodes -> extracted=[191]
9001 的 rebuild 事件 3 -> 4（增量 1）
memory_evidence 8 -> 9
另外注意到基线在我造数据前已经由 1 涨到 3 —— 说明常驻 Worker 也在这期间
投过事件，修复在真实链路里同样生效。
- `pytest tests/unit tests/contract` -> 1428 passed / 2 skipped / 1 failed
（剩下的 1 个是投顾工作台页面被替换所致，与本次无关）
## 测试
两个既有用例断言的正是被修掉的旧行为，已更新，并把第二个改造成**防回归守卫**
`test_repeated_aggregation_never_bumps_retry_count` —— 它守着
"`retry_count` 被重复聚合推高到 `max_retry` 之上会导致片段永久滞留"这个 P0。
`tests/unit/worker/test_episode_worker.py` 16 passed。
## 未处理
「召回恒空」（员工身份下 `recall` 取的是自己作为客户的记忆）**本次没动**。
它需要给 `AgentRequest` 加 `target_customer_id` 并配套越权校验，属接口契约变更；
排查报告给的建议是保持现状、员工侧走 `query_customer_profile` 工具。
要按"支持目标客户维度"做，请确认，我再单独一提交。
2026-09-14 21:09:03 +08:00
..
2026-09-14 20:35:46 +08:00
2026-09-14 18:24:24 +08:00
2026-09-14 00:30:06 +08:00
2026-09-14 00:30:06 +08:00
2026-09-13 23:51:45 +08:00
2026-09-14 20:35:46 +08:00
2026-09-14 18:24:24 +08:00
2026-09-14 21:09:03 +08:00
2026-09-09 21:55:37 +08:00
2026-09-13 15:56:54 +08:00