你把这套元数据结构拿出来给我看下

回复 群友 1942： 先说结论：我上次讲得太笼统了。翻完 Hy-Memory 的 README 和官方文档后，我发现官方并没有统一的内存条目 schema。这三类场景各有自己的数据结构，字段名可以直接从 SDK 里看到。 聊天记忆（chat）采用分层结构，共 8 层：L0 BASIC_INFO 基本信息、L1 RAW 原始对话且只追加、L2 FACT 原子事实且带版本、不可变、L3 SUMMARY 会话摘要、L6 SCHEMA 心智模型（图结构）、L7 INTENTION 前瞻意图且带过期时间，过期后降级成普通事实。召回时返回三条通道：profile、normal、proactive。 工作记忆（working）分为两层。Fact 层每条会话恰好生成一条，字段包括 statement、subject、files、details（原话），外加 superseded 可追溯和 fact_chain_summary。Experience 层每条会话 0 到 N 条，必须过价值阈值，字段是 task、search_keys、solution、boundary_envs（适用边界）、confidence。两层之间用 fact.derived_experience_ids 和 experience.source_fact_ids 互链。 代码记忆（coding）和工作记忆共用同一套 schema、同一个 pipeline，区别有三点：抽取规则按工程来，只记文件和函数的坐标，不贴代码；存储隔离在 coding_memory_cv.db；此外还有版本演化 diff 链，保存每次改动的真实 diff。 底层用的是 ChromaDB、Qdrant 或 FAISS 作为向量库，Kuzu 或 Neo4j 作为图库，工作记忆和代码记忆的元数据放在本地 SQLite，并不是纯 KV。另外，lite 模式完全不调用 LLM，把 scene 和 layers 都忽略，只做向量 RAG；pro 和 ultra 模式才会抽取和演化。 所以要修正我上次的说法：不存在一个统一的“记忆条目”结构，而是三个独立 schema，各管一个场景。