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

wiki/concepts/AgenticSystem.md

@@ -0,0 +1,39 @@
+---
+title: "Agentic System"
+type: concept
+tags: [ai, agent, autonomy, llm]
+sources: []
+last_updated: 2025-05-09
+---
+
+## Aliases
+- Agentic System
+- AI Agentic System
+- 智能体系统
+
+## Definition
+由 Agent（智能体）和 Workflow（工作流）组成的混合系统。Agent 利用 LLM 动态判断用户请求需要调用哪些工具并生成响应，而非按预定义路径执行固定的输出序列。与传统工作流的"确定性输出"不同，Agentic System 能根据上下文自适应地选择工具组合。
+
+## Core Distinction: Workflow vs. Agent
+
+| 维度 | Workflow | Agent |
+|------|----------|-------|
+| 执行逻辑 | 预定义，固定路径 | LLM 驱动，动态选择 |
+| 输出 | 一致、可预测 | 随输入变化 |
+| 工具选择 | 预设顺序 | 按需调用 |
+| 适用场景 | 规则明确的自动化 | 需要推理和判断的任务 |
+
+## Components
+- **Agent**：核心决策单元，接收用户输入、调用 LLM、选择并执行工具
+- **Memory**：保留多轮对话上下文，使 Agent 理解会话历史
+- **Tools**：Agent 可调用的外部能力（API、数据库、计算模块等）
+- **Workflow**：将 Agent 嵌入更大的自动化流程中
+
+## Relationship to Other Concepts
+- [[N8N]]：N8N 的 Advanced AI Agent 节点是构建 Agentic System 的低代码平台
+- [[Memory in AI Agents]]：Agent 保留上下文的关键机制
+- [[Tool Integration]]：Agent 调用外部能力的基础
+
+## Sources
+- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
+- [[how-agentic-ai-can-help-for-cloud-devops]]

wiki/concepts/AutomatedReminders.md

@@ -0,0 +1,32 @@
+---
+title: "AutomatedReminders"
+type: concept
+tags: [automation, reminders, scheduling]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-27
+---
+
+## Definition
+Automated Reminders（自动化提醒）是一种由定时任务（Cron）驱动、由 AI Agent 在预设时间主动向用户发送通知的机制。区别于被动查询——提醒在用户没有主动发起请求的情况下，根据时间或事件自动触发。
+
+## Core Pattern
+1. **触发条件**：时间驱动（每周一 18:00）或事件驱动（任务截止前 24h）
+2. **提醒生成**：AI Agent 根据上下文（个人 CRM、 calendario、项目状态）生成个性化提醒内容
+3. **发送通道**：Telegram / Slack / SMS / Email 等
+4. **记忆上下文**：提醒内容往往依赖 [[Agent-Memory]] 中的个人数据（联系人偏好、日程安排）
+
+## Example from [[multi-channel-assistant]]
+```
+Monday 6 PM: "🗑️ Trash day tomorrow"
+Friday 3 PM: "✍️ Time to write the weekly company update"
+```
+
+## Related Concepts
+- [[Scheduled-Task-Flywheel]] — 定时任务的飞轮效应
+- [[Cron定时任务]] — 定时任务的技术实现
+- [[Proactive-Agent-Recommendation]] — 主动式 Agent 的推荐能力
+- [[TopicRouting]] — 提醒通常通过 config/updates 话题发送
+
+## Connections
+- [[multi-channel-assistant]] ← implements ← [[AutomatedReminders]]
+- [[HabitTrackerAccountabilityCoach]] ← uses ← [[AutomatedReminders]]（习惯追踪的主动提醒）

wiki/concepts/ClaudeCodePrintMode.md

