Auto-sync: 2026-04-23 00:02

2026-04-23 00:02:55 +08:00
parent 377d32cd39
commit e823c78a9b
62 changed files with 2383 additions and 10 deletions
--- a/Project/fonrey/PRD/房源管理模块PRD.md
+++ b/Project/fonrey/PRD/房源管理模块PRD.md
@@ -1,8 +1,8 @@
 # PRD: 房源管理模块
 **状态**: Draft  
 **作者**: 产品经理  
-**最后更新**: 2026-04-22  
-**版本**: 1.0  
+**最后更新**: 2026-04-22（v1.1 新增别墅/商铺/商住/写字楼/其他房源类型）  
+**版本**: 1.1  
 **所属系统**: Fonrey 房产经纪管理系统  
 **关联模块**: 客源管理、组织人事管理、权限管理

@@ -45,7 +45,7 @@

 ## 3. 非目标（本期不做）

- 不包含商业地产（商铺、办公室、厂房）房源管理，本期仅覆盖住宅类
+- 商业地产类（商铺、商住、写字楼、其他）房源录入功能为**低优先级**，在住宅类（住宅、别墅）完成并稳定后方可排期开发
 - 不包含地图找房的底层地图服务建设（地图组件集成另行规划）
 - 不包含房源对外门户网站展示（营销推广为独立模块）
 - 不包含 AI 估价引擎的自研（可集成第三方价格解读服务）
@@ -302,6 +302,163 @@
 | 号码方 | 默认为当前用户，可修改 |
 | 出售方 | 默认为当前用户，可修改 |

+---
+
+### 5.3.x 房源类型体系与优先级
+
+系统支持 6 种房源类型，录入表单在通用结构基础上各有差异字段。按业务重要性和开发优先级排序如下：
+
+| 优先级 | 房源类型 | 适用场景 | 开发阶段 |
+|--------|----------|----------|----------|
+| **P0（必须）** | 住宅 | 普通住宅、花园洋房，最高频业务 | v1 上线 |
+| **P1（高）** | 别墅 | 联排/独栋/双拼/叠加别墅 | v1 上线 |
+| **P2（低）** | 商住 | 商住两用类物业 | v2 排期 |
+| **P2（低）** | 商铺 | 临街/商场/底商/综合体铺位 | v2 排期 |
+| **P2（低）** | 写字楼 | 办公楼层/整层出租出售 | v2 排期 |
+| **P2（低）** | 其他 | 车库/车位/平房/四合院/仓库/厂房/地皮等 | v2 排期 |
+
+> **优先级说明**：P2 类型（商住/商铺/写字楼/其他）在 v1 版本中**不开发**，但需在"新增房源"入口预留类型选择器的 UI 占位，选择后提示"该类型即将上线，敬请期待"，避免后期大规模改动入口设计。
+
+---
+
+#### 5.3.2 各房源类型差异字段说明
+
+以下以「新增住宅」为基准（通用字段不重复列出），仅标注各类型的**新增字段**或**差异字段**。
+
+##### ① 新增别墅（P1 — v1 上线）
+
+与住宅表单高度相似，核心差异点：
+
+| 差异字段 | 变化说明 |
+|----------|----------|
+| **用途** | 选项变更为：联排别墅 / 独栋别墅 / 双拼别墅 / 叠加别墅（替换住宅的"普通住宅/花园洋房"） |
+| 其他字段 | 与住宅完全一致（核心信息/业主/基础信息/交易信息/相关方） |
+
+> 别墅与住宅共用同一套表单框架，用途字段枚举值不同，后端可通过房源类型参数控制渲染，开发成本低。
+
+---
+
+##### ② 新增商铺（P2 — v2 排期）
+
+商铺为纯商业物业，字段差异较大：
+
+**核心信息区块 — 新增/差异字段**：
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| **用途** | 无选项（字段空白） | — | 商铺无细分用途，该行保留占位但无输入项 |
+| **开间** | 数字输入 | 否 | 单位：米，商铺特有尺寸维度 |
+| **进深** | 数字输入 | 否 | 单位：米，商铺特有尺寸维度 |
+| **层高** | 数字输入 | 否 | 单位：米，商铺特有尺寸维度 |
+| **位置** | 单选 | 是 | 临街 / 商场 / 小区 / 底商 / 商业综合体 |
+
+**无交易信息区块**：商铺表单仅含「房源核心信息 / 业主联系人 / 基础信息 / 相关方」4 个区块，**没有"交易信息" Tab**（无房本年限等住宅特有交易字段）。
+
+---
+
+##### ③ 新增商住（P2 — v2 排期）
+
+商住两用物业，字段结构与住宅高度相似，核心差异：
+
+| 差异字段 | 变化说明 |
+|----------|----------|
+| **用途** | 字段保留但选项为空（待业务方定义商住用途枚举值） |
+| **户型** | 与住宅一致（室/厅/卫/厨/阳台） |
+| **交易信息** | 仅保留「房本年限」，其余交易字段（产权年限/产权性质/唯一住房等）不展示 |
+
+> 商住介于住宅与商铺之间，本质是住宅户型 + 精简版交易信息的组合。
+
+---
+
+##### ④ 新增写字楼（P2 — v2 排期）
+
+写字楼为纯办公物业，表单最为精简：
+
+**表单区块**：房源核心信息 / 业主联系人 / 基础信息 / 相关方（**无"交易信息" Tab**，与商铺一致）
+
+**核心信息区块 — 差异字段**：
+
+| 字段 | 变化说明 |
+|------|----------|
+| **用途** | 字段保留但选项为空（待业务定义） |
+| **户型** | **无户型字段**（写字楼无室/厅概念） |
+| **建筑面积** | 保留，必填 |
+| **售价** | 保留 |
+
+> 写字楼表单是所有类型中字段最少的，核心信息区块仅有：状态/属性/用途/小区名称/户室号/楼层/建筑面积/售价。
+
+---
+
+##### ⑤ 新增其他（P2 — v2 排期）
+
+"其他"类型覆盖所有非标准物业形态，是兜底类型：
+
+**核心信息区块 — 用途枚举值（与其他类型最大差异）**：
+
+| 用途选项 | 说明 |
+|----------|------|
+| 车库 | 地下/地上车库 |
+| 车位 | 停车位 |
+| 平房 | 平房/老式民居 |
+| 四合院 | 传统院落式住宅 |
+| 仓库 | 储存类物业 |
+| 厂房 | 工业厂房 |
+| 地皮 | 土地/地块 |
+| 铺厂 | 商铺+厂房复合 |
+| 网点 | 金融网点/营业厅类 |
+| 写厂 | 写字楼+厂房复合 |
+
+**表单结构**：与住宅完全一致（含交易信息 Tab，有房本年限字段），但用途枚举值替换为上述列表，且**有户型字段**（室/厅/卫/厨/阳台）。
+
+---
+
+#### 5.3.3 房源类型选择入口设计
+
+**新增房源** 按钮点击后，先弹出类型选择步骤（不直接进入表单）：
+
+```
+选择房源类型
+┌──────────┬──────────┬──────────┐
+│   住宅   │   别墅   │  商住    │
+│ （P0）   │ （P1）   │ 即将上线 │
+├──────────┼──────────┼──────────┤
+│   商铺   │  写字楼  │   其他   │
+│ 即将上线 │ 即将上线 │ 即将上线 │
+└──────────┴──────────┴──────────┘
+```
+
+- P0/P1 类型（住宅/别墅）：可点击，进入对应录入表单
+- P2 类型（商住/商铺/写字楼/其他）：点击后 Toast 提示"该房源类型即将上线，敬请期待"，不跳转表单
+- v2 上线后，P2 类型逐步解锁，无需改动入口结构
+
+---
+
+#### 5.3.x+1 各类型字段对比总览
+
+| 字段 | 住宅 | 别墅 | 商住 | 商铺 | 写字楼 | 其他 |
+|------|------|------|------|------|--------|------|
+| 状态 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 房源属性（公/私盘） | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 用途 | 住宅/洋房 | 联排/独栋等 | 空（待定） | 无选项 | 空（待定） | 车库/车位等10项 |
+| 小区名称 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 户室号 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 楼层 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 户型（室/厅/卫/厨） | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ |
+| 建筑面积 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 售价 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 开间/进深/层高 | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
+| 位置（商铺专属） | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
+| 朝向 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 装修 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 电梯 | ✅（编辑时） | ✅（编辑时） | — | — | — | — |
+| 建成年代 | ✅（编辑时） | ✅（编辑时） | — | — | — | — |
+| 学校 | ✅（编辑时） | — | — | — | — | — |
+| 交易信息 Tab | ✅（完整） | ✅（完整） | 仅房本年限 | ❌ | ❌ | ✅（完整） |
+| 业主/联系人 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| 相关方 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+---
+
 #### 5.3.2 编辑房源

 - 编辑页面结构与新增一致，数据预填充
@@ -521,6 +678,11 @@
 - 房源列表（出售视图）：`Project/fonrey/sreenshots/房源/房源列表.png`
 - 全部房源视图：`Project/fonrey/sreenshots/房源/全部房源.png`
 - 新增住宅表单：`Project/fonrey/sreenshots/房源/增房/新增住宅.png`
+- 新增别墅表单：`Project/fonrey/sreenshots/房源/增房/新增别墅.png`
+- 新增商铺表单：`Project/fonrey/sreenshots/房源/增房/新增商铺.png`
+- 新增商住表单：`Project/fonrey/sreenshots/房源/增房/新增商住.png`
+- 新增写字楼表单：`Project/fonrey/sreenshots/房源/增房/新增写字楼.png`
+- 新增其他表单：`Project/fonrey/sreenshots/房源/增房/新增其他.png`
 - 编辑房源：`Project/fonrey/sreenshots/房源/增房/编辑房源.png`
 - 上传图片：`Project/fonrey/sreenshots/房源/增房/上传图片.png`
 - 写跟进：`Project/fonrey/sreenshots/房源/增房/写跟进.png`
