hehaiguang1123
a6f05ab2d5
- Phase 0: AGENTS.md cleanup (dedup quotes, renumber sections, merge qmd) - Phase 1: typed relations (manage-relations.py, graph-search.py, check-staleness.py, detect-conflicts.py) - Phase 2: frontmatter validator, weekly lint, knowledge promotion, git hooks - Fix .gitignore to track tools/ and .githooks/ - Fix git remote URL (remove plaintext token) - New wiki pages: 504 pages, 34 raw sources
11 KiB
categories, tags, created, source, type, aliases
| categories | tags | created | source | type | aliases | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
2026-04-14 | https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2 | concept |
|
LLM Wiki v2
概述
Rohit Ghumare 基于 Karpathy 原始理念开发的升级版本，新增记忆生命周期和知识图谱等功能。
基于 agentmemory 项目实践经验总结。
核心理念
停止重新推导，开始积累编译
RAG 是检索和遗忘。Wiki 是积累和复合。
The Memex is finally buildable. — 最终，Memex 可以建造了
缺失的层级：记忆生命周期
置信度评分 (Confidence Scoring)
每个事实应携带置信度评分：
- 有多少来源支持
- 最近何时被确认
- 是否有矛盾
"项目X使用Redis缓存"
→ 来自2个来源
→ 上次确认3周前
→ 置信度 0.85
置信度随时间衰减，随确认强化。
超替 (Supersession)
新信息与旧信息矛盾时：
- 旧信息不删除，标记为过时
- 新信息显式替代旧信息
- 保留时间戳和关联
遗忘 (Forgetting)
非永久保留机制：
- 基于艾宾浩斯遗忘曲线
- 重要但长期未访问的内容逐渐淡化
- 不删除，降级优先权
- 架构决策衰减慢，临时Bug衰减快
整合层级 (Consolidation Tiers)
原始观察 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆
↓ ↓ ↓ ↓ ↓
最新/未处理 单会话摘要 跨会话压缩 跨会话事实 工作流/模式
超越平面页面：知识图谱
实体提取
-ingest 时提取结构化实体：
- 人 (People)
- 项目 (Projects)
- 库 (Libraries)
- 概念 (Concepts)
- 文件 (Files)
- 决策 (Decisions)
类型化关系
| 关系类型 | 说明 |
|---|---|
| uses | 使用 |
| depends on | 依赖 |
| contradicts | 矛盾 |
| caused | 导致 |
| fixed | 修复 |
| supersedes | 替代 |
图遍历查询
不同于关键词搜索，从节点向外遍历：
Redis → depends on → 下游依赖
→ uses → 使用它的项目
搜索扩展
混合搜索
| 搜索类型 | 能力 |
|---|---|
| BM25 | 关键词匹配、词干、同义词扩展 |
| 向量搜索 | 语义相似度 (Embeddings) |
| 图遍历 | 实体感知关系行走 |
融合方式：Reciprocal Rank Fusion (RRF)
自动化：事件驱动
| 事件 | 自动执行 |
|---|---|
| 新来源 | auto-ingest, 提取实体, 更新图谱 |
| 会话开始 | 加载相关上下文 |
| 会话结束 | 压缩为观察, 归档洞察 |
| 查询时 | 检查是否值得归档 (质量分数>阈值) |
| 记忆写入 | 检查矛盾, 触发超替 |
| 定时 | lint, 整合, 遗忘衰减 |
质量与自愈
评分系统
每个LLM生成的内容都应有质量分数：
- 结构是否良好
- 是否引用来源
- 是否与Wiki其他部分一致
自愈 (Self-healing)
Lint操作应自动修复：
- 孤立页面链接或标记
- 陈旧声明标记
- 修复断裂的交叉引用
矛盾解决
- 标记矛盾
- LLM提议哪个更可能正确（基于来源时效性、权威性、观察数量）
- 人类可覆盖
多智能体与协作
网格同步
多智能体并行观察合并：
- Last-write-wins (大多数情况)
- 时间戳解决冲突
- 支持手动覆盖
共享 vs 私有
| 类型 | 说明 |
|---|---|
| 私有 | 我的偏好、工作流 |
| 共享 | 项目架构、团队决策 |
工作协调
- 谁在做什么
- 什么被阻塞
- 什么完成了
隐私与治理
###-ingest 时过滤
自动剥离敏感信息：
- API密钥
- Token
- 密码
- 标记为私有的内容
审计追踪
每次操作记录：
- 时间戳
- 变更内容
- 变更原因
结晶化 (Crystallization)
将完成的工作链自动提炼为结构化摘要：
探索结果 → 问题 → 发现 → 涉及实体 → 教训
探索是来源，与文章/论文同等对待。
实现光谱
| 层级 | 组件 | 适用规模 |
|---|---|---|
| 最小可用 | 原始来源 + Wiki页面 + index.md + Schema | ~50页 |
| +生命周期 | 置信度、超替、基本遗忘 | ~100页 |
| +结构 | 实体提取、类型关系、知识图谱 | ~200页 |
| +自动化 | Hooks、自动-ingest、自动lint | ~500页 |
| +扩展 | 混合搜索、整合层级、质量评分 | 500+页 |
| +协作 | 网格同步、共享/私有、工作协调 | 多用户 |
Schema 是真正的产品
CLAUDE.md / AGENTS.md 是系统最重要的文件：
- 定义存在的实体和关系类型
- 如何-ingest 不同来源
- 何时创建新页面 vs 更新现有页面
- 应用什么质量标准
- 如何处理矛盾
- 整合计划是什么
- 什么是私有 vs 共享
相关链接
| 项目 | 地址 |
|---|---|
| LLM Wiki v2 | gist.github.com/rohitg00 |
| Karpathy原始版 | gist.github.com/karpathy/442a6bf555914893e9891c11519de94f |
| agentmemory | github.com/rohitg00/agentmemory |
本地研究
学习资料：~/.openclaw/workspace/llm-wiki-v2-study/README.md
家族新成员：Google Open Knowledge Format (OKF)
验证日期：2026-06-16
结论：不投入。作为导出格式保留，作为生产格式放弃。
它是什么
Google 2026-06 发布的开放规范，把 Karpathy LLM Wiki + Rohit v2 的"Markdown + YAML frontmatter + 互相链接"模式抽成正式标准。v0.1 核心：
- 唯一硬性要求：
type字段 - 约定字段 6 个：
type/title/description/resource/tags/timestamp - 概念之间用普通 Markdown 链接（不是
[[wikilink]]） - 可选
index.md（导航）+log.md（变更历史） - 完整规范一页纸写完
GitHub: GoogleCloudPlatform/knowledge-catalog/tree/main/okf
真实验证（教育AI研究 corpus）
把 /root/.openclaw/workspace/教育AI研究/（121 个 .md）按 OKF 规范导出，10 秒脚本化完成，121/121 满足硬性要求。但暴露 7 个 friction：
- type 命名空间碎片化 — 49 个无 frontmatter 文件需要重写，OKF 不约束
- wikilink 不会自动变 Markdown link — 61 个内部链接需手工翻译
- 自定义字段（你用 20+ 字段）超出 OKF 6 字段 — 跨厂商只
tags真互操作 resource字段对研究型语料语义模糊 — OKF 假设指向 DB/API 链接- tag 表述不统一 —
LLM/大语言模型/生成式AI教育三个 tag 指同一概念 log.md完全可选 — 你的outputs/时间序列报告对 consumer 是黑盒- 40% 文件无 frontmatter — OKF 之外的 tool 拿不到元数据
与现有体系的关系
| 维度 | 你的 LLM Wiki v2 | OKF |
|---|---|---|
| frontmatter 字段 | 20+ 自定义 | 6 个约定（可扩展） |
| 链接语法 | [[wikilink]] Obsidian 风格 |
普通 Markdown |
| 互操作 | 自给自足 | 跨厂商设计 |
| 演化速度 | 个人决定 | 慢（一旦标准化） |
| type 系统 | 无强制 | 强制但自定义空间大 |
不投入的理由
- 生产层没有迁移收益。你现有 Obsidian 风格 + 自定义 frontmatter 体系已经能跑
- 导出层有保留价值。需要给外部 consumer 时，OKF 是个体面的交付物形态
- Google 立场可疑。"中立"是策略不是信仰，参考实现全部跑在 GCP 上
- type 命名空间是规范层隐患。OKF 文章刻意回避，落到具体语料立刻显形
何时重评
以下任一信号出现，重启这条线：
- Google/Cloud 之外出现独立的 OKF type 字典
- 有外部组织真正要求你交付 OKF 格式
- OKF v0.2 / v1.0 解决 type 命名空间问题
- 你开始"对外交付"知识（不是给 agent 内用，而是给合作机构/公众）
验证产物保留：
- Bundle：
/root/教育AI研究_okf/（30MB） - 脚本：
/tmp/build_okf.py（可重跑）
最后更新：2026-06-30（追加"4 级记忆在老何 wiki 落地"章节 + frontmatter 修正）
4 级记忆架构在老何 wiki 的落地（2026-06-30）
背景：2026-06-30 老何在 SCHEMA 重构时，把 LLM Wiki v2 文档里的"整合层级 (Consolidation Tiers)" — 原始观察 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆 — 正式落地为 vault 目录结构。
SCHEMA 里的 5 层映射
| LLM Wiki v2 概念 | 老何 wiki 目录 | 关键特征 |
|---|---|---|
| Working Memory（原始观察） | raw/ |
不可变输入（HTML/PDF/转录） |
| Working Memory（AI 可读提炼） | sources/ |
AI 摘要版本 |
| Episodic Memory | Daily/ |
每日笔记 + Dataview 视图 |
| Semantic Memory | concepts/ entities/ syntheses/ |
概念、实体、综合报告 |
| Procedural Memory | AGENTS.md SCHEMA.md log.md scripts/ |
规则、流程、工具 |
| 自动生成 | reports/ _openclaw/ |
系统诊断 + agent 缓存 |
与原 LLM Wiki v2 设计的差异
| 维度 | LLM Wiki v2 原始设计 | 老何 wiki 实际落地 |
|---|---|---|
| 记忆层级数 | 5 层 | 5 层 + 1 个自动生成层 |
| 工作记忆命名 | Working Memory | 拆成 raw/（不可变）+ sources/（可编辑提炼） |
| 程序记忆 | 不强调 | 4 个固定文件（AGENTS/SCHEMA/log/scripts）显式建模 |
| 写入分区 | 单端 | 双端（PC + 腾讯云），按目录分区 |
| 同步机制 | 不强调 | Gitea 双端同步（详见 wiki-gitea-sync skill） |
实际跑过的验证
2026-06-30 修复 wiki ↔ Gitea 同步时，本文档被作为"4 级记忆架构"的活样本使用：
- Working Memory 层：
raw/articles/接收老何下载的讲座转录、HTML 原文 - Episodic Memory 层：
Daily/2026-06-30.md记录当天会话事件流 - Semantic Memory 层：本文档（
concepts/LLM-Wiki-v2.md）作为概念层锚点 - Procedural Memory 层：
SCHEMA.md第 §五节编码了本文档里的 Consolidation Tiers 思想 - 自动生成层：
_openclaw/sync-events.jsonl记录 14 条维护事件，机器可读
与 以终为始 的关系
以终为始 是习惯七律的第一条——先定终态再行动。本文是"终态是什么"的元描述：当习惯 → 流程 → 工具 → 目录都按 4 级记忆架构搭建，以终为始 才有了具体的承载结构。