Auto-sync: 2026-04-27 20:02

2026-04-27 20:02:52 +08:00
parent 5854781fa8
commit de7ebe9256
59 changed files with 2122 additions and 1325 deletions
--- a/wiki/sources/aionui-cowork-desktop.md
+++ b/wiki/sources/aionui-cowork-desktop.md
@@ -1,44 +1,49 @@
---
-title: "OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/aionui-cowork-desktop.md]]
-
-## Summary（用中文描述）
- 核心主题：如何通过 AionUi 桌面应用将 OpenClaw 作为协作型 Agent 运行，并实现远程救援和多 Agent 集中管理
- 问题域：OpenClaw 用户缺少可视化工作空间、远程修复能力和统一的多 Agent 管理界面
- 方法/机制：AionUi 提供 Cowork 工作空间（文件感知界面）、内置 OpenClaw 部署专家（远程诊断修复）、多 Agent 并行运行、统一 MCP 配置、跨平台远程访问（WebUI/Telegram/Lark/DingTalk）
- 结论/价值：一个 App 集成 OpenClaw + 12+ 其他 Agent，配置一次 MCP 即可全局生效，远程场景下可随时通过 Telegram/WebUI 修复 OpenClaw 故障
-
-## Key Claims（用中文描述）
- AionUi 将 OpenClaw 作为一等公民 Agent 运行，提供文件感知的工作空间界面，用户可直接看到 Agent 读写文件、运行命令、浏览网页
- 当 OpenClaw 故障且用户不在机器旁时，可通过 Telegram 或 WebUI 打开 AionUi，使用内置 OpenClaw 部署专家运行 `openclaw doctor`、修复配置、重启网关
- AionUi 配置一次 MCP 服务器，即同步到 OpenClaw 和所有其他 Agent，无需逐个配置
- 支持 WebUI、Telegram、Lark、DingTalk 多渠道远程访问同一个 AionUi 实例（及 OpenClaw）
-
-## Key Quotes
-> "OpenClaw, built-in agent, Claude Code, Codex, etc. in one app; switch or run in parallel, same MCP config for all." — AionUi 多 Agent 统一界面
-> "A common pattern for users who run OpenClaw headless or on another machine." — 远程救援场景
-
-## Key Concepts
- [[CoworkWorkspace]]：文件感知的工作空间，用户可看到 Agent 读写文件、运行命令、浏览网页，而非仅终端/聊天输出
- [[RemoteRescuePattern]]：通过远程渠道（Telegram/WebUI）访问内置专家 Agent，执行诊断修复命令（`openclaw doctor`）恢复主 Agent 连接
- [[Multi-AgentHub]]：单一应用中并行运行 OpenClaw、Claude Code、Codex 等 12+ Agent，统一界面、统一 MCP 配置
- [[MCPOnceAllAgents]]：在 AionUi 中配置一次 MCP 服务器，全局同步到所有集成的 Agent
-
-## Key Entities
- [[AionUi]]：免费开源桌面应用，将 OpenClaw 作为一等公民 Agent 运行，支持多 Agent 并行、统一 MCP 配置和跨平台远程访问
- [[OpenClaw]]：开源 AI Agent 框架，支持持久记忆和工作流编排，本文档中的被集成目标
- [[iOfficeAI]]：AionUi 开发公司
-
-## Connections
- [[AionUi]] ← integrates ← [[OpenClaw]]
- [[AionUi]] ← extends ← [[OpenClaw-N8N-Webhook-Pattern]] （AionUi 本身提供多 Agent 界面，n8n 模式提供工作流安全集成）
- [[RemoteRescuePattern]] ← enables ← [[Self-Healing-Home-Server]] （远程修复 OpenClaw 故障的能力）
-
-## Contradictions
- 无明显冲突。AionUi 侧重桌面可视化 + 多 Agent 并行管理，[[openclaw-n8n-stack]] 侧重安全 Webhook 代理集成，两者可互补使用。
+---
+title: "OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/aionui-cowork-desktop.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 AionUi 桌面应用将 OpenClaw 打造为协作型 Cowork Agent，支持远程救援和多 Agent 统一管理。
+- 问题域：AI Agent 的可视化监控、远程故障修复、多 Agent 工具链统一配置。
+- 方法/机制：AionUi 自动检测 OpenClaw，内置 OpenClaw 部署专家（含 `openclaw doctor` 诊断、配置修复、gateway 重启），支持 Telegram/WebUI 远程接入；一次配置 MCP Server 所有 Agent 共享。
+- 结论/价值：解决"看不见 Agent 在做什么"和"Agent 坏了人在外地无法修复"两大痛点，实现多 Agent 一站式管理。
+
+## Key Claims（用中文描述）
+- AionUi 将 OpenClaw 以一等公民身份集成进 Cowork 工作空间，用户可见 Agent 读写文件、运行命令、浏览网页的全过程，而非仅依赖日志推断。
+- 内置的 OpenClaw 部署专家可在 Agent 不可达时，通过 Telegram/WebUI 远程执行 `openclaw doctor`、修复配置、重启 gateway，实现远程救援。
+- AionUi 支持 OpenClaw、Claude Code、Codex 等 12+ Agent 共存，一个界面切换或并行运行，共享同一 MCP 配置。
+- WebUI、Telegram、Lark、DingTalk 多通道接入，实现从手机或其他设备远程访问同一 AionUi 实例（即 OpenClaw）。
+- AionUi Cron 可定时调度 OpenClaw 或其他 Agent，实现 24/7 自动化任务。
+
+## Key Quotes
+> "AionUi is a free, open-source app that runs OpenClaw as a first-class agent alongside 12+ others (Claude Code, Codex, Qwen Code, etc.), with a built-in OpenClaw deployment expert for install, diagnose, and repair — including remote rescue when OpenClaw is down and you're not at the machine." — 文档正文
+
+> "Many users rely on this." — 描述远程救援功能的实用性
+
+## Key Concepts
+- [[Cowork-UI]]：AionUi 提供的桌面协作界面，可视化展示 AI Agent 的文件读写、终端命令、网页浏览等操作全过程。
+- [[Remote-Rescue]]：当 OpenClaw 不可达时，通过 Telegram/WebUI 远程接入 AionUi，使用内置部署专家进行诊断和修复。
+- [[Multi-Agent-Unified-MCP]]：在 AionUi 中统一配置 MCP Server 配置，一次配置同步至 OpenClaw 及所有其他 Agent，无需逐个设置。
+- [[OpenClaw-Deployment-Expert]]：AionUi 内置的 OpenClaw 安装、诊断、修复引导工具，支持 `openclaw doctor` 和 gateway 管理。
+
+## Key Entities
+- [[OpenClaw]]：开源 AI Agent 框架，支持多渠道接入（Telegram/WebUI）和持久记忆，作为 AionUi 的一等公民运行。
+- [[AionUi]]：免费开源桌面应用，支持 12+ AI Agent（OpenClaw/Claude Code/Codex 等），提供 Cowork UI、远程通道（WebUI/Telegram/Lark/DingTalk）和定时任务功能。
+- [[Claude-Code]]：Anthropic 的 AI 编程 Agent，与 OpenClaw 共存于 AionUi 中。
+- [[Codex]]：OpenAI 的 AI 编程 Agent，与 OpenClaw 共存于 AionUi 中。
+- [[MCP]]（Model Context Protocol）：AionUi 中统一配置的 Agent 上下文协议，实现跨 Agent 的工具共享。
+
+## Connections
+- [[OpenClaw]] ← 核心被集成对象 ← [[AionUi-Cowork-Desktop]]
+- [[OpenClaw-n8n-Workflow-Orchestration]] ← 相关扩展 ← [[AionUi-Cowork-Desktop]]（AionUi 可调度 OpenClaw 执行 n8n 工作流）
+- [[Multi-Agent-Team]] ← 互补关系 ← [[AionUi-Cowork-Desktop]]（AionUi 提供 Multi-Agent 统一管理界面）
+- [[Second-Brain]] ← 场景互补 ← [[AionUi-Cowork-Desktop]]（两者均可通过 OpenClaw 实现，但 Second Brain 侧重记忆捕获，本方案侧重 Agent 可视化与远程控制）
+
+## Contradictions
+- 无已知冲突内容。
--- a/wiki/sources/arxiv-paper-reader.md
+++ b/wiki/sources/arxiv-paper-reader.md
@@ -1,48 +1,46 @@
---
-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
- 无已知冲突内容
+---
+title: "arXiv Paper Reader"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/arxiv-paper-reader.md]]
+
+## Summary（用中文描述）
+- 核心主题：让 AI Agent 变身为 arXiv 论文阅读助手，实现无需离开工作空间即可阅读、分析和对比论文
+- 问题域：arXiv 论文阅读的痛点（下载 PDF、切换丢失上下文、LaTeX 符号难以解析）
+- 方法/机制：通过 `arxiv-reader` skill（3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`），直接从 arXiv 获取论文、自动解压 LaTeX 源码并扁平化，解析后以可读文本呈现；结果本地缓存，二次访问即时响应
+- 结论/价值：实现对话式论文阅读、摘要速扫、跨论文对比、局部章节精读
+
+## Key Claims（用中文描述）
+- Agent 通过 `arxiv_fetch` 工具 → 获取任意 arXiv ID 的论文并自动将 LaTeX 展平为可读文本
+- Agent 通过 `arxiv_sections` 工具 → 先浏览论文结构（列出各章节），再决定是否深入阅读
+- Agent 通过 `arxiv_abstract` 工具 → 快速扫描多篇摘要以筛选阅读清单
+- 本地缓存机制 → 再次访问同一论文时即时响应，无需重新下载
+- Skill 独立运行 → 无需 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." — 问题陈述
+> "No Docker or Python required — the skill runs standalone using Node.js built-ins." — 部署亮点
+
+## Key Concepts
+- [[arXiv Reader Skill]]：`arxiv-reader` skill（Prismer 项目），包含 3 个工具，是本工作流的核心依赖
+- [[LaTeX 扁平化]]：自动解压 LaTeX 源码并处理 include，自动展平复杂公式结构为可读文本
+- [[本地缓存]]：论文内容下载后缓存在本地，二次访问无需重复请求
+- [[对话式论文阅读]]：以 Agent 为中介的论文交互范式，支持摘要速扫、章节精读、跨论文对比
+
+## Key Entities
+- [[Prismer]]：提供 `arxiv-reader` skill 的开源项目，位于 GitHub；skill 包含 3 个工具
+- [[OpenClaw]]：Agent 运行环境（skill 需要复制到 OpenClaw skills 文件夹使用）
+- [[arXiv]]：全球最大的开放获取预印本论文库，本工作流的数据来源
+
+## Connections
+- [[Prismer]] ← provides ← [[arXiv Reader Skill]]
+- [[arXiv Reader Skill]] ← enables ← [[对话式论文阅读]]
+- [[OpenClaw]] ← hosts ← [[arXiv Reader Skill]]
+- [[YouTube Content Pipeline]] ← similar_to ← [[arXiv Paper Reader]]（均为内容获取与 Agent 对话式交互）
+
+## Contradictions
+- （无已知冲突）
--- a/wiki/sources/dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1.md
+++ b/wiki/sources/dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1.md
@@ -1,5 +1,5 @@
 ---
-title: "Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器"
+title: "Dataview——让我从笔记黑洞里逃出来的 Obsidian 神器"
 type: source
 tags: []
 date: 2025-03-07
--- a/wiki/sources/family-calendar-household-assistant.md
+++ b/wiki/sources/family-calendar-household-assistant.md
@@ -1,66 +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
- 无已知冲突。
+---
+title: "Family Calendar Aggregation & Household Assistant"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/family-calendar-household-assistant]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 作为家庭日程协调中心，聚合多源日历、提供晨间简报、监控消息自动创建日历事件、管理家庭库存和购物清单。
+- 问题域：现代家庭面临 5+ 个日历分散在不同平台（工作/个人/家庭/学校/课外），消息中的预约确认无人处理，家庭物资管理依赖零散短信。
+- 方法/机制：
+  - 日历聚合层：汇聚 Google Calendar、Apple Calendar、学校 PDF/邮件附件等多源日历，生成统一晨间简报
+  - 环境消息监控（Ambient Message Monitoring）：每 15 分钟扫描 iMessage，识别预约模式（"confirmed for..."、"moved to Saturday at 3pm"），自动创建日历事件并附加行车时间缓冲
+  - 家庭库存追踪：JSON 文件存储物品位置/数量，支持照片 OCR 更新、小票识别
+  - 共享家庭 Telegram 频道：双方伴侣均可查询，建立信任和错误早期发现
+- 结论/价值：Ambient（主动环境感知）比 Active（被动等待指令）更有价值——最大的突破是 Agent 在不被要求的情况下主动行动；Mac Mini 是该场景的最优硬件选择（iMessage 集成 + 始终在线）。
+
+## Key Claims（用中文描述）
+- 多日历分散导致重要事件遗漏：工作日历有安全限制无法共享，学校日历以 PDF 或手写网站形式存在，人工逐一检查每日不可持续。
+- 环境消息监控是核心差异化因素：Agent 被动监听消息流，在识别到可执行项时自动采取行动（"我从没要求它这样做。它就是知道这是我想要的。"）。
+- Mac Mini 是家庭助理场景的最优硬件：支持 iMessage 集成、Apple Calendar，始终在线，是该方案的甜点配置。
+- 照片输入被低估：拍摄学校日历 PDF 或冰箱内容的照片比打字更快，视觉模型处理效果良好。
+- 从只读开始：先启用日历读取和消息监控，再启用写入操作（创建事件、发送消息）。
+
+## Key Quotes
+> "Ambient > active: The biggest unlock is the agent acting without being asked. Detecting an appointment in a text message and creating a calendar event with driving buffers — 'I didn't ask it to do that. It just knew that's what I'd want.'"
+— Sparkry AI, 24 Hours with OpenClaw 实测案例（妻子收到牙医预约短信，OpenClaw 自动创建日历事件并附加 30 分钟行车缓冲）
+
+> "Copying events across calendars works well until I forget and one slips through the cracks."
+— angiolillo, Hacker News 用户
+
+> "How much milk do we have?" requires physically checking the fridge, then the basement pantry, then texting back.
+— 家庭物资协调痛点描述
+
+## Key Concepts
+- [[Morning Briefing]]：每天定时（8:00 AM）聚合所有家庭日历生成统一简报，通过 Telegram/Slack 家庭频道投递；本页面是 Morning Briefing 的家庭场景垂直实现。
+- [[Ambient Message Monitoring]]：环境消息监控——Agent 被动监听消息流而非等待用户主动询问，在识别到可执行项时自动创建日历事件或提醒，是本系统的核心差异化机制。
+- [[Household Inventory Tracking]]：家庭物资库存追踪——JSON 文件存储物品名称/数量/位置（冰箱/食品储藏室/地下室），支持照片 OCR、小票识别和自然语言更新。
+- [[Calendar Aggregation]]：多源日历聚合——整合 Google Calendar、Apple Calendar、学校 PDF 邮件附件等多个来源，生成统一视图。
+- [[Driving Time Buffer]]：行车时间缓冲——自动在预约事件前后各添加 30 分钟的通勤时间块。
+- [[Grocery Coordination]]：购物协调——跨食谱去重原料、追踪低库存物品、自动生成购物清单。
+
+## Key Entities
+- [[OpenClaw]]：核心 Agent 框架，支持持久记忆和工作流编排，运行本家庭助理系统的底层引擎。
+- [[Sparkry AI]]：OpenClaw 实践者社区，发布了"24 Hours with OpenClaw"实测文章，是 Ambient Message Monitoring 机制的实测来源。
+- Brandon Wang：Clawdbot "Linguini" 的作者，Mac Mini 家庭部署方案——通过 iMessage 和 Slack 协调家庭物流、处理照片库存、自动跟进提醒。
+- angiolillo：Hacker News 用户，分享了多日历管理痛点。
+- dns_snek：Hacker News 用户，提到家庭物资管理挑战（"我5秒前放的东西就忘了在哪...东西过期是个大问题"）。
+- Google Calendar：主要日历来源之一。
+- Apple Calendar：Mac Mini 本地日历源。
+
+## Connections
+- [[Second Brain]] ← 共享 ← [[Family Calendar Household Assistant]]
+  - 两者都基于 [[OpenClaw]] 的持久记忆能力；Second Brain 侧重对话记忆捕获，本方案侧重家庭协调场景。
+- [[Custom Morning Brief]] ← 类似模式 ← [[Family Calendar Household Assistant]]
+  - 同属定时晨间简报场景，但 Custom Morning Brief 面向个人，本方案面向家庭。
+- [[phone-based-personal-assistant]] ← 互补 ← [[Family Calendar Household Assistant]]
+  - 语音入口覆盖无屏场景，文字入口（iMessage/Telegram）覆盖图文交互。
+- [[personal-crm]] ← 类似技术栈 ← [[Family Calendar Household Assistant]]
+  - 均通过 Telegram Topic 或 Slack Channel 提供自然语言查询接口。
+
+## Contradictions
+- 无已知冲突。
--- a/wiki/sources/knowledge-base-rag.md
+++ b/wiki/sources/knowledge-base-rag.md
@@ -1,48 +1,42 @@
---
-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 页面的内容冲突
+---
+title: "Personal Knowledge Base (RAG)"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/knowledge-base-rag.md]]
+
+## Summary（用中文描述）
+- 核心主题：构建可搜索的个人知识库，从所有保存的内容（文章/Tweet/YouTube 视频/PDF）中自动摄取并支持语义检索
+- 问题域：阅读了大量文章、视频和 Tweet，却永远找不到上周看到的那条内容；书签堆积变得毫无用处
+- 方法/机制：通过 Telegram Topic 或 Slack Channel 接收 URL → 自动抓取内容（文章/Tweet/YouTube 字幕/PDF）→ 语义索引入库 → 支持自然语言提问检索 → 可供其他工作流（如视频创意流水线）查询
+- 结论/价值：**捕获像发短信一样简单，检索像搜索一样简单**；零摩擦摄入 + 语义搜索是解决"知识黑洞"的核心
+
+## Key Claims（用中文描述）
+- Telegram Topic 或 Slack Channel 可作为个人知识库的零摩擦摄入入口，用户直接发 URL 即可
+- 语义搜索（Semantic Search）使"我存了什么关于 LLM 记忆的内容？"这类自然语言查询成为可能，返回带来源和摘要的排序结果
+- 知识库可作为其他 AI 工作流的检索后端——如视频创意流水线在构建研究卡片时自动查询相关已存内容
+
+## 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
+- [[Semantic Search]]：基于语义向量相似度的搜索，而非关键词匹配，实现自然语言查询已存内容
+- [[RAG]]（Retrieval-Augmented Generation）：将外部知识库检索与 LLM 生成结合，提升回答的上下文相关性
+- [[Knowledge Base]]：集中存储、结构化索引、可按需检索的个人或组织知识集合
+
+## Key Entities
+- [[OpenClaw]]：AI Agent 框架，驱动整个 KB 摄取和检索流程（fetch 内容 → 索引 → 查询响应）
+- [[Telegram]]：作为摄取入口的即时通讯平台，用户发 URL 到专属 Topic 触发自动摄入
+- [[Slack]]：Telegram 的替代摄取入口，通过 Channel 实现相同功能
+
+## Connections
+- [[Second Brain]] ← 理念同源 ← [[Personal Knowledge Base (RAG)]]
+- [[养虾日记3]] ← 受启发于 ← [[Personal Knowledge Base (RAG)]]
+- [[custom-morning-brief]] ← 可查询 ← [[Personal Knowledge Base (RAG)]]
+- [[semantic-memory-search]] ← 技术基础 ← [[Personal Knowledge Base (RAG)]]
+
+## Contradictions
+- 与 [[Second Brain]] 的摄入方式：[[Second Brain]] 侧重对话内捕获（发短信"Remind me..."），[[Personal Knowledge Base (RAG)]] 侧重 URL 链接的直接摄入——两者摄入路径不同，可互补而非冲突
--- a/wiki/sources/multi-source-tech-news-digest.md
+++ b/wiki/sources/multi-source-tech-news-digest.md
@@ -1,51 +1,50 @@
---
-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）。两者互补而非冲突，共同构成完整的内容监控体系。
+---
+title: "Multi-Source Tech News Digest"
+type: source
+tags: [RSS, Twitter, GitHub, Web-Search, News-Aggregation, OpenClaw, ClawHub]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/multi-source-tech-news-digest.md]]
+
+## Summary（用中文描述）
+- 核心主题：多来源技术新闻自动聚合、评分与分发框架
+- 问题域：AI/开源/前沿技术资讯的获取效率——人工逐一查看数十个 RSS、Twitter、GitHub 和新闻网站耗时且缺乏质量过滤
+- 方法/机制：四层数据管道（RSS × 46 + Twitter KOL × 44 + GitHub Releases × 19 + Brave Search × 4），通过标题相似度去重 + 多维质量评分（优先级来源 +3，多来源 +5，时效性 +2，互动量 +1），最终推送至 Discord/邮件/Telegram；通过自然语言添加自定义来源
+- 结论/价值：零配置开箱即用，30 秒内添加自定义 RSS/Twitter/GitHub 来源，完全可定制
+
+## Key Claims（用中文描述）
+- 多来源聚合（RSS + Twitter + GitHub + Web Search）能够显著提升技术资讯获取效率
+- 质量评分机制（优先级来源 + 多来源交叉验证 + 时效性 + 互动量）可有效过滤低质量内容
+- 自然语言驱动的来源管理使非技术用户可在 30 秒内添加任意来源
+- 定时调度 + 多渠道分发（Discord/邮件/Telegram）实现真正自动化
+
+## Key Quotes
+> "Staying updated across AI, open-source, and frontier tech requires checking dozens of RSS feeds, Twitter accounts, GitHub repos, and news sites daily. Manual curation is time-consuming, and most existing tools either lack quality filtering or require complex configuration." — 痛点描述
+> "The framework is fully customizable — add your own RSS feeds, Twitter handles, GitHub repos, or search queries in 30 seconds." — 核心价值主张
+
+## Key Concepts
+- [[Content-Aggregation]]：多来源内容聚合——通过合并去重解决信息碎片化问题
+- [[Quality-Scoring]]：多维质量评分体系——优先级来源、多来源交叉、时效性、互动量四个维度综合打分
+- [[Content-Deduplication]]：基于标题相似度的智能去重——避免同一内容从多个渠道重复出现
+- [[Multi-Channel-Delivery]]：多渠道分发——Discord、Webhook 邮件、Telegram 等多平台同步推送
+
+## Key Entities
+- [[DracoVibeCoding]]：「Draco正在VibeCoding」公众号作者，multi-source-tech-news-digest 等多个 OpenClaw Agent 自动化方案的提出者
+- [[ClawHub]]：tech-news-digest Skill 的托管平台，提供 `clawhub install tech-news-digest` 一键安装
+- [[vLLM]]（仅在来源列表中出现 1 次，不满足 Entity 创建条件）：GitHub Releases 监控的 19 个仓库之一
+- [[Dify]]（已有 Entity）：GitHub Releases 监控的 19 个仓库之一
+- [[LangChain]]（已有 Entity）：GitHub Releases 监控的 19 个仓库之一
+- [[Ollama]]（已有 Entity）：GitHub Releases 监控的 19 个仓库之一
+
+## Connections
+- [[multi-source-tech-news-digest]] ← depends_on ← [[RSSHub]]（RSS Feed 层通过 RSSHub 生成标准化 RSS）
+- [[multi-source-tech-news-digest]] ← extends ← [[blogwatcher-daily收藏]]（两者均聚焦多来源资讯聚合，但 tech-news-digest 侧重多平台大规模聚合 + 质量评分）
+- [[DracoVibeCoding]] — authored — [[multi-source-tech-news-digest]]
+
+## Contradictions
+- 与 [[blogwatcher-daily收藏]]：
+  - 冲突点：两者功能存在重叠（均聚合多来源技术资讯）
+  - 当前观点：multi-source-tech-news-digest 以定时 digest + 质量评分为核心，支持更多来源类型（RSS + Twitter + GitHub + Web Search）
+  - 对方观点：blogwatcher-daily 侧重 RSSHub 生态的本地部署，聚焦单一平台内容监控，强调 BlogWatcher skill 与 daily notes 的深度集成
--- a/wiki/sources/phone-call-notifications.md
+++ b/wiki/sources/phone-call-notifications.md
@@ -1,61 +1,61 @@
---
-title: "Phone Call Notifications"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/phone-call-notifications.md]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 通过真实电话呼叫（而非推送通知）向用户发送紧急提醒，实现 Agent → 用户双向语音通话
- 问题域：推送通知容易被忽视，聊天消息容易被埋没，紧急信息无法可靠触达用户
- 方法/机制：通过 clawr.ing 托管电话服务（无需 Twilio/API Key 配置），Agent 评估事件优先级，决定是否值得打电话，主动拨叫用户真实号码；通话中用户可实时提问，Agent 实时响应，实现真正的双向对话
- 结论/价值：电话是唯一可靠绕过注意力屏障的触达方式；Agent 主动判断"是否值得打电话"而非被动响应；clawr.ing 消除电话集成的技术门槛
-
-## Key Claims（用中文描述）
- Agent 主动拨叫用户，而非用户呼叫 Agent——这是注意力触达效率的关键差异
- clawr.ing 消除了电话 API 配置门槛，一段 setup prompt 即完成集成，覆盖 100+ 国家真实 PSTN 电话
- 电话通知需与 Heartbeat/Cron Job 配合作为触发器，clawr.ing 本身仅是投递通道
- 通话场景下应使用快速模型（Haiku 级别）以降低延迟
- clawr.ing 不存储录音或文字记录，音频传输加密后即时销毁
-
-## Key Quotes
-> "Phone call means 'this actually matters.' If your agent calls you 10 times a day, you'll start ignoring it."
-> — 核心设计原则：控制电话通知频率，保持其作为最高优先级触达通道的价值
-
-> "Unlike a push notification, you can ask follow-up questions on the call."
-> — 双向对话是电话通知区别于所有其他通知渠道的本质差异
-
-## Key Concepts
- [[Voice Notification Channel]]：Agent 通过主动拨打电话作为高优先级通知投递通道，与推送通知/聊天消息并列
- [[Two-Way Voice Conversation]]：Agent 主动拨叫用户，用户可实时提问，Agent 实时响应，而非单向广播
- [[Call-Worthy Threshold]]：仅当事件足够重要时才触发电话，避免通知疲劳
- [[PSTN Calling]]：真实公共交换电话网电话（非 VoIP 叠加层），确保全球覆盖和可靠接通
-
-## Key Entities
- [[clawr.ing]]：托管电话服务提供商，消除了 Twilio 等传统电话 API 的配置复杂度，为 Agent 提供一键电话呼叫能力
- [[OpenClaw]]：Agent 框架，通过 clawr.ing skill 实现主动电话通知功能
- [[clawhub.ai]]：OpenClaw Skill 市场，托管 clawr.ing skill 安装包
-
-## Connections
- [[Phone-Based-Personal-Assistant]] ← extends ← [[phone-call-notifications]]
-  - Phone-Based Personal Assistant 侧重 Agent 接收用户来电并进行语音交互（用户 → Agent）
-  - Phone Call Notifications 侧重 Agent 主动向外拨叫通知用户（Agent → 用户）
-  - 两者互为补充，构成完整的语音双向通信能力
- [[multi-channel-assistant]] ← shares_channel ← [[phone-call-notifications]]
-  - 同属 OpenClaw 多渠道个人助理体系，但 Phone Call Notifications 补充了最高优先级的语音触达通道
- [[Custom Morning Brief]] ← delivery_channel ← [[phone-call-notifications]]
-  - 晨间简报可通过电话通道投递，实现"每天 7:30 准时来电"场景
- [[Self-Healing-Home-Server]] ← delivery_channel ← [[phone-call-notifications]]
-  - 家庭服务器关键告警可通过电话第一时间触达用户
- [[earnings-tracker]] ← delivery_channel ← [[phone-call-notifications]]
-  - 股价暴跌等紧急事件可通过电话立即通知
-
-## Contradictions
- 与 [[phone-based-personal-assistant]] 存在方向差异：
-  - 冲突点：谁来发起通话
-  - 当前观点（phone-call-notifications）：Agent 主动拨叫用户，拨叫门槛高（仅紧急事件）
-  - 对方观点（phone-based-personal-assistant）：用户主动呼叫 Agent，Agent 接听并提供助理服务
-  - 协调说明：两者不冲突——前者用于紧急通知（Agent → 用户），后者用于主动查询（用户 → Agent），共同构成双向语音通信体系
+---
+title: "Phone Call Notifications"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/phone-call-notifications.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 通过真实电话呼叫（而非推送通知）向用户发送紧急提醒，实现 Agent → 用户双向语音通话
+- 问题域：推送通知容易被忽视，聊天消息容易被埋没，紧急信息无法可靠触达用户
+- 方法/机制：通过 clawr.ing 托管电话服务（无需 Twilio/API Key 配置），Agent 评估事件优先级，决定是否值得打电话，主动拨叫用户真实号码；通话中用户可实时提问，Agent 实时响应，实现真正的双向对话
+- 结论/价值：电话是唯一可靠绕过注意力屏障的触达方式；Agent 主动判断"是否值得打电话"而非被动响应；clawr.ing 消除电话集成的技术门槛
+
+## Key Claims（用中文描述）
+- Agent 主动拨叫用户，而非用户呼叫 Agent——这是注意力触达效率的关键差异
+- clawr.ing 消除了电话 API 配置门槛，一段 setup prompt 即完成集成，覆盖 100+ 国家真实 PSTN 电话
+- 电话通知需与 Heartbeat/Cron Job 配合作为触发器，clawr.ing 本身仅是投递通道
+- 通话场景下应使用快速模型（Haiku 级别）以降低延迟
+- clawr.ing 不存储录音或文字记录，音频传输加密后即时销毁
+
+## Key Quotes
+> "Phone call means 'this actually matters.' If your agent calls you 10 times a day, you'll start ignoring it."
+> — 核心设计原则：控制电话通知频率，保持其作为最高优先级触达通道的价值
+
+> "Unlike a push notification, you can ask follow-up questions on the call."
+> — 双向对话是电话通知区别于所有其他通知渠道的本质差异
+
+## Key Concepts
+- [[Voice Notification Channel]]：Agent 通过主动拨打电话作为高优先级通知投递通道，与推送通知/聊天消息并列
+- [[Two-Way Voice Conversation]]：Agent 主动拨叫用户，用户可实时提问，Agent 实时响应，而非单向广播
+- [[Call-Worthy Threshold]]：仅当事件足够重要时才触发电话，避免通知疲劳
+- [[PSTN Calling]]：真实公共交换电话网电话（非 VoIP 叠加层），确保全球覆盖和可靠接通
+
+## Key Entities
+- [[clawr.ing]]：托管电话服务提供商，消除了 Twilio 等传统电话 API 的配置复杂度，为 Agent 提供一键电话呼叫能力
+- [[OpenClaw]]：Agent 框架，通过 clawr.ing skill 实现主动电话通知功能
+- [[clawhub.ai]]：OpenClaw Skill 市场，托管 clawr.ing skill 安装包
+
+## Connections
+- [[Phone-Based-Personal-Assistant]] ← extends ← [[phone-call-notifications]]
+  - Phone-Based Personal Assistant 侧重 Agent 接收用户来电并进行语音交互（用户 → Agent）
+  - Phone Call Notifications 侧重 Agent 主动向外拨叫通知用户（Agent → 用户）
+  - 两者互为补充，构成完整的语音双向通信能力
+- [[multi-channel-assistant]] ← shares_channel ← [[phone-call-notifications]]
+  - 同属 OpenClaw 多渠道个人助理体系，但 Phone Call Notifications 补充了最高优先级的语音触达通道
+- [[Custom Morning Brief]] ← delivery_channel ← [[phone-call-notifications]]
+  - 晨间简报可通过电话通道投递，实现"每天 7:30 准时来电"场景
+- [[Self-Healing-Home-Server]] ← delivery_channel ← [[phone-call-notifications]]
+  - 家庭服务器关键告警可通过电话第一时间触达用户
+- [[earnings-tracker]] ← delivery_channel ← [[phone-call-notifications]]
+  - 股价暴跌等紧急事件可通过电话立即通知
+
+## Contradictions
+- 与 [[phone-based-personal-assistant]] 存在方向差异：
+  - 冲突点：谁来发起通话
+  - 当前观点（phone-call-notifications）：Agent 主动拨叫用户，拨叫门槛高（仅紧急事件）
+  - 对方观点（phone-based-personal-assistant）：用户主动呼叫 Agent，Agent 接听并提供助理服务
+  - 协调说明：两者不冲突——前者用于紧急通知（Agent → 用户），后者用于主动查询（用户 → Agent），共同构成双向语音通信体系
--- a/wiki/sources/semantic-memory-search.md
+++ b/wiki/sources/semantic-memory-search.md
@@ -1,46 +1,44 @@
---
-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 文件的语义索引
+---
+title: "Semantic Memory Search"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/semantic-memory-search.md]]
+
+## Summary（用中文描述）
+- 核心主题：为 OpenClaw 的 markdown 记忆文件添加向量语义搜索能力
+- 问题域：随着记忆文件增多，无法通过关键词查找语义相关内容
+- 方法/机制：使用 memsearch 工具，将 markdown 文件索引到 Milvus 向量数据库，结合语义搜索 + BM25 全文搜索 + RRF 重排
+- 结论/价值：实现按语义而非关键词搜索记忆，支持文件监控自动重索引，节省 API 调用的智能去重
+
+## Key Claims（用中文描述）
+- memsearch 通过 SHA-256 内容哈希实现增量索引，未变化的文件不会被重新嵌入，零 API 浪费
+- 混合搜索（稠密向量 + BM25）通过倒数排名融合（RRF）重排，优于纯向量搜索
+- Markdown 文件始终是数据源，向量索引只是可重建的派生缓存
+
+## Key Quotes
+> "There is no search, just scrolling through files." — 描述 OpenClaw 记忆系统的原始痛点
+> "Markdown stays the source of truth. The vector index is just a derived cache — you can rebuild it anytime with `memsearch index`." — 强调数据主权设计
+
+## Key Concepts
+- [[HybridSearch]]：结合语义相似度（稠密向量）与关键词匹配（BM25）的混合搜索方法
+- [[Incremental-Indexing]]：基于内容哈希的增量索引，只处理新增或变化的文件块
+- [[Reciprocal-Rank-Fusion]]：倒数排名融合，通过综合多个搜索结果排名生成最终排序
+- [[Vector-Embedding]]：向量嵌入技术，将文本编码为高维向量用于语义搜索
+
+## Key Entities
+- [[OpenClaw]]：开源的 AI Agent 记忆系统，将所有记忆存储为 markdown 文件
+- [[memsearch]]：基于 Milvus 的向量搜索 CLI/库，为 markdown 文件提供语义搜索能力
+- [[Milvus]]：开源向量数据库，为语义搜索提供底层存储和检索支持
+
+## Connections
+- [[memsearch]] ← built_on ← [[Milvus]]
+- [[memsearch]] ← enhances ← [[OpenClaw]]
+- [[semantic-memory-search]] ← related_to ← [[SecondBrain]]
+- [[semantic-memory-search]] ← similar_pain_point ← [[knowledge-base-rag]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/x-account-analysis.md
+++ b/wiki/sources/x-account-analysis.md
@@ -1,42 +1,41 @@
---
-title: "X Account Analysis"
-type: source
-tags: ["openclaw", "social-media", "analytics", "x-twitter"]
-date: 2026-04-23
---
-
-## Source File
- [[Agent/usecases/x-account-analysis]]
-
-## Summary（用中文描述）
- 核心主题：X（Twitter）账号定性分析——超越数字指标，洞悉内容质量
- 问题域：现有 X 分析工具（X Analytics / 第三方订阅服务）只展示统计数据，无法回答"为什么"的问题
- 方法/机制：OpenClaw + Bird Skill，通过 Cookie 认证（auth-token / ct0）读取真实账号推文，AI 定性分析内容模式、话题偏好与互动差异原因
- 结论/价值：免费替代 $10-$50/月 订阅服务，自然语言问答式交互，无需专用 App
-
-## Key Claims（用中文描述）
- OpenClaw + Bird Skill 可对 X 账号进行定性分析，揭示使帖子病毒式传播的模式
- AI 能回答"为何有时帖子 1000+ 赞，有时 <5 赞"——分析内容质量而非数字
- Bird Skill 预装在 OpenClaw 中（`clawhub install bird`）
- 为安全隔离建议创建专用 ClawdBot 账号，而非直接使用真实账号
-
-## Key Quotes
-> "There are many websites designed to give you X analytics, but they focus on the statistics. There are probably 1-2 websites that let you talk with an AI to understand your performance." — 现有分析工具痛点
-> "Now you can use OpenClaw to do this analysis for you, without needing to pay $10-$50 for subscriptions on these websites." — OpenClaw 免费替代方案
-
-## Key Concepts
- [[X/Twitter-API-Automation]]：通过 Cookie 认证实现 API 访问
- [[Social-Media-Analytics]]：定性分析 vs 定量分析
- [[Credential-Isolation]]：为机器人创建独立账号实现安全隔离
-
-## Key Entities
- [[OpenClaw]]：多 Agent 框架，提供记忆持久化和 Skill 扩展能力
- [[Bird Skill]]：OpenClaw X/Twitter 操作 Skill，预装或通过 `clawhub install bird` 安装
- [[ClawdBot]]：OpenClaw 的机器人实例，建议创建独立账号用于 X 操作
-
-## Connections
- [[x-twitter-automation]] ← extends ← [[x-account-analysis]]（操作 vs 分析，互补关系）
- [[content-factory]] ← can_use ← [[x-account-analysis]]（社交媒体内容策略分析）
-
-## Contradictions
-无已知冲突
+---
+title: "X Account Analysis"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/x-account-analysis.md]]
+
+## Summary（用中文描述）
+- 核心主题：利用 AI Agent（OpenClaw + Bird Skill）对 X（Twitter）账号进行定性分析
+- 问题域：现有 X 分析工具大多只提供数据统计（播放量、点赞数），缺乏对内容质量的深度洞察
+- 方法/机制：通过 Bird Skill 抓取账号最近 N 条推文，结合 AI 对话式问答，发现内容规律与问题点
+- 结论/价值：免费（相比 $10-$50/月订阅的第三方网站）、安全隔离（建议用专用 ClawdBot 账号）、支持深度提问与脚本编写
+
+## Key Claims（用中文描述）
+- 现有 X 分析网站（如analytics官方面板）侧重数据统计，而非内容质量分析
+- 定性分析能回答：什么模式让帖子病毒式传播？哪些话题带来最高互动？为什么有时1000+赞有时<5赞？
+- OpenClaw + Bird Skill 可替代付费订阅网站，实现免费定性分析
+- 为安全和隔离，建议为 ClawdBot 创建专用 X 账号，而非直接用自己的账号
+
+## Key Quotes
+> "There are many websites designed to give you a qualitative analysis of your X account. While X already gives you an analytics section, it's more focused to show your numbers on your performance." — 指出 X 官方分析工具的局限性
+> "But now you can use OpenClaw to do this analysis for you, without needing to pay $10-$50 for subscriptions on these websites." — OpenClaw 的成本优势
+
+## Key Concepts
+- [[定性分析（Qualitative Analysis）]]：关注内容质量而非数据指标，分析帖子模式、话题趋势、互动差异原因
+- [[Bird Skill]]：OpenClaw 的 X/Twitter 操作技能，支持抓取推文、认证、信息提取
+
+## Key Entities
+- [[OpenClaw]]：AI Agent 平台，支持通过 Skill 扩展功能
+- [[Bird Skill]]：`clawhub install bird` 安装的 X/Twitter 操作技能（预装在 OpenClaw 中）
+- [[ClawdBot]]：专用 Bot 账号，用于隔离操作、保障安全
+
+## Connections
+- [[X/Twitter Automation from Chat]] ← extends ← [[X Account Analysis]]
+- [[OpenClaw]] ← uses_skill ← [[Bird Skill]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/x-twitter-automation.md
+++ b/wiki/sources/x-twitter-automation.md
@@ -1,44 +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 场景的完整能力覆盖
+---
+title: "X/Twitter Automation from Chat"
+type: source
+tags: ["openclaw", "twitter", "x", "automation", "social-media", "plugin"]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/x-twitter-automation.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过自然语言在聊天中完成 X/Twitter 全功能自动化操作
+- 问题域：X/Twitter 账号管理需要在 App、第三方仪表盘和数据分析工具之间来回切换，缺乏统一的对话式交互界面
+- 方法/机制：TweetClaw（OpenClaw 插件）通过 X/Twitter 官方托管 API 连接 Agent，提供发推/互动、搜索提取、抽奖工具、账号监控四大功能模块
+- 结论/价值：用一个聊天界面替代所有 X/Twitter 管理工具，所有操作通过托管 API 完成，无 Cookie、无爬虫、无凭证暴露
+
+## Key Claims（用中文描述）
+- TweetClaw 插件通过自然语言交互实现 X/Twitter 全功能操作（发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人、账号监控）
+- 抽奖功能支持可配置的筛选条件（最低粉丝数、账号年龄、关键词要求），从推文互动用户中随机抽取获奖者
+- 账号监控功能可追踪指定账号的新推文或粉丝变化并发送通知
+- 所有 API 操作通过 TweetClaw 托管服务完成，无需浏览器 Cookie、无爬虫脚本、无凭证暴露
+
+## Key Quotes
+> "Managing an X/Twitter presence requires jumping between the app, third-party dashboards, and analytics tools." — 痛点描述
+> "All actions go through a managed API — no browser cookies, no scraping, no credential exposure." — 安全性说明
+
+## Key Concepts
+- [[X/Twitter-API-Automation]]：通过 API 接口程序化控制 X/Twitter 账号行为，替代手动操作或爬虫方案
+- [[Social-Media-Giveaway]]：通过程序化方式从推文互动用户中随机抽取获奖者，支持多条件筛选
+- [[Account-Monitoring]]：持续追踪指定账号的内容发布或粉丝变动并触发通知
+
+## Key Entities
+- [[TweetClaw]]：OpenClaw 插件，通过 @xquik/tweetclaw npm 包安装，连接 Agent 与 X/Twitter API
+- [[Xquik-dev]]：TweetClaw 的开发公司，维护 GitHub 仓库和 npm 包
+- [[OpenClaw]]：多 Agent 框架，提供持久化记忆和 Plugin 系统，TweetClaw 的宿主平台
+
+## Connections
+- [[X-Account-Analysis]] ← related ← [[x-twitter-automation]]（两者同属 X/Twitter 场景，X-Account-Analysis 侧重数据分析，本页面侧重自动化操作）
+- [[Content-Factory]] ← extends ← [[x-twitter-automation]]（Content-Factory 的社交媒体发布能力可由 TweetClaw 提供支持）
+- [[x-twitter-automation]] ← depends_on ← [[OpenClaw]]（TweetClaw 以 OpenClaw Plugin 形式运行，依赖 OpenClaw 的 Agent 执行环境）
+- [[n8n-workflow-orchestration]] ← complementary ← [[x-twitter-automation]]（n8n Webhook 模式可作为 TweetClaw API 的安全凭证托管层）
+
+## Contradictions
+- 无已知冲突。与 [[x-account-analysis]] 互补——分析 vs 操作，共同构成 X/Twitter 场景的完整能力覆盖
--- a/wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md
+++ b/wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md
@@ -1,46 +1,44 @@
---
-title: "不谈技术：普通人该怎么在AI时代赚钱？"
-type: source
-tags: []
-date: 2026-04-23
---
-
-## Source File
- [[微信公众号/不谈技术：普通人该怎么 在AI时代赚钱？]]
-
-## Summary（用中文描述）
- 核心主题：AI时代普通人如何赚钱的思维框架，核心观点是"AI不会让普通人变富，但会让有品味、知道自己要做什么的人变得极其强大"
- 问题域：普通人在AI浪潮中的自我定位与生存策略
- 方法/机制：三大思维原则——品味值钱、做端到端的事、用死亡过滤器
- 结论/价值：转变问题框架，从"怎么不被AI淘汰"到"AI能帮我做什么以前做不到的事"
-
-## Key Claims（用中文描述）
- AI让工具民主化，但品味没有民主化——90%的人用AI生成的东西是shit，因为他们不知道什么是好的
- 做端到端的事（做一个完整的产品/服务），远比在一个AI流水线里当"螺丝钉"更有价值且更抗替代
- 用死亡过滤器追问：对什么有genuine的热爱和curiosity？把那一件事做到insanely great
- "普通人"和"不普通的人"的区别不在天赋/资源/运气，而在于愿不愿意对一千件事说No，只对一件事说Yes
- AI不会让普通人变富；AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大
-
-## Key Quotes
-> "正确的问题是：AI让我能做到什么以前做不到的事？" — 重新框架问题本身
-> "工具民主化了，但品味没有民主化。" — 为什么90%的AI输出是shit
-> "一个人用AI做出一个完整的App，比一个100人的团队里当'AI提示词工程师'强一万倍。" — 端到端的价值
-> "他们愿不愿意对一千件事说No，只对一件事说Yes，然后把那一件事做到insanely great。" — 普通与不普通的分水岭
-
-## Key Concepts
- [[品味（审美）]]: 判断AI方案中哪个是insanely great的能力，是AI时代真正的护城河
- [[端到端（End-to-End）]]: 从头到尾做一个完整的产品/服务/解决方案，而非成为AI流水线上的零件
- [[死亡过滤器（Death Filter）]]: 每天早上问自己"如果今天是最后一天，我还会做今天要做的事吗？"用于过滤真正值得投入的事
- [[工具民主化]]: AI降低了做事的门槛，但判断力/品味依然是稀缺能力
-
-## Key Entities
- [[乔布斯]]: 文章借乔布斯之口阐述三大原则，Mac桌面出版的类比说明品味比工具更重要
-
-## Connections
- [[个人品牌与一人公司]] ← 相关 ← [[不谈技术-普通人该怎么在ai时代赚钱]]
-  - 两者都强调整个人定位：找到真正热爱的事，用AI杠杆放大优势
- [[Ikigai框架]] ← 关联 ← [[不谈技术-普通人该怎么在ai时代赚钱]]
-  - 死亡过滤器与Ikigai的"热情（Passion）"维度高度一致：对自己真正在乎的事说Yes
-
-## Contradictions
- 无明显冲突
+---
+title: "不谈技术：普通人该怎么在AI时代赚钱？"
+type: source
+tags: [AI, 个人发展, 财富思维, 品味]
+date: 2026-04-27
+---
+
+## Source File
+- [[raw/微信公众号/不谈技术：普通人该怎么在AI时代赚钱？]]
+
+## Summary（用中文描述）
+- 核心主题：AI时代普通人的财富创造策略——打破「学AI技能谋生」的思维定式
+- 问题域：AI技术普及背景下的个人竞争力与价值定位
+- 方法/机制：三大认知框架——①品味是护城河；②做端到端而非零件；③用死亡过滤器找到真正热爱
+- 结论/价值：AI不会让普通人变富；AI会让那些知道自己要做什么、且对品质有执念的人变得极其强大
+
+## Key Claims（用中文描述）
+- 品味（而非工具）成为AI时代区分因素：工具民主化后，90%的人用AI生成的东西是shit，因为缺乏判断什么是好的能力
+- 端到端做事优于做零件：一个人用AI做出完整App，比在100人团队里当「AI提示词工程师」强一万倍
+- 死亡过滤器揭示真正热爱：用「如果今天是最后一天」问题过滤，找到对某事物的genuine热爱，再将AI与之结合
+- 「普通人」与「不普通的人」的核心差异：愿不愿意对一千件事说No，只对一件事说Yes，然后把那一件事做到insanely great
+
+## Key Quotes
+> "工具民主化了，但品味没有民主化" — 1984年Mac发布后90%桌面出版内容丑陋，当前AI同样面临此问题
+> "别做别人AI流水线上的一个螺丝钉，因为螺丝钉是最容易被替换的" — 零件思维的致命缺陷
+> "一个人用AI做出一个完整的App，比一个100人的团队里当AI提示词工程师强一万倍" — 端到端的价值对比
+> "AI不会让普通人变富。AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大" — 全文核心结论
+
+## Key Concepts
+- [[品味作为护城河]]：AI工具民主化后，品味（判断什么是好的能力）成为核心竞争力；能判断AI给出的10个方案里哪个是insanely great的人，比只会点「生成」按钮的人强一百倍
+- [[端到端优势]]：不做一个AI流水线上的零件，而是用AI做一个完整的产品/服务/解决方案，从头到尾控制；iPod成功不在于最好的MP3解码器，而在于iTunes到iPod到iTunes Store的完整体验
+- [[死亡过滤器]]：每天早上问「如果今天是最后一天，我还会做今天要做的事吗？」——用于过滤找到真正热爱的事物，而非追逐「最赚钱的AI技能」
+
+## Key Entities
+- [[乔布斯.skill]]：本文署名来源，以乔布斯口吻阐述三大认知框架；核心引用Mac、iPod、iTunes等Apple产品案例说明品味与端到端思维
+- [[Mac]]：1984年桌面出版民主化案例——工具民主化后90%产出丑陋，说明品味不会随工具民主化而普及
+- [[iPod]]：「端到端」成功案例——iPod成功不在于最好的MP3解码器，而在于iTunes+iPod+iTunes Store完整生态
+
+## Connections
+- [[乔布斯.skill]] ← 署名来源 ← [[不谈技术-普通人该怎么在ai时代赚钱]]
+
+## Contradictions
+- 无已知冲突
+
--- a/wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md
+++ b/wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md
@@ -1,59 +1,57 @@
---
-title: "养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统"
-type: source
-tags: [AI-Agent, Obsidian, Gitea, 知识管理, LLM-Wiki]
-date: 2026-04-09
---
-
-## Source File
- [[微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统]]
-
-## Summary（用中文描述）
- 核心主题：如何用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统，解决 AI 对话结束后输出丢失的核心问题
- 问题域：AI Agent 的输出持久化、版本控制、多端同步
- 方法/机制：用 Obsidian 做知识库（多端同步）、Gitea 做版本控制（Git 历史）、OpenClaw 做写入接口（obsidian skill）
- 结论/价值：把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录
-
-## Key Claims（用中文描述）
- OpenClaw Agent 通过 obsidian skill 将输出直接写入 Obsidian 笔记，实现持久化存储
- Gitea 托管笔记的 Git 版本管理，任何时候都能回溯历史变更
- iCloud Drive 保证手机、笔记本和 Mac mini 三端笔记永远同步
- 笔记目录采用分层结构：knowledgebase/ 存放跨 Agent 共用知识，<agentId>/ 存放单一 Agent 私有笔记
- Karpathy 的 LLM Wiki 思路：让 AI 增量构建和维护持久化 Wiki，页面间互相链接，知识越积越厚
- Obsidian Graph View 可以发现"孤岛页面"和"幽灵节点"（被多处引用但没有独立页面的概念）
-
-## Key Quotes
-> "用 Obsidian 做知识库，用 Gitea 做版本控制，用 OpenClaw 做写入接口。" — 核心架构概括
-> "AI 批量改文件的能力越强，你越需要版本管理来兜底。" — 版本管理的重要性
-> "本质上是把 AI 变成了一个'会自动整理笔记的实习生'——它做完事，就会顺手把记录更新好。" — 系统价值定位
-> "RAG 模式是'每次从零检索'，知识不积累；而 LLM Wiki 是让 AI 增量构建和维护一个持久化的 Wiki，页面之间互相链接，知识越积越厚。" — Karpathy LLM Wiki 核心理念
-
-## Key Concepts
- [[LLM Wiki]]：让 AI 增量构建和维护持久化的 Wiki，页面间互相链接，知识越积越厚（区别于 RAG 的"每次从零检索"）
- [[Obsidian Git]]：Obsidian 社区插件，支持 Auto commit-and-sync interval，自动 commit + push 到 Git 仓库
- [[Graph View]]：Obsidian 内置图谱视图，将所有 Wiki 页面以节点展示，双链关系自动连线，用于发现孤岛页面和知识盲区
- [[Obsidian Web Clipper]]：浏览器插件，用于快速采集外部网页文章为 Markdown 到 Obsidian，配合图片本地化
- [[QMD]]：完全本地运行的 Markdown 搜索引擎，适合 Wiki 规模变大后的精准搜索
- [[版本管理]]：Git 历史记录每一次变更的来源和内容，支持回溯和多协作
- [[被动更新]]：AI 在执行任务过程中顺手维护链接、更新摘要、添加 Tag、标记新旧矛盾，而非被动等着被查询
- [[双链笔记]]：Obsidian 的核心特性，页面间通过 [[wikilinks]] 互相链接形成知识网络
-
-## Key Entities
- [[Gitea]]：自建 Git 服务，托管笔记的版本控制，所有历史版本完整保留
- [[Obsidian]]：笔记管理工具，支持多端同步（iCloud Drive）和双链笔记
- [[OpenClaw]]：AI Agent 框架，提供 obsidian skill 作为写入接口
- [[Karpathy]]：LLM Wiki 理念的提出者（2026-03 分享）
- [[iCloud Drive]]：Apple 云同步服务，确保笔记在 Mac mini、笔记本和 iPhone 三端同步
-
-## Connections
- [[养虾日记1]] ← 同一系列 ← [[养虾日记2]]
- [[养虾日记1]] ← 同一系列 ← [[养虾日记3]]
- [[养虾日记2]] ← 同一系列 ← [[养虾日记3]]
- [[养虾日记4]] ← 同一系列 ← [[养虾日记5]]
- [[Second Brain]] ← 类似的持久化记忆理念 ← [[养虾日记3]]
- [[Personal Knowledge Base (RAG)]] ← 相关的知识管理方案 ← [[养虾日记3]]
- [[LLM Wiki]] ← 核心理论支撑 ← [[养虾日记3]]
- [[self-healing-home-server]] ← 使用同款笔记系统 ← [[养虾日记3]]
-
-## Contradictions
- 无已知冲突
+---
+title: "养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统"
+type: source
+tags: []
+date: 2026-04-09
+---
+
+## Source File
+- [[微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统]]
+
+## Summary（用中文描述）
+- 核心主题：使用 Obsidian + Gitea 构建 AI 助手的持久化笔记系统，解决 AI 输出随对话结束而丢失的核心问题
+- 问题域：AI Agent 的"记忆缺失"——对话结束后所有分析、结论、操作步骤全部消失，无法复用
+- 方法/机制：Gitea 做版本控制 + Obsidian 做知识库 + OpenClaw Obsidian Skill 做写入接口 + iCloud Drive 多端同步
+- 结论/价值：把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录，知识越积越厚
+
+## Key Claims（用中文描述）
+- OpenClaw Agent 将输出直接写入 Obsidian 笔记，工作笔记在 Mac mini、Laptop、iCloud Drive 三端同步，历史版本在 Gitea 中完整保留
+- 研究过程写入 Agent Archive，经过验证可复用的知识沉淀到 Knowledge Base，实现知识的分类管理
+- Git 版本管理让"任何时候都能回溯"，commit message 记录每次变更的来源和内容
+- Obsidian Git 插件设为 Auto commit-and-sync interval（如 10 分钟），自动 commit + push，完全无需手动操作
+- AI 在执行任务过程中"顺手维护链接、更新摘要、添加 Tag、标记新旧矛盾"，实现被动更新而非被动等待查询
+
+## Key Quotes
+> "一句话概括：用 Obsidian 做知识库，用 Gitea 做版本控制，用 OpenClaw 做写入接口。" — 核心系统架构总结
+
+> "RAG 模式是'每次从零检索'，知识不积累；而 LLM Wiki 是让 AI 增量构建和维护一个持久化的 Wiki，页面之间互相链接，知识越积越厚。" — Karpathy LLM Wiki 核心洞察
+
+> "本质上是把 AI 变成了一个'会自动整理笔记的实习生'——它做完事，就会顺手把记录更新好。" — 系统本质定位
+
+## Key Concepts
+- [[Agent Archive]]：单一 Agent 的私有笔记目录（如 openclaw/xingshu/），用于记录研究过程和工作输出
+- [[Knowledge Base]]：跨 Agent 共用的知识库目录（如 openclaw/knowledgebase/），存放经过整理的公共知识
+- [[LLM Wiki]]：让 AI 增量构建和维护持久化 Wiki 的方法论，区别于 RAG 的"从零检索"，Wiki 知识越积越厚
+- [[Obsidian Web Clipper]]：浏览器插件，快速将网页文章剪藏为 Markdown 并自动下载图片到本地 attachments/
+- [[Graph View]]：Obsidian 内置图谱视图，用于发现孤岛页面和知识盲区
+- [[Obsidian Git]]：社区插件，支持设置 Auto commit-and-sync interval 实现笔记的自动版本控制
+- [[QMD]]：纯本地运行的 Markdown 搜索引擎，当 Wiki 规模达到几百个页面后接入使用
+
+## Key Entities
+- [[Obsidian]]：笔记管理工具，提供双链、Graph View、多端同步能力，是系统的知识库前端
+- [[Gitea]]：自建 Git 服务，作为笔记的版本控制后端，保留所有历史版本
+- [[OpenClaw]]：AI Agent 框架，通过 obsidian skill（write/append/read/search/update）作为写入接口
+- [[iCloud Drive]]：云同步服务，确保笔记在 Mac mini、Laptop、iPhone 多端保持一致
+
+## Connections
+- [[Second Brain]] ← related_to ← [[养虾日记3]]
+- [[knowledge-base-rag]] ← related_to ← [[养虾日记3]]（两者均涉及知识管理，但本文强调持久积累 vs RAG 的从零检索）
+- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]] ← related_to ← [[养虾日记3]]（本文是 Karpathy LLM Wiki 思路的具体实践）
+- [[obsidian-高效指南-我常用的插件与实用技巧]] ← extends ← [[养虾日记3]]（Obsidian 插件配置的具体实操参考）
+
+## Contradictions
+- 与 [[knowledge-base-rag]] 冲突：
+  - 冲突点：RAG 模式每次从零检索，知识不积累；LLM Wiki 增量积累知识
+  - 当前观点（本文）：LLM Wiki 优于 RAG——AI 在执行任务过程中顺手维护链接、更新摘要，知识越积越厚
+  - 对方观点（[[knowledge-base-rag]]）：RAG 模式通过向量语义搜索实现知识复用，适合快速检索场景
+  - 评估：两者可互补——Wiki 负责长期积累，RAG 负责快速检索入口
--- a/wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md
+++ b/wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md
@@ -1,57 +1,58 @@
---
-title: "养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑"
-type: source
-tags: [OpenClaw, 错误排查, Context-Window, Telegram, 日志调试]
-date: 2026-04-10
---
-
-## Source File
- [[微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md]]
-
-## Summary（用中文描述）
- 核心主题：OpenClaw Agent 系统的 Context Limit 错误深度排查——从表象修复（调整 compaction 配置）到找到根本原因（Telegram channel 绑定了只有 16K context 的 DeepSeek 模型）
- 问题域：OpenClaw Telegram Channel 配置、模型 Fallback 机制、Context Window 管理
- 方法/机制：通过 Gateway 日志定位到模型被切换为 deepseek-reasoner（16K context），safeguard 模式预留 16K tokens 导致实际可用空间为 0；问题根源在 Agent 路由规则而非全局配置
- 结论/价值：错误信息 ≠ 问题根因；分层配置需要分层排查；日志是系统状态的最直接反映
-
-## Key Claims（用中文描述）
- 星枢 Telegram Channel 触发「Context limit exceeded」，直接原因并非对话历史过长，而是当前使用的模型（deepseek-reasoner）context window 仅 16K
- OpenClaw safeguard 模式在 compaction 时预留 16K tokens，与 16K context 模型叠加，导致实际可用 context 为 0
- 全局 compaction 配置（openclaw.json）与 Agent 级别模型配置是两套独立层级，修改全局配置无法解决 Agent 级别的模型问题
- 解决根本方案是将星枢 Telegram channel 的路由改回 MiniMax-M2.7（200K context），而非继续调低 compaction 阈值
- 日志分析是定位此类"隐藏配置路径"问题的唯一可靠手段
-
-## Key Quotes
-> `provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000 / estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384` — Gateway 日志直接揭示了模型切换和 token 耗尽问题
-> `「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题` — 核心教训：错误表象 ≠ 根本原因
-> `不要默认认为错误信息就是表面意思。先问一句：到底哪儿出问题了？` — 最终方法论总结
-
-## Key Concepts
- [[Context-Window]]: 模型单次请求能处理的最大 token 数量；deepseek-reasoner 仅 16K，MiniMax-M2.7 为 200K
- [[Model-Fallback]]: 当默认模型不可用时，OpenClaw 按优先级切换到 fallback 列表中的下一个模型；触发原因包括 API 503/429/Timeout、路由权重错误、或配置覆盖
- [[Compaction]]: OpenClaw 的上下文压缩机制，在 safeguard 模式下会预留 16K tokens 用于执行压缩操作
- [[Agent-Routing-Rules]]: 绑定 Telegram channel 到特定模型的路由规则，优先级高于全局配置
- [[Error-Surface-vs-Root-Cause]]: 不要被错误信息的字面意思误导；表象修复 ≠ 根本解决
- [[Layered-Configuration]]: OpenClaw 配置分全局配置（openclaw.json）和 Agent/Channel 级别配置；问题可能藏在不同层级
- [[Log-Driven-Debugging]]: Gateway 日志直接揭示了模型切换事件和 token 分配详情，是定位问题的唯一可靠手段
- [[Hidden-Failure-Paths]]: 复杂分布式系统中，故障可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方
-
-## Key Entities
- [[OpenClaw]]: 运行星枢的 AI Agent 框架；本文核心调试对象
- [[星枢]]: 用户的 AI 助手（xingshu/main agent）；通过 Telegram 与用户交互
- [[DeepSeek]]: deepseek-reasoner 模型提供方；context window 仅 16K，是本次问题的直接触发者
- [[MiniMax]]: MiniMax-M2.7 模型提供方；context window 为 200K，是正确的配置目标
-
-## Connections
- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] ← related_to ← [[养虾日记4]]（同属 OpenClaw 调试系列，互补关系）
- [[养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战]] ← related_to ← [[养虾日记4]]（同属"养虾日记"系列）
- [[养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]] ← related_to ← [[养虾日记4]]（同属"养虾日记"系列）
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]] ← related_to ← [[养虾日记4]]（同属"养虾日记"系列）
- [[n8n调用hermes-agents的工作流架构]] ← related_to ← [[养虾日记4]]（OpenClaw 配置层级问题在此亦有体现）
-
-## Contradictions
- 与 [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] 的互补关系：
-  - 冲突点：养龙虾系列重点在记忆写入/检索失效（semantic memory、context compression），本文重点在模型配置错误导致 context 立即耗尽
-  - 当前观点：两者均为 OpenClaw "记忆失效"症状的不同根因；养龙虾系列归因于记忆插件和压缩机制，本文归因于模型配置本身
-  - 对方观点：养龙虾系列认为写入纪律和压缩协同是主要挑战
-  - 说明：互补而非冲突，两类问题可同时存在
+---
+title: "养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑"
+type: source
+tags: ["调试经验", "OpenClaw", "模型配置", "Context-Window", "养虾日记"]
+date: 2026-04-10
+---
+
+## Source File
+- [[微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenClaw AI Agent 系统中"Context Limit Exceeded"错误的深度排查与解决
+- 问题域：OpenClaw 的模型路由、Compaction 机制与 Telegram Channel 配置的交叉地带
+- 方法/机制：通过 Gateway 日志（`openclaw logs`）定位问题根因——模型回退（Fallback）机制导致 Telegram Channel 绑定了只有 16K context 的 deepseek-reasoner，而 OpenClaw 的 safeguard 模式又预留 16K 给 compaction，实际可用空间为 0
+- 结论/价值：不要轻信表面错误信息；OpenClaw 全局配置与 Agent 级别模型配置是两层独立的配置体系；Gateway 日志是排查分布式 Agent 问题的关键工具
+
+## Key Claims（用中文描述）
+- 星枢的 Telegram Channel 被回退到了只有 16K context window 的 deepseek-reasoner 模型，而非用户默认的 MiniMax-M2.7（200K）
+- OpenClaw 的 safeguard 模式会为 compaction 预留 token 数（reserveTokens=16384），两者叠加导致 context window 完全被耗尽
+- 问题配置不在 `openclaw.json` 全局 compaction 配置里，而在 OpenClaw 的 agent 路由规则中，所以修改全局 compaction 配置无效
+- Fallback 触发原因包括：API 服务不可用（503/502/429/Timeout）、Token 长度隐式溢出预判、配置文件优先级覆盖、负载均衡随机切换
+
+## Key Quotes
+> "deepseek-reasoner 的 context window 只有 16K？" — 发现模型被切换后的震惊
+> "好家伙，这谁扛得住" — 得知 16K context + 16K reserve = 0 可用空间后的反应
+> "别小看任何报错，也别急着改配置。先问一句：到底哪儿出问题了？" — 核心教训总结
+
+## Key Concepts
+- [[Context-Window]]：模型的上下文窗口大小，MiniMax-M2.7 为 200K，deepseek-reasoner 仅 16K
+- [[Compaction]]：OpenClaw 的上下文压缩/压缩保护机制，safeguard 模式会预留一半 context 给 compaction
+- [[Fallback-机制]]：当主模型不可用或触发特定条件时，自动切换到备选模型
+- [[Agent-Routing-Rules]]：OpenClaw 的 agent 级别模型配置，独立于全局 compaction 配置
+
+## Key Entities
+- [[OpenClaw]]：自托管 AI Agent 系统，星枢（xingshu/main agent）运行在其上
+- [[星枢]]：xingshu/main agent，星枢通过 Telegram Channel 与用户交互
+- [[MiniMax-M2.7]]：用户默认使用的模型，context window 为 200K
+- [[deepseek-reasoner]]：回退备选模型，context window 仅 16K，导致问题的元凶
+- [[openclaw logs]]：Gateway 日志工具，用于排查 OpenClaw 系统问题
+
+## Connections
+- [[养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战]] ← series_prequel ← [[养虾日记4]]
+- [[养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]] ← series_prequel ← [[养虾日记4]]
+- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]] ← series_prequel ← [[养虾日记4]]
+- [[养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流]] ← series_sequel ← [[养虾日记4]]
+- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] ← related ← [[养虾日记4]]（均为 OpenClaw 调试实战记录）
+- [[OpenClaw]] ← uses ← [[Compaction]]（OpenClaw 通过 Compaction 机制管理长对话）
+- [[星枢]] ← runs_on ← [[OpenClaw]]（星枢 agent 运行在 OpenClaw 系统上）
+- [[星枢]] ← connected_to ← Telegram（Telegram Channel 是星枢的对话入口）
+
+## Contradictions
+- 无冲突——本文为调试经验分享，与其他养虾日记系列构成互补关系（养虾1-3为使用场景本文为运维调试）
+
+## Lessons Learned
+1. 不要默认认为错误信息就是表面意思——「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题
+2. 两层配置要分清：全局 compaction 配置和 agent 模型配置是两码事，改全局不行就得往 agent 级别去找
+3. 日志真的有用：Gateway 日志把问题写得明明白白，只是之前没仔细看
+4. 工具/系统越复杂，问题的隐藏路径越深：OpenClaw 这种分布式 agent 系统，问题可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方