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

2026-04-27 12:03:03 +08:00
parent fbd6107be4
commit 83c6e24e7c
45 changed files with 1898 additions and 886 deletions
--- a/wiki/sources/claude-code调用方法总结.md
+++ b/wiki/sources/claude-code调用方法总结.md
@@ -1,50 +1,42 @@
---
-title: "Claude Code 调用方法总结"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[raw/Agent/claude-code调用方法总结]]
-
-## Summary（用中文描述）
- 核心主题：Hermes Agent 通过 terminal 工具调用 Claude Code 的两种模式及最佳实践
- 问题域：如何从外部 Agent（如 Hermes）可靠地触发并控制 Claude Code 执行任务
- 方法/机制：Print Mode（stdin 单次执行）与 TMUX 交互模式两种调用路径；关键参数包括 `--permission-mode bypassPermissions`、`--dangerously-skip-permissions`、`--add-dir`、`--max-turns`
- 结论/价值：明确了何时使用 `claude -p` 而非 `delegate_task`，以及如何正确传递任务、配置 Skill 加载、规避常见坑点
-
-## Key Claims（用中文描述）
- Hermes Agent 使用 `terminal` 工具调用 `claude -p` 是调用 Claude Code 的推荐方式
- `--permission-mode bypassPermissions` 直接设置 bypass 模式，跳过所有交互确认
- 任务文本通过 stdin（heredoc）传入比命令行参数更可靠，可避免特殊字符转义问题
- `delegate_task` 调用的是 Hermes 子 Agent（API 调用），无法识别 SKILL.md；当任务需要 Claude Code 技能时应使用 `terminal` 调用 `claude -p`
- Skill 加载只需 `--add-dir <技能目录>`，Claude Code 会自动扫描 SKILL.md 和 `.claude/skills/` 目录
-
-## Key Quotes
-> "用 `--permission-mode bypassPermissions` 可直接跳过信任目录 + bypass 权限确认两步，不需要额外的 sleep + send-keys 模拟交互。" — 核心参数说明
-> "不写 bypass 参数 → 文件写入被阻塞，任务卡住（优先用 `--permission-mode bypassPermissions`）" — 常见坑点
-> "当任务需要调用 Claude Code 的 skill（如 fireworks-tech-graph）时，应使用 `terminal` 调用 `claude -p`，而非 `delegate_task`" — 结论
-
-## Key Concepts
- [[Print Mode]]：通过 `claude -p print` 非交互单次执行模式，适合绝大多数任务
- [[TMUX 交互模式]]：通过 TMUX 创建持久会话并附加交互，适合超长任务
- [[bypassPermissions]]：`--permission-mode bypassPermissions` 参数，直接跳过所有权限确认
- [[Skill 加载]]：`--add-dir` 加载技能目录，自动识别 SKILL.md
- [[delegate_task vs claude -p]]：子 Agent vs 外部 CLI 的本质区别与适用场景
-
-## Key Entities
- [[Claude Code]]：Anthropic CLI agent，被调用方
- [[Hermes]]：主 Agent，通过 terminal 工具调用 Claude Code
- [[TMUX]]：终端多路复用器，用于持久化 Claude Code 交互会话
-
-## Connections
- [[Claude Code]] ← 调用方 ← [[Hermes]]
- [[claude-code调用方法总结]] ← 补充 ← [[如何在项目里安装Claude Code Templates Skills]]
- [[claude-code调用方法总结]] ← 对比 ← [[delegate_task vs claude -p]]
-
-## Contradictions
- 与 [[llm-wiki]] 冲突：
-  - 冲突点：llm-wiki 中描述的 `delegate_task + acp_command='claude'` 调用 Claude Code 路径
-  - 当前观点：AGENTS.md 中说明只有 `provider=copilot-acp` 时 acp 参数才真正建立外部 CLI 通道；普通 `delegate_task` 调用的是 Hermes 子 Agent
-  - 对方观点：llm-wiki 描述了通过 ACP 协议调用 Claude Code 的方式，可能在特定配置下有效
+---
+title: "Claude Code 调用方法总结"
+type: source
+tags: [claude-code, hermes, ai-agent, terminal, skill]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/claude-code调用方法总结]]
+
+## Summary（用中文描述）
+- 核心主题：Hermes Agent 如何通过 terminal 工具调用 Claude Code CLI，包含两种调用模式和完整的参数说明
+- 问题域：AI Agent 集成与外部工具调用、Claude Code 的程序化调用方式
+- 方法/机制：Print Mode（推荐）和 TMUX 交互模式两种 CLI 调用路径，通过 stdin 传递任务文本，支持 `--permission-mode bypassPermissions` 跳过交互确认
+- 结论/价值：为 Hermes Agent 与 Claude Code 的深度集成提供了标准化调用模板，是使用 Claude Code skill（如 fireworks-tech-graph）的前置知识
+
+## Key Claims（用中文描述）
+- Hermes 通过 `terminal` 工具调用 Claude Code，有 Print Mode 和 TMUX 交互模式两种方式
+- `--permission-mode bypassPermissions` 可直接跳过信任目录和权限确认两步，比 `--dangerously-skip-permissions` 更可靠
+- Skill 加载只需 `--add-dir <技能所在目录>`，Claude Code 自动扫描 SKILL.md
+- `delegate_task` 调用的是 Hermes 子 agent（API），无法使用 Claude Code 的 SKILL.md 能力；当任务需要 Claude Code skill 时必须用 `terminal` 调用 `claude -p`
+
+## Key Quotes
+> "用 `--permission-mode bypassPermissions` 可直接跳过信任目录 + bypass 权限确认两步，不需要额外的 sleep + send-keys 模拟交互" — bypass 模式最简写法
+> "当任务需要调用 Claude Code 的 skill（如 fireworks-tech-graph）时，应使用 `terminal` 调用 `claude -p`，而非 `delegate_task`" — delegate_task 与 terminal 调用的本质区别
+
+## Key Concepts
+- [[ClaudeCodePrintMode]]：Claude Code 的非交互单次执行模式，通过 `claude -p print` 配合 stdin 传递任务文本，适合绝大多数自动化场景
+- [[ClaudeCodeTerminalIntegration]]：Hermes Agent 通过 terminal 工具调用 Claude Code 的两种集成方式（Print Mode 和 TMUX 交互模式）
+- [[SubagentDelegation]]：Hermes Agent 的子 agent 委托机制，通过 API 调用 LLM，无法使用 Claude Code SKILL.md
+
+## Key Entities
+- [[ClaudeCode]]：（Anthropic 官方 CLI 工具）——注意：尚未创建独立 Entity 页面，此处仅作概念标注
+
+## Connections
+- [[ClaudeCodeTerminalIntegration]] ← 包含 ← [[ClaudeCodePrintMode]]
+- [[ClaudeCodeTerminalIntegration]] ← 包含 ← [[TMUX 交互模式]]
+- [[ClaudeCodeTerminalIntegration]] ← 依赖 ← [[bypassPermissions]]
+- [[SubagentDelegation]] ← 对比 ← [[ClaudeCodePrintMode]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/custom-morning-brief.md
+++ b/wiki/sources/custom-morning-brief.md
@@ -1,44 +1,50 @@
---
-title: "Custom Morning Brief"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/custom-morning-brief]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 驱动的个性化晨间简报系统
- 问题域：个人生产力 / 信息过载 / 早晨时间利用
- 方法/机制：定时任务调度（每日固定时间） + AI 研究助理（抓取相关新闻） + 待办列表集成 + 主动任务推荐（AI 自主思考可帮助用户完成的事项）+ 创意内容生成（睡前完成完整稿件/邮件/方案草稿，而非仅提供标题）
- 结论/价值：将 AI 闲置的夜间时间转化为生产力，用户醒来即可获得结构化简报，把早晨最有价值的注意力用于决策而非信息收集
-
-## Key Claims（用中文描述）
- AI 主动推荐任务 → 用户从"等指令"变为"收到已完成的成果"，实现真正的自动驾驶式助理
- 完整草稿（full draft scripts）比标题建议 → 节省用户时间，醒来直接使用
- 简报个性化 → 发送文字消息即可调整，无需重新配置
-
-## Key Quotes
-> "The AI-recommended tasks section is the most powerful part — it has the agent proactively think of ways to help you, rather than waiting for instructions." — 核心洞察
-> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." — 与竞品差异化价值
-> "You can customize the brief just by texting. Say 'Add stock prices to my morning brief' and it updates." — 低门槛个性化
-
-## Key Concepts
- [[Scheduled Task Flywheel]]：定时任务飞轮——利用夜间空闲时间让 AI 完成前置工作，用户醒来直接使用成果
- [[Proactive Agent Recommendation]]：主动任务推荐——AI 自主思考可帮助用户完成的事项，而非被动等待指令
- [[Multi-Channel Integration]]：多渠道集成——Telegram / Discord / iMessage 统一消息入口
-
-## Key Entities
- [[OpenClaw]]：多 Agent 记忆框架，本简报场景的核心执行引擎
- [[Alex Finn]]：OpenClaw 玩家，YouTube 视频激发了此工作流的流行
- [[Todoist]]：待办列表集成目标之一（支持 Apple Reminders / Asana）
- [[x-research-v2]]：ClaHub 上的社交媒体趋势研究工具（可选集成）
-
-## Connections
- [[phone-based-personal-assistant]] ← shared_user_case ← [[custom-morning-brief]]（两者均强调 AI 在用户无主动操作时提供价值）
- [[multi-channel-assistant]] ← uses ← [[OpenClaw]]（均依赖 OpenClaw 的多渠道消息集成能力）
- [[self-healing-home-server]] ← extends ← [[custom-morning-brief]]（Reef 的 Morning Briefing 是 custom-morning-brief 的家庭服务器垂直场景实例）
-
-## Contradictions
- 无已知冲突
+---
+title: "Custom Morning Brief"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/custom-morning-brief.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenClaw AI 代理的"个性化早间简报"工作流——每天定时发送包含新闻、任务、创意内容草稿和 AI 主动建议的完整报告。
+- 问题域：用户最宝贵的时间（早晨）被低效的信息获取消耗；AI 代理夜间闲置造成资源浪费。
+- 方法/机制：定时任务（每日 8:00 AM）+ 消息推送（Telegram/Discord/iMessage）+ 任务管理器集成（Todoist/Apple Reminders/Asana）+ 网络新闻研究 + AI 主动推荐可自主完成的任务。
+- 结论/价值：将夜间空闲时间转化为高效准备时间；完整草稿（非仅标题/想法）才是节省时间的关键；通过自然语言随时定制简报内容。
+
+## Key Claims（用中文描述）
+- AI 代理夜间主动完成任务（生成草稿、研究新闻），用户醒来即可看到成品——把空闲时间转化为生产力。
+- 完整内容草稿（脚本、邮件、方案）比单纯的想法/标题节省更多时间，醒来就能用。
+- AI 推荐可自主完成的任务是最强大的功能——让 AI 主动思考如何帮助你，而非被动等待指令。
+- 通过发消息给 Bot 自然语言定制简报，无需重新配置——"Add stock prices to my morning brief" 即时生效。
+
+## Key Quotes
+> "You wake up and spend the first 30 minutes of your day catching up — scrolling news, checking your calendar, reviewing your to-do list, trying to figure out what matters today. What if all of that was already done and waiting for you as a text message?" — 核心愿景描述
+> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." — 核心价值主张
+> "The AI-recommended tasks section is the most powerful part — it has the agent proactively think of ways to help you, rather than waiting for instructions." — 最强功能洞察
+
+## Key Concepts
+- [[ScheduledReport]]：定时推送结构化报告的工作流，区别于按需查询——主动性是核心差异
+- [[ProactiveAI]]：AI 代理主动预测需求、推荐行动，而非被动响应用户指令
+- [[FullDraftGeneration]]：生成可直接使用的完整内容（脚本、邮件、方案），而非仅提供标题/想法
+
+## Key Entities
+- [[OpenClaw]]：本工作流的承载平台——调度任务、整合工具、生成报告的 AI Agent 框架
+- [[AlexFinn]]：OpenClaw 生活改变级用例视频的创作者，本工作流灵感来源
+- [[Telegram]]：主要消息推送通道之一
+- [[Todoist]]：任务管理器集成选项之一
+
+## Connections
+- [[MultiChannelAssistant]] ← extends ← [[CustomMorningBrief]]
+  - 多渠道助理已包含定时提醒能力，本工作流是其"定时主动推送"的具体应用场景
+- [[TodoistTaskManager]] ← depends_on ← [[CustomMorningBrief]]
+  - 从 Todoist 拉取今日任务列表是简报的任务模块数据源
+- [[SecondBrain]] ← similar_to ← [[CustomMorningBrief]]
+  - 都是将外部信息聚合后呈现给用户；区别在于 Second Brain 是被动查询，本工作流是主动推送
+- [[ScheduledReminder]] ← similar_to ← [[CustomMorningBrief]]
+  - 均为定时触发的 AI 推送，但本工作流内容更丰富（新闻+任务+草稿+建议）
+
+## Contradictions
+- 无已知冲突。本工作流与其他定时/推送类工作流为互补或层级扩展关系。
--- a/wiki/sources/daily-youtube-digest.md
+++ b/wiki/sources/daily-youtube-digest.md
@@ -1,58 +1,47 @@
---
-title: "Daily YouTube Digest"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/daily-youtube-digest]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 每日 YouTube 频道视频摘要推送——自动获取订阅频道最新视频、提取字幕、生成要点摘要，以 Digest 形式定时送达用户
- 问题域：YouTube 通知不可靠（算法压制）、刷推荐内容浪费时间、难以系统性追踪感兴趣的创作者更新
- 方法/机制：
-  - 通过 [[OpenClaw]] 的 `youtube-full` skill 安装并配置 TranscriptAPI.com API（100 免费积分，无需信用卡）
-  - AI Agent 定期检查频道最新上传 → 提取字幕 → 摘要 → 发送 Digest
-  - 支持两种模式：频道列表模式（指定 @TED/@Fireship 等）+ 关键词模式（搜索 "Claude Code"/"AI agents" 等）
-  - seen-videos.txt 机制避免重复处理
-  - `channel/latest` 和 `channel/resolve` API 免费（0 积分），仅字幕抓取收费（1 积分/视频）
- 结论/价值：把算法推荐的被动消费（doom-scrolling）转变为系统化的主动学习，用 AI 把"没时间看视频"变成"每天花 10 分钟获取精华"
-
-## Key Claims（用中文描述）
- YouTube 通知不可靠：订阅频道的新视频不会出现在通知或首页推荐中，被算法压制
- 每日 Digest 是对抗信息过载的有效策略：不是每条视频都值得看，但值得知道它们的存在
- TranscriptAPI.com 优于 yt-dlp：纯 HTTP API、无二进制依赖、跨平台可靠、支持缓存、不易被 YouTube 封禁
- 频道检查（channel/latest）完全免费，只需在有字幕的感兴趣视频上花费积分
- 已存在商业产品：Recapio - Daily YouTube Recap（recapio.com）
-
-## Key Quotes
-> "You subscribe to channels, but their new videos never show up in your home feed. They're not in notifications. They just... disappear." — 痛点描述
-> "It's fun to start the day with curated content insights instead of doom-scrolling a recommendation feed." — 价值主张
-> "This way you never waste credits re-fetching videos you've already seen." — 避免重复处理
-
-## Key Concepts
- [[Daily-Digest]]：定时将多个信息源的最新内容打包推送给用户的模式，替代实时通知的碎片化消费
- [[Transcript-Based Summarization]]：通过视频字幕提取 + AI 摘要实现视频内容的结构化处理，绕过长视频消费的"没时间"困境
- [[Channel-Based Monitoring]]：以订阅频道为单位跟踪新内容，而非依赖平台推荐算法
- [[Keyword-Based Monitoring]]：以关键词为触发条件搜索新内容，适合跟踪特定主题或竞品动态
- [[Credit-Efficient Processing]]：优化 API 调用策略（免费检查优先、按需付费摘要），降低 AI 消费成本
-
-## Key Entities
- [[OpenClaw]]：多 Agent 框架，支持持久记忆和工作流编排，运行 youtube-full skill
- [[ClawHub]]（clawhub.ai）：OpenClaw skill 市场，托管 youtube-full 等 Agent 技能包
- [[TranscriptAPI.com]]：YouTube 字幕 API 服务商（YouTubeToTranscript.com 的背后技术），提供 HTTP API 替代 CLI 工具，100 免费积分
- [[Recapio]]：商业竞品产品，提供 Daily YouTube Recap 功能（recapio.com）
-
-## Connections
- [[OpenClaw]] ← runs ← [[youtube-full skill]]
- [[youtube-full skill]] ← uses ← [[TranscriptAPI.com]]
- [[Daily YouTube Digest]] ← similar_to ← [[multi-source-tech-news-digest]]
- [[Daily YouTube Digest]] ← extends ← [[second-brain]] (信息摄入层)
-
-## Contradictions
- 与 [[实战笔记-本地部署-rsshub-并获取-youtube-订阅]] 可能存在重叠：
-  - 冲突点：两者都提供 YouTube 订阅内容追踪
-  - 当前观点（Daily YouTube Digest）：AI Agent 自动抓字幕 + 摘要，主动推送 Digest
-  - 对方观点（RSSHub）：通过 RSS 标准协议追踪更新，适合工作流集成（n8n），无 AI 摘要
-  - 补充：RSSHub 方案适合被动监控；AI Digest 方案适合主动学习，两者互补
+---
+title: "Daily YouTube Digest"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/daily-youtube-digest.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 每日自动抓取订阅频道新视频，通过 TranscriptAPI 获取字幕并生成摘要，定时推送个性化简报
+- 问题域：YouTube 算法推送不靠谱，订阅频道的新视频经常被淹没；用户想每天用精选内容洞察开启新的一天，而不是刷推荐流浪费时间
+- 方法/机制：youtube-full skill → channel/latest 检查新视频（免费）→ TranscriptAPI 获取字幕（1 credit/条）→ AI 摘要生成 → 定时/按需推送
+- 结论/价值：TranscriptAPI 比 yt-dlp 更适合 Agent 环境（无日志洪水、跨平台兼容、防封禁）；仅检查新上传免费，生成摘要才消耗积分
+
+## Key Claims（用中文描述）
+- YouTube 通知系统不可靠，订阅频道的新视频经常被算法埋没，用户实际上想看但看不到
+- 每日用精选内容洞察开启一天，比刷推荐信息流更有价值
+- channel/latest 和 channel/resolve 完全免费（0 credit），仅生成摘要才消耗积分
+- TranscriptAPI 相比 yt-dlp 在 Agent 场景下优势明显：无日志洪水、支持云端/本地、支持全部平台、防封禁
+
+## Key Quotes
+> "You subscribe to channels, but their new videos never show up in your home feed. They're not in notifications. They just... disappear." — YouTube 通知系统的核心痛点
+> "That's it. The agent handles the rest — including account creation and API key setup." — OpenClaw 自动化安装的承诺
+
+## Key Concepts
+- [[DailyDigest]]：定时推送的个性化内容摘要，本文档的核心概念
+- [[ContentCuration]]：内容策展，从海量信息中精选符合用户兴趣的高价值内容
+
+## Key Entities
+- [[OpenClaw]]：运行 AI Agent 的平台，youtube-full skill 的宿主
+- [[TranscriptAPI]]：字幕获取 API，比 yt-dlp 更适合 Agent 环境，提供干净 JSON 响应和全球缓存服务
+- [[YouTube]]：视频内容来源，支持通过频道 handle 或关键词搜索
+- [[Recapio]]：商业竞品产品，提供每日 YouTube 摘要功能
+
+## Connections
+- [[YouTube Content Pipeline]] ← extends ← [[Daily YouTube Digest]]
+- [[Multi-Source Tech News Digest]] ← similar_to ← [[Daily YouTube Digest]]
+- [[YouTube Content Pipeline]] ← uses ← [[TranscriptAPI]]
+
+## Contradictions
+- 与 [[Multi-Source Tech News Digest]] 功能重叠但互补：
+  - 冲突点：两者都提供每日内容摘要
+  - 当前观点：Daily YouTube Digest 专注 YouTube 视频内容，通过 TranscriptAPI 获取深度字幕摘要
+  - 对方观点：Multi-Source Tech News Digest 覆盖多来源（RSS/博客/新闻），范围更广但深度较浅
+  - 共存建议：两者可并行使用，YouTube 视频适合深度学习场景，多来源摘要适合快速扫读
--- a/wiki/sources/earnings-tracker.md
+++ b/wiki/sources/earnings-tracker.md
@@ -1,42 +1,46 @@
---
-title: "AI-Powered Earnings Tracker"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/earnings-tracker.md]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 自动化追踪科技公司财报
- 问题域：财报季需要追踪数十家科技公司的财报发布日期和结果，手动操作繁琐
- 方法/机制：
-  - 每周日 Cron Job 扫描财报日历，过滤关注的科技/AI 公司
-  - 用户选择后，OpenClaw 为每家公司创建一次性 Cron Job
-  - 财报发布后自动搜索结果，生成结构化摘要（beat/miss、营收、EPS、AI 亮点）
-  - 通过 Telegram 话题推送
- 结论/价值：零手动追踪，财报发布后自动收到个性化摘要
-
-## Key Claims（用中文描述）
- AI Agent 通过每周日定时扫描财报日历来自动化追踪流程
- 一次性 Cron Job 在财报发布日期自动触发搜索和摘要生成
- 结构化摘要包含业绩表现（beat/miss）、财务数据（营收、EPS）和 AI 相关亮点
-
-## Key Quotes
-> "Following earnings season across dozens of tech companies means checking multiple sources and remembering report dates." — 问题陈述：多公司财报追踪的痛点
-
-## Key Concepts
- [[Cron Job]]：定时任务，用于每周扫描和单次触发
- [[Telegram Topic]]：Telegram 话题分组，用于分类推送财报通知
-
-## Key Entities
- [[OpenClaw]]：驱动整个工作流的核心 Agent 框架
- 科技公司：NVDA、MSFT、GOOGL、META、AMZN、TSLA、AMD 等
-
-## Connections
- [[earnings-tracker]] ← depends_on ← [[web_search]]
- [[earnings-tracker]] ← delivers_to ← [[Telegram Topic]]
-
-## Contradictions
- 无已知冲突
+---
+title: "AI-Powered Earnings Tracker"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/earnings-tracker.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 自动追踪科技公司财报并生成摘要推送至 Telegram
+- 问题域：财报季人工查阅多个来源、记忆财报日期的繁琐工作
+- 方法/机制：OpenClaw Cron Job 定时扫描财报日历 → 用户筛选 → 单次定时任务在财报发布后自动搜索结果并生成摘要 → Telegram 推送
+- 结论/价值：把被动查财报变成主动推送，解放人工重复劳动
+
+## Key Claims（用中文描述）
+- OpenClaw 通过 Cron Job 实现每周自动扫描财报日历并推送预览
+- 用户选择要追踪的公司后，OpenClaw 为每家公司创建一次性定时任务
+- 财报发布后，OpenClaw 自动搜索结果并生成包含 Beat/Miss、关键指标、AI亮点的结构化摘要
+- 定时任务保留用户追踪偏好记忆，下次自动建议
+
+## Key Quotes
+> "Every Sunday at 6 PM, run a cron job to: 1. Search for the upcoming week's earnings calendar for tech and AI companies 2. Filter for companies I care about (NVDA, MSFT, GOOGL, META, AMZN, TSLA, AMD, etc.) 3. Post the list to my Telegram 'earnings' topic" — OpenClaw 每周预览 Prompt 示例
+
+## Key Concepts
+- [[Cron-Job]]：定时任务机制，用于定期扫描财报日历和单次执行财报结果搜索
+- [[AI-Agent]]：OpenClaw 作为 AI Agent 驱动整个追踪流程——搜索、筛选、格式化、推送
+- [[Telegram-Topic]]：Telegram Topic 作为财报更新专用的信息隔离通道
+
+## Key Entities
+- [[OpenClaw]]：AI Agent 平台，提供 Cron Job 支持和 Telegram 集成，是本工作流的核心引擎
+- [[NVDA]]（英伟达）：用户通常追踪的科技公司之一，AI/芯片行业代表
+- [[MSFT]]（微软）：用户通常追踪的科技公司之一
+- [[GOOGL]]（谷歌）：用户通常追踪的科技公司之一
+- [[META]]（Meta）：用户通常追踪的科技公司之一
+- [[AMZN]]（亚马逊）：用户通常追踪的科技公司之一
+- [[TSLA]]（特斯拉）：用户通常追踪的科技公司之一
+- [[AMD]]（超威半导体）：用户通常追踪的科技公司之一
+
+## Connections
+- [[Daily-YouTube-Digest]] ← similar_pattern ← [[Earnings-Tracker]]（同为 Cron Job + Telegram 推送模式）
+- [[Custom-Morning-Brief]] ← similar_pattern ← [[Earnings-Tracker]]（同为定时主动推送 + 用户确认模式）
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/event-guest-confirmation.md
+++ b/wiki/sources/event-guest-confirmation.md
@@ -1,48 +1,49 @@
---
-title: "Event Guest Confirmation"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/event-guest-confirmation]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 通过电话自动确认活动嘉宾出席情况
- 问题域：活动组织者手动逐一电话确认出席的低效痛点
- 方法/机制：OpenClaw + SuperCall 插件实现 AI 语音电话批量外呼，确认出席并收集备注
- 结论/价值：真人电话比短信回复率高，AI persona 保证通话安全隔离和话题专注
-
-## Key Claims（用中文描述）
- OpenClaw + SuperCall 通过 AI 语音电话自动确认活动嘉宾出席状态（主体 + 机制 + 结果）
- SuperCall 的沙盒 persona 设计使 AI 只拥有预设上下文，无法访问用户 Agent 或文件（主体 + 机制 + 结果）
- 沙盒 persona 每通电话独立重置，避免对话间信息混淆（主体 + 机制 + 结果）
- 通话后汇总生成出席确认、未出席、未接听三分类摘要（主体 + 机制 + 结果）
-
-## Key Quotes
-> "The key difference: SuperCall is a fully standalone voice agent. The AI persona on the call only has access to the context you provide (the persona name, the goal, and the opening line)." — 解释 SuperCall 与内置 voice_call 插件的核心差异
-> "The person on the other end of the call can't manipulate or access your agent through the conversation. There's no risk of prompt injection or data leakage." — 强调安全隔离机制
-> "Real phone calls cost money: Each call uses Twilio minutes." — 提醒实际部署成本考量
-
-## Key Concepts
- [[SuperCall]]：OpenClaw 的独立语音 Agent 插件，基于 GPT-4o Realtime API，每通电话独立沙盒运行
- [[Sandboxed Persona]]：SuperCall 的核心设计原则——AI persona 只拥有预设的 persona name、goal、opening line，无法访问外部系统
- [[AI 电话外呼]]：通过 Twilio 电话网络实现的 AI 批量自动外呼确认流程
-
-## Key Entities
- [[OpenClaw]]：多 Agent 框架，提供 memory、workflow 编排和 SuperCall 插件集成能力
- [[SuperCall]]：由 @xonder 开发的 OpenClaw 语音插件（clawhub.ai/xonder/supercall）
- [[Twilio]]：电话外呼基础设施提供商，提供拨打电话的分钟数计费服务
- [[ngrok]]：Webhook 隧道工具，用于将本地服务暴露给 Twilio 的回调请求
-
-## Connections
- [[phone-based-personal-assistant]] ← similar_use_case ← [[event-guest-confirmation]]
- [[OpenClaw]] ← powers ← [[event-guest-confirmation]]
- [[SuperCall]] ← enables ← [[event-guest-confirmation]]
-
-## Contradictions
- 与 [[phone-based-personal-assistant]] 对比：
-  - 冲突点：两者都使用电话外呼，但 [[event-guest-confirmation]] 强调 SuperCall 的独立沙盒特性；[[phone-based-personal-assistant]] 更侧重个人助手的日常任务场景
-  - 当前观点：[[event-guest-confirmation]] 认为 SuperCall 的独立沙盒设计对确认类任务更安全专注
-  - 对方观点：[[phone-based-personal-assistant]] 可能更适合需要访问更多上下文的复杂对话场景
+---
+title: "Event Guest Confirmation"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/event-guest-confirmation]]
+
+## Summary（用中文描述）
+- 核心主题：使用 OpenClaw + SuperCall 插件实现活动嘉宾自动电话确认
+- 问题域：活动筹备、嘉宾管理、电话外呼自动化
+- 方法/机制：通过 SuperCall（独立语音 Agent）逐个拨打嘉宾电话，AI 以活动协调员人设与嘉宾对话，确认出席、收集饮食需求、Plus-One 等信息，通话结束后汇总报告
+- 结论/价值：相比短信/手动拨号，AI 电话显著提升响应率；沙箱化设计保障隐私安全
+
+## Key Claims（用中文描述）
+- SuperCall 相比内置 voice_call 插件更安全：通话另一端无法操控或访问用户 Agent，无提示注入或数据泄露风险
+- 沙箱化语音 Agent 每次通话独立重置，不会产生对话间的上下文污染，适合批量拨打
+- AI 电话比短信/手动拨号响应率高，适合 20+ 嘉宾的大型活动确认
+- 通话产生 Twilio 费用，大规模嘉宾列表需在 Twilio 账户设置用量限制
+
+## Key Quotes
+> "SuperCall is a fully standalone voice agent. The AI persona on the call only has access to the context you provide (the persona name, the goal, and the opening line). It cannot access your gateway agent, your files, your other tools, or anything else." — 强调 SuperCall 的沙箱隔离特性
+
+> "Because the AI is scoped to a single focused task (confirm attendance), it stays on-topic and handles the call more naturally than a general-purpose voice agent would." — 专用 vs 通用语音 Agent 的对比
+
+## Key Concepts
+- [[SuperCall]]：OpenClaw 的独立语音 Agent 插件，通过 Twilio + OpenAI GPT-4o Realtime API 实现来电外呼；每次通话沙箱隔离，不访问用户主 Agent
+- [[Sandboxed Persona]]：SuperCall 中 AI 通话人设的概念；仅持有提供的上下文（人设名、目标、开场白），与主 Agent 完全隔离
+- [[Batch Phone Call]]：批量外呼模式；SuperCall 逐个拨打嘉宾列表，通话结束后汇总出席/拒绝/未接状态
+- [[Twilio]]：电话外呼基础设施；提供电话号码和通话分钟数，是 SuperCall 的底层通信依赖
+
+## Key Entities
+- [[OpenClaw]]：主 Agent 平台，SuperCall 插件的宿主；通过对话指令触发批量电话拨打
+- [[xonder]]（SuperCall 开发者）：SuperCall 插件的作者，插件托管于 ClawHub
+
+## Connections
+- [[Phone Call Notifications]] ← related_to ← [[Event Guest Confirmation]]
+- [[Phone-Based Personal Assistant]] ← related_to ← [[Event Guest Confirmation]]
+- [[OpenClaw]] ← uses ← [[SuperCall]]
+- [[SuperCall]] ← depends_on ← [[Twilio]]
+- [[SuperCall]] ← depends_on ← [[OpenAI Realtime API]]
+
+## Contradictions
+- 与 [[Phone Call Notifications]] 可能的冲突：
+  - 冲突点：两者都涉及电话功能，但 Phone Call Notifications 更偏向通知提醒，本文档偏向主动外呼确认
+  - 当前观点：Event Guest Confirmation 专注于活动嘉宾确认场景，强调 SuperCall 的沙箱安全设计
+  - 对方观点：Phone Call Notifications 可能使用通用 voice_call 插件，缺乏沙箱隔离机制
--- a/wiki/sources/meeting-notes-action-items.md
+++ b/wiki/sources/meeting-notes-action-items.md
@@ -1,55 +1,59 @@
---
-title: "Automated Meeting Notes & Action Items"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/meeting-notes-action-items.md]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 自动将会议录音转录文本转换为结构化会议记录，并自动在项目管理工具中创建待办任务
- 问题域：会议记录人工整理耗时（20+分钟）、行动项容易遗忘、任务分配缺乏追踪机制
- 方法/机制：监听会议转录文本来源 → 提取关键决策和行动项 → 自动创建 Jira/Linear/Todoist/Notion 任务 → 发送 Slack/Discord 摘要 → 截止日前自动提醒
- 结论/价值：**自动创建任务**比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"
-
-## Key Claims（用中文描述）
- AI Agent 通过消除"已讨论"到"已追踪"之间的Gap，提升团队协作效率
- 转录文本来源可以是 Otter.ai 导出、Google Meet 转录、Zoom 录制摘要或直接粘贴文本
- 真正的价值不在摘要，而在于**自动任务创建**——会议记录如果不变成可追踪的任务，只是"文档剧场"
- VTT/SRT 字幕文件（Zoom/Google Meet 导出）因包含时间戳而更适合作为输入，可帮助 Agent 区分发言人
- 应采用渐进式自动化：先从"粘贴转录文本 → 获取摘要"开始，逐步扩展到文件夹监听和 API 集成
-
-## Key Quotes
-> "Meeting notes that don't become tracked tasks are just documentation theater." — 核心洞察
-> "Start simple (paste transcript, get summary) and automate incrementally. Don't over-engineer the pipeline before validating the output quality." — 实施建议
-> "VTT/SRT subtitle files from Zoom or Google Meet work great as input — they include timestamps which help the agent attribute statements to speakers." — 输入格式建议
-
-## Key Concepts
- [[MeetingNotes]]：会议记录的 AI 自动化生成，包括摘要提取、关键决策识别、行动项抽取
- [[ActionItemTracking]]：从会议记录中识别并追踪分配给特定人员的待办事项
- [[TaskAutomation]]：通过 AI Agent 自动在项目管理工具（Jira/Linear/Todoist/Notion）中创建任务
- [[TranscriptProcessing]]：处理会议转录文本，包括 VTT/SRT 格式解析和发言人识别
-
-## Key Entities
- [[Jira]]：Atlassian 项目管理工具，支持通过 REST API 创建任务，Agent 将会议行动项自动同步到 Jira
- [[Linear]]：现代项目管理工具，提供 GraphQL API，Agent 将行动项自动同步到 Linear 项目
- [[Todoist]]：个人/团队任务管理工具，Agent 将个人会议行动项自动添加到 Todoist
- [[Notion]]：多功能协作工具，支持数据库操作，Agent 将会议摘要和行动项写入 Notion 页面
- [[Otter.ai]]：AI 会议转录服务，提供 API 导出转录文本，作为 Agent 的会议输入来源
- [[Fireflies.ai]]：AI 会议助手，自动记录和转录会议，作为 Agent 的会议输入来源
- [[Slack]]：团队沟通平台，Agent 通过 Incoming Webhook 将会议摘要发布到指定频道
- [[Discord]]：社区/团队沟通平台，Agent 将会议摘要发送到服务器频道
-
-## Connections
- [[MeetingNotes]] ← depends_on ← [[TranscriptProcessing]]
- [[ActionItemTracking]] ← extends ← [[Todoist Task Manager]]
- [[TaskAutomation]] ← uses ← [[Jira]], [[Linear]], [[Todoist]], [[Notion]]
- [[MeetingNotes]] ← uses ← [[Otter.ai]], [[Fireflies.ai]]
-
-## Contradictions
- 与 [[todoist-task-manager]] 可能存在重叠：
-  - 冲突点：两者都涉及 Todoist 任务管理，但侧重不同
-  - 当前观点：[[MeetingNotes]] 专注于从会议转录自动提取行动项后创建任务
-  - 对方观点：[[todoist-task-manager]] 侧重于通用的 Todoist 任务管理和提醒设置
+---
+title: "Automated Meeting Notes & Action Items"
+type: source
+tags: [agent-use-case, productivity, automation, task-management]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/meeting-notes-action-items.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 将会议转录文本自动转换为结构化笔记，并自动在项目管理系统中创建任务
+- 问题域：会议笔记繁琐耗时（20+ 分钟），行动项常被遗忘或埋没在聊天记录中，导致"讨论了但未追踪"
+- 方法/机制：监控转录来源 → LLM 提取关键决策和行动项 → Jira/Linear/Todoist API 创建任务 → Slack/Discord 发布摘要 → Cron Job 截止日前提醒
+- 结论/价值：真正的价值不在摘要，而在于**自动任务创建**——不转化为可追踪任务的会议笔记只是"文档表演"
+
+## Key Claims（用中文描述）
+- AI Agent 消除"讨论了"到"已追踪"之间的鸿沟——会议结束的瞬间，任务已分配给责任人
+- 自动任务创建是会议笔记 Agent 的核心价值——会议笔记若不转化为可追踪任务，只是"文档表演"
+- 会议记录的价值不在摘要本身，而在于将行动项自动录入项目管理系统
+- Zoom/Google Meet 的 VTT/SRT 字幕文件是理想输入格式——自带时间戳，可帮助 Agent 准确归属发言内容
+- 从简单开始（粘贴转录文本→获取摘要），逐步自动化，不要在验证输出质量前过度工程化
+
+## Key Quotes
+> "Meeting notes that don't become tracked tasks are just documentation theater." — 会议笔记 Agent 的核心价值主张
+
+> "The real value isn't in the summary — it's in the automatic task creation." — 自动任务创建是核心，摘要是副产品
+
+> "Start simple (paste transcript, get summary) and automate incrementally. Don't over-engineer the pipeline before validating the output quality." — 推荐实施路径
+
+## Key Concepts
+- [[AI-Driven Task Extraction]]：从非结构化文本（会议转录）中自动提取任务要素（做什么/谁负责/截止日期）并创建结构化任务
+- [[Task Automation Pipeline]]：自然语言输入 → 结构化解析 → API 调用 → 结果确认 → 持续追踪的完整流水线
+- [[Meeting-to-Task Workflow]]：会议结束 → 自动提取行动项 → 在项目管理系统中创建任务 → 分配责任人 → 截止日提醒
+- [[Recurring Tasks]]：截止日提醒机制——在截止日前通过 Slack 主动 ping assignee
+- [[DocumentationTheater]]：（隐含反讽概念）仅产出文档但无实际追踪效果的会议笔记
+
+## Key Entities
+- [[Otter.ai]]：会议转录服务，提供自动语音转文字和导出功能，是本 Agent 的转录来源之一
+- [[Jira]]：Atlassian 项目管理工具，Agent 可通过 REST API 为每个行动项创建 ticket 并分配责任人
+- [[Linear]]：现代项目管理系统，提供 GraphQL API，Agent 可直接创建 Issue 并关联团队成员
+- [[Todoist]]：跨平台任务管理工具，支持自然语言截止日期设置
+- [[Notion]]：文档+数据库平台，Agent 可在 Notion Database 中创建任务页面
+- [[Slack]]：团队协作工具，Agent 发布会议摘要到指定频道，让全团队有记录
+- [[Discord]]：团队沟通平台（可替代 Slack），Agent 发布会议摘要到指定频道
+
+## Connections
+- [[Todoist Task Manager]] ← extends ← [[Meeting Notes Action Items]]：会议场景下的任务管理扩展，两者共享 AI 驱动的任务提取能力
+- [[Meeting Notes Action Items]] ← uses ← [[Otter.ai]]：Otter.ai 的会议转录作为 Agent 的输入数据源
+- [[Meeting Notes Action Items]] ← creates_tasks_in ← [[Jira]]：会议行动项 → Jira ticket → 分配责任人
+- [[Meeting Notes Action Items]] ← creates_tasks_in ← [[Linear]]：会议行动项 → Linear Issue → 分配责任人
+- [[Meeting Notes Action Items]] ← posts_summary_to ← [[Slack]]：会议摘要 → Slack 频道 → 全团队可见
+- [[AI-Driven Task Extraction]] ← feeds ← [[Meeting Notes Action Items]]：会议场景下的具体任务提取实现
+
+## Contradictions
+- 与 [[Todoist Task Manager]] 互补而非冲突：
+  - 冲突点：无实质性冲突，两者关注点不同
+  - 当前观点：[[Todoist Task Manager]] 侧重于"随时随地通过自然语言创建任务"；[[Meeting Notes Action Items]] 侧重于"从会议转录中自动提取和创建任务"
+  - 对方观点：两者可以结合使用——会议行动项自动录入 Todoist，实现"会议即任务"闭环
--- a/wiki/sources/multi-agent-team.md
+++ b/wiki/sources/multi-agent-team.md
@@ -1,63 +1,59 @@
---
-title: "Multi-Agent Specialized Team (Solo Founder Setup)"
-type: source
-tags: []
-date: 2026-04-23
---
-
-## Source File
- [[Agent/usecases/multi-agent-team.md]]
-
-## Summary（用中文描述）
- **核心主题**：用多个专业化 AI Agent 组建团队，解决一人创业者（Solo Founder）身兼数职、上下文切换破坏深度工作的困境
- **问题域**：一人公司运营、AI Agent 协作架构、个人生产力系统
- **方法/机制**：4 个专业 Agent（Milo/策略、Josh/商业、Marketing/营销、Dev/开发）通过共享记忆 + 私有上下文 + Telegram 单一控制平面协调运作，定时任务驱动主动工作流，并行执行提升效率
- **结论/价值**：AI Agent 个性化（名字+人格）比技术本身更重要；共享记忆 + 私有上下文组合是关键；定时任务是价值飞轮；起步从 2 个 Agent 而非 4 个开始
-
-## Key Claims（用中文描述）
- 单个 Agent 无法精通所有领域：上下文窗口在同时处理策略、代码、营销研究、商业分析时快速填满
- 泛化提示产生泛化输出：编程 Agent 不应该同时撰写营销文案
- 一人公司需要团队而非另一个管理工具：Agent 应在后台工作并呈现结果，而非需要持续看护
- 知识孤岛问题：营销研究的洞察不会自动影响开发优先级，除非手动桥接
- 个性比想象中更重要：给 Agent 起名字和沟通风格，让人自然地"与团队对话"而非使用通用 AI
- 共享记忆 + 私有上下文组合是关键：Agent 需要共同基础（目标、决策）也需要积累领域专业知识的独立空间
- 根据任务复杂度匹配模型能力：不要用昂贵的推理模型做关键词监控
- 定时任务是价值飞轮：真正的价值来自 Agent 主动呈现洞察，而非仅在被询问时响应
- 从 2 个 Agent 而非 4 个开始：先用 1 个领导 + 1 个专家的组合，再根据瓶颈逐步添加
-
-## Key Quotes
-> "One agent can't do everything well: A single agent's context window fills up fast when juggling strategy, code, marketing research, and business analysis" — 单一 Agent 上下文溢出的痛点描述
-> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI" — Agent 个性化设计的核心洞察
-> "Scheduled tasks are the flywheel: The real value emerges when agents proactively surface insights, not just when you ask" — 定时任务作为价值飞轮
-> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks" — 从小规模起步的实践建议
-
-## Key Concepts
- [[Agent Specialization]]：专业分工，每个 Agent 有独特角色、性格和针对其领域优化的模型
- [[Agent Personality]]：Agent 个性化设计，赋予名字和沟通风格使协作更自然
- [[Shared Memory Architecture]]：共享记忆架构，团队通用文件（GOALS.md、DECISIONS.md、PROJECT_STATUS.md）
- [[Private Context]]：私有上下文，各 Agent 独立维护会话历史和领域特定笔记
- [[Single Control Plane]]：单一控制平面，所有 Agent 通过 Telegram 分组统一接入
- [[Scheduled Task Flywheel]]：定时任务飞轮，Agent 主动工作而非被动等待
- [[Parallel Agent Execution]]：并行执行，多个 Agent 可同时处理独立任务
-
-## Key Entities
- [[OpenClaw]]：多 Agent 框架，提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排
- [[Milo]]：策略领导 Agent，Claude Opus 模型，负责战略规划、Agent 协调、OKR 追踪
- [[Josh]]：商业分析 Agent，Claude Sonnet 模型，负责定价策略、增长指标、KPI 追踪
- [[Marketing Agent]]：营销研究 Agent，Gemini 模型，负责内容创意、竞品监控、SEO 研究
- [[Dev Agent]]：开发 Agent，Claude Opus/Codex 模型，负责编码、代码审查、架构决策
- [[Telegram]]：单一控制平面消息接口，所有 Agent 在同一群组中响应标签指令
- [[Trebuh]]：X 用户原型，独立创业者，成功实践 4 Agent 团队模式
- [[OpenClaw Showcase]]：OpenClaw 社区展示，包含 @jdrhyne（15+ Agent/3 机器/1 Discord）、@nateliason（多模型流水线）、@danpeguine（2 实例 WhatsApp 协作）等案例
-
-## Connections
- [[Content Factory]] ← uses ← [[Multi-Agent Team]]（内容工厂使用多 Agent 团队协作）
- [[OpenClaw]] ← powers ← [[Multi-Agent Team]]（OpenClaw 提供多 Agent 编排能力）
- [[Self-Healing Home Server]] ← similar_arch ← [[Multi-Agent Team]]（相似架构：OpenClaw + 定时任务）
- [[Multi-Agent System Reliability]] ← related_to ← [[Multi-Agent Team]]（多 Agent 系统可靠性是相关概念）
-
-## Contradictions
- 与 [[Content Factory]] 的团队架构差异：
-  - 冲突点：Content Factory 是链式协作（Research → Writing → Thumbnail），Multi-Agent Team 是并行专业化分工
-  - 当前观点：并行专业化分工更适合一人公司的多领域需求
-  - 对方观点：链式协作更适合内容创作这类有序流程
+---
+title: "Multi-Agent Specialized Team (Solo Founder Setup)"
+type: source
+tags: [multi-agent, solo-founder, telegram, openclaw, team-automation]
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/multi-agent-team.md]]
+
+## Summary（用中文描述）
+- 核心主题：Solo Founder 如何通过多 Agent 专业化团队实现"一人公司"运作
+- 问题域：单人创业者的角色切换成本、知识孤岛、无法专注深度工作
+- 方法/机制：4 个专业化 Agent（Milo 战略lead、Josh 商业分析、Marketing 内容营销、Dev 开发）+ 共享记忆 + Telegram 单入口 + 定时任务
+- 结论/价值：Agent 个性化比想象中更重要；共享记忆 + 私有上下文组合是关键；按任务复杂度选模型；定时任务形成飞轮；从小团队开始（lead + 1 specialist）
+
+## Key Claims（用中文描述）
+- 单个 Agent 无法同时处理战略、代码、营销、商业分析而不导致上下文耗尽：上下文切换摧毁深度工作
+- 通用 prompt 产生通用输出：编码 Agent 不应同时负责营销文案
+- Agent 个性化（名字 + 沟通风格）使"和团队对话"比"使用工具"更自然
+- 共享记忆 + 私有上下文组合是核心：共同ground（目标/决策） + 各自积累领域专业
+- 按任务复杂度匹配模型能力：不要用贵的推理模型做关键词监控
+- 定时主动推送洞察而非被动响应是价值飞轮：真正的价值在 Agent 主动浮现洞察
+- 从 2 个 Agent 而非 4 个开始：lead + 一个 specialist，然后按瓶颈扩展
+
+## Key Quotes
+> "A real small team available 24/7." — Trebuh，描述他用 4 个 OpenClaw Agent 组成的团队
+
+> "Personality matters more than you'd think." — OpenClaw Showcase，用户反馈 Agent 个性化使交互更自然
+
+> "Right model for the right job." — OpenClaw Showcase，不要用昂贵推理模型做简单任务
+
+## Key Concepts
+- [[SharedMemory]]：团队共享的项目文档、目标、关键决策，所有 Agent 均可访问
+- [[PrivateContext]]：每个 Agent 维护自己的对话历史和领域特定笔记
+- [[SingleControlPlane]]：通过单一 Telegram 群组控制所有 Agent，按 @tag 分发
+- [[ScheduledTask]]：Agent 主动在后台执行定时任务（每日 standup、内容推送、监控）
+- [[ChainedAgents]]：（相关——多 Agent 流水线与本场景的链式执行模式类似）
+
+## Key Entities
+- [[OpenClaw]]：本方案的技术基础框架，支持多 Agent 管理和 Telegram 集成
+- [[Telegram]]：单一控制平面的消息通道
+- [[Milo]]：战略 Lead Agent，由 Trebuh 创建，个性自信、有大局观、有魅力
+- [[Josh]]：商业分析 Agent，个性务实、直击要点、数据驱动
+- [[Trebuh]]：Solo Founder，OpenClaw 多 Agent 团队的首创实践者
+- [[Claude]]：Agent 所使用的模型之一（Milo/Dev Agent）
+- [[Gemini]]：Agent 所使用的模型之一（Marketing Agent）
+
+## Connections
+- [[ContentFactory]] ← extends ← [[Multi-AgentTeam]]
+- [[n8n]] ← integrates ← [[Multi-AgentTeam]]（n8n 做工作流编排）
+- [[Telegram]] ← controls ← [[Multi-AgentTeam]]
+
+## Contradictions
+- 与 [[ContentFactory]]（Multi-Agent Content Factory）：
+  - 冲突点：是否需要流水线式链式处理
+  - 当前观点（本页面）：多 Agent 按角色分工，通过共享记忆协调，强调 Agent 独立性和主动性
+  - 对方观点：多 Agent 按内容处理阶段链式执行，强调自动化流水线
+  - 说明：两者实为互补——ContentFactory 是内容创作流水线，本页面是团队管理架构，可以结合使用
--- a/wiki/sources/multi-channel-assistant.md
+++ b/wiki/sources/multi-channel-assistant.md
@@ -1,52 +1,47 @@
---
-title: "Multi-Channel Personal Assistant"
-type: source
-tags: [Agent, Workflow, OpenClaw, Automation]
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/multi-channel-assistant]]
-
-## Summary（用中文描述）
- 核心主题：构建一个统一入口的 AI 个人助理，通过单一界面（Telegram）整合所有工作工具（Google Workspace、Slack、Todoist、Asana），消除应用切换疲劳。
- 问题域：个人生产力管理中跨平台任务管理、日程安排、消息发送和工作流程自动化的碎片化问题。
- 方法/机制：基于 Telegram 话题（Topics）实现上下文路由，Telegram 作为主交互界面，通过 OpenClaw 配置整合 Google OAuth、Slack、Todoist、Asana API，借助 gog CLI 操作 Google Workspace。
- 结论/价值：将所有工具收敛到一个 AI 入口，用自然语言驱动一切操作，实现"说一句话，AI 完成全套工作"。
-
-## Key Claims（用中文描述）
- Telegram 话题（Topics）机制能够有效实现多上下文隔离路由，不同话题对应不同工作域（视频创意、CRM、财报、知识库等）。
- OpenClaw 通过统一的配置体系（Google OAuth、Slack tokens、API keys）连接所有工具，成为事实上的个人 AI 中枢。
- 定时提醒（Trash day、Weekly letter）这类自动化行为，是 AI Agent 区别于被动问答工具的核心标志——主动推送而非被动响应。
- 跨工作流交互（如 Slack 链接存入知识库后用于视频研究）展示了多工具集成的复合价值。
-
-## Key Quotes
-> "Context-switching between apps to manage tasks, schedule events, send messages, and track work is exhausting. You want one interface that routes to all your tools." — 痛点陈述
-> "Telegram topics: config → system settings / updates → daily summaries / video-ideas → content pipeline / personal-crm → contact queries / earnings → financial tracking / knowledge-base → save and search" — OpenClaw 路由策略示例
-
-## Key Concepts
- [[Topic-Based Routing]]：通过 Telegram Topic 标签实现多上下文分发路由，不同 Topic 触发不同工具和记忆上下文
- [[Multi-Tool Integration]]：整合 Google Workspace、Slack、Todoist、Asana 等多个平台工具的统一架构
- [[Scheduled Reminder]]：基于定时任务的主动提醒机制，Agent 主动推送而非被动等待用户查询
-
-## Key Entities
- [[OpenClaw]]：多 Agent 编排框架，通过配置连接所有工具，本方案的"控制平面"
- [[gog]]：Google Workspace CLI 工具，支持 Gmail、Calendar、Drive 操作，本方案中用于 Google 生态集成
- [[Telegram]]：主交互界面，通过 Bot + Topics 实现多上下文路由
- [[Slack]]：团队协作通道（任务分配、知识库存取、视频创意触发）
- [[Todoist]]：个人快速任务捕获工具
- [[Asana]]：项目管理工具，对应 Video Pipeline 项目
-
-## Connections
- [[multi-channel-assistant]] ← uses ← [[OpenClaw]]（控制平面）
- [[multi-channel-assistant]] ← uses ← [[gog]]（Google Workspace 集成）
- [[multi-channel-assistant]] ← uses ← [[Telegram]]（主界面 + 话题路由）
- [[multi-channel-assistant]] ← extends ← [[personal-crm]]（CRM 是 topics 之一）
- [[multi-channel-assistant]] ← similar_to ← [[knowledge-base-rag]]（知识库是 topics 之一）
-
-## Contradictions
- 与 [[multi-agent-team]] 冲突：
-  - 冲突点：Multi-Agent Team 强调多个专业化 Agent 并行工作；Multi-Channel Assistant 强调单一 AI 入口路由到多个工具。
-  - 当前观点：Multi-Channel Assistant 更适合个人用户，以 Telegram 为单一界面收敛所有工具。
-  - 对方观点：Multi-Agent Team 适合需要专业化分工的场景（策略/商业/营销/开发 Agent 各司其职）。
-  - 融合思路：两者可以结合——Multi-Agent Team 作为底层实现，Multi-Channel Assistant 作为用户交互层。
+---
+title: "Multi-Channel Personal Assistant"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/multi-channel-assistant.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过单一 AI 助手统一管理多平台工具（Telegram / Slack / Google Workspace / Todoist / Asana），消除应用间切换损耗
+- 问题域：个人效率工具碎片化——任务、日历、邮件、团队协作分布在多个独立应用中
+- 方法/机制：Telegram Topic 分话题路由（config / updates / video-ideas / personal-crm / earnings / knowledge-base）+ OpenClaw 配置层统一连接所有工具 + Prompt 指令层做意图分发
+- 结论/价值：用单入口 + 上下文路由替代多 app 切换，实现"说一句，AI 调动所有工具"
+
+## Key Claims（用中文描述）
+- Telegram Topic 路由：单一 Telegram bot 通过话题（topic）隔离不同上下文，实现"同一入口，不同工作流"
+- 工具统一配置：OpenClaw 作为配置中心，一次配置 Google OAuth / Slack / Todoist / Asana，后续通过 Prompt 指令统一调用
+- 意图分发层：Prompt 定义规则——"添加任务 → Todoist"、"创建卡片 → Asana"、"发邮件 → gog gmail"、"上传文件 → gog drive"
+- 定时自动化：Cron 驱动的主动提醒（如周一 18:00 提醒倒垃圾、周五 15:00 提醒写周报）
+
+## Key Quotes
+> "Context-switching between apps to manage tasks, schedule events, send messages, and track work is exhausting. You want one interface that routes to all your tools." — 痛点陈述
+
+## Key Concepts
+- [[TopicRouting]]：通过 Telegram topic（或类似的消息频道分区）实现单一入口内的上下文隔离，避免多 bot 混乱
+- [[ToolOrchestration]]：通过统一配置层（OpenClaw）集中管理多工具认证和 API，将工具调用逻辑从业务逻辑中解耦
+- [[IntentDrivenRouting]]：Prompt 层定义"意图 → 工具"的映射规则，AI 根据用户输入自动路由到对应工具
+- [[Scheduled-Reminder]]：定时触发的主动提醒机制，在预设时间由 AI Agent 主动推送通知（如周一 18:00 提醒倒垃圾），区别于被动查询
+
+## Key Entities
+- [[OpenClaw]]：多工具统一配置和编排层（本文档的主要实现框架）
+- [[Telegram]]：作为主交互界面，支持 Topic 分话题路由
+- [[Slack]]：团队协作集成（任务分配、知识库保存、视频创意触发）
+- [[Todoist]]：快速任务捕获工具
+- [[Asana]]：项目管理工具
+- Google Workspace（Gmail / Calendar / Drive）：通过 [[gog]] CLI 统一集成，由 OpenClaw Prompt 指令层调用
+- [[gog]]：Google Workspace CLI 工具，用于日历/邮件/云端硬盘操作（gog.md 实体页面）
+
+## Connections
+- [[multi-agent-team]] ← shares_pattern ← [[multi-channel-assistant]]（后者是单入口多工具路由的实践案例，可作为前者的基础设施层参考）
+- [[knowledge-base-rag]] ← enabled_by ← [[multi-channel-assistant]]（knowledge-base topic 作为 RAG 知识库的入口）
+- [[phone-based-personal-assistant]] ← extends ← [[multi-channel-assistant]]（前者是手机语音扩展，后者是桌面聊天入口）
+
+## Contradictions
+- 与 [[personal-crm]]：两者都涉及联系人管理，但 [[personal-crm]] 侧重联系人发现和关系维护，[[multi-channel-assistant]] 侧重通过 personal-crm topic 路由联系人查询请求——前者是数据层，后者是交互层，无实质冲突
--- a/wiki/sources/n8n-full-tutorial-building-ai-agents-in-2025-for-beginners.md
+++ b/wiki/sources/n8n-full-tutorial-building-ai-agents-in-2025-for-beginners.md
@@ -1,53 +1,50 @@
---
-title: "N8N Full Tutorial Building AI Agents in 2025 for Beginners!"
-type: source
-tags: [ai, ai-agent, n8n, tutorial]
-date: 2025-03-06
-sources: []
-last_updated: 2026-04-23
---
-
-## Source File
- [[Agent/n8n full tutorial building AI agents in 2025 for Beginners!.md]]
-
-## Summary（用中文描述）
- 核心主题：使用 N8N 平台构建 AI Agent 的完整入门教程
- 问题域：AI Agent 开发平台、工作流自动化、AI 与数据库集成
- 方法/机制：N8N 五类节点系统（Trigger/Action/Utility/Code/Advanced AI）、Agent 记忆机制、外部工具集成（Airtable）、Workflow 与 Agent 的区别
- 结论/价值：N8N 提供低门槛可视化界面，使初学者能够通过动态工具选择和上下文记忆构建有状态的 AI Agent 系统
-
-## Key Claims（用中文描述）
- N8N 平台通过五类节点（触发节点、动作节点、工具节点、代码节点、高级 AI 节点）的组合，使构建 AI Agent 变得直观可控
- Agentic System（智能体系统）将 Workflow 的可预测性与 Agent 的动态工具选择能力结合，实现能根据用户输入自适应响应的 AI 应用
- 记忆（Memory）机制是 AI Agent 与传统自动化 Workflow 的关键区别，使 Agent 能够保留对话上下文
- 外部工具集成（如 Airtable）扩展了 AI Agent 的能力边界，使其能够读写真实业务数据
-
-## Key Quotes
-> "Agentic systems consist of agents and workflows, where agents dynamically select tools for user requests." — 教程核心定义
-
-> "By retaining context from previous interactions, agents can provide more coherent and relevant responses." — 记忆机制的价值
-
-## Key Concepts
- [[Agentic System]]：由 Agent 和 Workflow 组成的智能系统，Agent 能根据用户请求动态选择工具
- [[AI Agent Memory]]：AI Agent 的上下文保持机制，使对话具有连续性
- [[N8N Node Types]]：N8N 平台的五类节点（Trigger、Action、Utility、Code、Advanced AI）
- [[Workflow vs Agent]]：传统自动化 Workflow（预定义输出）vs AI Agent（动态决策）的本质区别
-
-## Key Entities
- [[n8n]]：开源工作流自动化平台，支持 AI Agent 构建，提供可视化节点编辑界面
- [[AI Foundations]]：AI 学习和协作社区，提供本教程及后续进阶资源
- [[Airtable]]：云端数据库平台，教程中作为 Agent 的外部工具集成示例
-
-## Connections
- [[n8n + Claude：通过自然语言自动化工作流]] ← extends ← [[本教程]]
- [[使用Claude自动生成N8N工作流的实操教程]] ← related_to ← [[本教程]]
- [[n8n-workflow-orchestration]] ← related_to ← [[本教程]]
- [[n8n调用hermes-agents的工作流架构]] ← related_to ← [[本教程]]
- [[n8n-调用openclaw-agents的工作流架构]] ← related_to ← [[本教程]]
-
-## Contradictions
- 与 [[n8n + Claude：通过自然语言自动化工作流]] 的潜在差异：
-  - 冲突点：Claude 生成 N8N 工作流的自动化程度
-  - 当前观点（本教程）：N8N 适合作为独立 AI Agent 平台，通过记忆机制和工具集成实现复杂自动化
-  - 对方观点：Claude 可通过 n8n-mcp 理解 543 个 N8N 节点并自动生成工作流，完成度约 80%-90%
-  - 说明：两者互补——教程提供手动构建基础，Claude 工具提供自动化加速
+---
+title: "N8N Full Tutorial Building AI Agents in 2025 for Beginners!"
+type: source
+tags: [ai, ai-agent, n8n, tutorial]
+date: 2025-03-06
+---
+
+## Source File
+- [[Agent/n8n full tutorial building AI agents in 2025 for Beginners!.md]]
+
+## Summary（用中文描述）
+- 核心主题：使用 N8N 平台构建 AI Agent 的入门教程
+- 问题域：AI Agent 开发与工作流自动化
+- 方法/机制：通过 N8N 的可视化节点编辑器和 LLM 驱动的 Agent 节点，构建可动态选择工具的智能体系统；教程涵盖节点分类、工具集成、记忆管理和数据库交互
+- 结论/价值：N8N 将传统工作流的确定性与 AI Agent 的灵活性结合，是零代码/低代码构建 AI 自动化应用的理想平台，适合初学者快速上手
+
+## Key Claims（用中文描述）
+- N8N 通过可视化界面降低了 AI Agent 构建门槛，无需深厚编程背景
+- Agentic System（智能体系统）将工作流（Workflow）与 Agent 结合，实现动态工具选择与适应性响应
+- 五类节点（触发节点、动作节点、工具节点、代码节点、AI Agent 节点）是构建有效 AI 自动化的基础
+- 记忆模块（Memory）使 Agent 能够保留上下文，显著提升对话连贯性和用户体验
+- 集成 Airtable 等外部工具后，Agent 可实现库存查询和实时数据更新等真实业务场景
+
+## Key Quotes
+> "Agentic systems consist of agents and workflows, where agents dynamically select tools for user requests." — 核心定义
+> "N8N is designed for ease of use, offering a visual interface that simplifies the workflow creation process." — 平台特点
+> "Implementing memory within AI agents is a game-changer for user interaction. By retaining context from previous interactions, agents can provide more coherent and relevant responses." — 记忆的价值
+> "Integrating external tools like Airtable into the N8N workflows vastly expands the capabilities of AI agents." — 工具集成的重要性
+
+## Key Concepts
+- [[Agentic System]]：由 Agent 和工作流组成的智能体系统，Agent 能根据用户输入动态选择工具并生成输出，区别于预定义、输出恒定的工作流
+- [[Workflow]]：预定义的自动化流程，按照固定逻辑执行，产生一致的输出
+- [[N8N Node Types]]：N8N 中节点的五大类别——触发节点（Trigger）、动作节点（Action）、工具节点（Utility）、代码节点（Code）、高级 AI Agent 节点（Advanced AI）
+- [[Memory in AI Agents]]：在 AI Agent 中嵌入的记忆模块，用于保留多轮对话上下文，使交互更连贯自然
+- [[Tool Integration]]：将外部工具（如 Airtable）集成到工作流中，扩展 Agent 的数据获取和操作能力
+
+## Key Entities
+- [[N8N]]：开源工作流自动化平台，提供可视化节点编辑器，支持构建 AI Agent 和传统工作流
+- [[Airtable]]：在线数据库工具，在教程中作为 Agent 的库存管理工具被集成
+- [[AI Foundations]]：教程提及的 AI 社区，提供学习资源、课程和协作机会
+
+## Connections
+- [[N8N]] ← uses ← [[N8N Node Types]]
+- [[Agentic System]] ← built_with ← [[N8N]]
+- [[Agentic System]] ← includes ← [[Memory in AI Agents]]
+- [[Agentic System]] ← integrates ← [[Tool Integration]]
+- [[Airtable]] ← used_by ← [[Agentic System]]
+
+## Contradictions
+- 与 [[how-agentic-ai-can-help-for-cloud-devops]] 一致：两者对 Agentic System 的核心定义一致（Agent + LLM 动态工具选择），本教程为入门视角，Cloud DevOps 篇为应用视角，无冲突
--- a/wiki/sources/phone-based-personal-assistant.md
+++ b/wiki/sources/phone-based-personal-assistant.md
@@ -1,45 +1,48 @@
---
-title: "Phone-Based Personal Assistant"
-type: source
-tags: []
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/phone-based-personal-assistant.md]]
-
-## Summary（用中文描述）
- 核心主题：基于电话的 AI 个人助理——通过拨打电话与 AI Agent 语音对话
- 问题域：用户需要从任何手机（无需智能机 App 或浏览器）访问 AI Agent，在驾驶、步行或双手忙碌时获取免提语音辅助
- 方法/机制：ClawdTalk + OpenClaw 实现来电/去电能力，通过 Telnyx 提供电话连接服务；支持日历查询、Jira 更新、网络搜索等技能
- 结论/价值：把任意手机变成 AI 助理网关，覆盖无屏幕/双手占用场景
-
-## Key Claims（用中文描述）
- ClawdTalk 使 OpenClaw 能够接收和拨打电话，将任何手机变成 AI 助理入口
- 通过 Telnyx API 提供可靠的电信连接
- 用户可通过电话查询日历、获取 Jira 任务更新、进行网络搜索
-
-## Key Quotes
-> "Call a phone number to speak with your AI agent via voice" — 核心使用场景
-
-## Key Concepts
- [[Voice Interface]]：通过电话语音与 AI Agent 交互的接口层
- [[Telephony Integration]]：电话连接与来电/去电能力集成
-
-## Key Entities
- [[ClawdTalk]]：Telnyx 出品的电话集成客户端，使 OpenClaw 支持语音通话
- [[OpenClaw]]：多 Agent 框架，通过 ClawdTalk 实现电话能力
- [[Telnyx]]：电信 API 提供商，提供可靠的电话连接服务
-
-## Connections
- [[multi-channel-assistant]] ← related_to ← [[phone-based-personal-assistant]]
- [[event-guest-confirmation]] ← related_to ← [[phone-based-personal-assistant]]
- [[ClawdTalk]] ← enables ← [[OpenClaw]]
- [[Telnyx]] ← powers ← [[ClawdTalk]]
-
-## Contradictions
- 与 [[event-guest-confirmation]] 冲突（已在 overview.md Conflict Area #10 记录）：
-  - 冲突点：AI 电话外呼的应用场景定位
-  - [[phone-based-personal-assistant]]：侧重通用个人助手场景，需要访问更多上下文（Calendar/Jira/Web Search）
-  - [[event-guest-confirmation]]（SuperCall）：强调独立沙盒设计，适用于确认类单一任务（安全、无注入风险）
-  - 当前观点：通用语音 Agent 适用于跨系统协调的复杂助手场景；Sandboxed Persona 适用于确认类单一任务
+---
+title: "Phone-Based Personal Assistant"
+type: source
+tags: []
+date: 2026-04-27
+---
+
+## Source File
+- [[Agent/usecases/phone-based-personal-assistant.md]]
+
+## Summary（用中文描述）
+- 核心主题：基于电话的 AI 个人助理——通过拨打电话与 AI Agent 语音对话
+- 问题域：用户需要从任何手机（无需智能机 App 或浏览器）访问 AI Agent，在驾驶、步行或双手忙碌时获取免提语音辅助
+- 方法/机制：ClawdTalk + OpenClaw 实现来电/去电能力，通过 Telnyx 提供电话连接服务；支持日历查询、Jira 更新、网络搜索等技能；SMS 支持即将上线
+- 结论/价值：把任意手机变成 AI 助理网关，覆盖无屏幕/双手占用场景
+
+## Key Claims（用中文描述）
+- ClawdTalk 使 OpenClaw 能够接收和拨打电话，将任何手机变成 AI 助理入口
+- 通过 Telnyx API 提供可靠的电信连接
+- 用户可通过电话查询日历（Jira 任务、网络搜索结果）
+- SMS 支持即将上线
+
+## Key Quotes
+> "Call a phone number to speak with your AI agent via voice" — 核心使用场景：通过电话号直接与 AI Agent 语音对话
+> "SMS support is coming soon" — SMS 功能路线图说明
+
+## Key Concepts
+- [[Voice Interface]]：通过电话语音与 AI Agent 交互的接口层
+- [[Telephony Integration]]：电话连接与来电/去电能力集成
+
+## Key Entities
+- [[ClawdTalk]]：Telnyx 出品的电话集成客户端，使 OpenClaw 支持语音通话（GitHub: team-telnyx/clawdtalk-client）
+- [[OpenClaw]]：多 Agent 框架，通过 ClawdTalk 实现电话能力
+- [[Telnyx]]：电信 API 提供商，提供可靠的电话连接服务
+- [[OpenClaw Skills]]：AI Agent 可调用的技能集合（日历/Jira/Web Search 等）
+
+## Connections
+- [[multi-channel-assistant]] ← related_to ← [[phone-based-personal-assistant]]
+- [[event-guest-confirmation]] ← related_to ← [[phone-based-personal-assistant]]
+- [[ClawdTalk]] ← enables ← [[OpenClaw]]
+- [[Telnyx]] ← powers ← [[ClawdTalk]]
+
+## Contradictions
+- 与 [[event-guest-confirmation]] 冲突（已在 overview.md Conflict Area #10 记录）：
+  - 冲突点：AI 电话外呼的应用场景定位
+  - [[phone-based-personal-assistant]]：侧重通用个人助手场景，需要访问更多上下文（Calendar/Jira/Web Search）
+  - [[event-guest-confirmation]]（SuperCall）：强调独立沙盒设计，适用于确认类单一任务（安全、无注入风险）
+  - 当前观点：通用语音 Agent 适用于跨系统协调的复杂助手场景；Sandboxed Persona 适用于确认类单一任务
--- a/wiki/sources/podcast-production-pipeline.md
+++ b/wiki/sources/podcast-production-pipeline.md
@@ -1,51 +1,47 @@
---
-title: "Podcast Production Pipeline"
-type: source
-tags: ["agent", "podcast", "automation", "content-production"]
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/podcast-production-pipeline.md]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 全自动播客制作流水线，从选题到发布资产的完整工作流
- 问题域：个人播客创作者和小型团队的生产效率问题——录制本身只占总工作量的30%，其余70%都是繁琐的准备工作
- 方法/机制：通过 Chain Agents 串联完成「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」的全链路自动化
- 结论/价值：AI 承担生产侧的 70% 工作，创作者专注核心的对话录制，大幅降低播客制作门槛
-
-## Key Claims（用中文描述）
- Solo Podcaster 在制作上花费的时间远超录制时间，创意对话部分仅占总工作量的约 30%
- 录制前的深度嘉宾研究是整个流水线中价值最高的环节，直接提升访谈质量
- 带时间戳的节目笔记（Show Notes）是重要的听众留存工具，大多数播客主因繁琐而跳过
- 社媒推广包（Social Media Kit）是节省重复性时间最多的环节——每集必做，结构固定，非常适合自动化
- 与 [[Multi-Agent Content Factory]] 配合使用时，可将播客内容复用为博客文章、Newsletter 或视频片段
-
-## Key Quotes
-> "Walking into an interview with deep guest research makes the conversation dramatically better — and that's something you can't fake in post-production." — Key insight on pre-recording research value
-
-> "The social media kit saves the most *recurring* time. You need promo for every single episode, and it's always the same structure — perfect for automation." — On recurring automation ROI
-
-## Key Concepts
- [[Pre-Recording Research]]：嘉宾背景调研 + 话题趋势研究 + 采访问题生成，是流水线中价值最高的环节
- [[Podcast Show Notes]]：录制后处理录音文本，生成带时间戳的节目笔记，每一话题转换点配一句话摘要并附链接
- [[Social Media Kit]]：为每集生成 X/Twitter（3条推文）、LinkedIn（1篇专业帖）、Instagram（1条配图文案+hashtag）的推广内容包
- [[SEO Episode Description]]：为 Spotify、Apple Podcasts、YouTube 优化的 200 词以内节目描述，自然嵌入 3-5 个关键词
- [[Episode Outline]]：结构化节目大纲，含寒暄开场钩子（1-2句抓注意力）、30秒开场语、5-7个递进式采访问题、2-3个备用问题、结尾行动号召
- [[RSS Feed Monitoring]]：通过 RSS 订阅监控竞品播客，新集发布时自动推送 Telegram 提醒
-
-## Key Entities
- [[Whisper (OpenAI)]]：本地转录工具，用于录音生成文本，为 Show Notes 生成提供原始素材
- [[Spotify for Podcasters]]：播客分发平台，Episode Description 的目标发布渠道之一
- [[Apple Podcasts]]：播客分发平台，Episode Description 的目标发布渠道之一
- [[YouTube]]：视频播客平台，Episode Description 的目标发布渠道之一，同时支持 RSS 订阅
-
-## Connections
- [[Content Factory]] ← extends ← [[Podcast Production Pipeline]]：内容工厂将播客内容复用为博客、Newsletter、视频片段等
- [[Multi-Agent Coordination]] ← uses ← [[Podcast Production Pipeline]]：多 Agent 协调模式实现流水线并行处理
-
-## Contradictions
- 与 [[Content Factory]]（内容工厂）：
-  - 冲突点：内容工厂强调内容的批量生产与多格式复用；播客流水线强调录制前后的端到端自动化
-  - 当前观点：两者高度互补，播客流水线生产的内容直接输入内容工厂进行多格式复用
-  - 对方观点：内容工厂可独立运作，不依赖播客作为输入源
+---
+title: "Podcast Production Pipeline"
+type: source
+tags: [agent-use-case, content-production, automation]
+date: 2026-04-30
+---
+
+## Source File
+- [[Agent/usecases/podcast-production-pipeline.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 全自动播客生产流水线——从主题到发布资产的完整工作流
+- 问题域：独立播客主理人和小型团队，制作环节（研究、脚本、笔记、推广）占用 70% 时间，录制本身仅占 30%
+- 方法/机制：通过 Chain of Agents 实现：录制前研究→大纲生成→录制后字幕处理→Show Notes 生成→多平台社交媒体推广包创建
+- 结论/价值：AI 接管播客制作 70% 的非创意环节，让主理人专注于对话本身；Social Media Kit 每次录制均可复用，是自动化价值最高的部分
+
+## Key Claims（用中文描述）
+- 独立播客主理人花费在制作上的时间远超录制——录制仅占总工作量的 30%，其余 70% 均可由 Agent 自动化
+- 录制前的深度嘉宾研究是整个流程中价值最高的环节——充分准备使对话质量显著提升，无法靠后期制作弥补
+- 带时间戳的 Show Notes 是提升听众留存率的关键工具，大多数播客主理人因繁琐而跳过，Agent 使其变得轻松
+- Social Media Kit 是自动化价值最高的重复性环节——每期节目都需要结构一致的推广内容
+
+## Key Quotes
+> "The creative part — the conversation — is maybe 30% of the total effort. This agent handles the other 70%." — 播客生产痛点的核心洞察
+> "The pre-recording research is where most value is. Walking into an interview with deep guest research makes the conversation dramatically better — and that's something you can't fake in post-production." — 录制前研究的核心价值
+
+## Key Concepts
+- [[PodcastProductionPipeline]]：AI Agent 驱动的端到端播客生产流水线，覆盖研究→大纲→录制后处理→推广的全流程
+- [[PodcastShowNotes]]：时间戳化节目笔记，包含每期节目的主题跳转摘要及相关资源链接，用于提升听众体验和留存率
+- [[SocialMediaKit]]：多平台推广内容包，针对 X/Twitter、LinkedIn、Instagram 等平台生成结构化的宣传素材
+- [[MultiAgentContentFactory]]：多 Agent 内容工厂——可与播客生产流水线配对，将播客内容再利用为博客文章、Newsletter 或视频片段
+
+## Key Entities
+- [[OpenAI Whisper]]：本地化的语音转文字工具，用于播客录音的自动字幕生成
+- [[Spotify]]：播客分发平台之一，episode description 需要针对其搜索算法优化
+- [[Apple Podcasts]]：主流播客平台，需要特定格式的 episode description
+- [[YouTube]]：播客内容再分发平台，同时用于 episode description 的 SEO 优化
+- [[RSSFeed]]：播客订阅分发协议，用于竞品监控和内容选题追踪
+
+## Connections
+- [[MultiAgentContentFactory]] ← extends ← [[PodcastProductionPipeline]]
+- [[PodcastProductionPipeline]] ← uses ← [[OpenAI Whisper]]
+- [[PodcastProductionPipeline]] ← delivers_to ← [[Spotify]], [[Apple Podcasts]], [[YouTube]]
+- [[RSSFeed]] ← monitors ← [[PodcastProductionPipeline]] (竞品监控环节)
+
+## Contradictions
+- 无已知冲突。[[MultiAgentContentFactory]] 与本流水线为互补关系而非竞争关系——前者将播客内容再利用，后者负责原始播客生产。
--- a/wiki/sources/project-state-management.md
+++ b/wiki/sources/project-state-management.md
@@ -1,45 +1,63 @@
---
-title: "Project State Management System: Event-Driven Alternative to Kanban"
-type: source
-tags: [project-state]
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/project-state-management.md]]
-
-## Summary（用中文描述）
- 核心主题：用事件驱动系统替代传统看板管理项目状态
- 问题域：传统看板（Kanban）静态、需手动更新、容易遗忘、上下文丢失、无法追踪变更原因
- 方法/机制：自然语言对话式输入 → 事件日志 → 状态自动更新 → 自然语言查询；支持 Git 提交自动关联项目，每日 Cron 汇总报告
- 结论/价值：消灭"更新卡片"的摩擦，保留决策上下文，让项目状态查询和每日站会自动化
-
-## Key Claims（用中文描述）
- 自然语言对话替代拖拽看板卡片的机制：用户说"完成了X"/"被Y阻塞" → 系统自动记录事件并更新项目状态
- 全历史保留机制：每次状态变更均记录事件类型、描述、上下文、时间戳，而非仅存储当前状态
- Git 提交自动关联机制：Cron Job 扫描过去 24 小时提交，按分支名或提交信息匹配项目
- 每日站会自动化机制：9 AM 自动汇总"昨日进展 + 今日计划 + 当前阻塞"
-
-## Key Quotes
-> "Traditional Kanban boards are static and require manual updates. You forget to move cards, lose context between sessions, and can't track the 'why' behind state changes." — 看板痛点描述
-> "Instead of dragging cards, you chat with your assistant: 'Finished the auth flow, starting on the dashboard.'" — 事件驱动交互模式
-
-## Key Concepts
- [[Event Sourcing]]：将项目状态变更存储为事件序列，而非仅记录当前状态，每次变更（progress/blocker/decision/pivot）均作为独立事件持久化，保留完整上下文
- [[Project State]]：项目的当前状态元数据（status/phase/last_update），由事件自动驱动更新，而非手动维护
-
-## Key Entities
- [[OpenClaw]]：项目状态管理系统的核心平台，提供多 Agent 编排和 Telegram/Discord 通知集成能力
- PostgreSQL / SQLite：项目状态数据库的持久化存储引擎
-
-## Connections
- [[Event Sourcing]] ← uses ← [[Project State Management]]
- [[OpenClaw]] ← powers ← [[Project State Management]]
- [[GitHub]] ← provides commit data to ← [[Project State Management]]
- [[Project State Management]] ← alternative_to ← [[Kanban]]
-
-## Contradictions
- 与 [[Kanban]]（看板）存在方法论冲突：
-  - 冲突点：手动卡片拖拽 vs 事件驱动自动更新；静态快照 vs 全历史保留
-  - 当前观点（Event Sourcing）：事件驱动记录保留完整决策上下文，避免手动维护的摩擦和遗忘
-  - 对方观点（Kanban）：可视化面板提供直觉化状态概览，适合团队协作场景
+---
+title: "Project State Management System: Event-Driven Alternative to Kanban"
+type: source
+tags: [project-state, automation, ai, workflow]
+date: 2026-04-27
+---
+
+## Source File
+- [[raw/Agent/usecases/project-state-management.md]]
+
+## Summary（用中文描述）
+- 核心主题：用事件驱动系统替代传统 Kanban 看板，实现项目状态的自动化追踪与上下文保留
+- 问题域：Kanban 看板易失效（忘记移动卡片）、上下文丢失（无法追溯决策原因）、无代码变更与项目进度的自动关联
+- 方法/机制：
+  - PostgreSQL/SQLite 存储项目状态（projects 表 + events 表 + blockers 表）
+  - AI Agent 解析自然语言命令，自动生成 progress/blocker/decision/pivot 事件
+  - 每日 Cron 任务扫描 Git 提交（gh CLI），将 commit 链接到项目事件
+  - Discord/Telegram 频道接收更新通知和响应查询
+  - 每日站会摘要自动生成
+- 结论/价值：用自然对话替代手动看板维护，保留完整决策历史，实现"项目为什么这样"的即时查询能力
+
+## Key Claims（用中文描述）
+- 自然语言对话（"完成了X，被Y阻塞"）→ 自动触发项目状态转换，无需手动拖拽看板
+- 项目状态由事件序列自动推导，而非手动维护的快照
+- Git 提交自动扫描并关联到项目事件，实现代码变更与进度的可追溯链接
+- 每日站会摘要由 AI Agent 根据过去 24 小时事件和提交自动生成
+- Sub-agent 并行分析各项目状态，在 Sprint 规划时提供优先级建议
+
+## Key Quotes
+> "Kanban boards become stale. You waste time updating cards instead of doing work. Context gets lost—three months later, you can't remember why you made a key decision." — 痛点描述
+
+> "Instead of dragging cards, you chat with your assistant: 'Finished the auth flow, starting on the dashboard.' The system logs the event, updates project state, and preserves context." — 核心交互模式
+
+> "Git commits are automatically scanned and linked to projects. Your daily standup summary writes itself." — 自动化价值总结
+
+## Key Concepts
+- [[EventSourcing]]：本系统的底层架构模式 —— 所有状态变更作为不可变事件序列持久化，通过重放事件重建任意时间点状态
+- [[Kanban]]：本系统要替代的传统方案 —— 静态看板需手动更新，无法保留决策上下文
+- [[ProjectState]]：本系统的核心抽象 —— 项目任意时间点的完整快照，由事件序列自动驱动更新
+- 事件类型（progress / blocker / decision / pivot）：与 [[EventSourcing]] 中的事件类型定义完全一致
+
+## Key Entities
+- Discord：项目状态频道（#project-state）—— 接收事件更新通知、响应状态查询、发布每日站会摘要
+- Telegram：备选消息平台 —— 同样用于更新推送和自然语言查询接口
+- GitHub CLI（gh）：每日 Cron 扫描 Git 提交 —— 根据分支名或提交信息将 commit 关联到项目
+- PostgreSQL / SQLite：项目状态数据库 —— 存储 projects、events、blockers 三张核心表
+- Cron：定时任务调度器 —— 每日 9 AM 触发站会摘要生成
+- Sub-agents：并行项目分析器 —— Sprint 规划时并行分析各项目状态并提供优先级建议
+
+## Connections
+- [[ProjectState]] ← derived_from ← **EventSourcing**（[[ProjectState]] 由事件溯源模式驱动）
+- **Project State Management** ← uses ← [[EventSourcing]]（事件溯源是本系统的技术基础）
+- [[ProjectState]] ← uses ← **Discord**（Discord 承载事件通知和查询接口）
+- [[ProjectState]] ← uses ← **gh CLI**（GitHub CLI 实现提交与项目的自动关联）
+- **Project State Management** ← extends ← [[Vibe-Kanban]]（事件驱动管理是 Vibe-Kanban 的进阶形态）
+- [[Kanban]] ← alternative_to ← **Project State Management**（冲突：Kanban 静态可视化 vs 事件驱动自动追踪）
+
+## Contradictions
+- 与 [[Kanban]] 冲突：
+  - 冲突点：状态更新机制 —— Kanban 依赖手动拖拽卡片，事件驱动系统依赖自然语言对话自动记录
+  - 当前观点：手动看板易失效、丢失上下文；事件驱动自动追踪且保留完整历史
+  - 对方观点：Kanban 提供实时可视化，多人协作场景下状态一目了然，无需依赖 AI 解析准确性
+- 与 [[Vibe-Kanban]] 关系：Vibe-Kanban 是本地化的事件驱动看板实验，本系统是其在 Discord/Telegram 多渠道 + Git 集成 + 每日摘要方向的完整工程实现
--- a/wiki/sources/self-healing-home-server.md
+++ b/wiki/sources/self-healing-home-server.md
@@ -1,60 +1,118 @@
---
-title: "Self-Healing Home Server & Infrastructure Management"
-type: source
-tags: [openclaw, self-healing, home-server, infrastructure, agentic-ai, cron, ssh, iac, security]
-date: 2026-04-22
---
-
-## Source File
- [[Agent/usecases/self-healing-home-server]]
-
-## Summary（用中文描述）
- 核心主题：AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理
- 问题域：家庭服务器 24/7 运维负担（凌晨故障、证书过期、磁盘爆满、Pod崩溃）
- 方法/机制：OpenClaw + SSH + Cron Job 系统 + 自动化健康监控 + 故障自愈 + 基础设施即代码（Terraform/Ansible/Kubernetes）
- 结论/价值：Cron Job 是真正的产品力——定时自动化（健康检查、邮件分拣、晨报）比偶发命令提供更多日常价值；知识提取随时间复利增长
-
-## Key Claims（用中文描述）
- **AI 会硬编码 secrets**：AI Agent 会在代码中直接写入 API Key，这是 #1 安全风险。必须强制推行 pre-push hooks 和 secrets scanning（TruffleHog）
- **本地优先 Git 是必须的**：绝不能让 Agent 直接推送到公共仓库。使用私有 Gitea 实例作为中转，配合 CI 扫描_pipeline
- **Cron Job 是真正的产品**：定时自动化（健康检查、邮件分拣、晨报）比偶发命令提供更多日常价值
- **知识提取具有复利效应**：将笔记、对话导出和邮件处理成结构化知识库，时间越久价值越大——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实
-
-## Key Quotes
-> "I can't believe I have a self-healing server now" — 代理可以在你不知情的情况下通过 SSH、Terraform、Ansible 和 kubectl 修复基础设施问题
-> "AI assistants will happily hardcode secrets. They sometimes don't have the same instincts humans do." — Nathan 的惨痛教训（第1天即发生 API Key 泄露）
-> "The scheduled automation (health checks, email triage, briefings) provides more daily value than ad-hoc commands." — Cron Job 才是真正的产品
-
-## Key Concepts
- [[Self-Healing-Systems]]：通过健康检查检测问题并自动执行修复（重启 Pod、扩缩容、修复配置）
- [[Agentic AI]]：具有自主决策和任务执行能力的 AI 系统——驱动整个自愈管道的核心
- [[Infrastructure-as-Code]]（IaC）：Agent 编写并应用 Terraform、Ansible、Kubernetes manifests 管理基础设施
- [[Morning Briefing]]：每日 8 AM 自动生成天气/日历/系统状态/任务看板晨报的自动化流程
- [[Email Triage]]：AI 自动扫描收件箱，标记待办项，归档噪音邮件
- [[Local-first Git]]：通过私有 Gitea + CI 扫描_pipeline 防止 Agent 直接推送到公共仓库
- [[Defense-in-Depth]]（纵深防御）：AI 安全多层策略——TruffleHog pre-push hooks + 1Password 专用保管库 + 网络分段 + 每日安全审计
-
-## Key Entities
- [[OpenClaw]]：multi-agent framework，驱动 Reef 基础设施代理的核心平台
- [[K3s]]：轻量级 Kubernetes 发行版，Reef 管理的家庭 K8s 集群
- [[Gitea]]：自托管 Git 服务，用于私有代码中转（推送到公共 GitHub 前的 CI 扫描）
- [[TruffleHog]]：Git secrets scanning 工具，pre-push hooks 必需组件
- [[1Password]]：密码保管库，Agent 专用 AI vault（只读凭证访问）
- [[ArgoCD]]：GitOps 持续交付工具，Reef 监控部署状态的组件
- [[Gatus]]：自托管健康检查工具，与 ArgoCD/服务端点共同构成本地监控层
- [[Loki]]：日志聚合系统，配合监控栈进行日志分析
- [[n8n]]：工作流自动化平台，与 OpenClaw 共同编排复杂工作流
-
-## Connections
- [[Self-Healing-Systems]] ← extends ← [[Agentic AI]]
- [[Morning Briefing]] ← depends_on ← [[OpenClaw]]
- [[Local-first Git]] ← required_by ← [[OpenClaw]]
- [[TruffleHog]] ← part_of ← [[Defense-in-Depth]]
- [[K3s]] ← managed_by ← [[OpenClaw]]
- [[Infrastructure-as-Code]] ← implements ← [[Self-Healing-Systems]]
-
-## Contradictions
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 的监控方案对比：
-  - 冲突点：自愈能力 —— Prometheus/Grafana 方案专注于"监控+告警"，需要人工介入；本文档方案通过 OpenClaw Agent 实现"检测+诊断+修复"全自动闭环
-  - 当前观点：AI Agent 驱动的自愈系统可以做到"在你知道问题前就修复它"
-  - 对方观点：Prometheus + Alertmanager + 人工 runbook 是更可控的运维模式
+---
+title: "Self-Healing Home Server & Infrastructure Management"
+type: source
+tags: [openclaw, self-healing, home-server, infrastructure, agentic-ai, cron, ssh, iac, security]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/usecases/self-healing-home-server]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理
+- 问题域：家庭服务器 24/7 运维负担（凌晨故障、证书过期、磁盘爆满、Pod崩溃）
+- 方法/机制：OpenClaw + SSH + Cron Job 系统 + 自动化健康监控 + 故障自愈 + 基础设施即代码（Terraform/Ansible/Kubernetes）
+- 结论/价值：Cron Job 是真正的产品力——定时自动化（健康检查、邮件分拣、晨报）比偶发命令提供更多日常价值；知识提取随时间复利增长
+
+## Skills
+- `ssh` — 访问家庭网络机器（192.168.1.0/24）
+- `kubectl` — K3s 集群管理
+- `terraform` / `ansible` — 基础设施即代码
+- `1password` CLI — secrets 管理（Agent 专用只读 vault）
+- `gog` CLI — Gmail 邮件访问
+- Calendar API — 日历（本人 + 伴侣）
+- Obsidian vault — 知识库（5000+ 笔记）
+- `openclaw doctor` — 自我诊断
+
+## How to Set It Up
+
+### Core Agent Configuration
+在 AGENTS.md 中定义 Agent 名称和访问范围，例如名为 **Reef** 的基础设施 Agent：
+- SSH 到家庭网络所有机器
+- kubectl 操作 K3s 集群
+- 1Password vault（只读凭证，专用 AI vault）
+- Gmail via gog CLI
+- 日历（本人 + 伴侣）
+- Obsidian vault at ~/Documents/Obsidian/
+规则：永远不用硬编码 secrets；永远通过 PR 而非直接推送 main；每次自检运行 `openclaw doctor`；所有基础设施变更记录到 ~/logs/infra-changes.md
+
+### Automated Cron Job System
+配置 HEARTBEAT.md 调度系统：
+- 每 15 分钟：看板任务续做
+- 每小时：健康检查（Gatus/ArgoCD）、邮件分拣、告警检查
+- 每 6 小时：知识库录入、自检（openclaw doctor/磁盘/内存/日志）
+- 每 12 小时：代码质量审计、日志分析（Loki）
+- 每日 4:00 AM：夜间头脑风暴；8:00 AM：晨报（天气/日历/系统/看板）；1:00 AM：速率评估
+- 每周：知识库 QA、安全审计
+
+### Security Setup（关键）
+- Pre-push hooks：所有仓库安装 TruffleHog，阻止含 API Key/Token/Password 的提交
+- 本地优先 Git：用私有 Gitea 实例作为中转，CI 扫描后才推公共 GitHub，主分支合并需人工审核
+- 纵深防御：AI Agent 专用 1Password vault（受限范围）、网络分段、每日自动化安全审计（特权容器/硬编码 secrets/权限过宽/已知漏洞）
+- Agent 约束：PR 保护主分支、只读访问优先、所有变更可审计
+
+### Morning Briefing Template
+每日 8:00 AM 自动生成并投递：
+- 天气：当前位置当前状况和预报
+- 日历：本人和伴侣今日事件，冲突标记
+- 系统健康：所有机器 CPU/RAM/存储，服务 UP/DOWN，最近部署（ArgoCD），过去 24h 告警
+- 任务看板：昨日完成/进行中/阻塞项
+- 要点：昨夜头脑风暴亮点、待操作邮件、本周截止
+
+## Key Claims（用中文描述）
+- **AI 会硬编码 secrets**：AI Agent 会在代码中直接写入 API Key，这是 #1 安全风险。必须强制推行 pre-push hooks 和 secrets scanning（TruffleHog）
+- **本地优先 Git 是必须的**：绝不能让 Agent 直接推送到公共仓库。使用私有 Gitea 实例作为中转，配合 CI 扫描 pipeline
+- **Cron Job 是真正的产品**：定时自动化（健康检查、邮件分拣、晨报）比偶发命令提供更多日常价值
+- **知识提取具有复利效应**：将笔记、对话导出和邮件处理成结构化知识库，时间越久价值越大——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实
+
+## Key Quotes
+> "I can't believe I have a self-healing server now" — 代理可以在你不知情的情况下通过 SSH、Terraform、Ansible 和 kubectl 修复基础设施问题
+> "AI assistants will happily hardcode secrets. They sometimes don't have the same instincts humans do." — Nathan 的惨痛教训（第1天即发生 API Key 泄露）
+> "The scheduled automation (health checks, email triage, briefings) provides more daily value than ad-hoc commands." — Cron Job 才是真正的产品
+
+## Key Concepts
+- [[Self-Healing-Systems]]：通过健康检查检测问题并自动执行修复（重启 Pod、扩缩容、修复配置）
+- [[Agentic AI]]：具有自主决策和任务执行能力的 AI 系统——驱动整个自愈管道的核心
+- [[Infrastructure-as-Code]]（IaC）：Agent 编写并应用 Terraform、Ansible、Kubernetes manifests 管理基础设施
+- [[Morning Briefing]]：每日 8 AM 自动生成天气/日历/系统状态/任务看板晨报的自动化流程
+- [[Email Triage]]：AI 自动扫描收件箱，标记待办项，归档噪音邮件
+- [[Local-first Git]]：通过私有 Gitea + CI 扫描 pipeline 防止 Agent 直接推送到公共仓库
+- [[Defense-in-Depth]]（纵深防御）：AI 安全多层策略——TruffleHog pre-push hooks + 1Password 专用保管库 + 网络分段 + 每日安全审计
+
+## Key Entities
+- [[OpenClaw]]：multi-agent framework，驱动 Reef 基础设施代理的核心平台
+- [[K3s]]：轻量级 Kubernetes 发行版，Reef 管理的家庭 K8s 集群
+- [[Gitea]]：自托管 Git 服务，用于私有代码中转（推送到公共 GitHub 前的 CI 扫描）
+- [[TruffleHog]]：Git secrets scanning 工具，pre-push hooks 必需组件
+- [[1Password]]：密码保管库，Agent 专用 AI vault（只读凭证访问）
+- [[ArgoCD]]：GitOps 持续交付工具，Reef 监控部署状态的组件
+- [[Gatus]]：自托管健康检查工具，与 ArgoCD/服务端点共同构成本地监控层
+- [[Loki]]：日志聚合系统，配合监控栈进行日志分析
+- [[n8n]]：工作流自动化平台，与 OpenClaw 共同编排复杂工作流
+
+## Connections
+- [[Self-Healing-Systems]] ← extends ← [[Agentic AI]]
+- [[Morning Briefing]] ← depends_on ← [[OpenClaw]]
+- [[Local-first Git]] ← required_by ← [[OpenClaw]]
+- [[TruffleHog]] ← part_of ← [[Defense-in-Depth]]
+- [[K3s]] ← managed_by ← [[OpenClaw]]
+- [[Infrastructure-as-Code]] ← implements ← [[Self-Healing-Systems]]
+- [[self-healing-home-server]] ← extends ← [[dynamic-dashboard]]（系统健康监控场景）
+- [[self-healing-home-server]] ← extends ← [[custom-morning-brief]]（Reef 的 Morning Briefing 是 custom-morning-brief 的家庭服务器垂直场景实例）
+
+## Contradictions
+- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 的监控方案对比：
+  - 冲突点：自愈能力 —— Prometheus/Grafana 方案专注于"监控+告警"，需要人工介入；本文档方案通过 OpenClaw Agent 实现"检测+诊断+修复"全自动闭环
+  - 当前观点：AI Agent 驱动的自愈系统可以做到"在你知道问题前就修复它"
+  - 对方观点：Prometheus + Alertmanager + 人工 runbook 是更可控的运维模式
+
+## Inspired By
+本文档基于 Nathan 的详细文章 [\"Everything I've Done with OpenClaw (So Far)\"](https://madebynathan.com/2026/02/03/everything-ive-done-with-openclaw-so-far/)，描述了他的 OpenClaw Agent **Reef** 运行在家庭服务器上，通过 SSH 访问所有机器、管理 K3s 集群、集成 1Password 和 Obsidian vault（5000+ 笔记）。Reef 运行 15 个活跃 cron job、24 个自定义脚本，自主构建并部署了包括任务管理 UI 在内的多个应用。Nathan 第 1 天 API Key 泄露的惨痛教训："AI assistants will happily hardcode secrets." 他的纵深防御安全方案（TruffleHog pre-push hooks、私有 Gitea、CI 扫描、每日审计）是任何尝试此模式者的必读内容。亦参考 [OpenClaw Showcase](https://openclaw.ai/showcase) 上 `@georgedagg_` 的类似模式：部署监控、日志审查、配置修复和 PR 提交——遛狗时完成。
+
+## Related Links
+- [Nathan's Full Writeup](https://madebynathan.com/2026/02/03/everything-ive-done-with-openclaw-so-far/)
+- [OpenClaw Documentation](https://github.com/openclaw/openclaw)
+- [TruffleHog (Secret Scanning)](https://github.com/trufflesecurity/trufflehog)
+- [K3s (Lightweight Kubernetes)](https://k3s.io/)
+- [Gitea (Self-hosted Git)](https://gitea.io/)
+- [n8n (Workflow Automation)](https://n8n.io/)