@@ -0,0 +1,54 @@
+---
+title: "Claude Code Print Mode"
+type: concept
+tags: [claude-code, hermes, ai-agent, terminal, non-interactive]
+last_updated: 2026-04-27
+---
+
+## Aliases
+- Print Mode
+- claude -p
+
+## Definition
+Claude Code 的非交互单次执行模式。通过 `claude -p print` 命令调用，配合 stdin 传递任务描述文本，适合绝大多数自动化场景和 Hermes Agent 的程序化调用。
+
+## How It Works
+```bash
+cat << 'TASK_END' | claude -p print \
+  --dangerously-skip-permissions \
+  --add-dir ~/.claude/skills/[技能名] \
+  --add-dir [项目源码路径] \
+  --add-dir /tmp \
+  --max-turns 30 \
+  2>&1
+[具体任务描述]
+TASK_END
+```
+
+## Key Parameters
+- `--dangerously-skip-permissions`：跳过交互确认（信任目录、权限提示）
+- `--add-dir <路径>`：添加可访问目录，可多次使用
+- `--max-turns N`：最大迭代次数，建议 20-30
+- `--bare`：跳过插件/MCP/CLAUDE.md 加载，最快启动
+- `--model <模型>`：指定模型，如 `sonnet`、`opus`
+- `--output-format json`：结构化 JSON 输出
+
+## Task Text Structure（stdin 写法规范）
+```
+1. 告诉 Claude Code 要做什么
+2. 告诉它用哪个 skill
+3. 告诉它目标文件输出到哪里
+4. 如果需要格式转换（如 SVG → PNG），明确写出转换命令
+5. 最后要求它输出 "done: 文件路径"
+```
+
+## Relationship to TMUX Mode
+- Print Mode：适合绝大多数自动化场景，单次执行，无需后续交互
+- TMUX 交互模式：适合超长任务或需要中途干预的场景
+
+## Sources
+- [[Claude Code 调用方法总结]]
+
+## Connections
+- [[ClaudeCodePrintMode]] ← 推荐使用 ← [[Claude Code]]
+- [[ClaudeCodePrintMode]] ← 对比 ← [[ClaudeCodeTerminalIntegration]]

wiki/concepts/ClaudeCodeTerminalIntegration.md

@@ -0,0 +1,62 @@
+---
+title: "Claude Code Terminal Integration"
+type: concept
+tags: [claude-code, hermes, ai-agent, terminal, tmux, subprocess]
+last_updated: 2026-04-27
+---
+
+## Aliases
+- TMUX 交互模式
+- Claude Code TMUX Mode
+
+## Definition
+Hermes Agent 通过 `terminal` 工具启动 Claude Code 进程的两种集成方式：Print Mode（推荐）和 TMUX 交互模式。这两种模式允许 Hermes 作为编排层调用 Claude Code CLI，实现外部 AI 工具的程序化调用。
+
+## Two Integration Modes
+
+### Mode 1: Print Mode（推荐）
+```bash
+cat << 'TASK_END' | claude -p print \
+  --dangerously-skip-permissions \
+  --add-dir ~/.claude/skills/[技能名] \
+  --max-turns 30 \
+  2>&1
+[任务描述]
+TASK_END
+```
+- 非交互单次执行
+- 适合绝大多数自动化场景
+- 优先选用
+
+### Mode 2: TMUX 交互模式
+```bash
+tmux new-session -d -s <session-name> -x 140 -y 40
+tmux send-keys -t <session-name> 'claude --permission-mode bypassPermissions' Enter
+sleep 8 && tmux capture-pane -t <session-name> -p
+```
+- 适合超长任务或需要中途干预
+- 任务文本通过 `tmux send-keys` 发送
+- 使用 `--permission-mode bypassPermissions` 跳过确认
+
+## Key Parameters
+
+| 参数 | 作用 |
+|------|------|
+| `--permission-mode bypassPermissions` | 直接设置 bypass 模式，跳过所有交互确认 |
+| `--dangerously-skip-permissions` | 同上，但通过 CLI 内部触发，可能仍需交互确认 |
+| `--add-dir <路径>` | 添加可访问目录，可多次使用 |
+| `--max-turns N` | 最大迭代次数，建议 20-30 |
+| `--bare` | 跳过插件/MCP/CLAUDE.md 加载，最快启动 |
+
+## Skill Loading
+Claude Code 自动扫描 `--add-dir` 目录下的 `SKILL.md` 和 `.claude/skills/` 目录。
+```bash
+--add-dir ~/.claude/skills/[技能名]   # 加载指定技能
+```
+
+## Sources
+- [[Claude Code 调用方法总结]]
+
+## Connections
+- [[ClaudeCodeTerminalIntegration]] ← 被 ← [[Hermes Agent]]
+- [[ClaudeCodeTerminalIntegration]] ← 对比 ← [[SubagentDelegation]]

wiki/concepts/DocumentationTheater.md

@@ -0,0 +1,31 @@
+---
+title: "Documentation Theater"
+type: concept
+tags: [anti-pattern, productivity, knowledge-management]
+sources: [meeting-notes-action-items]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+Documentation Theater（文档剧场）是一种反讽概念——形容产出大量文档/记录，但实际上没有任何有意义的行动或追踪跟进的现象。核心批评：形式大于实质，记录本身变成了目的，而非达成目的的手段。
+
+## Origin
+
+本概念来自 [[meeting-notes-action-items]] source 中的一句话：
+
+> *"Meeting notes that don't become tracked tasks are just documentation theater."*
+
+## Core Insight
+
+会议笔记的价值不在于"写得好不好"，而在于"写完之后是否有行动项被追踪"。一个格式完美但无人执行的会议记录，与完全不做记录相比，实际价值几乎为零。
+
+## Related Concepts
+
+- [[MeetingNotes]] — 文档剧场是 MeetingNotes 模式的反面
+- [[AI-Driven Task Extraction]] — 对抗文档剧场的核心手段：让 AI 自动提取并创建可追踪任务
+- [[TaskAutomationPipeline]] — 文档剧场 → 可执行任务的自动化流水线
+
+## Related Sources
+
+- [[meeting-notes-action-items]]