--- a/openclaw/每日复盘/2026-04-22.md
+++ b/openclaw/每日复盘/2026-04-22.md
@@ -0,0 +1,17 @@
+## 【yunhan】云瀚 每日复盘 - 2026-04-22
+
+### 当日活动
+- **Cron 任务**: 每日复盘任务正常触发
+- **活动类型**: 无活动
+
+### 复盘内容
+今天 yunhan 没有收到任何 Telegram 消息或任务，Django Admin 日报显示为空会话记录。
+
+### 观察
+- yunhan 作为 Cloud Ops agent，主要负责监控任务
+- 今天没有触发任何监控告警或定时任务
+
+### 元数据
+- **日期**: 2026-04-22
+- **Agent**: yunhan
+- **来源**: cron-task daily-review
--- a/wiki/concepts/AmbientMessageMonitoring.md
+++ b/wiki/concepts/AmbientMessageMonitoring.md
@@ -0,0 +1,39 @@
+---
+title: "Ambient Message Monitoring"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Ambient Message Monitoring
+
+## Definition
+Agent 被动监听消息流（iMessage/SMS/Telegram 等），在识别到可执行模式（如预约确认、承诺回复、活动变更）时自动采取行动，无需用户主动请求。
+
+## How It Works
+1. **定时轮询**：每 N 分钟（典型 15 分钟）检查新消息
+2. **模式识别**：检测预约类文本（如 "confirmed for...", "moved to Saturday at 3pm"）
+3. **自动行动**：创建日历事件 → 添加行车缓冲 → 推送确认消息
+4. **承诺追踪**：检测承诺类文本（如 "I'll send that by Friday"）→ 创建待办提醒
+
+## Key Properties
+- **被动**：Agent 主动感知，用户无需发起请求
+- **上下文感知**：理解对话意图，而非机械关键词匹配
+- **行动闭环**：从识别 → 创建事件 → 通知伴侣，全自动完成
+
+## Comparison
+| | Active（主动请求） | Ambient（环境感知） |
+|---|---|---|
+| 触发方式 | 用户说"创建日历事件" | Agent 自动检测到预约后行动 |
+| 用户负担 | 高（需主动指令） | 低（零摩擦） |
+| 覆盖面 | 只覆盖被请求的事项 | 覆盖所有对话中的可执行项 |
+
+## Related Concepts
+- [[Morning Briefing]]：Ambient Monitoring 的输出之一
+- [[Cron Job]]：Ambient Monitoring 的底层调度机制
+- [[Second Brain]]：Ambient Monitoring 的认知增强效果
+
+## Related Sources
+- [[family-calendar-household-assistant]] — 主要来源，牙医预约短信自动创建日历事件案例
+- [[n8n-workflow-orchestration]] — n8n Webhook 触发机制对比
--- a/wiki/concepts/Audit-Trail.md
+++ b/wiki/concepts/Audit-Trail.md
@@ -0,0 +1,27 @@
+---
+title: "Audit-Trail"
+type: concept
+tags: [observability, compliance, n8n, security]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Audit Trail
+- 审计轨迹
+
+## Definition
+
+系统自动记录每次工作流执行的完整输入、输出和状态信息，形成可追溯的执行历史。在 n8n 中，每次工作流触发都会记录执行数据，无需额外配置即可获得完整的操作审计日志。
+
+## Why It Matters
+- **合规需求**：SOC2、ISO 27001 等框架要求记录所有敏感操作
+- **故障排查**：API 调用失败时可快速定位问题
+- **Agent 行为审查**：确认 Agent 实际发送了什么数据
+- **数据回放**：失败的执行可重新触发
+
+## Connections
+- [[Visual-Debugging]] — 可视化调试依赖审计数据
+- [[Webhook-Proxy-Pattern]] — 自动为 Webhook 调用生成审计记录
+- [[n8n]] — 提供开箱即用的工作流执行审计能力
+- [[Defense-in-Depth]] — 审计轨迹是纵深防御的重要组成部分
--- a/wiki/concepts/Brain-Dump.md
+++ b/wiki/concepts/Brain-Dump.md
@@ -0,0 +1,60 @@
+---
+title: "Brain Dump"
+type: concept
+tags: [knowledge-management, agent-memory, prompting]
+sources: [overnight-mini-app-builder, second-brain]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Brain Dump（脑暴倾倒）是一种将所有目标、使命、任务和上下文一次性倒入 AI Agent 记忆系统的操作方式。目的是给 Agent 足够的背景信息，使其能够自主生成高质量的每日可执行任务，而非被动等待指令。
+
+## Aliases
+
+- 脑暴倾倒
+- 目标倾倒
+- Context Injection
+
+## How It Works
+
+用户通过消息/短信/Telegram 将所有目标一次性告诉 Agent：
+
+```text
+Here are my goals and missions. Remember all of this:
+
+Career:
+- Grow my YouTube channel to 100k subscribers
+- Launch my SaaS product by Q3
+- Build a community around AI education
+
+Personal:
+- Read 2 books per month
+- Learn Spanish
+
+Business:
+- Scale revenue to $10k/month
+- Build partnerships with 5 companies in my space
+- Automate as much of my workflow as possible
+
+Use this context for everything you do going forward.
+```
+
+## Key Insight
+
+> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be."
+
+Brain Dump 是整个 [[overnight-mini-app-builder]] 工作流中**最重要的一步**。它决定了 Agent 每日任务的相关性和价值。
+
+## Relationship to Second Brain
+
+- [[Second Brain]] — Brain Dump 是 Second Brain 捕获阶段的具体实践方式
+- [[overnight-mini-app-builder]] — 将 Brain Dump 作为自主任务生成的上下文输入
+- [[Cumulative Memory]] — Brain Dump 产生的上下文被 [[OpenClaw]] 永久记忆，随时间积累
+
+## Key Relationships
+
+- [[Cumulative Memory]] — Brain Dump 产生的上下文被 Agent 永久记忆
+- [[Second Brain]] — Brain Dump 是 Second Brain 捕获零摩擦理念的具体操作
+- [[Zero-Friction Capture]] — Brain Dump 强调用最自然的方式（发消息）完成捕获
+- [[overnight-mini-app-builder]] — 本概念的来源场景
--- a/wiki/concepts/Content-Hashing.md
+++ b/wiki/concepts/Content-Hashing.md
@@ -0,0 +1,50 @@
+---
+title: "Content Hashing (Incremental Indexing)"
+type: concept
+tags: [indexing, optimization, hash, incremental]
+sources: [semantic-memory-search]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- Content Hashing
+- 增量索引
+- Incremental Indexing
+- 内容哈希
+
+## Definition
+
+内容哈希是一种通过计算文档内容块的 SHA-256 哈希值来唯一标识内容的技术。当文档内容未变化时，哈希值保持不变，系统据此跳过已索引内容，仅处理新增或变更的内容块，从而实现增量索引，避免重复 Embedding API 调用。
+
+## How It Works
+
+```
+文档内容块 → SHA-256 哈希 → 内容指纹
+    ↓
+内容指纹 vs 已索引指纹 → 比对结果：
+  - 完全匹配 → 跳过（已存在，无需重新嵌入）
+  - 变化/新增 → 执行 Embedding 并存储向量
+```
+
+## Why SHA-256?
+
+- **确定性**：相同内容总是产生相同哈希，无误判
+- **抗碰撞**：SHA-256 的 256 位空间使碰撞概率可忽略不计
+- **快速**：哈希计算比 Embedding 快数个数量级，适合高频增量检查
+
+## Key Insight
+
+> "Smart dedup saves money. Each chunk is identified by a SHA-256 content hash. Re-running `index` only embeds new or changed content, so you can run it as often as you like without wasting embedding API calls." — memsearch
+
+## Benefits
+
+| 收益 | 说明 |
+|------|------|
+| **成本节省** | 避免重复 Embedding API 调用，节省 token 和费用 |
+| **速度提升** | 仅处理增量变化，索引重建时间大幅缩短 |
+| **幂等性** | 任意次数重新索引，结果一致 |
+| **原子性** | 内容块级别独立，无整体重写的开销 |
+
+## Connections
+- [[semantic-memory-search]] — memsearch 使用 SHA-256 内容哈希实现增量索引
+- [[memsearch]] — 内容哈希是 memsearch 增量索引的核心机制
--- a/wiki/concepts/Content-Ingestion.md
+++ b/wiki/concepts/Content-Ingestion.md
@@ -0,0 +1,42 @@
+---
+title: "Content Ingestion"
+type: concept
+last_updated: 2026-04-22
+---
+
+## Definition
+
+内容摄取（Content Ingestion）：将外部内容（网页、PDF、YouTube 字幕、推文等）通过自动化解析提取为结构化文本，并分块（Chunking）入库供检索系统使用的过程。是 [[Knowledge-Base-RAG]] 工作流的第一步——没有高质量的内容摄取，就没有可搜索的知识库。
+
+## Ingestion Pipeline
+
+```
+URL 输入 → 内容获取 → 格式解析 → 文本清洗 → 分块（Chunking）→ Embedding → 向量入库
+```
+
+## Supported Content Types
+
+| 类型 | 解析方式 | 挑战 |
+|------|----------|------|
+| 网页 | HTML 解析 / Firecrawl / Jina Reader | 广告/导航移除、JS 渲染内容 |
+| PDF | marker / pdfminer / PyMuPDF | 表格、多栏布局、扫描件 OCR |
+| YouTube | Transcript API / Whisper | 自动字幕质量、噪音处理 |
+| 推文/Tweet | Twitter API / 第三方抓取 | 字符限制、线程重组 |
+| Slack 消息 | Slack API | 富文本格式、附件分离 |
+
+## Chunking Strategies
+
+详见 [[Knowledge-Base-RAG]] 概念页。
+
+## Why It Matters
+
+Garbage in, garbage out——即使 Embedding 模型再强大，如果摄取内容充满噪音（广告、HTML 标签、格式乱码），检索质量也会大幅下降。好的摄取 pipeline 需要：
+1. 内容纯净（去广告/去导航/去脚注）
+2. 格式保留（标题层级、列表结构有助于理解）
+3. 元数据保留（URL、标题、日期、来源类型）
+
+## Connections
+
+- [[Knowledge-Base-RAG]] — Content Ingestion 是 RAG 工作流的第一个环节
+- [[Semantic-Search]] — 摄入的内容最终通过语义搜索被检索
+- [[web_fetch]] — 内容获取的工具技能
--- a/wiki/concepts/Credential-Isolation.md
+++ b/wiki/concepts/Credential-Isolation.md
@@ -0,0 +1,32 @@
+---
+title: "Credential-Isolation"
+type: concept
+tags: [security, credentials, agent-architecture]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Credential Isolation
+- 凭证隔离
+
+## Definition
+
+将 API 凭证（密钥、token）存储在 Agent 可控范围之外的系统中，确保 Agent 的工作环境无法直接访问敏感凭证，从而防止因 Agent 代码提交、错误输出或 Prompt Injection 导致凭证泄露。
+
+## Mechanism
+
+在 [[Webhook-Proxy-Pattern]] 中：
+- Agent 只持有 Webhook URL（例：`http://n8n:5678/webhook/my-workflow`）
+- API 密钥存储在 n8n 的 Credential Store 中
+- Agent 发送的 JSON payload 不包含任何密钥
+
+## Why It Matters
+- Agent 的代码、记忆、输出可能被提交到 Git 或暴露在日志中
+- 即使 Agent prompt 被泄露，攻击者也拿不到实际密钥
+- 凭证轮换可在 n8n 端独立完成，无需修改 Agent 提示词
+
+## Connections
+- [[Webhook-Proxy-Pattern]] — 凭证隔离的实现架构
+- [[Defense-in-Depth]] — 防御纵深策略的组成部分
+- [[Lockable-Workflow]] — 配合凭证隔离防止 Agent 修改调用逻辑
--- a/wiki/concepts/DuckDB.md
+++ b/wiki/concepts/DuckDB.md
@@ -0,0 +1,43 @@
+---
+title: "DuckDB"
+type: concept
+tags: ["database", "embedded", "sql", "analytics"]
+last_updated: 2026-04-22
+---
+
+## Overview
+嵌入式分析型数据库管理系统（Analytical DBMS），DenchClaw 的数据存储后端。完全嵌入进程、无服务器进程、无凭证、无网络依赖——只是一个文件。
+
+## Aliases
+- None
+
+## Definition
+DuckDB 是专为 OLAP（在线分析处理）优化的嵌入式 SQL 数据库。它是 SQLite 的分析型替代品，支持完整 SQL 语法，但针对聚合查询和大规模数据分析进行了优化。
+
+## Key Properties
+- **嵌入式**: 链接到应用程序进程，无需独立服务器
+- **零配置**: 无需安装、启动或维护数据库服务器
+- **无网络**: 数据在本地文件，无需远程连接
+- **完全 SQL**: 支持标准 SQL 语法（DML、DDL、子查询、窗口函数等）
+- **列式存储**: 针对分析查询优化（GROUP BY、JOIN、聚合）
+- **向量式执行**: CPU SIMD 加速批量数据处理
+
+## Why DuckDB for CRM
+DenchClaw 选择 DuckDB 作为嵌入式 CRM 数据库的理由：
+1. **最小体积**: 比 PostgreSQL/MySQL 等服务器数据库轻量得多
+2. **完全 SQL**: 保留关系型数据库的全部查询能力
+3. **无摩擦**: 无需管理服务器进程或连接字符串
+4. **高性能**: 分析查询性能优于 SQLite
+
+> "DuckDB is the sweet spot: Smallest, most performant embedded database that still supports full SQL. No server process, no credentials, no network — just a file."
+> — DenchClaw 核心设计哲学
+
+## Use Cases
+- [[DenchClaw]]: 本地 CRM 结构化数据存储
+- 分析型工作负载（OLAP）
+- 数据科学探索（pandas 集成）
+- 嵌入式分析功能
+
+## Related
+- [[DenchClaw]]: 使用 DuckDB 的 CRM 框架
+- [[File-System-First-UI]]: 与 DuckDB 配合的设计哲学
--- a/wiki/concepts/File-System-First-UI.md
+++ b/wiki/concepts/File-System-First-UI.md
@@ -0,0 +1,34 @@
+---
+title: "File-System-First UI"
+type: concept
+tags: ["design-pattern", "agentic", "ux", "openclaw"]
+last_updated: 2026-04-22
+---
+
+## Overview
+一种 Agent 原生 UI 设计范式——将所有 UI 配置、设置、过滤器、视图存储为文件系统中的文件（YAML/Markdown），使 AI Agent 可以像编辑代码一样自然地修改界面。
+
+## Definition
+传统 UI 依赖 API 或内部状态存储配置，Agent 需要通过 API 抽象层修改；而 File-System-First UI 直接让 Agent 读写配置文件，Agent 可以用相同的工具链（文件编辑、版本控制）操作 UI。
+
+## Key Insight
+> "Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
+> — [[DenchClaw]] 核心设计哲学
+
+## How It Works
+1. **配置文件即 UI**: 所有视图定义、过滤器设置、列配置存储为 `.yaml` / `.md` 文件
+2. **Agent 直接编辑**: Agent 使用标准文件编辑工具修改配置
+3. **UI 自动响应**: 前端监听文件系统变化，实时更新界面
+4. **版本控制**: 所有变更通过 Git 追踪，支持回滚和协作
+
+## Benefits
+- **No API abstraction**: Agent 不需要理解 API，直接操作原始数据
+- **Standard tools**: Agent 用同一套文件编辑技能操作 UI 和代码
+- **Version control**: UI 配置变更天然被 Git 追踪
+- **Reproducibility**: 配置即代码，环境可复现
+- **Transparency**: 所有变更可审计、可回滚
+
+## Related
+- [[DenchClaw]]: File-System-First UI 的典型实现
+- [[Chrome Profile Cloning]]: 配合实现无缝浏览器自动化
+- [[One-Command-Setup]]: 配套的安装哲学
--- a/wiki/concepts/File-Watcher.md
+++ b/wiki/concepts/File-Watcher.md
@@ -0,0 +1,55 @@
+---
+title: "File Watcher (Auto-Reindex)"
+type: concept
+tags: [automation, file-system, indexing, realtime]
+sources: [semantic-memory-search]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- File Watcher
+- 文件监视器
+- 文件监听
+- Auto-Reindex
+- 自动重建索引
+
+## Definition
+
+文件监视器是一种实时监控指定目录文件变化的机制，当文件被创建、修改或删除时，自动触发相应的索引更新操作。在语义搜索场景中，这意味着记忆文件的变更会即时反映到向量索引中，保持索引与源文档的同步，无需手动重新运行索引命令。
+
+## How It Works
+
+```
+文件系统事件 → 检测到变更 → 触发回调：
+  - 文件创建 → 计算哈希，Embedding，存入向量数据库
+  - 文件修改 → 重新计算哈希，更新向量数据库记录
+  - 文件删除 → 从向量数据库移除对应记录
+```
+
+## Implementation Patterns
+
+| 方式 | 工具 | 说明 |
+|------|------|------|
+| 轮询 | `watchdog` (Python) | 跨平台，跨语言，通用 |
+| 系统事件 | inotify (Linux) / FSEvents (macOS) / ReadDirectoryChangesW (Windows) | 高效，仅 Linux/macOS/Windows 原生 |
+| cron 批处理 | `*/5 * * * *` | 简单，不实时，适合低频场景 |
+| Webhook | Git post-commit hook | 适合 Git 管理的文档 |
+
+## Use Case in memsearch
+
+memsearch 的 `memsearch watch` 命令使用文件监视器自动追踪记忆目录变化：
+```bash
+memsearch watch ~/path/to/your/memory/
+# 持续监控，新增/修改文件自动触发增量索引
+```
+
+## Benefits
+
+- **实时同步**：索引始终反映最新文档状态
+- **零手动操作**：无需人工干预，忘记索引更新也不怕
+- **节省成本**：基于 [[Content Hashing]] 的增量机制，仅处理实际变化部分
+
+## Connections
+- [[semantic-memory-search]] — 文件监视器是 memsearch 保持索引实时的核心功能
+- [[memsearch]] — memsearch 内置文件监视器实现
+- [[Content Hashing]] — 文件监视器的增量触发依赖内容哈希比对
--- a/wiki/concepts/GitHub-Release-Monitoring.md
+++ b/wiki/concepts/GitHub-Release-Monitoring.md
@@ -0,0 +1,28 @@
+---
+title: "GitHub Release Monitoring"
+type: concept
+tags: []
+---
+
+## Definition
+GitHub Release 监控模式——通过 GitHub API 追踪指定仓库的 Release 发布动态，自动获取新版本更新信息并触发通知或工作流。
+
+## Implementation
+通过 GitHub API `GET /repos/{owner}/{repo}/releases` 获取仓库最新 Release，常见触发条件：
+- 新 Release 发布
+- 特定版本号（如 v1.0.0）
+- Pre-release 版本
+- Draft 版本
+
+## Environment Variables
+- `GITHUB_TOKEN` — GitHub 个人访问令牌，提升 API 速率限制（未认证 60 req/hr，认证 5000 req/hr）
+
+## Use Cases
+- [[multi-source-tech-news-digest]] — 监控 vLLM、LangChain、Ollama、Dify 等 19 个热门开源项目 Release
+- 开发者依赖更新通知
+- 安全漏洞补丁追踪
+
+## Related Concepts
+- [[Social-Media-Monitoring]] — 同属账号/项目级变更监控
+- [[Content-Automation]] — 监控到更新后的自动处理
+- [[Daily-Digest]] — 汇总多个仓库更新为每日摘要
--- a/wiki/concepts/HouseholdInventoryTracking.md
+++ b/wiki/concepts/HouseholdInventoryTracking.md
@@ -0,0 +1,47 @@
+---
+title: "Household Inventory Tracking"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Household Inventory Tracking
+
+## Definition
+Agent 维护家庭物资库存记录（JSON/数据库），追踪物品名称、数量、存放位置（冰箱/储藏室/地下室），支持多种输入方式（照片 OCR、文字更新、小票识别），并提供自然语言查询接口。
+
+## Data Model
+```json
+{
+  "item": "milk",
+  "quantity": "2 gallons",
+  "location": "fridge",
+  "last_updated": "2026-04-22T10:30:00",
+  "low_stock_threshold": "1 gallon"
+}
+```
+
+## Input Methods
+| Method | Example | Mechanism |
+|--------|---------|-----------|
+| 照片 | 拍摄冰箱内容 → Vision 模型提取物品 | 视觉 AI OCR |
+| 文字 | "We're out of eggs" / "Bought 2 gallons of milk" | 自然语言解析 |
+| 小票 | 拍摄购物小票 → 自动扣减/更新 | 收据 OCR |
+
+## Query Interface
+通过 Telegram/Slack 等消息平台自然语言查询：
+- "Do we have butter?" → 返回位置和数量
+- "What's running low?" → 列出低于阈值的物品
+- "Generate grocery list" → 汇总低库存物品 + 食谱所需食材
+
+## Storage Location
+`~/household/inventory.json` 或通过 Agent 记忆系统（如 [[OpenClaw]] MEMORY）存储
+
+## Related Concepts
+- [[Morning Briefing]]：库存低时可在晨间简报中提醒
+- [[Second Brain]]：同属持久记忆能力的家庭应用
+- [[Personal CRM]]：[[personal-crm]] 的物资版，结构化数据 + 自然语言接口
+
+## Related Sources
+- [[family-calendar-household-assistant]] — 家庭物资追踪场景描述
--- a/wiki/concepts/Hybrid-Search.md
+++ b/wiki/concepts/Hybrid-Search.md
@@ -0,0 +1,51 @@
+---
+title: "Hybrid Search"
+type: concept
+tags: [search, vector, bm25, retrieval]
+sources: [semantic-memory-search, knowledge-base-rag]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+混合搜索结合两种或多种检索策略——通常是稠密向量检索（语义相似性）和稀疏关键词检索（BM25）——通过排名融合算法合并结果，兼顾语义理解和精确匹配。是当前 RAG 系统提升召回率的主流方法。
+
+## How It Works
+
+```
+查询 → [向量检索（ANN）] ─┐
+     → [BM25 关键词检索] ──┼─→ Reciprocal Rank Fusion (RRF) → 融合排名结果
+     → [其他检索器] ──────┘
+```
+
+1. **向量检索**：Embedding 模型将查询编码为向量，通过 ANN 索引（如 HNSW）找到语义相近的文档块
+2. **BM25 检索**：传统关键词检索，统计词频和文档频率，返回字面匹配的文档块
+3. **RRF 融合**：对各检索器的排名结果按 `1/(k+rank)` 公式融合，k 为平滑参数（通常 k=60）
+
+## Why Not Pure Vector Search?
+
+纯向量搜索的局限性：
+- **同义词覆盖不足**：Embedding 空间无法覆盖所有同义词（如"缓存"vs"cache"）
+- **专有名词精度低**：罕见词/新词/数字类实体的向量表示不够精确
+- **计算成本高**：向量检索的计算量随向量维度增长
+
+混合搜索通过 BM25 补充关键词精确匹配，同时保留向量搜索的语义理解能力。
+
+## Key Insight
+
+> "Hybrid search beats pure vector search. Combining semantic similarity (dense vectors) with keyword matching (BM25) via Reciprocal Rank Fusion catches both meaning-based and exact-match queries." — memsearch 文档
+
+## Implementation
+
+| 组件 | 说明 |
+|------|------|
+| 向量检索器 | Milvus / Pinecone / FAISS / Qdrant |
+| BM25 | Elasticsearch / OpenSearch / rank_bm25 |
+| RRF 融合 | 自实现或向量数据库内置 |
+| Embedding | OpenAI text-embedding-3 / BGE / Sentence-BERT |
+
+## Connections
+- [[semantic-memory-search]] — memsearch 使用混合搜索策略
+- [[Knowledge-Base-RAG]] — 混合搜索是知识库 RAG 提升召回率的关键
+- [[Semantic-Search]] — 混合搜索是纯语义搜索的增强版
+- [[Reciprocal Rank Fusion]] — 混合搜索的融合算法
--- a/wiki/concepts/Knowledge-Base-RAG.md
+++ b/wiki/concepts/Knowledge-Base-RAG.md
@@ -0,0 +1,57 @@
+---
+title: "Knowledge Base RAG"
+type: concept
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Retrieval-Augmented Generation（RAG）：在 LLM 生成回答前，先从外部知识库检索相关文档片段作为上下文补充，从而让 LLM 基于真实、私有或最新信息作答，而非依赖训练数据截止日期或模型幻觉。
+
+## Architecture
+
+```
+用户问题 → 编码为向量 → 向量数据库 ANN 检索 → Top-K 相关片段 → 与原问题拼接 → LLM 生成
+```
+
+## Components
+
+| 组件 | 说明 |
+|------|------|
+| **文档切分（Chunking）** | 将长文档拆分为适合检索的片段（通常 512-1024 tokens），过小丢失上下文，过大降低精度 |
+| **Embedding 模型** | 将文本编码为向量（见 [[Vector-Embedding]]） |
+| **向量数据库** | 存储 embedding 并支持 ANN 检索（Qdrant / Pinecone / pgvector / sqlite-vss） |
+| **重排序（Reranker）** | ANN 初筛后，用重排序模型（如 BGE-Reranker）精排，提高 top-K 准确率 |
+| **LLM** | 接收检索片段 + 原问题，生成最终回答 |
+
+## Chunking Strategies
+
+| 策略 | 适用场景 |
+|------|------|
+| 固定长度切分 | 简单快速，但可能切断语义单元 |
+| 递归字符切分（Recursive Character Splitting） | 按段落/句子边界切分，保留语义完整性 |
+| 基于语义切分（Semantic Chunking） | 用 LLM 判定切分点，效果最好但成本高 |
+| Agentic Chunking | 按工作流/主题边界切分，适合知识库分域管理 |
+
+## Applications in OpenClaw Workflows
+
+| 场景 | 说明 |
+|------|------|
+| [[YouTube-Content-Pipeline]] | 分享 Slack 链接时，Agent 查询知识库了解用户已有内容，避免重复选题 |
+| [[Second Brain]] | 个人知识库 RAG，支持跨记忆/文档的语义搜索 |
+| [[Pre-Build-Idea-Validator]] | 扫描知识库确认是否已做过类似项目 |
+| [[autonomous-game-dev-pipeline]] | 检索技术债务和已有代码片段 |
+
+## Quality Optimization
+
+1. **Hybrid Search**：向量检索 + BM25 关键词检索融合，提升召回率
+2. **Query Expansion**：将用户问题改写为多个视角再检索
+3. **Context Compression**：LLM 前对检索片段做摘要压缩，节省 token
+4. **Chunk Overlap**：相邻 chunk 重叠 10-20% 防止边界截断关键信息
+
+## Connections
+
+- [[Vector-Embedding]] — RAG 的检索底层
+- [[Semantic-Deduplication]] — 语义去重防止 RAG 检索重复片段
+- [[OpenClaw]] — 提供 `knowledge-base` skill 实现 RAG
+- [[Second Brain]] — RAG 的个人知识管理应用
--- a/wiki/concepts/LaTeX-Flattening.md
+++ b/wiki/concepts/LaTeX-Flattening.md
@@ -0,0 +1,26 @@
+---
+title: "LaTeX Flattening"
+type: concept
+tags: []
+sources: [arxiv-paper-reader]
+last_updated: 2026-04-17
+---
+
+## Concept Definition
+**LaTeX 扁平化（LaTeX Flattening）** 是指将多文件 LaTeX 论文项目（含 `\include{}`、 `\input{}`、子文件等）自动合成为单一连续文本的技术过程，使 AI 模型能够完整理解论文结构而无需处理文件引用和相对路径。
+
+## How It Works
+arXiv 论文通常包含多个 `.tex` 文件（主文件引用 `sections/` 目录下的子文件）。扁平化过程：
+1. 下载 arXiv LaTeX 源码压缩包（`.tar.gz`）
+2. 解析主文件，找到所有 `\include{}` / `\input{}` 引用
+3. 按引用顺序将子文件内容拼接注入主文件
+4. 清理 `\bibliography{}`、图片引用等外部依赖标记
+5. 输出单一完整文本流
+
+## Use Cases
+- [[arXiv-Paper-Reader]] 的核心处理步骤——将 arXiv LaTeX 源码转换为 AI 可读的纯净文本
+- 任何需要将 LaTeX 文档喂入 LLM 的场景
+
+## Related Concepts
+- [[arXiv-API]]：LaTeX 源码的下载来源
+- [[本地缓存]]：扁平化结果可缓存避免重复处理
--- a/wiki/concepts/Local-Caching.md
+++ b/wiki/concepts/Local-Caching.md
@@ -0,0 +1,28 @@
+---
+title: "Local Caching"
+type: concept
+tags: []
+sources: [arxiv-paper-reader]
+last_updated: 2026-04-17
+---
+
+## Concept Definition
+**本地缓存（Local Caching）** 是指将 API 调用结果或解析结果持久化到本地文件系统，使重复访问无需重新请求或重新处理，直接从本地读取即可获得毫秒级响应。
+
+## How It Works
+1. 首次请求：API 调用 → 结果处理 → 写入本地缓存文件（含 hash 标识）
+2. 后续请求：计算请求 hash → 命中缓存 → 直接返回本地文件内容
+3. 缓存失效：由 TTL、源文件修改时间或手动清理触发
+
+## Use Cases
+- [[arXiv-Paper-Reader]]：论文解析结果本地缓存，重复阅读即时响应
+- [[Semantic-Memory-Search]]：向量嵌入缓存，避免重复计算
+- [[YouTube-Content-Pipeline]]：视频目录 90 天缓存，避免重复抓取
+
+## Trade-offs
+- **优点**：零成本、即时响应、保护 API 限额
+- **缺点**：占用磁盘空间、需管理缓存失效策略
+
+## Related Concepts
+- [[Content Hashing]]：用于缓存键生成的哈希机制
+- [[File Watcher]]：检测源文件变更触发缓存失效
--- a/wiki/concepts/Lockable-Workflow.md
+++ b/wiki/concepts/Lockable-Workflow.md
@@ -0,0 +1,32 @@
+---
+title: "Lockable-Workflow"
+type: concept
+tags: [security, workflow, n8n, governance]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Lockable Workflow
+- 可锁定工作流
+
+## Definition
+
+工作流在 Agent 构建、人工验证后进入锁定状态（locked），锁定后的工作流不可被 Agent 修改，从而确保工作流的 API 调用逻辑不被 Agent 静默改变。锁定是 [[Webhook-Proxy-Pattern]] 安全运转的必要条件。
+
+## Why It Matters
+- 不锁定的工作流，Agent 可以通过 n8n API 重新编辑 Webhook 逻辑
+- Agent 可能无意中修改凭证参数或 API 端点
+- 锁定创建了一个明确的信任边界：Agent 只能调用，不能改造
+
+## Lifecycle
+1. **Build**：Agent 通过 n8n API 创建工作流
+2. **Test**：管理员验证工作流行为符合预期
+3. **Lock**：锁定工作流，Agent 失去编辑权限
+4. **Call**：Agent 通过 Webhook 持续调用
+
+## Connections
+- [[Webhook-Proxy-Pattern]] — 锁定保障该模式的安全
+- [[Credential-Isolation]] — 与凭证隔离共同构成安全护城河
+- [[Safeguard-Steps]] — 锁定前可加入人工审批等 Safeguard
+- [[n8n]] — 提供工作流锁定能力的平台
--- a/wiki/concepts/Multi-Channel-Delivery.md
+++ b/wiki/concepts/Multi-Channel-Delivery.md
@@ -0,0 +1,27 @@
+---
+title: "Multi-Channel Delivery"
+type: concept
+tags: []
+---
+
+## Definition
+多渠道内容投递模式——同一内容根据用户偏好同时或选择性地通过多个平台（Discord、Email、Telegram 等）进行投递，提升触达率和用户便利性。
+
+## Common Channels
+| 渠道 | 特点 | 适用场景 |
+|------|------|----------|
+| Discord | 频道制、社区感、支持富文本 | 社区内容推送 |
+| Email | 正式、可存档、适合长内容 | Newsletter、报告 |
+| Telegram | 即时、话题制、跨设备同步 | 个人助理、私人简报 |
+| Slack | 团队协作、频道/话题隔离 | 工作流通知 |
+
+## Design Pattern
+```
+[内容生成器] → [渠道适配层] → [Discord] / [Email] / [Telegram]
+                              (用户偏好决定投递渠道组合)
+```
+
+## Related Concepts
+- [[Daily-Digest]] — 投递内容的一种常见形式
+- [[Quality-Scoring-Algorithm]] — 投递前的内容筛选
+- [[Preference-Learning]] — 根据用户反馈持续优化渠道选择
--- a/wiki/concepts/Paper-Abstract-Batch-Fetching.md
+++ b/wiki/concepts/Paper-Abstract-Batch-Fetching.md
@@ -0,0 +1,24 @@
+---
+title: "Paper Abstract Batch Fetching"
+type: concept
+tags: []
+sources: [arxiv-paper-reader]
+last_updated: 2026-04-17
+---
+
+## Concept Definition
+**论文摘要批量获取（Paper Abstract Batch Fetching）** 是指在一次操作中同时从多个 arXiv 论文获取摘要，并生成结构化对比表格以支持快速筛选和优先级排序的工作模式。
+
+## How It Works
+1. 输入：多个 arXiv ID 列表（如 `["2301.00001", "2301.04088", "2302.07789"]`）
+2. 调用：批量 `arxiv_abstract` 工具并行/串行获取摘要
+3. 输出：结构化表格（ID | 标题 | 作者 | 摘要摘要 | 相关性评分）
+4. 用户筛选：确认阅读优先级后触发全文获取
+
+## Use Cases
+- [[arXiv-Paper-Reader]] 的核心工作流之一——快速 triage 阅读列表
+- 研究选题初期对多条候选论文进行对比评估
+
+## Comparison with Related
+- [[Semantic-Memory-Search]] 侧重对已有内容的检索；本概念侧重对新内容的发现和筛选
+- 与 [[Agent-Driven Market Research]] 同属批量情报收集，但本概念聚焦学术论文
--- a/wiki/concepts/Personal-CRM.md
+++ b/wiki/concepts/Personal-CRM.md
@@ -0,0 +1,51 @@
+---
+title: "Personal CRM"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Aliases
+- Personal Customer Relationship Management
+- 联系人关系管理
+
+## Definition
+基于 AI Agent 的个人联系人管理系统，通过自动发现而非手动录入维护人际关系记忆，核心价值在于零摩擦积累和主动会议准备。
+
+## Key Attributes
+
+| 属性 | 描述 |
+|------|------|
+| 数据来源 | Gmail、Google Calendar（通过 gog CLI） |
+| 存储结构 | SQLite（联系人表：姓名、邮箱、首见时间、末联系时间、互动次数、备注） |
+| 查询接口 | Telegram Topic（personal-crm）自然语言查询 |
+| 触发机制 | Cron Job（每日联系人扫描 + 每日会议简报） |
+| AI 框架 | OpenClaw |
+
+## Workflow
+
+1. **每日 6AM Cron Job**：扫描 Gmail + Calendar 过去 24 小时
+2. **提取新联系人**：自动识别邮件/日历中的外部参与者
+3. **更新数据库**：新增或更新已有联系人的互动记录
+4. **每日 7AM Cron Job**：查询当天日历，收集每位外部参会者背景
+5. **推送简报**：Telegram 投递会前准备（含上次交流内容、待跟进事项）
+6. **按需查询**：Telegram personal-crm topic 接收自然语言查询
+
+## 与相关概念的区分
+
+| 概念 | 差异点 |
+|------|--------|
+| [[Second Brain]] | 非结构化任意内容捕获，Personal CRM 侧重结构化联系人关系 |
+| [[Local CRM Framework]] | DenchClaw 侧重本地 Web UI + 数据导入；Personal CRM 侧重自动发现 |
+| [[Email Triage]] | 侧重邮件分拣；Personal CRM 侧重联系人关系追踪 |
+| [[Meeting Prep Briefing]] | Personal CRM 的子功能之一 |
+
+## 实现方案
+
+- **[[personal-crm]]**（本文档来源）：OpenClaw + gog CLI + SQLite + Telegram Topic
+- **[[local-crm-framework]]**（DenchClaw）：OpenClaw + DuckDB + Web UI + 浏览器自动化
+
+## Sources
+- [[personal-crm]]
+- [[local-crm-framework]]
+- [[multi-channel-assistant]]
--- a/wiki/concepts/Quality-Scoring-Algorithm.md
+++ b/wiki/concepts/Quality-Scoring-Algorithm.md
@@ -0,0 +1,29 @@
+---
+title: "Quality Scoring Algorithm"
+type: concept
+tags: []
+---
+
+## Definition
+多维度加权评分算法——通过 priority source（优先级来源）、multi-source（多源交叉验证）、recency（时效性）和 engagement（互动量）四个维度对内容进行加权评分，过滤噪音提升信息价值。
+
+## Formula
+```
+score = priority_source(×3) + multi_source(×5) + recency(×2) + engagement(×1)
+```
+
+## Dimensions
+| 维度 | 权重 | 说明 |
+|------|------|------|
+| priority_source | +3 | 高质量来源（如 OpenAI Blog、Hacker News） |
+| multi_source | +5 | 多源同时报道同一事件 |
+| recency | +2 | 发布时间距现在越近分数越高 |
+| engagement | +1 | 社交媒体互动量（点赞/转发/评论） |
+
+## Use Cases
+- [[multi-source-tech-news-digest]] — 科技新闻质量评分
+- 任何需要从大量来源中筛选高价值内容的场景
+
+## Related Concepts
+- [[Semantic-Deduplication]] — 与评分算法配合，先去重再评分
+- [[Daily-Digest]] — 评分结果最终投递为每日简报
--- a/wiki/concepts/RSS-Aggregation.md
+++ b/wiki/concepts/RSS-Aggregation.md
@@ -0,0 +1,40 @@
+---
+title: "RSS Aggregation"
+type: concept
+tags: []
+---
+
+## Definition
+RSS 聚合模式——通过 RSS 协议从多个信息源持续获取最新内容，作为信息监控和内容策展的基础数据管道。
+
+## Architecture
+```
+[RSS Feed URLs] → [RSS Parser (feedparser)] → [内容提取] → [去重评分] → [投递]
+                       ↑
+              [RSSHub] 扩展无原生 RSS 的站点
+```
+
+## Key Tools
+| 工具 | 用途 |
+|------|------|
+| [[RSSHub]] | 开源 RSS 聚合服务，为无原生 RSS 的网站（如 Twitter、GitHub、bilibili）生成 RSS 源 |
+| feedparser | Python RSS/Atom 解析库 |
+| FreshRSS | 自托管 RSS 阅读器 |
+| Inoreader | 托管 RSS 服务 |
+
+## RSSHub Extended Sources
+RSSHub 可为以下无原生 RSS 的网站生成 RSS 源：
+- 社交媒体：Twitter 用户/话题、微博用户
+- 视频平台：YouTube 频道、bilibili 用户/分区
+- GitHub：仓库 Issues/PR/Releases/Commits
+- 新闻：知乎话题、微博热搜
+
+## Use Cases
+- [[multi-source-tech-news-digest]] — 46 个 RSS 源（OpenAI Blog、Hacker News、MIT Tech Review 等）
+- Newsletter 订阅源
+- 竞品动态监控
+
+## Related Concepts
+- [[Web-Search-Aggregation]] — RSS 的互补方案：被动拉取 vs 主动搜索
+- [[Content-Deduplication]] — 多 RSS 源之间的内容去重
+- [[RSSHub]] — 扩展 RSS 覆盖范围的工具
--- a/wiki/concepts/Reciprocal-Rank-Fusion.md
+++ b/wiki/concepts/Reciprocal-Rank-Fusion.md
@@ -0,0 +1,52 @@
+---
+title: "Reciprocal Rank Fusion (RRF)"
+type: concept
+tags: [search, ranking, fusion, algorithm]
+sources: [semantic-memory-search]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- RRF
+- Reciprocal Rank Fusion
+
+## Definition
+
+Reciprocal Rank Fusion（倒数排名融合）是一种多检索器结果融合算法，通过对各检索器返回结果的排名取倒数并进行加权求和，生成统一的融合排名。无需训练，简单高效，是混合搜索的标准融合策略。
+
+## Formula
+
+```
+RRF_score(d) = Σ  1 / (k + rank_i(d))
+
+其中：
+- d = 文档
+- rank_i(d) = 检索器 i 对文档 d 的排名（从1开始）
+- k = 平滑参数（通常 k=60，作用是减少高排名文档的压倒性优势）
+```
+
+## Why k=60?
+
+k=60 是一个经验值，来源于 BM25 的默认参数 k1=1.2、b=0.75 的理论推导。选择 k=60 使得排名差异在高位次（rank 1 vs rank 2）时有明显影响，但在低排名（rank 50 vs rank 51）时影响减弱，兼顾早期精确和长尾包容。
+
+## Example
+
+假设有两个检索器对同一查询的结果：
+
+| 文档 | 向量检索排名 | BM25 排名 |
+|------|------------|----------|
+| A | 1 | 3 |
+| B | 2 | 1 |
+| C | 3 | 2 |
+
+k=60 时：
+- RRF(A) = 1/(60+1) + 1/(60+3) = 0.01639 + 0.01587 = **0.03226**
+- RRF(B) = 1/(60+2) + 1/(60+1) = 0.01613 + 0.01639 = **0.03252**
+- RRF(C) = 1/(60+3) + 1/(60+2) = 0.01587 + 0.01613 = **0.03200**
+
+最终排名：B > A > C
+
+## Connections
+- [[Hybrid Search]] — RRF 是混合搜索的标准融合算法
+- [[semantic-memory-search]] — memsearch 使用 RRF 融合向量和 BM25 结果
+- [[Knowledge-Base-RAG]] — RRF 用于提升知识库检索质量
--- a/wiki/concepts/Safeguard-Steps.md
+++ b/wiki/concepts/Safeguard-Steps.md
@@ -0,0 +1,31 @@
+---
+title: "Safeguard-Steps"
+type: concept
+tags: [security, workflow, governance, n8n]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Safeguard Steps
+- 安全门控步骤
+
+## Definition
+
+在 n8n 工作流中，于实际 API 调用执行前插入的验证节点、速率限制节点或人工审批节点，用于在凭证被使用前增加额外的安全层，确保外部 API 调用符合预期范围。
+
+## Examples
+- **输入验证**：检查 payload 字段是否符合预期格式和范围
+- **速率限制**：防止 Agent 短时间内大量重复调用
+- **人工审批**：高风险操作（如发送付款邮件、删除数据）需要人工确认
+- **条件分支**：超出预算/权限的调用自动拒绝
+
+## Why It Matters
+- 凭证隔离只防止密钥泄露，不防止 Agent 误用密钥
+- Safeguard 步骤在凭证被调用前设置最后一道关卡
+- 与 [[Lockable-Workflow]] 配合，确保 Safeguard 逻辑本身不被 Agent 修改
+
+## Connections
+- [[Credential-Isolation]] — 互补：隔离防止泄露，Safeguard 防止误用
+- [[Lockable-Workflow]] — 锁定 Safeguard 逻辑本身不被修改
+- [[Webhook-Proxy-Pattern]] — Safeguard 是该模式的推荐实现组件
--- a/wiki/concepts/Semantic-Deduplication.md
+++ b/wiki/concepts/Semantic-Deduplication.md
@@ -0,0 +1,45 @@
+---
+title: "Semantic Deduplication"
+type: concept
+last_updated: 2026-04-22
+---
+
+## Definition
+
+通过向量嵌入（vector embedding）计算文本内容的语义相似度，在相似度超过阈值时判定为重复，从而实现比精确匹配更智能的去重能力。
+
+## Mechanism
+
+1. **Embedding 生成**：将文本内容（选题、摘要、评论等）通过 LLM 或专用 embedding 模型（如 OpenAI text-embedding-3-small）转为高维向量
+2. **相似度计算**：使用余弦相似度（cosine similarity）或点积（dot product）比较向量距离
+3. **阈值判定**：相似度 > 阈值（通常 0.85-0.95）则判定为重复
+4. **存储与检索**：向量存入数据库（SQLite + extension / pgvector / Qdrant），检索时做 ANN（近似最近邻）搜索
+
+## Why It Matters
+
+精确匹配（字符串/哈希去重）无法识别语义重复：
+- "Claude Code 发布了新功能" vs "Anthropic's CLI agent got an update" — 同一事件，不同措辞
+- 语义去重确保：不做重复选题，不生成相似内容，不过度覆盖同一主题
+
+## Applications
+
+| 场景 | 工具 | 说明 |
+|------|------|------|
+| YouTube 选题去重 | [[YouTube-Content-Pipeline]] | SQLite 存储向量，从不推送同一选题两次 |
+| 知识库 RAG | [[Knowledge-Base-RAG]] | 检索时过滤语义重复的上下文片段 |
+| Newsletter 去重 | [[Inbox-De-clutter]] | 避免同一事件被重复摘要 |
+| 竞品分析 | [[Pre-Build-Idea-Validator]] | 识别赛道内相似产品 |
+
+## Implementation Notes
+
+- **SQLite**：可用 `sqlite-vss` 扩展（基于 FAISS）实现向量存储和 ANN 搜索
+- **Embedding 模型选择**：text-embedding-3-small（OpenAI）性价比最高；BGE-m3（国产，支持中文）
+- **阈值调优**：高阈值（0.95）保守去重，低阈值（0.85）激进去重，需根据场景调整
+- **更新策略**：已有内容变化时需重新生成 embedding
+
+## Connections
+
+- [[Vector-Embedding]] — 底层使能技术
+- [[Knowledge-Base-RAG]] — 应用场景之一
+- [[YouTube-Content-Pipeline]] — 具体应用实例
+- [[Pre-Build-Validation]] — 避免重复发现同类竞品
--- a/wiki/concepts/Semantic-Search.md
+++ b/wiki/concepts/Semantic-Search.md
@@ -0,0 +1,36 @@
+---
+title: "Semantic Search"
+type: concept
+last_updated: 2026-04-22
+---
+
+## Definition
+
+基于 Embedding 向量模型将文本编码为高维向量，通过向量相似度（如余弦相似度）而非关键词匹配来检索相关内容的搜索方式。相比 BM25/BM25 等传统关键词检索，能捕捉语义层面的相关性，例如"我保存的关于 LLM memory 的内容？"能匹配到讨论 agent 记忆机制的文章，即使两者用词不同。
+
+## How It Works
+
+```
+用户查询 → Embedding 模型编码 → 高维向量
+文档库 → Embedding 模型编码 → 文档向量集合
+↓
+向量相似度计算（ANN 索引）→ Top-K 结果 → LLM 回答
+```
+
+## Components
+
+| 组件 | 说明 |
+|------|------|
+| Embedding 模型 | text-embedding-3-small、BGE、Sentence-BERT 等 |
+| ANN 索引 | FAISS / HNSW / ScaNN，实现十亿级向量近实时检索 |
+| 相似度度量 | 余弦相似度 / 点积 / 欧氏距离 |
+
+## Why It Matters in RAG
+
+关键词搜索依赖字面匹配，容易漏掉同义词/多义词场景。语义搜索理解查询意图，使 [[Knowledge-Base-RAG]] 返回真正相关结果而非机械的字面匹配。
+
+## Connections
+
+- [[Knowledge-Base-RAG]] — 语义搜索是知识库 RAG 的检索层
+- [[Vector-Embedding]] — 语义搜索的底层编码技术
+- [[Hybrid Search]] — 向量检索 + BM25 关键词检索融合，进一步提升召回率
--- a/wiki/concepts/Social-Media-Monitoring.md
+++ b/wiki/concepts/Social-Media-Monitoring.md
@@ -0,0 +1,31 @@
+---
+title: "Social Media Monitoring"
+type: concept
+tags: []
+---
+
+## Definition
+社交媒体监控模式——通过 API 追踪特定账号（KOL、品牌、竞品）的动态更新，实现自动化内容发现和情报收集。
+
+## Key Components
+1. **账号发现** — 确定需要监控的社交账号列表（KOL、行业专家、竞品官方）
+2. **API 集成** — 通过平台官方 API（Twitter/X API、Instagram Graph API 等）获取数据
+3. **变更检测** — 检测新帖子、互动变化、粉丝变化等事件
+4. **事件通知** — 检测到变化时触发通知（Discord/Telegram/Email）
+
+## Supported Platforms
+| 平台 | 监控内容 | 相关工具 |
+|------|----------|----------|
+| Twitter/X | 推文、回复、关注者变化 | TweetClaw, X_BEARER_TOKEN |
+| LinkedIn | 帖子、文章 | OpenClaw agents |
+| Reddit | Subreddit 热门帖子 | reddit-readonly skill |
+
+## Use Cases
+- [[multi-source-tech-news-digest]] — 监控 44 个 Twitter/X KOL 账号
+- [[YouTube-Content-Pipeline]] — 监控 Twitter/X 突发 AI 新闻
+- [[x-twitter-automation]] — 主动发帖和互动
+
+## Related Concepts
+- [[Account-Monitoring]] — 同一模式，侧重账号级变化监控
+- [[Content-Automation]] — 监控到内容后的自动处理
+- [[X/Twitter-API-Automation]] — Twitter/X API 的具体实现方式
--- a/wiki/concepts/Sub-Agent-Race-Condition.md
+++ b/wiki/concepts/Sub-Agent-Race-Condition.md
@@ -0,0 +1,51 @@
+---
+title: "Sub-Agent Race Condition"
+type: concept
+tags: [multi-agent, concurrency, engineering-pitfall]
+sources: [overnight-mini-app-builder]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+多子代理并发编辑共享文件时导致的竞态条件。当主会话和子代理同时尝试修改同一文件（如 AUTONOMOUS.md/Kanban 状态文件）时，由于 `edit` 工具要求精确的 `oldText` 匹配，子代理在主会话读取和编辑之间的窗口期内更新了文件内容，导致 `oldText` 失效，`edit` 操作静默失败。
+
+## Aliases
+
+- Race Condition
+- 并发编辑冲突
+- Silent Edit Failure
+
+## Root Cause
+
+OpenClaw 的 `edit` 工具依赖精确字符串匹配（exact `oldText` match）。在多 Agent 并发场景下：
+1. 主会话读取文件 → 内存中为旧版本
+2. 子代理修改同一文件 → 磁盘版本已更新
+3. 主会话尝试 `edit(oldText=旧版本)` → 匹配失败 → **静默失败**
+
+## Solution: Git-Style Append-Only Pattern
+
+参考 Git 的"不重写历史"原则，将任务文件分为两类：
+
+| 文件 | 角色 | 谁可写 |
+|------|------|--------|
+| `AUTONOMOUS.md` | 状态文件（目标 + 开放待办） | **仅主会话** |
+| `memory/tasks-log.md` | 追加日志（已完成任务） | **所有子代理（只追加）** |
+
+```markdown
+# tasks-log.md — Completed Tasks (append-only)
+# Sub-agents: always append to the END. Never edit existing lines.
+
+### 2026-02-24
+- ✅ TASK-001: Research competitors → research/competitors.md
+- ✅ TASK-002: Draft blog post → drafts/post-1.md
+```
+
+子代理 spawn 指令中必须包含：
+> "When done, append a ✅ line to `memory/tasks-log.md`. Never edit `AUTONOMOUS.md` directly."
+
+## Key Relationships
+
+- [[GitAsAuditLog]] — 本模式的概念来源，Git 的追加提交哲学
+- [[SharedStateCoordination]] — 共享状态协调的通用概念
+- [[overnight-mini-app-builder]] — 本模式的来源场景
--- a/wiki/concepts/Token-Light-Design.md
+++ b/wiki/concepts/Token-Light-Design.md
@@ -0,0 +1,40 @@
+---
+title: "Token-Light Design"
+type: concept
+tags: [optimization, memory, cost-efficiency]
+sources: [overnight-mini-app-builder]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Token-Light Design 是一种 AI Agent 记忆系统的令牌优化策略——保持高频加载文件（如 `AUTONOMOUS.md`）在精简行数以内，避免每次心跳轮询时消耗过多上下文令牌，从而降低 LLM 调用成本。
+
+## Aliases
+
+- Token 优化
+- 令牌效率设计
+- Lightweight Memory File
+
+## Core Principle
+
+**AUTONOMUS.md 应保持在约 50 行以内**，包含：
+- 目标（一行描述）
+- 开放待办 backlog（简洁列表）
+
+已完成的任务**不**存入高频文件，而是：
+- 追加到 `memory/tasks-log.md`（append-only，仅需要时读取）
+- 或存档到专用文件（按需读取）
+
+## Why It Matters
+
+在 OpenClaw 等框架中：
+1. 每次心跳轮询（heartbeat poll）需要加载 `AUTONOMOUS.md`
+2. 文件越大 → 上下文越长 → 令牌越多 → 成本越高
+3. 已完成任务长期积累会使文件膨胀
+
+## Key Relationships
+
+- [[Sub-Agent Race Condition]] — 两者共同构成 AUTONOMOUS.md 的最佳实践
+- [[Cumulative Memory]] — 对立面：强调累积记忆的丰富性
+- [[overnight-mini-app-builder]] — 本概念的来源场景
--- a/wiki/concepts/Vector-Embedding.md
+++ b/wiki/concepts/Vector-Embedding.md
@@ -0,0 +1,53 @@
+---
+title: "Vector Embedding"
+type: concept
+last_updated: 2026-04-22
+---
+
+## Definition
+
+将文本、图片、音频等非结构化数据通过深度学习模型转换为高维稠密向量（dense vector），使语义相似的内容在向量空间中彼此接近。
+
+## How It Works
+
+1. **编码（Encoding）**：文本经过 embedding 模型（如 BERT、OpenAI text-embedding-3-small、BGE-m3）处理，输出固定维度的实数向量（常见维度：384/768/1536/3072）
+2. **存储**：向量存入向量数据库（Qdrant、Pinecone、Weaviate）或支持向量索引的数据库（pgvector、SQLite + sqlite-vss）
+3. **检索**：查询时将查询文本同样编码为向量，在向量空间中搜索最近邻（ANN 或 KNN）
+
+## Key Properties
+
+| 属性 | 说明 |
+|------|------|
+| 维度（dimensionality） | 越高表达能力越强，但存储/计算成本更高 |
+| 语义保持（semantic preservation） | 同义词/近义表达在空间中接近 |
+| 可微性 | 支持通过梯度下降持续优化（对比学习） |
+| 跨模态 | CLIP 等模型可实现图文跨模态检索 |
+
+## Core Operations
+
+- **余弦相似度**（cosine similarity）：衡量方向一致性，值域 [-1, 1]
+- **点积**（dot product）：值域无界，embedding 已归一化时等价于余弦相似度
+- **欧氏距离**（L2 distance）：衡量绝对距离
+
+## Applications
+
+| 应用 | 说明 |
+|------|------|
+| RAG | 检索相关文档片段作为 LLM 上下文 |
+| 语义去重 | [[Semantic-Deduplication]] — 识别语义重复内容 |
+| 推荐系统 | 基于内容 embedding 找相似物品 |
+| 聚类分析 | 将相似文档自动分组 |
+
+## Tools & Models
+
+- **OpenAI text-embedding-3-small**：1536 维，性价比最高（$0.02/1M tokens）
+- **BGE-m3**：支持中文多语言，开源（FlagEmbedding）
+- **nomic-embed-text**：开源 768 维，支持本地部署
+- **sqlite-vss**：SQLite 扩展，支持向量 ANN 搜索
+- **Qdrant**：开源向量数据库，支持过滤条件
+
+## Connections
+
+- [[Semantic-Deduplication]] — 向量嵌入的直接应用
+- [[Knowledge-Base-RAG]] — RAG 的核心检索技术
+- [[YouTube-Content-Pipeline]] — 用向量嵌入实现选题去重
--- a/wiki/concepts/Visual-Debugging.md
+++ b/wiki/concepts/Visual-Debugging.md
@@ -0,0 +1,26 @@
+---
+title: "Visual-Debugging"
+type: concept
+tags: [debugging, observability, workflow, n8n]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Visual Debugging
+- 可视化调试
+
+## Definition
+
+n8n 的拖拽式可视化节点编辑器让每个工作流的执行路径完全透明可见，管理员和开发者可以直观地检查工作流的逻辑分支、数据转换步骤和 API 调用详情，而无需阅读 JavaScript 代码。
+
+## Why It Matters
+- Agent 生成的代码/工作流难以直接审查
+- 可视化界面让非技术人员也能理解工作流在做什么
+- 大幅降低排查"AI 静默干了什么"的难度
+
+## Connections
+- [[Audit-Trail]] — 可视化与执行日志互为补充
+- [[Webhook-Proxy-Pattern]] — 该模式受益于可视化调试
+- [[Lockable-Workflow]] — 锁定前需通过可视化验证
+- [[n8n]] — 提供可视化调试能力的平台
--- a/wiki/concepts/Web-Search-Aggregation.md
+++ b/wiki/concepts/Web-Search-Aggregation.md
@@ -0,0 +1,33 @@
+---
+title: "Web Search Aggregation"
+type: concept
+tags: []
+---
+
+## Definition
+网页搜索聚合模式——通过搜索 API 主动获取特定主题的最新网页结果，补充无 RSS/无 API 的信息源，实现更全面的内容覆盖。
+
+## Key Providers
+| 提供方 | API | 特点 |
+|--------|-----|------|
+| Brave Search | Brave Search API | 注重隐私，搜索结果质量高 |
+| Google Custom Search | Google Programmable Search | 覆盖最广 |
+| DuckDuckGo | 非官方 API | 免费但不稳定 |
+| SerpAPI | 聚合多平台 | 付费，支持 Google/Bing/Yandex |
+
+## Environment Variables
+- `BRAVE_API_KEY` — Brave Search API 密钥
+
+## Use Cases
+- [[multi-source-tech-news-digest]] — 通过 Brave Search API 执行 4 个主题的主动搜索，覆盖无 RSS 来源的科技新闻
+- 补充特定领域的深度搜索需求
+
+## Design Pattern
+```
+[定时触发] → [主题搜索查询列表] → [Brave Search API] → [结果解析] → [评分去重] → [简报投递]
+```
+
+## Related Concepts
+- [[RSS-Aggregation]] — 两种互补的内容获取方式：RSS 被动拉取 vs Search 主动搜索
+- [[Quality-Scoring-Algorithm]] — 搜索结果的后续处理
+- [[Content-Deduplication]] — 搜索结果与 RSS 结果的交叉去重
--- a/wiki/concepts/Webhook-Proxy-Pattern.md
+++ b/wiki/concepts/Webhook-Proxy-Pattern.md
@@ -0,0 +1,34 @@
+---
+title: "Webhook-Proxy-Pattern"
+type: concept
+tags: [webhook, security, agent-architecture, n8n]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Webhook Proxy Pattern
+- Webhook 代理模式
+
+## Definition
+
+一种 AI Agent 外部 API 调用架构：Agent 不直接持有凭证，而是通过调用 n8n Webhook URL 触发工作流，n8n 在服务端持有 API 凭证并执行实际 API 调用。Agent 只知道 Webhook 端点，不知道任何密钥。
+
+## Why It Matters
+- **安全性**：API 密钥从不进入 Agent 环境，一次误提交也不会泄露
+- **可观测性**：n8n 记录每次调用的输入输出
+- **可治理**：工作流可被锁定，Agent 无法静默修改 API 行为
+- **可测试**：工作流可在 n8n UI 中独立调试
+
+## How It Works
+1. Agent 通过 n8n API 创建工作流（含 Webhook 触发器）
+2. 管理员在 n8n UI 中添加凭证并锁定工作流
+3. Agent 只需调用 `POST http://n8n:5678/webhook/workflow-name` 附带 JSON payload
+4. n8n 执行实际 API 调用并返回结果
+
+## Connections
+- [[Credential-Isolation]] — 该模式的核心安全属性
+- [[Lockable-Workflow]] — 该模式的安全保障机制
+- [[Webhook]] — 技术基础
+- [[n8n]] — 执行代理
+- [[OpenClaw]] — 调用方 Agent
--- a/wiki/concepts/arXiv-API.md
+++ b/wiki/concepts/arXiv-API.md
@@ -0,0 +1,30 @@
+---
+title: "arXiv API"
+type: concept
+tags: []
+sources: [arxiv-paper-reader]
+last_updated: 2026-04-17
+---
+
+## Concept Definition
+**arXiv API** 是 arXiv 开放论文平台提供的 HTTP 接口集，支持通过程序化方式获取论文元数据（标题、作者、摘要、分类）、PDF 和 LaTeX 源码，无需手动下载。
+
+## Key Endpoints
+| 操作 | 端点 | 说明 |
+|------|------|------|
+| 搜索 | `http://export.arxiv.org/api/query?search_query=...` | Atom XML 格式返回匹配论文 |
+| 获取 | `http://export.arxiv.org/api/query?id_list=2301.00001` | 按 arXiv ID 获取单篇或批量论文 |
+| LaTeX 源码 | `https://arxiv.org/e-print/<arxiv-id>` | 下载 LaTeX 源码 `.tar.gz` |
+| PDF | `https://arxiv.org/pdf/<arxiv-id>.pdf` | 下载 PDF 全文 |
+
+## Use Cases
+- [[arXiv-Paper-Reader]] 的核心数据来源
+- 批量论文筛选和元数据分析
+
+## Limitations
+- 每秒最多 1 请求（官方限速），需实现请求节流
+- LaTeX 源码仅部分论文提供（非强制提交）
+
+## Related Concepts
+- [[LaTeX-Flattening]]：API 返回的 LaTeX 源码的处理方式
+- [[论文摘要批量获取]]：批量调用 API 的应用场景
--- a/wiki/entities/Alex-Finn.md
+++ b/wiki/entities/Alex-Finn.md
@@ -2,7 +2,7 @@
 title: "Alex Finn"
 type: entity
 tags: [content-creator, openclaw-community]
