OpenViking ↔ negentropy 机制映射报告

声明：只分析不改码；锚点均经 grep -n 实测（工作区 HEAD a924fadd；ng/ = apps/negentropy/src/negentropy/）。材料侧证据见 014 精读笔记，上游钉点 volcengine/OpenViking@14a7b812（2026-09-23，AGPL-3.0）。

#结论先行

1. 对齐面比预想宽，只是形态不同：OpenViking 用「路径 + sidecar 文件」表达的能力，本仓大多已有等价物，只是做成「Postgres 表 + JSONB 元数据」——去重合并、审计、幂等、检索轨迹、九类记忆都能找到落点。13 条映射中 ✅4 / 🔶5 / ⏸4。
2. 最大真增量在 M-d（会话两阶段提交），不在 M-a（统一 URI）：本仓交互式对话的「会话 → 长期记忆」链路零触发方——add_session_to_memory 无任何调用方（含 ADK Runner 与 UI/BFF，本次已逐一核验），consolidation_jobs 只入队、无消费者。OpenViking 的「同步归档 + 异步提炼 + .done 水位」正好对准这个断点，且本仓 title_inspector 已有可复用的水位范式。
3. M-a 不宜照搬：viking:// 背后是副本式文件系统（AGFS），与 013 蓝图 ADR-1「目录只 UNION 指针、不复制数据」正面冲突。可借鉴的只是寻址格式，不是存储形态。
4. 取证顺带发现 8 处本仓漂移/缺陷（§5），其中 D2（断链）、D3（force_refresh 被 TypeError 静默吞掉）、D6（_fetch_memory 不校验用户，ISSUE-194 方案落地前的必须前置修复）优先级最高。
5. 许可证约束：上游 2026-03-30（ce998873，v0.2.15 起）由 Apache-2.0 改为 AGPL-3.0（crates/ov_cli、crates/ragfs、examples/ 仍为 Apache-2.0）。本仓 Apache-2.0：不得 vendoring/改写其主体代码；以独立进程网络调用（若引入）不触发 AGPL 传染，但任何「改造后对外提供网络服务」的场景都需法务评估。

#映射总表

#逐条说明（判定理由与建议）