wiki/concepts/EventSourcing.md

@@ -1,50 +1,51 @@
----
-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 自动追踪+上下文保留）
+---
+title: "Event Sourcing"
+type: concept
+tags: [architecture, data-modeling, patterns]
+sources: [project-state-management]
+last_updated: 2026-04-27
+---
+
+## 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 自动追踪+上下文保留）

wiki/concepts/FullDraftGeneration.md

@@ -0,0 +1,33 @@
+---
+title: "FullDraftGeneration"
+type: concept
+tags: []
+---
+
+## Definition
+AI 生成可直接使用的完整内容（脚本、邮件、商业方案等），而非仅提供标题、想法或大纲摘要的工作模式。
+
+## Aliases
+- 完整草稿生成
+- End-to-End Drafting
+- Ready-to-Use Output
+
+## Key Characteristics
+- **完整性（Completeness）**：输出即成品，可直接消费或微调后使用
+- **可执行性（Actionability）**：草稿可直接用于执行（发送邮件、上传视频、提交方案）
+- **时间节省（Time Saving）**：用户醒来面对的是成品，而非"还需要我加工的半成品"
+
+## Why It Matters
+[[custom-morning-brief]] 明确指出："Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions."
+
+在晨间简报场景中，"内容创意想法"不如"完整脚本大纲"有价值——想法还需要用户花时间展开，草稿则可直接使用。
+
+## Examples
+- 完整 YouTube 视频脚本（而非标题列表）
+- 完整商业提案框架（而非"可以考虑做 X"）
+- 完整邮件草稿（而非邮件主题建议）
+- 完整社交媒体帖子（而非帖子主题）
+
+## Related Concepts
+- [[ProactiveAI]]：主动生成草稿背后的驱动理念
+- [[ContentAutomation]]：完整草稿是内容自动化链条的最终产出

wiki/concepts/IntentDrivenRouting.md

@@ -0,0 +1,35 @@
+---
+title: "IntentDrivenRouting"
+type: concept
+tags: [routing, intent, AI-agent]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-27
+---
+
+## Definition
+Intent-Driven Routing（意图驱动路由）是一种 AI Agent 设计模式：通过 Prompt 层或配置层定义"用户意图 → 工具/动作"的映射规则，AI 根据用户输入中的关键词或语义自动路由到对应的工具或工作流，而无需用户显式指定。
+
+## How It Works
+1. **意图识别**：AI 解析用户输入，识别核心意图（如"添加任务"、"发邮件"、"创建日程"）
+2. **规则匹配**：根据 Prompt 中预定义的规则表，匹配意图到对应工具
+3. **工具执行**：调用对应工具完成任务
+4. **结果返回**：将工具输出以自然语言返回给用户
+
+## Example from [[multi-channel-assistant]]
+```
+Prompt 规则：
+"Add [task] to my todo" → use Todoist
+"Create a card for [topic]" → use Asana Video Pipeline project
+"Schedule [event]" → use gog calendar
+"Email [person] about [topic]" → draft email via gog gmail
+"Upload [file] to Drive" → use gog drive
+```
+
+## Related Concepts
+- [[TopicRouting]] — 意图路由与话题路由可组合使用（话题提供上下文，意图决定动作）
+- [[Intent-Classification]] — 意图分类是路由的前置步骤
+- [[Agent-Routing-Rules]] — 基于规则的显式路由
+
+## Connections
+- [[multi-channel-assistant]] ← uses ← [[IntentDrivenRouting]]
+- [[ToolOrchestration]] ← enables ← [[IntentDrivenRouting]]（工具编排提供可调用工具集）

wiki/concepts/Kanban.md