-sources: [market-research-product-factory, content-factory, custom-morning-brief, second-brain]
+sources: [market-research-product-factory, content-factory, custom-morning-brief, second-brain, overnight-mini-app-builder]
 last_updated: 2026-04-22
 ---

--- a/wiki/entities/DenchClaw.md
+++ b/wiki/entities/DenchClaw.md
@@ -0,0 +1,47 @@
+---
+title: "DenchClaw"
+type: entity
+tags: ["openclaw", "crm", "product", "automation"]
+last_updated: 2026-04-22
+---
+
+## Overview
+MIT 许可证开源框架，通过 `npx denchclaw` 一键将 [[OpenClaw]] 转化为完整的本地 CRM、销售自动化和生产力平台。
+
+## Aliases
+- Dench Claw
+- DenchClaw
+
+## Details
+- **官网**: https://denchclaw.com
+- **GitHub**: https://github.com/DenchHQ/DenchClaw
+- **许可证**: MIT
+- **Discord 社区**: https://discord.gg/PDFXNVQj9n
+
+## Key Features
+1. **One-command setup**: 自动安装 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器自动化和 Skills
+2. **Natural language CRM**: 自然语言查询实时更新视图，无需手动过滤器
+3. **Chrome profile cloning**: 复制浏览器认证状态，Agent 可直接操作用户已登录的 Web 应用
+4. **Multiple views**: Table、Kanban、Calendar、Timeline、Gallery、List 视图
+5. **App builder**: OpenClaw 构建自包含 Web 应用，运行在 workspace 内并访问数据库
+6. **File-system-first**: 所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接读写
+
+## Architecture
+- **Database**: [[DuckDB]] — 嵌入式分析型数据库
+- **Agent Engine**: [[OpenClaw]]
+- **Web UI**: localhost:3100
+- **Gateway**: port 19001
+
+## Bundled Skills
+- **CRM Skill**: DuckDB 后端结构化数据管理（对象/字段/条目/多视图）
+- **App Builder Skill**: 构建运行在 workspace 内、访问数据库的 Web 应用
+- **Browser Automation Skill**: Chromium 浏览器，继承用户 Chrome 认证状态
+
+## Key Insight
+> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
+
+## Related
+- [[OpenClaw]] — 底层 Agent 引擎
+- [[DuckDB]] — 数据存储
+- [[Chrome Profile Cloning]] — 浏览器自动化机制
+- [[File-System-First-UI]] — 设计哲学
--- a/wiki/entities/DracoVibeCoding.md
+++ b/wiki/entities/DracoVibeCoding.md
@@ -0,0 +1,17 @@
+---
+title: "DracoVibeCoding"
+type: entity
+tags: []
+---
+
+## Overview
+公众号"Draco正在VibeCoding"作者，专注 Vibe Coding 与 AI Agent 实战分享，是 [[multi-source-tech-news-digest]] 等多个 OpenClaw Agent 自动化方案的提出者。
+
+## Type
+人物 / 内容创作者
+
+## Aliases
+- DracoVibeCoding
+
+## Related Links
+- [[ClawHub]] — 作者方案的发布平台
--- a/wiki/entities/Memsearch.md
+++ b/wiki/entities/Memsearch.md
@@ -0,0 +1,42 @@
+---
+title: "memsearch"
+type: entity
+tags: [vector-search, semantic-search, openclaw, milvus]
+sources: [semantic-memory-search]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- memsearch
+
+## Definition
+
+memsearch（ZillizTech/memsearch）是开源的向量语义搜索 CLI/库，专为 OpenClaw 等 Markdown 记忆系统设计，通过 Milvus 向量数据库实现语义搜索能力。用户可用自然语言提问而无需精确关键词。
+
+## Key Features
+
+- **混合搜索**：稠密向量（语义相似性）+ BM25（关键词精确匹配），通过 Reciprocal Rank Fusion (RRF) 重排
+- **增量索引**：SHA-256 内容哈希确保仅新增或变更内容被重新嵌入，节省 API 调用
+- **文件监视器**：`memsearch watch` 实时监控记忆文件变化，自动重建索引
+- **多 Embedding 提供商**：支持 OpenAI、Google、Voyage、Ollama，以及完全本地模式（无需 API Key）
+- **Markdown 不可变**：原始 Markdown 文件是唯一真相，向量索引是派生缓存，可随时重建
+
+## Usage
+
+```bash
+pip install memsearch
+memsearch config init
+memsearch index ~/path/to/memory/
+memsearch search "what caching solution did we pick?"
+memsearch watch ~/path/to/memory/
+# 本地模式（无需 API Key）
+pip install "memsearch[local]"
+memsearch config set embedding.provider local
+memsearch index ~/path/to/memory/
+```
+
+## Connections
+- [[Milvus]] — 向量数据库后端
+- [[OpenClaw]] — 上层应用框架，memsearch 为其 Markdown 记忆提供语义搜索
+- [[Hybrid Search]] — memsearch 使用的搜索策略
+- [[Content Hashing]] — memsearch 的增量索引机制
--- a/wiki/entities/Milvus.md
+++ b/wiki/entities/Milvus.md
@@ -0,0 +1,32 @@
+---
+title: "Milvus"
+type: entity
+tags: [vector-db, embedding, rag, open-source]
+sources: [semantic-memory-search]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- Milvus
+
+## Definition
+
+Milvus 是开源的分布式向量数据库，专为相似性搜索场景设计，支持十亿级向量数据的存储与检索。是 [[memsearch]] 的底层向量存储和检索引擎。
+
+## Key Characteristics
+
+- **高维向量检索**：支持 ANN（近似最近邻）索引如 HNSW、IVF、PQ，实现毫秒级检索
+- **多索引类型**：HNSW（高召回高速度）、IVF（聚类加速）、PQ（压缩存储）
+- **分布式架构**：支持水平扩展，处理海量向量
+- **多语言 SDK**：Python、Go、Java、RESTful API
+- **元数据过滤**：支持在向量检索的同时做属性过滤
+
+## Role in RAG Stack
+
+Milvus 作为向量数据库负责存储文档 Embedding 向量，在 [[Knowledge-Base-RAG]] 和 [[semantic-memory-search]] 场景中是检索层的核心基础设施。
+
+## Connections
+- [[memsearch]] — 使用 Milvus 作为向量后端的语义搜索库
+- [[Vector-Embedding]] — Milvus 存储的向量来源
+- [[Knowledge-Base-RAG]] — Milvus 作为知识库的向量存储层
+- [[semantic-memory-search]] — Milvus 为 OpenClaw 记忆提供向量检索能力
--- a/wiki/entities/OpenClaw.md
+++ b/wiki/entities/OpenClaw.md
@@ -2,7 +2,7 @@
 title: "OpenClaw"
 type: entity
 tags: [OpenClaw, Agent, Workspace, Multi-Agent]
