Auto-sync: 2026-04-28 12:03
This commit is contained in:
52
wiki/concepts/Context-Cores.md
Normal file
52
wiki/concepts/Context-Cores.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Context-Cores"
|
||||
type: concept
|
||||
tags: [AI-Memory, Context-Substrate, Version-Control, Portable-Context, Software-Engineering]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
由 [[TrustGraph]] 引入的概念——便携、带版本的上下文容器，包含领域 schema、知识图谱、向量嵌入、证据来源和检索策略。将上下文视为代码工程制品。
|
||||
|
||||
## Core Components
|
||||
一个 Context Core 包含：
|
||||
- **领域 Schema**：定义上下文中有什么类型的实体和关系
|
||||
- **知识图谱**：实体和关系的结构化表示
|
||||
- **向量嵌入**：语义检索支持
|
||||
- **证据来源**：每条上下文可追溯到原始来源
|
||||
- **检索策略**：如何查询和组合上下文
|
||||
|
||||
## Version Control Semantics
|
||||
Context Cores 的核心类比是**将上下文视为代码**：
|
||||
- **版本化（versioning）**：追踪上下文的演变历史
|
||||
- **测试（testing）**：验证上下文质量
|
||||
- **推动（promoting）**：将上下文从开发环境推入生产
|
||||
- **回滚（rolling back）**：恢复到之前状态
|
||||
|
||||
## Operational Value
|
||||
|
||||
### Agent 交接
|
||||
将 Context Core 交给新 Agent → 继承完整运营上下文
|
||||
```
|
||||
New Agent + Context Core → Full operational context
|
||||
```
|
||||
|
||||
### 实验分叉
|
||||
分叉一个 Context Core 做实验 → 合并回主分支
|
||||
```
|
||||
Main Context Core → Experiment Branch → Merge Back
|
||||
```
|
||||
|
||||
## Conceptual Significance
|
||||
TrustGraph 的 Context Cores 是整个 AI 记忆工具领域最接近**可部署的上下文单元**的概念。每个 Camp 1 工具将记忆视为对话的副作用。TrustGraph 将上下文视为有身份、版本和生命周期的第一等制品。
|
||||
|
||||
## Implementation Note
|
||||
TrustGraph 的实际实现较重（Cassandra + Qdrant），但概念模型是正确的方向——Context Core 的设计允许：
|
||||
- 团队成员间共享上下文
|
||||
- 在不同 Agent 间迁移
|
||||
- 对上下文变更进行 code review
|
||||
|
||||
## Connections
|
||||
- [[TrustGraph]] ← 引入 ← Context-Cores 由 TrustGraph 引入
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Cores 是 @witcheer 识别的最接近"可部署上下文单元"的概念
|
||||
37
wiki/concepts/Context-Engineering.md
Normal file
37
wiki/concepts/Context-Engineering.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Context-Engineering"
|
||||
type: concept
|
||||
tags: [AI-Memory, Context-Substrate, Market-Trend, Paradigm-Shift]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
由 [[Zep]] 公司引入的术语，代表 AI 记忆工具领域从"Memory"向 [[Context-Substrate]] 方向的范式转移。是该领域最重要的市场信号。
|
||||
|
||||
## Origin
|
||||
Zep 是一家获得融资的 AI 记忆工具公司（4.4k stars）。在审视了领域走向后，他们决定放弃"Memory"这个词，将整个品牌重新定位为"Context Engineering"。这一行为比任何技术文档都更能说明领域正在发生什么。
|
||||
|
||||
## Why the Rebrand Matters
|
||||
- Zep 有资金、有市场验证，不需要追热点
|
||||
- 他们的技术团队理解了 Camp 1 和 Camp 2 的区别
|
||||
- 他们选择了 Camp 2 的语言（"context"而非"memory"）
|
||||
- 这意味着 Context Substrate 不是学术概念，而是被市场验证的方向
|
||||
|
||||
## Author Prediction
|
||||
@witcheer 预测：**6 个月内，"Context Engineering"将取代"Memory"成为描述成熟 Agent 基础设施的标准术语**。
|
||||
|
||||
背后的逻辑：
|
||||
- 持续运行 Agent 的需求在增长
|
||||
- 这类 Agent 需要的不只是"记住"，而是"在不断丰富的上下文中工作"
|
||||
- 旧的"Memory"术语无法捕捉这种复杂性
|
||||
- "Context Engineering"更准确地描述了问题的本质
|
||||
|
||||
## Key Distinction
|
||||
- **Memory**：暗示一个独立于 Agent 的存储系统
|
||||
- **Context Engineering**：强调上下文的设计、构建和维护工程
|
||||
|
||||
## Connections
|
||||
- [[Context-Substrate]] ← 包含 ← Context-Engineering 是 Context Substrate 方向的商业化/品牌化语言
|
||||
- [[Zep]] ← 引入 ← Zep 率先使用 Context-Engineering 术语
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Engineering 是 @witcheer 识别的最重要市场信号
|
||||
@@ -1,41 +1,56 @@
|
||||
---
|
||||
title: "Context Substrate"
|
||||
type: concept
|
||||
tags: [ai-agent, memory, architecture]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Agent 的上下文管理技术路线之一（Camp 2）。维护结构化、人类可读的上下文文件（Markdown、知识图谱、上下文容器），跨会话自然累积增长。
|
||||
|
||||
## Core Philosophy
|
||||
**"What context should the AI work inside?"**（而非 Camp 1 的 "what should the AI remember?"）
|
||||
|
||||
- Nothing gets extracted — the context is the files.
|
||||
- 文件是人类可读、可编辑、可理解的。
|
||||
- 因为上下文是文件，人可以随时纠正、补充和理解 Agent 知道什么。
|
||||
- 系统随时间自然复合增长（compounding），而非依赖提取质量。
|
||||
|
||||
## Mechanism
|
||||
```
|
||||
Agent reads structured context → Agent works within that context →
|
||||
Agent (or background process) writes back to the structured context →
|
||||
Next session, the context is richer than before
|
||||
```
|
||||
|
||||
## Representative Tools
|
||||
- [[OpenClaw]]：Markdown 文件 + dreaming cycle
|
||||
- [[Zep]]：Temporal knowledge graph（Graphiti）
|
||||
- [[Thoth]]：Personal knowledge graph（10 entity types, 67 relations）
|
||||
- [[TrustGraph]]：Context Cores（可移植版本化上下文捆绑包）
|
||||
- [[MemSearch]]：Markdown-first + shadow vector index
|
||||
- [[ALIVE]]：Structured context substrate, walnuts as portable containers
|
||||
|
||||
## Relationship to Camp 1
|
||||
- Camp 1 优化目标：**召回**（can the system find the right fact?）
|
||||
- Camp 2 优化目标：**复合**（does the system get better over time?）
|
||||
- Zep 从"memory"→"context engineering"的品牌重塑，是 Camp 1/Camp 2 边界处最强的市场信号
|
||||
- Supermemory（Camp 1）的时序感知和 Honcho（Camp 1）的心理建模，代表 Camp 1 向 Camp 2 的演进趋势
|
||||
|
||||
## Key Distinction from RAG
|
||||
RAG 通常指一次性的文档检索问答场景；Context Substrate 强调**跨时间的上下文累积**，是持续运行 Agent 的基础设施。
|
||||
---
|
||||
title: "Context-Substrate"
|
||||
type: concept
|
||||
tags: [AI-Memory, Context-Substrate, File-Native, Compounding]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 记忆工具的 Camp 2 范式。维护结构化、人类可读的上下文，跨会话累积。不提取"事实"——上下文本身就是文件。问的核心问题是"**AI 应该在什么上下文中工作？**"
|
||||
|
||||
## Core Loop
|
||||
1. Agent 工作前读取结构化上下文
|
||||
2. Agent 在上下文中工作
|
||||
3. Agent（或后台进程）写回结构化上下文
|
||||
4. 下一会话，上下文比之前更丰富
|
||||
|
||||
## Optimization Goal
|
||||
**复合增长（compounding）**——系统是否随时间变得更好？
|
||||
|
||||
## Representative Tools
|
||||
- [[OpenClaw]]：358k stars，MEMORY.md + 每日笔记 + DREAMS.md，Dreaming 三阶段
|
||||
- [[Zep]]：4.4k stars，从"Memory"重品牌为"Context Engineering"，TKG 时间知识图谱
|
||||
- [[Thoth]]：145 stars，10 实体类型 + 67 关系，Dream Cycle 四阶段
|
||||
- [[TrustGraph]]：2.0k stars，Context Cores 版本化容器
|
||||
- [[MemSearch]]：1.2k stars，Markdown 优先，Milvus 影子索引
|
||||
- [[ALIVE]]：文件原生，零依赖，@witcheer 自用方案
|
||||
|
||||
## Common Characteristics
|
||||
- 文件（Markdown、知识图谱）是上下文本身
|
||||
- 人类可读、可编辑、可版本控制
|
||||
- 跨会话累积，不替换而是丰富
|
||||
- 后台整合进程（Dream Cycle）定期提炼
|
||||
- 透明度高：人类能准确知道 Agent 知道什么
|
||||
|
||||
## Key Contrast with Memory-Backend
|
||||
| 维度 | Memory Backend | Context Substrate |
|
||||
|------|---------------|-------------------|
|
||||
| 问的问题 | AI 应该记住什么？ | AI 应该在什么上下文中工作？ |
|
||||
| 处理对象 | 提取的"事实" | 结构化上下文文件 |
|
||||
| 人类可读 | 否 | 是 |
|
||||
| 随时间演进 | 否（静态条目） | 是（复合累积） |
|
||||
| 透明度 | 低（黑盒） | 高（文件可见） |
|
||||
| 优化目标 | 召回精度 | 复合增长 |
|
||||
| 适用场景 | 单轮问答 | 持续多会话 Agent |
|
||||
|
||||
## Connections
|
||||
- [[Memory-Backend]] ← 对立阵营 ← Context-Substrate
|
||||
- [[OpenClaw]] ← 属于 ← Context-Substrate
|
||||
- [[Zep]] ← 属于 ← Context-Substrate
|
||||
- [[Thoth]] ← 属于 ← Context-Substrate
|
||||
- [[TrustGraph]] ← 属于 ← Context-Substrate
|
||||
- [[MemSearch]] ← 属于 ← Context-Substrate
|
||||
- [[ALIVE]] ← 属于 ← Context-Substrate
|
||||
- [[Context-Engineering]] ← 重品牌化方向 ← Context-Substrate
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Substrate 是 @witcheer 提出的分类框架中的 Camp 2
|
||||
|
||||
63
wiki/concepts/Dream-Cycle.md
Normal file
63
wiki/concepts/Dream-Cycle.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Dream-Cycle"
|
||||
type: concept
|
||||
tags: [AI-Memory, Context-Substrate, Knowledge-Consolidation, Background-Process]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
[[OpenClaw]] 和 [[Thoth]] 采用的后台知识整合机制——夜间多阶段过程将日常笔记、短期上下文整合为长期记忆。是 Context Substrate 范式中最关键的"上下文复合"实现机制。
|
||||
|
||||
## OpenClaw Dreaming（三阶段）
|
||||
|
||||
源自 OpenClaw 的官方文档，定义了三层递进的整合阶段：
|
||||
|
||||
### Light Sleep（浅睡）
|
||||
- 筛选每日笔记
|
||||
- 将相近行分组为连贯段落
|
||||
- 识别值得保留的信息
|
||||
|
||||
### REM（快速眼动）
|
||||
- 加权召回提升（weighted recall promotion）
|
||||
- 频繁访问的信息成为"持久真理"（lasting truths）
|
||||
- 激活与巩固已有上下文关联
|
||||
|
||||
### Deep Sleep（深睡）
|
||||
- 安全推入 MEMORY.md（replay-safe promotion）
|
||||
- 协调而非重复（reconciles rather than duplicates）
|
||||
- 最终沉淀为长期记忆
|
||||
|
||||
### 阈值门控（Gate Mechanism）
|
||||
只有通过所有阈值的条目才会被提升：
|
||||
- 最小评分：0.8
|
||||
- 最小召回次数：3
|
||||
- 最小独立查询数：3
|
||||
|
||||
### 六维评分信号
|
||||
1. 相关性（relevance）：0.30
|
||||
2. 频率（frequency）：0.24
|
||||
3. 查询多样性（query diversity）：0.15
|
||||
4. 时效性（recency）：0.15
|
||||
5. 整合度（consolidation）：0.10
|
||||
6. 概念丰富度（conceptual richness）：0.06
|
||||
|
||||
## Thoth Dream Cycle（四阶段）
|
||||
|
||||
Thoth 实现了更精细化的四阶段过程：
|
||||
|
||||
1. **重复合并**（duplicate merging）：相似度 ≥ 0.93 的重复项合并
|
||||
2. **描述富化**（description enrichment）：从对话上下文中丰富实体描述
|
||||
3. **关系推断**（relationship inference）：推断共现实体之间的关系
|
||||
4. **置信度衰减**（confidence decay）：超过 90 天的关系置信度自动衰减
|
||||
|
||||
额外机制：
|
||||
- 三层反污染机制防止跨实体事实串扰
|
||||
|
||||
## Conceptual Significance
|
||||
Dream Cycle 的核心洞察：**系统不决定什么是"事实"，而是促进持续被证明相关的内容**。这比预先定义的提取规则更鲁棒，因为相关性来自实际使用模式而非人工设计。
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 实现 ← OpenClaw 实现了 Dreaming 三阶段
|
||||
- [[Thoth]] ← 实现 ← Thoth 实现了 Dream Cycle 四阶段
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Dream-Cycle 是 Camp 2 工具的核心整合机制
|
||||
71
wiki/concepts/Fact-Recall-vs-Compounding.md
Normal file
71
wiki/concepts/Fact-Recall-vs-Compounding.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "Fact-Recall-vs-Compounding"
|
||||
type: concept
|
||||
tags: [AI-Memory, Memory-Backend, Context-Substrate, Optimization-Goal]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 记忆工具领域的两种根本不同的优化目标：
|
||||
- **Fact Recall（事实召回）**：Memory Backend 范式追求的目标——系统能否找到正确的事实？
|
||||
- **Compounding（复合增长）**：Context Substrate 范式追求的目标——系统是否随时间变得更好？
|
||||
|
||||
## Camp 1: Fact Recall（事实召回）
|
||||
|
||||
### Definition
|
||||
给定一个查询，从存储的记忆中找到最相关的事实。
|
||||
|
||||
### Metric
|
||||
召回精度（recall accuracy），通常以百分比衡量：
|
||||
- [[MemPalace]]：LongMemEval 纯语义搜索 **96.6%**
|
||||
- [[Supermemory]]：LongMemEval + LoCoMo + ConvoMem 声称第一
|
||||
|
||||
### What This Optimizes For
|
||||
- "我三周前说的那句话是什么？"
|
||||
- "用户喜欢什么？"
|
||||
- "上次讨论 X 时说了什么？"
|
||||
|
||||
### Limitations
|
||||
- 精度再高，也只是"找到过去说过的话"
|
||||
- 无法让 Agent 变得"更好"——只是更准确地记住
|
||||
- 记忆是静态条目，不随交互演进
|
||||
|
||||
## Camp 2: Compounding（复合增长）
|
||||
|
||||
### Definition
|
||||
系统随时间和使用变得更丰富、更有价值——上下文在每次交互后复合增长。
|
||||
|
||||
### Metric
|
||||
难以量化，但可以观察：
|
||||
- 上下文在多会话后的丰富程度
|
||||
- Agent 决策质量的随时间提升
|
||||
- 人类对 Agent 上下文的理解程度
|
||||
|
||||
### What This Optimizes For
|
||||
- "给我跨五个项目的当前工作状态"
|
||||
- "我的 Agent 今天应该优先做什么？"
|
||||
- "过去三周发生了什么重要决策？"
|
||||
|
||||
### Advantage
|
||||
- 上下文本身就是可读的、可审计的
|
||||
- 人类可以理解、纠正、补充 Agent 的上下文
|
||||
- 上下文复合增长 → Agent 能力随时间提升
|
||||
|
||||
## The Fundamental Difference
|
||||
|
||||
| 问题 | Fact Recall | Compounding |
|
||||
|------|-----------|-------------|
|
||||
| 问 | "AI 应该记住什么？" | "AI 应该在什么上下文中工作？" |
|
||||
| 记忆是 | 提取的事实条目 | 累积的上下文文件 |
|
||||
| 随时间 | 静态（条目不演进） | 动态（复合增长） |
|
||||
| 人类交互 | 黑盒（不直接操作） | 白盒（直接读写文件） |
|
||||
| 适用场景 | 单轮问答 | 持续 Agent |
|
||||
|
||||
## Why Both Matter
|
||||
对于简单场景（聊天机器人记住用户偏好），Fact Recall 足够好。对于持续运行、多会话、多项目的 Agent，必须有 Compounding 能力。两者不互斥，但必须理解何时用哪个。
|
||||
|
||||
## Connections
|
||||
- [[Memory-Backend]] ← 优化目标 ← Memory-Backend 优化 Fact Recall
|
||||
- [[Context-Substrate]] ← 优化目标 ← Context-Substrate 优化 Compounding
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Fact-Recall-vs-Compounding 是 @witcheer 分类框架的核心区分轴
|
||||
@@ -1,41 +1,46 @@
|
||||
---
|
||||
title: "Memory Backend"
|
||||
type: concept
|
||||
tags: [ai-agent, memory, architecture, vector-db]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Agent 记忆工具的技术路线之一（Camp 1）。从对话中提取事实，存入向量数据库（和/或图数据库），下次对话时检索相关事实并注入上下文。
|
||||
|
||||
## Core Philosophy
|
||||
**"What should the AI remember?"**（而非 Camp 2 的 "what context should the AI work inside?"）
|
||||
|
||||
- 智能集中在**提取**和**检索**阶段。
|
||||
- 人类与 Agent 交互，记忆系统幕后运行。
|
||||
- 用户从不直接触碰记忆——信任系统记住正确的事情并在正确的时间召回。
|
||||
|
||||
## Fundamental Loop
|
||||
```
|
||||
Conversation → System extracts facts or stores content →
|
||||
Facts go into database (vector, graph, or both) →
|
||||
Next conversation: relevant facts retrieved and injected
|
||||
```
|
||||
|
||||
## Representative Tools
|
||||
- **[[Mem0]]**（53.1k stars）：四操作（add/search/update/delete），三层存储（user/session/agent），混合检索，集成最简单
|
||||
- **[[MemPalace]]**（46.2k stars）：逐字存储，ChromaDB，wings/rooms/drawers 组织，LongMemEval 96.6% 召回率
|
||||
- **[[Supermemory]]**（21.8k stars）：时序感知（过期事实自动遗忘），多模态连接器，MemoryBench 声称领先
|
||||
- **[[Honcho]]**（2.4k stars）：人/Agent 统一对等体模型，异步推理推导心理洞察，PostgreSQL + pgvector
|
||||
- 其他：Cognee（图数据库+向量搜索）、Memori（API 调用拦截，81.95% @ 4.97% context tokens）
|
||||
|
||||
## Limitations
|
||||
1. **记忆是扁平条目**——条目之间没有关系
|
||||
2. **提取质量依赖 LLM prompt**——garbage in, garbage out
|
||||
3. **事实不进化**——1月的事实和4月的事实并存，不知道谁取代了谁
|
||||
4. **无法真正复合增长**——系统只是在累积条目，不是在变得更聪明
|
||||
|
||||
## Relationship to Context Substrate
|
||||
- [[Context Substrate]]（Camp 2）代表不同哲学：上下文文件本身才是记忆，而非从对话中提取的条目
|
||||
- Supermemory 的时序感知和 Honcho 的心理洞察，代表 Camp 1 向 Camp 2 边界的演进
|
||||
- GitHub 上 450+ repos 标记"agent-memory"，几乎都属 Camp 1 路线
|
||||
---
|
||||
title: "Memory-Backend"
|
||||
type: concept
|
||||
tags: [AI-Memory, Memory-Backend, Vector-DB, Fact-Recall]
|
||||
sources: [ai-memory-tools-two-camps]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 记忆工具的 Camp 1 范式。从对话中提取事实并存储到向量数据库（或图数据库），检索相关事实并注入下一轮对话。问的核心问题是"**AI 应该记住什么？**"
|
||||
|
||||
## Core Loop
|
||||
1. 对话发生（conversation happens）
|
||||
2. 系统提取事实或存储内容（extract facts / store content）
|
||||
3. 事实进入数据库（向量、图或两者）
|
||||
4. 下一对话，相关事实被检索并注入
|
||||
|
||||
## Optimization Goal
|
||||
**召回精度（recall）**——系统能否找到正确的事实？
|
||||
|
||||
## Representative Tools
|
||||
- [[Mem0]]：53.1k stars，类别领导者，四操作 API
|
||||
- [[MemPalace]]：46.2k stars，本地优先，逐字记忆，96.6% 召回率
|
||||
- [[Supermemory]]：21.8k stars，时间感知，自动覆盖过期事实
|
||||
- [[Honcho]]：2.4k stars，对等体模型，心理洞察
|
||||
|
||||
## Common Characteristics
|
||||
- 从对话中提取"事实"（fact extraction）
|
||||
- 存储在向量/图数据库
|
||||
- 检索时注入上下文
|
||||
- 人类不直接与记忆交互
|
||||
- 信任系统记住正确的事并在正确时间检索
|
||||
|
||||
## Limitations
|
||||
- 记忆是扁平条目，条目间无关系
|
||||
- 每次提取需 LLM 调用，质量依赖提取提示词
|
||||
- 存储后不演进，无法处理新旧事实冲突
|
||||
- 无法支撑持续、多会话、多项目的 Agent 运行
|
||||
|
||||
## Connections
|
||||
- [[Context-Substrate]] ← 对立阵营 ← Memory-Backend
|
||||
- [[Mem0]] ← 属于 ← Memory-Backend
|
||||
- [[MemPalace]] ← 属于 ← Memory-Backend
|
||||
- [[Supermemory]] ← 属于 ← Memory-Backend
|
||||
- [[Honcho]] ← 属于 ← Memory-Backend
|
||||
- [[ai-memory-tools-two-camps]] ← 来源 ← Memory-Backend 是 @witcheer 提出的分类框架中的 Camp 1
|
||||
|
||||
@@ -1,38 +1,56 @@
|
||||
---
|
||||
title: "Scholar-Skill"
|
||||
type: concept
|
||||
tags: [obsidian, skills, academic, openclaw]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
scholar-skill 是 EESJGong 基于 OpenClaw 框架开发的学术研究 Skill，通过 L1/L2/L3 三级分级阅读策略，将原始论文（PDF/ArXiv）转化为 Obsidian 中的双链卡片、MOC（内容地图）和系统性反思报告。
|
||||
|
||||
## 三级阅读体系
|
||||
|
||||
| 级别 | 名称 | 产出 | 时长 |
|
||||
|------|------|------|------|
|
||||
| L1 | 分发级 | 快速评估，优先级判定（P0/P1/P2） | 分钟级 |
|
||||
| L2 | 标准阅读 | 结构化笔记 + 双链卡片 | 十几分钟 |
|
||||
| L3 | 深度解构 | MOC + 反思报告 + 知识冲突检测 | 最长 2.5 小时 |
|
||||
|
||||
## 特殊机制
|
||||
- **超长周期任务编排**：L3 级深度阅读最长 2.5 小时，依赖 durable-task-runner 处理 API 限流和崩溃恢复
|
||||
- **周期性反思**：内置时间触发器，在周末或月末强制对"临时存储的知识"进行 L2/L3 反思
|
||||
- **Human-in-the-loop**：发现新论文推翻旧笔记时，不直接覆写旧笔记，生成确认单放入 `0-Inbox` 文件夹，等待人工审核
|
||||
|
||||
## 必须依赖
|
||||
- `obsidian-direct`：绕过官方限制，直接读写本地 `.md` 文件
|
||||
- `arxiv-watcher`：通过 ArXiv API 抓取文献资源
|
||||
- `durable-task-runner`：L3 级别长时间挂机任务的调度与断点续传
|
||||
|
||||
## 风险预警
|
||||
⚠️ Token 消耗极高（L3 循环 + RAG 检索），商用模型可能带来高昂账单
|
||||
⚠️ `obsidian-direct` 使用暴力文件 I/O，多端同步期间易引发文件冲突
|
||||
|
||||
## Connections
|
||||
- [[EESJGong]] — scholar-skill 作者
|
||||
- [[OpenClaw]] — 运行基础框架
|
||||
- [[obsidian-必装-skills]] — 来源文档
|
||||
- [[StudyVault]] — L2/L3 产出的知识库格式
|
||||
- [[arXiv-API]] — 文献获取来源
|
||||
---
|
||||
title: "scholar-skill"
|
||||
type: concept
|
||||
tags: [obsidian, openclaw, academic, research, paper]
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## scholar-skill（学术论文分级阅读工作流）
|
||||
|
||||
### 简介
|
||||
scholar-skill 是基于 [[OpenClaw]] 框架的深度学术研究工具，通过 L1/L2/L3 分级阅读策略，将原始论文（PDF/ArXiv）转化为 Obsidian 中的双链卡片、MOC（内容地图）以及系统性反思报告。
|
||||
|
||||
### 核心机制
|
||||
|
||||
#### L1 快速评估（快速分发）
|
||||
对论文进行初步评估，判断其优先级（P0/P1/P2）。可后台静默执行。
|
||||
|
||||
#### L2 标准阅读（标准化笔记）
|
||||
按照预设模板提取论文的关键信息：研究问题、方法、结果、贡献。
|
||||
|
||||
#### L3 深度解构（深度解读）
|
||||
长达 2.5 小时的异步挂机任务，进行复杂公式解析、跨论文引用追踪、架构溯源。
|
||||
|
||||
### 触发条件
|
||||
当意图匹配到"阅读论文"、"L1/L2/L3阅读"、"知识内化"或"文献笔记"时自动触发。
|
||||
|
||||
### 依赖
|
||||
- **基础环境**：Python + Obsidian 客户端
|
||||
- **核心框架**：OpenClaw
|
||||
- **必须依赖**（通过 ClawHub 安装）：
|
||||
- `obsidian-direct`：绕过官方限制，直接通过 Python 读写本地 .md 文件
|
||||
- `arxiv-watcher`：通过 ArXiv API 抓取文献资源
|
||||
- `durable-task-runner`：支持 L3 级别长时间挂机任务的调度与断点续传
|
||||
- **可选依赖**：`tavily`（联网抓取）、`pdf`（文本解析）、`academic-research-hub`
|
||||
|
||||
### 特殊机制
|
||||
|
||||
#### 超长周期任务编排
|
||||
L3 级深度阅读设计为长达 2.5 小时的异步任务，底层依赖 `durable-task-runner` 处理 LLM 推演循环、API 限流等待以及崩溃恢复。
|
||||
|
||||
#### 周期性反思机制
|
||||
内置时间触发器逻辑，强制在周末或月末对"临时存储的知识"进行 L2/L3 反思，生成知识体系演进报告。
|
||||
|
||||
#### 人类确认防呆机制（Human in the loop）
|
||||
当 AI 发现新论文推翻旧笔记结论时，不会直接覆写旧笔记，而是生成确认单放进 `0-Inbox` 文件夹，等待人工审核。
|
||||
|
||||
### 风险预警
|
||||
- **财务风险**：L3 循环和高频历史知识检索（RAG）会消耗大量 Token，商用前沿模型（如 Claude 3.5 Sonnet 或 GPT-4o）单篇深读成本高昂
|
||||
- **数据覆写风险**：`obsidian-direct` 使用 Python 暴力文件 I/O，在 iCloud/Obsidian Sync 多端同步期间容易引发文件冲突，建议在独立测试库中运行并开启 Git 快照
|
||||
|
||||
### 与其他工具的关系
|
||||
- 与 [[tutor-skills]] 的通用学习不同，scholar-skill 专注于学术论文领域
|
||||
- 类似 [[arxiv-paper-reader]] 的论文获取能力，但 scholar-skill 强调深度内化和长期知识管理
|
||||
|
||||
### Aliases
|
||||
- scholar-skill
|
||||
|
||||
@@ -1,41 +1,45 @@
|
||||
---
|
||||
title: "Tutor-Skills"
|
||||
type: concept
|
||||
tags: [obsidian, skills, learning]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
tutor-skills 是 Choi Wontak 开发的 Obsidian "输入-内化-检测" 完整学习闭环系统，由两个 Skill 组成：[[Tutor-Setup]]（解析并生成知识库）和 [[Tutor]]（互动式测验 + 薄弱点追踪）。
|
||||
|
||||
## 组成
|
||||
|
||||
| Skill | 功能 | 触发方式 |
|
||||
|-------|------|----------|
|
||||
| [[Tutor-Setup]] | 将文档/代码库一键转化为 [[StudyVault]] | `/tutor-setup` 在工作目录 |
|
||||
| [[Tutor]] | 读取知识库进度，生成互动测验，追踪薄弱点 | `/tutor` 在已有 StudyVault 目录 |
|
||||
|
||||
## 核心机制：模式自动侦测
|
||||
无需手动指定，Skill 自动扫描当前工作目录：
|
||||
- 发现 `package.json`/`pom.xml` 等工程文件 → 进入**代码库模式**
|
||||
- 只有 PDF/纯文本 → 进入**文档模式**
|
||||
|
||||
## 核心机制：输入-内化-检测闭环
|
||||
```
|
||||
文档/代码库 → tutor-setup 解析 → StudyVault 生成
|
||||
↓
|
||||
Tutor 读取进度
|
||||
↓
|
||||
生成互动式测验 → 暴露知识薄弱点
|
||||
↓
|
||||
记录学习轨迹 → 持续改进
|
||||
```
|
||||
|
||||
## ⚠️ Token 消耗风险
|
||||
**代码库模式**会递归读取大量源文件并进行架构溯源（Phase C1-C9 循环），短时间内可能消耗大量 Token 额度。
|
||||
|
||||
## Connections
|
||||
- [[Choi-Wontak]] — tutor-skills 作者
|
||||
- [[StudyVault]] — tutor-skills 产出的知识库格式
|
||||
- [[obsidian-必装-skills]] — 来源文档
|
||||
- [[OpenClaw]] — 运行基础环境
|
||||
---
|
||||
title: "tutor-skills"
|
||||
type: concept
|
||||
tags: [obsidian, openclaw, learning, education]
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## tutor-skills（AI 学习闭环系统）
|
||||
|
||||
### 简介
|
||||
tutor-skills 是由 Choi Wontak 开发的一套 Obsidian AI 学习工具集，包含两个核心组件 `tutor-setup` 和 `tutor`，构成"**输入-内化-检测**"三阶段完整闭环。
|
||||
|
||||
### 核心组件
|
||||
|
||||
#### tutor-setup
|
||||
将任意本地文档或源代码工程自动解析，生成带有双链、MOC（内容地图）和复习题的独立 Obsidian 学习金库（StudyVault）。
|
||||
|
||||
#### tutor
|
||||
读取知识库的进度数据，在终端内生成互动式测验，追踪并攻克用户的知识薄弱点。
|
||||
|
||||
### 使用方法
|
||||
- **触发构建**：在特定工作目录输入命令 `/tutor-setup`
|
||||
- **触发复习**：在已有 StudyVault 的目录下输入 `/tutor`
|
||||
|
||||
### 特殊机制
|
||||
|
||||
#### 模式自动侦测
|
||||
无需手动指定，Skill 会自动扫描当前工作目录：
|
||||
- 发现 `package.json` 或 `pom.xml` → 进入"代码库模式"
|
||||
- 只有 PDF/纯文本 → 进入"文档模式"
|
||||
|
||||
#### Token 消耗风险
|
||||
尽管禁止了 PDF 图像读取，但"代码库模式"会递归读取大量源文件并进行架构溯源（Phase C1-C9 循环），在短时间内消耗大量 Token 额度。
|
||||
|
||||
### 依赖
|
||||
- 基础环境：智能体工具如 Claude Code、OpenCode
|
||||
- Obsidian 客户端及配置好的 Vault 文件夹
|
||||
|
||||
### 与其他工具的关系
|
||||
- 不同于 [[scholar-skill]] 的学术论文阅读方向，tutor-skills 面向通用文档和代码库学习
|
||||
- 与 [[obsidian-markdown]] 的被动笔记写作不同，tutor-skills 强调主动检测和复习机制
|
||||
|
||||
### Aliases
|
||||
- tutor-setup
|
||||
- tutor
|
||||
|
||||
Reference in New Issue
Block a user