lzf_0626
d7f6ef7ddc
一、自动触发 在记忆抽取 worker 里，记忆写入成功后**写一条 profile.rebuild_requested 事件**，由 Worker 的事件循环在下一轮消费，完成画像重建与图投影。 为什么不直接在抽取处调用：抽取时那条记忆还在**未提交**的事务里，另开 session 去重建画像 看不到它——实测踩到过：画像重建确实执行了、快照也多了一条，但新事实没进 user_facts、 画像字段没更新、图里也没多出关系。改走事件后，它只可能在本事务提交之后被消费，届时数据 一定可见，且与记忆写入共享事务边界（要么都留痕、要么都不留）。 链路因此变成：客户说话 → 记忆抽取 → 画像更新 → 图投影，全程无需手工介入。 runtime 侧新增 dispatch_profile_rebuild handler 与 relationships 注入点（与既有 projection_cleaner 同一模式）；未注入或图库不可用时投影如实降级，不影响画像更新。 二、顺带修复：记忆内容变化会导致整条更新失败 实测触发：同一 memory_key 的内容从"约三年"改成"长期（5年以上）"时， INSERT INTO memory_conflict 报 `1264 Out of range for column 'right_memory_id'`。 根因：memory_service._conflict_right_id 在"同一行原地更新、没有独立新值行"时返回 `-memory.id` 作为合成标识（注释写明了意图是与恒为正的自增主键不冲突），但库中 right_memory_id 是 `BIGINT UNSIGNED NOT NULL`，写负数被 MySQL 直接拒绝。 后果不是丢一条冲突记录，而是**记忆内容一旦变化、整条更新就失败**， Worker 反复重试直至事件进入死信。 因基线字段不可变更（AGENTS.md 第 4 条禁止改动已有字段的类型），改为在无符号范围内的 高位取值 `2**63 + memory.id`：真实自增主键从 1 开始且远小于 2^63，因此该值必为正、 且必然不等于任何真实记忆行主键，原设计"左右不相等且不混淆"的意图完整保留。 三、实测结果（全程未运行任何手工脚本） 客户两条消息（"投资期限约三年" → 改口"长期，五年以上"）之后： · memory_unit 2 行，horizon 记忆 version=2、conflict_count=1； · memory_conflict 1 行，合成标识 9223372036854776037（= 2^63+229）合法写入； · user_facts 2 行（事实自动提升，置信 0.95 过门槛）； · fin_customer_profile.investment_horizon 自动更新为"长期（5年以上）"； · profile_snapshots 4 个版本； · Neo4j 自动出现 HAS_GOAL 关系；profile.rebuild_requested 事件为 published； · ruff 通过、mypy 112 文件无错。