#1 ⏸ 统一 URI：viking:// 是「把一切导入自有 AGFS」的副本式设计；013 §5.3 ADR-1 明确拒绝该形态（新表=副本=Split-Brain 引信）。触发条件：013 三视图/context_catalog_unified 落地时，把 {item_type}:{uuid} 定为统一指针格式——只取其寻址语法（scope 语义、确定性 ID），不取其存储。 #2 🔶 分层披露：本仓已有四种两级形态但无「每节点 sidecar」。值得做的只是新鲜度子集（#3）；逐目录 sidecar 与本仓「目录=人工 Wiki 组织」的现状不匹配，且 Skills L2/L3 实际不可达（ISSUE-194），先修激活层再谈分层。 #3 🔶 新鲜度：get_or_generate_summary 的 24h TTL 不感知源数据变化；且 SummarizeStep 传入的 force_refresh 因签名不符抛 TypeError 被降级吞掉（D3）——绑定 #7 同批：#7 落地后 summarize step 每次巩固真实执行，TTL 失真随即暴露；修法是把 TTL 换成「源水位差」判据，范式直接复用 title_inspector.py:191。 #4 ⏸ typed query：拆分收益取决于「多源统一检索」先存在。触发：013 §8.5 ADR-2（HybridPlanner 接 Memory 第 4 路种子）落地后，把 intent 升级为「按源 typed sub-query」。OpenViking 自己的教训（014 §4.1：priority/intent 字段不参与排序、无会话即不触发）说明这条机制的实际收益并未被验证，不必抢跑。 #5 ⏸ 目录递归：需要一棵「语义化的深层目录树」。本仓记忆扁平、KB 目录是人工组织、navigation 意图只返回 corpus 列表——现在引入递归等于先造树再检索，YAGNI。触发：检索评测出现「建错目录/选错 corpus」类失败占比显著，或 catalog 深度 ≥3 且 Agent 需要按目录浏览。OpenViking 的两条实测教训（014 §4.2：默认部署不触发递归；α=1.0 后层级只影响可达性不影响排序）是引入前必读的反例。 #6 ✅ 同步归档：events.sequence_num 全局序 + append_event 同步落库，与 Phase 1「归档是事实」等价。 #7 🔶 会话→记忆触发（本报告最高优先）：断链修复而非新特性。最小方案：① 复用 inspector 范式选「事件水位差 ≥Δ 且空闲 ≥T」的会话；② 入队 consolidation_jobs（表与部分索引已存在，迁移 0043/0044）；③ 消费者 FOR UPDATE SKIP LOCKED 取任务执行 _simple_consolidate，成功推进水位。零新表。二阶风险：每会话新增一次 embedding + LLM 提取（用 Δ、T 封顶）；单 uvicorn worker 下消费者必须是异步限流后台任务；巩固后 preload 检索到更多 episodic 行，需观察 memory_retrieval_logs 噪声率。 #8 ✅/⏸ 去重合并：主干等价且更可审计（阈值可解释）。LLM 裁决档（OpenViking 的原子写集）只值得用于模糊带 cos 0.80–0.90。触发：模糊带误合并/漏合并被 retrieval 反馈证实（outcome_feedback=irrelevant 聚集在 merged_from 行）。OpenViking 的反例（014 §5.3：topic 命名漂移即产生矛盾并存、跨会话单条新文件直通不查语义）说明 LLM 裁决不是银弹。 #9 🔶 巩固 diff 审计：消费者把本轮 {created_ids, merged:[{loser, primary}], superseded_facts, steps:[StepResult]} 写入已有的 consolidation_jobs.result JSONB（ng/models/internalization.py:323），不新建表；人工审计继续走 memory_audit_logs，两者正交。注意 OpenViking 的教训：memory_diff 只写不读等同摆设——审计必须接一个消费方（UI /memory/audit 展示即可）。 #10 🔶 幂等水位：threads.metadata 增加 consolidated_at_event_seq，同构 title_generated_at_event_seq。OpenViking 的两条细则值得抄：水位只记「到哪了」不记「做了什么」（重跑靠内容去重兜底）；.done 最后写（提交点语义）。 #11 ✅ / #12 ✅ / #13 ⏸：类型学覆盖完整（trajectories 以日志形态存在是本仓的合理取舍）；检索轨迹分通道已比 OpenViking 落地更实（它的 ThinkingTrace 无生产者，014 §4.5）；经验进化闭环已按 Reflexion 方式成立，触发：ISSUE-194 修复后若 skill_template proposer 长期无证据不提案，再把同 skill 相关的 procedural 失败教训接为证据源。

#013 蓝图五层对位（回写建议）

#落地建议汇总

• 做（绑定 #7 一批，建议独立 PR，先于 013 Phase 1）：① 会话巩固触发器 + consolidation_jobs 消费者 + 水位（#7/#10）；② 巩固 diff 写 result 并接 UI（#9）；③ 修 D3 force_refresh 签名并改源水位判据（#3）。
• 写（一句话成本）：④ 013 §12.7 #9 状态行校正 + §8.5 宿主更正（D1/D7）；⑤ 本报告登记进 issue.md（D2/D3/D6）。
• 暂缓（写明触发条件）：#1（013 三视图落地时）、#4（ADR-2 统一检索后）、#5（目录深度 ≥3 且评测出现选错目录类失败）、#8-LLM 档（模糊带误判被反馈证实）、#13（ISSUE-194 修复后 proposer 仍无证据）。

#取证副产物：本仓漂移与风险清单

#交叉引用

• OpenViking 精读笔记（机制载荷与证据分级）· Context Layer 蓝图（五层 SSOT）· Horizon ↔ negentropy 映射（同为「材料机制 ↔ 本仓」先例）
• ISSUE-194（expand_skill 未挂载）见 issue.md；本报告 D1–D8 已按精读流程登记为 ISSUE-195。