@@ -1,33 +1,33 @@
----
-title: "Kanban"
-type: concept
-tags: []
-sources: []
-last_updated: 2026-04-24
----
-
-## 定义
-Kanban 是一种敏捷框架，强调持续流动（continuous flow），无固定 Sprint 边界，允许随时调整优先级和需求。
-
-## 核心特征
-- **持续交付：** 无需等待 Sprint 结束即可发布
-- **随时变更：** 优先级可在任何时候调整
-- **可视化看板：** 通过列（列名）管理任务状态
-- **限制在制品（WIP）：** 控制同时进行的工作数量
-
-## 与 Scrum 的对比
-| 维度 | Scrum | Kanban |
-|------|-------|--------|
-| 迭代周期 | 固定 Sprint（1-4周） | 无固定周期 |
-| 变更时机 | Sprint 期间禁止 | 随时可调整 |
-| 发布节奏 | Sprint 结束时批量发布 | 持续交付 |
-| 仪式 | Sprint Planning/Review/Retrospective | 可选 ceremonies |
-
-## 企业实践：混合框架
-云转型团队采用以 Kanban 为主 + 保留 Scrum 仪式（每日站会和回顾会议）的混合方案，兼顾灵活性和反馈循环。
-
-## 来源
-- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
-
-## 别名
-- Kanban Framework
+---
+title: "Kanban"
+type: concept
+tags: [project-management, agile]
+sources: [project-state-management]
+last_updated: 2026-04-27
+---
+
+## 定义
+Kanban 是一种敏捷框架，强调持续流动（continuous flow），无固定 Sprint 边界，允许随时调整优先级和需求。
+
+## 核心特征
+- **持续交付：** 无需等待 Sprint 结束即可发布
+- **随时变更：** 优先级可在任何时候调整
+- **可视化看板：** 通过列（列名）管理任务状态
+- **限制在制品（WIP）：** 控制同时进行的工作数量
+
+## 与 Scrum 的对比
+| 维度 | Scrum | Kanban |
+|------|-------|--------|
+| 迭代周期 | 固定 Sprint（1-4周） | 无固定周期 |
+| 变更时机 | Sprint 期间禁止 | 随时可调整 |
+| 发布节奏 | Sprint 结束时批量发布 | 持续交付 |
+| 仪式 | Sprint Planning/Review/Retrospective | 可选 ceremonies |
+
+## 企业实践：混合框架
+云转型团队采用以 Kanban 为主 + 保留 Scrum 仪式（每日站会和回顾会议）的混合方案，兼顾灵活性和反馈循环。
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+
+## 别名
+- Kanban Framework

wiki/concepts/MemoryInAIAgents.md

@@ -0,0 +1,40 @@
+---
+title: "Memory in AI Agents"
+type: concept
+tags: [ai, agent, context, llm, memory]
+sources: []
+last_updated: 2025-05-09
+---
+
+## Aliases
+- AI Agent Memory
+- 对话记忆
+- 上下文保留
+- Context Retention
+
+## Definition
+在 AI Agent 中嵌入的上下文保留机制，通过在多轮对话中存储和检索历史信息，使 Agent 能够理解会话的完整语境，从而生成连贯、相关且符合上下文的响应。没有 Memory 的 Agent 每次交互都是孤立的，无法利用前序对话中的关键信息。
+
+## Why It Matters
+- **连贯性**：用户无需在每轮对话中重复已提供的背景信息
+- **个性化**：Agent 记住用户的偏好、之前的任务状态和关键事实
+- **效率**：避免用户反复解释相同的需求或约束
+- **真实性**：使对话更接近人与人之间的自然交流
+
+## Implementation Patterns
+- **短期记忆（Short-term）**：单次会话内的上下文窗口管理
+- **长期记忆（Long-term）**：跨会话持久化用户偏好、项目状态等
+- **向量检索**：将历史交互转为 embedding，通过相似度搜索召回相关信息
+- **摘要压缩**：定期将长对话摘要化，减少 token 消耗
+
+## Related Concepts
+- [[Agentic System]]：Memory 是 Agentic System 的核心组件之一
+- [[Tool Integration]]：Memory 与工具调用结合使 Agent 能够访问持久化状态
+
+## Related Entities
+- [[OpenClaw]]：强调持久记忆的多 Agent 系统
+- [[n8n]]：通过 Memory 节点支持对话上下文保留
+
+## Sources
+- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
+- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]]

wiki/concepts/Multi-Agent-Team.md