-sources: [multi-agent-team, 万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest, self-healing-home-server, custom-morning-brief, second-brain]
+sources: [multi-agent-team, 万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest, self-healing-home-server, custom-morning-brief, second-brain, n8n-workflow-orchestration]
 last_updated: 2026-03-21
 ---

--- a/wiki/entities/Prismer-AI.md
+++ b/wiki/entities/Prismer-AI.md
@@ -0,0 +1,16 @@
+---
+title: "Prismer AI"
+type: entity
+tags: []
+sources: [arxiv-paper-reader]
+last_updated: 2026-04-17
+---
+
+## Entity Overview
+**Prismer AI** 是一个开源 AI Agent 技能库维护组织，通过 GitHub 仓库 [Prismer-AI/Prismer](https://github.com/Prismer-AI/Prismer) 提供多种即装即用的 Agent skill，包括 `arxiv-reader` 等。
+
+## Aliases
+- Prismer
+
+## Role in Wiki
+- `arxiv-reader` skill 的维护方，提供 3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`
--- a/wiki/entities/Simon-Hoiberg.md
+++ b/wiki/entities/Simon-Hoiberg.md
@@ -0,0 +1,27 @@
+---
+title: "Simon Hoiberg"
+type: entity
+tags: [n8n, openclaw, workflow-automation, productivity]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Simon Hoiberg
+- SimonHøiberg
+
+## Definition
+
+Simon Hoiberg 是一位专注于 AI Agent 和工作流自动化的开发者和技术布道者。他提出了 **OpenClaw + n8n Webhook 代理模式**——通过让 AI Agent 将外部 API 交互委托给 n8n 工作流，实现凭证隔离、可观测性和 token 节省三大收益。
+
+## Key Contributions
+
+- 提出了 OpenClaw + n8n 集成的核心思路：Agent 从不接触 API 凭证，所有外部调用通过 n8n Webhook 代理
+- 强调 "build → test → lock" 安全工作流生命周期
+- 维护 [openclaw-n8n-stack](https://github.com/caprihan/openclaw-n8n-stack) Docker Compose 堆栈
+
+## Connections
+- [[n8n-workflow-orchestration]] — 提出该模式的核心来源
+- [[openclaw-n8n-stack]] — Docker 部署方案
+- [[OpenClaw]] — 该模式中的 Agent 端
+- [[n8n]] — 该模式中的执行代理端
--- a/wiki/entities/SparkryAI.md
+++ b/wiki/entities/SparkryAI.md
@@ -0,0 +1,25 @@
+---
+title: "Sparkry AI"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Sparkry AI
+
+## Role
+OpenClaw 实践者社区作者，发布了详细的 OpenClaw 实测报告《24 Hours with OpenClaw》。
+
+## Key Contribution
+实测记录了 OpenClaw 的环境消息监控（Ambient Message Monitoring）机制：
+- **场景**：妻子收到牙医预约短信
+- **Agent 行为**：自动创建日历事件并附加 30 分钟行车缓冲，无需用户请求
+- **用户反馈**："我从没要求它这样做。它就是知道这是我想要的。"
+
+## Source
+[Sparkry AI Substack — 24 Hours with OpenClaw](https://sparkryai.substack.com/p/24-hours-with-openclaw-the-ai-setup)
+
+## Also Referenced In
+- [[family-calendar-household-assistant]]
+- [[OpenClaw]]（在 OpenClaw Showcase 中也有引用）
--- a/wiki/entities/TweetClaw.md
+++ b/wiki/entities/TweetClaw.md
@@ -0,0 +1,36 @@
+---
+title: "TweetClaw"
+type: entity
+tags: ["openclaw", "twitter", "x", "plugin", "automation"]
+last_updated: 2026-04-17
+---
+
+## Overview
+TweetClaw 是 OpenClaw 的 X/Twitter 插件，通过 @xquik/tweetclaw npm 包安装，将 Agent 连接到 X/Twitter 官方托管 API，实现自然语言驱动的全功能 X/Twitter 操作。
+
+## Type
+- **Plugin**（OpenClaw Plugin）
+
+## Key Capabilities
+- **Post & Engage**：发帖、回复推文、点赞、转发、关注/取消关注、发送私信
+- **Search & Extract**：搜索推文和用户，提取关注者、点赞者、转发者、引用推文者、列表成员
+- **Giveaways**：从推文互动用户中随机抽取获奖者，支持可配置筛选条件（最低粉丝数、账号年龄、关键词要求）
+- **Monitors**：监控指定账号的新推文或粉丝变化并发送通知
+
+## Installation
+```text
+openclaw plugins install @xquik/tweetclaw
+```
+
+## Related Links
+- [GitHub Repository](https://github.com/Xquik-dev/tweetclaw)
+- [npm Package](https://www.npmjs.com/package/@xquik/tweetclaw)
+
+## Connections
+- [[OpenClaw]] — TweetClaw 的宿主平台，通过 OpenClaw Plugin 系统安装和运行
+- [[x-twitter-automation]] — TweetClaw 的应用场景，通过该插件实现 X/Twitter 全功能自动化
+- [[Xquik-dev]] — TweetClaw 的开发公司
+
+## Notes
+- 所有 API 操作通过 TweetClaw 托管服务完成，无需浏览器 Cookie、无爬虫脚本、无凭证暴露
+- 与 [[n8n-workflow-orchestration]] 互补：n8n 可作为凭证托管层，TweetClaw 提供具体 API 操作能力
--- a/wiki/entities/n8n.md
+++ b/wiki/entities/n8n.md
@@ -18,6 +18,7 @@ last_updated: 2025-12-31
 - 可与 AI 模型集成（Claude、OpenAI、LangChain 等）

 ## Related
+- [n8n-workflow-orchestration]
 - [[n8n-mcp]] — Claude 与 N8N 的连接桥梁
 - [[工作流自动化]] — 相关概念
 - [[Webhook]] — N8N 常用触发方式
--- a/wiki/entities/openclaw-n8n-stack.md
+++ b/wiki/entities/openclaw-n8n-stack.md
@@ -0,0 +1,27 @@
+---
+title: "openclaw-n8n-stack"
+type: entity
+tags: [openclaw, n8n, docker, self-hosted]
+sources: [n8n-workflow-orchestration]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- openclaw-n8n-stack
+
+## Definition
+
+[openclaw-n8n-stack](https://github.com/caprihan/openclaw-n8n-stack) 是由社区维护的 Docker Compose 堆栈，一键部署 OpenClaw + n8n 共享 Docker 网络环境，是 [[n8n-workflow-orchestration]] 所述集成模式的最简入场方案。
+
+## Key Features
+- OpenClaw 运行在端口 3456
+- n8n 运行在端口 5678
+- 共享 Docker 网络：`http://n8n:5678/webhook/...` 可直接访问
+- 预置工作流模板（多 LLM 事实核查、邮件分类、社交监控等）
+- 包含 Anthropic API Key 配置模板
+
+## Connections
+- [[n8n-workflow-orchestration]] — 主要来源
+- [[Docker]] — 部署底座
+- [[OpenClaw]] — 栈内 Agent 组件
+- [[n8n]] — 栈内工作流引擎
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,8 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-22] [Semantic Memory Search](sources/semantic-memory-search.md)
+- [2026-04-22] [OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub](sources/aionui-cowork-desktop.md)
 - [2026-04-22] [Family Calendar Aggregation & Household Assistant](sources/family-calendar-household-assistant.md)
 - [2026-04-22] [Multi-Source Tech News Digest](sources/multi-source-tech-news-digest.md)
 - [2026-04-22] [X/Twitter Automation from Chat](sources/x-twitter-automation.md)
