diff --git a/Project/fonrey/PRD/房源管理模块PRD.md b/Project/fonrey/PRD/房源管理模块PRD.md index 7c9a1a13..f3012962 100644 --- 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` diff --git a/openclaw/每日复盘/2026-04-22.md b/openclaw/每日复盘/2026-04-22.md new file mode 100644 index 00000000..3dc7e459 --- /dev/null +++ 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 diff --git a/wiki/concepts/AmbientMessageMonitoring.md b/wiki/concepts/AmbientMessageMonitoring.md new file mode 100644 index 00000000..e615a70f --- /dev/null +++ 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 触发机制对比 diff --git a/wiki/concepts/Audit-Trail.md b/wiki/concepts/Audit-Trail.md new file mode 100644 index 00000000..6f2e3e16 --- /dev/null +++ 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]] — 审计轨迹是纵深防御的重要组成部分 diff --git a/wiki/concepts/Brain-Dump.md b/wiki/concepts/Brain-Dump.md new file mode 100644 index 00000000..09eb2743 --- /dev/null +++ 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]] — 本概念的来源场景 diff --git a/wiki/concepts/Content-Hashing.md b/wiki/concepts/Content-Hashing.md new file mode 100644 index 00000000..07f8ef77 --- /dev/null +++ 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 增量索引的核心机制 diff --git a/wiki/concepts/Content-Ingestion.md b/wiki/concepts/Content-Ingestion.md new file mode 100644 index 00000000..c0839df1 --- /dev/null +++ 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]] — 内容获取的工具技能 diff --git a/wiki/concepts/Credential-Isolation.md b/wiki/concepts/Credential-Isolation.md new file mode 100644 index 00000000..4abbd958 --- /dev/null +++ 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 修改调用逻辑 diff --git a/wiki/concepts/DuckDB.md b/wiki/concepts/DuckDB.md new file mode 100644 index 00000000..d02639d6 --- /dev/null +++ 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 配合的设计哲学 diff --git a/wiki/concepts/File-System-First-UI.md b/wiki/concepts/File-System-First-UI.md new file mode 100644 index 00000000..93f83444 --- /dev/null +++ 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]]: 配套的安装哲学 diff --git a/wiki/concepts/File-Watcher.md b/wiki/concepts/File-Watcher.md new file mode 100644 index 00000000..8bc099de --- /dev/null +++ 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]] — 文件监视器的增量触发依赖内容哈希比对 diff --git a/wiki/concepts/GitHub-Release-Monitoring.md b/wiki/concepts/GitHub-Release-Monitoring.md new file mode 100644 index 00000000..e7056710 --- /dev/null +++ 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]] — 汇总多个仓库更新为每日摘要 diff --git a/wiki/concepts/HouseholdInventoryTracking.md b/wiki/concepts/HouseholdInventoryTracking.md new file mode 100644 index 00000000..d59ec7c9 --- /dev/null +++ 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]] — 家庭物资追踪场景描述 diff --git a/wiki/concepts/Hybrid-Search.md b/wiki/concepts/Hybrid-Search.md new file mode 100644 index 00000000..ca25fd79 --- /dev/null +++ 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]] — 混合搜索的融合算法 diff --git a/wiki/concepts/Knowledge-Base-RAG.md b/wiki/concepts/Knowledge-Base-RAG.md new file mode 100644 index 00000000..bafd1d04 --- /dev/null +++ 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 的个人知识管理应用 diff --git a/wiki/concepts/LaTeX-Flattening.md b/wiki/concepts/LaTeX-Flattening.md new file mode 100644 index 00000000..a09c3c7e --- /dev/null +++ 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 源码的下载来源 +- [[本地缓存]]：扁平化结果可缓存避免重复处理 diff --git a/wiki/concepts/Local-Caching.md b/wiki/concepts/Local-Caching.md new file mode 100644 index 00000000..6ad9d3a9 --- /dev/null +++ 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]]：检测源文件变更触发缓存失效 diff --git a/wiki/concepts/Lockable-Workflow.md b/wiki/concepts/Lockable-Workflow.md new file mode 100644 index 00000000..3c0e0e28 --- /dev/null +++ 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]] — 提供工作流锁定能力的平台 diff --git a/wiki/concepts/Multi-Channel-Delivery.md b/wiki/concepts/Multi-Channel-Delivery.md new file mode 100644 index 00000000..a748df1c --- /dev/null +++ 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]] — 根据用户反馈持续优化渠道选择 diff --git a/wiki/concepts/Paper-Abstract-Batch-Fetching.md b/wiki/concepts/Paper-Abstract-Batch-Fetching.md new file mode 100644 index 00000000..1b2b745c --- /dev/null +++ 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]] 同属批量情报收集，但本概念聚焦学术论文 diff --git a/wiki/concepts/Personal-CRM.md b/wiki/concepts/Personal-CRM.md new file mode 100644 index 00000000..76466294 --- /dev/null +++ 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]] diff --git a/wiki/concepts/Quality-Scoring-Algorithm.md b/wiki/concepts/Quality-Scoring-Algorithm.md new file mode 100644 index 00000000..be79438a --- /dev/null +++ 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]] — 评分结果最终投递为每日简报 diff --git a/wiki/concepts/RSS-Aggregation.md b/wiki/concepts/RSS-Aggregation.md new file mode 100644 index 00000000..b57c0235 --- /dev/null +++ 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 覆盖范围的工具 diff --git a/wiki/concepts/Reciprocal-Rank-Fusion.md b/wiki/concepts/Reciprocal-Rank-Fusion.md new file mode 100644 index 00000000..0ee17e56 --- /dev/null +++ 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 用于提升知识库检索质量 diff --git a/wiki/concepts/Safeguard-Steps.md b/wiki/concepts/Safeguard-Steps.md new file mode 100644 index 00000000..314b9358 --- /dev/null +++ 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 是该模式的推荐实现组件 diff --git a/wiki/concepts/Semantic-Deduplication.md b/wiki/concepts/Semantic-Deduplication.md new file mode 100644 index 00000000..de3f772b --- /dev/null +++ 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]] — 避免重复发现同类竞品 diff --git a/wiki/concepts/Semantic-Search.md b/wiki/concepts/Semantic-Search.md new file mode 100644 index 00000000..cf5ce58e --- /dev/null +++ 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 关键词检索融合，进一步提升召回率 diff --git a/wiki/concepts/Social-Media-Monitoring.md b/wiki/concepts/Social-Media-Monitoring.md new file mode 100644 index 00000000..15c3261d --- /dev/null +++ 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 的具体实现方式 diff --git a/wiki/concepts/Sub-Agent-Race-Condition.md b/wiki/concepts/Sub-Agent-Race-Condition.md new file mode 100644 index 00000000..539cf42b --- /dev/null +++ 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]] — 本模式的来源场景 diff --git a/wiki/concepts/Token-Light-Design.md b/wiki/concepts/Token-Light-Design.md new file mode 100644 index 00000000..1ddc495b --- /dev/null +++ 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]] — 本概念的来源场景 diff --git a/wiki/concepts/Vector-Embedding.md b/wiki/concepts/Vector-Embedding.md new file mode 100644 index 00000000..4ba68b21 --- /dev/null +++ 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]] — 用向量嵌入实现选题去重 diff --git a/wiki/concepts/Visual-Debugging.md b/wiki/concepts/Visual-Debugging.md new file mode 100644 index 00000000..3875c6a2 --- /dev/null +++ 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]] — 提供可视化调试能力的平台 diff --git a/wiki/concepts/Web-Search-Aggregation.md b/wiki/concepts/Web-Search-Aggregation.md new file mode 100644 index 00000000..337ce23e --- /dev/null +++ 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 结果的交叉去重 diff --git a/wiki/concepts/Webhook-Proxy-Pattern.md b/wiki/concepts/Webhook-Proxy-Pattern.md new file mode 100644 index 00000000..189d1aac --- /dev/null +++ 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 diff --git a/wiki/concepts/arXiv-API.md b/wiki/concepts/arXiv-API.md new file mode 100644 index 00000000..91ae7c03 --- /dev/null +++ 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/` | 下载 LaTeX 源码 `.tar.gz` | +| PDF | `https://arxiv.org/pdf/.pdf` | 下载 PDF 全文 | + +## Use Cases +- [[arXiv-Paper-Reader]] 的核心数据来源 +- 批量论文筛选和元数据分析 + +## Limitations +- 每秒最多 1 请求（官方限速），需实现请求节流 +- LaTeX 源码仅部分论文提供（非强制提交） + +## Related Concepts +- [[LaTeX-Flattening]]：API 返回的 LaTeX 源码的处理方式 +- [[论文摘要批量获取]]：批量调用 API 的应用场景 diff --git a/wiki/entities/Alex-Finn.md b/wiki/entities/Alex-Finn.md index 3ee6bb79..48111803 100644 --- 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 --- diff --git a/wiki/entities/DenchClaw.md b/wiki/entities/DenchClaw.md new file mode 100644 index 00000000..d566c9df --- /dev/null +++ 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]] — 设计哲学 diff --git a/wiki/entities/DracoVibeCoding.md b/wiki/entities/DracoVibeCoding.md new file mode 100644 index 00000000..518d0c50 --- /dev/null +++ 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]] — 作者方案的发布平台 diff --git a/wiki/entities/Memsearch.md b/wiki/entities/Memsearch.md new file mode 100644 index 00000000..ed4218a7 --- /dev/null +++ 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 的增量索引机制 diff --git a/wiki/entities/Milvus.md b/wiki/entities/Milvus.md new file mode 100644 index 00000000..9e015984 --- /dev/null +++ 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 记忆提供向量检索能力 diff --git a/wiki/entities/OpenClaw.md b/wiki/entities/OpenClaw.md index 36a9569c..26176216 100644 --- 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 --- diff --git a/wiki/entities/Prismer-AI.md b/wiki/entities/Prismer-AI.md new file mode 100644 index 00000000..c97c1a64 --- /dev/null +++ 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` diff --git a/wiki/entities/Simon-Hoiberg.md b/wiki/entities/Simon-Hoiberg.md new file mode 100644 index 00000000..36197897 --- /dev/null +++ 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]] — 该模式中的执行代理端 diff --git a/wiki/entities/SparkryAI.md b/wiki/entities/SparkryAI.md new file mode 100644 index 00000000..bb2354a8 --- /dev/null +++ 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 中也有引用） diff --git a/wiki/entities/TweetClaw.md b/wiki/entities/TweetClaw.md new file mode 100644 index 00000000..d131d807 --- /dev/null +++ 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 操作能力 diff --git a/wiki/entities/n8n.md b/wiki/entities/n8n.md index 687ee713..60a9c2a2 100644 --- 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 常用触发方式 diff --git a/wiki/entities/openclaw-n8n-stack.md b/wiki/entities/openclaw-n8n-stack.md new file mode 100644 index 00000000..14125675 --- /dev/null +++ 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]] — 栈内工作流引擎 diff --git a/wiki/index.md b/wiki/index.md index 3057635c..1d2dd984 100644 --- 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) diff --git a/wiki/log.md b/wiki/log.md index 1b0dac34..3627669e 100644 --- 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: ✅ 成功摄入 diff --git a/wiki/overview.md b/wiki/overview.md index 3babb8da..7c35c3bf 100644 --- 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）→ **销售漏斗搭建**（获客 → 激活 → 转化，价格锚定与诱饵效应）。 diff --git a/wiki/sources/arxiv-paper-reader.md b/wiki/sources/arxiv-paper-reader.md new file mode 100644 index 00000000..b8f78f3a --- /dev/null +++ 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 +- 无已知冲突内容 diff --git a/wiki/sources/family-calendar-household-assistant.md b/wiki/sources/family-calendar-household-assistant.md new file mode 100644 index 00000000..4c28fa6e --- /dev/null +++ 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 +- 无已知冲突。 diff --git a/wiki/sources/knowledge-base-rag.md b/wiki/sources/knowledge-base-rag.md new file mode 100644 index 00000000..7c101890 --- /dev/null +++ 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 页面的内容冲突 diff --git a/wiki/sources/local-crm-framework.md b/wiki/sources/local-crm-framework.md new file mode 100644 index 00000000..666527dc --- /dev/null +++ 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 页面的内容冲突） diff --git a/wiki/sources/multi-source-tech-news-digest.md b/wiki/sources/multi-source-tech-news-digest.md new file mode 100644 index 00000000..bbe2222d --- /dev/null +++ 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）。两者互补而非冲突，共同构成完整的内容监控体系。 diff --git a/wiki/sources/n8n-workflow-orchestration.md b/wiki/sources/n8n-workflow-orchestration.md new file mode 100644 index 00000000..497cc9a7 --- /dev/null +++ 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 安全集成问题，两者可叠加使用。 diff --git a/wiki/sources/overnight-mini-app-builder.md b/wiki/sources/overnight-mini-app-builder.md new file mode 100644 index 00000000..3357e444 --- /dev/null +++ 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]] 替代看板，强调自动追踪和完整上下文保留，避免手动拖拽和状态丢失 diff --git a/wiki/sources/personal-crm.md b/wiki/sources/personal-crm.md new file mode 100644 index 00000000..74a6b110 --- /dev/null +++ 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 侧重任意内容的零摩擦捕获（非结构化） + - 对方观点：两者可共享底层记忆系统，差异化在于查询界面和数据结构 diff --git a/wiki/sources/polymarket-autopilot.md b/wiki/sources/polymarket-autopilot.md new file mode 100644 index 00000000..da4a84be --- /dev/null +++ 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 +- 无已知冲突 + diff --git a/wiki/sources/semantic-memory-search.md b/wiki/sources/semantic-memory-search.md new file mode 100644 index 00000000..dd238992 --- /dev/null +++ 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 文件的语义索引 diff --git a/wiki/sources/x-twitter-automation.md b/wiki/sources/x-twitter-automation.md new file mode 100644 index 00000000..8a360732 --- /dev/null +++ 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 场景的完整能力覆盖 diff --git a/wiki/sources/youtube-content-pipeline.md b/wiki/sources/youtube-content-pipeline.md new file mode 100644 index 00000000..aeebd120 --- /dev/null +++ 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