@@ -0,0 +1,34 @@
+---
+title: "Multi-Agent-Team"
+type: concept
+tags: [multi-agent, team-structure, coordination]
+sources: [multi-agent-team, nexus-spatial-discovery, workflow-startup-mvp]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+多 Agent 团队架构——通过多个专业化 Agent 的分工协作实现复杂任务的系统性解决方案。与流水线式链式执行（[[ContentFactory]]）和流水线编排（[[Agents-Orchestrator]]）同属多 Agent 协作模式的不同维度。
+
+## Key Design Principles
+
+- **角色专业化**：每个 Agent 专注单一领域，避免上下文切换成本
+- **共享记忆 + 私有上下文**：共同 ground（目标/决策）+ 各积累领域专长
+- **单一控制平面**：通过统一入口（Telegram / Discord）控制所有 Agent，降低管理复杂度
+- **定时主动任务**：Agent 主动推送洞察，而非被动等待指令
+- **个性驱动交互**：Agent 个性化（名字 + 沟通风格）使"和团队对话"比"使用工具"更自然
+- **从小开始**：lead + 1 specialist，按瓶颈逐步扩展
+
+## Related Patterns
+
+- [[ContentFactory]]：多 Agent 按内容处理阶段链式执行，强调自动化流水线——与本模式互补，可结合使用
+- [[Agents-Orchestrator]]：流水线编排器，自主管理从规格到交付的完整流程——本模式侧重团队协作，后者侧重流程自动化
+- [[SharedMemory]]：多 Agent 团队协调的核心基础设施
+- [[PrivateContext]]：与 SharedMemory 组合使用
+
+## Variants
+
+- **[[multi-agent-team]]**（Solo Founder Setup）：4 个专业 Agent（Milo 战略lead / Josh 商业分析 / Marketing 内容营销 / Dev 开发）+ Telegram + 定时任务
+- **[[nexus-spatial-discovery]]**：8 个 The Agency 专业 Agent 并行协作，完成产品完整规划
+- **[[workflow-startup-mvp]]**：多 Agent 以周为单位的长周期迭代
+- **[[workflow-landing-page]]**：Landing Page 场景下的多 Agent 一天冲刺

wiki/concepts/N8NNodeTypes.md

@@ -0,0 +1,56 @@
+---
+title: "N8N Node Types"
+type: concept
+tags: [n8n, workflow, automation, nodes]
+sources: []
+last_updated: 2025-05-09
+---
+
+## Aliases
+- N8N Node Types
+- N8N 节点类型
+- N8N Nodes
+
+## Definition
+N8N 工作流自动化平台中节点（Node）的五大类别，每类节点在自动化流程中承担不同的功能角色。理解节点分类是高效构建 N8N 工作流和 AI Agent 的基础。
+
+## The Five Node Categories
+
+### 1. Trigger Nodes（触发节点）
+工作流的入口点，负责启动整个流程。
+- **Webhook Trigger**：接收外部 HTTP 请求触发
+- **Schedule Trigger**：定时启动（如 Cron）
+- **Manual Trigger**：手动点击运行
+- **Event Triggers**：邮箱新邮件、GitHub Push 等事件触发
+
+### 2. Action Nodes（动作节点）
+执行具体的操作动作，是工作流的核心执行单元。
+- **数据库操作**：Read/Write/Update/Delete
+- **文件操作**：上传、下载、移动
+- **消息发送**：Email、Telegram、Slack 通知
+
+### 3. Utility Nodes（工具节点）
+提供辅助功能，不直接操作外部系统，而是转换、格式化或处理数据。
+- **Date & Time**：时间格式转换
+- **Code**：运行 JavaScript/Python 代码片段
+- **Move Binary Data**：二进制数据编码转换
+
+### 4. Code Nodes（代码节点）
+允许在 N8N 工作流中嵌入自定义逻辑，通过 JavaScript 或 Python 编写。
+- 数据转换与复杂计算
+- 自定义业务逻辑
+- 桥接 N8N 不原生支持的 API
+
+### 5. Advanced AI Nodes（高级 AI 节点）
+专为构建 AI Agent 设计的节点类型。
+- **AI Agent**：核心 Agent 节点，连接 LLM，动态选择工具
+- **AI Chain**：构建 LLM 调用链（Chain）
+- **Memory**：对话上下文保留
+- **Sub-Nodes**：为 AI Agent 提供工具的子节点
+
+## Relationship to Other Concepts
+- [[Agentic System]]：Advanced AI 节点是 N8N 实现 Agentic System 的核心手段
+- [[n8n]]：N8N 的全部能力通过节点系统暴露
+
+## Sources
+- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]

wiki/concepts/ProactiveAI.md

