Auto-sync: 2026-04-22 19:20
This commit is contained in:
53
wiki/concepts/Agent-Build-Gate.md
Normal file
53
wiki/concepts/Agent-Build-Gate.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Agent-Build-Gate"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent 执行构建任务前的条件检查机制——只有通过门控条件的 Agent 才允许进入实际代码编写阶段。通过在 Agent 的 instructions 中嵌入 pre-gate 规则实现自动化门控,是 [[Pre-Build Validation]] 的技术实现机制。
|
||||
|
||||
## Implementation Pattern
|
||||
在 [[OpenClaw]] Agent 的 instructions 中嵌入规则:
|
||||
|
||||
```text
|
||||
Before starting any new project, feature, or tool, always run idea_check first.
|
||||
|
||||
Rules:
|
||||
- If reality_signal > 70: STOP. Report top 3 competitors.
|
||||
Ask me if I want to proceed, pivot, or abandon.
|
||||
- If reality_signal 30-70: Show me results and pivot_hints.
|
||||
Suggest a niche angle that existing projects don't cover.
|
||||
- If reality_signal < 30: Proceed to build.
|
||||
Mention that the space is open.
|
||||
- Always show the reality_signal score and top competitors before writing any code.
|
||||
```
|
||||
|
||||
## How It Works
|
||||
1. 用户向 Agent 发送构建指令(如"build me a CLI tool for AI code review")
|
||||
2. Agent 自动调用 `idea_check()` 工具(而非立即开始写代码)
|
||||
3. 获取 `reality_signal` 和竞品信息
|
||||
4. 根据阈值执行对应规则(STOP / 展示建议 / 直接构建)
|
||||
5. 只有在 `reality_signal < 30` 或用户明确授权的情况下,Agent 才进入代码编写阶段
|
||||
|
||||
## Relationship to Related Concepts
|
||||
- [[Pre-Build Validation]] ← Agent-Build-Gate 是其技术实现
|
||||
- [[idea-reality-mcp]] ← 提供 `idea_check()` 工具
|
||||
- [[Reality-Signal]] ← Gate 的判断依据
|
||||
- [[Pivot-Strategy]] ← Gate 触发 STOP 时的后续建议
|
||||
- [[OpenClaw]] ← 当前唯一支持此模式的 Agent 框架
|
||||
|
||||
## Advantages over Manual Gate
|
||||
- **自动化**:无需人工触发,Agent 自动执行检查
|
||||
- **强制化**:Agent 指令层面嵌入,无法绕过(除非修改 instructions)
|
||||
- **上下文保持**:检查结果和 Agent 对话上下文共存,无需额外工具切换
|
||||
- **持续生效**:每次新的构建指令都会自动触发,无需重复提醒
|
||||
|
||||
## Related
|
||||
- [[Pre-Build Validation]]
|
||||
- [[idea-reality-mcp]]
|
||||
- [[Reality-Signal]]
|
||||
- [[Pivot-Strategy]]
|
||||
- [[OpenClaw]]
|
||||
- [[Competition-Analysis]]
|
||||
38
wiki/concepts/Agent-Driven-Market-Research.md
Normal file
38
wiki/concepts/Agent-Driven-Market-Research.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Agent-Driven Market Research"
|
||||
type: concept
|
||||
tags: [market-research, agentic-ai, automation]
|
||||
sources: [market-research-product-factory]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Agent-Driven Market Research(Agent 驱动的市场调研)是指利用 AI Agent 自动采集、整理和分析市场信息的方法,替代传统人工搜索、浏览和归纳的市场调研模式。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
- **自动化数据采集**:AI Agent 主动从 Reddit、X、论坛等平台抓取用户讨论
|
||||
- **结构化信息提取**:从非结构化文本中提取痛点、功能请求、竞品评价等关键信息
|
||||
- **趋势分析**:按时间窗口(近7天/30天/90天)聚合分析,识别新兴趋势
|
||||
- **多源交叉验证**:综合多个来源确保洞察的可靠性和代表性
|
||||
|
||||
## Contrast with Traditional Methods
|
||||
|
||||
| 维度 | 传统市场调研 | Agent-Driven Market Research |
|
||||
|------|-------------|----------------------------|
|
||||
| 数据来源 | 问卷/访谈/一手报告 | Reddit/X/论坛/评论 |
|
||||
| 数据真实性 | 经过受访者过滤和美化的二手信息 | 用户原生表达,未加工的真实情绪 |
|
||||
| 时效性 | 调研周期长,数据可能滞后 | 近实时采集,可聚焦特定时间窗口 |
|
||||
| 成本 | 专业调研公司费用高 | AI Agent 自动化,成本极低 |
|
||||
| 规模 | 样本量受限 | 可覆盖数十万条讨论帖子 |
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Agent-Driven Market Research]] → 输出 → [[Pain Point Mining]] → 支撑 → [[Startup MVP Pipeline]]
|
||||
- [[Agentic AI]] → 技术基础 → [[Agent-Driven Market Research]]
|
||||
- [[Last 30 Days Method]] → 工具方法 → [[Agent-Driven Market Research]]
|
||||
|
||||
## Sources
|
||||
|
||||
- [[market-research-product-factory]]
|
||||
44
wiki/concepts/Agent-Personality.md
Normal file
44
wiki/concepts/Agent-Personality.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Agent Personality"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Design, UX]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Agent Personality** 是给 AI Agent 赋予独特的名字、性格设定和沟通风格的设计实践,使其与用户协作时更加自然,而非像一个通用 AI 工具。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "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 个性比想象中更重要:
|
||||
- **降低协作摩擦**:用户自然地"与团队对话",而非使用工具
|
||||
- **明确的职责边界**:名字和人格暗示了 Agent 的专长
|
||||
- **增强信任感**:有个性的 Agent 更容易建立情感连接
|
||||
|
||||
## 设计要素
|
||||
|
||||
- **Name(名字)**:简短、独特,如 Milo、Josh、Dev
|
||||
- **性格描述**:用叙事性语言定义 Agent 的行事风格
|
||||
- Milo: "Confident, big-picture, charismatic"(策略领导型)
|
||||
- Josh: "Pragmatic, straight to the point, numbers-driven"(商业分析型)
|
||||
- Dev: "Precise, thorough, security-conscious"(开发严谨型)
|
||||
- **沟通风格**:决定 Agent 如何呈现信息和建议
|
||||
|
||||
## 与 Agent Specialization 的关系
|
||||
|
||||
Agent Personality 配合 Agent Specialization 共同作用:
|
||||
- **Personality** 解决"如何沟通"的问题
|
||||
- **Specialization** 解决"做什么任务"的问题
|
||||
- 两者结合让 Agent 更像一个真实的团队成员
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Agent Specialization]] — Agent 的专业分工
|
||||
- [[OpenClaw]] — SOUL.md 是 Agent Personality 的配置文件
|
||||
- [[Agent-Memory]] — 个性配合长期记忆增强 Agent 连续性
|
||||
- [[Chained Agents]] — 链式 Agent 中的角色设计
|
||||
|
||||
55
wiki/concepts/Agent-Specialization.md
Normal file
55
wiki/concepts/Agent-Specialization.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Agent Specialization"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Architecture, Team]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Agent Specialization** 是多 Agent 系统中,每个 Agent 拥有独立角色、专长领域和针对性优化的模型,通过协作完成复杂任务的架构设计原则。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "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 同时处理多领域任务时上下文快速填满
|
||||
- **泛化输出的局限**:通用提示产生通用输出,专业任务需要专业 Agent
|
||||
- **效率不均衡**:不同任务需要的模型能力不同,混用造成资源浪费
|
||||
|
||||
## 专业化 Agent 示例
|
||||
|
||||
| Agent | 角色 | 模型选择 | 核心职责 |
|
||||
|-------|------|----------|----------|
|
||||
| Milo | 策略领导 | Claude Opus | 战略规划、OKR 追踪、Agent 协调 |
|
||||
| Josh | 商业分析 | Claude Sonnet | 定价策略、KPI 追踪、竞品分析 |
|
||||
| Marketing | 营销研究 | Gemini | 内容创意、SEO 研究、社媒监控 |
|
||||
| Dev | 开发工程 | Claude Opus/Codex | 代码审查、架构决策、文档撰写 |
|
||||
|
||||
## 模型匹配原则
|
||||
|
||||
> "Right model for the right job: Don't use an expensive reasoning model for keyword monitoring"
|
||||
|
||||
- **复杂推理任务**:Claude Opus(深度思考、架构设计)
|
||||
- **分析性任务**:Claude Sonnet(快速分析、数据处理)
|
||||
- **研究性任务**:Gemini(长上下文、网页研究)
|
||||
- **执行性任务**:Codex(代码生成、工具调用)
|
||||
|
||||
## 起步策略
|
||||
|
||||
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
|
||||
|
||||
从最小可行团队开始:
|
||||
1. **1 个领导 Agent**:总协调、决策、汇总
|
||||
2. **1 个专家 Agent**:根据当前最大瓶颈选择
|
||||
3. **逐步扩展**:瓶颈出现时添加新 Agent
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Agent Personality]] — Agent 个性化与专业化相辅相成
|
||||
- [[Multi-Agent Coordination]] — 多 Agent 协调机制
|
||||
- [[Parallel Agent Execution]] — 并行执行提升效率
|
||||
- [[Chained Agents]] — 链式 Agent(另一种协作模式)
|
||||
|
||||
29
wiki/concepts/Ai-Powered-Digest.md
Normal file
29
wiki/concepts/Ai-Powered-Digest.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "AI-Powered Digest"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI-Powered Digest(AI 驱动的自动化摘要)是一种由 AI Agent 主导的信息获取-整理-格式化-投递模式。核心特征:定时/事件触发 → 自动抓取原始数据 → AI 理解与结构化 → 投递到即时通讯工具 → 用户无需主动搜索。
|
||||
|
||||
## Pattern Components
|
||||
1. **Trigger**:定时(Cron Job)或事件驱动
|
||||
2. **Collection**:通过 API/Web 搜索/爬虫获取原始数据
|
||||
3. **Processing**:AI 理解内容,提取关键信息
|
||||
4. **Formatting**:结构化摘要(分类、排序、highlight)
|
||||
5. **Delivery**:推送至 Telegram/Slack/Email 等即时渠道
|
||||
|
||||
## Variants in the Wiki
|
||||
| 场景 | 来源 | Trigger | 内容源 |
|
||||
|------|------|---------|--------|
|
||||
| 财报追踪 | [[earnings-tracker]] | Cron Job(周日扫描+财报发布后触发) | 财报日历+搜索结果 |
|
||||
| YouTube 摘要 | [[daily-youtube-digest]] | Cron Job(频道更新检测) | 视频转录+摘要 |
|
||||
| 晨报 | [[self-healing-home-server]] | Cron Job(每日 8AM) | 天气/日历/系统状态 |
|
||||
|
||||
## Related Concepts
|
||||
- [[Cron Job]] — 定时触发的技术基础
|
||||
- [[Telegram Topic]] — 投递渠道
|
||||
- [[Daily-Digest]] — Digest 模式在 YouTube 场景的具体化
|
||||
- [[Earnings Calendar]] — Digest 模式的金融场景应用
|
||||
37
wiki/concepts/Automated-Health-Logging.md
Normal file
37
wiki/concepts/Automated-Health-Logging.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Automated Health Logging"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Automated Health Logging
|
||||
|
||||
利用 AI 自动解析自然语言输入并写入结构化健康数据日志的实践方法。
|
||||
|
||||
## Definition
|
||||
通过自然语言接口(消息、语音、文本)收集健康数据,由 AI 自动解析提取关键实体(食物、症状、药物等)并写入结构化日志文件,减少人工录入负担。
|
||||
|
||||
## Key Components
|
||||
1. **自然语言输入**:用户以日常语言描述,无需记忆特定格式
|
||||
2. **AI 解析引擎**:提取食物名称、数量、时间、症状描述等关键信息
|
||||
3. **结构化存储**:写入 Markdown/JSON 等可读且易处理的日志文件
|
||||
4. **定时提醒**:Cron Job 驱动的一日多次提醒,确保数据完整性
|
||||
|
||||
## Comparison with Manual Logging
|
||||
|
||||
| 维度 | 手动记录 | 自动化日志 |
|
||||
|------|---------|-----------|
|
||||
| 门槛 | 需要记忆格式 | 任意自然语言 |
|
||||
| 一致性 | 易遗漏 | 提醒驱动 |
|
||||
| 可分析性 | 依赖用户格式化 | AI 标准化 |
|
||||
| 维护成本 | 高 | 低 |
|
||||
|
||||
## Implementation
|
||||
- [[health-symptom-tracker]]:Telegram topic → OpenClaw Agent → Markdown 日志文件
|
||||
- [[habit-tracker-accountability-coach]]:类似的自动化记录模式
|
||||
|
||||
## Connections
|
||||
- [[Food Sensitivity Tracking]] ← enabled_by ← [[Automated Health Logging]]
|
||||
- [[OpenClaw]] ← powers ← [[Automated Health Logging]]
|
||||
32
wiki/concepts/CEOPattern.md
Normal file
32
wiki/concepts/CEOPattern.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "CEO Pattern"
|
||||
type: concept
|
||||
tags: [multi-agent, architecture, orchestration]
|
||||
sources: [autonomous-project-management]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## 定义
|
||||
主 Agent 仅负责策略决策(strategy only),所有执行操作下沉至子 Agent 的极简主控模式。其名称来源于"CEO 只做战略,不管执行"的企业管理隐喻。
|
||||
|
||||
## 核心原则
|
||||
- **主会话越薄越好**:0-2 步工具调用,响应速度与主会话的"薄度"成正比
|
||||
- **只做决策**:任务分配、优先级调整、结果汇总
|
||||
- **不做事**:不直接执行工具调用,不处理具体业务逻辑
|
||||
- **所有执行下沉**:子 Agent 自主工作,主会话只负责协调
|
||||
|
||||
## 关键洞察
|
||||
> "The less the main agent does, the faster it responds."
|
||||
|
||||
主会话的功能越少,其响应速度越快——这是去中心化协调架构的性能保障。
|
||||
|
||||
## 实现方式
|
||||
通过 [[PM Delegation Pattern]],每个子 Agent 被赋予特定范围的任务,独立完成,主会话不干预具体执行过程。
|
||||
|
||||
## 与传统 Orchestrator 模式的区别
|
||||
| 维度 | Orchestrator 模式 | CEO 模式 |
|
||||
|------|-------------------|---------|
|
||||
| 主 Agent 角色 | 交通指挥员(所有调用必经) | CEO(仅决策) |
|
||||
| 并行能力 | 受限(中心瓶颈) | 强(完全并行) |
|
||||
| 响应速度 | 随任务数线性下降 | 稳定(子 Agent 异步执行) |
|
||||
| 扩展性 | O(n) 瓶颈 | O(1) 主会话成本 |
|
||||
54
wiki/concepts/Competition-Analysis.md
Normal file
54
wiki/concepts/Competition-Analysis.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Competition-Analysis"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
在项目启动前,通过多平台(GitHub/npm/PyPI/Hacker News/Product Hunt)扫描竞品的存在性、成熟度和市场关注度的分析过程。是 [[Pre-Build Validation]] 的核心组成部分,帮助 AI Agent 和创业者判断赛道的真实竞争状态。
|
||||
|
||||
## 5 Data Sources
|
||||
| 平台 | 评估维度 | 代表性指标 |
|
||||
|---|---|---|
|
||||
| GitHub | 仓库数量、Star 总数、贡献者活跃度 | Top 竞品 star counts |
|
||||
| npm | Node.js 包数量、下载量趋势 | 包生态成熟度 |
|
||||
| PyPI | Python 包数量、pip 安装量 | Python 领域成熟度 |
|
||||
| Hacker News | 讨论帖数量、帖子分数 | 技术社区关注度 |
|
||||
| Product Hunt | 早期产品数量、Upvote 数 | 市场需求验证 |
|
||||
|
||||
## Process
|
||||
1. 输入:项目想法描述
|
||||
2. 扫描:5 个平台并行查询
|
||||
3. 聚合:综合评分([[Reality-Signal]])
|
||||
4. 输出:竞品列表 + 评分 + 转向建议
|
||||
|
||||
## Output Example
|
||||
```
|
||||
reality_signal: 90/100 (very high)
|
||||
|
||||
Top competitors:
|
||||
1. Gitea — 53,940 stars
|
||||
2. reviewdog — 9,104 stars
|
||||
3. Danger (Ruby) — 5,649 stars
|
||||
|
||||
This space has 143,000+ related repos.
|
||||
|
||||
Pivot suggestions:
|
||||
- Focus on a specific language (Rust/Go-only)
|
||||
- Target a specific framework (React/Vue component review)
|
||||
- Target a specific industry (financial/medical compliance)
|
||||
```
|
||||
|
||||
## Relationship to Related Concepts
|
||||
- [[Pre-Build Validation]] ← 核心组成部分
|
||||
- [[Reality-Signal]] ← 输出指标
|
||||
- [[Pivot-Strategy]] ← 拥挤赛道的后续行动
|
||||
- [[idea-reality-mcp]] ← 技术实现工具
|
||||
|
||||
## Related
|
||||
- [[Pre-Build Validation]]
|
||||
- [[Reality-Signal]]
|
||||
- [[Pivot-Strategy]]
|
||||
- [[idea-reality-mcp]]
|
||||
- [[Startup MVP Pipeline]]
|
||||
@@ -64,5 +64,5 @@ Cloudflare 是全球知名的 CDN 和 DNS 服务提供商,提供免费的 DNS
|
||||
- [[Cloudflare]] — DNS 托管服务商
|
||||
- [[RackNerd]] — VPS 公网 IP(DNS A 记录指向)
|
||||
- [[Caddy]] — 自动 HTTPS + 反向代理
|
||||
- [[FRP]] — 内网穿透隧道
|
||||
- [[frp]] — 内网穿透隧道
|
||||
- [[阿里云 DNS]] — 国内 DNS 替代方案
|
||||
|
||||
42
wiki/concepts/Defense-in-Depth.md
Normal file
42
wiki/concepts/Defense-in-Depth.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Defense-in-Depth"
|
||||
type: concept
|
||||
tags: [security, devsecops, ai-agents, risk-management]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Defense-in-Depth(纵深防御)是一种信息安全策略:通过叠加多层独立的安全控制措施,确保任何单一安全措施的失效不会导致系统完全沦陷。每层防线相互补足,即使攻击者突破一层,仍面临其他层的阻挡。
|
||||
|
||||
## In AI Agent Security Context
|
||||
在 [[self-healing-home-server]] 中,纵深防御针对 AI Agent 的特殊风险构建(特别是 [[OpenClaw]] 的 [[TruffleHog]] 第1天 API Key 泄露教训):
|
||||
|
||||
### 多层防御架构
|
||||
```
|
||||
Layer 1: Pre-push hooks (TruffleHog)
|
||||
↓ 阻止内嵌 secrets 的 commit
|
||||
Layer 2: Local-first Git (私有 Gitea)
|
||||
↓ 所有代码先到私有仓库
|
||||
Layer 3: CI Scanning Pipeline
|
||||
↓ TruffleHog + 依赖漏洞扫描
|
||||
Layer 4: Human Review
|
||||
↓ 必须人工审核 main 分支
|
||||
Layer 5: 1Password AI Vault
|
||||
↓ Agent 只能读取专用 vault 中的凭证
|
||||
Layer 6: Network Segmentation
|
||||
↓ 敏感服务网络隔离
|
||||
Layer 7: Daily Security Audit
|
||||
↓ 每日自动检查特权容器/过度权限
|
||||
```
|
||||
|
||||
## Key Principle
|
||||
> "Never trust a single security control." — 纵深防御的核心哲学
|
||||
|
||||
AI Agent 的风险在于它们**缺乏人类的"常识性危险感知"**——Agent 会在代码中直接写入 API Key而不产生"直觉性警告"。因此,安全防线必须设计为即使 Agent 无意识地绕过一层,仍有多层阻止最终损害。
|
||||
|
||||
## Connections
|
||||
- [[TruffleHog]] — 第1层防线:pre-push secrets 检测
|
||||
- [[Local-first Git]] — 第2-3层防线:私有仓库 + CI 扫描
|
||||
- [[1Password]] — 第5层防线:凭证安全管理
|
||||
- [[OpenClaw]] — 需要纵深防御保护的 Agent 平台
|
||||
- [[Agentic AI]] — 纵深防御是对 AI Agent 固有风险的主动应对
|
||||
28
wiki/concepts/Earnings-Beat-Miss.md
Normal file
28
wiki/concepts/Earnings-Beat-Miss.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Earnings Beat/Miss"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Earnings Beat/Miss 是衡量公司实际财报表现与分析师预期之间差距的指标。Beat(超预期)指实际 EPS/营收等指标高于预期;Miss(低于预期)则相反。是 AI 格式化财报摘要中的核心判断输出。
|
||||
|
||||
## Aliases
|
||||
- Beat/Miss
|
||||
- Earnings Surprise
|
||||
- 财报超预期 / 财报低于预期
|
||||
|
||||
## Key Metrics
|
||||
- **EPS**(Earnings Per Share):每股收益
|
||||
- **Revenue**(营收):季度/年度总收入
|
||||
- **AI Highlights**:AI 相关业务亮点
|
||||
- **Guidance**(指引):管理层对未来业绩的前瞻性预期
|
||||
|
||||
## Context
|
||||
在 [[Earnings Tracker]] 工作流中,OpenClaw 搜索财报结果后,格式化摘要需包含 beat/miss 判断及上述关键指标,作为 Telegram 投递的核心内容。Beat/Miss 直接影响股价短期走势,是财报读者最关心的结论性信息。
|
||||
|
||||
## Related Concepts
|
||||
- [[Earnings Calendar]] — 触发时机
|
||||
- [[Earnings Tracker]] — 使用此指标的工作流
|
||||
- [[AI-Powered Digest]] — 格式化摘要的通用模式
|
||||
22
wiki/concepts/Earnings-Calendar.md
Normal file
22
wiki/concepts/Earnings-Calendar.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Earnings Calendar"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Earnings Calendar(财报日历)是上市公司财报发布时间表,列出每家公司计划发布季度/年度财务报告的具体日期和时间。AI Agent 自动化追踪系统的输入数据源。
|
||||
|
||||
## Aliases
|
||||
- Earnings Schedule
|
||||
- 财报日历
|
||||
- 财报发布日程
|
||||
|
||||
## Context
|
||||
在 [[Earnings Tracker]] 工作流中,Earnings Calendar 是第一步数据源——OpenClaw Cron Job 每周日扫描日历,过滤用户关注的公司(NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD 等)后,在 Telegram 投递预览列表,用户确认后启动下一步追踪。
|
||||
|
||||
## Related Concepts
|
||||
- [[Earnings Beat/Miss]] — 财报结果判断
|
||||
- [[Earnings Tracker]] — 使用 Earnings Calendar 的自动化追踪工作流
|
||||
- [[Daily-Digest]] — 同属定时信息摘要模式
|
||||
29
wiki/concepts/Email-Triage.md
Normal file
29
wiki/concepts/Email-Triage.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Email Triage"
|
||||
type: concept
|
||||
tags: [automation, productivity, agent, email]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Email Triage(邮件分拣)指 AI Agent 自动扫描收件箱、识别待办事项、标记优先级,并归档噪音邮件的自动化流程。类似于医院急诊的分诊(triage)机制——快速评估、将紧急项优先处理、其余归档。
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 中,每小时运行的 Cron Job 自动执行邮件分拣:
|
||||
- **标记待办项**:识别需要回复或跟进的邮件,自动添加到任务看板
|
||||
- **归档噪音**:Promotional/Newsletters 等噪音邮件自动归档
|
||||
- **紧急升级**:包含关键词("urgent"/"deadline"/"ASAP")的邮件触发告警
|
||||
|
||||
## Tools Used
|
||||
- `gog CLI`:OpenClaw Agent 访问 Gmail 的接口
|
||||
- Gmail Labels:通过标签系统管理邮件分类
|
||||
- IMAP/SMTP:通用邮件访问协议
|
||||
|
||||
## Key Insight
|
||||
自动化邮件分拣将每日 30-60 分钟的手动邮件处理时间降至接近零,让用户专注于高价值任务。
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] — 通过 gog CLI 访问 Gmail 的 Agent 平台
|
||||
- [[Morning Briefing]] — 晨报中包含邮件处理提醒
|
||||
- [[TaskAutomation]] — 邮件分拣后自动创建任务
|
||||
- [[Cron定时任务]] — 邮件分拣的调度机制(每小时 cron)
|
||||
50
wiki/concepts/EventSourcing.md
Normal file
50
wiki/concepts/EventSourcing.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Event Sourcing"
|
||||
type: concept
|
||||
tags: [architecture, data-modeling, patterns]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
事件溯源(Event Sourcing)是一种软件架构模式——不直接存储数据的当前状态,而是将所有状态变更作为**不可变事件序列**持久化,通过重放事件来重建任意时间点的状态。源自 Martin Fowler 的经典模式。
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **唯一真实来源(Single Source of Truth)**:事件日志是唯一真实来源,当前状态由事件推导得出,而非直接存储
|
||||
2. **不可变性(Immutability)**:事件一旦写入,永不修改或删除,只能追加新事件
|
||||
3. **全历史可追溯(Audit Trail)**:天然具备完整审计日志,可回溯任何历史变更的"为什么"
|
||||
4. **时间旅行调试**:任意时刻的状态可精确重建,便于复现 BUG 和分析决策上下文
|
||||
|
||||
## Event Sourcing vs Traditional State Storage
|
||||
|
||||
| 维度 | 传统状态存储 | 事件溯源 |
|
||||
|------|------------|---------|
|
||||
| 存储内容 | 当前状态快照 | 状态变更事件序列 |
|
||||
| 历史保留 | 通常不保留或有限保留 | 完整保留(无上限)|
|
||||
| 变更原因 | 通常不记录 | 完整记录每次变更的原因 |
|
||||
| 回滚能力 | 依赖备份 | 通过反向事件补偿天然支持 |
|
||||
| 审计合规 | 需额外构建 | 内置,无需额外开发 |
|
||||
|
||||
## Key Event Types
|
||||
|
||||
- **Progress**:任务向前推进的里程碑事件
|
||||
- **Blocker**:阻塞/障碍事件,通常触发状态 → "blocked"
|
||||
- **Decision**:关键决策事件,记录决策理由和背景
|
||||
- **Pivot**:转向/重大调整事件,记录原因和备选方案
|
||||
- **Completion**:完成事件,触发状态 → "completed"
|
||||
|
||||
## Applications in Project Management
|
||||
|
||||
[[Project State Management]] 是事件溯源在个人/团队项目管理中的具体应用:
|
||||
|
||||
- 用自然语言对话替代手动拖拽看板卡片
|
||||
- 每句话("完成了X"/"被Y阻塞")作为独立事件持久化
|
||||
- 当前状态由事件序列自动推导,无需手动维护
|
||||
- 查询"项目为什么这样"等同于"重放这个项目的所有事件"
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Project State Management]] ← uses ← **Event Sourcing**
|
||||
- [[Centralized Logging]] ← related_to ← **Event Sourcing**(集中日志可视为事件溯源的一种实现)
|
||||
- [[Kanban]] ← alternative_to ← **Event Sourcing**(冲突:可视化协作 vs 自动追踪+上下文保留)
|
||||
31
wiki/concepts/Food-Sensitivity-Tracking.md
Normal file
31
wiki/concepts/Food-Sensitivity-Tracking.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Food Sensitivity Tracking"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Food Sensitivity Tracking
|
||||
|
||||
通过长期日志追踪来识别个人食物不耐受或过敏的实践方法。
|
||||
|
||||
## Definition
|
||||
记录食物摄入与身体症状(如头痛、腹胀、皮疹等)的时间关联,通过模式分析发现潜在的触发食物。
|
||||
|
||||
## How It Works
|
||||
1. **日志记录**:在摄入食物或出现症状时即时记录,带时间戳
|
||||
2. **一致性保证**:定时提醒确保不遗漏,建立长期数据积累
|
||||
3. **周期性分析**:每周或每月回顾日志,识别统计相关性
|
||||
4. **迭代验证**:排除疑似触发食物,观察症状变化以确认
|
||||
|
||||
## Key Insight
|
||||
> "Identifying food sensitivities requires consistent logging over time, which is tedious to maintain." — 这是自动化的核心驱动力
|
||||
|
||||
## Implementation Patterns
|
||||
- [[health-symptom-tracker]]:Telegram 话题 + OpenClaw 自动解析 + Markdown 日志
|
||||
- 移动端 App(如 Cara、Spoonful)作为专用替代方案
|
||||
|
||||
## Connections
|
||||
- [[Automated Health Logging]] ← enables ← [[Food Sensitivity Tracking]]
|
||||
- [[Cron Job Reminders]] ← supports ← [[Food Sensitivity Tracking]]
|
||||
50
wiki/concepts/Full-Draft-Generation.md
Normal file
50
wiki/concepts/Full-Draft-Generation.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Full Draft Generation"
|
||||
type: concept
|
||||
tags: [openclaw, productivity, content-automation]
|
||||
sources: [custom-morning-brief]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
完整草稿生成(Full Draft Generation)是一种 AI 内容创作范式——AI 不是仅提供标题或概要,而是生成可直接使用的完整内容成品(脚本、邮件、商业方案等),用户醒来后无需再从零开始。
|
||||
|
||||
## Why "Full Draft" Matters
|
||||
|
||||
传统 AI 助手通常生成:
|
||||
- ❌ 标题列表("5 个标题供选择")
|
||||
- ❌ 概要要点("要点如下:...")
|
||||
- ❌ 半成品框架("你可以这样写...")
|
||||
|
||||
Full Draft 模式生成:
|
||||
- ✅ 完整脚本/大纲 → 拿来就用
|
||||
- ✅ 完整邮件正文 → 直接发送
|
||||
- ✅ 完整商业方案 → 提交即用
|
||||
|
||||
## Key Insight
|
||||
|
||||
> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." — 自定义晨间简报的核心差异化价值
|
||||
|
||||
## Typical Workflow
|
||||
|
||||
1. **睡前**:用户通过 Telegram 发送创作需求
|
||||
2. **夜间**:OpenClaw 在后台生成完整内容
|
||||
3. **晨起**:用户收到可直接使用的成品
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **[[custom-morning-brief]]**:睡前生成完整演讲脚本/视频大纲/邮件草稿
|
||||
- **[[podcast-production-pipeline]]**:生成播客脚本和社媒推广包
|
||||
|
||||
## Trade-off
|
||||
|
||||
Full Draft 比概要生成:
|
||||
- **优势**:节省用户时间,交付物价值更高
|
||||
- **劣势**:计算成本更高,生成时间更长
|
||||
- **适合**:高频、固定格式、有明确使用场景的内容
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Scheduled Task Flywheel]] — Full Draft 生成的时间调度机制
|
||||
- [[Proactive Agent Recommendation]] — Full Draft 作为主动推荐的具体输出形式
|
||||
35
wiki/concepts/GitAsAuditLog.md
Normal file
35
wiki/concepts/GitAsAuditLog.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Git-as-Audit-Log"
|
||||
type: concept
|
||||
tags: [version-control, git, audit, multi-agent]
|
||||
sources: [autonomous-project-management]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## 定义
|
||||
将所有状态变更(包括 [[Shared State Coordination]] 中的 STATE.yaml 变更)作为 Git 提交处理,从而获得完整可追溯的决策和执行历史的方法。
|
||||
|
||||
## 核心实践
|
||||
每次对 STATE.yaml 的修改都触发一个 Git 提交:
|
||||
```bash
|
||||
# 状态更新后
|
||||
git add STATE.yaml
|
||||
git commit -m "task(id=xxx): updated status from in_progress to done"
|
||||
```
|
||||
|
||||
## 价值
|
||||
1. **完整历史追溯**:任意时刻可回滚到任何历史状态
|
||||
2. **决策上下文保留**:每次变更的 commit message 即变更理由的记录
|
||||
3. **团队协作基础**:多成员可查看、review 状态变更历史
|
||||
4. **自动化 CI/CD 集成**:可基于 Git 状态变更触发后续流程
|
||||
|
||||
## 在 [[autonomous-project-management]] 中的角色
|
||||
- 规则明确:All state changes committed to git
|
||||
- 每个 PM 子 Agent 负责自己 STATE.yaml 的 Git 提交
|
||||
- 结合 [[Git-as-Audit-Log]] 和 [[Shared State Coordination]],实现自文档化的项目协调
|
||||
|
||||
## Commit Message 约定
|
||||
建议格式:`[type](task_id): description`
|
||||
- `type`: started / updated / completed / blocked / unblocked
|
||||
- `task_id`: 对应 STATE.yaml 中的任务 ID
|
||||
- `description`: 变更的具体内容
|
||||
@@ -74,4 +74,4 @@ Caddy 是用 Go 语言编写的现代化 Web 服务器,其核心特性之一
|
||||
- [[Caddy]] — 自动 HTTPS 实现者
|
||||
- [[RackNerd]] — Caddy 运行环境
|
||||
- [[Cloudflare]] — DNS 服务提供商,支持 DNS-01 挑战
|
||||
- [[FRP]] — 内网服务的传输通道
|
||||
- [[frp]] — 内网服务的传输通道
|
||||
|
||||
43
wiki/concepts/Last-30-Days-Method.md
Normal file
43
wiki/concepts/Last-30-Days-Method.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Last 30 Days Method"
|
||||
type: concept
|
||||
tags: [market-research, social-media-mining, agentic-ai]
|
||||
sources: [market-research-product-factory, last30days-使用指南]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Last 30 Days Method(近30天法)是一种聚焦近期用户讨论以获取时效性洞察的市场研究方法论——通过限定时间窗口过滤噪音,专注于用户在此时此刻正在经历的问题和需求,避免被历史积累的过时信息干扰。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
1. **时间窗口锁定**:只采集最近30天内的帖子/推文/评论
|
||||
2. **数据源覆盖**:Reddit(社区讨论)和 X/Twitter(实时热点)双平台
|
||||
3. **聚类与排名**:将相似问题归类,按出现频率排序,识别TOP痛点
|
||||
4. **原始引用保留**:保留用户原始表述,而非经过转述的二手信息
|
||||
|
||||
## Why 30 Days
|
||||
|
||||
- **信息时效性**:30天足够收集足够样本量,又不至于被过时内容淹没
|
||||
- **市场敏感度**:技术领域变化快,过时的讨论可能反映已解决的旧问题
|
||||
- **信号/噪音比**:对比全量历史,30天内的讨论代表用户当前最关心的事
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- **[[Last 30 Days Method]]** → 工具方法 → **[[Agent-Driven Market Research]]**
|
||||
- **[[Last 30 Days Method]]** → 工具方法 → **[[Pain Point Mining]]**
|
||||
- **[[Last 30 Days Method]]** → 数据供给 → **[[Startup MVP Pipeline]]**
|
||||
- **[[Last 30 Days Skill]]** → 软件实现 → **[[Last 30 Days Method]]**
|
||||
|
||||
## Implementation
|
||||
|
||||
在 OpenClaw 生态中,通过 `Last 30 Days Skill` 实现:
|
||||
```text
|
||||
Please use the Last 30 Days skill to research challenges people are having with [your topic].
|
||||
```
|
||||
|
||||
## Sources
|
||||
|
||||
- [[market-research-product-factory]]
|
||||
- [[last30days-使用指南]]
|
||||
35
wiki/concepts/Local-first-Git.md
Normal file
35
wiki/concepts/Local-first-Git.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Local-first Git"
|
||||
type: concept
|
||||
tags: [git, security, devops, self-hosted, devsecops]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Local-first Git 是一种 Git 工作流策略:所有代码变更首先推送到本地/私有 Git 服务(而非直接推送到公共 GitHub),经过 CI 扫描和人工 review 后再合并到公共仓库。核心原则:**公共仓库永远不应该是 Agent 的直接目标**。
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 的安全架构中,Local-first Git 工作流:
|
||||
```
|
||||
Agent commits
|
||||
↓
|
||||
Gitea (private self-hosted) — 私有中转站
|
||||
↓
|
||||
CI pipeline — TruffleHog secrets scanning
|
||||
↓
|
||||
Human review — 必须人工审核 main 分支合并
|
||||
↓
|
||||
GitHub (public) — 最终发布目标
|
||||
```
|
||||
|
||||
## Why Local-first for AI Agents?
|
||||
1. **Secrets 暴露风险**:AI Agent 会在代码中直接写入 API keys(TruffleHog 可检测但不能阻止)
|
||||
2. **CI 安全扫描**:在代码到达公共仓库前,有机会拦截问题
|
||||
3. **Human oversight**:人工 review 作为最后防线
|
||||
4. **Audit trail**:Gitea 提供完整的代码变更审计记录
|
||||
|
||||
## Connections
|
||||
- [[Gitea]] — Local-first 工作流的核心基础设施
|
||||
- [[TruffleHog]] — CI pipeline 中的 secrets scanning 工具
|
||||
- [[Defense-in-Depth]] — Local-first Git 是多层安全防御的一环
|
||||
- [[OpenClaw]] — 使用 Local-first Git 工作流的 Agent 平台
|
||||
48
wiki/concepts/Morning-Briefing.md
Normal file
48
wiki/concepts/Morning-Briefing.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Morning Briefing"
|
||||
type: concept
|
||||
tags: [automation, agent, productivity, daily-routine]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
Morning Briefing(晨报)是 AI Agent 每日定时(通常 8:00 AM)自动生成并推送的结构化摘要,将天气、日历、系统状态和任务看板整合为一份统一的可操作简报。
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 中,OpenClaw Agent "Reef" 每日 8:00 AM 生成晨报,包含以下模块:
|
||||
|
||||
### 晨报模板结构
|
||||
```
|
||||
### Weather
|
||||
- 当前天气条件和 [所在地] 预报
|
||||
|
||||
### Calendars
|
||||
- 你的今日事件
|
||||
- 伴侣的今日事件
|
||||
- 冲突或重叠标记
|
||||
|
||||
### System Health
|
||||
- 所有机器的 CPU / RAM / Storage
|
||||
- Services: UP/DOWN 状态
|
||||
- 最近部署(ArgoCD)
|
||||
- 过去 24h 的任何告警
|
||||
|
||||
### Task Board
|
||||
- 昨日完成的卡片
|
||||
- 进行中的卡片
|
||||
- 需要关注的阻塞项
|
||||
|
||||
### Highlights
|
||||
- 夜间头脑风暴的亮点
|
||||
- 需要处理的邮件
|
||||
- 本周即将到来的截止日期
|
||||
```
|
||||
|
||||
## Key Insight
|
||||
晨报将来自多个系统的碎片信息(天气 API、日历 API、监控系统、看板)整合为单一可操作视图,大幅降低每日信息获取成本。
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] — 生成晨报的 Agent 平台
|
||||
- [[Agentic AI]] — 驱动晨报自动化的 AI 能力
|
||||
- [[Cron定时任务]] — 晨报调度的触发机制(每日 8:00 AM cron job)
|
||||
- [[Daily-Digest]] — 类似思路:AI 每日自动整理信息推送
|
||||
30
wiki/concepts/PMDelegationPattern.md
Normal file
30
wiki/concepts/PMDelegationPattern.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "PM Delegation Pattern"
|
||||
type: concept
|
||||
tags: [multi-agent, project-management, coordination]
|
||||
sources: [autonomous-project-management]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## 定义
|
||||
主会话仅负责协调(coordinator),所有执行下沉至子 Agent 的委托模式。每个子 Agent 作为独立的 PM(Project Manager),拥有自己的 STATE.yaml 文件。
|
||||
|
||||
## 核心规则
|
||||
- **主会话最大工具调用数**:0-2 步(仅 spawn/send 操作)
|
||||
- **PM 子 Agent 职责**:拥有和管理自己的 STATE.yaml 文件
|
||||
- **PM 可派生子子 Agent**:支持多层级的并行子任务
|
||||
- **Git 版本控制**:所有状态变更必须提交至 Git
|
||||
|
||||
## 工作流
|
||||
1. 新任务到达主会话
|
||||
2. 检查 PROJECT_REGISTRY.md 确认是否存在对应 PM
|
||||
3. 存在 PM → `sessions_send(label="pm-xxx", message="[task]")`
|
||||
4. 新项目 → `sessions_spawn(label="pm-xxx", task="[task]")`
|
||||
5. PM 执行任务并更新 STATE.yaml,完成后汇报主会话
|
||||
6. 主会话向用户汇总
|
||||
|
||||
## 标签约定
|
||||
使用 `pm-{project}-{scope}` 格式(如 `pm-auth-refactor`),便于追踪和管理。
|
||||
|
||||
## 与 [[CEO Pattern]] 的关系
|
||||
PM Delegation Pattern 是 CEO Pattern 在项目管理场景的具体实现——主会话扮演 CEO,仅做战略决策;PM 子 Agent 扮演部门负责人,负责具体执行。
|
||||
27
wiki/concepts/Pain-Point-Mining.md
Normal file
27
wiki/concepts/Pain-Point-Mining.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Pain Point Mining"
|
||||
type: concept
|
||||
tags: [market-research, agentic-ai, product-discovery]
|
||||
sources: [market-research-product-factory]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Pain Point Mining(痛点挖掘)是通过系统化方式从真实用户讨论中识别未被满足的需求、抱怨和功能请求的过程,区别于传统调查问卷或访谈——它直接采集未经加工的用户原生表达。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
- **数据来源**:Reddit 社区帖子、X/Twitter 用户推文、论坛讨论、产品评论区
|
||||
- **时间窗口**:聚焦近期(如最近30天)讨论以获取时效性洞察
|
||||
- **分析方法**:频率统计(高频问题 → 高优先级)、情感分析(强烈负面情绪 → 强需求)、竞品对比(现有方案缺失 → 机会点)
|
||||
- **输出格式**:痛点排名 + 具体投诉引用 + 潜在解决方案方向
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- **[[Pain Point Mining]]** → 输入 → **[[Agent-Driven Market Research]]** → 支撑 → **[[Startup MVP Pipeline]]**
|
||||
- **[[Pain Point Mining]]** ← 工具依赖 ← **[[Last 30 Days Method]]**
|
||||
|
||||
## Sources
|
||||
|
||||
- [[market-research-product-factory]]
|
||||
61
wiki/concepts/Parallel-Agent-Execution.md
Normal file
61
wiki/concepts/Parallel-Agent-Execution.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Parallel Agent Execution"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Architecture, Performance]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Parallel Agent Execution** 是多 Agent 系统中,多个 Agent 同时处理相互独立的任务,通过并行计算提升整体效率的架构模式。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "Parallel execution: Multiple agents can work on independent tasks simultaneously"
|
||||
|
||||
并行执行的价值:
|
||||
- **效率倍增**:多个任务同时处理,总时间大幅减少
|
||||
- **资源优化**:不同 Agent 使用各自擅长的模型
|
||||
- **独立扩展**:根据任务量动态调整 Agent 数量
|
||||
|
||||
## 并行 vs 串行
|
||||
|
||||
| 模式 | 描述 | 时间复杂度 | 适用场景 |
|
||||
|------|------|------------|----------|
|
||||
| **串行执行** | Agent A → Agent B → Agent C | O(n×t) | 有依赖关系的任务链 |
|
||||
| **并行执行** | Agent A ∥ Agent B ∥ Agent C | O(max(t₁,t₂,t₃)) | 独立任务 |
|
||||
|
||||
## 并行执行的典型场景
|
||||
|
||||
1. **多领域研究**
|
||||
- Josh 分析市场数据
|
||||
- Marketing 追踪竞品动态
|
||||
- Dev 检查 CI/CD 健康状态
|
||||
- 三者同时进行,无需等待
|
||||
|
||||
2. **内容创作**
|
||||
- 同时生成多个内容变体
|
||||
- 不同 Agent 用不同风格/角度
|
||||
|
||||
3. **监控与响应**
|
||||
- Marketing 持续监控社媒
|
||||
- Dev 持续监控代码质量
|
||||
- Milo 持续追踪 OKR
|
||||
|
||||
## 与 Chained Agents 的对比
|
||||
|
||||
| 维度 | Parallel Execution | Chained Agents |
|
||||
|------|-------------------|----------------|
|
||||
| **任务关系** | 独立 | 串行依赖 |
|
||||
| **时间效率** | 高(同时) | 中(等待) |
|
||||
| **适用场景** | 多领域研究、监控 | 内容生产、审批流 |
|
||||
| **协调复杂度** | 低 | 中 |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Agent Specialization]] — 专业化 Agent 是并行执行的基础
|
||||
- [[Chained Agents]] — 链式 Agent(串行依赖场景)
|
||||
- [[Multi-Agent Coordination]] — 多 Agent 协调机制
|
||||
- [[Scheduled Task Flywheel]] — 定时任务常利用并行执行
|
||||
|
||||
54
wiki/concepts/Pivot-Strategy.md
Normal file
54
wiki/concepts/Pivot-Strategy.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Pivot-Strategy"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
当赛道拥挤度较高(`reality_signal > 30`)时,通过重新定位切入角度实现差异化的策略。通过分析现有竞品的覆盖盲区,找到一个可专注的细分维度,在该维度上构建竞争优势。
|
||||
|
||||
## Three Pivot Dimensions
|
||||
当 `reality_signal` 显示赛道拥挤时,可通过以下三个维度实现转向:
|
||||
|
||||
### 1. Language Specialization
|
||||
语言专一化——只支持特定编程语言的竞品细分。
|
||||
- 示例:不做通用的"AI code review tool",而是"**Rust-only AI code review**",规避与通用方案(GitHub Copilot、CodeRabbit)的正面竞争
|
||||
- 适用场景:某语言社区有特殊需求,通用方案覆盖不足
|
||||
|
||||
### 2. Framework Specialization
|
||||
框架专一化——只针对特定框架的审查工具。
|
||||
- 示例:"**React 组件合规性审查**"而非通用代码审查
|
||||
- 适用场景:某框架有独特的 linting/compliance 需求
|
||||
|
||||
### 3. Industry Specialization
|
||||
行业专一化——针对特定垂直行业的合规/审查工具。
|
||||
- 示例:"**金融/医疗代码合规性审查**"(HIPAA、SOX 相关代码检查)
|
||||
- 适用场景:强监管行业有特殊代码合规要求,通用方案无法满足
|
||||
|
||||
## Decision Framework
|
||||
```
|
||||
reality_signal > 70?
|
||||
→ STOP + 展示竞品 + 询问用户是否继续/转向/放弃
|
||||
→ 用户选择 pivot 后,从三个维度中选择最合适的角度
|
||||
|
||||
reality_signal 30-70?
|
||||
→ 展示竞品 + 提供 pivot_hints
|
||||
→ Agent 主动建议差异化角度
|
||||
|
||||
reality_signal < 30?
|
||||
→ 赛道空白,直接构建
|
||||
```
|
||||
|
||||
## Relationship to Related Concepts
|
||||
- [[Competition-Analysis]] ← 识别需要 pivot 的时机
|
||||
- [[Reality-Signal]] ← 决策阈值依据
|
||||
- [[Pre-Build Validation]] ← 包含 pivot 决策的工作流
|
||||
- [[Agent-Build-Gate]] ← pivot 决策通过后的后续动作
|
||||
|
||||
## Related
|
||||
- [[Competition-Analysis]]
|
||||
- [[Reality-Signal]]
|
||||
- [[Pre-Build Validation]]
|
||||
- [[Agent-Build-Gate]]
|
||||
- [[Startup MVP Pipeline]]
|
||||
45
wiki/concepts/Pre-Build-Validation.md
Normal file
45
wiki/concepts/Pre-Build-Validation.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Pre-Build Validation"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
在代码编写之前进行市场/竞争验证的工作流模式。AI Agent 接收构建指令后,首先调用竞争分析工具(如 [[idea-reality-mcp]] 的 `idea_check()`)评估赛道的真实拥挤度,只有通过门控条件才允许进入实际代码编写阶段。
|
||||
|
||||
## Mechanism
|
||||
1. 用户/Agent 提出构建需求(如"build me an AI code review tool")
|
||||
2. Agent 调用 `idea_check()` 扫描多平台真实数据
|
||||
3. 返回 `reality_signal` 分数(0-100)
|
||||
4. 根据阈值决策:继续构建 / 暂停讨论 / 建议转向
|
||||
|
||||
## Decision Thresholds
|
||||
| reality_signal | 决策 | 行动 |
|
||||
|---|---|---|
|
||||
| > 70 | STOP | 展示竞品,询问是否继续/转向/放弃 |
|
||||
| 30-70 | 展示+建议 | 显示结果和 pivot_hints,建议差异化角度 |
|
||||
| < 30 | 直接构建 | 提示市场空白,批准开始编写代码 |
|
||||
|
||||
## Why It Matters
|
||||
防止 AI Agent 犯最昂贵的错误:**在一个已被成熟方案解决的领域投入大量时间**。GitHub 上有 143,000+ AI code review 相关仓库,顶端方案已有 53,000+ stars——Agent 不知道是因为没有人告诉它去查,也没有人告诉它应该查。
|
||||
|
||||
## Relationship to Related Concepts
|
||||
- [[Pre-Build Validation]] ← 前置于 [[Startup MVP Pipeline]]
|
||||
- [[Pain Point Mining]] → [[Pre-Build Validation]] → [[Startup MVP Pipeline]](完整的产品发现到构建流程)
|
||||
- [[Reality-Signal]] 是 [[Pre-Build Validation]] 的核心度量指标
|
||||
- [[Agent-Build-Gate]] 是 [[Pre-Build Validation]] 的技术实现机制
|
||||
|
||||
## Aliases
|
||||
- Pre-Build Gate
|
||||
- Idea Validation Gate
|
||||
- Pre-Build Checkpoint
|
||||
|
||||
## Related
|
||||
- [[idea-reality-mcp]]
|
||||
- [[Reality-Signal]]
|
||||
- [[Competition-Analysis]]
|
||||
- [[Pivot-Strategy]]
|
||||
- [[Agent-Build-Gate]]
|
||||
- [[Startup MVP Pipeline]]
|
||||
- [[Pain Point Mining]]
|
||||
63
wiki/concepts/Private-Context.md
Normal file
63
wiki/concepts/Private-Context.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Private Context"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Architecture, Memory]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Private Context** 是多 Agent 系统中,每个 Agent 独立维护的会话历史和领域特定笔记,与 Shared Memory 共同构成 Agent 的完整知识体系。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "Shared memory + private context: The combination is critical — agents need common ground (goals, decisions) but also their own space to accumulate domain expertise"
|
||||
|
||||
私有上下文的作用:
|
||||
- **积累领域专长**:Agent 在独立空间深耕专业知识
|
||||
- **会话连续性**:Agent 能记住自己的历史决策和上下文
|
||||
- **避免干扰**:专业笔记不会与其他 Agent 混淆
|
||||
|
||||
## 私有上下文结构
|
||||
|
||||
```
|
||||
team/agents/
|
||||
├── milo/ # Milo 的私有上下文
|
||||
│ ├── sessions/ # 会话历史
|
||||
│ └── notes/ # 战略分析和笔记
|
||||
├── josh/ # Josh 的私有上下文
|
||||
│ ├── sessions/ # 会话历史
|
||||
│ └── notes/ # 商业分析和模型
|
||||
├── marketing/ # 营销 Agent 的私有上下文
|
||||
│ ├── sessions/ # 会话历史
|
||||
│ └── notes/ # 营销研究和趋势分析
|
||||
└── dev/ # 开发 Agent 的私有上下文
|
||||
├── sessions/ # 会话历史
|
||||
└── notes/ # 技术笔记和技术债追踪
|
||||
```
|
||||
|
||||
## 与 Shared Memory 的关系
|
||||
|
||||
**Private Context** + **Shared Memory** 组合是关键:
|
||||
|
||||
| 维度 | Shared Memory | Private Context |
|
||||
|------|---------------|-----------------|
|
||||
| **可见性** | 所有 Agent | 仅该 Agent |
|
||||
| **用途** | 团队协调、共同决策 | 领域深耕、专业积累 |
|
||||
| **更新频率** | 决策时更新 | 持续积累 |
|
||||
| **典型内容** | 目标、决策、状态 | 会话历史、专业笔记 |
|
||||
|
||||
## 为什么两者都需要
|
||||
|
||||
- **只有共享记忆**:Agent 缺乏领域深度
|
||||
- **只有私有上下文**:Agent 无法协调,形成知识孤岛
|
||||
- **两者结合**:既能有团队协作,又能深耕专业
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Shared Memory Architecture]] — 团队共享记忆
|
||||
- [[Agent-Memory]] — OpenClaw 的长期记忆机制
|
||||
- [[Agent Specialization]] — 专业化 Agent 依赖私有上下文积累深度
|
||||
- [[OpenClaw]] — workspace 目录体系支持私有上下文
|
||||
|
||||
41
wiki/concepts/Proactive-Agent-Recommendation.md
Normal file
41
wiki/concepts/Proactive-Agent-Recommendation.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Proactive Agent Recommendation"
|
||||
type: concept
|
||||
tags: [openclaw, ai-agent, productivity]
|
||||
sources: [custom-morning-brief, multi-agent-team]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
主动任务推荐(Proactive Agent Recommendation)是一种 AI Agent 设计范式——Agent 不是被动等待用户指令,而是主动分析用户上下文并推荐可自主完成的辅助任务,使用户从"发出指令→等待结果"转变为"收到已完成的工作成果"。
|
||||
|
||||
## Contrast with Reactive Mode
|
||||
|
||||
| 维度 | 被动模式(Reactive) | 主动模式(Proactive) |
|
||||
|------|--------------------|--------------------|
|
||||
| 触发方式 | 用户主动发起请求 | AI 定时或基于上下文自动触发 |
|
||||
| 用户角色 | 指挥官 | 接收者/审批者 |
|
||||
| 价值交付 | 按需响应 | 提前完成,超出预期 |
|
||||
| 认知负担 | 用户需持续思考"要什么" | AI 承担"思考要做什么" |
|
||||
|
||||
## Key Applications
|
||||
|
||||
- **[[custom-morning-brief]]**:每日晨间简报中的"AI 主动推荐可完成任务"模块
|
||||
- **[[multi-agent-team]]**:Agent 主动推送工作成果,而非等待轮询
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
```text
|
||||
1. Cron Job 触发 → AI 分析用户上下文
|
||||
2. AI 生成 N 条可自主完成的任务建议
|
||||
3. 高置信度任务 → 自动执行
|
||||
4. 中置信度任务 → 推送选项,用户确认后执行
|
||||
5. 结果交付 → Telegram/Discord
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Scheduled Task Flywheel]] — 主动推荐的时间调度机制
|
||||
- [[Agent Personality]] — 主动行为需要精心设计的 Agent 人格
|
||||
- [[Morning Briefing]] — 主动推荐的典型应用场景
|
||||
59
wiki/concepts/ProjectState.md
Normal file
59
wiki/concepts/ProjectState.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Project State"
|
||||
type: concept
|
||||
tags: [project-management, automation, ai]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
项目状态(Project State)指一个项目在任意时间点的完整快照——包括当前阶段、活跃阻塞项、最近进展、以及完整的事件历史上下文。与传统项目管理工具中"当前状态"字段不同,项目状态由底层事件自动驱动更新,而非手动维护。
|
||||
|
||||
## What It Captures
|
||||
|
||||
一个完整项目状态系统通常包含:
|
||||
|
||||
- **基本元数据**:项目名称、当前阶段(phase)、总体状态(active/blocked/completed)
|
||||
- **时间戳**:最后更新时间,便于判断项目是否"失活"
|
||||
- **事件日志**:所有 progress/blocker/decision/pivot 事件的完整序列
|
||||
- **阻塞清单**:当前所有 open blockers 及创建时间
|
||||
- **上下文**:每次变更的决策理由,而非仅记录"变更了什么"
|
||||
|
||||
## State Machine
|
||||
|
||||
典型项目状态流转:
|
||||
|
||||
```
|
||||
active → [blocked event] → blocked
|
||||
blocked → [blocker resolved event] → active
|
||||
active → [completion event] → completed
|
||||
any → [pivot event] → active (new phase)
|
||||
```
|
||||
|
||||
## Event-Driven vs Kanban
|
||||
|
||||
| 维度 | 事件驱动项目状态 | 传统看板(Kanban)|
|
||||
|------|---------------|----------------|
|
||||
| 更新方式 | 自然语言对话自动驱动 | 手动拖拽卡片 |
|
||||
| 状态来源 | 事件序列推导 | 卡片当前位置 |
|
||||
| 历史保留 | 完整事件日志,可回溯决策原因 | 通常不保留,状态变更即丢失 |
|
||||
| 上下文 | 每次变更附带决策理由 | 无,需额外备注 |
|
||||
| 阻塞追踪 | 独立 blocker 记录 + 自动状态更新 | 卡片标签/泳道,依赖人工识别 |
|
||||
| 团队协作 | 需要额外机制(如 Discord 多用户)| 原生支持多人实时协作 |
|
||||
| 适合场景 | 个人/小团队,需要上下文保留 | 中大型团队,强协作需求 |
|
||||
|
||||
## AI Integration
|
||||
|
||||
在 [[Project State Management]] 系统中,AI Agent 承担以下角色:
|
||||
|
||||
- **自然语言解析器**:将用户日常对话转换为结构化事件
|
||||
- **状态引擎**:根据事件类型自动更新项目状态
|
||||
- **查询接口**:回答"项目X现在什么状态"/"为什么做了Y决策"
|
||||
- **报告生成器**:自动生成每日站会、每周总结
|
||||
|
||||
## Connections
|
||||
|
||||
- **Project State** ← derived_from ← [[Event Sourcing]]
|
||||
- **Project State** ← powered_by ← [[OpenClaw]]
|
||||
- **Project State Management** ← uses ← **Project State**
|
||||
- [[Kanban]] ← alternative_to ← **Project State**(冲突:参见 overview.md Conflict Area #1)
|
||||
40
wiki/concepts/Reality-Signal.md
Normal file
40
wiki/concepts/Reality-Signal.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Reality-Signal"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
通过 `idea_check()` 返回的 0-100 赛道拥挤度评分,基于 GitHub 仓库数量、Star 分布、Hacker News 讨论量等真实数据。用于 [[Pre-Build Validation]] 的核心度量指标,决定 Agent 是否可以继续构建还是需要暂停讨论。
|
||||
|
||||
## Scoring Mechanism
|
||||
- **GitHub**:相关仓库数量 + Top 竞品的 Star 总数
|
||||
- **Hacker News**:相关讨论帖数量 + 平均分数
|
||||
- **npm / PyPI**:包数量 + 下载量分布
|
||||
- **Product Hunt**:早期产品关注度
|
||||
|
||||
综合以上数据输出 0-100 的 `reality_signal` 分数。
|
||||
|
||||
## Interpretation
|
||||
| 分数区间 | 信号含义 | 行动 |
|
||||
|---|---|---|
|
||||
| > 70/100 | 高度拥挤 | 成熟竞品众多,需强差异化 |
|
||||
| 30-70/100 | 中度竞争 | 存在机会但需细分角度 |
|
||||
| < 30/100 | 市场空白 | 真正的蓝海,白手起家的最佳区间 |
|
||||
|
||||
## Key Properties
|
||||
- **基于真实数据,非 LLM 猜测**:unlike subjective assessment, reality_signal uses actual repo counts, star distributions, and HN discussion volume
|
||||
- **用途**:[[Pre-Build Validation]] 决策依据;Hackathon 想法排名(最低分 = 最佳机会)
|
||||
- **局限性**:无法评估技术实现难度、市场进入时机、团队执行能力
|
||||
|
||||
## Aliases
|
||||
- Competition Score
|
||||
- Market Saturation Score
|
||||
- Idea Signal
|
||||
|
||||
## Related
|
||||
- [[Pre-Build Validation]]
|
||||
- [[Competition-Analysis]]
|
||||
- [[idea-reality-mcp]]
|
||||
- [[Pivot-Strategy]]
|
||||
31
wiki/concepts/Sandboxed-Persona.md
Normal file
31
wiki/concepts/Sandboxed-Persona.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Sandboxed Persona"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
沙盒 Persona 是一种 AI 对话设计模式——AI persona 仅持有预设的上下文(persona name、goal、opening line),与外部系统(Agent、数据、工具、其他对话)完全隔离,无法访问、修改或泄露任何超出预设范围的信息。
|
||||
|
||||
## Key Properties
|
||||
- **上下文隔离**:AI 只知道预设的三要素(名称、目标、开场白)
|
||||
- **状态重置**:每轮对话独立初始化,无跨对话状态保留
|
||||
- **攻击面收窄**:外部用户无法通过对话注入 Prompt 或窃取数据
|
||||
- **任务专注**:AI 不会因过多上下文而偏离单一任务
|
||||
|
||||
## Use Cases
|
||||
- [[SuperCall]] — 电话外呼场景,AI 以沙盒 persona 接听来电确认出席
|
||||
- [[voice-call-confirmation]] — 需要纯确认流程的各类电话场景
|
||||
- AI 客服 / AI 面试官 / AI 问卷调查 — 需要严格控制信息边界的对话
|
||||
|
||||
## Related Concepts
|
||||
- [[Agent Personality Design]] — Agent 的角色/性格设计
|
||||
- [[Private Context]] — Agent 的私有上下文保护
|
||||
- [[Prompt Injection Defense]] — 对抗恶意 Prompt 注入的防御策略
|
||||
|
||||
## Contradictions
|
||||
- 与 [[General Purpose Voice Agent]] 对比:
|
||||
- 冲突点:通用语音 Agent 追求多功能和上下文丰富性;沙盒 Persona 追求最小暴露
|
||||
- 当前观点:沙盒 Persona 适用于确认类单一任务场景
|
||||
- 对方观点:通用 Agent 适用于需要跨系统协调的复杂助手场景
|
||||
37
wiki/concepts/Scheduled-Reminder.md
Normal file
37
wiki/concepts/Scheduled-Reminder.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Scheduled Reminder"
|
||||
type: concept
|
||||
tags: [Automation, Cron, Agent, Proactive, OpenClaw]
|
||||
sources: [multi-channel-assistant]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Scheduled Reminder
|
||||
|
||||
## Definition
|
||||
Scheduled Reminder(定时提醒)是一种基于 Cron Job 的主动推送机制——AI Agent 在预设时间自动触发提醒消息,无需用户主动查询。在 [[multi-channel-assistant]] 中展示了定时提醒的典型应用。
|
||||
|
||||
## Mechanism
|
||||
OpenClaw 通过 Cron Job 系统调度定时任务:
|
||||
|
||||
- **周一 18:00** → "🗑️ 明天是垃圾清理日"
|
||||
- **周五 15:00** → "✍️ 该写每周公司周报了"
|
||||
|
||||
## Significance
|
||||
Scheduled Reminder 是 AI Agent 区别于传统问答式 AI 工具的核心特征:
|
||||
|
||||
| 被动模式 | 主动模式 |
|
||||
|---------|---------|
|
||||
| 用户问,AI 答 | AI 定时推送,用户被动接收 |
|
||||
| 需要用户主动关注 | 用户无需记住,系统主动提醒 |
|
||||
| 依赖用户记忆 | 零记忆负担 |
|
||||
|
||||
## Related Patterns
|
||||
- [[Scheduled Task Flywheel]] — 定时任务驱动的持续运转机制
|
||||
- [[Morning Briefing]] — 定时提醒的具体应用场景
|
||||
- [[Topic-Based Routing]] — `updates` Topic 承载提醒消息的投递
|
||||
|
||||
## Connections
|
||||
- [[multi-channel-assistant]] — Scheduled Reminder 的应用场景
|
||||
- [[OpenClaw]] — Cron Job 调度引擎
|
||||
- [[Telegram]] — 提醒消息的投递渠道
|
||||
42
wiki/concepts/Scheduled-Task-Flywheel.md
Normal file
42
wiki/concepts/Scheduled-Task-Flywheel.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Scheduled Task Flywheel"
|
||||
type: concept
|
||||
tags: [openclaw, automation, productivity]
|
||||
sources: [multi-agent-team, custom-morning-brief, earnings-tracker, self-healing-home-server]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
定时任务飞轮(Scheduled Task Flywheel)是 OpenClaw 的核心自动化范式——通过定时 Cron Job 触发 AI Agent 自主工作,用户无需主动发起指令,AI 在后台完成情报收集、内容生成、数据处理等任务,结果在用户需要时已就位。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
1. **调度层**:通过 Cron Job 设置定时触发规则(每日 8AM、每周日 6PM 等)
|
||||
2. **执行层**:AI Agent 在触发时间自动执行任务(网络搜索、内容生成、数据处理)
|
||||
3. **交付层**:结果通过 Telegram/Discord/iMessage 推送给用户
|
||||
4. **飞轮效应**:每次执行都为下次提供更好的上下文积累,形成自动化正向循环
|
||||
|
||||
## Key Applications
|
||||
|
||||
- **[[custom-morning-brief]]**:利用夜间空闲时间让 AI 完成新闻研究和草稿生成,晨起直接收到完整简报
|
||||
- **[[earnings-tracker]]**:每周日自动扫描财报日历,用户选择后为每家公司创建一次性 Job
|
||||
- **[[self-healing-home-server]]**:Reef Agent 的 24/7 全天候自动化(每15分钟健康检查、每小时监控)
|
||||
- **[[multi-agent-team]]**:多个 Agent 定时轮转,主动向用户推送成果
|
||||
|
||||
## Key Insight
|
||||
|
||||
> "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." — 自定义晨间简报的核心洞察
|
||||
|
||||
## Why "Flywheel"
|
||||
|
||||
与被动等待指令的传统助手不同,飞轮模式下 AI **主动**创造价值。每次定时触发后:
|
||||
- 上下文积累 → 下次执行更精准
|
||||
- 模板成熟 → 输出质量持续提升
|
||||
- 用户习惯养成 → 简报成为每日必需
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Morning Briefing]] — 定时飞轮的具体应用场景
|
||||
- [[Proactive Agent Recommendation]] — 飞轮中"主动思考如何帮助用户"的关键能力
|
||||
- [[Single Control Plane]] — 飞轮与用户之间的统一交互界面
|
||||
57
wiki/concepts/Shared-Memory-Architecture.md
Normal file
57
wiki/concepts/Shared-Memory-Architecture.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Shared Memory Architecture"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Architecture, Memory]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Shared Memory Architecture** 是多 Agent 系统中,所有 Agent 共用一套公共记忆文件(GOALS.md、DECISIONS.md、PROJECT_STATUS.md),确保团队目标、关键决策和项目状态对所有 Agent 可见的架构模式。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "Shared memory + private context: The combination is critical — agents need common ground (goals, decisions) but also their own space to accumulate domain expertise"
|
||||
|
||||
共享记忆解决的问题:
|
||||
- **知识孤岛**:营销洞察不会自动影响开发优先级
|
||||
- **上下文丢失**:每个 Agent 独立会话无法继承团队决策
|
||||
- **重复工作**:Agent A 的发现对 Agent B 不可见
|
||||
|
||||
## 共享文件结构
|
||||
|
||||
```
|
||||
team/
|
||||
├── GOALS.md # 当前 OKR 和优先级(所有 Agent 读取)
|
||||
├── DECISIONS.md # 关键决策日志(追加写入)
|
||||
├── PROJECT_STATUS.md # 当前项目状态(所有 Agent 更新)
|
||||
├── agents/
|
||||
│ ├── milo/ # Milo 的私有上下文和笔记
|
||||
│ ├── josh/ # Josh 的私有上下文
|
||||
│ ├── marketing/ # 营销 Agent 的研究笔记
|
||||
│ └── dev/ # 开发 Agent 的技术笔记
|
||||
```
|
||||
|
||||
## 共享记忆类型
|
||||
|
||||
| 文件 | 用途 | 写入规则 |
|
||||
|------|------|----------|
|
||||
| GOALS.md | 团队目标和 OKR | 定期更新(周/日) |
|
||||
| DECISIONS.md | 关键决策记录 | 决策时追加 |
|
||||
| PROJECT_STATUS.md | 项目当前状态 | 状态变更时更新 |
|
||||
|
||||
## 与 Private Context 的关系
|
||||
|
||||
**Shared Memory** + **Private Context** 组合是关键:
|
||||
- **Shared Memory**:共同基础(目标、决策、项目状态)
|
||||
- **Private Context**:独立空间积累领域专业知识
|
||||
- 两者缺一不可:只有共享记忆导致缺乏深度,只有私有上下文导致知识孤岛
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Agent-Memory]] — OpenClaw 的长期记忆机制
|
||||
- [[Private Context]] — Agent 私有上下文
|
||||
- [[OpenClaw]] — 提供 workspace 目录体系支持
|
||||
- [[Agent Specialization]] — 专业化 Agent 依赖共享记忆协调
|
||||
|
||||
59
wiki/concepts/SharedStateCoordination.md
Normal file
59
wiki/concepts/SharedStateCoordination.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Shared State Coordination"
|
||||
type: concept
|
||||
tags: [multi-agent, coordination, architecture]
|
||||
sources: [autonomous-project-management]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## 定义
|
||||
多 Agent 通过读写共享状态文件(而非消息传递)实现协调的通信范式。在 [[autonomous-project-management]] 中具体实现为共享的 `STATE.yaml` 文件。
|
||||
|
||||
## 核心机制
|
||||
- **单一真相来源**(Single Source of Truth):STATE.yaml 作为项目协调的单一事实来源
|
||||
- **文件读写协调**:各子 Agent 读取自己被分配的任务,写入进度/完成状态
|
||||
- **轮询自驱动**:Agent 主动轮询 STATE.yaml,发现任务解锁后自动拾取
|
||||
- **无需消息队列**:避免引入额外的消息传递中间件依赖
|
||||
|
||||
## STATE.yaml 结构示例
|
||||
```yaml
|
||||
project: website-redesign
|
||||
updated: 2026-02-10T14:30:00Z
|
||||
|
||||
tasks:
|
||||
- id: homepage-hero
|
||||
status: in_progress
|
||||
owner: pm-frontend
|
||||
notes: "Working on responsive layout"
|
||||
|
||||
- id: api-auth
|
||||
status: done
|
||||
owner: pm-backend
|
||||
output: "src/api/auth.ts"
|
||||
|
||||
- id: content-migration
|
||||
status: blocked
|
||||
owner: pm-content
|
||||
blocked_by: api-auth
|
||||
|
||||
next_actions:
|
||||
- "pm-content: Resume migration now that api-auth is done"
|
||||
```
|
||||
|
||||
## 优势
|
||||
- **去中心化**:无中心协调器,单点故障风险低
|
||||
- **版本可控**:Git 作为审计日志,完整可追溯
|
||||
- **简单可靠**:无需额外的消息队列或 RPC 中间件
|
||||
- **持久化**:状态天然持久,支持断点恢复
|
||||
|
||||
## 与消息传递模式对比
|
||||
| 维度 | 共享文件协调 | 消息传递协调 |
|
||||
|------|-------------|-------------|
|
||||
| 中间件依赖 | 仅文件系统 | 需要 MQ/Pub-Sub |
|
||||
| 状态持久性 | 天然持久 | 需要额外存储 |
|
||||
| 并发控制 | 文件锁 | 队列ACK |
|
||||
| 调试难度 | 高(需读文件) | 中(需追踪消息流) |
|
||||
| 适用场景 | 并行独立任务 | 有序依赖链 |
|
||||
|
||||
## 衍生概念
|
||||
- [[Git-as-Audit-Log]]:将所有 STATE.yaml 变更提交至 Git,获得完整历史
|
||||
67
wiki/concepts/Single-Control-Plane.md
Normal file
67
wiki/concepts/Single-Control-Plane.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Single Control Plane"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent, Architecture, Interface]
|
||||
sources: [multi-agent-team]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
**Single Control Plane** 是多 Agent 系统中,通过单一消息接口(如 Telegram 分组)统一接入所有 Agent,每个 Agent 仅在收到特定标签时响应的架构设计。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
> "Single control plane: All agents are accessible through one Telegram group chat — tag the agent you need"
|
||||
|
||||
单一控制平面的价值:
|
||||
- **降低使用门槛**:用户只需在一个地方与团队互动
|
||||
- **统一入口**:不需要记住多个 Agent 的独立接口
|
||||
- **自然协作**:像在团队群组中与不同成员对话
|
||||
|
||||
## Telegram 路由配置
|
||||
|
||||
```
|
||||
Telegram group: "Team"
|
||||
|
||||
Routing:
|
||||
- @milo → Strategy agent (spawns/resumes milo session)
|
||||
- @josh → Business agent (spawns/resumes josh session)
|
||||
- @marketing → Marketing agent (spawns/resumes marketing session)
|
||||
- @dev → Dev agent (spawns/resumes dev session)
|
||||
- @all → Broadcast to all agents
|
||||
- No tag → Milo (team lead) handles by default
|
||||
|
||||
Each agent:
|
||||
1. Reads shared GOALS.md and PROJECT_STATUS.md for context
|
||||
2. Reads its own private notes
|
||||
3. Processes the message
|
||||
4. Responds in Telegram
|
||||
5. Updates shared files if the response involves a decision or status change
|
||||
```
|
||||
|
||||
## Agent 处理流程
|
||||
|
||||
每个 Agent 收到消息时的标准处理流程:
|
||||
|
||||
1. **读取共享上下文**:GOALS.md 和 PROJECT_STATUS.md
|
||||
2. **读取私有笔记**:自己的 agents/<name>/ 目录
|
||||
3. **处理消息**:结合上下文和专业知识
|
||||
4. **响应 Telegram**:在群组中回复
|
||||
5. **更新共享文件**:如有决策或状态变更
|
||||
|
||||
## 与其他接口模式的对比
|
||||
|
||||
| 模式 | 描述 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| **Single Control Plane** | 统一入口 + 标签路由 | 团队协作、多 Agent 协调 |
|
||||
| **独立接口** | 每个 Agent 独立通道 | 简单任务、专业工具 |
|
||||
| **网页界面** | Web UI 控制台 | 监控和管理 |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[OpenClaw]] — 提供 sessions_spawn/sessions_send 能力
|
||||
- [[Telegram]] — 常用作控制平面的消息平台
|
||||
- [[Multi-Agent Coordination]] — 协调多 Agent 的机制
|
||||
- [[Agent Specialization]] — 专业化 Agent 便于标签路由
|
||||
|
||||
37
wiki/concepts/Startup-MVP-Pipeline.md
Normal file
37
wiki/concepts/Startup-MVP-Pipeline.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Startup MVP Pipeline"
|
||||
type: concept
|
||||
tags: [startup, agentic-ai, mvp, product-building]
|
||||
sources: [market-research-product-factory]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Startup MVP Pipeline(创业最小可行产品流水线)是从市场机会发现到可演示产品原型的端到端自动化流程——用 AI Agent 替代人工完成"调研→验证→构建→交付"全链路。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
1. **Pain Point Mining**:从 Reddit/X 挖掘真实用户痛点(按频率排序)
|
||||
2. **Opportunity Validation**:分析现有方案缺口,确定未被满足的需求
|
||||
3. **MVP Specification**:用自然语言描述要解决的问题,AI 自动生成产品需求
|
||||
4. **Automated Build**:AI Agent(OpenClaw)根据需求构建 Web 应用原型
|
||||
5. **Delivery**:生成的 Web 应用可直接分享给用户验证
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **全自动化**:用户只需发一条消息,即可获得可演示的 Web 应用
|
||||
- **无技术门槛**:无需编程能力,OpenClaw 承担所有构建职责
|
||||
- **快速迭代**:发现痛点 → 构建原型 → 用户验证,周期以小时计
|
||||
- **持续监控**:可定期调度调研,持续追踪市场痛点演化
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Pain Point Mining]] → 供给数据 → [[Startup MVP Pipeline]]
|
||||
- [[Agent-Driven Market Research]] → 提供方法论 → [[Startup MVP Pipeline]]
|
||||
- [[content-factory]] ← extends ← [[Startup MVP Pipeline]]:内容工厂延伸为产品工厂
|
||||
- [[product-trend-researcher]] ← depends_on ← [[Last 30 Days Method]] → 支持 [[Startup MVP Pipeline]]
|
||||
|
||||
## Sources
|
||||
|
||||
- [[market-research-product-factory]]
|
||||
25
wiki/concepts/Telephony-Integration.md
Normal file
25
wiki/concepts/Telephony-Integration.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Telephony Integration"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Telephony Integration(电话能力集成)
|
||||
|
||||
## Definition
|
||||
电话能力集成指 AI Agent 框架通过电信 API 实现来电接收和去电呼叫的能力,使 AI Agent 能够通过传统电话网络与用户通信,无需依赖智能手机 App 或互联网连接。
|
||||
|
||||
## Implementation Pattern
|
||||
1. **电信 API**:通过 [[Telnyx]] 等提供商获取电话号码和电话连接
|
||||
2. **客户端库**:通过 [[ClawdTalk]] 等客户端库与 Agent 框架对接
|
||||
3. **Agent 框架**:[[OpenClaw]] 等支持 phone skill 的多 Agent 框架
|
||||
4. **语音处理**:实时语音流与 Agent 的对话能力结合
|
||||
|
||||
## Use Cases
|
||||
- **来电接收**:用户主动拨打,接听并与 AI 对话
|
||||
- **去电外呼**:Agent 主动拨打电话(参见 [[event-guest-confirmation]] 中的 [[SuperCall]] 方案)
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
39
wiki/concepts/Topic-Based-Routing.md
Normal file
39
wiki/concepts/Topic-Based-Routing.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Topic-Based Routing"
|
||||
type: concept
|
||||
tags: [Routing, Telegram, Multi-Context, OpenClaw]
|
||||
sources: [multi-channel-assistant]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Topic-Based Routing
|
||||
|
||||
## Definition
|
||||
Topic-Based Routing(基于话题的路由)是一种通过标签/话题机制将用户请求分发到不同上下文处理单元的设计模式。在 [[multi-channel-assistant]] 中,通过 Telegram Topic 实现多上下文隔离。
|
||||
|
||||
## Mechanism
|
||||
用户在不同 Telegram Topic 中发送消息,OpenClaw 根据 Topic 标签识别上下文域:
|
||||
|
||||
| Topic | 处理的上下文 |
|
||||
|-------|------------|
|
||||
| `config` | 系统设置、调试 |
|
||||
| `updates` | 日报摘要、定时提醒、日历 |
|
||||
| `video-ideas` | 内容管线、研究 |
|
||||
| `personal-crm` | 联系人和会议准备 |
|
||||
| `earnings` | 财务追踪 |
|
||||
| `knowledge-base` | 知识库存取与检索 |
|
||||
|
||||
## Key Properties
|
||||
- **上下文隔离**:每个 Topic 携带独立的记忆上下文,不会跨 Topic 污染
|
||||
- **单一入口**:用户只需记住 Telegram 一个入口,不需要切换多个 App
|
||||
- **意图推断**:通过 Topic 标签帮助 LLM 理解用户当前关注域,降低提示词复杂度
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Tool Integration]] — Topic Routing 是触发不同工具集的前提
|
||||
- [[Single Control Plane]] — Telegram 作为统一控制平面的实现方式
|
||||
- [[Scheduled Reminder]] — `updates` Topic 承载主动提醒推送
|
||||
|
||||
## Connections
|
||||
- [[multi-channel-assistant]] — Topic-Based Routing 的应用场景
|
||||
- [[OpenClaw]] — 路由逻辑的执行引擎
|
||||
- [[Telegram]] — 路由机制的载体平台
|
||||
25
wiki/concepts/Voice-Interface.md
Normal file
25
wiki/concepts/Voice-Interface.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Voice Interface"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Voice Interface(语音接口)
|
||||
|
||||
## Definition
|
||||
语音接口是通过电话等语音通道与 AI Agent 进行交互的接口层。相比文字入口(如 Telegram、Slack),语音接口无需屏幕或键盘,覆盖驾驶、步行、双手占用等场景。
|
||||
|
||||
## Characteristics
|
||||
- **免提交互**:用户无需盯着屏幕或使用键盘
|
||||
- **场景覆盖**:驾驶、步行、双手忙碌时
|
||||
- **输入限制**:语音输入的信息密度低于文字(无法精确指定参数)
|
||||
- **输出优化**:需要将结构化信息转译为自然语言表述
|
||||
|
||||
## Related Concepts
|
||||
- [[Telephony Integration]]:语音接口的底层电话能力集成
|
||||
- [[Multi-Tool Integration]]:语音接口通常需要 Calendar/Jira/Web Search 等多工具配合才能提供完整价值
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
29
wiki/entities/Alex-Finn.md
Normal file
29
wiki/entities/Alex-Finn.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Alex Finn"
|
||||
type: entity
|
||||
tags: [content-creator, openclaw-community]
|
||||
sources: [market-research-product-factory, content-factory, custom-morning-brief]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Alex Finn 是 OpenClaw 社区的内容创作者和资深用户,通过 YouTube 视频分享 OpenClaw 高阶用法,推动了多个 OpenClaw 自动化工作流的流行。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Alex Finn
|
||||
- Alex Finn (OpenClaw YouTuber)
|
||||
|
||||
## Role in System
|
||||
|
||||
- 通过 YouTube 视频激发了 [[market-research-product-factory]] 和 [[custom-morning-brief]] 等工作流的实践
|
||||
- 其视频内容是 OpenClaw 社区高阶用法的重要传播渠道
|
||||
- 专注于展示 AI Agent 在个人生产力场景中的实际应用价值
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — Alex Finn 的主要研究和推广对象
|
||||
- [[market-research-product-factory]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[custom-morning-brief]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[content-factory]] — 受 Alex Finn 视频启发的 Discord 多 Agent 内容工厂
|
||||
28
wiki/entities/Asana.md
Normal file
28
wiki/entities/Asana.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Asana"
|
||||
type: entity
|
||||
tags: [productivity, task-management, collaboration]
|
||||
sources: [multi-channel-assistant, custom-morning-brief]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Asana 是一个企业级工作管理平台,支持项目追踪、团队协作和任务管理,被 OpenClaw 多 Agent 工作流广泛集成作为任务数据来源。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Asana
|
||||
- asana
|
||||
|
||||
## Role in System
|
||||
|
||||
- 作为 [[OpenClaw]] Agent 工作流的标准任务集成目标之一(与 Todoist / Apple Reminders 并列)
|
||||
- 在 [[custom-morning-brief]] 中用于拉取当日待办事项,纳入晨间简报
|
||||
- 在 [[multi-channel-assistant]] 中作为统一任务管理后端
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — 集成 Asana 作为任务管理后端
|
||||
- [[Todoist]] — Asana 的竞品,同为待办列表集成选项
|
||||
- [[Apple Reminders]] — Asana 的竞品,同为待办列表集成选项
|
||||
@@ -52,6 +52,6 @@ Calibre 是功能最强大的开源电子书库管理工具,支持电子书格
|
||||
## Related Entities
|
||||
- [[Synology NAS DS718]] — 部署宿主
|
||||
- [[RackNerd]] — 公网 VPS(Caddy)
|
||||
- [[FRP]] — 内网穿透机制
|
||||
- [[frp]] — 内网穿透机制
|
||||
- [[Jellyfin]] — 视频媒体服务(同一 NAS)
|
||||
- [[Navidrome]] — 音乐流媒体服务(同一 NAS)
|
||||
|
||||
33
wiki/entities/ClawdTalk.md
Normal file
33
wiki/entities/ClawdTalk.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "ClawdTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# ClawdTalk
|
||||
|
||||
## Overview
|
||||
ClawdTalk 是由 Telnyx 团队出品的电话集成客户端库([@team-telnyx/clawdtalk-client](https://github.com/team-telnyx/clawdtalk-client)),使 [[OpenClaw]] 能够接收和拨打电话,将任意手机变成 AI 助理的语音入口。
|
||||
|
||||
## Core Functions
|
||||
- **来电接收**:AI Agent 可接收用户拨打的电话
|
||||
- **去电发起**:AI Agent 可主动拨打电话联系用户
|
||||
- **语音对话**:通过电话实现与 AI Agent 的实时语音交互
|
||||
|
||||
## Architecture
|
||||
- 作为 [[OpenClaw]] 的电话技能(phone skill)集成
|
||||
- 底层依赖 [[Telnyx]] API 提供电信连接
|
||||
- 属于 [[OpenClaw Skills]] 生态,通过 OpenClaw 的 skills 接口调用
|
||||
|
||||
## Related Links
|
||||
- [ClawdTalk Website](https://clawdtalk.com)
|
||||
- [ClawdTalk GitHub](https://github.com/team-telnyx/clawdtalk-client)
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
|
||||
## Aliases
|
||||
- clawdtalk
|
||||
- ClawdTalk Client
|
||||
33
wiki/entities/Gitea.md
Normal file
33
wiki/entities/Gitea.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Gitea"
|
||||
type: entity
|
||||
tags: [git, self-hosted, github-alternative, devops]
|
||||
sources: [self-healing-home-server]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gitea
|
||||
- gitea
|
||||
|
||||
## Definition
|
||||
Gitea 是一个开源、轻量级的自托管 Git 服务(GitHub/GitLab 替代方案),使用 Go 语言编写,最低硬件要求极低(512MB RAM)。支持 Git 仓库管理、Issue 追踪、Pull Request、Wiki、CI/CD(Actions)等完整功能。
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 安全架构中,Gitea 作为**本地优先 Git 仓库**:
|
||||
- 作为私有代码中转站(推送到公共 GitHub 前的 CI 扫描_gate)
|
||||
- CI pipeline 运行 TruffleHog 等 secrets scanning 工具
|
||||
- Human review required before main branch merges
|
||||
- 防止 Agent 直接暴露 API keys 到公共仓库
|
||||
|
||||
## Security Role
|
||||
Gitea 在 [[Local-first Git]] 工作流中的位置:
|
||||
```
|
||||
Agent → commits → Gitea (private) → CI scan (TruffleHog) → Human review → GitHub (public)
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[Local-first Git]] — Gitea 作为私有中转的核心基础设施
|
||||
- [[OpenClaw]] — Agent 代码托管和工作流编排平台
|
||||
- [[TruffleHog]] — Gitea CI pipeline 中运行的 secrets scanning 工具
|
||||
- [[Defense-in-Depth]] — Gitea 是多层安全防御架构的一环
|
||||
32
wiki/entities/K3s.md
Normal file
32
wiki/entities/K3s.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "K3s"
|
||||
type: entity
|
||||
tags: [kubernetes, container, orchestration, open-source]
|
||||
sources: [self-healing-home-server]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- K3s
|
||||
- k3s
|
||||
|
||||
## Definition
|
||||
K3s 是一个轻量级的 Kubernetes 发行版,由 Rancher Labs(现 SUSE)开发,专为边缘计算、资源受限环境和家庭实验室设计。相较于标准 Kubernetes,K3s 将所有控制平面组件打包为单一二进制文件,去除了 cloud provider 特化代码,默认使用 SQLite 作为存储后端,体积仅约 50MB。
|
||||
|
||||
## Core Features
|
||||
- **单二进制部署**:所有 K8s 组件打包为单一可执行文件
|
||||
- **轻量资源占用**:最低 512MB RAM 即可运行,适合树莓派和家庭服务器
|
||||
- **内置容器运行时**:默认使用 containerd,无需 Docker 依赖
|
||||
- **简化运维**:自动处理 TLS、滚动更新、指标收集
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 使用场景中,K3s 作为家庭 Kubernetes 集群,由 OpenClaw Agent "Reef" 通过 kubectl 管理。Agent 可自动化执行以下操作:
|
||||
- Pod 重启与健康检查
|
||||
- 资源扩缩容
|
||||
- 配置变更与 Rollback
|
||||
- 跨节点工作负载调度
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] — 通过 kubectl 管理 K3s 集群的 Agent 平台
|
||||
- [[Self-Healing-Systems]] — K3s 提供 Liveness/Readiness Probes 原生自愈能力
|
||||
- [[Infrastructure-as-Code]] — Agent 编写并应用 Kubernetes manifests
|
||||
20
wiki/entities/NicholasCarlini.md
Normal file
20
wiki/entities/NicholasCarlini.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Nicholas Carlini"
|
||||
type: entity
|
||||
tags: [ai-researcher, autonomous-agents]
|
||||
sources: [autonomous-project-management]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **职业**:AI 研究者
|
||||
- **研究领域**:自主编码 Agent、可扩展 AI 系统
|
||||
|
||||
## 核心观点
|
||||
- "Let agents self-organize rather than micromanaging them."
|
||||
- 让 Agent 自我组织,而非微观管理每个执行步骤
|
||||
- 这是 [[autonomous-project-management]] 去中心化协调模式的核心思想来源
|
||||
|
||||
## Aliases
|
||||
- Nicholas Carlini
|
||||
- N. Carlini
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "OpenClaw"
|
||||
type: entity
|
||||
tags: [OpenClaw, Agent, Workspace, Multi-Agent]
|
||||
sources: [万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest]
|
||||
sources: [multi-agent-team, 万字讲透openclaw-workspace深度解析-2026-03-21, 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录, daily-youtube-digest, self-healing-home-server, custom-morning-brief]
|
||||
last_updated: 2026-03-21
|
||||
---
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ RackNerd VPS 在整个家庭网络架构中扮演**公网网关**角色:
|
||||
|
||||
## Related Entities
|
||||
- [[Caddy]] — 自动HTTPS反向代理(VPS上运行)
|
||||
- [[FRP]] — 内网穿透工具(frps在VPS, frpc在各内网节点)
|
||||
- [[frp]] — 内网穿透工具(frps在VPS, frpc在各内网节点)
|
||||
- [[Cloudflare]] — DNS托管服务商
|
||||
- [[Synology NAS DS718]] — 内网NAS(frpc客户端之一)
|
||||
- [[Mac Mini M4]] — 主控节点(frpc客户端之一)
|
||||
|
||||
@@ -94,7 +94,7 @@ Synology NAS DS718 是群晖(Synology)推出的双盘位 NAS 设备,搭载
|
||||
- [[Zipline]] — 图床应用
|
||||
- [[MinIO]] — 对象存储
|
||||
- [[Caddy]] — 自动HTTPS反向代理(VPS运行)
|
||||
- [[FRP]] — 内网穿透(frps:VPS, frpc:NAS)
|
||||
- [[frp]] — 内网穿透(frps:VPS, frpc:NAS)
|
||||
- [[RackNerd]] — 公网VPS提供商
|
||||
- [[矿神源]] — 群晖第三方套件源(SPK格式)
|
||||
- [[阿里云盘]] — CloudDrive2的挂载目标
|
||||
|
||||
24
wiki/entities/Telnyx.md
Normal file
24
wiki/entities/Telnyx.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Telnyx"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Telnyx
|
||||
|
||||
## Overview
|
||||
Telnyx 是一家电信 API 提供商,提供可靠的全球电话连接服务。在 AI Agent 场景中,Telnyx API 为 [[ClawdTalk]] 提供底层电话能力支撑,使 [[OpenClaw]] 能够实现来电接收和去电呼叫。
|
||||
|
||||
## Key Products
|
||||
- **Telnyx Voice API**:全球 SIP 中继和电话号码管理
|
||||
- **电话连接**:支持来电接收(Inbound)和去电发起(Outbound)
|
||||
- **短信服务(即将)**:SMS 支持正在开发中
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
|
||||
## Aliases
|
||||
- Telnyx API
|
||||
- Telnyx.com
|
||||
@@ -1,35 +1,29 @@
|
||||
---
|
||||
title: "Todoist"
|
||||
type: entity
|
||||
tags: []
|
||||
tags: [productivity, task-management]
|
||||
sources: [multi-channel-assistant, custom-morning-brief, meeting-notes-action-items]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# Todoist
|
||||
## Definition
|
||||
|
||||
跨平台个人和团队任务管理工具,支持自然语言输入、标签、过滤器和协作功能。通过 API 可实现个人行动项的自动化管理,适合个人工作流和轻量级团队场景。
|
||||
|
||||
## Overview
|
||||
|
||||
Todoist 是 [[meeting-notes-action-items]] 和 [[todoist-task-manager]] 中的核心任务管理工具。Agent 从会议中提取的个人行动项可自动添加到 Todoist,设置截止日和提醒。
|
||||
Todoist 是一个跨平台待办事项管理工具,支持个人任务管理和团队协作,被 OpenClaw 多 Agent 工作流广泛集成作为任务数据来源。
|
||||
|
||||
## Aliases
|
||||
- Todoist 自然语言解析
|
||||
- Todoist API
|
||||
|
||||
## Capabilities
|
||||
- 自然语言任务创建("明天3点完成任务")
|
||||
- 项目/标签/过滤器层级
|
||||
- 团队协作(个人版/专业版/商业版)
|
||||
- REST API
|
||||
- 截止日和定时提醒
|
||||
- 与 Google Calendar 同步
|
||||
- Todoist
|
||||
- todoist
|
||||
|
||||
## Related Entities
|
||||
- [[Linear]] — 团队级替代
|
||||
- [[Jira]] — 企业级替代
|
||||
- [[Notion]] — 协作型知识管理
|
||||
## Role in System
|
||||
|
||||
## Related Sources
|
||||
- [[meeting-notes-action-items]]
|
||||
- [[todoist-task-manager]]
|
||||
- 作为 [[OpenClaw]] Agent 工作流的标准任务集成目标之一(与 Apple Reminders / Asana 并列)
|
||||
- 在 [[custom-morning-brief]] 中用于拉取当日待办事项,纳入晨间简报
|
||||
- 在 [[multi-channel-assistant]] 中作为统一任务管理后端
|
||||
- 在 [[meeting-notes-action-items]] 中用于自动创建会议行动项任务
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — 集成 Todoist 作为任务管理后端
|
||||
- [[Apple Reminders]] — Todoist 的竞品,同为待办列表集成选项
|
||||
- [[Asana]] — Todoist 的竞品,同为团队协作任务管理工具
|
||||
|
||||
38
wiki/entities/TruffleHog.md
Normal file
38
wiki/entities/TruffleHog.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "TruffleHog"
|
||||
type: entity
|
||||
tags: [security, secrets-detection, git, open-source]
|
||||
sources: [self-healing-home-server]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- TruffleHog
|
||||
- trufflehog
|
||||
- Truffle Hog
|
||||
|
||||
## Definition
|
||||
TruffleHog 是一个开源的 Git secrets scanning 工具,通过正则表达式和 entropy 分析检测 Git 仓库中的硬编码凭证(API keys、tokens、passwords、private keys 等)。支持 GitHub、GitLab、Gitea 等所有 Git 服务,是 DevSecOps 和 AI Agent 安全运营的必备工具。
|
||||
|
||||
## Core Features
|
||||
- **High-entropy 检测**:识别随机字符串形式的 API keys
|
||||
- **正则匹配**:识别常见凭证格式(AWS keys、Slack tokens、JWTs 等)
|
||||
- **Git 历史扫描**:扫描整个 Git 历史中的 secrets(og commit 检测)
|
||||
- **CI/CD 集成**:支持 GitHub Actions、GitLab CI、Gitea Actions 等
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 的安全 checklist 中,TruffleHog 是**第一道防线**:
|
||||
- **Pre-push hooks**:在 Agent commit 之前阻断包含 secrets 的代码
|
||||
- 配合 [[Gitea]] CI pipeline 使用
|
||||
- 与 [[1Password]] 专用 AI vault 共同构成纵深防御
|
||||
|
||||
## Critical Insight
|
||||
> "AI assistants will happily hardcode secrets. They sometimes don't have the same instincts humans do." — Nathan([[OpenClaw]] 用户)
|
||||
|
||||
AI Agent 在生成代码时倾向于直接写入 API keys,这是 AI Agent 基础设施安全的 #1 风险。TruffleHog pre-push hooks 是**必须配置**的防线。
|
||||
|
||||
## Connections
|
||||
- [[Defense-in-Depth]] — TruffleHog 作为多层安全防御的第一环
|
||||
- [[Local-first Git]] — 与 Gitea 配合实现安全 Git 工作流
|
||||
- [[1Password]] — Agent secrets 的安全存储方案
|
||||
- [[OpenClaw]] — 需要 TruffleHog 保护的 Agent 平台
|
||||
27
wiki/entities/gog.md
Normal file
27
wiki/entities/gog.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "gog"
|
||||
type: entity
|
||||
tags: [gog, Google Workspace, CLI, OpenClaw]
|
||||
sources: [multi-channel-assistant]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# gog
|
||||
|
||||
## Overview
|
||||
gog 是一个 Google Workspace CLI 工具,支持通过命令行操作 Gmail、Google Calendar 和 Google Drive。在 [[multi-channel-assistant]] 中作为 OpenClaw 与 Google Workspace 集成的核心工具。
|
||||
|
||||
## Capabilities
|
||||
- **Gmail**:发送、读取、搜索邮件
|
||||
- **Calendar**:创建日历事件、查询日程
|
||||
- **Drive**:上传和管理文件
|
||||
|
||||
## Role in OpenClaw Workflow
|
||||
- "Schedule [event]" → 使用 `gog calendar`
|
||||
- "Email [person] about [topic]" → 使用 `gog gmail`
|
||||
- "Upload [file] to Drive" → 使用 `gog drive`
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] — 通过命令行调用 gog
|
||||
- [[Google-Workspace]] — gog 的集成目标
|
||||
- [[multi-channel-assistant]] — 依赖 gog 实现 Google 生态集成
|
||||
66
wiki/entities/idea-reality-mcp.md
Normal file
66
wiki/entities/idea-reality-mcp.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "idea-reality-mcp"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
基于 [[MCP(Model Context Protocol)]] 的竞争分析 MCP 服务器,在 AI 项目启动前扫描 GitHub、Hacker News、npm、PyPI、Product Hunt 五个真实数据源,返回 `reality_signal` 分数(0-100)评估赛道拥挤度,并提供竞品信息和转向建议。
|
||||
|
||||
## Type
|
||||
产品 / MCP Server
|
||||
|
||||
## Installation
|
||||
```bash
|
||||
uvx idea-reality-mcp
|
||||
```
|
||||
|
||||
## Configuration (OpenClaw)
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"idea-reality": {
|
||||
"command": "uvx",
|
||||
"args": ["idea-reality-mcp"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## API: `idea_check()`
|
||||
输入:项目想法描述(字符串)
|
||||
输出:
|
||||
- `reality_signal`:0-100 拥挤度评分
|
||||
- `top_competitors`:竞品列表(含 stars、描述)
|
||||
- `pivot_hints`:转向建议
|
||||
|
||||
## Usage Rules (OpenClaw Instructions)
|
||||
```
|
||||
Before starting any new project, feature, or tool, always run idea_check first.
|
||||
|
||||
Rules:
|
||||
- If reality_signal > 70: STOP. Report top 3 competitors with star counts.
|
||||
Ask if I want to proceed, pivot, or abandon.
|
||||
- If reality_signal 30-70: Show results and pivot_hints.
|
||||
Suggest a niche angle that existing projects don't cover.
|
||||
- If reality_signal < 30: Proceed to build.
|
||||
Mention that the space is open.
|
||||
- Always show the reality_signal score and top competitors before writing any code.
|
||||
```
|
||||
|
||||
## Data Sources
|
||||
- GitHub(仓库数量、Star 分布)
|
||||
- Hacker News(讨论热度)
|
||||
- npm(Node.js 包生态)
|
||||
- PyPI(Python 包生态)
|
||||
- Product Hunt(早期产品关注度)
|
||||
|
||||
## Related
|
||||
- [[Pre-Build Validation]]
|
||||
- [[Competition-Analysis]]
|
||||
- [[MCP(Model Context Protocol)]]
|
||||
- [[OpenClaw]]
|
||||
- [GitHub](https://github.com/mnemox-ai/idea-reality-mcp)
|
||||
- [PyPI](https://pypi.org/project/idea-reality-mcp/)
|
||||
- [Web Demo](https://mnemox.ai/check)
|
||||
@@ -4,6 +4,20 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-22] [Pre-Build Idea Validator](sources/pre-build-idea-validator.md) — AI 项目启动前的竞争分析门控机制,通过 MCP 扫描 GitHub/HN/npm/PyPI/Product Hunt 评估赛道拥挤度
|
||||
- [2026-04-22] [Autonomous Project Management with Subagents](sources/autonomous-project-management.md)
|
||||
- [2026-04-22] [Daily Reddit Digest](sources/daily-reddit-digest.md)
|
||||
- [2026-04-22] [Inbox De-clutter](sources/inbox-declutter.md)
|
||||
- [2026-04-22] [Custom Morning Brief](sources/custom-morning-brief.md)
|
||||
- [2026-04-22] [Market Research & Product Factory](sources/market-research-product-factory.md)
|
||||
- [2026-04-22] [Phone-Based Personal Assistant](sources/phone-based-personal-assistant.md)
|
||||
- [2026-04-22] [Event Guest Confirmation](sources/event-guest-confirmation.md)
|
||||
- [2026-04-22] [Multi-Channel Personal Assistant](sources/multi-channel-assistant.md)
|
||||
- [2026-04-22] [AI-Powered Earnings Tracker](sources/earnings-tracker.md)
|
||||
- [2026-04-22] [Multi-Agent Specialized Team (Solo Founder Setup)](sources/multi-agent-team.md)
|
||||
- [2026-04-22] [Project State Management System: Event-Driven Alternative to Kanban](sources/project-state-management.md)
|
||||
- [2026-04-22] [Health & Symptom Tracker](sources/health-symptom-tracker.md)
|
||||
- [2026-04-22] [Self-Healing Home Server & Infrastructure Management](sources/self-healing-home-server.md)
|
||||
- [2026-04-22] [Multi-Agent Content Factory](sources/content-factory.md)
|
||||
- [2026-04-22] [Daily YouTube Digest](sources/daily-youtube-digest.md)
|
||||
- [2026-04-22] [Automated Meeting Notes & Action Items](sources/meeting-notes-action-items.md)
|
||||
@@ -11,7 +25,7 @@
|
||||
- [2026-04-22] [Claude Code 调用方法总结](sources/claude-code调用方法总结.md)
|
||||
- [2026-04-22] [N8N Full Tutorial Building AI Agents in 2025 for Beginners!](sources/n8n-full-tutorial-building-ai-agents-in-2025-for-beginners.md)
|
||||
- [2026-04-22] [n8n + Claude:通过自然语言自动化工作流](sources/n8n-claude-通过自然语言自动化工作流.md)
|
||||
- [2026-04-22] [万字保姆级教程,让你90天跑通"一人公司"模式(附AI提示词)](sources/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md)
|
||||
- [2026-04-22] [万字保姆级教程,让你90天跑通一人公司模式(附AI提示词)](sources/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md)
|
||||
- [2026-04-22] [使用Claude自动生成N8N工作流的实操教程](sources/使用claude自动生成n8n工作流的实操教程.md)
|
||||
- [2026-04-22] [MCP在Cursor中的集成与应用详解](sources/mcp在cursor中的集成与应用详解.md)
|
||||
- [2026-04-22] [Google 5个 Agent Skill 设计模式](sources/google-5个agent-skill设计模式-2026-03-19.md)
|
||||
@@ -20,7 +34,7 @@
|
||||
- [2026-04-22] [万字讲透OpenClaw Workspace深度解析](sources/万字讲透openclaw-workspace深度解析-2026-03-21.md)
|
||||
- [2026-04-22] [How to get Youtube Channel ID](sources/how-to-get-youtube-channel-id.md)
|
||||
- [2026-04-22] [TikTok PM - Python Django 项目](sources/tiktok-pm-python-django-project.md)
|
||||
- [2026-04-22] [Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器](sources/dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1.md)
|
||||
- [2026-04-22] [Dataview——让我从笔记黑洞里逃出来的 Obsidian 神器](sources/dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1.md)
|
||||
- [2026-04-22] [Obsidian 高效指南:我常用的插件与实用技巧](sources/obsidian-高效指南-我常用的插件与实用技巧.md)
|
||||
- [2026-04-22] [Obsidian最有必要安装的10款插件是这些](sources/obsidian最有必要安装的10款插件是这些.md)
|
||||
- [2026-04-22] [Obsidian Tasks 插件:这可能是最适合懒人的任务管理方式](sources/obsidian-tasks-插件-这可能是最适合懒人的任务管理方式.md)
|
||||
@@ -104,7 +118,6 @@
|
||||
- [2026-04-21] [marketing-social-media-strategist](sources/marketing-social-media-strategist.md) — (expected: wiki/sources/marketing-social-media-strategist.md — source missing)
|
||||
- [2026-04-21] [todoist-task-manager](sources/todoist-task-manager.md) — (expected: wiki/sources/todoist-task-manager.md — source missing)
|
||||
- [2026-04-21] [marketing-kuaishou-strategist](sources/marketing-kuaishou-strategist.md) — (expected: wiki/sources/marketing-kuaishou-strategist.md — source missing)
|
||||
- [2026-04-21] [project-state-management](sources/project-state-management.md) — (expected: wiki/sources/project-state-management.md — source missing)
|
||||
- [2026-04-21] [marketing-video-optimization-specialist](sources/marketing-video-optimization-specialist.md) — (expected: wiki/sources/marketing-video-optimization-specialist.md — source missing)
|
||||
- [2026-04-21] [marketing-instagram-curator](sources/marketing-instagram-curator.md) — (expected: wiki/sources/marketing-instagram-curator.md — source missing)
|
||||
- [2026-04-21] [marketing-china-ecommerce-operator](sources/marketing-china-ecommerce-operator.md) — (expected: wiki/sources/marketing-china-ecommerce-operator.md — source missing)
|
||||
@@ -402,18 +415,6 @@
|
||||
- [2026-04-17] [habit-tracker-accountability-coach](sources/habit-tracker-accountability-coach.md) — (expected: wiki/sources/habit-tracker-accountability-coach.md — source missing)
|
||||
- [2026-04-17] [dynamic-dashboard](sources/dynamic-dashboard.md) — (expected: wiki/sources/dynamic-dashboard.md — source missing)
|
||||
- [2026-04-17] [pre-build-idea-validator](sources/pre-build-idea-validator.md) — (expected: wiki/sources/pre-build-idea-validator.md — source missing)
|
||||
- [2026-04-17] [autonomous-project-management](sources/autonomous-project-management.md) — (expected: wiki/sources/autonomous-project-management.md — source missing)
|
||||
- [2026-04-17] [daily-reddit-digest](sources/daily-reddit-digest.md) — (expected: wiki/sources/daily-reddit-digest.md — source missing)
|
||||
- [2026-04-17] [inbox-declutter](sources/inbox-declutter.md) — (expected: wiki/sources/inbox-declutter.md — source missing)
|
||||
- [2026-04-17] [custom-morning-brief](sources/custom-morning-brief.md) — (expected: wiki/sources/custom-morning-brief.md — source missing)
|
||||
- [2026-04-17] [market-research-product-factory](sources/market-research-product-factory.md) — (expected: wiki/sources/market-research-product-factory.md — source missing)
|
||||
- [2026-04-17] [phone-based-personal-assistant](sources/phone-based-personal-assistant.md) — (expected: wiki/sources/phone-based-personal-assistant.md — source missing)
|
||||
- [2026-04-17] [event-guest-confirmation](sources/event-guest-confirmation.md) — (expected: wiki/sources/event-guest-confirmation.md — source missing)
|
||||
- [2026-04-17] [multi-channel-assistant](sources/multi-channel-assistant.md) — (expected: wiki/sources/multi-channel-assistant.md — source missing)
|
||||
- [2026-04-17] [earnings-tracker](sources/earnings-tracker.md) — (expected: wiki/sources/earnings-tracker.md — source missing)
|
||||
- [2026-04-17] [multi-agent-team](sources/multi-agent-team.md) — (expected: wiki/sources/multi-agent-team.md — source missing)
|
||||
- [2026-04-17] [health-symptom-tracker](sources/health-symptom-tracker.md) — (expected: wiki/sources/health-symptom-tracker.md — source missing)
|
||||
- [2026-04-17] [self-healing-home-server](sources/self-healing-home-server.md) — (expected: wiki/sources/self-healing-home-server.md — source missing)
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
@@ -539,10 +540,12 @@
|
||||
- [Agentic-AI](entities/Agentic-AI.md)
|
||||
- [aitmpl.com](entities/aitmpl.com.md)
|
||||
- [Alertmanager](entities/Alertmanager.md)
|
||||
- [Alex-Finn](entities/Alex-Finn.md)
|
||||
- [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md)
|
||||
- [Amazon-EventBridge](entities/Amazon-EventBridge.md)
|
||||
- [Anthropic](entities/Anthropic.md)
|
||||
- [Apache-Superset](entities/Apache-Superset.md)
|
||||
- [Asana](entities/Asana.md)
|
||||
- [AWS](entities/AWS.md)
|
||||
- [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md)
|
||||
- [AWS-Organizations](entities/AWS-Organizations.md)
|
||||
@@ -552,10 +555,12 @@
|
||||
- [BMC](entities/BMC.md)
|
||||
- [bottom](entities/bottom.md)
|
||||
- [btop++](entities/btop++.md)
|
||||
- [Caddy](entities/Caddy.md)
|
||||
- [cAdvisor](entities/cAdvisor.md)
|
||||
- [Calibre](entities/Calibre.md)
|
||||
- [Claude-Desktop](entities/Claude-Desktop.md)
|
||||
- [Claude-Pro](entities/Claude-Pro.md)
|
||||
- [ClawdTalk](entities/ClawdTalk.md)
|
||||
- [ClawHub](entities/ClawHub.md)
|
||||
- [Clonezilla](entities/Clonezilla.md)
|
||||
- [cloud-computing](entities/cloud-computing.md)
|
||||
@@ -574,8 +579,11 @@
|
||||
- [Docker-Network](entities/Docker-Network.md)
|
||||
- [Docker卷](entities/Docker卷.md)
|
||||
- [DORA-Metrics](entities/DORA-Metrics.md)
|
||||
- [frp](entities/frp.md)
|
||||
- [GDPR](entities/GDPR.md)
|
||||
- [Gitea](entities/Gitea.md)
|
||||
- [glances](entities/glances.md)
|
||||
- [gog](entities/gog.md)
|
||||
- [Google-Cloud](entities/Google-Cloud.md)
|
||||
- [GoogleCloud](entities/GoogleCloud.md)
|
||||
- [Grafana](entities/Grafana.md)
|
||||
@@ -588,10 +596,12 @@
|
||||
- [it-tools](entities/it-tools.md)
|
||||
- [Jellyfin](entities/Jellyfin.md)
|
||||
- [Jira](entities/Jira.md)
|
||||
- [K3s](entities/K3s.md)
|
||||
- [KoolCenter固件服务器](entities/KoolCenter固件服务器.md)
|
||||
- [Kubernetes](entities/Kubernetes.md)
|
||||
- [LaunchDarkly](entities/LaunchDarkly.md)
|
||||
- [Linear](entities/Linear.md)
|
||||
- [LinuxServer.io](entities/LinuxServer.io.md)
|
||||
- [Mac-Mini-M4](entities/Mac-Mini-M4.md)
|
||||
- [MariaDB](entities/MariaDB.md)
|
||||
- [MCP(Model Context Protocol)](entities/MCP(Model Context Protocol).md)
|
||||
@@ -602,6 +612,7 @@
|
||||
- [n8n-mcp](entities/n8n-mcp.md)
|
||||
- [Navidrome](entities/Navidrome.md)
|
||||
- [Netdata](entities/Netdata.md)
|
||||
- [NicholasCarlini](entities/NicholasCarlini.md)
|
||||
- [node-exporter](entities/node-exporter.md)
|
||||
- [Node.js](entities/Node.js.md)
|
||||
- [nodewarden](entities/nodewarden.md)
|
||||
@@ -622,10 +633,13 @@
|
||||
- [Slack](entities/Slack.md)
|
||||
- [stacer](entities/stacer.md)
|
||||
- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md)
|
||||
- [Telnyx](entities/Telnyx.md)
|
||||
- [Terraform](entities/Terraform.md)
|
||||
- [Todoist](entities/Todoist.md)
|
||||
- [Trae](entities/Trae.md)
|
||||
- [TranscriptAPI](entities/TranscriptAPI.md)
|
||||
- [Transmission](entities/Transmission.md)
|
||||
- [TruffleHog](entities/TruffleHog.md)
|
||||
- [Ubuntu-Server](entities/Ubuntu-Server.md)
|
||||
- [Uptime-Kuma](entities/Uptime-Kuma.md)
|
||||
- [Veeam](entities/Veeam.md)
|
||||
@@ -641,16 +655,21 @@
|
||||
|
||||
## Concepts
|
||||
- [ActionItemTracking](concepts/ActionItemTracking.md)
|
||||
- [Agent-Driven-Market-Research](concepts/Agent-Driven-Market-Research.md)
|
||||
- [Agent-Memory](concepts/Agent-Memory.md)
|
||||
- [Agent-Mode](concepts/Agent-Mode.md)
|
||||
- [Agent-Personality](concepts/Agent-Personality.md)
|
||||
- [Agent-Specialization](concepts/Agent-Specialization.md)
|
||||
- [AGENTS.md](concepts/AGENTS.md.md)
|
||||
- [AgilePractices](concepts/AgilePractices.md)
|
||||
- [AI-ChatOps](concepts/AI-ChatOps.md)
|
||||
- [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md)
|
||||
- [AIOps](concepts/AIOps.md)
|
||||
- [AI代理](concepts/AI代理.md)
|
||||
- [APT-仓库配置](concepts/APT-仓库配置.md)
|
||||
- [Asset-Management](concepts/Asset-Management.md)
|
||||
- [Attach容器](concepts/Attach容器.md)
|
||||
- [Automated-Health-Logging](concepts/Automated-Health-Logging.md)
|
||||
- [Automated-Security-Audit](concepts/Automated-Security-Audit.md)
|
||||
- [Availability](concepts/Availability.md)
|
||||
- [BindMount](concepts/BindMount.md)
|
||||
@@ -665,6 +684,7 @@
|
||||
- [caffeinate](concepts/caffeinate.md)
|
||||
- [Canary-Release](concepts/Canary-Release.md)
|
||||
- [Centralized-Logging](concepts/Centralized-Logging.md)
|
||||
- [CEOPattern](concepts/CEOPattern.md)
|
||||
- [Chained Agents](concepts/Chained Agents.md)
|
||||
- [Change-Failure-Rate](concepts/Change-Failure-Rate.md)
|
||||
- [Change-Management](concepts/Change-Management.md)
|
||||
@@ -699,6 +719,7 @@
|
||||
- [DAST](concepts/DAST.md)
|
||||
- [Data-Governance](concepts/Data-Governance.md)
|
||||
- [Data-Sovereignty](concepts/Data-Sovereignty.md)
|
||||
- [Defense-in-Depth](concepts/Defense-in-Depth.md)
|
||||
- [Deployment-Automation](concepts/Deployment-Automation.md)
|
||||
- [Deployment-vs-Release](concepts/Deployment-vs-Release.md)
|
||||
- [Design-to-Code-Workflow](concepts/Design-to-Code-Workflow.md)
|
||||
@@ -714,18 +735,25 @@
|
||||
- [DORA-Metrics](concepts/DORA-Metrics.md)
|
||||
- [DRaaS](concepts/DRaaS.md)
|
||||
- [DRY原则](concepts/DRY原则.md)
|
||||
- [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md)
|
||||
- [Earnings-Calendar](concepts/Earnings-Calendar.md)
|
||||
- [efibootmgr](concepts/efibootmgr.md)
|
||||
- [Email-Triage](concepts/Email-Triage.md)
|
||||
- [Error-Budget](concepts/Error-Budget.md)
|
||||
- [Event-Correlation](concepts/Event-Correlation.md)
|
||||
- [EventSourcing](concepts/EventSourcing.md)
|
||||
- [Exporter](concepts/Exporter.md)
|
||||
- [Extended Thinking](concepts/Extended Thinking.md)
|
||||
- [external配置](concepts/external配置.md)
|
||||
- [Failover](concepts/Failover.md)
|
||||
- [Feature-Flag](concepts/Feature-Flag.md)
|
||||
- [FinOps](concepts/FinOps.md)
|
||||
- [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md)
|
||||
- [Full-Draft-Generation](concepts/Full-Draft-Generation.md)
|
||||
- [Gatekeeper](concepts/Gatekeeper.md)
|
||||
- [GDM3](concepts/GDM3.md)
|
||||
- [Generator](concepts/Generator.md)
|
||||
- [GitAsAuditLog](concepts/GitAsAuditLog.md)
|
||||
- [GitOps](concepts/GitOps.md)
|
||||
- [GPG-密钥验证](concepts/GPG-密钥验证.md)
|
||||
- [Green-Computing](concepts/Green-Computing.md)
|
||||
@@ -749,11 +777,14 @@
|
||||
- [JFFS双清](concepts/JFFS双清.md)
|
||||
- [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md)
|
||||
- [Kill-Switch](concepts/Kill-Switch.md)
|
||||
- [Last-30-Days-Method](concepts/Last-30-Days-Method.md)
|
||||
- [launchd](concepts/launchd.md)
|
||||
- [Lead-Time](concepts/Lead-Time.md)
|
||||
- [Local-first-Git](concepts/Local-first-Git.md)
|
||||
- [MeetingNotes](concepts/MeetingNotes.md)
|
||||
- [MEMORY.md](concepts/MEMORY.md.md)
|
||||
- [Micro-Recovery](concepts/Micro-Recovery.md)
|
||||
- [Morning-Briefing](concepts/Morning-Briefing.md)
|
||||
- [MTTA](concepts/MTTA.md)
|
||||
- [MTTD](concepts/MTTD.md)
|
||||
- [MTTR](concepts/MTTR.md)
|
||||
@@ -767,22 +798,29 @@
|
||||
- [NVMe硬盘分区](concepts/NVMe硬盘分区.md)
|
||||
- [Obsidian-Tasks](concepts/Obsidian-Tasks.md)
|
||||
- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md)
|
||||
- [Pain-Point-Mining](concepts/Pain-Point-Mining.md)
|
||||
- [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md)
|
||||
- [passkey](concepts/passkey.md)
|
||||
- [Pay-as-you-go](concepts/Pay-as-you-go.md)
|
||||
- [Penetration-Testing](concepts/Penetration-Testing.md)
|
||||
- [Pipeline](concepts/Pipeline.md)
|
||||
- [Plan-Mode](concepts/Plan-Mode.md)
|
||||
- [PMDelegationPattern](concepts/PMDelegationPattern.md)
|
||||
- [pmset](concepts/pmset.md)
|
||||
- [Policy-as-Code](concepts/Policy-as-Code.md)
|
||||
- [Predictive-Maintenance](concepts/Predictive-Maintenance.md)
|
||||
- [Private-Cloud](concepts/Private-Cloud.md)
|
||||
- [Private-Context](concepts/Private-Context.md)
|
||||
- [Proactive-Agent-Recommendation](concepts/Proactive-Agent-Recommendation.md)
|
||||
- [Problem-Management](concepts/Problem-Management.md)
|
||||
- [process-management](concepts/process-management.md)
|
||||
- [Progressive-Rollout](concepts/Progressive-Rollout.md)
|
||||
- [ProjectState](concepts/ProjectState.md)
|
||||
- [Prometheus告警规则](concepts/Prometheus告警规则.md)
|
||||
- [PromQL](concepts/PromQL.md)
|
||||
- [proxychains](concepts/proxychains.md)
|
||||
- [Public-Cloud](concepts/Public-Cloud.md)
|
||||
- [PUID-PGID](concepts/PUID-PGID.md)
|
||||
- [Recurring-Task](concepts/Recurring-Task.md)
|
||||
- [Redis缓存](concepts/Redis缓存.md)
|
||||
- [Release-Management](concepts/Release-Management.md)
|
||||
@@ -797,34 +835,44 @@
|
||||
- [RPO](concepts/RPO.md)
|
||||
- [RTO](concepts/RTO.md)
|
||||
- [S3-兼容对象存储](concepts/S3-兼容对象存储.md)
|
||||
- [Sandboxed-Persona](concepts/Sandboxed-Persona.md)
|
||||
- [SAST](concepts/SAST.md)
|
||||
- [SCA](concepts/SCA.md)
|
||||
- [Scalability](concepts/Scalability.md)
|
||||
- [Scheduled-Reminder](concepts/Scheduled-Reminder.md)
|
||||
- [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md)
|
||||
- [Security-and-Compliance](concepts/Security-and-Compliance.md)
|
||||
- [Self-Healing-Systems](concepts/Self-Healing-Systems.md)
|
||||
- [self-hosted-password-manager](concepts/self-hosted-password-manager.md)
|
||||
- [Sequential-Thinking](concepts/Sequential-Thinking.md)
|
||||
- [Serverless-Computing](concepts/Serverless-Computing.md)
|
||||
- [Shared-Memory-Architecture](concepts/Shared-Memory-Architecture.md)
|
||||
- [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md)
|
||||
- [SharedStateCoordination](concepts/SharedStateCoordination.md)
|
||||
- [Shift-Left-Security](concepts/Shift-Left-Security.md)
|
||||
- [Shift-Right-Security](concepts/Shift-Right-Security.md)
|
||||
- [Single-Control-Plane](concepts/Single-Control-Plane.md)
|
||||
- [Socket-登录](concepts/Socket-登录.md)
|
||||
- [SOCKS5代理](concepts/SOCKS5代理.md)
|
||||
- [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md)
|
||||
- [SOUL.md](concepts/SOUL.md.md)
|
||||
- [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md)
|
||||
- [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md)
|
||||
- [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
|
||||
- [symbolic-link](concepts/symbolic-link.md)
|
||||
- [system-monitoring](concepts/system-monitoring.md)
|
||||
- [systemd](concepts/systemd.md)
|
||||
- [Task-Query](concepts/Task-Query.md)
|
||||
- [TaskAutomation](concepts/TaskAutomation.md)
|
||||
- [TCP隧道](concepts/TCP隧道.md)
|
||||
- [Telegram-Trigger](concepts/Telegram-Trigger.md)
|
||||
- [Telephony-Integration](concepts/Telephony-Integration.md)
|
||||
- [Threat-Modeling](concepts/Threat-Modeling.md)
|
||||
- [Time-to-Market](concepts/Time-to-Market.md)
|
||||
- [Tool-Calling](concepts/Tool-Calling.md)
|
||||
- [TOOLS.md](concepts/TOOLS.md.md)
|
||||
- [ToolWrapper](concepts/ToolWrapper.md)
|
||||
- [Topic-Based-Routing](concepts/Topic-Based-Routing.md)
|
||||
- [totp](concepts/totp.md)
|
||||
- [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md)
|
||||
- [TranscriptProcessing](concepts/TranscriptProcessing.md)
|
||||
@@ -834,6 +882,7 @@
|
||||
- [USER.md](concepts/USER.md.md)
|
||||
- [Vendor-Lock-In](concepts/Vendor-Lock-In.md)
|
||||
- [Vibe-Coding](concepts/Vibe-Coding.md)
|
||||
- [Voice-Interface](concepts/Voice-Interface.md)
|
||||
- [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md)
|
||||
- [Wake-on-LAN](concepts/Wake-on-LAN.md)
|
||||
- [Wayland](concepts/Wayland.md)
|
||||
@@ -850,7 +899,9 @@
|
||||
- [价格锚定与诱饵效应](concepts/价格锚定与诱饵效应.md)
|
||||
- [全盘镜像备份](concepts/全盘镜像备份.md)
|
||||
- [内容矩阵](concepts/内容矩阵.md)
|
||||
- [内网穿透](concepts/内网穿透.md)
|
||||
- [单一职责原则](concepts/单一职责原则.md)
|
||||
- [反向代理](concepts/反向代理.md)
|
||||
- [合成监控](concepts/合成监控.md)
|
||||
- [四个心理陷阱](concepts/四个心理陷阱.md)
|
||||
- [固件刷入](concepts/固件刷入.md)
|
||||
@@ -869,12 +920,14 @@
|
||||
- [故障转移](concepts/故障转移.md)
|
||||
- [数据可视化](concepts/数据可视化.md)
|
||||
- [时序数据库](concepts/时序数据库.md)
|
||||
- [桥接网络](concepts/桥接网络.md)
|
||||
- [模块化编程](concepts/模块化编程.md)
|
||||
- [永久挂载](concepts/永久挂载.md)
|
||||
- [消息队列](concepts/消息队列.md)
|
||||
- [版本控制](concepts/版本控制.md)
|
||||
- [用户权限](concepts/用户权限.md)
|
||||
- [硬件转码](concepts/硬件转码.md)
|
||||
- [端口映射](concepts/端口映射.md)
|
||||
- [策略组分流](concepts/策略组分流.md)
|
||||
- [系统睡眠管理](concepts/系统睡眠管理.md)
|
||||
- [虚拟信用卡](concepts/虚拟信用卡.md)
|
||||
|
||||
206
wiki/log.md
206
wiki/log.md
@@ -1,3 +1,176 @@
|
||||
## [2026-04-22] ingest | Pre-Build Idea Validator
|
||||
- Source file: Agent/usecases/pre-build-idea-validator.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI 项目启动前的竞争分析门控机制——在写代码之前通过 idea-reality-mcp 扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源,返回 reality_signal 分数(0-100)评估赛道拥挤度,防止 Agent 在已饱和赛道投入资源。
|
||||
- Concepts created: [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]]
|
||||
- Entities created: [[idea-reality-mcp]]
|
||||
- Source page: wiki/sources/pre-build-idea-validator.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入顶部)
|
||||
- 更新 overview.md,添加 pre-build-idea-validator 段落并补充 4 个新概念至 Key Concepts
|
||||
- 创建 5 个 Concept 页面:Pre-Build-Validation.md、Reality-Signal.md、Competition-Analysis.md、Pivot-Strategy.md、Agent-Build-Gate.md
|
||||
- 创建 1 个 Entity 页面:idea-reality-mcp.md
|
||||
- Hacker-News 和 Product-Hunt 仅出现 1 次,不满足 ≥2 次的 Entity 创建阈值,未创建
|
||||
- 与 market-research-product-factory 互补:后者挖痛点找方向,前者在动手前验证赛道的竞争密度
|
||||
- 冲突:无
|
||||
|
||||
## [2026-04-22] ingest | Autonomous Project Management with Subagents
|
||||
- Source file: Agent/usecases/autonomous-project-management.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 去中心化多 Agent 项目协调模式——通过共享 STATE.yaml 实现并行自主执行,主会话遵循 CEO 模式(仅做策略决策),Git 作为审计日志记录所有状态变更。核心洞察:文件协调优于中心编排器,主会话越薄响应越快。
|
||||
- Concepts created: [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]]
|
||||
- Entities created: [[Nicholas Carlini]]
|
||||
- Source page: wiki/sources/autonomous-project-management.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入顶部)
|
||||
- 更新 overview.md,添加 4 个新概念至 Key Concepts
|
||||
- 创建 4 个 Concept 页面:PMDelegationPattern.md、CEOPattern.md、SharedStateCoordination.md、GitAsAuditLog.md
|
||||
- 创建 1 个 Entity 页面:NicholasCarlini.md
|
||||
- 冲突记录:与 [[project-state-management]] 的任务管理范式冲突(动态文件 vs 静态看板)
|
||||
- Nicholas Carlini 未在原 Wiki 中出现,作为启发来源创建 Entity 页面
|
||||
|
||||
- Source file: Agent/usecases/daily-reddit-digest.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 OpenClaw + reddit-readonly skill,每日定时抓取多 Subreddit 热门帖子,AI 记忆偏好持续优化规则,纯读取模式无需认证。
|
||||
- Concepts created: [[Daily-Digest]], [[Reddit Read-Only]], [[Preference Learning]]
|
||||
- Entities created: [[reddit-readonly]]
|
||||
- Source page: wiki/sources/daily-reddit-digest.md
|
||||
- Notes:
|
||||
- 更新 index.md,替换缺失标记为正式条目
|
||||
- 更新 overview.md,添加至 YouTube Automation / Daily Digest 章节
|
||||
- OpenClaw Entity 页面已存在,无需新建
|
||||
- Preference Learning Concept 已在 inbox-declutter 中引用,无需新建
|
||||
|
||||
## [2026-04-22] ingest | Inbox De-clutter
|
||||
- Source file: Agent/usecases/inbox-declutter.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 每日自动整理 Newsletter 邮件摘要——通过 Cron Job 每日 20:00 阅读过去 24 小时 Newsletter 新邮件,生成精华摘要并附链接,根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。
|
||||
- Concepts created: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]]
|
||||
- Entities created: [[Gmail OAuth]]
|
||||
- Source page: wiki/sources/inbox-declutter.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入顶部)
|
||||
- 更新 overview.md,添加 inbox-declutter 描述段落(作为 [[custom-morning-brief]] 的相似模式)
|
||||
- 创建 Concept 页面:Email-Triage.md、Newsletter-Digest.md、Preference-Learning.md
|
||||
- 创建 Entity 页面:Gmail-OAuth.md
|
||||
- 与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的不同垂直场景
|
||||
- 冲突:无
|
||||
|
||||
## [2026-04-22] ingest | Market Research & Product Factory
|
||||
- Source file: Agent/usecases/market-research-product-factory.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 驱动的"从市场调研到产品构建"全自动化流水线——通过 Last 30 Days skill 挖掘 Reddit 和 X 近30天真实用户痛点,OpenClaw 根据痛点构建 Web 应用 MVP。核心价值:发短信即可完成"发现问题→验证需求→构建方案"全流程,无需技术背景。
|
||||
- Concepts created: [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]]
|
||||
- Source page: wiki/sources/market-research-product-factory.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md
|
||||
- 更新 overview.md,添加 Market Research & Product Factory 描述段落
|
||||
- 添加 Pain Point Mining、Startup MVP Pipeline、Agent-Driven Market Research、Last 30 Days Method 到 Key Concepts
|
||||
- Alex Finn 出现2次(content-factory + market-research),但按出现频次标准不满足 Entity 创建条件,跳过
|
||||
- Matt Van Horne 仅出现1次,跳过 Entity 页面创建
|
||||
- 冲突:无已知冲突
|
||||
|
||||
## [2026-04-22] ingest | Phone-Based Personal Assistant
|
||||
- Source file: Agent/usecases/phone-based-personal-assistant.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 OpenClaw 对话,支持日历查询、Jira 任务更新、网络搜索,无需智能手机 App 或浏览器,覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补:文字入口覆盖图文交互,语音入口覆盖无屏场景。
|
||||
- Concepts created: [[Voice Interface]], [[Telephony Integration]]
|
||||
- Entities created: [[ClawdTalk]], [[Telnyx]]
|
||||
- Source page: wiki/sources/phone-based-personal-assistant.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入 Multi-Channel Personal Assistant 之后)
|
||||
- 更新 overview.md,添加 phone-based-personal-assistant 描述段落,添加 Voice Interface、Telephony Integration 到 Key Concepts
|
||||
- 创建 2 个 Entity 页面:ClawdTalk.md、Telnyx.md
|
||||
- 创建 2 个 Concept 页面:Voice-Interface.md、Telephony-Integration.md
|
||||
- 冲突已记录(已在 overview.md Conflict Area #10):[[phone-based-personal-assistant]] 通用语音 Agent vs [[event-guest-confirmation]] SuperCall 沙盒 Persona
|
||||
|
||||
## [2026-04-22] ingest | Event Guest Confirmation
|
||||
- Source file: Agent/usecases/event-guest-confirmation.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 基于 OpenClaw + SuperCall 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人,确认出席状态并收集备注(饮食禁忌、Plus-One、到达时间等),通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值:真人电话比短信回复率高;SuperCall 沙盒 persona 设计确保安全隔离,无 Prompt Injection 风险;每通电话独立重置,无对话间信息混淆。
|
||||
- Concepts created: [[Sandboxed Persona]]
|
||||
- Entities created: (无新实体;OpenClaw 已在其他来源中出现)
|
||||
- Source page: wiki/sources/event-guest-confirmation.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入 Multi-Channel Personal Assistant 之后)
|
||||
- 更新 overview.md,添加 AI Tools & Productivity 小节描述
|
||||
- 更新 overview.md Conflict Area #10,添加 SuperCall 沙盒 Persona vs 通用语音 Agent 对比
|
||||
- 创建 1 个 Concept 页面:Sandboxed-Persona.md
|
||||
|
||||
## [2026-04-22] ingest | Multi-Channel Personal Assistant
|
||||
- Source file: Agent/usecases/multi-channel-assistant.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 基于 Telegram Topic 路由 + OpenClaw 的多渠道个人助理方案——以 Telegram 为统一入口,通过 Topic 隔离不同上下文(config/updates/video-ideas/personal-crm/earnings/knowledge-base),整合 Google Workspace(gog)、Slack、Todoist、Asana,实现"说一句话完成全套工作"。核心价值:消除应用切换疲劳,AI 主动推送定时提醒。
|
||||
- Concepts created: [[Topic-Based Routing]], [[Scheduled Reminder]]
|
||||
- Entities created: [[Asana]], [[gog]]
|
||||
- Source page: wiki/sources/multi-channel-assistant.md
|
||||
- Notes: 与 [[multi-agent-team]] 存在互补关系——Multi-Agent Team 为底层专业化分工,Multi-Channel Assistant 为用户交互层。
|
||||
|
||||
## [2026-04-22] ingest | Project State Management System: Event-Driven Alternative to Kanban
|
||||
- Source file: Agent/usecases/project-state-management.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 用事件驱动系统替代传统看板——自然语言对话自动记录项目事件(progress/blocker/decision/pivot),PostgreSQL/SQLite 存储完整事件历史,Git 提交自动关联项目,每日 Cron 生成站会报告。消灭手动拖拽卡片的摩擦,保留完整决策上下文,让项目状态查询和每日站会自动化。
|
||||
- Concepts created: [[Event Sourcing]], [[Project State]]
|
||||
- Entities created: (无新实体;OpenClaw 已存在于多个来源中,无需独立 Entity 页面)
|
||||
- Source page: wiki/sources/project-state-management.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入 Sources 首行)
|
||||
- 更新 overview.md Conflict Area #1,扩展 Kanban vs Event Sourcing 对比描述
|
||||
- 创建 2 个 Concept 页面:EventSourcing.md、ProjectState.md
|
||||
- 冲突已记录:Event Sourcing(自动追踪+上下文保留)vs Kanban(可视化协作+团队同步)
|
||||
- Source file: Agent/usecases/health-symptom-tracker.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 通过 Telegram 话题 + OpenClaw AI Agent 自动追踪食物与症状,实现食物敏感性识别。每日三餐定时提醒(8AM/1PM/7PM)确保日志一致性,OpenClaw 自动解析消息并带时间戳写入 Markdown 日志,每周日分析关联模式识别潜在触发因素。无需专用 App,完全自托管。
|
||||
- Concepts created: [[Food Sensitivity Tracking]], [[Automated Health Logging]]
|
||||
- Entities created: (无新实体;OpenClaw 实体已存在)
|
||||
- Source page: wiki/sources/health-symptom-tracker.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入首行)
|
||||
- 新增健康追踪主题至 overview.md
|
||||
- 冲突记录:与 habit-tracker-accountability-coach 的习惯追踪 vs 健康数据追踪侧重对比
|
||||
|
||||
|
||||
- Source file: Agent/usecases/self-healing-home-server.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理——OpenClaw + SSH + Cron Job 系统实现自动健康监控、故障自愈(重启 Pod/扩缩容/修复配置)、邮件分拣、每日 8AM 晨报(天气/日历/系统状态/看板)、知识库录入和安全审计。核心洞察:Cron Job 是真正的产品;知识提取具有复利效应;AI 会硬编码 secrets,TruffleHog pre-push hooks 是必须配置的防线;Local-first Git 是防止 API Key 暴露的架构基础。
|
||||
- Concepts created: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]]
|
||||
- Entities created: [[K3s]], [[Gitea]], [[TruffleHog]]
|
||||
- Entities updated: [[OpenClaw]](追加 self-healing-home-server 到 sources)
|
||||
- Source page: wiki/sources/self-healing-home-server.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(替换缺失条目)
|
||||
- 更新 overview.md,添加 "Self-Healing Infrastructure Agent" 章节
|
||||
- 创建 3 个 Entity 页面:K3s.md、Gitea.md、TruffleHog.md
|
||||
- 创建 4 个 Concept 页面:Morning-Briefing.md、Email-Triage.md、Local-first-Git.md、Defense-in-Depth.md
|
||||
- 冲突已记录:Prometheus/Grafana 监控方案(人工介入)vs AI Agent 自愈方案(全自动闭环)
|
||||
|
||||
## [2026-04-22] ingest | AI-Powered Earnings Tracker
|
||||
- Source file: Agent/usecases/earnings-tracker.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 自动化追踪科技公司财报——每周日 Cron Job 扫描财报日历并通过 Telegram 推送,用户选择后为每家公司创建一次性 Cron Job,财报发布后自动搜索结果并生成结构化摘要(beat/miss、营收、EPS、AI 亮点)。
|
||||
- Concepts created: (无新概念;Cron Job 已在其他来源中建立)
|
||||
- Entities created: (无新实体;OpenClaw 已存在;科技公司 NVDA/MSFT 等无需独立页面)
|
||||
- Source page: wiki/sources/earnings-tracker.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入首行)
|
||||
- 无需更新 overview.md(与现有 OpenClaw + Cron Job 主题一致)
|
||||
- 无需创建 Entity/Concept 页面
|
||||
- 无冲突
|
||||
|
||||
## [2026-04-23] ingest | Multi-Agent Specialized Team (Solo Founder Setup)
|
||||
- Source file: Agent/usecases/multi-agent-team.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 用多个专业化 AI Agent 组建团队,解决一人创业者(Solo Founder)身兼数职的困境——4 个专业 Agent(Milo/策略、Josh/商业、Marketing/营销、Dev/开发)通过共享记忆 + 私有上下文 + Telegram 单一控制平面协调运作,定时任务驱动主动工作流。
|
||||
- Concepts created: [[Agent Personality]], [[Agent Specialization]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]]
|
||||
- Entities updated: [[OpenClaw]](追加 multi-agent-team 到 sources)
|
||||
- Source page: wiki/sources/multi-agent-team.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(插入首行)
|
||||
- 更新 overview.md Key Concepts,添加 5 个新概念
|
||||
- 创建 6 个 Concept 页面
|
||||
- 更新 OpenClaw.md sources 字段
|
||||
- 冲突已记录:Multi-Agent Team(并行专业化分工)vs Content Factory(链式协作)
|
||||
|
||||
## [2026-04-23] ingest | Daily YouTube Digest
|
||||
- Source file: Agent/usecases/daily-youtube-digest.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -112,6 +285,24 @@
|
||||
- Key Entities: [[GoogleCloud]], [[Anthropic]], [[ADK]], [[SabooShubham]], [[lavinigam]]
|
||||
- 冲突检测:与 [[ClaudeSkill设计指南9种类型]] 存在互补关系——Google 强调 5 种结构模式,Anthropic 强调 9 类分类,两者可互补使用
|
||||
|
||||
## [2026-04-22] ingest | Custom Morning Brief
|
||||
- Source file: Agent/usecases/custom-morning-brief.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AI Agent 驱动的个性化晨间简报系统——定时推送(8AM)新闻研究/待办事项/主动任务推荐/睡前完整草稿,通过 Telegram/Discord/iMessage 送达。核心洞察:主动任务推荐是最有价值部分;完整草稿比标题节省时间;发消息即可个性化调整。
|
||||
- Concepts created: [[Scheduled Task Flywheel]], [[Proactive Agent Recommendation]], [[Full Draft Generation]]
|
||||
- Concepts referenced: [[Morning Briefing]], [[Multi-Channel Integration]]
|
||||
- Entities created: [[Todoist]], [[Asana]], [[Alex Finn]]
|
||||
- Entities updated: [[OpenClaw]](追加 custom-morning-brief 到 sources)
|
||||
- Source page: wiki/sources/custom-morning-brief.md
|
||||
- Notes:
|
||||
- 新增 Sources 条目至 index.md(Sources 首行)
|
||||
- 更新 overview.md,添加 Custom Morning Brief 段落
|
||||
- 创建 3 个 Entity 页面:Todoist.md、Asana.md、Alex-Finn.md
|
||||
- 创建 3 个 Concept 页面:Scheduled-Task-Flywheel.md、Proactive-Agent-Recommendation.md、Full-Draft-Generation.md
|
||||
- 与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景(个人生产力 vs 家庭服务器),已记录为 Connections
|
||||
- 冲突检测:无内容冲突
|
||||
- 与 [[phone-based-personal-assistant]] 均强调"AI 在用户无主动操作时提供价值",互补而非冲突
|
||||
|
||||
## [2026-04-25] ingest | n8n configure telegram trigger
|
||||
- Source file: Agent/n8n configure telegram trigger.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -623,4 +814,19 @@
|
||||
- Alex Finn 仅出现 1 次且无关键影响,跳过 Entity 页面创建
|
||||
- wiki/entities/ 和 wiki/concepts/ 目录存在但为空,所有 Concept 页面直接写入 wiki/concepts/
|
||||
|
||||
## [2026-04-22] ingest | AI-Powered Earnings Tracker
|
||||
- Source file: Agent/usecases/earnings-tracker.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: OpenClaw + Cron Job 自动化财报追踪——每周日 6PM 扫描财报日历过滤关注公司,Telegram 投递预览;用户确认后调度一次性 Cron Job,财报发布后自动搜索、格式化摘要(beat/miss、营收、EPS、AI 亮点、指引)并投递。消灭手动追踪摩擦,用户醒来即可获得成品摘要。
|
||||
- Concepts created: [[Earnings-Calendar]], [[Earnings-Beat-Miss]], [[AI-Powered Digest]]
|
||||
- Concepts linked: [[Cron Job]], [[Daily-Digest]], [[Telegram Topic]]
|
||||
- Entities checked: NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD(公开公司,仅作示例引用,跳过 Entity 页面创建;[[OpenClaw]] 已存在,无需更新)
|
||||
- Source page: wiki/sources/earnings-tracker.md
|
||||
- Notes:
|
||||
- 更新了 overview.md,在 AI Tools & Prompt Engineering 章节补充 Earnings Tracker 说明
|
||||
- 更新了 index.md,在 Sources 节和 Concepts 节添加新条目
|
||||
- 创建 3 个 Concept 页面:Earnings-Calendar.md、Earnings-Beat-Miss.md、Ai-Powered-Digest.md
|
||||
- 冲突已记录:Earnings Tracker vs Daily YouTube Digest(架构高度相似,可视为同一 Digest 模式的不同实例)
|
||||
- 与 Daily YouTube Digest 的时间粒度差异已在 Contradictions 节记录(财报事件触发 vs 频道更新检测)
|
||||
|
||||
|
||||
|
||||
@@ -7,7 +7,13 @@ This wiki is a living synthesis of curated sources spanning AI agents, cloud inf
|
||||
### Multi-Agent AI Systems
|
||||
The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n.
|
||||
|
||||
Key concepts: [[Agent Personality]], [[Agent Specialization]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]]
|
||||
**[[multi-channel-assistant]]**:基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口,整合 Google Workspace(gog)、Slack、Todoist、Asana,实现"说一句话完成全套工作"。核心价值:消除应用切换疲劳,AI 主动推送定时提醒(如每周垃圾清理、公司周报)。
|
||||
|
||||
**[[phone-based-personal-assistant]]**:通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话,支持日历查询、Jira 任务更新、网络搜索等技能,无需智能手机 App 或浏览器,覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补:文字入口覆盖图文交互,语音入口覆盖无屏场景。
|
||||
|
||||
**Inbox De-clutter**:基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件,生成精华摘要并附原文链接,根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。
|
||||
|
||||
Key concepts: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]]
|
||||
|
||||
### Cloud Transformation & DevOps
|
||||
Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps.
|
||||
@@ -19,11 +25,15 @@ Home office setup guides cover a complete multi-node home network infrastructure
|
||||
|
||||
Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compose]], [[Docker Engine]], [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]], [[it-tools]], [[RSSHub]], [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]], [[Symbolic Link]], [[软链接策略]], [[目录映射]], [[Prometheus]], [[PromQL]], [[Prometheus告警规则]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]], [[合成监控]], [[Exporter]], [[时序数据库]], [[TUI]], [[Process Management]], [[System Monitoring]], [[容器资源限制]], [[容器重启策略]], [[端口映射]], [[媒体服务器]], [[转码缓存]], [[只读挂载]], [[增量备份]], [[永久挂载]], [[挂载点检查]], [[Cron定时任务]], [[进程管理]], [[Socket 登录]], [[用户权限]], [[固件刷入]], [[过渡固件]], [[JFFS双清]], [[策略组分流]], [[故障转移]], [[订阅机制]], [[PUID/PGID]], [[桥接网络]], [[Socket Activation]], [[UFW 防火墙]], [[开机自启]], [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]], **[[全盘镜像备份]]**, **[[裸机恢复]]**, **[[NFS网络备份]]**, **[[UEFI启动]]**, [[指纹浏览器]], [[IP纯净度]], [[虚拟信用卡]], [[接码平台]], [[账号隔离]], **[[云盘挂载]]**, **[[NAS套件管理]]**, [[Root权限修复]], [[SPK套件格式]], [[launchd]], [[Gatekeeper]], **[[图床]]**, **[[S3-兼容对象存储]]**, **[[Docker堆栈]]**, **[[逻辑备份]]**, [[systemd]], [[Ubuntu Server]], **[[BI平台]]**, [[数据可视化]], **[[systemd-logind]]**, **[[HandleLidSwitch]]**, [[休眠目标]], [[pmset]], [[caffeinate]], [[Wake-on-LAN]], [[Headless 服务器]], [[系统睡眠管理]]
|
||||
|
||||
**Self-Healing Infrastructure Agent**: 基于 [[OpenClaw]] 的家庭服务器自动驾驶代理(代号 "Reef")——通过 SSH 访问家庭网络所有机器,配置 Cron Job 系统(15个活跃任务)实现 24/7 全天候自动化:每 15 分钟检查看板、每小时健康监控+邮件分拣、每 6 小时知识库录入+自检、每日 8AM 晨报(天气/日历/系统状态)、每周安全审计。Agent 可自动执行 SSH、Terraform、Ansible、kubectl 命令修复基础设施问题——"在你知道问题前就修复它"。核心安全策略:TruffleHog pre-push hooks + 私有 Gitea CI 扫描_pipeline + 1Password 专用 AI vault + 每日安全审计(防特权容器/硬编码 secrets/过度权限)。知识提取具有复利效应——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实。Key concepts: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]], [[Self-Healing-Systems]], [[Agentic AI]], [[Infrastructure-as-Code]], [[Gitea]], [[TruffleHog]], [[ArgoCD]], [[Loki]], [[Gatus]], [[K3s]]
|
||||
|
||||
### YouTube Automation
|
||||
A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in browser to access channel page source, search for `channel_id` string in the page source to find the RSS Feed URL containing the channel ID. Can be used in [[n8n]] workflows for YouTube subscription monitoring.
|
||||
|
||||
**AI-Powered Daily Digest**: [[daily-youtube-digest]] provides a fully automated pipeline — AI Agent periodically checks subscribed channels for new uploads → extracts video transcripts via [[TranscriptAPI.com]] → generates key-point summaries → delivers a daily digest. Runs on [[OpenClaw]] via the `youtube-full` skill (installable from [[ClawHub]]), using 0-credit free API calls for channel checking and 1 credit per transcript for summarization. Supports two modes: channel-based (e.g., @TED, @Fireship, @LexFridman) and keyword-based (e.g., "Claude Code", "AI agents").
|
||||
|
||||
**[[Daily Reddit Digest]]**:AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 [[OpenClaw]] + `reddit-readonly` skill,每日定时抓取指定 Subreddit 的热门/最新/最高赞帖子,AI 记忆用户偏好并持续优化精选规则(如排除表情包类内容)。纯读取模式,无需认证。属 [[Daily YouTube Digest]] 同款模式(定时 + AI 摘要 + 偏好学习)的 Reddit 垂直场景。
|
||||
|
||||
**Multi-Agent Content Factory**: [[content-factory]] 是基于 Discord 频道的多 Agent 内容工厂,通过 Research Agent → Writing Agent → Thumbnail Agent 链式协作,实现内容创作全流程自动化(研究→写作→设计)。每天定时运行,创作者次日醒来即可收获成品内容。[[OpenClaw]] 提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排。
|
||||
|
||||
Key concepts: [[Channel ID]], [[RSS Feed]], [[YouTube Automation]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]]
|
||||
@@ -53,6 +63,18 @@ Key concepts: [[国家中小学智慧教育平台]], [[tchMaterial-parser]], [[C
|
||||
### AI Tools & Prompt Engineering
|
||||
Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP via `npx claude-code-templates@latest --skill=<path> --yes` from aitmpl.com), OpenCode, [[Cursor]], [[Trae]], Gemini CLI, Vibe Coding, RAG, multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools.
|
||||
|
||||
**Custom Morning Brief**:基于 [[OpenClaw]] 的晨间简报自动化——每天定时(例 8AM)通过 Telegram/Discord/iMessage 推送结构化报告,内容涵盖:新闻研究(AI/创业/科技方向)、当日待办事项(集成 Todoist/Apple Reminders/Asana)、主动任务推荐(AI 自主思考可帮助完成的事项)、睡前完成的完整草稿(脚本/邮件/商业方案,而非仅标题)。核心洞察:**主动任务推荐**是整个系统最有价值的部分——AI 主动思考如何帮助用户,而非被动等待指令;完整草稿(full draft)比标题建议节省大量时间;用户只需发消息即可调整简报内容,无门槛个性化。与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景。
|
||||
|
||||
**Health & Symptom Tracker**:基于 [[OpenClaw]] 的食物敏感性自动追踪方案——通过 Telegram 话题记录食物和症状,Cron Job 每日三餐定时提醒(8AM/1PM/7PM),OpenClaw 自动解析消息并带时间戳写入 Markdown 日志,每周分析关联模式识别潜在触发因素。无需专用 App,完全自托管。
|
||||
|
||||
**AI-Powered Earnings Tracker**:基于 [[OpenClaw]] 的财报季自动化追踪方案——每周日 6PM 扫描财报日历并过滤用户关注公司(NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD),Telegram 投递预览列表;用户确认后为每家公司调度一次性 Cron Job,财报发布后自动搜索、格式化摘要(beat/miss、营收、EPS、AI 亮点、指引)并投递。与 [[Daily YouTube Digest]] 同属 Cron Job + AI 摘要 + Telegram 投递模式的不同实例。
|
||||
|
||||
**Event Guest Confirmation**:基于 [[OpenClaw]] + [[SuperCall]] 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人,确认出席状态并收集备注(饮食禁忌、Plus-One、到达时间等),通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值:真人电话比短信/文字消息回复率更高;SuperCall 的沙盒 persona 设计确保 AI 只拥有预设上下文,无法访问用户 Agent 或数据,无 Prompt Injection 风险;每通电话独立重置,无对话间信息混淆。与 [[phone-based-personal-assistant]] 同属 AI 电话外呼场景,但 [[SuperCall]] 的独立沙盒设计更适用于确认类单一任务。
|
||||
|
||||
**Market Research & Product Factory**:基于 [[OpenClaw]] 的"创业自动驾驶"方案——通过 [[Last 30 Days Skill]] 挖掘 Reddit 和 X 近30天真实用户痛点,按频率排序TOP需求,分析现有方案缺口,然后直接让 OpenClaw 构建可分享的 Web 应用 MVP。核心价值:**发短信就能完成从市场调研到产品原型的全流程**,无需技术背景。与 [[content-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法,但前者侧重内容创作,后者侧重产品机会发现。
|
||||
|
||||
**Pre-Build Idea Validator**:基于 [[OpenClaw]] + [[idea-reality-mcp]] 的 AI 项目启动前竞争分析门控——在写代码之前自动扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源,返回 `reality_signal` 分数(0-100)评估赛道拥挤度:高分数(>70)触发 STOP(展示竞品+询问是否继续/转向),低分数(<30)直接构建。核心价值:**在投入时间前发现已解决的同类问题**,是单兵创业者最重要的决策门控。与 [[market-research-product-factory]] 互补:后者挖痛点找方向,前者在动手前验证赛道的竞争密度。
|
||||
|
||||
**Claude Code 调用方法**:[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode(`claude -p`,适合绝大多数任务)和 TMUX 交互模式(适合超长任务)。核心参数包括 `--permission-mode bypassPermissions`(跳过所有权限确认)和 `--add-dir`(加载 SKILL.md)。关键结论:当任务需要 Claude Code 的 Skill 时,应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。
|
||||
|
||||
**播客制作自动化**:[[podcast-production-pipeline]] 提供 AI Agent 全自动播客制作流水线,覆盖「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」全链路。与 [[Content Factory]] 配合可将播客内容复用为博客、Newsletter、视频片段等多格式资产。
|
||||
@@ -63,7 +85,7 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
|
||||
|
||||
**会议记录自动化**:[[meeting-notes-action-items]] 提供 AI Agent 自动将会议转录文本(Otter.ai、Google Meet、Zoom)转换为结构化摘要,自动从会议中提取行动项并创建 Jira/Linear/Todoist/Notion 任务,同时发送 Slack/Discord 摘要,支持截止日提醒。核心洞察:**自动任务创建**比摘要本身更有价值,无法转化为追踪任务的会议记录只是"文档剧场"。
|
||||
|
||||
Key concepts: [[MeetingNotes]], [[ActionItemTracking]], [[TaskAutomation]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[AGENTS.md]], [[SOUL.md]], [[USER.md]], [[IDENTITY.md]], [[TOOLS.md]], [[BOOTSTRAP.md]], [[HEARTBEAT.md]], [[MEMORY.md]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP(Model Context Protocol)]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]]
|
||||
Key concepts: [[MeetingNotes]], [[ActionItemTracking]], [[TaskAutomation]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[AGENTS.md]], [[SOUL.md]], [[USER.md]], [[IDENTITY.md]], [[TOOLS.md]], [[BOOTSTRAP.md]], [[HEARTBEAT.md]], [[MEMORY.md]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP(Model Context Protocol)]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]]
|
||||
|
||||
### Productivity & Knowledge Management
|
||||
Obsidian plugins, blogwatcher RSS monitoring, Quartz static site generation, project management systems, and personal CRM frameworks. QuickAdd plugin enables quick note capture via hotkeys for rapid idea recording.
|
||||
@@ -226,7 +248,7 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
|
||||
|
||||
## Conflict Areas
|
||||
|
||||
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. [[Project State Management]] vs traditional PM tools.
|
||||
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**(事件驱动看板替代方案)vs 传统 PM 工具。核心差异:手动拖拽 vs 自然语言输入;静态快照 vs 全历史保留;无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列,每次 progress/blocker/decision/pivot 均持久化,保留完整决策上下文。
|
||||
|
||||
2. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies.
|
||||
|
||||
@@ -243,3 +265,5 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
|
||||
8. **macOS vs Linux 睡眠管理**:macOS 使用 `pmset` 命令配置电源管理(sleep/displaysleep/standby/hibernatemode),Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同(防止服务器睡眠),但工具链完全不同,不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。
|
||||
|
||||
9. **数据库备份方案**:pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准(零停机、跨平台迁移能力强),但不能备份运行中数据库的物理文件目录;rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录,两者互补。
|
||||
|
||||
10. **SuperCall 沙盒 Persona vs 通用语音 Agent**:[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line,无法访问外部系统;[[phone-based-personal-assistant]] 侧重通用个人助手场景,需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务(安全、无注入风险);通用语音 Agent 适用于需要跨系统协调的复杂助手场景。
|
||||
|
||||
46
wiki/sources/autonomous-project-management.md
Normal file
46
wiki/sources/autonomous-project-management.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Autonomous Project Management with Subagents"
|
||||
type: source
|
||||
tags: [multi-agent, project-management, autonomous-agents, coordination]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/autonomous-project-management]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:去中心化的多子 Agent 并行项目管理体系,通过共享 STATE.yaml 文件协调而非中央编排器
|
||||
- 问题域:复杂多并行工作流项目管理的上下文切换瓶颈问题——传统编排模式主 Agent 成为交通指挥员
|
||||
- 方法/机制:主 Agent 仅做策略(CEO 模式),子 Agent 通过读写共享 STATE.yaml 自主工作;Git 作为审计日志
|
||||
- 结论/价值:基于文件的协调比消息传递更具可扩展性;Git 版本控制提供完整历史追溯
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- **共享 STATE.yaml > 中心编排器**:文件协调比消息传递模式更具扩展性
|
||||
- **CEO 模式**:主会话越薄(0-2 步工具调用),响应速度越快
|
||||
- **Git 作为审计日志**:STATE.yaml 变更即提交,获得完整可追溯历史
|
||||
- **标签约定至关重要**:使用 `pm-{project}-{scope}` 格式便于追踪
|
||||
|
||||
## Key Quotes
|
||||
> "Let agents self-organize rather than micromanaging them." — [[Nicholas Carlini]]
|
||||
|
||||
> "The less the main agent does, the faster it responds." — 核心洞察
|
||||
|
||||
## Key Concepts
|
||||
- [[PM Delegation Pattern]]:主会话仅协调,所有执行下沉至子 Agent 的委托模式
|
||||
- [[CEO Pattern]]:主 Agent 仅负责策略决策,子 Agent 负责执行的极简主控模式
|
||||
- [[Shared State Coordination]]:通过共享文件(而非消息传递)实现多 Agent 协调
|
||||
- [[Git-as-Audit-Log]]:将所有状态变更提交至 Git,获得完整决策历史
|
||||
|
||||
## Key Entities
|
||||
- [[Nicholas Carlini]]:AI 研究者,其自主编码 Agent 方法启发了此模式——让 Agent 自我组织而非微观管理
|
||||
|
||||
## Connections
|
||||
- [[project-state-management]] ← related_to ← [[autonomous-project-management]](两者均强调文件化状态管理,但 project-state-management 侧重事件驱动看板)
|
||||
- [[content-factory]] ← related_to ← [[autonomous-project-management]](均使用 sessions_spawn/sessions_send 实现多 Agent 编排)
|
||||
- [[multi-agent-team]] ← related_to ← [[autonomous-project-management]](均涉及多 Agent 专业团队协作)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[project-state-management]] 冲突:
|
||||
- 冲突点:任务管理范式——动态状态文件 vs 静态看板视图
|
||||
- 当前观点:去中心化文件协调,子 Agent 自主驱动进度
|
||||
- 对方观点:事件驱动看板,用户通过自然语言操作,完整保留决策链上下文
|
||||
44
wiki/sources/custom-morning-brief.md
Normal file
44
wiki/sources/custom-morning-brief.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
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
|
||||
- 无已知冲突
|
||||
39
wiki/sources/daily-reddit-digest.md
Normal file
39
wiki/sources/daily-reddit-digest.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Daily Reddit Digest"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/daily-reddit-digest.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 驱动的 Reddit 每日精选摘要自动化
|
||||
- 问题域:如何高效追踪多个 Subreddit 的热门内容
|
||||
- 方法/机制:通过 OpenClaw + reddit-readonly skill,每日定时运行,自动抓取 Reddit 热门/最新/最高赞帖子
|
||||
- 结论/价值:提供免登录、免发帖、无噪音的纯阅读体验,支持搜索帖子、获取评论上下文,适合人工后续筛选和回复
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- OpenClaw Agent ← 每日定时执行 ← Reddit 热门帖子抓取,实现自动化内容订阅
|
||||
- reddit-readonly skill ← 无需认证 ← 纯读取模式,安全可靠
|
||||
- 记忆系统 ← 学习用户偏好 ← 持续优化精选规则,实现个性化 digest
|
||||
|
||||
## Key Quotes
|
||||
> "It's read-only. No posting, voting, or commenting." — 核心设计原则,专注阅读不引入干扰
|
||||
|
||||
## Key Concepts
|
||||
- [[Daily-Digest]]:定时运行的 AI 内容摘要服务,每日自动推送精选内容
|
||||
- [[Reddit Read-Only]]:纯读取模式,无需账户认证,专注于内容消费
|
||||
- [[Preference Learning]]:通过用户反馈持续学习偏好,优化推荐规则
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:多 Agent 框架,承载 reddit-readonly skill 和每日定时调度
|
||||
- [[reddit-readonly]]:ClawHub 上的公开 Skill,专注于 Reddit 内容读取,无需认证
|
||||
|
||||
## Connections
|
||||
- [[Daily YouTube Digest]] ← shares_pattern ← [[Daily Reddit Digest]](同为 Cron Job + AI 摘要 + Telegram 投递模式的不同垂直场景)
|
||||
- [[Content Factory]] ← extends ← [[Daily Reddit Digest]](前者扩展为多 Agent 协作内容创作链)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器"
|
||||
title: "Dataview——让我从笔记黑洞里逃出来的 Obsidian 神器"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
|
||||
42
wiki/sources/earnings-tracker.md
Normal file
42
wiki/sources/earnings-tracker.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
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
|
||||
- 无已知冲突
|
||||
48
wiki/sources/event-guest-confirmation.md
Normal file
48
wiki/sources/event-guest-confirmation.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
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]] 可能更适合需要访问更多上下文的复杂对话场景
|
||||
44
wiki/sources/health-symptom-tracker.md
Normal file
44
wiki/sources/health-symptom-tracker.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Health & Symptom Tracker"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/health-symptom-tracker.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:通过 Telegram 话题 + AI Agent 自动追踪食物与症状,实现食物敏感性识别
|
||||
- 问题域:食物敏感性识别需要长期一致的日志记录,人工维护繁琐
|
||||
- 方法/机制:
|
||||
- 在 Telegram 创建 "health-tracker" 话题作为记录入口
|
||||
- OpenClaw Agent 解析消息中的食物和症状,自动带时间戳写入 Markdown 日志文件
|
||||
- Cron Job 实现每日三餐定时提醒(8AM/1PM/7PM)
|
||||
- 每周日分析过去一周日志,识别食物-症状关联模式
|
||||
- 结论/价值:低技术门槛的自动化健康追踪方案,无需专用 App,适合个人自托管部署
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Telegram 话题 + AI 日志解析 = 无需专用 App 的食物追踪系统
|
||||
- 每日三餐提醒确保日志一致性,减少遗漏
|
||||
- 周期性模式分析能识别潜在食物触发因素
|
||||
|
||||
## Key Quotes
|
||||
> "Identifying food sensitivities requires consistent logging over time, which is tedious to maintain." — 问题陈述,解释了为何需要自动化追踪
|
||||
|
||||
## Key Concepts
|
||||
- [[Food Sensitivity Tracking]]:通过日志追踪食物摄入与症状关联,识别个人食物不耐受
|
||||
- [[Automated Health Logging]]:利用 AI 自动解析自然语言消息并写入结构化日志文件
|
||||
- [[Cron Job Reminders]]:定时任务驱动的生活方式干预,每日多次提醒形成习惯
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:作为 Agent 引擎,解析 Telegram 消息、写入日志文件、执行定时分析
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← powers ← [[health-symptom-tracker]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[habit-tracker-accountability-coach]] 对比:
|
||||
- 冲突点:习惯追踪 vs 健康数据追踪的侧重
|
||||
- 当前观点:health-symptom-tracker 专注症状-食物关联分析
|
||||
- 对方观点:habit-tracker 更侧重行为习惯养成和问责机制
|
||||
43
wiki/sources/inbox-declutter.md
Normal file
43
wiki/sources/inbox-declutter.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Inbox De-clutter"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/inbox-declutter.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 自动整理邮箱订阅 newsletters
|
||||
- 问题域:Newsletter 堆积造成的信息过载
|
||||
- 方法/机制:通过定时 Cron Job 让 AI 每日阅读过去 24 小时的新邮件,生成摘要并请求用户反馈,持续学习用户偏好
|
||||
- 结论/价值:用 AI 代替人工翻阅 Newsletter,只获取精华内容,减少信息噪音
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- AI Agent 通过每日 Cron Job 可主动整理 Newsletter 新邮件,无需用户手动翻阅
|
||||
- 用户反馈机制使 AI 能够持续优化摘要质量,越用越懂用户偏好
|
||||
|
||||
## Key Quotes
|
||||
> "I want you to run a cron job everyday at 8 p.m. to read all the newsletter emails of the past 24 hours and give me a digest of the most important bits along with links to read more." — OpenClaw 配置指令示例
|
||||
|
||||
> "Then ask for my feedback on whether you picked good bits, and update your memory based on my preferences for better digests in the future jobs." — 偏好学习机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Cron Job]]:定时调度任务,本文档中设置为每天 20:00 自动执行邮件摘要
|
||||
- [[Email Triage]]:邮件分拣,将 Newsletter 按重要性筛选整理
|
||||
- [[Newsletter Digest]]:AI 生成的 Newsletter 内容摘要,突出重点并附原文链接
|
||||
- [[Preference Learning]]:通过用户反馈持续优化 AI 摘要质量
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:多 Agent 记忆框架,inbox-declutter 的执行环境,支持 Cron Job 和 Memory 持久化
|
||||
- [[Gmail OAuth]]:Gmail API 认证方式,是此技能的前置依赖
|
||||
|
||||
## Connections
|
||||
- [[custom-morning-brief]] ← similar_pattern ← [[inbox-declutter]]
|
||||
- 两者均基于 [[OpenClaw]] Cron Job + Telegram 投递模式,但垂直场景不同
|
||||
- [[email-triage]] ← related_to ← [[inbox-declutter]]
|
||||
- inbox-declutter 是 Email Triage 的 Newsletter 垂直实现
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
45
wiki/sources/market-research-product-factory.md
Normal file
45
wiki/sources/market-research-product-factory.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Market Research & Product Factory"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/market-research-product-factory.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 驱动的"从市场调研到产品构建"全自动化流水线
|
||||
- 问题域:创业者/个人开发者的"不知道做什么产品"困境,替代传统手动论坛/社媒浏览式调研
|
||||
- 方法/机制:Last 30 Days skill 挖掘 Reddit 和 X 近30天真实用户痛点 → OpenClaw 根据痛点构建 MVP → 完整"发现问题→验证需求→构建方案"闭环
|
||||
- 结论/价值:**创业自动驾驶模式**(entrepreneurship on autopilot)—— 发短信即可完成调研到原型的全部流程,无需技术背景
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Last 30 Days skill 提供未经加工的真实用户情绪,区别于经过美化的调查数据
|
||||
- OpenClaw 同时承担研究和构建双重角色,用户无需技术背景
|
||||
- 定期调度(如每周一)可持续追踪市场痛点演化
|
||||
- 该流水线适合任何领域的产品机会发现,不限于特定行业
|
||||
|
||||
## Key Quotes
|
||||
> "You want to build a product but don't know what to build." — 核心痛点定义
|
||||
> "Real world example: OpenClaw identifies three pain points → user asks for an app → OpenClaw ships it → You have a product." — 端到端价值闭环
|
||||
> "Entrepreneurship on autopilot: find problems → validate demand → build solutions, all through text messages." — 模式定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Pain Point Mining]]:通过社媒挖掘真实用户投诉和功能需求
|
||||
- [[Startup MVP Pipeline]]:从市场调研到最小可行产品的自动化流程
|
||||
- [[Agent-Driven Market Research]]:AI Agent 替代人工进行持续性市场情报收集
|
||||
- [[Last 30 Days Method]]:聚焦近期用户讨论以获取时效性洞察的方法论
|
||||
|
||||
## Key Entities
|
||||
- [[Last 30 Days Skill]]:Matt Van Horne 开发的市场调研 skill,通过 Reddit 和 X 挖掘近30天用户痛点
|
||||
- [[OpenClaw]]:多 Agent 框架,同时承担研究和构建职责
|
||||
- [[Alex Finn]]:发布"改变人生的 OpenClaw 用法"视频的创作者,本方案的灵感来源
|
||||
- [[Matt Van Horne]]:Last 30 Days skill 的作者
|
||||
|
||||
## Connections
|
||||
- [[content-factory]] ← extends ← [[market-research-product-factory]]:前者侧重内容创作调研,后者侧重产品机会发现
|
||||
- [[product-trend-researcher]] ← depends_on ← [[Last 30 Days Skill]]:产品趋势研究员依赖 Last 30 Days skill 获取数据
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
63
wiki/sources/multi-agent-team.md
Normal file
63
wiki/sources/multi-agent-team.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
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 是并行专业化分工
|
||||
- 当前观点:并行专业化分工更适合一人公司的多领域需求
|
||||
- 对方观点:链式协作更适合内容创作这类有序流程
|
||||
52
wiki/sources/multi-channel-assistant.md
Normal file
52
wiki/sources/multi-channel-assistant.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
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 作为用户交互层。
|
||||
45
wiki/sources/phone-based-personal-assistant.md
Normal file
45
wiki/sources/phone-based-personal-assistant.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
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 适用于确认类单一任务
|
||||
49
wiki/sources/pre-build-idea-validator.md
Normal file
49
wiki/sources/pre-build-idea-validator.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Pre-Build Idea Validator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/pre-build-idea-validator]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI 项目启动前的竞争分析门控机制——在写代码之前自动扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个真实数据源,评估赛道拥挤度并给出转向建议。
|
||||
- 问题域:AI Agent 盲目构建已知问题域——开发者告诉 Agent "build me an AI code review tool",Agent 花 6 小时愉快地写代码,却不知道 GitHub 上已有 143,000+ 相关仓库(最高 53,000 stars)。
|
||||
- 方法/机制:[[idea-reality-mcp]] MCP 服务器提供 `idea_check()` 工具,输入项目想法返回 `reality_signal` 分数(0-100);OpenClaw Agent 在收到构建指令时自动调用此工具作为 pre-build gate。
|
||||
- 结论/价值:`reality_signal > 70` 触发 STOP 策略(展示竞品+询问是否继续/转向);30-70 分展示竞品并建议细分角度;<30 分直接构建。核心价值:**在投入时间前发现已解决的同类问题**,是单兵创业者最重要的决策门控。
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- [[OpenClaw]] Agent 通过在构建前调用 `idea_check()` 工具扫描 5 个真实数据源,可将"构建已知问题"的成本前置化。
|
||||
- `reality_signal` 分数基于真实数据(仓库数量、Star 分布、HN 讨论量),而非 LLM 主观猜测,保证评估客观性。
|
||||
- 高分数不意味着"不要做",而是意味着"必须差异化,否则别做"。
|
||||
- 低分数意味着真正的市场空白——这是单兵构建者胜出概率最高的区域。
|
||||
|
||||
## Key Quotes
|
||||
> "You tell your agent 'build me an AI code review tool' and it happily spends 6 hours coding. Meanwhile, 143,000+ repos already exist on GitHub — the top one has 53,000 stars." — 痛点描述:Agent 盲目构建的根本原因
|
||||
> "This prevents the most expensive mistake in building: solving a problem that's already been solved." — 核心价值:pre-build 检查的ROI
|
||||
> "A low score means genuine white space exists. That's where solo builders have the best odds." — 低分数即机会信号
|
||||
|
||||
## Key Concepts
|
||||
- [[Reality-Signal]]:通过 `idea_check()` 返回 0-100 的拥挤度评分,基于 GitHub 仓库数量、Star 分布、HN 讨论量等真实数据。阈值:>70 高风险,30-70 中等,<30 低风险/白空间。
|
||||
- [[Pre-Build-Validation]]:在代码编写之前进行市场/竞争验证的工作流模式,作为 Agent 构建指令的 pre-gate gate,防止在已饱和赛道投入资源。
|
||||
- [[Competition-Analysis]]:通过多平台(GitHub/npm/PyPI/HN/Product Hunt)扫描竞品的存在性、成熟度和市场关注度的分析过程。
|
||||
- [[Pivot-Strategy]]:当赛道拥挤时,通过语言专一化(Rust-only)、框架专一化(React 组件审查)或行业专一化(金融/医疗合规)实现差异化切入的策略。
|
||||
- [[Agent-Build-Gate]]:Agent 执行构建任务前的条件检查机制,只有通过门控条件才允许进入实际代码编写阶段。
|
||||
|
||||
## Key Entities
|
||||
- [[idea-reality-mcp]]:基于 [[MCP(Model Context Protocol)]] 的竞争分析 MCP 服务器,扫描 GitHub/HN/npm/PyPI/Product Hunt 返回 reality_signal 分数和竞品信息。安装方式:`uvx idea-reality-mcp`。
|
||||
- [[mnemox.ai]]:MCP 服务托管平台,提供 idea-reality-mcp 的 Web 体验版(mnemox.ai/check),无需安装即可试用工作流。
|
||||
- [[OpenClaw]]:多 Agent 框架,通过在 agent instructions 中嵌入 pre-build 规则实现自动门控——`idea_check()` → `reality_signal` → 构建/暂停/转向决策。
|
||||
- [[Product-Hunt]]:产品发布平台,idea-reality-mcp 的 5 个扫描数据源之一,用于发现未正式发布但已有关注度的早期产品。
|
||||
- [[Hacker-News]]:Y Combinator 技术新闻社区,idea-reality-mcp 的数据源之一,通过 HN 讨论量评估赛道热度。
|
||||
|
||||
## Connections
|
||||
- [[pre-build-idea-validator]] ← depends_on ← [[idea-reality-mcp]]
|
||||
- [[pre-build-idea-validator]] ← depends_on ← [[OpenClaw]]
|
||||
- [[market-research-product-factory]] ← extends ← [[pre-build-idea-validator]](后者验证想法,前者从想法生成到产品构建)
|
||||
- [[Pain-Point-Mining]] ← precedes ← [[pre-build-idea-validator]](挖痛点 → pre-build 验证 → 构建)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。
|
||||
45
wiki/sources/project-state-management.md
Normal file
45
wiki/sources/project-state-management.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
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):可视化面板提供直觉化状态概览,适合团队协作场景
|
||||
60
wiki/sources/self-healing-home-server.md
Normal file
60
wiki/sources/self-healing-home-server.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
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 是更可控的运维模式
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "万字保姆级教程,让你90天跑通"一人公司"模式(附AI提示词)"
|
||||
title: "万字保姆级教程,让你90天跑通一人公司模式(附AI提示词)"
|
||||
type: source
|
||||
tags: [一人公司, 个人品牌, 商业变现, AI提示词, 产品体系, 内容营销]
|
||||
date: 2026-02-11
|
||||
|
||||
@@ -49,7 +49,7 @@ date: 2026-04-03
|
||||
- [[Synology NAS DS718]]:群晖NAS设备(192.168.3.17),运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin等Docker应用。
|
||||
- [[Ubuntu Server]]:两个内网Ubuntu服务器节点(Ubuntu1: 192.168.3.47, Ubuntu2: 192.168.3.45),承担监控/导航/下载/工作流/Git等服务。
|
||||
- [[Caddy]]:公网VPS上的自动HTTPS反向代理服务器,绑定*.ishenwei.online域名。
|
||||
- [[FRP]]:内网穿透工具(frps/frpc v0.65.0),实现内网端口到公网端口的TCP隧道映射。
|
||||
- [[frp]]:内网穿透工具(frps/frpc v0.65.0),实现内网端口到公网端口的TCP隧道映射。
|
||||
- [[Prometheus]]:时序数据库监控系统,在NAS和Ubuntu1上运行,采集node_exporter/cAdvisor/blackbox_exporter指标。
|
||||
- [[Grafana]]:监控可视化平台(Ubuntu1:13000),通过Dashboard ID导入官方模板。
|
||||
- [[vaultwarden]]:轻量级Bitwarden密码管理器服务端,在Mac Mini和NAS上均有部署。
|
||||
@@ -77,7 +77,7 @@ date: 2026-04-03
|
||||
- [[it-tools]]:开源开发者工具集合,在Ubuntu1和Ubuntu2上运行(端口8999),提供URL编解码、UUID生成、哈希计算等100+工具。
|
||||
|
||||
## Connections
|
||||
- [[Caddy]] ← 反向代理 ← [[FRP]](Caddy将HTTPS请求代理到FRP映射端口)
|
||||
- [[Caddy]] ← 反向代理 ← [[frp]](Caddy将HTTPS请求代理到FRP映射端口)
|
||||
- [[Cloudflare]] ← DNS托管 ← [[Caddy]](DNS A记录指向VPS公网IP)
|
||||
- [[Prometheus]] ← 指标采集 ← [[node_exporter]] + [[cAdvisor]] + [[blackbox_exporter]]
|
||||
- [[Grafana]] ← 数据源 ← [[Prometheus]](Grafana消费Prometheus指标)
|
||||
@@ -89,8 +89,8 @@ date: 2026-04-03
|
||||
- [[OpenClaw]] ← 运行平台 ← [[Mac Mini M4]](OpenClaw的主要运行环境)
|
||||
- [[n8n]] ← 数据存储 ← [[PostgreSQL]](Ubuntu2上n8n_postgres容器)
|
||||
- [[Cloudflare]] ← DNS ← [[RackNerd]](VPS IP: 192.227.222.142)
|
||||
- [[FRP]] ← 客户端节点 ← [[Mac Mini M4]] + [[Synology NAS DS718]] + [[Ubuntu Server 1]] + [[Ubuntu Server 2]](4个frpc客户端)
|
||||
- [[FRP]] ← 服务端 ← [[RackNerd]](VPS运行frps服务端)
|
||||
- [[frp]] ← 客户端节点 ← [[Mac Mini M4]] + [[Synology NAS DS718]] + [[Ubuntu Server 1]] + [[Ubuntu Server 2]](4个frpc客户端)
|
||||
- [[frp]] ← 服务端 ← [[RackNerd]](VPS运行frps服务端)
|
||||
- [[Docker Compose]] ← 部署载体 ← [[Prometheus]] + [[Grafana]] + [[Jellyfin]] + [[Navidrome]] + [[n8n]] + [[Zipline]] + [[MinIO]] + [[v2rayA]] + [[vaultwarden]] + [[Portainer]] + [[Homarr]] + [[Apache Superset]] + [[Gitea]] + [[it-tools]](所有Docker应用均通过Docker Compose部署)
|
||||
|
||||
## Contradictions
|
||||
|
||||
Reference in New Issue
Block a user