ContextNest / ContextNext — Verifiable Context Governance
ContextNest / ContextNext — Verifiable Context Governance
一句话结论
ContextNest/ContextNext 的核心价值不是又一个 RAG，而是给 agent 可消费知识库增加“上下文治理层”：哪些材料被批准、是否当前有效、版本是什么、hash 是否匹配、agent 输出到底消费了哪一版上下文。它和 LLM-Wiki、Knowledge-as-Code、Context-Engineering 高度相关。
为什么对用户重要
用户的 llm-wiki 已经是一个 typed Markdown vault，并且有 raw、source、concept、index、log、vector index。今天的缺口不在“没有知识”，而在：检索结果是否可复现？某次回答用了哪些页面版本？raw 是否被改动？source 页面是否已经过期？vector 检索是否把不该参与的 raw/第三方文件混进来了？
ContextNest 把这些问题命名为 context governance。对 Hermes 来说，这意味着知识库不仅要能被搜索，还要能证明“当时被 agent 使用的上下文是合格、可追踪、可重建的”。
机制 / 一阶原理
普通 RAG 优化 relevance；context governance 先决定 retrieval 的候选集合是否合法。摘要里提到的机制包括 typed Markdown metadata、确定性 set-algebra selectors、contextnest:// URI、SHA-256 hash-chained version histories、graph checkpoints、MCP live data source nodes 和 context consumption audit traces。
一阶原理是：agent 的输入上下文也是供应链。只要上下文来源、版本、资格和消费轨迹不可追踪，输出就难以审计。向量相似度不能替代版本资格判断；高相关但过期或未批准的页面仍可能污染结果。
和既有 wiki 的关系
- LLM-Wiki 已经把知识从一次性检索升级为可维护 Markdown 网络；ContextNest 补的是治理与审计协议。
- Context-Engineering 关注如何组织、加载和评测上下文；ContextNest 强调确定性 selectors、版本身份和 consumption trace。
- Knowledge-as-Code 可吸收 hash、checkpoint、selector 和 audit log，把知识库变成更接近可测试工程制品的系统。
对 Hermes / llm-wiki 的可执行启发
- 低风险可立即做：继续保持 raw
sha256，并在雷达报告里说明新增页面的证据路径。 - 中期可做：为
wiki-vquery增加更明确的 category/type selector，并在报告中记录实际命中的页面。 - 长期可做：为重要回答保存 context manifest：query、页面 slug、mtime/hash、是否来自 raw/source/concept、是否被允许用于回答。
- 对 cron：把“reindex 成功”升级为“reindex 范围正确 + 未混入 data/phantom md + 新页面可检索”。
失败模式 / 未解问题
- 治理层过重会让个人 wiki 维护成本上升；需要先实现少量高杠杆检查，而不是照搬企业级规范。
- 确定性 selector 可能牺牲发现意外相关内容的能力，适合和 semantic search 并存。
- 摘要里的 dense+HNSW 非确定性结论需要看完整实验设置后再判断外推范围。
相关页面
写入记录
- 2026-07-06 09:00 CST：新增 ContextNest/ContextNext 来源页，提炼 context governance 对 llm-wiki 的版本、selector、hash 与审计启发。