@@ -0,0 +1,26 @@
+---
+title: "ProactiveAI"
+type: concept
+tags: []
+---
+
+## Definition
+AI 代理主动预测用户需求、推荐行动方案，而非被动等待用户发起指令的设计模式。核心转变：从"你让我做什么"到"我认为你需要什么"。
+
+## Aliases
+- 主动式 AI
+- Anticipatory AI
+
+## Key Characteristics
+- **需求预测（Demand Forecasting）**：基于上下文（时间、位置、历史行为）预测下一步
+- **自主建议（Autonomous Recommendations）**：AI 主动提出可帮助完成的任务，而非等待指令
+- **零门槛定制（Zero-Threshold Customization）**：用户可通过自然语言随时调整 AI 的主动行为范围
+- **价值飞轮（Value Flywheel）**：AI 越主动 → 用户越依赖 → 数据越多 → AI 越精准
+
+## Core Example
+[[custom-morning-brief]] 中的"AI 主动推荐可自主完成的任务"——AI 在分析用户待办清单后，主动思考并推荐可代劳的工作，让用户醒来已有产出。
+
+## Related Concepts
+- [[ScheduledReport]]：主动推送的结构化形式
+- [[AgenticMemory]]：支撑主动预测的长期记忆能力
+- [[FullDraftGeneration]]：主动产出的内容质量标准——不仅建议，做完它

wiki/concepts/ProjectState.md

@@ -1,59 +1,60 @@
----
-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）
+---
+title: "Project State"
+type: concept
+tags: [project-management, automation, ai]
+sources: [project-state-management]
+last_updated: 2026-04-27
+---
+
+## 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）

wiki/concepts/ScheduledReport.md

@@ -0,0 +1,31 @@
+---
+title: "ScheduledReport"
+type: concept
+tags: []
+---
+
+## Definition
+定时推送结构化报告的工作流模式——AI 代理按预设时间（每日 8AM 等）主动推送包含多类信息的摘要报告，而非等待用户按需查询。
+
+## Aliases
+- Morning Brief
+- Morning Briefing
+- Daily Digest
+- Scheduled Summary
+
+## Key Characteristics
+- **主动性（Proactive）**：Agent 主动推送，用户无需发起请求
+- **时间触发（Time-Triggered）**：基于 Cron 或调度器在固定时间执行
+- **内容聚合（Content Aggregation）**：整合多个数据源（新闻、任务、日历等）到单一报告
+- **推送通道（Push Channel）**：Telegram / Discord / iMessage / Email
+
+## Examples
+- [[custom-morning-brief]]：每日 8AM 推送新闻+任务+草稿+AI推荐
+- [[self-healing-home-server]] 的 Morning Briefing：天气+日历+系统状态
+- [[family-calendar-household-assistant]]：家庭日程聚合晨报
+- [[daily-reddit-digest]]：每日 Reddit 社区摘要
+
+## Related Concepts
+- [[ProactiveAI]]：主动推送背后的核心设计理念
+- [[ScheduledReminder]]：简化版定时提醒
+- [[SecondBrain]]：被动查询式知识管理，与主动推送互补

wiki/concepts/SharedMemory.md

@@ -0,0 +1,50 @@
+---
+title: "SharedMemory"
+type: concept
+tags: [multi-agent, memory, coordination]
+sources: [multi-agent-team, workflow-with-memory, content-factory, multi-channel-assistant]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+共享记忆——多 Agent 系统中所有 Agent 可访问的公共知识库，用于存储项目文档、目标、关键决策和上下文信息。消除知识孤岛，确保 Agent 间协调的一致性。
+
+## Aliases
+- Team Memory
+- Common Ground
+- Shared Context
+- Shared Knowledge Base
+
+## Core Components
+
+典型的共享记忆结构：
+```
+team/
+├── GOALS.md           # 当前 OKR 和优先级（所有 Agent 读取）
+├── DECISIONS.md       # 关键决策日志（只追加）
+├── PROJECT_STATUS.md  # 当前项目状态（所有 Agent 更新）
+├── agents/
+│   ├── agent-a/       # Agent A 的私有上下文和笔记
+│   └── agent-b/       # Agent B 的私有上下文
+```
+
+## Key Characteristics
+
+- **全局可读**：所有 Agent 均可访问共享记忆，无权限壁垒
+- **结构化组织**：按用途分类（目标/决策/状态），避免信息混乱
+- **Append-only 决策日志**：DECISIONS.md 只追加，保留完整决策历史
+- **状态同步**：PROJECT_STATUS.md 由所有 Agent 共同维护，实时反映项目状态
+
+## Related Patterns
+
+- [[PrivateContext]]：与共享记忆互补——每个 Agent 维护自己的私有上下文，积累领域专长
+- [[SymbolicLink]]：在 OpenClaw 中通过符号链接使隐藏目录对外部工具可见
+- [[MemoryServer]]：记忆服务器作为多 Agent 协作的粘合剂（MCP Memory Server）
+
+## Usage Contexts
+
+- **[[multi-agent-team]]**：Milo/Josh/Marketing/Dev Agent 通过 GOALS.md、DECISIONS.md、PROJECT_STATUS.md 实现团队协调
+- **[[workflow-with-memory]]**：Memory Server 作为粘合剂，`remember` 存储交付物、`recall` 召回上下文、`rollback` 回滚检查点
+- **[[ContentFactory]]**：Discord 频道作为共享记忆，Research Agent 输出 → Writing Agent 读取
+- **[[multi-channel-assistant]]**：Google Workspace 共享日历/邮件作为跨渠道记忆

