2 Commits

Author	SHA1	Message	Date
JianFeeeee	dae01f9c06	refactor(memory): 移除 media_refs/引用计数，媒体成为一等记忆块 ... 媒体此前是"文本块 + digest 引用 + owner 账本 + 独立 GC"：ContextEvent.Media 记 digest，media_refs 表用 owner_kind/owner_id 保活，ref_count 决定 GC 能否清。 这与文本记忆块的管理方式不一致，也是本次一并纠正的核心偏差。 改为与文本块完全一致的生命周期： 1. 一等记忆块直接由所在层持有 - ContextEvent.Blocks / Doc.Blocks / GraphDB memory_blocks - 块带 modality/digest/MIME/size/vector/fingerprint，文本、图片、视频同构 - Context→Document→Graph 迁移的是块本身（ID 不变），迁移后清空源容器， 同一块不同时存在于两层 2. 删除平行生命周期账本 - media.Store 去掉 media_refs 表、OwnerKind 常量、RefCount 字段、 AddRef/DropRef/DropOwner/Refs、ref_count 列与索引 - 删除 mediaGCLoop、GC(keep,minAge)、容量上限与 media.gc_* / media.max_mb 配置 - 媒体内容在块被永久删除时一并删除（media.Store.Delete + forgetPayloads）， 与"删除文本块即删除内容"同一语义 3. L3 原生结构 - memory_blocks / memory_block_edges（contains/depicts/derived_from） - 边端点必须是真实图节点，不再用 owner 字符串伪装关系 - BlocksForNode 支持 sentence --contains--> block 反查 4. SDK 与检索同步 - 插件附件/标记直接变成块，不再 AddRef - 跨模态检索改用 QueryMediaScored（CAS 内不再有孤儿缓存需要过滤） 测试全部改写为块语义：删除 refcount/media_refs/GC 断言，新增块迁移、 单层不变量、Delete 语义与并发删除回归。 注：cmd/homed/main.go 同时携带工作区中既有的 CLIP→Qwen 模型目录接线改动。	2026-09-11 10:57:22 +08:00
JianFeeeee	f855893d1c	feat(memory): 媒体接入 L0/L2——digest 挂到对话事件，归档时引用随之转移 ... 在 a822674 的 CAS 层之上把媒体真正接进记忆链路。此前 CAS 只是个孤立的 存储包，没有任何写入方。 ## 媒体进入对话有两条路，两条都只把文字留给记忆 1. 用户直接发图 → processMediaInput → mediaToBlocks ContextEvent.Input 只存 alt 文本（"[从 qq 收到了 image]"）， base64 随 message 数组发给模型后就丢了。 2. 插件注入 → SetToolBlocks → process.go 的 mediaMsg ToolResultItem.Output 只存那句 "[已将图片注入后续对话] /tmp/x.png"。 于是下一轮起，模型能看到的只剩一句路径或一句 alt。那个文件被删、被覆盖， 或者本来就是 /tmp 下的临时产物，连线索都断了。 现在两条路在同一处收口（captureBlockMedia）：从 ContentBlock 的 data URL 取出字节存进 CAS，digest 挂到当轮 ContextEvent。 ## 改动 internal/agent/core/mediaref.go（新） - captureBlockMedia：ContentBlock → CAS。只处理 data URL——http(s) URL 拿不到字节就无法内容寻址，而「下载它再存」会把一次对话变成一次网络 请求（超时、鉴权、SSRF 全来了），不在本层解决。 - stage/drainMediaDigests：媒体在 process() 期间被捕获，而承载它的 ContextEvent 要等 process() 返回后才 Append——此刻还没有 owner_id， 故先缓存。与既有 pendingMedia 同一手法，同受 a.mu 保护。 - bindEventMedia：双向落地。evt.Media 让事件记得引了什么（随 context.json 持久化），media_refs 让 CAS 知道谁在引用（GC 的判断依据）。 只写一边的话，要么 GC 误删仍被引用的内容，要么孤儿永远清不掉。 - mediaSummaryForEvent：把已有描述拼成一行写进 Input。这是方案 C 的 落点——**描述文本才是持久语义记忆，blob 只是缓存**。blob 可能被容量 GC 淘汰，但描述会一直留在 L0/L2/L3 的文本里，让「那张紫蓝红三色带图」 几个月后仍可被检索。 ContextEvent 新增 ID 与 Media 两个字段，都是 omitempty： - ID 懒生成，只有真要挂媒体时才赋值。绝大多数对话没有媒体，全量生成 会让每条事件都多一个字段进 context.json。 - 存量 context.json 读回来两字段皆空，不影响任何既有行为（有测试）。 RelevanceContext.Prune 归档时转移引用（transferMediaRefs）： **先挂到归档文档、再注销原事件引用**。顺序不能反——先销后挂会让引用 计数瞬时归零，若此刻后台 GC 正在跑就会把仍被记忆引用的内容当孤儿清掉。 为此把 Prune 内的局部类型 scored 提为包级 scoredEvent（局部类型无法 出现在方法签名上）。 media 包新增 OwnerContext/OwnerDocument/OwnerGraphSentence 常量： owner_kind 进了主键，拼错一个字符就是一条永远对不上的孤立引用—— AddRef 不报错，DropOwner 也永远匹配不到。 ## 配置 core.memory.media.enabled（默认 true）、.dir、.max_mb（2048）、 .gc_interval（6h）、.gc_min_age（1h）。 关闭后全链路静默跳过，对话行为与本特性上线前完全一致（有测试）。 mediaStore 为 nil 时同理——它是记忆增强，不是对话必需品，开不起来 只记一条 warning 不阻止启动。 ## 测试（11 例） 入库与 MIME 归类、http URL 跳过、nil store 全链路 no-op、音视频混合、 stage/drain 清空语义、懒生成 ID、描述作为持久记忆、**归档转移期间内容 始终可读且 refcount 不归零**、无媒体存储时归档照常、context.json 向后兼容往返。 全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。 ## 尚未接入 L3 图库的 graph_sentence owner（常量已备好，无写入方）、 描述生成的后台任务（Pending() 已就绪，尚无消费者）、 媒体 GC 的定时触发（配置项已注册，尚未接 ticker）。	2026-09-04 20:53:32 +08:00