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

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 触发机制对比

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]] — 审计轨迹是纵深防御的重要组成部分

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]] — 本概念的来源场景

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 增量索引的核心机制

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]] — 内容获取的工具技能

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 修改调用逻辑

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 配合的设计哲学

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]]: 配套的安装哲学

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]] — 文件监视器的增量触发依赖内容哈希比对

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]] — 汇总多个仓库更新为每日摘要

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]] — 家庭物资追踪场景描述

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]] — 混合搜索的融合算法

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 的个人知识管理应用

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 源码的下载来源
+- [[本地缓存]]：扁平化结果可缓存避免重复处理

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]]：检测源文件变更触发缓存失效

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]] — 提供工作流锁定能力的平台

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]] — 根据用户反馈持续优化渠道选择

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]] 同属批量情报收集，但本概念聚焦学术论文

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]]

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]] — 评分结果最终投递为每日简报

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 覆盖范围的工具

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 用于提升知识库检索质量

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 是该模式的推荐实现组件

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]] — 避免重复发现同类竞品

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 关键词检索融合，进一步提升召回率

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 的具体实现方式

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]] — 本模式的来源场景

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]] — 本概念的来源场景

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]] — 用向量嵌入实现选题去重

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]] — 提供可视化调试能力的平台

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 结果的交叉去重

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

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 的应用场景