Files

T

giteahh e8c22a4794 feat(wiki): 摄入历史性新机遇分析框架 + 静能量章节扩展 + frontmatter 验证工具增强

- 新增 wiki/历史性新机遇分析框架.md — 大镇乡谈政策分析框架（一目标一核心两支柱三周期）
- 更新 
aw/呸未然_静能量/ — 摄入 6 个章节内容（盘坐、正身、正言、正行、止念、业力）
- 新增/更新 wiki/静能量.md、wiki/佛家修行.md — 概念页扩展
- 优化 	ools/scripts/validate-frontmatter.py:
  * 支持根目录 .md 文件（如 AGENTS.md）的 wiki 专用检查
  * relations 目标存在性检查扩展到整个 vault（不限于 wiki/）
  * 添加 is_wiki_file() 判断，避免对非 wiki 文件误报
- 更新 wiki/LLM-Wiki-v2.md — 删除冗余 relation，修正 SCHEMA→AGENTS
- 更新 wiki/index.md — 页面数统计（505→506）
- 追加 wiki/log.md — ingest 记录

2026-07-03 09:39:55 +08:00

11 KiB

Raw Blame History

categories, tags, created, source, type, aliases, confidence, status, last_reviewed, review_interval_days, relations

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 老何在 AGENTS 重构时，把 LLM Wiki v2 文档里的"整合层级 (Consolidation Tiers)" — 原始观察 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆 — 正式落地为 vault 目录结构。

AGENTS 里的 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` `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 层：AGENTS.md 第 §五节编码了本文档里的 Consolidation Tiers 思想
自动生成层：_openclaw/sync-events.jsonl 记录 14 条维护事件，机器可读

与以终为始的关系

以终为始是习惯七律的第一条——先定终态再行动。本文是"终态是什么"的元描述：当习惯 → 流程 → 工具 → 目录都按 4 级记忆架构搭建，以终为始才有了具体的承载结构。

11 KiB Raw Blame History Unescape Escape