wiki/concepts/SubagentDelegation.md

@@ -0,0 +1,39 @@
+---
+title: "Subagent Delegation"
+type: concept
+tags: [hermes, ai-agent, delegation, api, subprocess]
+last_updated: 2026-04-27
+---
+
+## Aliases
+- delegate_task
+- 子 agent 委托
+
+## Definition
+Hermes Agent 的子 agent 委托机制，通过 `delegate_task` 工具启动子 AIAgent 实例，通过 API 调用 LLM。**关键限制**：子 agent 仍然是 Hermes 自身的 agent 实例，只能使用 Hermes 工具集，无法感知 Claude Code 的 SKILL.md 能力。
+
+## How It Works
+`delegate_task` 工具虽有 `acp_command` 参数，但：
+- `acp_command` 仅控制子 AIAgent 的构造参数
+- 子 AIAgent 通过 API 调用 LLM，不是外部 Claude Code 进程
+- **只有当 provider 为 `copilot-acp` 时**，`acp` 参数才会真正建立外部 CLI 通道
+
+## Comparison: delegate_task vs terminal 调用 Claude Code
+
+| | delegate_task | terminal 调用 claude -p |
+|--|--------------|------------------------|
+| 本质 | Hermes 子 agent（API 调用） | 外部 Claude Code 进程 |
+| Skill 感知 | 无 | 能识别 SKILL.md |
+| 工具能力 | Hermes 工具集 | Claude Code 自身工具集 |
+| 适用场景 | 通用推理任务 | 需要 Claude Code 技能的特定任务 |
+
+## When to Use Which
+- **使用 delegate_task**：通用推理、无需 Claude Code skill 的任务
+- **使用 terminal 调用 `claude -p`**：需要 Claude Code skill（如 fireworks-tech-graph、llm-wiki-sync 等）的任务
+
+## Sources
+- [[Claude Code 调用方法总结]]
+
+## Connections
+- [[SubagentDelegation]] ← 对比 ← [[Claude Code]]
+- [[SubagentDelegation]] ← 替代方案 ← [[Claude Code Print Mode]]

wiki/concepts/TaskAutomationPipeline.md

@@ -0,0 +1,38 @@
+---
+title: "Task Automation Pipeline"
+type: concept
+tags: [automation, workflow, ai, task-management]
+sources: [todoist-task-manager, meeting-notes-action-items]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+Task Automation Pipeline（任务自动化流水线）是一种端到端的 AI 工作流——将非结构化的自然语言输入，通过 LLM 解析和 API 调用，转化为结构化任务数据，并完成创建→确认→追踪的完整闭环。
+
+## Core Pattern
+
+```
+自然语言输入 → LLM 结构化解析 → API 创建任务 → 结果确认 → 持续追踪（Cron Job）
+```
+
+## Variations
+
+| 输入类型 | 解析目标 | 落地工具 |
+|----------|----------|----------|
+| 会议转录 | 行动项 + 负责人 + 截止日 | Jira/Linear/Todoist |
+| 邮件正文 | 待回复事项 + 优先级 | Todoist/Notion |
+| 聊天消息 | 任务请求 + 上下文 | Jira/Todoist |
+| 语音转录 | 待确认/待执行事项 | Todoist/SuperCall |
+
+## Related Concepts
+
+- [[AI-Driven Task Extraction]] — 流水线中的核心解析环节
+- [[Recurring Tasks]] — 流水线中的持续追踪环节
+- [[Meeting-to-Task Workflow]] — 会议场景下的具体流水线实现
+- [[DocumentationTheater]] — 缺乏流水线的后果：文档剧场
+
+## Related Sources
+
+- [[todoist-task-manager]] — 个人任务管理的流水线实现
+- [[meeting-notes-action-items]] — 会议场景的流水线实现

wiki/concepts/ToolIntegration.md