@@ -411,9 +413,7 @@
 - [2026-04-17] [x-account-analysis](sources/x-account-analysis.md) — (expected: wiki/sources/x-account-analysis.md — source missing)
 - [2026-04-17] [phone-call-notifications](sources/phone-call-notifications.md) — (expected: wiki/sources/phone-call-notifications.md — source missing)
 - [2026-04-17] [autonomous-game-dev-pipeline](sources/autonomous-game-dev-pipeline.md) — (expected: wiki/sources/autonomous-game-dev-pipeline.md — source missing)
- [2026-04-17] [arxiv-paper-reader](sources/arxiv-paper-reader.md) — (expected: wiki/sources/arxiv-paper-reader.md — source missing)
- [2026-04-17] [semantic-memory-search](sources/semantic-memory-search.md) — (expected: wiki/sources/semantic-memory-search.md — source missing)
- [2026-04-17] [AionUi Desktop Cowork](sources/aionui-cowork-desktop.md) — 通过 AionUi 桌面应用将 OpenClaw 作为可视化 Cowork Agent 运行，支持远程救援和多 Agent 统一管理
+- [2026-04-17] [arXiv Paper Reader](sources/arxiv-paper-reader.md) — AI Agent 驱动的 arXiv 论文阅读助手，通过 arxiv-reader skill 实现对话式论文浏览、摘要对比和选择性细读，无需离开工作区
 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
 - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
 - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
@@ -537,6 +537,7 @@
 - [ADK](entities/ADK.md)
 - [AdsPower](entities/AdsPower.md)
 - [Agentic-AI](entities/Agentic-AI.md)
+- [AionUi](entities/AionUi.md)
 - [aitmpl.com](entities/aitmpl.com.md)
 - [Alertmanager](entities/Alertmanager.md)
 - [Alex-Finn](entities/Alex-Finn.md)
@@ -607,7 +608,9 @@
 - [Mac-Mini-M4](entities/Mac-Mini-M4.md)
 - [MariaDB](entities/MariaDB.md)
 - [MCP（Model Context Protocol）](entities/MCP（Model Context Protocol）.md)
+- [Memsearch](entities/Memsearch.md)
 - [MerlinClash插件](entities/MerlinClash插件.md)
+- [Milvus](entities/Milvus.md)
 - [MinIO](entities/MinIO.md)
 - [mission-center](entities/mission-center.md)
 - [n8n](entities/n8n.md)
@@ -728,11 +731,13 @@
 - [Compliance-Automation](concepts/Compliance-Automation.md)
 - [Configuration-Management](concepts/Configuration-Management.md)
 - [Content Automation](concepts/Content Automation.md)
+- [Content-Hashing](concepts/Content-Hashing.md)
 - [Content-Ingestion](concepts/Content-Ingestion.md)
 - [Continuous-Deployment](concepts/Continuous-Deployment.md)
 - [Continuous-Integration](concepts/Continuous-Integration.md)
 - [Conversational-Interface](concepts/Conversational-Interface.md)
 - [Cost-Optimization](concepts/Cost-Optimization.md)
+- [CoworkWorkspace](concepts/CoworkWorkspace.md)
 - [Credential-Isolation](concepts/Credential-Isolation.md)
 - [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md)
 - [Cron定时任务](concepts/Cron定时任务.md)
