4 Commits

Author	SHA1	Message	Date
JianFeeeee	5836c2ce5c	refactor(memory): 拆除描述式媒体索引，媒体成为一等块并按原生向量融合 ... 背景：此前媒体是靠「生成的描述文本」将就进记忆的——写 marker 进正文、 再由正则反解成 media_refs 与图库里的 type=Media 实体。这条链路有三个 致命缺陷：描述由异步模型生成（未生成前媒体等于不存在）、语义检索实质上 只搜描述文字、图库里的「媒体节点」是描述文本的投影而不是媒体本身。 本提交把这条链路整体拆除，媒体改为按自己的原生向量参与记忆： 一、描述链彻底删除（无残留、无兼容分支） - media.Item 去掉 Description/DescribedBy 与对应列； - 删除 Store.Describe / Store.Search / Store.Pending； - 删除 Agent.mediaDescribeLoop / describePendingMedia 与配置项 core.memory.media.describe_on_ingest； - SDK 侧 MediaAttachment 去掉 Description（见 SDK 仓独立提交）。 二、marker 机制删除，媒体归属改为结构化块边 - 删除 mediaMarkerLine/parseMediaMarkers/mediaEntityName/mediaTriplesFromText/ extractMediaDigests/sentenceWithMediaMarkers/docMediaContext； - memory.Triple 新增 MediaDigests 结构化字段；句子文本保持原样， 不再被 marker 污染； - 块以 sentence --contains--> block / document --contains--> block 结构边 挂到承载节点（新增 documents 表与 document 节点种类）； - 模型未给原句时用「主谓宾。」拼一句自然语言作落点，不造 marker 文本。 三、旧数据迁移（幂等） - 新增 GraphDB.MigrateLegacyMediaEntities：把 type=Media 的旧实体按短 digest 还原成原生块、挂回原句子、删除旧实体与描述关系；Agent 启动时执行； - CleanupOrphanedSentences 同时看关系引用与块边，避免把只靠块存活的句子 连同块边一起删掉。 四、向量融合：媒体按图本身被召回 - 新增 vector.FuseVectors（逐维求和 + L2 归一化）； - Doc.DenseVec = 文本向量 ⊕ 文档块的媒体向量（同 fingerprint 才融合）， 新增 Doc.DenseFP，指纹变化触发重算； - ContextEvent.DenseVec 同理融合事件块；事件新增 DenseFP，Prune 只在 同一统一空间内比稠密余弦； - 跨模态视觉路只召回「仍被某层记忆块持有」的媒体，CAS 全库字节不再 直接充当记忆检索结果。 五、同时纳入本分支既有的嵌入基础改造（此前工作区未提交，缺它 HEAD 不可构建） - internal/tfidf 懒回退包、千问三段式多模态 ONNX 空间的 Go 侧 （qwen/embedder.go、image.go、model_input.go）、CLIP 移除、 sdk.NewStore 分词器签名与调用点、embed 侧车 systemd 单元。 验证：go build ./... 、go vet ./...（含 -tags medialive）均通过； 在 HEAD 的独立 worktree 上重放本次暂存集后 go test -short ./internal/... 全部通过（端口冲突类用例在隔离环境中亦通过）。未提交工作区中与本改造 无关的改动（HarmonyOS、waiter、devicebridge、plan.md 等）。	2026-09-11 11:45:24 +08:00
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	74a24f93d7	feat(memory): 媒体 GC 与描述生成两条后台循环 ... 补齐媒体记忆的最后两块：容量上限真正生效，描述文本成为持久语义记忆。 ## mediaGCLoop：让容量上限不再形同虚设 CAS 的 GC 只在被显式调用时执行，Put 路径不触发它。此前配置项 core.memory.media.max_mb 注册了却没有任何调用方——一次 see_video 抽 10 帧， 帧本身在工具结果被 Prune 后就没人引用了，若无人清理会一直堆在磁盘上。 现在按 gc_interval（默认 6h）周期调 GC(gc_min_age)。两个不变量： - 有引用的内容永不删除，即使超容量（宁可超限也不断引用） - gc_min_age（默认 1h）保护刚 Put 还没来得及 AddRef 的项——它们 refcount 也是 0 ## mediaDescribeLoop：描述才是能活过 GC 的那部分 blob 会被容量 GC 淘汰，而描述留在 media 表里，并经 mediaSummaryForEvent 写进 L0 事件、随归档进 L2 文档、经蒸馏进 L3 图库。于是「那张紫蓝红三色 带图」在原始字节早已被清掉之后仍然可被检索到。 复用既有的视觉回退链（resolveModalFallback + chatModalFallbackBatch）， 不新造一套模型调用。 三个刻意的决定： - **走后台而非入库时同步**：视觉模型一次调用生产实测 9.6s。放在对话 路径上会让每张图都给回复加十几秒，而描述的价值是几个月后还能检索到， 不是这一轮——这一轮模型本来就直接看着图。 - **逐条而非批量**：批量拿回来是一整段文字，无法可靠切分回各自的 digest（模型未必按序号输出，也可能把两张图合并成一句）。宁可多几次 往返也要保证「描述 ↔ digest」的对应关系确定。 - **默认关闭**（describe_on_ingest=false）：它消耗视觉模型配额。开启后 每 30s 最多处理 4 条，不跟对话抢额度。 失败处理分三类： - 网络抖动/配额 → 不标记，下轮重试 - 空回复 → 视作失败（上游剥离媒体时通常回空，与 modalfallback 同理） - 不可描述（kind=other、blob 已丢失）→ 标记 described_by=unsupported/ content-missing，退出队列 ## 顺带修掉 Pending 的一个真缺陷 测试写出来才发现：Pending 原先只看 `description = ''`，于是被标记为 described_by=unsupported 但 description 仍空的项**每轮都会被重新取出来 重试**，永久占着 LIMIT 的名额，真正需要描述的新项永远轮不到。 改为同时要求 described_by 也为空。 这是「先写断言再看它是否成立」抓到的——原本我以为标记一下就够了。 ## 测试 medialoop_test.go 7 例：两条循环在禁用时立即返回（nil store / 零间隔 / describe 关闭三种形态，不留空转 goroutine）、GC 清孤儿保留有引用项、 minAge 保护新项、无可用源时不误标记、不可描述大类被标记后退出队列。 media_test.go 补 1 例专测 Pending 的排除逻辑。 全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。	2026-09-04 22:00:03 +08:00
JianFeeeee	a82267484a	feat(memory): 内容寻址媒体存储（CAS）——图记忆支持二进制多媒体节点的底座 ... 此前四层记忆全是纯文本载体，没有任何一层能存二进制： L0 ContextEvent — Input/Response/ToolResults[].Output 全 string L1 text.Event — 同上 L2 document.Doc — Summary/Content/Tags 全 string L3 图库 — sentences.text TEXT UNIQUE，节点身份就是那串文本 于是 multimodal 插件注入的图只在本轮对话内可见（走 message 数组，不经 记忆），下一轮起只剩 ToolResultItem.Output 里那句 "[已将图片注入后续对话] /tmp/x.png"——一条路径字符串。那个文件被删或 被覆盖之后连线索都断了。 ## 为何内容寻址而不是存路径 - 路径会失效。/tmp 下的探针图、下载缓存、别的进程的临时产物，记忆里 留个路径等于留个悬空指针。 - 同一内容常被反复注入（连问几轮同一张截图、see_video 相邻帧高度相似）， 按 sha256 寻址天然去重。 - 内容即身份，与 L3 图库 sentences.text UNIQUE 思路一致：文本节点用文本 本身做身份，媒体节点用内容摘要做身份。 ## 结构 元数据（SQLite media.db）与内容（磁盘 blobs/ 两级前缀分桶）分离，不把 blob 塞进库：单张图动辄几 MB，塞进去让每次 VACUUM/备份都拖着几百 MB 走， WAL 也会迅速膨胀。 media(digest PK, kind, mime, size, width, height, origin_path, tool, description, described_by, ref_count, first_seen, last_seen) media_refs(digest, owner_kind, owner_id, created_at, PK 三列) digest 既是主键也是文件名，所以没有 Path 字段——路径由 digest 推导， 不落库（落了就又是个会失效的引用）。origin_path 仅供人类溯源，注释里 明确标注不可用于读取。owner_kind 预留 context/document/graph_sentence。 ## 几处刻意的决定 - Get 强制校验 digest：CAS 的全部保证建立在「文件名 == 内容摘要」上， 位翻转或外部误改必须被发现——把损坏的图喂给模型只会得到无从追溯的幻觉。 - 先写 .tmp 再 rename：中途崩溃不留半个 blob 被当成完整内容读走。 - AddRef 幂等：只有真插进 media_refs 才递增，否则计数虚高会让 GC 永远 不敢清。DropRef 用 MAX(0,...) 兜底防负数。 - Put 的空描述不冲掉已有描述（先到的可能来自更强的模型），但尺寸/工具名 这类前一次缺失的信息会被补写。Describe 是显式操作，允许覆盖。 - GC 两段 + minAge 保护：刚 Put 还没 AddRef 的项 refcount 也是 0，minAge 防「落地后还没挂上就被清掉」。有引用的项永不删除，即使超容量——宁可 超限也不断引用。 ## 测试 21 例，覆盖去重 / MIME 归类 / 损坏检测 / 无残留临时文件 / AddRef 幂等 / 计数不为负 / DropOwner / GC 保留有引用项 / minAge 保护 / 容量淘汰 / 描述覆盖与补写策略 / Search 按描述与 kind 过滤 / Pending / data URL 往返 / Stats / 跨重启持久化。 本 commit 只加存储层，尚未接入 L0/L2/L3 与描述生成。	2026-09-04 11:03:36 +08:00