@@ -0,0 +1,39 @@
+---
+title: "Tool Integration"
+type: concept
+tags: [ai, agent, tools, api, integration]
+sources: []
+last_updated: 2025-05-09
+---
+
+## Aliases
+- Tool Integration
+- 工具集成
+- External Tool Integration
+- 外部工具集成
+
+## Definition
+将外部工具（数据库、API、文件系统、第三方服务等）作为可调用资源接入 AI Agent 的过程。工具集成是 Agent 超越语言模型自身能力边界、执行真实世界任务的核心手段。通过工具集成，Agent 可以查询实时数据、操作外部系统、完成端到端的业务流程自动化。
+
+## Key Principles
+- **可组合性**：多个工具可以按需组合，形成复杂的工作流
+- **权限边界**：工具调用应有明确的权限控制，防止误操作
+- **错误处理**：工具返回错误时 Agent 应有降级策略
+- **上下文感知**：工具选择应基于用户意图和当前对话状态
+
+## Examples in N8N
+- **Airtable**：库存查询与数据更新
+- **HTTP Request**：调用任意 REST API
+- **Database nodes**：PostgreSQL、MySQL 等数据库读写
+- **Webhook**：触发外部事件或接收回调
+
+## Relationship to Other Concepts
+- [[Agentic System]]：Tool Integration 是 Agent 动态执行能力的基础
+- [[Memory in AI Agents]]：Memory 使工具调用具有持久化上下文
+
+## Related Entities
+- [[Airtable]]：教程中的工具集成案例
+- [[n8n]]：提供 400+ 预置集成节点的平台
+
+## Sources
+- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]

wiki/concepts/ToolOrchestration.md

@@ -0,0 +1,32 @@
+---
+title: "ToolOrchestration"
+type: concept
+tags: [tools, integration, orchestration]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-27
+---
+
+## Definition
+Tool Orchestration（工具编排）是指通过统一的配置层和接口，集中管理多种外部工具（API、SaaS、CLI）的认证、调用和结果处理，使 AI Agent 能够跨多个工具执行复杂任务，而无需为每个工具单独编写集成代码。
+
+## Core Components
+1. **配置层**：集中存储所有工具的 API Key、OAuth Token、环境变量（如 [[OpenClaw]] 的 config.yaml）
+2. **适配器/包装器**：为每个工具提供统一调用接口（[[ToolWrapper]]）
+3. **意图路由**：根据用户请求自动选择对应工具（如 [[IntentDrivenRouting]]）
+
+## Role in [[multi-channel-assistant]]
+OpenClaw 作为配置中心，一次配置 Google OAuth / Slack / Todoist / Asana，AI Agent 通过统一 Prompt 指令调用不同工具：
+- "Add [task] to my todo" → Todoist
+- "Create a card for [topic]" → Asana
+- "Schedule [event]" → gog calendar
+- "Email [person] about [topic]" → gog gmail
+
+## Related Concepts
+- [[ToolWrapper]] — 工具的标准化封装接口
+- [[IntentDrivenRouting]] — 基于意图选择工具
+- [[Workflow-Engineering]] — 多工具组合形成工作流
+- [[SubagentDelegation]] — 将工具调用委托给子 Agent
+
+## Connections
+- [[OpenClaw]] ← provides ← [[ToolOrchestration]]（核心实现框架）
+- [[multi-channel-assistant]] ← uses ← [[ToolOrchestration]]

wiki/concepts/TopicRouting.md

@@ -0,0 +1,34 @@
+---
+title: "TopicRouting"
+type: concept
+tags: [routing, context, multi-channel]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-27
+---
+
+## Definition
+Topic Routing（话题路由）是一种通过消息平台的话题/线程（Topic）机制，在单一入口内实现多上下文隔离的设计模式。不同话题对应不同的工作流或知识域，用户无需切换 app 或启动多个 bot，只需要在对应话题中发起请求即可。
+
+## Core Mechanism
+1. **平台支持**：Telegram Topics、Discord Threads、Slack Channels 等都支持话题隔离
+2. **规则映射**：Prompt 或配置层定义"话题 → 工具/知识库/工作流"的映射规则
+3. **上下文注入**：AI Agent 根据当前所在话题注入对应的 system prompt 和工具集
+
+## Example: [[multi-channel-assistant]]
+```
+config      → 系统设置和调试
+updates     → 状态通知和日历提醒
+video-ideas → 内容创意流水线
+personal-crm → 联系人查询和会面准备
+earnings    → 财务追踪
+knowledge-base → RAG 知识库查询
+```
+
+## Related Concepts
+- [[Intent-Classification]] — 路由前先分类用户意图
+- [[Agent-Routing-Rules]] — 基于规则的路由决策
+- [[Context-Passing]] — 话题切换时的上下文传递
+
+## Connections
+- [[multi-channel-assistant]] ← implements ← [[TopicRouting]]（核心实现模式）
+- [[PhoneBasedPersonalAssistant]] ← alternative_to ← [[TopicRouting]]（电话是另一种单入口路由方式）