@@ -773,6 +778,7 @@
 - [Failover](concepts/Failover.md)
 - [Feature-Flag](concepts/Feature-Flag.md)
 - [File-System-First-UI](concepts/File-System-First-UI.md)
+- [File-Watcher](concepts/File-Watcher.md)
 - [FinOps](concepts/FinOps.md)
 - [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md)
 - [Full-Draft-Generation](concepts/Full-Draft-Generation.md)
@@ -791,6 +797,7 @@
 - [HTTPS自动化证书](concepts/HTTPS自动化证书.md)
 - [Human-Handoff](concepts/Human-Handoff.md)
 - [Hybrid-Cloud](concepts/Hybrid-Cloud.md)
+- [Hybrid-Search](concepts/Hybrid-Search.md)
 - [Hyperautomation](concepts/Hyperautomation.md)
 - [IAST](concepts/IAST.md)
 - [IDENTITY.md](concepts/IDENTITY.md.md)
@@ -815,6 +822,7 @@
 - [Lead-Time](concepts/Lead-Time.md)
 - [Local-first-Git](concepts/Local-first-Git.md)
 - [Lockable-Workflow](concepts/Lockable-Workflow.md)
+- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md)
 - [MeetingNotes](concepts/MeetingNotes.md)
 - [MEMORY.md](concepts/MEMORY.md.md)
 - [Micro-Recovery](concepts/Micro-Recovery.md)
@@ -823,6 +831,7 @@
 - [MTTD](concepts/MTTD.md)
 - [MTTR](concepts/MTTR.md)
 - [Multi-Account-Deployment](concepts/Multi-Account-Deployment.md)
+- [Multi-AgentHub](concepts/Multi-AgentHub.md)
 - [Multi-AI-Review](concepts/Multi-AI-Review.md)
 - [Multi-Channel-Delivery](concepts/Multi-Channel-Delivery.md)
 - [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md)
@@ -861,12 +870,14 @@
 - [PUID-PGID](concepts/PUID-PGID.md)
 - [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md)
 - [Reality-Signal](concepts/Reality-Signal.md)
+- [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md)
 - [Recurring-Task](concepts/Recurring-Task.md)
 - [Recurring-Tasks](concepts/Recurring-Tasks.md)
 - [Redis缓存](concepts/Redis缓存.md)
 - [Release-Management](concepts/Release-Management.md)
 - [Remote-SSH](concepts/Remote-SSH.md)
 - [RemoteDevelopment](concepts/RemoteDevelopment.md)
+- [RemoteRescuePattern](concepts/RemoteRescuePattern.md)
 - [Reviewer](concepts/Reviewer.md)
 - [Rightsizing](concepts/Rightsizing.md)
 - [Risk-Mitigation](concepts/Risk-Mitigation.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,18 @@
+## [2026-04-22] ingest | Semantic Memory Search
+- Source file: Agent/usecases/semantic-memory-search.md
+- Status: ✅ 成功摄入
+- Summary: 通过 memsearch（基于 Milvus 向量数据库）为 OpenClaw Markdown 记忆添加语义搜索能力——用自然语言提问即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引节省成本；文件监视器自动重建索引；支持本地模式无需 API Key。核心理念：Markdown 是唯一真相，向量索引是派生缓存。
+- Concepts created: [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]]
+- Entities created: [[memsearch]], [[Milvus]]
+- Source page: wiki/sources/semantic-memory-search.md
+- Notes:
+  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
+  - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[semantic-memory-search]] 段落，在 Key Concepts 列表新增 6 个新概念
+  - 创建 Entity 页面：Memsearch.md（ZillizTech memsearch CLI/库）、Milvus.md（开源向量数据库）
+  - 创建 Concept 页面：Hybrid-Search.md（混合搜索策略）、Reciprocal-Rank-Fusion.md（排名融合算法）、Content-Hashing.md（增量索引机制）、File-Watcher.md（自动重建索引）
+  - 与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景——后者侧重 URL 入库，前者侧重现有 Markdown 文件的语义索引
+  - 冲突检测：wiki/concepts/Semantic-Search.md 已引用 [[Hybrid Search]]，与本 Source 一致；wiki/concepts/Knowledge-Base-RAG.md 有 Hybrid Search 说明，与本 Source 一致，暂无实质冲突
+
 ## [2026-04-22] ingest | OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub
 - Source file: Agent/usecases/aionui-cowork-desktop.md
 - Status: ✅ 成功摄入
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -43,13 +43,15 @@ A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in

 **[[YouTube-Content-Pipeline]]**：AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；同时维护 90 天视频目录（播放量 + 主题分析）避免选题重复，通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现。与 [[Content-Factory]] 共享并行子 Agent 执行模式。

+**[[arXiv-Paper-Reader]]**：AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科；与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式。
+
 **[[Daily Reddit Digest]]**：AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 [[OpenClaw]] + `reddit-readonly` skill，每日定时抓取指定 Subreddit 的热门/最新/最高赞帖子，AI 记忆用户偏好并持续优化精选规则（如排除表情包类内容）。纯读取模式，无需认证。属 [[Daily YouTube Digest]] 同款模式（定时 + AI 摘要 + 偏好学习）的 Reddit 垂直场景。

 **Multi-Agent Content Factory**: [[content-factory]] 是基于 Discord 频道的多 Agent 内容工厂，通过 Research Agent → Writing Agent → Thumbnail Agent 链式协作，实现内容创作全流程自动化（研究→写作→设计）。每天定时运行，创作者次日醒来即可收获成品内容。[[OpenClaw]] 提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排。

 **X/Twitter Automation**: [[x-twitter-automation]] 是基于 [[OpenClaw]] 的 X/Twitter 全功能自动化方案——通过 TweetClaw 插件（`@xquik/tweetclaw`）连接 X/Twitter 托管 API，实现自然语言驱动的发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人和账号监控。支持可配置的抽奖筛选条件（最低粉丝数/账号年龄/关键词），账号监控可追踪指定用户的新推文或粉丝变化并推送通知。所有操作通过托管 API 完成，无 Cookie、无爬虫、无凭证暴露。与 [[x-account-analysis]] 互补（分析 vs 操作），可与 [[content-factory]] 配合扩展社交媒体内容发布能力。

-Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]]
+Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]], [[arXiv-API]], [[LaTeX-扁平化]], [[本地缓存]], [[论文摘要批量获取]]

 ### n8n Workflow Automation
 [[n8n]] 是开源工作流自动化平台，支持 Trigger 节点监听外部事件。n8n 可与 [[Telegram]] 集成，接收机器人消息触发工作流；也可与 YouTube API 集成实现订阅监控。Telegram 集成时需要通过 `WEBHOOK_URL` 环境变量（设为 HTTPS 地址）解决 Telegram 对 Webhook 协议的要求，否则会报 "bad webhook: An HTTPS URL must be provided for webhook" 错误。
@@ -119,7 +121,9 @@ Obsidian plugins, blogwatcher RSS monitoring, Quartz static site generation, pro

 **Personal Knowledge Base (RAG)**：基于 [[OpenClaw]] 的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索（"我保存的关于 LLM memory 的内容？"），返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**，无需专用 App。[[ClawHub]] 提供 knowledge-base skill 一键安装。与 [[Second Brain]] 同属 OpenClaw 持久记忆能力，Second Brain 侧重对话记忆，本方案侧重结构化知识检索。

-Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Templater]], [[QuickAdd]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[间隔重复]], [[看板]], [[动态模板]], [[双向链接]], [[Daily Notes]], [[Event Sourcing]], [[Second Brain]], [[Personal CRM]], [[Knowledge-Base-RAG]], [[Zero-Friction-Capture]], [[Semantic-Search]], [[Content-Ingestion]]
+**[[semantic-memory-search]]**：通过 [[memsearch]]（基于 [[Milvus]] 向量数据库）为 OpenClaw 的 Markdown 记忆文件添加语义搜索能力——用自然语言提问（"我们选了哪个缓存方案？"）即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF 重排）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引，仅重新嵌入变更内容；支持本地模式（无需 API Key）。Markdown 文件是唯一真相，向量索引随时可重建。与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景。
+
+Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Templater]], [[QuickAdd]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[间隔重复]], [[看板]], [[动态模板]], [[双向链接]], [[Daily Notes]], [[Event Sourcing]], [[Second Brain]], [[Personal CRM]], [[Knowledge-Base-RAG]], [[Zero-Friction-Capture]], [[Semantic-Search]], [[Content-Ingestion]], [[semantic-memory-search]], [[memsearch]], [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]]

 ### 个人品牌与一人公司
 系统性的个人商业化方法论：**天才地带自检**（识别能产生心流的活动）→ **底层能力挖掘**（追溯童年、毫不费力、底层通用三个维度）→ **心理陷阱识别**（愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱）→ **Ikigai 框架定位**（热情 × 擅长 × 市场需求 × 报酬）→ **赛道验证**（搜索意图分析、支付意愿测试、落地页测试、预售验证）→ **产品体系设计**（引流免费PDF → ¥199入门工具 → ¥4999核心特训营 → ¥20,000/月高价咨询）→ **内容矩阵构建**（核心主题 × 内容形式，反向金字塔内容法，Build in Public）→ **销售漏斗搭建**（获客 → 激活 → 转化，价格锚定与诱饵效应）。
