giteahh/llm_wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 0-2: Schema cleanup, typed relations, event-driven automation

Browse Source 
- 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
This commit is contained in:
hehaiguang1123
2026-07-01 08:05:43 +08:00
parent e544d6e04a
commit a6f05ab2d5
1067 changed files with 522992 additions and 819 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/docs/homewiki/CLI-MCP-Skill关系.md
+216
View File
@@ -0,0 +1,216 @@
# CLI / MCP / Skill 三层架构关系
## 一句话说明
- **CLI** = 底层程序，在 terminal 里执行
- **MCP Server** = 通过 MCP 协议暴露工具，LLM 直接调用
- **Skill** = 使用说明书，告诉 LLM 什么时候、怎么调用前两者
---
## 架构图
```
┌──────────────────────────────────────────────────┐
│ Skill (SKILL.md) │
│ 作用：告诉 LLM 怎么用工具 │
│ - 何时用它（触发条件） │
│ - 用什么命令/参数 │
│ - 典型示例 │
│ 不是程序，是"使用手册" │
└──────────────────────┬───────────────────────────┘
│ 被 LLM 读取
┌──────────────▼───────────────┐
│ MCP Server │
│ LLM 通过 MCP 协议直接调用 │
│ 结果结构化返回给 LLM │
│ 无需写命令，LLM 自己组织调用 │
└──────────────┬───────────────┘
│ MCP 协议 / 工具调用
┌──────────────▼───────────────┐
│ CLI / 外部服务 │
│ 底层执行程序 │
│ mmx / npx / curl / gh 等 │
└───────────────────────────────┘
```
**关键理解：Skill 和 MCP 是不同层次的东西，不互斥。**
- **有 MCP 无 Skill**：LLM 可能不知道怎么用
- **有 Skill 无 MCP**：LLM 知道怎么用但没有工具可用
- **有 Skill + MCP**：LLM 知道怎么用且能直接调用 ✅
---
## 当前环境概览
```
MCP Servers: 6 个
Skills: 93 个（含 MiniMax/GLM 相关 10+ 个）
CLI 工具: mmx / hermes / gh / git / curl / npx 等
主模型: MiniMax-M2.7 (minimax-cn)
备选模型: GLM-4.7 (zai, GLM Coding Plan)
```
---
## 当前 MCP Servers
| Server | 协议 | 功能 | Skill |
|--------|------|------|-------|
| `hermes-docs` | HTTPS | Hermes 中文文档搜索/读取 | — |
| `minimax-token` | npx (stdio) | MiniMax Coding Plan 编程辅助（代码补全/搜索） | `minimax` |
| `zread` | npx (stdio) | 通用网页读取 | — |
| `glm-reader` | HTTP Stream | GLM 网页内容读取（markdown/text） | `glm-reader` |
| `glm-search` | HTTP Stream | GLM 网络搜索（返回标题/URL/摘要） | `glm-search` |
| `zai-vision` | npx (stdio) | GLM-4.6V 图片理解/截图分析/视频解析 | `zai-vision` |
### 关系说明
```
glm-search ──MCP── LLM 直接调用搜索网页
glm-reader ──MCP── LLM 直接调用读网页内容
zai-vision ──MCP── LLM 直接调用理解图片/视频
minimax-token ──MCP── LLM 直接调用编程辅助（不是搜索/图片）
hermes-docs ──MCP── LLM 直接调用查 Hermes 文档
zread ──MCP── LLM 直接调用读网页
```
---
## 当前 Skills（重点分组）
### 🔵 MiniMax 相关（mmx CLI + MCP）
| Skill | 功能 | 底层 |
|-------|------|------|
| `minimax` | 全能力汇总：图/视频/音乐/语音/搜索 | mmx-cli |
| `minimax-image` | 文生图（MiniMax Image 01） | mmx CLI `mmx image` |
| `minimax-video` | 文生视频（Hailuo 2.3） | mmx CLI `mmx video` |
| `minimax-music` | 文生音乐（Music 2.6） | mmx CLI `mmx music` |
| `minimax-speech` | 语音合成（Speech 2.8 HD） | mmx CLI `mmx speech synthesize` |
| `minimax-search` | 网络搜索 | mmx CLI `mmx web` |
**关系：**
- Skill 告诉 LLM：`mmx image "描述"` 可以生成图片
- mmx CLI 是实际执行程序（已认证，可直接用）
- `minimax-coding-plan-mcp` 是另一个 MCP，提供编程辅助能力
### � eco9; 🟢 GLM 相关（MCP 直接暴露）
| Skill | 功能 | 底层 |
|-------|------|------|
| `glm-search` | 网络搜索 | `glm-search` MCP |
| `glm-reader` | 网页内容读取 | `glm-reader` MCP |
| `glm-coding-plan` | GLM 全能力汇总（搜索/读页/图/视频理解） | GLM MCP 组合 |
| `zai-vision` | 图片/截图/视频理解 | `zai-vision` MCP |
**关系：**
- 全是 MCP 直接暴露，无独立 CLI
- LLM 通过 MCP 协议直接调用这些工具
- Skill 告诉 LLM 工具的用法和适用场景
### 🟡 其他常用 Skills
| Skill | 功能 |
|-------|------|
| `hermes-onboarding` | Hermes 学习路径（Phase 1-5） |
| `hermes-agent` | Hermes 自身配置/扩展 |
| `subagent-driven-development` | delegate_task 并行任务编排 |
| `jupyter-live-kernel` | 交互式 Python（数据科学） |
| `arxiv` | 学术论文搜索 |
| `youtube-content` | YouTube 字幕→摘要/文章 |
| `spotify` | Spotify 控制（播放/搜索/歌单） |
| `github-pr-workflow` | GitHub PR 完整流程 |
| `openhue` | 飞利浦 Hue 智能灯光控制 |
| `xurl` | X/Twitter 发推/搜索/DM |
---
## 当前 CLI 工具
| CLI | 功能 |
|-----|------|
| `mmx` | MiniMax Token Plan 全能力入口（图/视频/音乐/语音/搜索），v1.0.13 |
| `hermes` | Hermes Agent 自身管理（config/cron/mcp/skills 等） |
| `gh` | GitHub CLI（需确认已安装） |
| `git` | 版本控制 |
| `curl` | HTTP 请求 |
| `npx` | 运行 npm 包（MCP servers 用） |
---
## 使用场景对照
### 场景 1：让 LLM 搜索网页
**MCP 路线（直接）：**
```
LLM → glm-search MCP tool → 返回搜索结果
需要 skill glm-search 告诉 LLM 怎么用
```
**CLI 路线（间接）：**
```
LLM → terminal → mmx web "关键词" → 解析输出
需要 skill minimax-search 告诉 LLM 命令格式
```
### 场景 2：生成一张图片
**CLI 路线（实测）：**
```bash
mmx image "一只橘色的猫在打哈欠" --out /tmp/cat.png
```
skill `minimax-image` 告诉 LLM 这个命令格式。
**MCP 路线：**
当前无原生图片生成 MCP，通过 mmx CLI 走 skill 路线。
### 场景 3：理解一张图片
**MCP 路线：**
```
LLM → zai-vision MCP tool → 返回图片描述/分析
skill zai-vision 告诉 LLM 工具用法
```
### 场景 4：写好笔记让 LLM 记住
**Skill 路线：**
```
skill minimax-image → 告诉 LLM 用 mmx image 生成图片
skill glm-search → 告诉 LLM 用 glm-search MCP 搜索
```
---
## 认证状态
```bash
$ mmx auth status
→ method: api-key, 已认证 ✅
$ hermes mcp list
→ 6 个 MCP servers，全部 enabled ✅
$ hermes config get tts.provider
→ minimax ✅（语音已配置）
```
---
## 常见误区
1. **"有了 Skill 就不需要 MCP"** — 错。Skill 是文档，MCP 是工具，缺一不可。
2. **"有了 MCP 就不需要 Skill"** — 错。LLM 需要 Skill 告诉它什么时候用、怎么描述参数。
3. **"MiniMax MCP 就是 mmx CLI"** — 错。`minimax-coding-plan-mcp` 是另一个工具，提供编程辅助，和 `mmx image` 等 CLI 命令是不同的东西。
4. **"配置了 Skill 就自动能用"** — 错。Skill 只是文档，底层程序必须可用（MCP server 在线，或 CLI 已安装认证）。
---
## 文件位置
- Skills：`~/.hermes/skills/`
- MCP 配置：`~/.hermes/config.yaml` → `mcp_servers:`
- Obsidian 笔记：`/home/obsidian/wiki/03-工具/layer-架构/`
tools/docs/homewiki/Hermes多Agent协作机制官方文档解析.md
+265
View File
@@ -0,0 +1,265 @@
# Hermes 多 Agent 协作机制官方文档解析
> 来源：Hermes Agent 官方文档（hermesagent.org.cn）
> 整理时间：2026-05-20
> 用途：Hermes（二休）建立独立于 OpenClaw 的多 Agent 协作闭环
---
## 核心发现：Hermes 有三套独立的 Multi-Agent 机制
这和 OpenClaw 的持久 Agent（main/news/assistant/research）模式完全不同。Hermes 的多 Agent 是**可组合的三层架构**：
| 机制 | OpenClaw 对应 | 用途 | 特点 |
|------|-------------|------|------|
| **Profiles** | 配置文件 | 同一机器运行多个独立 Agent | 完全隔离的配置/记忆/技能/网关 |
| **delegate_task** | agentToAgent | 临时委派子 Agent | 最多 3 并发，隔离上下文，父 Agent 只收摘要 |
| **cron jobs** | 定时任务 | autonomous Agent | 后台自动运行，可链式编排 |
---
## 1. Profiles（配置文件）
### 核心概念
> 在同一台机器上运行多个独立的 Hermes Agent —— 每个 Agent 拥有自己的配置、API 密钥、记忆、会话、技能和网关。
### 关键特点
- 创建 Profile 后自动获得命令别名（如 `hermes profile create coder` → `coder chat`）
- **完全隔离**：每个 Profile 有独立的 `config.yaml`、`.env`、`SOUL.md`、记忆、会话、技能、定时任务
- 不同用途可运行不同 Profile：代码助手、个人机器人、研究 Agent
- 不会相互干扰
### 命令示例
```bash
hermes profile create research # 创建 research Profile
research setup # 配置 API 密钥和模型
research chat # 开始聊天
hermes profile list # 列出所有 Profile
hermes profile use research # 切换默认 Profile
```
### 适用场景
- 需要**长期运行**的专用 Agent（如专门的代码 Agent、研究 Agent）
- 不同 Agent 需要不同模型或 API 密钥
- 需要完全隔离的记忆和上下文
---
## 2. delegate_task（子 Agent 委派）
### 官方文档核心要点
> `delegate_task` 工具会启动具有隔离上下文、受限工具集和独立终端会话的子 AIAgent 实例。每个子 Agent 都会获得一个全新的对话，并独立工作——只有其最终摘要才会进入父 Agent 的上下文。
### 重要约束
:::warning 子 Agent 一无所知
子 Agent 从一个**完全全新的对话**开始。它们对父 Agent 的对话历史、之前的工具调用或任何先前讨论的内容都**一无所知**。唯一上下文来自 `goal` 和 `context` 字段。
:::
**正确传递上下文：**
```python
# BAD - subagent 不知道 "the error" 是什么
delegate_task(goal="Fix the error")
# GOOD - subagent 拥有所需的所有内容
delegate_task(
goal="Fix the TypeError in api/handlers.py",
context="""The file api/handlers.py has a TypeError on line 47:
'NoneType' object has no attribute 'get'.
The function process_request() receives a dict from parse_body(),
but parse_body() returns None when Content-Type is missing.
The project is at /home/user/myproject and uses Python 3.11."""
)
```
### 单个任务
```python
delegate_task(
goal="Debug why tests fail",
context="Error: assertion in test_foo.py line 42",
toolsets=["terminal", "file"]
)
```
### 并行批量任务（最多 3 并发）
```python
delegate_task(tasks=[
{"goal": "Research topic A", "toolsets": ["web"]},
{"goal": "Research topic B", "toolsets": ["web"]},
{"goal": "Fix the build", "toolsets": ["terminal", "file"]}
])
```
### 工具集选择建议
| 任务类型 | 工具集 |
|---------|--------|
| 代码审查 / 重构 | `["terminal", "file"]` |
| 网络研究 | `["web"]` |
| 浏览器自动化 | `["browser"]` |
| 定时任务管理 | `["cronjob"]` |
| 文件操作 | `["file"]` |
| 混合任务 | `["terminal", "file", "web"]` |
### 最大并发数
默认最多 **3 个并发子 Agent**。超出则排队等待。
### 深度限制
子 Agent（leaf role）**不能**进一步委派。Orchestrator role 可以委派，但 nesting depth 有限制。
---
## 3. cron jobs（定时 Autonomous Agent）
### 官方文档要点
- Jobs 运行在**新鲜 session** 中，无当前聊天上下文
- Prompts 必须**自包含**
- 如果提供 skills，按顺序加载后执行 prompt
- 支持**链式编排**：Job A 收集数据 → Job B 处理 → Job C 汇总
- Delivery 可指定：`origin`（回当前聊天）、`local`（仅保存）、`all`（所有连接渠道）
### delivery 参数
| 值 | 行为 |
|---|------|
| `origin` | 回当前聊天（默认） |
| `local` | 仅保存到 `~/.hermes/cron/output/` |
| `all` | 广播到所有已连接渠道 |
| `platform:chat_id` | 指定特定渠道 |
### 关键安全规则
> **cron-run sessions should not recursively schedule more cron jobs.**
---
## Hermes Multi-Agent 协作闭环设计
基于官方文档三机制，设计 Hermes（二休）的多 Agent 协作闭环：
### 机制选型
| 任务类型 | 推荐机制 | 说明 |
|---------|---------|------|
| 临时性研究任务 | `delegate_task` | Web 并行研究，1 次性 |
| 临时性编码任务 | `delegate_task` | Terminal/File 工具集 |
| 长期专用 Agent | **Profiles** | 独立的 research/coder Agent |
| 定期自动任务 | **cron jobs** | 每小时/每天执行 |
### Hermes 协作闭环架构
```
微信指令（老何）
│
▼
┌─────────────────────────────────────┐
│ Hermes（二休）- 主 Agent │
│ - 理解任务 │
│ - 拆解步骤 │
│ - 判断：直接做 / delegate / cron │
└─────────────────────────────────────┘
│
├──────────────────┬──────────────────┐
▼ ▼ ▼
delegate_task delegate_task cron job
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────────┐
│Research │ │ Coding │ │ Autonomous │
│ Agent │ │ Agent │ │ Agent │
│(临时) │ │(临时) │ │(定时) │
└─────────┘ └─────────┘ └─────────────┘
│ │ │
└──────────────────┴──────────────────┘
│
▼
结果写 Wiki / Git push
│
▼
PC 端 OpenCode 读取处理
```
### 与 OpenClaw 的关键区别
| 维度 | OpenClaw | Hermes |
|------|----------|--------|
| Agent 类型 | 持久 Agent（main/news/assistant/research） | Profiles（持久）+ delegate_task（临时）+ cron（定时） |
| 上下文共享 | 共享对话历史 | delegate_task 完全隔离，Profiles 独立隔离 |
| 委派方式 | agentToAgent 配置 | delegate_task 工具调用 |
| 通信机制 | 共享消息通道 | Profile 间通过 Wiki/Git 间接协作 |
| 向量检索 | embedding-3（OpenAI API） | embedding-3（OpenAI API） |
### Wiki 协作路径
```
Hermes委派子Agent → 处理结果写入Wiki → Git push到Gitee
│
▼
PC端 OpenCode 读取Wiki
│
▼
处理结果写回Wiki → Git push
│
▼
Hermes 读取Wiki → 汇总结果
```
---
## 实际配置记录
### Profile 创建（2026-05-20）
| Profile | 模型 | 用途 | 目录 |
|--------|------|------|------|
| `research` | glm-4.7 | 网络研究、信息收集 | `/home/ubuntu/.hermes/profiles/research/` |
| `coder` | MiniMax-M2.7 | 代码审查/重构/执行 | `/home/ubuntu/.hermes/profiles/coder/` |
### Wiki 协作目录
```
raw/
├── research/ # research profile 输出
└── coder/ # coder profile 输出
```
### PC 端协作流程
```
1. Hermes 委派 research/coder 子 Agent
2. 结果写入 /home/obsidian/wiki/raw/research/ 或 raw/coder/
3. Git push 到 Gitee
4. PC 端 Obsidian Git 插件定时拉取
5. PC OpenCode 读取处理
6. PC 端处理结果写回 Wiki → Git push
7. Hermes 读取 Wiki 汇总
```
### Profile 命令
```bash
research chat # 进入 research profile
coder chat # 进入 coder profile
research gateway start # 启动 research 网关（当前不需要）
coder gateway start # 启动 coder 网关（当前不需要）
```
---
## 参考文档
- [子 Agent 委派](https://hermesagent.org.cn/docs/user-guide/features/delegation)
- [配置文件](https://hermesagent.org.cn/docs/user-guide/profiles)
- [Agent Loop 内部机制](https://hermesagent.org.cn/docs/developer-guide/agent-loop)
- [架构](https://hermesagent.org.cn/docs/developer-guide/architecture)
tools/docs/homewiki/LLMWiki知识基建完善计划.md
+327
View File
@@ -0,0 +1,327 @@
# LLMWiki 知识基建完善计划
## 一、现状盘点
### 1.1 已有的东西
| 组件 | 状态 | 说明 |
|------|------|------|
| 目录结构 | ✅ 已有 | concepts/ entities/ sources/ reports/ syntheses/ |
| Front Matter | ⚠️ 部分规范 | 概念页有，实体页有，但 top-level 混乱 |
| auto-digest | ✅ 已有 | .openclaw-wiki/cache/agent-digest.json |
| Reports | ✅ 已启用 | claim-health/contradictions/stale-pages 等6个报告 |
| index.md | ⚠️ 残缺 | 有人工写的索引，但与 digest 不同步 |
| WIKI.md | ✅ 已有 | vault 元数据（isolated/native） |
| AGENTS.md | ✅ 已有 | Agent 交互规则 |
### 1.2 缺失的核心文件
| 文件 | 用途 | 状态 |
|------|------|------|
| `SCHEMA.md` | 领域规范：定义实体类型、关系、标签体系 | ❌ 不存在 |
| `log.md` | 操作日志：记录增删改、来源追踪 | ❌ 不存在 |
| `raw/` | 原始资料：PDF、HTML、剪藏的未处理原始内容 | ❌ 不存在（sources/ 混用了） |
| `claims.jsonl` | 机器可读的结构化事实库 | ❌ 不存在 |
| 标签体系 | 统一标签枚举 | ⚠️ 不一致 |
### 1.3 数据统计
```
Page counts:
concepts: 7 ✅ 有实质内容
entities: 2 ⚠️ 有内容但未在 agent-digest 中计入
sources: 40 ✅ 散落在 sources/
synthesis: 1 ⚠️ 哈尔滨工程大学报告（来源不明）
reports: 6 ✅ 自动生成
Claim count: 5
missing evidence: 5 ← 所有 claims 都缺来源
contested: 0
stale: 0
```
### 1.4 质量评估
**最大问题：所有 claims 都没有证据来源。**
这意味着知识库的"知识"部分其实还没有真正建立——页面虽然写了，但每个结论背后引用的原始资料没有被记录。
---
## 二、完善目标
### 2.1 目标状态
```
最小可用层（50页规模）：
✅ sources/ 有原始资料
✅ 实体页/概念页有完整 frontmatter
✅ SCHEMA.md 定义规范
✅ index.md 作为主入口
✅ log.md 记录变更历史
进阶层（100页）：
✅ raw/ 分离原始资料
✅ claims.jsonl 结构化事实库
✅ 标签体系规范化
✅ 置信度评分
知识图谱层（200页）：
⬜ 实体提取自动化
⬜ 类型化关系定义
⬜ 图遍历查询
```
---
## 三、分阶段实施方案
### 阶段 A：补全核心元文件（1-2天）
这是基础设施，补完才能谈其他所有功能。
#### A1. 创建 SCHEMA.md
```markdown
# SCHEMA.md — 知识库领域规范
## 领域定义
本知识库服务于：高等教育AI研究方向的知识积累与研究协作
## 实体类型（Entities）
| 类型 | 说明 | 示例 |
|------|------|------|
| person | 人物 | [[郭朝晖]] |
| organization | 组织机构 | [[宝钢]] |
| concept | 概念 | [[涌现]] |
| project | 项目/系统 | [[Hermes Agent]] |
| paper | 论文 | arXiv:2510.19247 |
| article | 文章 | 微信公众号文章 |
| tool | 工具/软件 | [[Obsidian]] |
## 概念类型（Concepts）
见 concepts/ 目录下的分类
## 关系类型
| 关系 | 说明 |
|------|------|
| uses | 使用某工具/方法 |
| depends-on | 依赖某系统 |
| caused-by | 由...导致 |
| contradicts | 与...矛盾 |
| supersedes | 替代旧内容 |
| related-to | 相关 |
## 标签体系（Canonical Tags）
必须从以下标签中选择，禁止自定义标签：
- 研究方向：[higher-ed, AI-education, curriculum-design, assessment]
- 技术类：[LLM, RAG, agent, knowledge-graph, embedding]
- 项目类：[project, tool, skill, workflow]
- 人物类：[researcher, practitioner, mentor]
- 元类：[meta, methodology, reflection]
## 页面创建规则
1. 每个页面必须有完整 frontmatter
2. 概念页必须包含：定义、关键特征、相关概念
3. 实体页必须包含：基本信息、主要贡献、关联概念
4. 来源页必须在 frontmatter 的 sources 字段中引用原始文件
## Claims 规范
每个 claim 格式：
```json
{"text": "...", "source": "来源ID", "confidence": 0.9, "date": "2026-05-20"}
```
## Lint 规则
- 所有 [[Wikilinks]] 必须指向已存在的页面
- sources 字段必须是已有来源的相对路径
- date 格式必须是 YYYY-MM-DD
```
#### A2. 创建 log.md
```markdown
# log.md — 知识库操作日志
## 格式规范
每条记录格式：[日期] [操作类型] [页面名] [操作人] [说明]
## 类型枚举
- CREATE: 新建页面
- UPDATE: 更新内容
- DELETE: 删除/归档
- INGEST: 批量摄入
- SYNC: Git 同步
- SCHEMA: 规范变更
## 记录
<!-- 起始记录 -->
[2026-05-20] [SCHEMA] [SCHEMA.md] [老何] 初始化领域规范
```
#### A3. 创建 raw/ 目录结构
```
raw/
├── papers/ # PDF + 提取的 markdown
├── articles/ # 网页剪藏 HTML/markdown
├── transcripts/ # 会议/课程转录
└── datasets/ # 数据集说明文档
```
**迁移任务**：将 sources/ 中的 PDF 和 HTML 分类移入 raw/，sources/ 专门放 AI 可读的 markdown 提炼版本。
---
### 阶段 B：规范化现有内容（1-2天）
#### B1. 统一 frontmatter 规范
现有页面 frontmatter 不一致，示例：
```yaml
# 现有（不统一）
---
title: 涌现
created: 2026-05-15
updated: 2026-05-15
type: concept
tags: [concept, complexity, physics, consciousness, systems-theory]
sources: [sources/涌现的本质是什么-万物本源说.html]
confidence: high
---
# 规范目标
---
type: concept
title: 涌现
created: 2026-05-15
updated: 2026-05-15
tags: [complexity, systems-theory, consciousness]
sources: [raw/articles/涌现的本质是什么-万物本源说.html]
confidence: high
claims:
- text: "大量简单个体遵循简单规则聚集互动，会自发诞生全新宏观属性"
source: "raw/articles/涌现的本质是什么-万物本源说.html"
confidence: 0.9
date: 2026-05-15
---
```
**任务**：遍历所有概念页和实体页，补全缺失的 frontmatter 字段。
#### B2. 修复 agent-digest 中的 entity 计数
当前 agent-digest 显示 `entity: 0`，但 entities/ 下有 2 个文件。
原因：frontmatter 中 entity 页面没有声明 `type: entity`。
---
### 阶段 C：建立 claims.jsonl（持续）
#### C1. 什么是 claims
Claims 是知识库中每个可校验的事实的结构化记录。
```jsonl
{"page": "concepts/涌现.md", "text": "涌现指大量简单个体遵循简单规则聚集互动，会自发诞生全新宏观属性", "source": "sources/涌现的本质是什么-万物本源说.html", "confidence": 0.9, "extracted": "2026-05-20"}
{"page": "entities/郭朝晖.md", "text": "郭朝晖曾任职于宝钢", "source": "sources/我的科研经历-反思与成长-郭朝晖.html", "confidence": 0.95, "extracted": "2026-05-20"}
```
#### C2. 提取策略
从现有页面提取：
1. 遍历所有概念页和实体页
2. 提取带有 `[引用]` 标记的句子
3. 关联到 sources/ 中的原始文件
4. 写入 `claims.jsonl`
新页面的 claims 在创建时同步生成。
---
### 阶段 D：Git 同步 + 冲突规避（阶段二同步做）
#### D1. Git 初始化
腾讯云 VM 端：
```bash
cd /home/obsidian/wiki
git init
git add -A
git commit -m "初始化 LLMWiki"
git remote add origin git@gitee.com:你的用户名/仓库名.git
git push -u origin main
```
#### D2. 分区写入规则（防冲突）
```markdown
## Git 同步的分区写入规则
| Agent | 可写目录 |
|-------|---------|
| main | 顶层 + concepts/ + entities/ + 03-工具/ |
| news | sources/ + raw/ |
| assistant | 04-Tools/ + reports/ |
| research | syntheses/ + 06-学术研究/ |
| PC OpenCode | 全部（用户操作层） |
原则：
- 每个 Agent 有主要负责的目录
- 跨越分区写入前先检查 git status
- 冲突时：最后提交者负责解决
```
#### D3. 同步触发机制
```bash
# cron 任务：每30分钟自动同步
*/30 * * * * cd /home/obsidian/wiki && git pull --rebase && git push
```
---
## 四、基础设施清单
| 任务 | 优先级 | 工作量 | 依赖 |
|------|--------|--------|------|
| 创建 SCHEMA.md | 🔴 高 | 1小时 | 无 |
| 创建 log.md | 🔴 高 | 30分钟 | 无 |
| 创建 raw/ 目录 | 🔴 高 | 30分钟 | 无 |
| 规范化现有 frontmatter | 🟡 中 | 2-3小时 | SCHEMA.md |
| 迁移 sources/ 到 raw/ | 🟡 中 | 1-2小时 | raw/ 建立 |
| 建立 claims.jsonl | 🟡 中 | 2-3小时 | frontmatter 规范 |
| Git 初始化 + Gitee | 🔴 高 | 1小时 | Gitee 仓库地址 |
| 配置 cron 同步 | 🟡 中 | 30分钟 | Git 初始化 |
| 补充 entity index | 🟡 中 | 30分钟 | 无 |
---
## 五、下一步行动
### 今天可以做
1. **创建 SCHEMA.md** — 定义领域、实体类型、标签体系
2. **创建 log.md** — 建立操作日志
3. **创建 raw/ 目录** — 分离原始资料
### 本周可以做
1. 规范化所有现有页面的 frontmatter（7个概念页 + 2个实体页）
2. Git 初始化 + Gitee 关联
### 需要确认
1. **Gitee 仓库地址** — 云端 Git 初始化需要
2. **同步频率** — 30分钟自动还是手动触发？
3. **PC 端 Obsidian 版本** — 是否 1.12+，决定能否用 Obsidian CLI
tools/docs/homewiki/WSL使用指南.md
+117
View File
@@ -0,0 +1,117 @@
---
type: concept
subtype: technology
title: Windows Subsystem for Linux
created: 2026-05-20
updated: 2026-05-20
tags: [tool, workflow, Windows, Linux]
sources: ["https://docs.microsoft.com/zh-cn/windows/wsl/"]
confidence: high
---
# Windows 11 WSL 使用指南
> Windows Subsystem for Linux，Windows 11 内置的 Linux 子系统
## 简介
WSL 让你在 Windows 里直接运行 Linux 子系统，无需虚拟机或双系统。Win 11 自带 WSL2。
## 安装
```powershell
# PowerShell 以管理员身份运行
wsl --install
# 重启后自动完成 Ubuntu 安装
```
其他发行版：
```powershell
wsl --install -d Debian
wsl --install -d Ubuntu-22.04
wsl --list --online # 查看可用发行版
```
## WSL1 vs WSL2
| 特性 | WSL1 | WSL2 |
|------|------|------|
| 架构 | Linux ELF 二进制翻译 | 完整 Linux 内核虚拟机 |
| 性能（文件系统 I/O） | 快 | 更快（跨系统访问稍慢） |
| GPU/CUDA | 不支持 | 支持 |
| 系统调用兼容性 | 少数不支持 | 几乎完全兼容 |
| 内存占用 | 更小 | 动态分配 |
日常开发推荐 **WSL2**。
## 常用命令
```powershell
wsl --status # 查看状态
wsl --list -v # 列出已安装的发行版
wsl -d Ubuntu # 启动指定发行版
wsl --shutdown # 关闭所有 WSL（重置）
wsl --update # 更新 WSL 内核
wsl -e cat /etc/os-release # 不进入 Shell 直接执行命令
```
Windows 终端直接操作 Linux 文件：
```bash
wsl ls ~/
```
## 文件互访
| 方向 | 路径 |
|------|------|
| Linux → Windows | `cd /mnt/c/Users/你的用户名` |
| Windows → Linux | `\\wsl$\Ubuntu\home\username` |
## 常用场景
### 1. 开发环境
- 使用 Linux 原生工具链（bash, git, ssh, vim）
- Node.js / Python / Go 开发
- 不用纠结 Windows 路径问题
### 2. 容器 & DevOps
- Docker Desktop 底层用 WSL2 运行
- 直接在 Linux 环境打包/测试
- Kubernetes / Docker 编排
### 3. 机器学习 / AI
- WSL2 + CUDA GPU 加速
- 跑 TensorFlow / PyTorch 训练
- 用 Ollama 本地跑 LLM
### 4. 服务器管理
- SSH 远程连接服务器
- 跑 Shell 脚本 / Cron 定时任务
- 使用 Ansible / Terraform 管理 Infra
### 5. 学习 Linux
- 零成本体验 Linux 环境
- 熟悉命令行 / 系统管理
- 无破坏 Windows 的风险
## 核心优势
| 优势 | 说明 |
|------|------|
| 性能 | 直接调用 Windows 内核，接近原生 Linux 效率 |
| 资源 | 比虚拟机轻量，内存/磁盘占用小 |
| 互通 | 与 Windows 文件系统无缝互操作 |
| 终端 | 用 Windows Terminal 体验原生 Linux 终端 |
| 开发 | 直接用 Linux 工具链 |
| GPU 支持 | WSL2 支持 GPU 加速，可跑 CUDA/机器学习 |
## 注意事项
- **版本**：Win 11 自带 WSL2，Win 10 需要 2004+ 且开启虚拟机平台
- **数据**：Linux 文件尽量放 WSL 内部，跨系统 I/O 有性能损耗
- **杀毒软件**：部分 AV 会显著拖慢 WSL2 文件系统，必要时加白
## 参考
- [WSL 官方文档](https://docs.microsoft.com/zh-cn/windows/wsl/)
tools/docs/homewiki/markitdown-wiki-integration.md
+60
View File
@@ -0,0 +1,60 @@
# MarkItDown + Wiki 集成
## 快速开始
```bash
# 转换文件并加入Wiki
~/.openclaw/workspace/04-Tools/wiki-ingest.sh document.pdf
# 指定Wiki页面名
~/.openclaw/workspace/04-Tools/wiki-ingest.sh document.pdf 我的文档
# 直接使用markitdown
~/.venv/markitdown/bin/markitdown file.pdf -o output.md
```
## 支持格式
| 格式 | 说明 |
|------|------|
| PDF | 文档、扫描件 |
| DOCX/XLSX/PPTX | Office文档 |
| 图片 | EXIF + OCR |
| 音频 | EXIF + 转录 |
| HTML | 网页 |
| EPUB | 电子书 |
| CSV/JSON/XML | 数据文件 |
## 依赖
- MarkItDown: `~/.venv/markitdown/bin/markitdown`
- 虚拟环境: `~/.venv/markitdown`
## 安装
```bash
python3 -m venv ~/.venv/markitdown
~/.venv/markitdown/bin/pip install 'markitdown[all]'
```
## Wiki结构
```
~/.openclaw/wiki/
├── concepts/ # 概念文档
├── methods/ # 方法论
├── examples/ # 案例
└── index/ # 索引
```
## 工作流
1. 用户发送文件（PDF/Word/Excel等）
2. Agent使用MarkItDown转换
3. 提取关键内容整理成Wiki格式
4. 添加frontmatter元数据
5. 保存到对应分类目录
---
*最后更新：2026-04-14*
tools/docs/homewiki/多Agent协作-OpenClaw实际配置核实报告.md
+228
View File
@@ -0,0 +1,228 @@
# OpenClaw 多 Agent 协作方案：实际配置核实
## 核实结论
原分析报告有若干关键错误，以下基于实际配置数据修正。
---
## 一、实际系统配置
### 1.1 Agent 现状（实际）
| Agent ID | 名称 | 工作区 | 状态 |
|-----------|------|--------|------|
| main | 主代理 | /root/.openclaw/workspace | ✅ 活跃 |
| news | 新闻助手 | /root/.openclaw/workspace-news | ✅ 活跃 |
| assistant | 个人助理 | /root/.openclaw/workspace-assistant | ✅ 活跃 |
| research | 研究助手 | /root/.openclaw/workspace-research | ✅ 活跃 |
| weixin2 | 小新 | /root/.openclaw/agents/weixin2 | ⚠️ 有目录但未入 config |
| zz | - | /root/.openclaw/agents/zz | ❌ 未配置 |
**原分析错误**：报告说"6个Agent"，实际活跃的4个。weixin2 和 zz 有目录但不在活跃配置里。
### 1.2 agentToAgent（已确认开启）
```yaml
tools:
agentToAgent:
enabled: true
allow: ["main", "news", "assistant", "research"]
```
**好消息**：多 Agent 通信已经启用，不需要额外配置。
---
## 二、向量检索实际配置
### 2.1 记忆搜索配置
```yaml
memorySearch:
provider: openai # OpenAI 兼容接口
enabled: true
model: embedding-3 # GLM embedding-3 模型
remote:
baseUrl: https://open.bigmodel.cn/api/paas/v4
```
**结论**：向量检索已配置，通过 BigModel CN API 的 embedding-3 实现，不是 SQLite。原分析"70%相似度"修正为 80%。
### 2.2 LanceDB-pro 状态
```
config.yaml 配置了 memory-lancedb-pro 插件
但 /root/.openclaw/memory/lancedb-pro/ 目录是空的
插件已配置但未实际启用本地向量存储
```
---
## 三、知识库实际配置（双 Wiki 架构）
系统存在 **两套 Wiki**，需要区分：
| 位置 | 类型 | 用途 |
|------|------|------|
| /root/.openclaw/wiki/ | OpenClaw memory-wiki | Agent 记忆层，bridge 模式 |
| /home/obsidian/wiki/ | 标准 Obsidian vault | 你的主知识库，Obsidian 桌面端用 |
### 3.1 OpenClaw wiki（Agent 用）
```
wiki/
├── concepts/ # 概念页
├── entities/ # 实体页
├── sources/ # 原始资料
├── reports/ # 报告
├── syntheses/ # 综合
├── main/ # 主代理子空间
├── index.md
├── WIKI.md
└── AGENTS.md
```
- vault mode: bridge（连接外部 Obsidian）
- render mode: obsidian
- search corpus: all
### 3.2 Obsidian vault（你本地用）
/home/obsidian/wiki/ - 这是你日常在 Obsidian 里用的笔记库。
### 3.3 共享知识库
```
workspace-shared/
├── 01-公共知识/
├── 02-协作记录/
├── 03-资源库/
└── README.md
```
README 明确定义了使用规则：只读优先、分 Agent 写入不同文件、定期清理。
---
## 四、Git 同步现状
### 4.1 PC 端已有同步脚本
`/root/.openclaw/workspace/Obsidian/sync-gitea.ps1` - PowerShell 脚本，功能：
- 检测本地变更 → git add/commit
- git pull 远程
- 检测冲突（发现冲突则退出告警）
- git push
### 4.2 腾讯云端现状
**尚未配置 Git 同步**。云端 VM 的 /home/obsidian/wiki/ 没有初始化 Git，也没有关联 Gitee。
### 4.3 风险重新评估
| 风险 | 原方案 | 实际问题 |
|------|--------|---------|
| 同时写入冲突 | "使用文件锁或分区存储" | sync-gitea.ps1 只检测冲突后退出，没有自动解决 |
| 冲突通知 | 未提及 | 冲突时脚本 exit 2，但谁来处理？ |
---
## 五、Coding Subagent 现状
```
/root/.openclaw/subagents/runs.json
→ {"version": 2, "runs": {}}
```
**subagent 机制存在，但目前没有配置任何 subagent。**
原分析推荐用 `openclaw subagent create` 创建 coding subagent，但：
- openclaw 命令本身有权限问题（/root/.local/share/pnpm/openclaw Permission denied）
- 没有找到 `subagent create` 的实际命令文档
- subagent 机制和 workspace-agent 是两套系统
**建议**：先用现有的 assistant agent 承担 coding 任务，不一定要单独建 subagent。
---
## 六、关键修正汇总
| 项目 | 原分析结论 | 实际核实结论 |
|------|-----------|------------|
| 活跃 Agent 数量 | 6个 | 4个（main/news/assistant/research） |
| agentToAgent | "需要配置" | ✅ 已启用 |
| 向量数据库 | SQLite 70%相似度 | 有 embedding-3 向量搜索，80% |
| Wiki 结构 | 一套 | 两套（OpenClaw wiki + Obsidian vault） |
| 共享知识库 | "需要创建" | workspace-shared 已存在 |
| Git 同步 | "需要开发" | PC 端脚本已有，云端未配置 |
| coding subagent | "用命令创建" | subagent 机制空，命令未验证 |
---
## 七、修正后的分阶段方案
### 阶段一：验证多 Agent 协作（1-2天）
**目标**：验证 agentToAgent 委派流程
现有条件已满足，只需写 SOUL.md 协作规则。
```
阶段一可以立即执行，不需要任何配置变更
```
### 阶段二：建立云端 Git 同步（2-3天）
```
1. 腾讯云 VM 上初始化 Git（/home/obsidian/wiki/ → git init）
2. 关联 Gitee 仓库（和 PC 端同一仓库）
3. 配置 cron 自动同步（每30分钟）
4. 添加冲突检测脚本
```
### 阶段三：完善 Wiki 体系（持续）
```
1. 补全 /home/obsidian/wiki/ 的 LLMWiki 元文件（SCHEMA.md, index.md, log.md）
2. 将 wiki-vault-maintainer skill 的规范落地到 Obsidian
3. 统一两套 Wiki 的边界和使用规则
```
### 阶段四：Coding 能力建设（如果需要）
```
方案A：改造 assistant agent，给它写专门的 SOUL.md 增加 coding 职责
方案B：等 subagent 机制验证后再迁过去
```
---
## 八、立即可执行的行动
### 今天可以做
1. **给 main agent 写 SOUL.md**，加入委派规则
2. **验证 agentToAgent** 是否真的工作：向 main 发消息委派给 news，看能否通信
### 本周可以做
1. 初始化云端 wiki 的 Git：进入 /home/obsidian/wiki/ → git init → 关联 Gitee
2. PC 端和云端同时配置 cron 同步
3. 写 workspace-shared/02-协作记录/ 里的协作规则文档
### 需要先确认的
1. Gitee 仓库地址是什么？
2. weixin2 和 zz 这两个 agent 还要不要激活？
---
## 九、风险项重新评估
| 风险 | 可能性 | 影响 | 应对 |
|------|--------|------|------|
| Git 同步冲突 | 高 | 中 | 明确各端写入分区，发生冲突告警人工处理 |
| weixin2/zz agent 冲突 | 中 | 低 | 明确不激活或删除 |
| 两套 Wiki 混乱 | 中 | 高 | 明确边界：OpenClaw wiki 是 Agent 记忆层，Obsidian 是用户交互层 |
| subagent 命令不可用 | 高 | 中 | 先用 assistant agent 试，不等 subagent |
tools/docs/homewiki/新安装技能使用指南.md
+326
View File
@@ -0,0 +1,326 @@
# 新安装技能使用指南
> 创建时间: 2026-04-28
> 服务器: 腾讯云轻量 Ubuntu
---
## 📋 目录
1. [安全扫描类](#安全扫描类)
2. [系统监控类](#系统监控类)
3. [磁盘清理类](#磁盘清理类)
4. [Web服务类](#web服务类)
5. [腾讯云服务类](#腾讯云服务类)
6. [笔记Wiki类](#笔记wiki类)
---
## 安全扫描类
### 🔒 skill-vetter
**功能**: 安装前安全扫描，防止"技能投毒"
**使用场景**:
- 安装任何第三方技能前必用
- 扫描已有技能的安全隐患
- 检查代码中的 Red Flags
**使用方法**:
```
询问我: "用 skill-vetter 扫描 xxx"
```
**检查项目**:
- ❌ eval/exec 滥用
- ❌ 未经授权访问 .ssh/
- ❌ 凭据窃取模式
- ❌ 外部 curl/wget 下载
- ❌ Base64 混淆代码
**风险等级**:
| 等级 | 含义 | 操作 |
|------|------|------|
| 🟢 LOW | 低风险 | 可直接安装 |
| 🟡 MEDIUM | 中风险 | 需完整代码审查 |
| 🔴 HIGH | 高风险 | 需人工确认 |
| ⛔ EXTREME | 极高风险 | 禁止安装 |
---
## 系统监控类
### 📊 system-resource-monitor
**功能**: CPU/内存/磁盘/运行时监控
**使用场景**:
- 查看服务器运行状态
- 排查性能问题
- 定期健康检查
**使用方法**:
```
询问我: "查看系统状态" 或 "系统资源监控"
```
**监控指标**:
| 指标 | 说明 |
|------|------|
| Uptime | 系统运行时长 |
| Load Average | 1/5/15分钟负载 |
| Memory | RAM 和 Swap 使用 |
| Disk | 根分区容量和使用率 |
**当前服务器状态示例**:
```
Uptime: 23 hours, 52 minutes
System Load: 1.59, 1.52, 1.54
Memory Usage: 1.4Gi / 1.9Gi (74%)
Swap Usage: 1.2Gi / 8.0Gi (15%)
Disk Usage: 27G / 40G (70%)
```
---
## 磁盘清理类
### 🧹 diskclean
**功能**: AI辅助磁盘扫描和清理
**使用场景**:
- 磁盘空间不足时
- 定期维护清理
- 清理 Python/node_modules 等缓存
**使用方法**:
```bash
# 扫描
diskclean scan
# 预览清理（dry run）
diskclean clean --dry
# 执行清理
diskclean clean --confirm
```
**清理分层**:
| 分层 | 说明 | 自动删除 |
|------|------|----------|
| **Safe Tier** | 白名单 + 超过7天 | ✅ 是 |
| **Suggest Tier** | 其他所有项 | ❌ 需确认 |
**可清理项目**:
| 类别 | 年龄门槛 | 可自动清理 |
|------|----------|------------|
| node_modules | 7天 | ✅ |
| Python 缓存 | 7天 | ✅ |
| 构建输出 | 7天 | ✅ |
| Docker | - | ❌ |
| 大文件下载 | - | ❌ |
**安全规则**:
- ❌ 永不删除 `$HOME` 之外的文件
- ❌ 永不删除 `.git` 目录
- ❌ 永不删除源代码/文档
- ❌ 永不不带 `--dry` 直接执行
**当前扫描结果**:
- 总可回收: ~2.9 GB
- 主要来自: `.venv/` Python虚拟环境
---
## Web服务类
### 🌐 nginx-config-creator
**功能**: Nginx 反向代理配置、验证、回滚
**使用场景**:
- 配置新的网站反代
- 修改现有 Nginx 配置
- SSL 证书配置
**使用方法**:
```
询问我: "帮我配置 Nginx 反向代理"
```
**功能**:
- 配置生成
- 配置验证
- 语法检查
- 回滚支持
---
### 🌐 agent-browser
**功能**: 无头浏览器自动化
**使用场景**:
- 网页截图
- 表单自动填写
- 网页数据抓取
- UI自动化测试
**使用方法**:
```
询问我: "帮我截图 xxx 网页"
```
---
## 腾讯云服务类
### ☁️ tencentcloud-lighthouse-skill
**功能**: 腾讯云轻量应用服务器管理
**使用场景**:
- 查看服务器信息
- 管理应用市场
- 监控服务器状态
**使用方法**:
```
询问我: "查看轻量服务器状态"
```
---
### ☁️ tencent-cos-skill
**功能**: 腾讯云对象存储管理
**使用场景**:
- 上传/下载文件
- 管理存储桶
- 配置访问权限
**使用方法**:
```
询问我: "上传文件到 COS"
```
---
### 📄 tencent-docs
**功能**: 腾讯文档集成
**使用场景**:
- 读取腾讯文档
- 创建新文档
- 文档同步
**使用方法**:
```
询问我: "读取腾讯文档 xxx"
```
---
## 笔记Wiki类
### 📝 obsidian 系列
**已安装组件**:
| 组件 | 功能 |
|------|------|
| obsidian | 核心集成 |
| obsidian-cli-official | Obsidian CLI 工具 |
| obsidian-direct | 直接访问 |
| obsidian-bases | 知识库基础 |
| obsidian-daily | 每日笔记 |
| obsidian-markdown | Markdown 处理 |
**使用场景**:
- 创建和管理笔记
- 知识库维护
- 每日复盘
**使用方法**:
```
询问我: "创建 Obsidian 笔记"
```
---
### 📝 wiki-local / wiki-vault-maintainer
**功能**: 本地 Wiki 维护
**使用场景**:
- 维护知识库结构
- 清理孤立页面
- 索引管理
---
## 🔧 快速参考
### 推荐安装顺序（新服务器）
```
1. 安全底座
skill-vetter
2. 系统监控
system-resource-monitor
3. 磁盘清理
diskclean
4. Nginx 配置
nginx-config-creator
5. 腾讯云服务
tencentcloud-lighthouse-skill
tencent-cos-skill
```
### 常用命令
| 任务 | 命令/询问 |
|------|-----------|
| 查看系统状态 | "系统资源监控" |
| 扫描磁盘 | "diskclean scan" |
| 预览清理 | "diskclean clean --dry" |
| 安全扫描技能 | "用 skill-vetter 扫描 xxx" |
| 配置 Nginx | "nginx-config-creator" |
---
## 📊 已安装技能清单
**总计**: 43 个技能
| 类别 | 数量 | 代表技能 |
|------|------|----------|
| 🌐 网络/浏览器 | 4 | agent-browser, brave-search |
| ☁️ 云服务 | 3 | 腾讯云系列 |
| 📝 笔记/Wiki | 7 | obsidian系列 |
| 🧹 系统工具 | 3 | diskclean, nginx-config |
| 📚 学术 | 2 | arxiv, arxiv-watcher |
| 📰 新闻 | 3 | cctv-news-fetcher |
| 🔍 搜索 | 4 | tavily, brave, desearch |
| 🖼️ 媒体 | 3 | ima-image-ai, ima-tts-ai |
---
## ⚠️ 安全提醒
1. **所有技能均已通过安全扫描** ✅
2. **腾讯云技能需要配置凭据才可用**
3. **ima-* 系列需要 IMA_API_KEY 环境变量**
4. **brave-search 需要 BRAVE_SEARCH_API_KEY**
---
*最后更新: 2026-04-28*