|
|
758ec11832
|
fix(memory): 图整备覆盖 scenes + 证据桶按桶清（R3/R5）
R3：图整理心跳只查 entities/relations，scenes 完全没有整备路径。
Recall(nil,nil,1,"") 的全量路径只 SELECT 这两张表
（graph.go:609/631），于是同一场面的双胞胎键从建库起无人发现：
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs，
孪生的 auto:chan:qq_part:morning 持有 210 refs 却 0 features
（聚类只读 scene_features，所以它永远不被看见）。
新增 GraphDB.DedupeScenes：归一化后同名的场景合成一个——强度相加、
特征取并集（权重取大）、引用全部重定向，存活者保留 id 最小行，
跨 origin 也合。接到 mergeLoop 尾部。
为什么不塞进 detectEntityMerge 的双重循环：
- 实体是全库两两 bigram + LLM 裁决（1 万实体实测 5000 万次配对、
~224GB 瞬时分配每轮，是独立问题）；
- 场景的判重口径是**归一化后是否同名**——同名即同一场面，键相同
本身就是证据，不需要 LLM 裁决。而「像不像」是 EnterScene 聚类的
职责，不是这里的事。
只做同键合并、不做相似度合并：把 chan:qq 与 chan:webui 合并是危险
的，去重不是「把像的一律合并」。
生产库副本实测（sqlite3 备份式复制到 /tmp，未碰生产）：
65 个场景 → 合并 8 组 → 57 个；
auto:chan:qq_part:morning 的 refs/rel/ent 一条没丢，strength 1 → 272。
R5：createSceneLocked 新场景成立时执行的是
`DELETE FROM situation_evidence`（全表清），而证据表是多通道共用的
计数桶。后果不是「多清一点」：qq 的场景一长出来，就把 mc/webui/cli
尚未攒够 minSceneEvidence=2 的证据抹掉，它们的计数被反复清零，
于是**永远**攒不到 2 次。判据实测：6 个通道各来 3 次，只长出 2 个场景。
改为 `DELETE ... WHERE label = ?`，只清本指纹那个桶。
判据：scene_dedupe_test.go 8 例（含「不同场面不得被合并」与幂等）、
scene_evidence_test.go 3 例。均先红后绿。修 R5 时差点栽：桶键是
sig.Label(2) 本身、不带 auto: 前缀（base 才是带前缀的场景键），
第一版删错对象会「一条没删却看起来通过」，用探针实测真实桶键后改正。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
|
2026-09-26 20:16:11 +08:00 |
|
|
|
1fa9ef68a4
|
fix(memory): 场景键归一化 + 排除最弱维度，修双胞胎与空转
现网实测：scenes 表 65 行里有 6 组是同一场面的双胞胎键，最严重的
auto:chan:qq+part:morning 累积到 strength=270、6 个 features、
0 条记忆，日志里被"命中"179 次；孪生的 auto:chan:qq_part:morning
则持有 201 条记忆却有 0 个 features（不参与聚类）。两套特征体系
各活各的，谁也发现不了谁。
病因：键构造不唯一。
- Label() 直接用 "+" 拼接且不过 NormalizeSceneKey，而
EnsureScene / effectiveScenes / RecallByScene 三处都过了归一化。
"+" 会被 normalizeSceneSegment 归一成 "_"，于是两个字符串都合法，
key UNIQUE 约束拦不住。
- Label(2) 会把权重仅 0.2 的 part（时段）挤进场景身份。实测
morning 场景吞掉 evening 指纹：共享 chan:qq 权重 1.0、并集含
part 0.2×2，相似度 1.0/1.4 = 0.714 > joinSceneThreshold 0.5。
这本就是加权 Jaccard 的正常行为，但键名不该写进时段。
- createSceneLocked 的 "#N" 冲突后缀同样会被归一成 "_"，
造成 auto:chan:mc:event+topic:mc#2 在库、而写侧归一化后去找
auto:chan:mc:event_topic:mc_2 —— 又一对匹配不上的双胞胎。
修法：
- Label 只取权重 ≥ 0.5 的主导特征，结果过 NormalizeSceneKey；
全部特征都弱于门槛时退回最强的一批（宁可名字信息量低，也不能
没有名字 —— 没名字就没有键，场景根本长不出来）。
- createSceneLocked 对 base 再做一次防御性归一化，并在 label 为空
时拒建无名场景。
- 冲突后缀由 "#" 改为 "."（'#' 会被归一化，'.' 是白名单字符）。
判据：新增 scene_key_test.go 6 例，参照物在生产代码之外（"同一场面
⇒ 同一个键"这条不变量 + 直查 scenes 表复算行数）。先跑红确认判据
在跑（4 红 1 绿，失败的正是键唯一性/时段污染/证据桶），再改实现。
其中 TestWrittenRefReachableFromItsScene 一开始就是绿的——写侧到读侧
那条路本身是通的，坏的只是键的构造。
记忆 8 包 + agent/core 全绿。
|
2026-09-26 19:56:28 +08:00 |
|
|
|
acc94723fd
|
fix(memory): 打通场景/索引/召回残余矛盾点，清理死代码与冗余索引
- DecaySceneRefs 真半衰期：新增 scene_refs.decayed_at 作计时起点，
每个引用至多每 halfLife 衰减一次。此前只按 created_at 判龄 + 每次
心跳对半砍，30 天阈值配 60 分钟心跳会在几小时内清空老关联（不是半
衰期是骤死）；时间基准改走 SQLite datetime('now')，不再与 Go 本地
时间混用。
- Indexer.syncIfStale 基线口径与 Sync 对齐（min(实体数, 全量召回上限)）：
实体数超过上限时原实现永远不相等，每 retrainInterval 全量重训一次。
- EnsureScene 去掉从不使用的 Situation 参数；修正 EnterSceneWithHint /
resolveTurnScenes / 测试里「声明场景会学整轮指纹」的过时注释（实际
刻意不学，否则会吃死被动路）。
- SituationFeature.Weight 补 peer_group → wFeatPeer：此前落到 default
话题级 0.4，群聊身份被降级成软信号。
- RecallBySituation 注释改为与实现一致（相似度只决定命中哪些场景，
不参与每条关系排序）。
- 移除只被测试使用的 EmergentScenes（SceneStats 已含 origin/strength/
features，完全覆盖）。
- 清理与 UNIQUE 隐含索引重复的 idx_entity_name / idx_sentences_text。
- 新增 TestSyncIfStaleBaseline / TestPeerGroupWeight，衰减测试补「同一
半衰期内不重复衰减」用例。
go build/vet 干净，internal/... 全绿。
|
2026-09-15 10:20:40 +08:00 |
|
|
|
49695c38f3
|
feat(memory): 场景双通道——主动声明与被动涌现并存，且互不吞噬
按「声明式的也要支持，相当于主动被动两条路」落实。此前两者只是恰好并存，
没有边界，实测会互相吃掉（下面的坑就是）。
- Triple.Scenes []string（多值）：一轮写下的记忆**两条路都挂**。
只挂一条会丢东西——只挂声明则细粒度唤起丢失，只挂涌现则首次交互
（场景还没长出来）没有兜底。单值 Scene 保留兼容。
- TurnScene：Primary 用于写（优先涌现场景，首次退到声明场景兜底），
Keys 是两条路的并集，用于召回（声明+涌动的场景一起进 RecallByScene）。
- EnterSceneWithHint：主动路 EnsureScene（声明即建场景，不等第二次），
被动路 EnterScene（指纹聚类）。写侧由 executeToolCall 把本轮场景集合
传给 memory_commit，模型不需要知道"场景"这回事。
踩到并修掉的坑（两条路互相吞噬）：
最初让声明场景也吸收**整轮指纹**，于是 chan:qq 的相似度永远是 1.0，
把后续所有同类轮次全部吃掉 → 被动路再也长不出更细的场面，
实测 turn2.Emergent=true 但 Primary 仍是 chan:qq、没有 auto: 场景。
修法：给场景加 origin（declared/emergent）：
- 被动聚类只认 origin='emergent' 的场景（声明场景不进相似度空间）；
- 声明场景的特征**只从键自身解析**（chan:qq/peer:group_1 → {chan:qq, peer:group_1}），
白名单 kind（chan/peer/peer_group/tool/topic/part），不猜——
「老大2026-09-04_12:27_qq私聊图片」里的 12:27 也是 kind:value 形态，
放进特征空间就是往相似度里灌垃圾（有测试钉住）。
- 声明路的泛化靠**层级键前缀**（chan:qq 覆盖 chan:qq/peer:x），机制各归各。
- memgc -scene-stats 增加 [declared|emergent] 与 strength/features 两栏，
可直接观察两条路各自在长什么。
新增/改写用例：
- TestDeclaredAndEmergentBothLearn：首次交互兜底到声明场景 → 第 2 轮长出
细粒度涌现场景且**优先用于写入** → 声明场景不进相似度空间（防止压死被动路）
但仍走声明键取回 → 两条路都进召回集合 → 声明键特征解析与白名单。
- TestEffectiveScenes：多值+单值合并去重保序。
go build/vet 干净，go test -count=1 ./... 全绿。
|
2026-09-15 09:37:29 +08:00 |
|
|
|
d4f9a12db0
|
feat(memory): 场景从「声明」改为「涌现」——场面指纹自己长成场景
上一版场景是声明/派生的：调用方写 scene="chan:qq"，或由通道机械派生。
那不是涌现，是贴标签——标签谁定、怎么定全靠人。按「像人一样：干了什么事，
后续类似场面自动唤起对应记忆」的要求重做。
机制（全部取自运行时可观察量，无需模型配合、无需人工标注）：
- **场面指纹 Situation**：每轮采集 `chan:xx / peer:xx / peer_group:xx /
tool:xx / topic:xx / part:xx`。权重按种类：通道与对象最强（1.0），
工具次之（0.8），话题是软信号（0.4），时段最弱（0.2）。
- **归属判定用加权 Jaccard**（不是字符串相等）：共享特征权重和 / 并集权重和。
加权是必须的——`chan:qq` 与 `topic:排班` 的证据力差 2.5 倍，不加权会让
一次偶然的话题重合把两个不同场面并成一个。
- **涌现**：同类指纹重复到 minSceneEvidence=2 次才长出场景
（首次只登记 situation_evidence 足迹）。一次性的交互不是「场面」，
给它建场景会让库被一次性事件撑满、之后每次路过都召回一堆只发生过一次的事。
- **强化**：场景每次重现 strength+1、并入新特征。
- **唤起**：RecallBySituation 按**相似度**取回（阈值 0.35，比归属阈值 0.5 低
——想不起来是损失，多想起一条只是多几行上下文），与措辞无关。
- **遗忘**：DecaySceneRefs 按半衰期让久未重现的关联淡出，低于 floor 直接删；
已接进 archive 心跳（半衰期 30 天，比「这个月没做过这类事」更久）。
三个必须讲清的边界：
1. 一轮只解析一次场景（TaskFrame 缓存）——多解析一次就多记一次强度，
「工具调得多」会被误读成「这个场面更常出现」。
2. 声明与涌现**并存**：声明是「我知道这是哪个场面」（插件注入点最清楚），
涌现是「这轮看起来像哪个场面」。两者都进召回。
3. 记忆挂载全自动：memory_commit 没写 scene 时落到本轮涌现场景，
模型不需要知道场景这回事。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例（核心证据）：
- TestSceneEmergesFromRepetition：首次不建场景 → 第 2 次同类场面长出场景 →
同场面**不同话题**仍并入同一场景 → 换通道的场面自己长出独立场景（共 2 个）→
强度随重现增长、特征多条。全程没有任何人声明过场景键。
- TestSceneRecallsBySituationNotWording：场面里写下的规则，换措辞后仍被
自动唤起（含原句），无关场面不唤起。
- TestSceneRefDecay：一个半衰期权重减半、第二个半衰期低于 floor 被清掉，
仍在重现的场景不受影响。
- TestSituationFeaturesFor：指纹维度齐全、归一化、数值 group_id 转换、nil 安全。
|
2026-09-15 09:27:39 +08:00 |
|