--- a/wiki/sources/arxiv-paper-reader.md
+++ b/wiki/sources/arxiv-paper-reader.md
@@ -0,0 +1,48 @@
+---
+title: "arXiv Paper Reader"
+type: source
+tags: []
+date: 2026-04-17
+---
+
+## Source File
+- [[Agent/usecases/arxiv-paper-reader]]
+
+## Summary（用中文描述）
+- 核心主题：基于 AI Agent 的 arXiv 论文阅读助手工作流
+- 问题域：arXiv 论文阅读的痛点——下载 PDF、切换论文丢失上下文、LaTeX 符号难以解析
+- 方法/机制：通过 `arxiv-reader` skill（3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）实现纯 Node.js 离线工作流，直接从 arXiv 下载 LaTeX 源码并自动扁平化展开；本地缓存实现重复访问秒级响应
+- 结论/价值：将 AI Agent 变成研究阅读助手，支持摘要浏览、对比排序、选择性细读和会话式分析
+
+## Key Claims（用中文描述）
+- Agent + arxiv-reader skill → 可对话式阅读任意 arXiv 论文，无需离开工作区
+- LaTeX 源码自动扁平化展开 → 消除密集数学符号解析障碍
+- 本地缓存机制 → 重复访问论文即时响应
+- 多论文批量摘要对比 → 帮助快速筛选阅读优先级
+- 无需 Docker/Python，Node.js 内置模块即可运行 → 零依赖部署
+
+## Key Quotes
+> "Reading arXiv papers means downloading PDFs, losing context when switching between papers, and struggling to parse dense LaTeX notation." — 论文阅读痛点描述
+> "Results are cached locally — revisiting a paper is instant." — 本地缓存的价值
+> "No Docker or Python required — the skill runs standalone using Node.js built-ins." — 零依赖特性
+
+## Key Concepts
+- [[arXiv-API]]：论文元数据和 PDF 抓取的数据来源
+- [[LaTeX-扁平化]]：自动展开 LaTeX include 语句，将多文件论文合成为单一流文本
+- [[本地缓存]]：论文解析结果本地持久化，重复访问避免重复下载和解析
+- [[论文摘要批量获取]]：同时获取多篇论文摘要并生成对比表格
+
+## Key Entities
+- [[Prismer-AI]]：`arxiv-reader` skill 的维护方（GitHub 仓库）
+- [[OpenClaw]]：推荐承载该工作流的 AI Agent 框架
+
+## Connections
+- [[YouTube-Content-Pipeline]] ← 扩展 ← [[arXiv-Paper-Reader]]
+  - 后者扩展：论文阅读发现 → 视频内容创作选题研究
+- [[academic-historian]] ← 相关 ← [[arXiv-Paper-Reader]]
+  - 同属学术研究场景，arXiv Reader 侧重理工科论文，academic-historian 侧重人文社科
+- [[Semantic-Memory-Search]] ← 互补 ← [[arXiv-Paper-Reader]]
+  - 两者结合：论文阅读 → 关键观点存入语义记忆 → 后续语义检索
+
+## Contradictions
+- 无已知冲突内容
--- a/wiki/sources/family-calendar-household-assistant.md
+++ b/wiki/sources/family-calendar-household-assistant.md
@@ -0,0 +1,66 @@
+---
+title: "Family Calendar Aggregation & Household Assistant"
+type: source
+tags: []
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/family-calendar-household-assistant]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 作为家庭日程协调中心，聚合多源日历、提供晨间简报、监控消息自动创建日历事件、管理家庭库存和购物清单。
+- 问题域：现代家庭面临 5+ 个日历分散在不同平台（工作/个人/家庭/学校/课外），消息中的预约确认无人处理，家庭物资管理依赖零散短信。
+- 方法/机制：
+  - 日历聚合层：汇聚 Google Calendar、Apple Calendar、学校 PDF 邮件附件等多源日历，生成统一晨间简报
+  - 环境消息监控（Ambient Message Monitoring）：每 15 分钟扫描 iMessage，识别预约模式（"confirmed for..."、"moved to Saturday at 3pm"），自动创建日历事件并附加行车时间缓冲
+  - 家庭库存追踪：JSON 文件存储物品位置/数量，支持照片 OCR 更新、小票识别
+  - 共享家庭 Telegram 频道：双方伴侣均可查询，建立信任和错误早期发现
+- 结论/价值：Ambient（主动环境感知）比 Active（被动等待指令）更有价值——最大的突破是 Agent 在不被要求的情况下主动行动；Mac Mini 是该场景的最优硬件选择（iMessage 集成 + 始终在线）。
+
+## Key Claims（用中文描述）
+- 多日历分散导致重要事件遗漏：工作日历有安全限制无法共享，学校日历以 PDF 或手写网站形式存在，人工逐一检查每日不可持续。
+- 环境消息监控是核心差异化因素：Agent 被动监听消息流，在识别到可执行项时自动采取行动（"我从没要求它这样做。它就是知道这是我想要的。"）。
+- Mac Mini 是家庭助理场景的最优硬件：支持 iMessage 集成、Apple Calendar，始终在线，是该方案的甜点配置。
+- 照片输入被低估：拍摄学校日历 PDF 或冰箱内容的照片比打字更快，视觉模型处理效果良好。
+- 从只读开始：先启用日历读取和消息监控，再启用写入操作（创建事件、发送消息）。
+
+## Key Quotes
+> "Ambient > active: The biggest unlock is the agent acting without being asked. Detecting an appointment in a text message and creating a calendar event with driving buffers — 'I didn't ask it to do that. It just knew that's what I'd want.'"
+— Sparkry AI, 24 Hours with OpenClaw 实测案例（妻子收到牙医预约短信，OpenClaw 自动创建日历事件并附加 30 分钟行车缓冲）
+
+> "Copying events across calendars works well until I forget and one slips through the cracks."
+— angiolillo, Hacker News 用户
+
+> "How much milk do we have?" requires physically checking the fridge, then the basement pantry, then texting back.
+— 家庭物资协调痛点描述
+
+## Key Concepts
+- [[Morning Briefing]]：每天定时（8:00 AM）聚合所有家庭日历生成统一简报，通过 Telegram/Slack 家庭频道投递；本页面是 Morning Briefing 的家庭场景垂直实现。
+- [[Ambient Message Monitoring]]：环境消息监控——Agent 被动监听消息流而非等待用户主动询问，在识别到可执行项时自动创建日历事件或提醒，是本系统的核心差异化机制。
+- [[Household Inventory Tracking]]：家庭物资库存追踪——JSON 文件存储物品名称/数量/位置（冰箱/食品储藏室/地下室），支持照片 OCR、小票识别和自然语言更新。
+- [[Calendar Aggregation]]：多源日历聚合——整合 Google Calendar、Apple Calendar、学校 PDF 邮件附件等多个来源，生成统一视图。
+- [[Driving Time Buffer]]：行车时间缓冲——自动在预约事件前后各添加 30 分钟的通勤时间块。
+- [[Grocery Coordination]]：购物协调——跨食谱去重原料、追踪低库存物品、自动生成购物清单。
+
+## Key Entities
+- [[OpenClaw]]：核心 Agent 框架，支持持久记忆和工作流编排，运行本家庭助理系统的底层引擎。
+- [[Sparkry AI]]：OpenClaw 实践者社区，发布了"24 Hours with OpenClaw"实测文章，是 Ambient Message Monitoring 机制的实测来源。
+- Brandon Wang：Clawdbot "Linguini" 的作者，Mac Mini 家庭部署方案——通过 iMessage 和 Slack 协调家庭物流、处理照片库存、自动跟进提醒。
+- angiolillo：Hacker News 用户，分享了多日历管理痛点。
+- dns_snek：Hacker News 用户，提到家庭物资管理挑战（"我5秒前放的东西就忘了在哪...东西过期是个大问题"）。
+- Google Calendar：主要日历来源之一。
+- Apple Calendar：Mac Mini 本地日历源。
+
+## Connections
+- [[Second Brain]] ← 共享 ← [[Family Calendar Household Assistant]]
+  - 两者都基于 [[OpenClaw]] 的持久记忆能力；Second Brain 侧重对话记忆捕获，本方案侧重家庭协调场景。
+- [[Custom Morning Brief]] ← 类似模式 ← [[Family Calendar Household Assistant]]
+  - 同属定时晨间简报场景，但 Custom Morning Brief 面向个人，本方案面向家庭。
+- [[phone-based-personal-assistant]] ← 互补 ← [[Family Calendar Household Assistant]]
+  - 语音入口覆盖无屏场景，文字入口（iMessage/Telegram）覆盖图文交互。
+- [[personal-crm]] ← 类似技术栈 ← [[Family Calendar Household Assistant]]
+  - 均通过 Telegram Topic 或 Slack Channel 提供自然语言查询接口。
+
+## Contradictions
+- 无已知冲突。
--- a/wiki/sources/knowledge-base-rag.md
+++ b/wiki/sources/knowledge-base-rag.md
@@ -0,0 +1,48 @@
+---
+title: "Personal Knowledge Base (RAG)"
+type: source
+tags: []
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/knowledge-base-rag]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 驱动的个人知识库 RAG 系统，实现"零摩擦保存、语义检索"的工作流
+- 问题域：书签堆积却无法找到所需内容——阅读的文章、推文、视频随时间遗忘
+- 方法/机制：
+  - 通过 Telegram Topic 或 Slack Channel 一键摄取引擎（URL 自动抓取网页/推文/YouTube 字幕/PDF）
+  - Embedding 向量化存储，支持语义搜索（"我保存的关于 LLM memory 的内容？"）
+  - 集成 OpenClaw knowledge-base skill，工作流间自动查询知识库
+- 结论/价值：**捕获像发短信一样简单，检索像搜索一样容易**，无需专用 App
+
+## Key Claims（用中文描述）
+- 个人知识积累面临"阅读多、保存多、找到难"的困境
+- 通过 Telegram/Slack 直接投递 URL，自动解析内容并索引至知识库
+- 语义搜索超越关键词匹配，返回排名结果并附带来源引用
+- 知识库可被其他工作流（如视频选题流水线）主动调用
+
+## Key Quotes
+> "You read articles, tweets, and watch videos all day but can never find that one thing you saw last week. Bookmarks pile up and become useless." — 痛点描述
+
+## Key Concepts
+- [[Knowledge-Base-RAG]]：Retrieval-Augmented Generation，个人知识库的核心架构，详见 [[Knowledge-Base-RAG]] 概念页
+- [[Zero-Friction-Capture]]：零摩擦捕获——任何内容只需发消息即可入库，无需切换 App
+- [[Semantic-Search]]：基于 Embedding 向量相似度的语义检索，而非关键词匹配
+- [[Content-Ingestion]]：URL 内容自动解析与分块（Chunking）入库
+
+## Key Entities
+- [[OpenClaw]]：多 Agent 框架，提供 `knowledge-base` skill 实现 RAG 工作流
+- [[ClawHub]]：OpenClaw Skill 市场，knowledge-base skill 的分发来源
+- [[Telegram]]：知识库投递入口（Topic 路由）
+- [[Slack]]：知识库投递入口（Channel）
+
+## Connections
+- [[Second Brain]] ← extends ← [[Knowledge-Base-RAG]]：个人知识库 RAG 是 Second Brain 的检索底层
+- [[YouTube-Content-Pipeline]] ← queries ← [[Knowledge-Base-RAG]]：视频选题工作流自动查询知识库避免重复选题
+- [[Pre-Build-Idea-Validator]] ← queries ← [[Knowledge-Base-RAG]]：项目启动前查询知识库确认是否已做过类似项目
+- [[Content-Ingestion]] ← supports ← [[Semantic-Search]]：内容被抓取才能被搜索
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的内容冲突
--- a/wiki/sources/local-crm-framework.md
+++ b/wiki/sources/local-crm-framework.md
@@ -0,0 +1,56 @@
+---
+title: "Local CRM Framework with DenchClaw"
+type: source
+tags: ["openclaw", "crm", "automation", "duckdb", "browser-automation"]
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/local-crm-framework.md]]
+
+## Summary（用中文描述）
+- 核心主题：DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台的完整框架
+- 问题域：OpenClaw 作为基础原语功能强大，但用于真实商业工作流（线索追踪、外联、管道管理）需要集成数据库、UI、浏览器自动化、消息平台等多个工具，设置复杂易碎
+- 方法/机制：`npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化 + Skills）；所有设置/视图以文件（YAML/Markdown）存储，OpenClaw 可直接读写修改 UI；Chrome Profile 克隆继承浏览器认证状态
+- 结论/价值：Cursor 级别的 UX 用于商业运营，无需 Docker/环境配置，通过自然语言管理完整的 CRM 管道
+
+## Key Claims（用中文描述）
+- DenchClaw 一键安装（`npx denchclaw`）自动配置 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器和 Skills，无需手动设置
+- 自然语言 CRM 查询（"显示员工>5人的公司"）实时更新视图，无需手动过滤器操作
+- Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据，无需 OAuth 流程
+- 所有设置/视图/过滤器以 YAML/Markdown 文件存储，Agent 可像编辑代码一样自然地修改 UI
+- DuckDB 是嵌入式数据库的最佳选择：最小体积、完全 SQL 支持、无服务器/凭证/网络依赖
+- DenchClaw 内置三种 Skills：CRM Skill（对象/字段/视图）、App Builder Skill（Web 应用构建）、Browser Automation Skill（浏览器自动化）
+
+## Key Quotes
+> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
+> — DenchClaw 的核心设计哲学：文件系统即 Agent 原生 UI
+
+> "DuckDB is the sweet spot: Smallest, most performant embedded database that still supports full SQL. No server process, no credentials, no network — just a file."
+> — DuckDB 作为嵌入式 CRM 数据库的理由
+
+> "Chrome profile cloning is a superpower: Instead of fighting OAuth flows and API rate limits, DenchClaw copies your browser's auth state. The agent sees what you see, does what you do."
+> — Chrome Profile 克隆实现无缝浏览器自动化
+
+> "One `npx` command beats a weekend of setup: The entire stack installs and configures itself. No Docker, no env files, no dependency hell."
+> — 一键安装 vs 手动配置的对比
+
+## Key Concepts
+- [[File-System-First UI]]：所有设置/视图以文件形式存储，Agent 可直接读写，无需 API 抽象层
+- [[Chrome Profile Cloning]]：复制浏览器认证状态而非依赖 OAuth，使 Agent 继承用户的登录会话
+- [[One-Command-Setup]]：通过单一命令自动安装和配置完整技术栈，消除环境配置摩擦
+- [[DuckDB]]：嵌入式分析型数据库，无服务器、零配置、完全 SQL 支持
+
+## Key Entities
+- [[DenchClaw]]：MIT 许可证开源框架，将 OpenClaw 转化为本地 CRM/SaaS 平台
+- [[OpenClaw]]：多 Agent 框架，DenchClaw 的底层 Agent 引擎
+- [[DuckDB]]：SQLite 替代品，Analytical DBMS，用于 CRM 结构化数据存储
+- [[HubSpot]]：CRM 平台示例，DenchClaw 可导入其数据
+
+## Connections
+- [[Second Brain]] ← 相关 ← [[local-crm-framework]]：两者均基于 OpenClaw 的记忆/持久化能力
+- [[personal-crm]] ← 相关 ← [[local-crm-framework]]：个人 CRM 场景的不同实现方案
+- [[multi-channel-assistant]] ← 共享技术栈 ← [[local-crm-framework]]：均使用 Telegram/消息平台作为交互入口
+
+## Contradictions
+（暂无发现与其他 Wiki 页面的内容冲突）
--- a/wiki/sources/multi-source-tech-news-digest.md
+++ b/wiki/sources/multi-source-tech-news-digest.md
@@ -0,0 +1,51 @@
+---
+title: "Multi-Source Tech News Digest"
+type: source
+tags: []
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/multi-source-tech-news-digest.md]]
+
+## Summary（用中文描述）
+- 核心主题：多源科技新闻自动聚合、评分与投递系统，通过 AI Agent 驱动的四层数据管道，整合 RSS、Twitter/X、GitHub Releases 和网页搜索共 109+ 信息源，生成个性化每日技术简报。
+- 问题域：AI/开源/前沿技术从业者需要每日手动检查数十个 RSS 订阅、Twitter 账号、GitHub 仓库和新闻网站，人工策展耗时且现有工具缺乏质量过滤或配置复杂。
+- 方法/机制：四层数据管道（RSS 46 源 + Twitter/X KOL 44 账号 + GitHub Releases 19 仓库 + Brave Search 网页搜索 4 个主题）→ 合并去重（标题相似度）→ 质量评分（优先级来源 +3，多来源 +5，时效性 +2，互动量 +1）→ Discord/Email/Telegram 投递。
+- 结论/价值：通过自然语言配置，完全可定制，30 秒内添加自定义来源，替代人工信息策展。
+
+## Key Claims（用中文描述）
+- 多源聚合系统通过四层数据管道（RSS + Twitter/X + GitHub Releases + Web Search）将科技新闻策展效率提升至接近自动化水平。
+- 质量评分机制（priority source +3, multi-source +5, recency +2, engagement +1）有效过滤噪音，提升简报价值。
+- 完全自然语言驱动——用户通过对话即可添加自定义 RSS/Twitter/GitHub 来源，无需手动配置。
+- 支持 Discord、Email、Telegram 三通道投递，适配不同用户习惯。
+
+## Key Quotes
+> "The framework is fully customizable — add your own RSS feeds, Twitter handles, GitHub repos, or search queries in 30 seconds." — 功能描述，强调零配置门槛
+> "All articles are merged, deduplicated by title similarity, and quality-scored (priority source +3, multi-source +5, recency +2, engagement +1)." — 核心算法逻辑
+
+## Key Concepts
+- [[RSS聚合]]：通过 RSS 协议从 46 个科技媒体（OpenAI Blog、Hacker News、MIT Tech Review 等）持续获取最新内容
+- [[社交媒体监控]]：通过 Twitter/X API 监控 44 位 KOL（@karpathy、@sama、@VitalikButerin 等）的动态
+- [[GitHub动态监控]]：追踪 19 个热门开源项目（vLLM、LangChain、Ollama、Dify 等）的 Release 更新
+- [[网页搜索聚合]]：通过 Brave Search API 执行 4 个主题的主动搜索，覆盖无 RSS 的来源
+- [[内容去重]]：基于标题相似度对多源内容进行合并，避免重复推送
+- [[质量评分算法]]：priority source +3 / multi-source +5 / recency +2 / engagement +1 的多维度加权评分体系
+- [[多渠道投递]]：支持 Discord、Email、Telegram 三个投递通道
+
+## Key Entities
+- [[DracoVibeCoding]]：公众号"Draco正在VibeCoding"作者，Multi-Source Tech News Digest 的提出者
+- [[Brave Search]]：网页搜索层 API 提供方，为无 RSS 来源的主题提供主动搜索能力
+- [[ClawHub]]：tech-news-digest skill 的分发平台，通过 `clawhub install tech-news-digest` 一键安装
+- [[RSSHub]]：开源 RSS 聚合服务，可扩展 RSS 覆盖的信息源范围
+- [[gog]]（可选）：Gmail 邮件投递依赖的 CLI 工具
+
+## Connections
+- [[YouTube-Content-Pipeline]] ← 同类多源内容监控 → [[multi-source-tech-news-digest]]
+- [[Daily-YouTube-Digest]] ← 同类定时 + AI 摘要 + 多通道投递模式 → [[multi-source-tech-news-digest]]
+- [[Daily Reddit Digest]] ← 同类 Cron Job + AI 摘要 → [[multi-source-tech-news-digest]]
+- [[Brave Search]] ← 提供网页搜索数据 → [[multi-source-tech-news-digest]]
+- [[RSSHub]] ← 扩展 RSS 信息源覆盖 → [[multi-source-tech-news-digest]]
+
+## Contradictions
+- 与 [[YouTube-Content-Pipeline]]：两者都做多源内容监控，但侧重点不同——YouTube 侧重视频内容发现（转录+摘要），本文档侧重文字新闻聚合（RSS+Twitter+GitHub+Search）。两者互补而非冲突，共同构成完整的内容监控体系。
--- a/wiki/sources/n8n-workflow-orchestration.md
+++ b/wiki/sources/n8n-workflow-orchestration.md
@@ -0,0 +1,55 @@
+---
+title: "OpenClaw + n8n Workflow Orchestration"
+type: source
+tags: [openclaw, n8n, workflow-orchestration, security, credential-management, webhook]
+date: 2026-04-17
+---
+
+## Source File
+- [[Agent/usecases/n8n-workflow-orchestration.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Webhook 代理模式将 OpenClaw Agent 的外部 API 交互委托给 n8n 工作流，实现凭证隔离、可视化调试和流程锁定。
+- 问题域：AI Agent 直接管理 API 凭证的安全风险（泄露、无序扩展、token 浪费）。
+- 方法/机制：OpenClaw 设计并调用 n8n Webhook → n8n 持有凭证并执行外部 API 调用 → Agent 只知道 Webhook URL，不知道密钥。
+- 结论/价值：一次实现三大收益——可观测性（n8n UI）、安全性（凭证隔离）、性能（确定性任务不消耗 LLM token）。
+
+## Key Claims（用中文描述）
+- OpenClaw Agent 直接管理 API 密钥容易造成安全事件（一次误提交即泄露）。
+- n8n Webhook 代理模式使 Agent 完全接触不到凭证，凭证存储在 n8n credential store 中。
+- n8n 拥有 400+ 集成节点，大多数外部服务已有现成节点，无需 Agent 编写自定义 API 调用。
+- "构建 → 测试 → 锁定" 循环是该模式安全运转的关键——不锁定，Agent 可以静默修改工作流行为。
+- n8n 自动记录每次工作流执行的输入输出数据，提供开箱即用的审计轨迹。
+- Docker Compose 一键部署（openclaw-n8n-stack）预配置了 OpenClaw + n8n 共享 Docker 网络。
+
+## Key Quotes
+> "Three wins in one: Observability (visual UI), security (credential isolation), and performance (deterministic workflows don't burn tokens)." — 核心价值总结
+> "Lock after testing: The build → test → lock cycle is critical — without locking, the agent can silently modify workflows." — 安全运转关键
+> "n8n has 400+ integrations: Most external services you'd want to connect already have n8n nodes, saving the agent from writing custom API calls." — 集成广度
+
+## Key Concepts
+- [[Webhook-Proxy-Pattern]]：Agent 通过 Webhook URL 调用 n8n 工作流，凭证留在 n8n 端，Agent 不持有密钥。
+- [[Credential-Isolation]]：API 密钥存储在 n8n credential store，Agent 只知道 Webhook URL，无法访问凭证。
+- [[Lockable-Workflow]]：工作流经 Agent 构建并人工验证后锁定，防止 Agent 静默修改 API 调用逻辑。
+- [[Visual-Debugging]]：n8n 的拖拽式 UI 使每个工作流完全可视化可检查。
+- [[Safeguard-Steps]]：在 n8n 工作流中可加入验证、速率限制、人工审批等安全门控。
+- [[Audit-Trail]]：n8n 记录每次工作流执行的输入输出数据，提供执行历史。
+
+## Key Entities
+- [[OpenClaw]]：作为 Agent 端，设计工作流并调用 Webhook，从不接触 API 凭证。
+- [[n8n]]：作为执行代理端，持有凭证、执行 API 调用、提供可视化 UI 和锁定能力。
+- [[Simon-Hoiberg]]：提出该集成模式的专家，n8n + OpenClaw 组合的布道者。
+- [[openclaw-n8n-stack]]：预配置的 Docker Compose 堆栈，一键部署 OpenClaw + n8n 共享网络环境。
+
+## Connections
+- [[OpenClaw]] ← uses_for_external_api ← [[n8n]]（Webh
+
+ook 代理）
+- [[Credential-Isolation]] ← implemented_by ← [[Lockable-Workflow]]
+- [[n8n-workflow-orchestration]] ← extends ← [[Webhook]]（Webhook 触发是该模式的基础）
+- [[openclaw-n8n-stack]] ← builds_on ← [[Docker]]（容器化部署底座）
+- [[Webhook-Proxy-Pattern]] ← alternative_to ← [[Agent-direct-API-access]]（直接持证 vs 代理模式）
+
+## Contradictions
+- 与 [[workflow-automation]] 中的 n8n 独立使用方式相比：本文强调 n8n 作为 Agent 的安全执行代理，而非独立自动化平台——不冲突，是互补关系。
+- 与 [[使用Claude自动生成n8n工作流的实操教程]] 的互补关系：Claude + n8n-mcp 解决工作流生成问题，本文解决 Agent 安全集成问题，两者可叠加使用。
--- a/wiki/sources/overnight-mini-app-builder.md
+++ b/wiki/sources/overnight-mini-app-builder.md
@@ -0,0 +1,52 @@
+---
+title: "Goal-Driven Autonomous Tasks"
+type: source
+tags: ["OpenClaw", "Autonomous Agent", "Task Management", "AI Productivity"]
+date: 2026-04-17
+---
+
+## Source File
+- [[Agent/usecases/overnight-mini-app-builder]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 从被动执行者转变为主动规划者的目标驱动型自主任务系统
+- 问题域：人们有大目标但难以分解为每日可执行步骤，且执行本身消耗所有时间
+- 方法/机制：OpenClaw 记忆系统 + 每日自主任务生成 + Kanban 看板追踪 + 过夜 MVP 构建
+- 结论/价值：将"规划"和"执行"都外包给 AI Agent，用户只需定义目的地，Agent 自动分解并执行每日步骤
+
+## Key Claims（用中文描述）
+- OpenClaw + 每日任务生成 → 将 AI Agent 从被动工具转变为主动员工
+- 每日清晨 8:00 自动生成 4-5 个任务，涵盖研究/写作/应用构建/竞品分析/内容创作
+- 过夜构建惊喜 Mini-App MVP → 每天醒来获得一个贴近目标的新产品原型
+- Kanban 看板 → 将 AI Agent 变成可追踪的员工，可实时查看进度并纠偏
+- "Brain Dump 是关键" → 给越多目标上下文，Agent 的每日任务越精准
+
+## Key Quotes
+> "Every morning, the agent generates 4-5 tasks it can complete autonomously on your computer." — 每日任务自动生成机制
+> "You define the destination; the agent figures out the daily steps and walks them." — 核心价值主张
+> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be." — 最重要的一步
+> "Keep AUTONOMOUS.md under ~50 lines: goals (one-liners) + open backlog only." — Token 优化原则
+> "Git never rewrites history, you only add new commits. It eliminates race conditions entirely." — 竞态条件解决思路
+
+## Key Concepts
+- [[Kanban]]：看板系统，OpenClaw 自动构建 Next.js 看板追踪任务状态（To Do/In Progress/Done）
+- [[Autonomous Agent]]：自主代理，具备目标理解、任务分解、自主执行能力的 AI Agent 模式
+- [[Brain Dump]]：一次性将所有目标/使命/任务倒入 AI 记忆系统，是整个工作流最关键的第一步
+- [[Sub-Agent Race Condition]]：多子代理并发编辑共享文件导致的竞态条件，解决方案：只追加日志 + 主会话独管状态文件
+- [[Token-Light Design]]：Token 优化设计，保持 AUTONOMOUS.md 在 50 行以内避免心跳轮询时消耗过多令牌
+
+## Key Entities
+- [[OpenClaw]]：多 Agent 框架，提供 sessions_spawn/sessions_send 能力支撑自主任务执行
+- [[Alex Finn]]：OpenClaw 资深用户，YouTube 频道分享 Life-changing OpenClaw Use Cases，启发了本工作流
+
+## Connections
+- [[Goal-Driven Autonomous Tasks]] ← extends ← [[Second Brain]]
+- [[Goal-Driven Autonomous Tasks]] ← extends ← [[multi-channel-assistant]]
+- [[Goal-Driven Autonomous Tasks]] ← extends ← [[Dynamic Dashboard]]
+- [[Goal-Driven Autonomous Tasks]] ← extends ← [[market-research-product-factory]]
+
+## Contradictions
+- 与 [[Project State Management]] 冲突：
+  - 冲突点：看板 vs 事件溯源的任务管理方式
+  - 当前观点：本方案使用 Next.js 构建 Kanban 看板，强调用户可视化追踪
+  - 对方观点：[[Project State Management]] 使用 [[Event Sourcing]] 替代看板，强调自动追踪和完整上下文保留，避免手动拖拽和状态丢失
--- a/wiki/sources/personal-crm.md
+++ b/wiki/sources/personal-crm.md
@@ -0,0 +1,46 @@
+---
+title: "Personal CRM with Automatic Contact Discovery"
+type: source
+tags: []
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/personal-crm.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 驱动的个人 CRM 系统，自动从邮件和日历中发现联系人并建立关系管理
+- 问题域：手动追踪联系人交流历史困难、重要跟进遗漏、开会前忘记之前讨论内容
+- 方法/机制：每日 Cron Job 扫描 Gmail 和日历提取新联系人 → SQLite 结构化存储（含关系上下文）→ 自然语言查询接口 → 会议前自动简报生成
+- 结论/价值：零手动录入，AI 自动构建和维护联系人知识库，开会前自动准备背景资料
+
+## Key Claims（用中文描述）
+- 每日 Cron Job 自动扫描邮件和日历 → 无需手动录入联系人
+- AI 存储每次互动的上下文（时间、内容摘要）→ 保留完整交流历史
+- 每次会议前自动研究外部参会者 → 提供背景简报（含上次交流内容、待跟进事项）
+- 自然语言查询 → "上次和某人聊了什么？"、"谁需要跟进？"
+
+## Key Quotes
+> "Keeping track of who you've met, when, and what you discussed is impossible to do manually. Important follow-ups slip through the cracks, and you forget context before important meetings." — 痛点陈述
+
+## Key Concepts
+- [[Personal CRM]]：基于 AI Agent 自动发现和维护个人联系人关系的管理系统
+- [[Cron Job]]：定时任务触发每日联系人扫描和会议简报生成
+- [[Automatic Contact Discovery]]：从 Gmail 日历自动提取联系人和互动事件
+- [[Meeting Prep Briefing]]：会前自动收集参会者背景资料和历史交流记录
+
+## Key Entities
+- [[gog CLI]]：Gmail 和 Google Calendar 的 CLI 工具，本方案的数据采集层
+- [[OpenClaw]]：AI Agent 框架，负责 Cron Job 编排、自然语言查询和简报生成
+- [[Telegram]]：CRM 查询接口的推送通道，通过 personal-crm topic 接收查询请求
+
+## Connections
+- [[local-crm-framework]] ← extends ← [[personal-crm]]（DenchClaw 本地 CRM 框架是该方案的具体实现）
+- [[multi-channel-assistant]] ← extends ← [[personal-crm]]（CRM 是 Telegram topic 路由的频道之一）
+- [[Second Brain]] ← related ← [[personal-crm]]：均属 OpenClaw 持久化记忆能力的不同应用场景
+
+## Contradictions
+- 与 [[Second Brain]] 可能存在功能重叠：
+  - 冲突点：两者都依赖 OpenClaw 的记忆存储，是否需要合并？
+  - 当前观点：Personal CRM 侧重联系人发现和会议准备（结构化数据），Second Brain 侧重任意内容的零摩擦捕获（非结构化）
+  - 对方观点：两者可共享底层记忆系统，差异化在于查询界面和数据结构
--- a/wiki/sources/polymarket-autopilot.md
+++ b/wiki/sources/polymarket-autopilot.md
@@ -0,0 +1,41 @@
+---
+title: "Polymarket Autopilot"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/usecases/polymarket-autopilot.md]]
+
+## Summary（用中文描述）
+- 核心主题：基于 AI Agent 的 Polymarket 预测市场自动驾驶交易系统
+- 问题域：预测市场信息获取滞后、交易决策效率低下、无法 24/7 监控市场动态
+- 方法/机制：AI Agent 自动监控 Polymarket 市场数据、智能分析预测概率变化、自动执行交易策略、定时推送市场洞察
+- 结论/价值：实现预测市场的半自动化交易，减少人工盯盘时间，提高市场信息获取效率
+
+## Key Claims（用中文描述）
+- AI Agent 能够实现 Polymarket 市场的 24/7 全天候监控
+- 自动化分析可识别预测概率的显著变化
+- 定时推送机制确保用户及时获取关键市场信息
+- 多 Agent 协作可处理复杂的市场研究和交易决策流程
+
+## Key Quotes
+> "AI agents can monitor Polymarket markets 24/7, analyzing prediction probabilities and triggering automated responses" — 核心价值主张
+
+## Key Concepts
+- [[Prediction Market]]：预测市场平台，用户通过交易事件结果概率获取收益
+- [[Polymarket]]：基于区块链的去中心化预测市场协议
+- [[Agentic Trading]]：AI Agent 驱动的自动化交易策略
+- [[Market Monitoring]]：市场动态实时监控与警报系统
+
+## Key Entities
+- [[Polymarket]]：去中心化预测市场协议，本文档的核心交互平台
+
+## Connections
+- [[Dynamic Dashboard]] ← extends ← [[polymarket-autopilot]]
+- [[earnings-tracker]] ← similar_pattern ← [[polymarket-autopilot]]
+
+## Contradictions
+- 无已知冲突
+
--- a/wiki/sources/semantic-memory-search.md
+++ b/wiki/sources/semantic-memory-search.md
@@ -0,0 +1,46 @@
+---
+title: "Semantic Memory Search"
+type: source
+tags: [memory, semantic-search, vector-db, openclaw]
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/semantic-memory-search]]
+
+## Summary（用中文描述）
+- 核心主题：为 OpenClaw 的 Markdown 记忆文件添加向量语义搜索能力
+- 问题域：OpenClaw 记忆以纯 Markdown 存储，随时间积累后无法检索，grep 只能关键词匹配，无法语义理解
+- 方法/机制：使用 memsearch 库（Milvus 向量数据库）构建混合搜索（稠密向量 + BM25）配合 RRF 重排；SHA-256 内容哈希实现增量索引；文件监视器自动重建索引
+- 结论/价值：用自然语言提问（如"我们选了哪个缓存方案？"）即可找到相关内容，无需记忆精确措辞；支持本地模式无需 API Key
+
+## Key Claims（用中文描述）
+- OpenClaw 记忆库积累后，纯 Markdown 无法语义检索，用户需要通过含义而非关键词找到过去决策
+- 混合搜索（稠密向量 + BM25）结合 RRF 重排，同时捕获语义相似性和关键词精确匹配，优于纯向量搜索
+- SHA-256 内容哈希确保仅新内容或变更内容被嵌入，避免重复 API 调用，节省成本
+- Markdown 文件是唯一真相，向量索引只是派生缓存，随时可通过 `memsearch index` 重建
+
+## Key Quotes
+> "Markdown stays the source of truth. The vector index is just a derived cache — you can rebuild it anytime with `memsearch index`. Your memory files are never modified." — 核心理念：原始文档不可变
+> "Hybrid search beats pure vector search. Combining semantic similarity (dense vectors) with keyword matching (BM25) via Reciprocal Rank Fusion catches both meaning-based and exact-match queries." — 混合搜索的优越性
+> "Smart dedup saves money. Each chunk is identified by a SHA-256 content hash. Re-running `index` only embeds new or changed content, so you can run it as often as you like without wasting embedding API calls." — 增量索引节省成本
+
+## Key Concepts
+- [[Semantic Memory Search]]：通过向量嵌入实现对记忆文件的语义搜索，而非仅关键词匹配
+- [[Hybrid Search]]：结合稠密向量（语义相似性）和 BM25（关键词精确匹配）的混合检索策略
+- [[Reciprocal Rank Fusion (RRF)]]：通过排名融合重排合并多个检索结果，提升搜索质量
+- [[Content Hashing]]：使用 SHA-256 哈希识别内容块，仅对新增或变更内容重新嵌入
+- [[File Watcher]]：监视记忆文件变化，自动触发增量重建索引，保持索引实时更新
+
+## Key Entities
+- [[memsearch]]：ZillizTech 开源的向量语义搜索 CLI/库，为 OpenClaw 记忆提供语义搜索能力，基于 Milvus 向量数据库
+- [[Milvus]]：开源向量数据库后端，memsearch 的向量存储和检索引擎
+- [[OpenClaw]]：多 Agent 框架，自带 Markdown 记忆系统，是本用例的上层应用框架
+
+## Connections
+- [[OpenClaw]] ← extends ← [[Semantic Memory Search]]：本用例在 OpenClaw 纯 Markdown 记忆之上叠加向量语义搜索层
+- [[Knowledge-Base-RAG]] ← related_to ← [[Semantic Memory Search]]：两者都涉及向量 Embedding 检索，属于 RAG 技术栈的不同场景
+- [[Second Brain]] ← related_to ← [[Semantic Memory Search]]：第二大脑的记忆持久化与语义检索能力相辅相成
+
+## Contradictions
+- 与 [[Knowledge-Base-RAG]] 无冲突，两者属同一技术栈的不同实现：Knowledge Base RAG 侧重 Telegram/Slack 投递 URL 并入库，本用例侧重现有 Markdown 文件的语义索引
--- a/wiki/sources/x-twitter-automation.md
+++ b/wiki/sources/x-twitter-automation.md
@@ -0,0 +1,44 @@
+---
+title: "X/Twitter Automation from Chat"
+type: source
+tags: ["openclaw", "twitter", "x", "automation", "social-media", "plugin"]
+date: 2026-04-17
+---
+
+## Source File
+- [[Agent/usecases/x-twitter-automation.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过自然语言在聊天中完成 X/Twitter 全功能自动化操作
+- 问题域：X/Twitter 账号管理需要在 App、第三方仪表盘和数据分析工具之间来回切换，缺乏统一的对话式交互界面
+- 方法/机制：TweetClaw（OpenClaw 插件）通过 X/Twitter 官方托管 API 连接 Agent，提供发推/互动、搜索提取、抽奖工具、账号监控四大功能模块
+- 结论/价值：用一个聊天界面替代所有 X/Twitter 管理工具，所有操作通过托管 API 完成，无 Cookie、无爬虫、无凭证暴露
+
+## Key Claims（用中文描述）
+- TweetClaw 插件通过自然语言交互实现 X/Twitter 全功能操作（发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人、账号监控）
+- 抽奖功能支持可配置的筛选条件（最低粉丝数、账号年龄、关键词要求），从推文互动用户中随机抽取获奖者
+- 账号监控功能可追踪指定账号的新推文或粉丝变化并发送通知
+- 所有 API 操作通过 TweetClaw 托管服务完成，无需浏览器 Cookie、无爬虫脚本、无凭证暴露
+
+## Key Quotes
+> "Managing an X/Twitter presence requires jumping between the app, third-party dashboards, and analytics tools." — 痛点描述
+> "All actions go through a managed API — no browser cookies, no scraping, no credential exposure." — 安全性说明
+
+## Key Concepts
+- [[X/Twitter-API-Automation]]：通过 API 接口程序化控制 X/Twitter 账号行为，替代手动操作或爬虫方案
+- [[Social-Media-Giveaway]]：通过程序化方式从推文互动用户中随机抽取获奖者，支持多条件筛选
+- [[Account-Monitoring]]：持续追踪指定账号的内容发布或粉丝变动并触发通知
+
+## Key Entities
+- [[TweetClaw]]：OpenClaw 插件，通过 @xquik/tweetclaw npm 包安装，连接 Agent 与 X/Twitter API
+- [[Xquik-dev]]：TweetClaw 的开发公司，维护 GitHub 仓库和 npm 包
+- [[OpenClaw]]：多 Agent 框架，提供持久化记忆和 Plugin 系统，TweetClaw 的宿主平台
+
+## Connections
+- [[X-Account-Analysis]] ← related ← [[x-twitter-automation]]（两者同属 X/Twitter 场景，X-Account-Analysis 侧重数据分析，本页面侧重自动化操作）
+- [[Content-Factory]] ← extends ← [[x-twitter-automation]]（Content-Factory 的社交媒体发布能力可由 TweetClaw 提供支持）
+- [[x-twitter-automation]] ← depends_on ← [[OpenClaw]]（TweetClaw 以 OpenClaw Plugin 形式运行，依赖 OpenClaw 的 Agent 执行环境）
+- [[n8n-workflow-orchestration]] ← complementary ← [[x-twitter-automation]]（n8n Webhook 模式可作为 TweetClaw API 的安全凭证托管层）
+
+## Contradictions
+- 无已知冲突。与 [[x-account-analysis]]（尚未摄入）互补——分析 vs 操作，共同构成 X/Twitter 场景的完整能力覆盖
--- a/wiki/sources/youtube-content-pipeline.md
+++ b/wiki/sources/youtube-content-pipeline.md
@@ -0,0 +1,57 @@
+---
+title: "YouTube Content Pipeline"
+type: source
+tags: [youtube, content-automation, openclaw, cron-job, semantic-dedup]
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/usecases/youtube-content-pipeline]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 驱动的 YouTube 内容发现与选题自动化流水线
+- 问题域：每日 YouTube 创作者面临的信息过载、选题重复、趋势追踪困难等问题
+- 方法/机制：定时 Cron Job + Web/X 搜索 + YouTube Analytics 查重 + SQLite 向量相似度去重 + Telegram 选题推送 + Slack 链接自动研究
+- 结论/价值：实现选题发现、查重、推送的全链路自动化，创作者只需从 Telegram 选题即可
+
+## Key Claims（用中文描述）
+- Hourly Cron Job 扫描 Web + X/Twitter 的突发 AI 新闻，自动向 Telegram 推送选题
+- 维护 90 天 YouTube 视频目录（含播放量和主题分析），避免重复覆盖同类选题
+- SQLite 数据库存储所有选题及向量嵌入，通过语义相似度实现选题去重
+- Slack 分享链接时，OpenClaw 自动研究主题、搜索 X 相关帖子、查询知识库，并创建带完整大纲的 Asana 任务卡
+
+## Key Quotes
+> "Finding fresh, timely video ideas across the web and X/Twitter is time-consuming. Tracking what you've already covered prevents duplicates and helps you stay ahead of trends." — 核心痛点阐述
+> "Stores all pitches in a SQLite database with vector embeddings for semantic dedup (so you never get pitched the same idea twice)" — 技术选型亮点
+
+## Key Concepts
+- [[Semantic-Deduplication]]：通过向量嵌入（embedding）计算选题语义相似度，防止重复选题
+- [[Cron-Job]]：定时任务驱动，每小时自动执行内容发现流程
+- [[Knowledge-Base-RAG]]：检索增强生成，查询知识库辅助选题研究
+- [[Content-Automation]]：内容创作全流程自动化，从发现到任务创建
+- [[Vector-Embedding]]：将文本选题转为向量，实现语义层面精确去重
+
+## Key Entities
+- [[OpenClaw]]：核心 Agent 框架，编排所有工具（Web 搜索、X 搜索、知识库查询、Asana 集成）
+- [[YouTube-Analytics]]：通过 `gog` CLI 获取频道播放量和视频主题分析
+- [[Asana]]：项目管理工具，用于创建选题任务卡
+- [[Telegram]]：选题推送渠道，通过专属 Topic 接收 AI 推送的选题
+- [[SQLite]]：选题数据库，存储 timestamp/topic/embedding/sources
+- [[X-Twitter]]：选题来源之一，搜索突发 AI 新闻和社区讨论
+
+## Connections
+- [[Daily-YouTube-Digest]] ← extends ← [[YouTube-Content-Pipeline]]
+  - Daily YouTube Digest 侧重于已有订阅频道的更新监控，本流水线侧重于全网突发新闻和趋势的主动发现
+- [[Content-Factory]] ← shares_pattern ← [[YouTube-Content-Pipeline]]
+  - 同属多工具编排的自动化内容流水线，均使用子 Agent 并行执行模式
+- [[Custom-Morning-Brief]] ← shares_pattern ← [[YouTube-Content-Pipeline]]
+  - 同属 Cron Job + Telegram 推送模式，但前者侧重综合信息简报，后者垂直于视频选题
+
+## Contradictions
+- 无已知冲突
+
+## Setup Instructions Summary
+1. 配置 Telegram Topic 作为选题接收渠道
+2. 安装 knowledge-base skill 和 x-research skill
+3. 创建 SQLite pitches 表（含 id/timestamp/topic/embedding/sources）
+4. 向 OpenClaw 发送 prompt 指令，激活每小时 Cron Job