Sync: add productivity workflow notes
This commit is contained in:
@@ -1,46 +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 自主驱动进度
|
||||
- 对方观点：事件驱动看板，用户通过自然语言操作，完整保留决策链上下文
|
||||
---
|
||||
title: "Autonomous Project Management with Subagents"
|
||||
type: source
|
||||
tags: [multi-agent, project-management, autonomous-agents, coordination]
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## 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 自主驱动进度
|
||||
- 对方观点：事件驱动看板，用户通过自然语言操作，完整保留决策链上下文
|
||||
|
||||
@@ -1,39 +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
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "Daily Reddit Digest"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## 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,50 +1,53 @@
|
||||
---
|
||||
title: "Dynamic Dashboard with Sub-agent Spawning"
|
||||
type: source
|
||||
tags: [dashboard, monitoring, OpenClaw, automation]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/dynamic-dashboard]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：基于子代理并行执行的多数据源实时监控仪表盘
|
||||
- 问题域：静态仪表盘数据过时、手动更新繁琐、轮询多 API 效率低且易触发限流
|
||||
- 方法/机制：主 Agent 生成子代理并行抓取多个数据源，定时更新，聚合结果推送 Discord，支持告警阈值和历史趋势存储
|
||||
- 结论/价值：用对话式描述替代数周的前端开发，立即获得实时洞察
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 子代理并行执行可避免阻塞并分散 API 负载，避免顺序轮询导致的限流问题
|
||||
- 主 Agent 通过对话式指令调度子代理，无需编写前端代码即可获得实时仪表盘
|
||||
- 定时任务（Cron Job）与告警机制结合，实现"主动通知"而非"被动查询"
|
||||
- 历史指标存储在 PostgreSQL 数据库，支持趋势分析和历史数据回溯
|
||||
|
||||
## Key Quotes
|
||||
> "Static dashboards show stale data and require constant manual updates. You want real-time visibility across multiple data sources without building a custom frontend or hitting API rate limits." — 痛点描述
|
||||
> "OpenClaw spawns sub-agents to fetch each data source in parallel, aggregates the results, and delivers a formatted dashboard to Discord or as an HTML file." — 核心机制
|
||||
> "Updates run automatically on a cron schedule." — 自动化更新
|
||||
|
||||
## Key Concepts
|
||||
- [[Dynamic-Dashboard]]：基于子代理并行执行的多数据源实时监控仪表盘
|
||||
- [[Parallel-Agent-Execution]]：子代理并行抓取避免阻塞和分散 API 负载
|
||||
- [[Scheduled-Task-Flywheel]]：Cron Job 驱动的定时更新机制
|
||||
- [[Alerting]]：基于阈值的主动告警推送机制
|
||||
- [[Metrics-Database]]：PostgreSQL 存储历史指标供趋势分析
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：多代理框架，支撑子代理调度和定时任务编排
|
||||
- [[Discord]]：仪表盘结果推送渠道之一
|
||||
- [[PostgreSQL]]：指标历史数据库（metrics 表 + alerts 表）
|
||||
|
||||
## Connections
|
||||
- [[multi-agent-team]] ← depends_on ← [[dynamic-dashboard]]（共享子代理编排模式）
|
||||
- [[self-healing-home-server]] ← extends ← [[dynamic-dashboard]]（系统健康监控场景）
|
||||
- [[earnings-tracker]] ← extends ← [[dynamic-dashboard]]（市场数据监控场景）
|
||||
- [[content-factory]] ← depends_on ← [[dynamic-dashboard]]（社交媒体监控场景）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[content-factory]] 冲突：
|
||||
- 冲突点：内容工厂也有并行执行模式，但侧重内容创作流水线
|
||||
- 当前观点：[[dynamic-dashboard]] 侧重数据监控和告警，聚合多数据源
|
||||
- 对方观点：[[content-factory]] 侧重内容创作的多 Agent 链式协作
|
||||
---
|
||||
title: "Dynamic Dashboard with Sub-agent Spawning"
|
||||
type: source
|
||||
tags: [dashboard, sub-agent, monitoring]
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/dynamic-dashboard.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 驱动的实时动态仪表盘——通过子 Agent 并行抓取多数据源，自动聚合为统一仪表盘并定时推送到 Discord 或生成 HTML 文件
|
||||
- 问题域：静态仪表盘数据过时、需要自定义前端、API 速率限制、无法实时获取多源数据
|
||||
- 方法/机制：主 Agent 以对话方式定义监控目标 → 并行生成多个子 Agent 分别抓取各数据源 → 聚合结果写入 PostgreSQL → 格式化仪表盘内容 → 通过 Discord 或 Canvas 推送 → Cron 定时更新 + 阈值告警
|
||||
- 结论/价值：无需构建自定义前端，AI 接管全部编排工作；子 Agent 并行执行避免阻塞和速率限制；历史数据持久化支持趋势分析
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 子 Agent 并行执行可避免 API 速率限制（OpenClaw spawns sub-agents to fetch each data source in parallel）
|
||||
- AI 驱动的仪表盘可以在分钟级粒度自动更新，无需人工干预（Updates run automatically on a cron schedule）
|
||||
- 历史指标存储在数据库中支持任意时间范围的趋势查询（Query historical data: "Show me GitHub star growth over the past 30 days."）
|
||||
- 告警阈值检测使系统具备主动通知能力（alerts when metrics cross thresholds）
|
||||
|
||||
## Key Quotes
|
||||
> "Monitors multiple data sources simultaneously (APIs, databases, GitHub, social media)" — 核心能力：多数据源并行监控
|
||||
> "Spawns sub-agents for each data source to avoid blocking and distribute API load" — 技术实现：子 Agent 分载模式
|
||||
> "You define what you want to monitor conversationally" — 用户体验：以自然语言定义监控需求
|
||||
|
||||
## Key Concepts
|
||||
- [[SubAgent]]：并行子 Agent 用于分布式数据抓取，每个数据源对应一个独立 Agent 进程
|
||||
- [[CronJobs]]：定时任务驱动仪表盘周期性更新，支持分钟级粒度
|
||||
- [[AlertThreshold]]：告警阈值机制，当指标超过设定值时主动通知用户
|
||||
- [[MetricsDatabase]]：PostgreSQL 指标存储，表结构包含 source/metric_name/metric_value/timestamp，支持历史趋势分析
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：主编排引擎，负责对话式目标定义、子 Agent 调度和结果聚合
|
||||
- [[Discord]]：仪表盘输出渠道，支持 #dashboard 频道推送格式化内容
|
||||
- [[GitHub]]：数据源之一，提供 stars/forks/issues/commits 等项目指标
|
||||
- [[Polymarket]]：预测市场数据源，提供交易量和趋势信息
|
||||
|
||||
## Connections
|
||||
- [[AutonomousProjectManagement]] ← extends ← [[DynamicDashboard]]
|
||||
- 两者都依赖子 Agent 并行执行模式，但前者聚焦项目协调，后者聚焦数据监控
|
||||
- [[CustomMorningBrief]] ← similar_pattern ← [[DynamicDashboard]]
|
||||
- 都是定时运行的数据聚合工作流，但早间简报聚焦内容推荐，仪表盘聚焦实时指标
|
||||
- [[MultiChannelAssistant]] ← uses ← [[Discord]]
|
||||
- 多渠道助手使用 Discord 作为输出通道，与本工作流共享同一推送基础设施
|
||||
|
||||
## Contradictions
|
||||
- 与 [[AutonomousProjectManagement]] 冲突：
|
||||
- 冲突点：子 Agent 的协调机制
|
||||
- 当前观点：[[DynamicDashboard]] 采用数据聚合模式（各 Agent 写入共享数据库，主 Agent 读取聚合），适合统计类任务
|
||||
- 对方观点：[[AutonomousProjectManagement]] 采用文件协调模式（共享 STATE.yaml，CEO 模式），适合项目执行类任务
|
||||
- 注：两者可互补使用，数据聚合模式适用于监控场景，文件协调模式适用于任务执行场景
|
||||
|
||||
@@ -1,50 +1,51 @@
|
||||
---
|
||||
title: "Habit Tracker & Accountability Coach"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/habit-tracker-accountability-coach.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 作为主动的习惯追踪与问责伙伴，通过 Telegram/SMS 每日定时签到，替代被动式习惯追踪 App
|
||||
- 问题域：现有习惯追踪 App 依赖用户主动打开，Push 通知容易被忽视，用户在一周后放弃
|
||||
- 方法/机制：主动问责模式——定时签到 + 连续打卡追踪 + 自适应语气调节 + 每周报告；技能栈：Telegram Bot API / Twilio SMS + Cron 调度 + 本地文件存储 + Google Sheets 可视化（可选）
|
||||
- 结论/价值：主动问责（active accountability）比被动追踪更能驱动行为改变；保持 3-5 个习惯的小规模可避免签到疲劳；每周模式分析能发现隐藏规律
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 习惯 App 失败的根本原因不是 App 本身，而是追踪习惯这一行为是被动的（用户需要主动打开 App）
|
||||
- **主动问责**（active accountability）——由 AI 直接询问、庆祝胜利、在用户松懈时轻轻催促——才能真正驱动行为改变
|
||||
- 自适应语气是关键差异化因素：静态提醒会被忽视，而"第 15 天了，别断了"这样的消息具有真实激励效果
|
||||
- 追踪的习惯数量应保持在 3-5 个——太多会导致签到疲劳，用户会开始忽略消息
|
||||
- 每周模式分析出人意料地有用——用户会发现类似"我总是在有早会的日子不运动"这样的规律，从而提前规划
|
||||
|
||||
## Key Quotes
|
||||
> "The problem isn't the app — it's that tracking habits is passive." — OpenClaw 官方文档
|
||||
> "Day 12 of morning workouts. Solid." — 自定义确认完成回复示例
|
||||
> "When I miss a habit, don't guilt-trip me. Just acknowledge it and remind me why I started." — 自定义错失习惯回复语气指南
|
||||
> "Keep the number of tracked habits small (3-5). Tracking too many leads to check-in fatigue and you'll start ignoring the messages." — 关键洞察
|
||||
|
||||
## Key Concepts
|
||||
- [[Adaptive Tone]]：AI 根据用户表现动态调整语气——连续完成时给予鼓励（encouraging），连续错失时保持温和坚持（gently persistent）。静态提醒容易被忽略，个性化消息具有真实激励效果
|
||||
- [[Streak Tracking]]：记录每个习惯的当前连续打卡天数，在消息中引用，让用户直观看到积累的成果，形成心理激励
|
||||
- [[Check-in Fatigue]]：当追踪的习惯数量过多（>5个）时，用户会因签到负担过重而开始忽略消息，导致系统失效
|
||||
- [[Weekly Pattern Analysis]]：每周日汇总分析本周完成率、最长连续天数，发现隐藏的行为模式（如"总是在周五跳过阅读"），用于下周建议
|
||||
- [[Active Accountability]]：AI Agent 主动发消息询问用户，而非等待用户主动打开 App，是区别于传统习惯追踪 App 的核心机制
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：多 Agent 框架，提供记忆（memory）和 session_spawn/sessions_send 能力，是本方案的底层运行平台
|
||||
- [[Telegram Bot API]]：Telegram 官方 Bot API，用于每日签到消息的发送和接收，无需额外 App
|
||||
- [[Twilio]]：短信 API，用于 SMS 渠道的每日签到，适合没有 Telegram 的用户
|
||||
- [[Google Sheets API]]：可选集成，将每日习惯数据自动写入 Google Sheets 生成可视化仪表盘
|
||||
|
||||
## Connections
|
||||
- [[Health & Symptom Tracker]] ← pairs_with ← [[Habit Tracker & Accountability Coach]]
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_pattern ← [[Custom Morning Brief]]（定时 Cron Job + AI 推送模式）
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_pattern ← [[Daily YouTube Digest]]（定时 Cron Job + AI 摘要推送模式）
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_tech_stack ← [[Todoist Task Manager]]（Telegram + Cron Job 集成）
|
||||
|
||||
## Contradictions
|
||||
- 与传统习惯追踪 App（如 Streaks、Habitica）的对比：传统 App 强调被动记录和视觉激励（成就徽章、等级）；本方案强调主动询问和个性化文字激励。两者并非互斥，可互补使用。
|
||||
---
|
||||
title: "Habit Tracker & Accountability Coach"
|
||||
type: source
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/habit-tracker-accountability-coach.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 作为主动的习惯追踪与问责伙伴，通过 Telegram/SMS 每日定时签到，替代被动式习惯追踪 App
|
||||
- 问题域：现有习惯追踪 App 依赖用户主动打开，Push 通知容易被忽视，用户在一周后放弃
|
||||
- 方法/机制：主动问责模式——定时签到 + 连续打卡追踪 + 自适应语气调节 + 每周报告；技能栈：Telegram Bot API / Twilio SMS + Cron 调度 + 本地文件存储 + Google Sheets 可视化（可选）
|
||||
- 结论/价值：主动问责（active accountability）比被动追踪更能驱动行为改变；保持 3-5 个习惯的小规模可避免签到疲劳；每周模式分析能发现隐藏规律
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 习惯 App 失败的根本原因不是 App 本身，而是追踪习惯这一行为是被动的（用户需要主动打开 App）
|
||||
- **主动问责**（active accountability）——由 AI 直接询问、庆祝胜利、在用户松懈时轻轻催促——才能真正驱动行为改变
|
||||
- 自适应语气是关键差异化因素：静态提醒会被忽视，而"第 15 天了，别断了"这样的消息具有真实激励效果
|
||||
- 追踪的习惯数量应保持在 3-5 个——太多会导致签到疲劳，用户会开始忽略消息
|
||||
- 每周模式分析出人意料地有用——用户会发现类似"我总是在有早会的日子不运动"这样的规律，从而提前规划
|
||||
|
||||
## Key Quotes
|
||||
> "The problem isn't the app — it's that tracking habits is passive." — OpenClaw 官方文档
|
||||
> "Day 12 of morning workouts. Solid." — 自定义确认完成回复示例
|
||||
> "When I miss a habit, don't guilt-trip me. Just acknowledge it and remind me why I started." — 自定义错失习惯回复语气指南
|
||||
> "Keep the number of tracked habits small (3-5). Tracking too many leads to check-in fatigue and you'll start ignoring the messages." — 关键洞察
|
||||
|
||||
## Key Concepts
|
||||
- [[Adaptive Tone]]：AI 根据用户表现动态调整语气——连续完成时给予鼓励（encouraging），连续错失时保持温和坚持（gently persistent）。静态提醒容易被忽略，个性化消息具有真实激励效果
|
||||
- [[Streak Tracking]]：记录每个习惯的当前连续打卡天数，在消息中引用，让用户直观看到积累的成果，形成心理激励
|
||||
- [[Check-in Fatigue]]：当追踪的习惯数量过多（>5个）时，用户会因签到负担过重而开始忽略消息，导致系统失效
|
||||
- [[Weekly Pattern Analysis]]：每周日汇总分析本周完成率、最长连续天数，发现隐藏的行为模式（如"总是在周五跳过阅读"），用于下周建议
|
||||
- [[Active Accountability]]：AI Agent 主动发消息询问用户，而非等待用户主动打开 App，是区别于传统习惯追踪 App 的核心机制
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：多 Agent 框架，提供记忆（memory）和 session_spawn/sessions_send 能力，是本方案的底层运行平台
|
||||
- [[Telegram Bot API]]：Telegram 官方 Bot API，用于每日签到消息的发送和接收，无需额外 App
|
||||
- [[Twilio]]：短信 API，用于 SMS 渠道的每日签到，适合没有 Telegram 的用户
|
||||
- [[Google Sheets API]]：可选集成，将每日习惯数据自动写入 Google Sheets 生成可视化仪表盘
|
||||
|
||||
## Connections
|
||||
- [[Health & Symptom Tracker]] ← pairs_with ← [[Habit Tracker & Accountability Coach]]
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_pattern ← [[Custom Morning Brief]]（定时 Cron Job + AI 推送模式）
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_pattern ← [[Daily YouTube Digest]]（定时 Cron Job + AI 摘要推送模式）
|
||||
- [[Habit Tracker & Accountability Coach]] ← shares_tech_stack ← [[Todoist Task Manager]]（Telegram + Cron Job 集成）
|
||||
|
||||
## Contradictions
|
||||
- 与传统习惯追踪 App（如 Streaks、Habitica）的对比：传统 App 强调被动记录和视觉激励（成就徽章、等级）；本方案强调主动询问和个性化文字激励。两者并非互斥，可互补使用。
|
||||
|
||||
@@ -1,44 +1,43 @@
|
||||
---
|
||||
title: "LaTeX Paper Writing"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/latex-paper-writing.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：基于 AI Agent 的 LaTeX 论文写作助手，通过云端 TeX 环境实现无需本地安装的即时编译
|
||||
- 问题域：本地 LaTeX 环境配置繁琐（TeX Live 体积巨大）、编译错误调试繁琐、在编辑器和 PDF 阅读器之间切换打断写作流
|
||||
- 方法/机制：Prismer Docker 容器提供云端 LaTeX 编译服务 + latex-compiler skill（4 个工具） + AI 对话生成 LaTeX 代码 + 内联 PDF 预览
|
||||
- 结论/价值：通过云端即时编译消除本地安装，实现对话式论文写作，AI 负责生成 LaTeX 源码并自动修复编译错误
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI Agent 可以作为 LaTeX 写作助手，用户描述内容需求，Agent 生成对应的 LaTeX 源码
|
||||
- 通过 Docker 容器在云端运行完整 TeX Live（端口 8080），无需在本地安装任何 TeX 发行版
|
||||
- 支持三种编译器自动选择：pdflatex（默认）、xelatex（支持中文/CJK）、lualatex（Unicode 支持）
|
||||
- 内联 PDF 预览无需切换到其他应用程序
|
||||
- 提供四种启动模板：article、IEEE、beamer（演示文稿）、Chinese article（中文论文）
|
||||
- 支持 BibTeX/BibLaTeX 参考文献管理，直接粘贴 .bib 内容即可
|
||||
- 交叉引用需运行 2 次编译 pass
|
||||
|
||||
## Key Quotes
|
||||
> "Setting up a local LaTeX environment is painful — installing TeX Live takes gigabytes, debugging compilation errors is tedious, and switching between your editor and PDF viewer breaks flow." — 痛点描述
|
||||
> "Use xelatex if I need Chinese/CJK support, otherwise default to pdflatex. Always run 2 passes for cross-references." — 编译器使用规范
|
||||
|
||||
## Key Concepts
|
||||
- [[latex-compiler]]：Prismer 内置 skill，提供 4 个工具：`latex_compile`、`latex_preview`、`latex_templates`、`latex_get_template`
|
||||
- [[Prismer]]：开源 AI Agent workspace 项目，通过 Docker 提供完整 TeX Live 云端环境，LaTeX server 监听端口 8080
|
||||
- [[Docker]]：容器化部署底座，Prismer 通过 `docker compose -f docker/docker-compose.dev.yml up` 启动
|
||||
- [[BibTeX]]：LaTeX 参考文献格式工具，支持 .bib 文献库管理，BibLaTeX 是其现代替代方案
|
||||
|
||||
## Key Entities
|
||||
- [[Prismer]]：GitHub 开源项目（Prismer-AI/Prismer），提供云端 TeX Live 和 latex-compiler skill，Agent 无需额外安装
|
||||
|
||||
## Connections
|
||||
- [[latex-paper-writing]] ← depends_on ← [[Prismer]]
|
||||
- [[Prismer]] ← runs_on ← [[Docker]]
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
---
|
||||
title: "LaTeX Paper Writing"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/latex-paper-writing.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 AI Agent 实现对话式 LaTeX 论文写作与即时编译
|
||||
- 问题域：本地 LaTeX 环境配置繁琐（TeX Live 体积庞大）、编译错误排查耗时、编辑器与 PDF 预览器切换破坏工作流
|
||||
- 方法/机制：使用 Prismer Workspace 容器（内置完整 TeX Live + LaTeX 服务器），通过 latex-compiler skill 的 4 个工具让 Agent 替代用户完成 LaTeX 写作、编译、预览全流程
|
||||
- 结论/价值：用户只需用自然语言描述论文内容，Agent 生成 LaTeX 源码并即时编译预览，无需本地安装 TeX 环境
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent + Prismer 容器 → 用户无需本地安装 TeX Live 即可完成 LaTeX 论文写作
|
||||
- latex-compiler skill 提供 4 个工具（latex_compile、latex_preview、latex_templates、latex_get_template），覆盖完整写作流程
|
||||
- 支持多种模板（article、IEEE、beamer、中文论文）和编译引擎（pdflatex、xelatex、lualatex）
|
||||
- BibTeX/BibLaTeX 文献管理内置支持，用户只需粘贴 .bib 内容
|
||||
|
||||
## Key Quotes
|
||||
> "Setting up a local LaTeX environment is painful — installing TeX Live takes gigabytes, debugging compilation errors is tedious, and switching between your editor and PDF viewer breaks flow." — 问题陈述
|
||||
> "Compile to PDF instantly with pdflatex, xelatex, or lualatex (no local TeX installation needed)" — 核心价值主张
|
||||
> "Use xelatex if I need Chinese/CJK support, otherwise default to pdflatex." — 引擎选择策略
|
||||
|
||||
## Key Concepts
|
||||
- [[LaTeX]]：科技论文排版系统，Prismer 提供完整 TeX Live 运行时
|
||||
- [[BibTeX/BibLaTeX]]：LaTeX 参考文献管理工具，latex-compiler skill 内置支持
|
||||
- [[Prismer Workspace]]：Docker 容器化工作环境，内置 LaTeX 服务器（端口 8080）
|
||||
- [[LaTeX Compiler Skill]]：4 工具技能集（latex_compile、latex_preview、latex_templates、latex_get_template）
|
||||
|
||||
## Key Entities
|
||||
- [[Prismer-AI]]：提供 Prismer Workspace 容器和 latex-compiler skill 的开源项目
|
||||
- [[latex-compiler]]：Prismer 内置的 4 工具 LaTeX 技能
|
||||
|
||||
## Connections
|
||||
- [[Prismer-AI]] ← provides runtime ← [[LaTeX Paper Writing]]
|
||||
- [[LaTeX Compiler Skill]] ← enables ← [[LaTeX Paper Writing]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突内容
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Local CRM Framework with DenchClaw"
|
||||
type: source
|
||||
tags: ["openclaw", "crm", "automation", "duckdb", "browser-automation"]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/local-crm-framework.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台的完整框架
|
||||
- 问题域：OpenClaw 作为基础原语功能强大，但用于真实商业工作流（线索追踪、外联、管道管理）需要集成数据库、UI、浏览器自动化、消息平台等多个工具，设置复杂易碎
|
||||
- 方法/机制：`npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化 + Skills）；所有设置/视图以文件（YAML/Markdown）存储，OpenClaw 可直接读写修改 UI；Chrome Profile 克隆继承浏览器认证状态
|
||||
- 结论/价值：Cursor 级别的 UX 用于商业运营，无需 Docker/环境配置，通过自然语言管理完整的 CRM 管道
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DenchClaw 一键安装（`npx denchclaw`）自动配置 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器和 Skills，无需手动设置
|
||||
- 自然语言 CRM 查询（"显示员工>5人的公司"）实时更新视图，无需手动过滤器操作
|
||||
- Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据，无需 OAuth 流程
|
||||
- 所有设置/视图/过滤器以 YAML/Markdown 文件存储，Agent 可像编辑代码一样自然地修改 UI
|
||||
- DuckDB 是嵌入式数据库的最佳选择：最小体积、完全 SQL 支持、无服务器/凭证/网络依赖
|
||||
- DenchClaw 内置三种 Skills：CRM Skill（对象/字段/视图）、App Builder Skill（Web 应用构建）、Browser Automation Skill（浏览器自动化）
|
||||
|
||||
## Key Quotes
|
||||
> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
|
||||
> — DenchClaw 的核心设计哲学：文件系统即 Agent 原生 UI
|
||||
|
||||
> "DuckDB is the sweet spot: Smallest, most performant embedded database that still supports full SQL. No server process, no credentials, no network — just a file."
|
||||
> — DuckDB 作为嵌入式 CRM 数据库的理由
|
||||
|
||||
> "Chrome profile cloning is a superpower: Instead of fighting OAuth flows and API rate limits, DenchClaw copies your browser's auth state. The agent sees what you see, does what you do."
|
||||
> — Chrome Profile 克隆实现无缝浏览器自动化
|
||||
|
||||
> "One `npx` command beats a weekend of setup: The entire stack installs and configures itself. No Docker, no env files, no dependency hell."
|
||||
> — 一键安装 vs 手动配置的对比
|
||||
|
||||
## Key Concepts
|
||||
- [[File-System-First UI]]：所有设置/视图以文件形式存储，Agent 可直接读写，无需 API 抽象层
|
||||
- [[Chrome Profile Cloning]]：复制浏览器认证状态而非依赖 OAuth，使 Agent 继承用户的登录会话
|
||||
- [[One-Command-Setup]]：通过单一命令自动安装和配置完整技术栈，消除环境配置摩擦
|
||||
- [[DuckDB]]：嵌入式分析型数据库，无服务器、零配置、完全 SQL 支持
|
||||
|
||||
## Key Entities
|
||||
- [[DenchClaw]]：MIT 许可证开源框架，将 OpenClaw 转化为本地 CRM/SaaS 平台
|
||||
- [[OpenClaw]]：多 Agent 框架，DenchClaw 的底层 Agent 引擎
|
||||
- [[DuckDB]]：SQLite 替代品，Analytical DBMS，用于 CRM 结构化数据存储
|
||||
- [[HubSpot]]：CRM 平台示例，DenchClaw 可导入其数据
|
||||
|
||||
## Connections
|
||||
- [[Second Brain]] ← 相关 ← [[local-crm-framework]]：两者均基于 OpenClaw 的记忆/持久化能力
|
||||
- [[personal-crm]] ← 相关 ← [[local-crm-framework]]：个人 CRM 场景的不同实现方案
|
||||
- [[multi-channel-assistant]] ← 共享技术栈 ← [[local-crm-framework]]：均使用 Telegram/消息平台作为交互入口
|
||||
|
||||
## Contradictions
|
||||
（暂无发现与其他 Wiki 页面的内容冲突）
|
||||
---
|
||||
title: "Local CRM Framework with DenchClaw"
|
||||
type: source
|
||||
tags: ["openclaw", "crm", "automation", "duckdb", "browser-automation"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/local-crm-framework.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台的完整框架
|
||||
- 问题域：OpenClaw 作为基础原语功能强大，但用于真实商业工作流（线索追踪、外联、管道管理）需要集成数据库、UI、浏览器自动化、消息平台等多个工具，设置复杂易碎
|
||||
- 方法/机制：`npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化 + Skills）；所有设置/视图以文件（YAML/Markdown）存储，OpenClaw 可直接读写修改 UI；Chrome Profile 克隆继承浏览器认证状态
|
||||
- 结论/价值：Cursor 级别的 UX 用于商业运营，无需 Docker/环境配置，通过自然语言管理完整的 CRM 管道
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DenchClaw 一键安装（`npx denchclaw`）自动配置 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器和 Skills，无需手动设置
|
||||
- 自然语言 CRM 查询（"显示员工>5人的公司"）实时更新视图，无需手动过滤器操作
|
||||
- Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据，无需 OAuth 流程
|
||||
- 所有设置/视图/过滤器以 YAML/Markdown 文件存储，Agent 可像编辑代码一样自然地修改 UI
|
||||
- DuckDB 是嵌入式数据库的最佳选择：最小体积、完全 SQL 支持、无服务器/凭证/网络依赖
|
||||
- DenchClaw 内置三种 Skills：CRM Skill（对象/字段/视图）、App Builder Skill（Web 应用构建）、Browser Automation Skill（浏览器自动化）
|
||||
|
||||
## Key Quotes
|
||||
> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
|
||||
> — DenchClaw 的核心设计哲学：文件系统即 Agent 原生 UI
|
||||
|
||||
> "DuckDB is the sweet spot: Smallest, most performant embedded database that still supports full SQL. No server process, no credentials, no network — just a file."
|
||||
> — DuckDB 作为嵌入式 CRM 数据库的理由
|
||||
|
||||
> "Chrome profile cloning is a superpower: Instead of fighting OAuth flows and API rate limits, DenchClaw copies your browser's auth state. The agent sees what you see, does what you do."
|
||||
> — Chrome Profile 克隆实现无缝浏览器自动化
|
||||
|
||||
> "One `npx` command beats a weekend of setup: The entire stack installs and configures itself. No Docker, no env files, no dependency hell."
|
||||
> — 一键安装 vs 手动配置的对比
|
||||
|
||||
## Key Concepts
|
||||
- [[File-System-First UI]]：所有设置/视图以文件形式存储，Agent 可直接读写，无需 API 抽象层
|
||||
- [[Chrome Profile Cloning]]：复制浏览器认证状态而非依赖 OAuth，使 Agent 继承用户的登录会话
|
||||
- [[One-Command-Setup]]：通过单一命令自动安装和配置完整技术栈，消除环境配置摩擦
|
||||
- [[DuckDB]]：嵌入式分析型数据库，无服务器、零配置、完全 SQL 支持
|
||||
|
||||
## Key Entities
|
||||
- [[DenchClaw]]：MIT 许可证开源框架，将 OpenClaw 转化为本地 CRM/SaaS 平台
|
||||
- [[OpenClaw]]：多 Agent 框架，DenchClaw 的底层 Agent 引擎
|
||||
- [[DuckDB]]：SQLite 替代品，Analytical DBMS，用于 CRM 结构化数据存储
|
||||
- [[HubSpot]]：CRM 平台示例，DenchClaw 可导入其数据
|
||||
|
||||
## Connections
|
||||
- [[Second Brain]] ← 相关 ← [[local-crm-framework]]：两者均基于 OpenClaw 的记忆/持久化能力
|
||||
- [[personal-crm]] ← 相关 ← [[local-crm-framework]]：个人 CRM 场景的不同实现方案
|
||||
- [[multi-channel-assistant]] ← 共享技术栈 ← [[local-crm-framework]]：均使用 Telegram/消息平台作为交互入口
|
||||
|
||||
## Contradictions
|
||||
（暂无发现与其他 Wiki 页面的内容冲突）
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Multi-Channel AI Customer Service Platform"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/multi-channel-customer-service.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 驱动的多渠道客服统一收件箱，专为小型企业设计，整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一平台。
|
||||
- 问题域：小型企业在多个渠道管理客户消息时面临响应延迟、人工成本高、7×24覆盖困难等问题。
|
||||
- 方法/机制：AI 自动回复处理常见问题（FAQ/预约/咨询），复杂问题转人工，Intent Classification 识别消息类型，语言自动检测并匹配客户语言回复，支持 Test Mode 演示而不影响真实客户。
|
||||
- 结论/价值：餐厅实测将响应时间从 4 小时缩短至 2 分钟以内，80% 的咨询自动处理。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 小型企业需在 WhatsApp、Instagram DMs、邮件、Google Reviews 多个渠道应对客户，7×24 即时响应成本高昂。
|
||||
- AI 统一收件箱将所有渠道整合至一处，AI 自动回复处理 FAQ、预约请求和常见咨询。
|
||||
- Intent Classification 将消息分类为 FAQ → 从知识库回复、Appointment → 确认预约、Complaint → 标记人工审核、Review → 感谢并回应。
|
||||
- Test Mode 使代理商可在不影响真实客户的情况下演示系统。
|
||||
- 餐厅案例：响应时间从 4+ 小时降至 2 分钟以内，80% 咨询自动处理。
|
||||
|
||||
## Key Quotes
|
||||
> "Small businesses juggle WhatsApp, Instagram DMs, emails, and Google Reviews across multiple apps. Customers expect instant responses 24/7, but hiring staff for round-the-clock coverage is expensive." — 问题背景
|
||||
> "One restaurant reduced response time from 4+ hours to under 2 minutes, handling 80% of inquiries automatically." — 实际效果数据
|
||||
|
||||
## Key Concepts
|
||||
- [[Unified-Inbox]]：将多个客服渠道（WhatsApp/Instagram/Email/Review）整合至单一 AI 驱动的收件箱
|
||||
- [[Intent-Classification]]：AI 自动识别客户消息意图（FAQ/Appointment/Complaint/Review）并匹配对应处理策略
|
||||
- [[Human-Handoff]]：复杂问题或投诉自动转交人工客服，AI 仅处理可自动回复的高频问题
|
||||
- [[Test-Mode]]：代理商演示模式，日志记录但实际不发送至真实渠道，不影响现有客户
|
||||
- [[Business-Knowledge-Base]]：AI 客服的知识库，包含服务/定价/营业时间/FAQ/升级触发条件
|
||||
- [[Language-Detection]]：自动检测客户语言（ES/EN/UA）并以对应语言回复
|
||||
- [[AI-Auto-Response]]：基于知识库的自动回复引擎，处理常见问题无需人工介入
|
||||
- [[Heartbeat-Monitoring]]：定时心跳检查，监控未回复消息积压并告警
|
||||
|
||||
## Key Entities
|
||||
- [[WhatsApp-Business-API]]：WhatsApp Business 官方 API，通过 360dialog 或官方渠道接入
|
||||
- [[Instagram-Graph-API]]：Meta Business Suite 的 Instagram 消息 API
|
||||
- [[Gmail]]：通过 gog CLI OAuth 接入 Gmail 收件箱
|
||||
- [[Google-Business-Profile-API]]：Google 商家评价 API，用于管理和回复 Google Reviews
|
||||
- [[OpenClaw]]：AI Agent 框架，支撑消息路由和 AGENTS.md 配置逻辑
|
||||
|
||||
## Connections
|
||||
- [[multi-channel-assistant]] ← extends ← [[multi-channel-customer-service]]：前者侧重个人助理多渠道入口，后者侧重企业客服场景
|
||||
- [[phone-based-personal-assistant]] ← shares_channel_concept ← [[multi-channel-customer-service]]：两者均处理多渠道消息路由，但前者针对个人助理，后者针对企业客服
|
||||
- [[Self-Healing-Home-Server]] ← shares_heartbeat ← [[multi-channel-customer-service]]：两者均使用 Heartbeat 定时检查机制
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本来源与现有 Wiki 来源在场景和目标受众上均可互补。
|
||||
---
|
||||
title: "Multi-Channel AI Customer Service Platform"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/multi-channel-customer-service.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多渠道 AI 客服平台，将 WhatsApp、Instagram、邮件、Google Reviews 等客户触点整合到统一 AI 收件箱
|
||||
- 问题域：中小企业需要在多个平台全天候响应客户，但人工成本高
|
||||
- 方法/机制：AI 自动回复 + 意图分类 + 人工接管；通过 OpenClaw 配置渠道连接；知识库训练业务上下文；AGENTS.md 配置消息路由逻辑；心跳监控检测响应积压
|
||||
- 结论/价值： Futurist Systems 部署案例中，餐厅响应时间从 4+ 小时降至 2 分钟内，80% 的咨询自动处理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI 客服平台整合 WhatsApp Business、Instagram DMs、Gmail、Google Reviews 到统一收件箱
|
||||
- AI 自动回复可处理 FAQ、预约请求和常见咨询，复杂问题升级人工处理
|
||||
- 测试模式允许在不影响真实客户的情况下向客户演示系统
|
||||
- AI 基于企业服务、定价和政策训练，确保回复准确
|
||||
- 多语言检测并以客户语言回复，避免虚构知识库外的信息
|
||||
|
||||
## Key Quotes
|
||||
> "Small businesses juggle WhatsApp, Instagram DMs, emails, and Google Reviews across multiple apps. Customers expect instant responses 24/7, but hiring staff for round-the-clock coverage is expensive." — 问题背景说明
|
||||
> "One restaurant reduced response time from 4+ hours to under 2 minutes, handling 80% of inquiries automatically." — 实际业务效果量化数据
|
||||
|
||||
## Key Concepts
|
||||
- [[UnifiedInbox]]：统一收件箱 — 将多个渠道消息汇聚到单一 AI 驱动界面
|
||||
- [[IntentClassification]]：意图分类 — 识别 FAQ/预约/投诉/评价并触发对应处理流程
|
||||
- [[HumanHandoff]]：人工接管 — 定义升级触发条件，复杂问题转人工处理
|
||||
- [[TestMode]]：测试模式 — 演示系统而不影响真实客户，响应前缀 [TEST]
|
||||
- [[BusinessKnowledgeBase]]：业务知识库 — 训练 AI 掌握服务、定价、营业时间、FAQ
|
||||
- [[HeartbeatMonitoring]]：心跳监控 — 每 30 分钟检查未回复消息并告警
|
||||
|
||||
## Key Entities
|
||||
- [[FuturistSystems]]：部署该方案的公司，为本地服务企业（餐厅、诊所、美容院）提供实施
|
||||
- [[WhatsAppBusiness]]：渠道之一，通过 360dialog 或官方 API 连接
|
||||
- [[Instagram]]：渠道之一，通过 Meta Business Suite 的 Instagram Graph API 连接
|
||||
- [[Gmail]]：渠道之一，通过 gog CLI OAuth 连接
|
||||
- [[GoogleBusinessProfile]]：渠道之一，通过 Google Business Profile API 连接评论
|
||||
|
||||
## Connections
|
||||
- [[WhatsAppBusiness]] ← integrates_with ← [[Multi-ChannelCustomerService]]
|
||||
- [[Instagram]] ← integrates_with ← [[Multi-ChannelCustomerService]]
|
||||
- [[Gmail]] ← integrates_with ← [[Multi-ChannelCustomerService]]
|
||||
- [[GoogleBusinessProfile]] ← integrates_with ← [[Multi-ChannelCustomerService]]
|
||||
- [[Multi-ChannelCustomerService]] ← extends ← [[MultiChannelAssistant]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
@@ -1,52 +1,56 @@
|
||||
---
|
||||
title: "Goal-Driven Autonomous Tasks"
|
||||
type: source
|
||||
tags: ["OpenClaw", "Autonomous Agent", "Task Management", "AI Productivity"]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/overnight-mini-app-builder]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 从被动执行者转变为主动规划者的目标驱动型自主任务系统
|
||||
- 问题域：人们有大目标但难以分解为每日可执行步骤，且执行本身消耗所有时间
|
||||
- 方法/机制：OpenClaw 记忆系统 + 每日自主任务生成 + Kanban 看板追踪 + 过夜 MVP 构建
|
||||
- 结论/价值：将"规划"和"执行"都外包给 AI Agent，用户只需定义目的地，Agent 自动分解并执行每日步骤
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- OpenClaw + 每日任务生成 → 将 AI Agent 从被动工具转变为主动员工
|
||||
- 每日清晨 8:00 自动生成 4-5 个任务，涵盖研究/写作/应用构建/竞品分析/内容创作
|
||||
- 过夜构建惊喜 Mini-App MVP → 每天醒来获得一个贴近目标的新产品原型
|
||||
- Kanban 看板 → 将 AI Agent 变成可追踪的员工，可实时查看进度并纠偏
|
||||
- "Brain Dump 是关键" → 给越多目标上下文，Agent 的每日任务越精准
|
||||
|
||||
## Key Quotes
|
||||
> "Every morning, the agent generates 4-5 tasks it can complete autonomously on your computer." — 每日任务自动生成机制
|
||||
> "You define the destination; the agent figures out the daily steps and walks them." — 核心价值主张
|
||||
> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be." — 最重要的一步
|
||||
> "Keep AUTONOMOUS.md under ~50 lines: goals (one-liners) + open backlog only." — Token 优化原则
|
||||
> "Git never rewrites history, you only add new commits. It eliminates race conditions entirely." — 竞态条件解决思路
|
||||
|
||||
## Key Concepts
|
||||
- [[Kanban]]：看板系统，OpenClaw 自动构建 Next.js 看板追踪任务状态（To Do/In Progress/Done）
|
||||
- [[Autonomous Agent]]：自主代理，具备目标理解、任务分解、自主执行能力的 AI Agent 模式
|
||||
- [[Brain Dump]]：一次性将所有目标/使命/任务倒入 AI 记忆系统，是整个工作流最关键的第一步
|
||||
- [[Sub-Agent Race Condition]]：多子代理并发编辑共享文件导致的竞态条件，解决方案：只追加日志 + 主会话独管状态文件
|
||||
- [[Token-Light Design]]：Token 优化设计，保持 AUTONOMOUS.md 在 50 行以内避免心跳轮询时消耗过多令牌
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：多 Agent 框架，提供 sessions_spawn/sessions_send 能力支撑自主任务执行
|
||||
- [[Alex Finn]]：OpenClaw 资深用户，YouTube 频道分享 Life-changing OpenClaw Use Cases，启发了本工作流
|
||||
|
||||
## Connections
|
||||
- [[Goal-Driven Autonomous Tasks]] ← extends ← [[Second Brain]]
|
||||
- [[Goal-Driven Autonomous Tasks]] ← extends ← [[multi-channel-assistant]]
|
||||
- [[Goal-Driven Autonomous Tasks]] ← extends ← [[Dynamic Dashboard]]
|
||||
- [[Goal-Driven Autonomous Tasks]] ← extends ← [[market-research-product-factory]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project State Management]] 冲突：
|
||||
- 冲突点：看板 vs 事件溯源的任务管理方式
|
||||
- 当前观点：本方案使用 Next.js 构建 Kanban 看板，强调用户可视化追踪
|
||||
- 对方观点：[[Project State Management]] 使用 [[Event Sourcing]] 替代看板，强调自动追踪和完整上下文保留，避免手动拖拽和状态丢失
|
||||
---
|
||||
title: "Goal-Driven Autonomous Tasks"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/overnight-mini-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 从被动执行工具转变为主动的"自我导向型员工"——只需用户一次性输入目标，Agent 每天自动生成、调度并完成推动目标前进的任务，包括夜间自动构建惊喜 Mini-App MVP。
|
||||
- 问题域：大多数人虽有宏大目标，但难以将其拆解为每日可执行的步骤，且执行本身占据全部时间。
|
||||
- 方法/机制：Goal Brain Dump → 每日自主任务生成（4-5项）+ Kanban 追踪 → 可选：夜间 Mini-App 构建流水线。
|
||||
- 结论/价值：将"规划"和"执行"双重重担外包给 AI Agent，用户只需定义目的地，Agent 负责每日跋涉抵达。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **OpenClaw** ← 通过 **goal brain dump + 每日自主任务调度** ← 实现 **从被动工具到自我导向型员工的转变**
|
||||
- **每日任务** ← 覆盖 **研究/写作/脚本/功能构建/内容创作/竞品分析** ← 不限于 App 构建
|
||||
- **Kanban Board** ← 实时追踪 **To Do / In Progress / Done** 三列任务状态 ← 实现 **Agent 工作可视化**
|
||||
- **夜间 Mini-App 构建** ← 通过 **明确指定 MVP 简化要求** ← 实现 **每日惊喜交付**
|
||||
- **Race Condition 风险** ← 由 **主 session 与子 Agent 同时编辑共享文件** ← 导致 **edit 工具静默失败**
|
||||
- **Race Condition 解法** ← 通过 **AUTONOMOUS.md（仅主 session 可写）+ tasks-log.md（仅追加）文件分离** ← 实现 **子 Agent 安全并发**
|
||||
|
||||
## Key Quotes
|
||||
> "Brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be. Don't hold back." — 目标 Brain Dump 是整个工作流的最重要环节，信息越充分，Agent 的每日任务越精准。
|
||||
> "When done, append a ✅ line to `memory/tasks-log.md`. Never edit `AUTONOMOUS.md` directly." — 子 Agent 的黄金规则：只追加，不编辑，防止竞态条件。
|
||||
> "AUTONOMOUS.md stays small, so it costs fewer tokens every time it's loaded in a heartbeat." — 保持 AUTONOMOUS.md 轻量化，减少心跳轮询时的 Token 消耗。
|
||||
|
||||
## Key Concepts
|
||||
- [[Autonomous-Task-Execution]]：AI Agent 自主生成、调度并完成任务，无需用户逐条指令。定义：用户给出目标上下文，Agent 每日主动拆解并执行。
|
||||
- [[Race-Condition-Avoidance]]：多 Agent 并发编辑共享文件时导致的静默失败。解法：分离"可变主文件"（仅主 session 可写）与"只追加日志"（子 Agent 只能追加）。
|
||||
- [[Mini-App-MVP-Pipeline]]：夜间自动构建并交付最小可行产品的流水线。关键约束：不追求完美，明确 MVP 边界。
|
||||
- [[Kanban-Board]]：可视化任务追踪板，三列（To Do / In Progress / Done）实时更新，赋予 Agent 工作可追溯性。
|
||||
- [[Token-Cost-Optimization]]：通过文件轻量化（减少心跳轮询加载的 Token）实现 Agent 运行的隐性成本控制。
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 框架，提供 sessions_spawn / sessions_send 等子 Agent 调度能力，Memory System 支撑长期上下文。
|
||||
- [[Alex Finn]]：OpenClaw 资深用户，该 Goal-Driven Autonomous Tasks 工作流的提出者，发布于其 OpenClaw 生活改变用例系列视频。
|
||||
- [[Next.js]]：Kanban Board 的前端技术栈，OpenClaw 为用户构建。
|
||||
- Telegram / Discord：Agent 与用户的消息通信渠道（集成要求）。
|
||||
|
||||
## Connections
|
||||
- [[autonomous-project-management]] ← extends ← [[Autonomous-Task-Execution]]
|
||||
> 本文档侧重于个人目标驱动的日常任务执行，[[autonomous-project-management]] 侧重于项目维度的多 Agent 协调与进度追踪。
|
||||
- [[dynamic-dashboard]] ← shares_pattern ← [[Kanban-Board]]
|
||||
> 两者均通过可视化面板实现 Agent 产出的可观测性，但 Dynamic Dashboard 面向数据监控，Kanban Board 面向任务管理。
|
||||
- [[OpenClaw]] ← provides_infrastructure ← [[Autonomous-Task-Execution]]
|
||||
> OpenClaw 的 Memory System + sessions_spawn 能力是 Goal-Driven 工作流的技术基础。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[autonomous-project-management]] 的子 Agent 协调机制存在设计张力：
|
||||
- 冲突点：两者均使用子 Agent 执行任务，但对共享状态管理的策略不同。
|
||||
- 当前观点（本页面）：通过文件分离（AUTONOMOUS.md + tasks-log.md）解决竞态，主 session 持有写权限，子 Agent 仅追加日志。
|
||||
- 对方观点（[[autonomous-project-management]]）：采用事件驱动的 Project State Management，通过事件日志替代中心化文件，消除写权限争用。
|
||||
- 说明：两种方案各有取舍，文件分离简单直接但依赖子 Agent 遵守约定；事件驱动更robust但实现复杂度更高。
|
||||
|
||||
@@ -1,49 +1,48 @@
|
||||
---
|
||||
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
|
||||
- 无已知冲突。
|
||||
---
|
||||
title: "Pre-Build Idea Validator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/pre-build-idea-validator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 项目启动前的竞争情报验证机制
|
||||
- 问题域：AI 开发者在没有市场验证的情况下盲目开始构建，导致时间和精力的浪费
|
||||
- 方法/机制：通过 idea-reality-mcp MCP server 扫描 GitHub、Hacker News、npm、PyPI、Product Hunt 五个真实数据源，返回 reality_signal 分数（0-100），作为"预构建门控"决策依据
|
||||
- 结论/价值：在写代码之前先做竞争分析，避免在红海市场中浪费生命；低分空间 = 独立开发者最佳机会窗口
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI Agent（OpenClaw）+ 真实数据源（MCP）→ 在构建前自动评估市场竞争程度 → 避免重复造轮子
|
||||
- reality_signal > 70（高竞争）→ Agent 停止构建，展示前3竞品及 stars 数量 → 触发用户决策（继续/转型/放弃）
|
||||
- reality_signal 30-70（中等竞争）→ 展示竞品 + pivot_hints → 建议差异化角度
|
||||
- reality_signal < 30（低竞争）→ Agent 直接继续构建 → 确认白海空间存在
|
||||
- reality_signal 基于真实数据（repo 数量、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." — Pain Point 场景描述
|
||||
> "This prevents the most expensive mistake in building: solving a problem that's already been solved." — 核心价值主张
|
||||
> "A low score means genuine white space exists. That's where solo builders have the best odds." — 低分即机会
|
||||
|
||||
## Key Concepts
|
||||
- [[Reality-Signal]]：竞争饱和度评分（0-100），基于 GitHub/HN/npm/PyPI/Product Hunt 真实数据计算，数值越高竞争越激烈
|
||||
- [[Pre-Build-Validation]]：在代码编写前进行的市场竞争验证流程，作为 Agent 决策门控
|
||||
- [[Pivot Direction]]：当竞争饱和时，工具给出的差异化转型建议（特定语言/框架/行业垂直）
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：开源 AI Agent 框架，支持 MCP server 集成，通过 agent instructions 实现预构建验证自动化
|
||||
- [[idea-reality-mcp]]：MCP server，扫描5个平台返回竞争评分和竞品信息，由 mnemox.ai 开发
|
||||
- [[mnemox.ai]]：idea-reality-mcp 的开发者和维护者，提供 Web demo（mnemox.ai/check）
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← uses ← [[idea-reality-mcp]]
|
||||
- [[Pre-Build-Validation]] ← gate_for ← [[autonomous-project-management]]
|
||||
- [[Reality-Signal]] ← used_by ← [[multi-agent-team]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[autonomous-project-management]] 的潜在张力：
|
||||
- 冲突点：自主性边界——Pre-Build Validator 强制 Agent STOP（高竞争时），而 autonomous-project-management 强调 Agent 应持续推进减少人工干预
|
||||
- 当前观点：Pre-Build Validator 认为高竞争时的"停止"是必要的成本控制机制
|
||||
- 对方观点：autonomous-project-management 倾向于让 Agent 自主决策并持续迭代，人工仅在关键节点介入
|
||||
|
||||
@@ -1,56 +1,45 @@
|
||||
---
|
||||
title: "Todoist Task Manager"
|
||||
type: source
|
||||
tags: [agent, productivity, task-management, automation, ai]
|
||||
date: 2026-04-21
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/todoist-task-manager.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 通过 Todoist API 实现自然语言驱动的任务管理自动化
|
||||
- 问题域：个人/团队任务管理的效率瓶颈——手动创建任务、设置截止日期、分配优先级耗时且易遗漏
|
||||
- 方法/机制：Agent 解析用户自然语言指令 → 调用 Todoist REST API 创建/更新/查询任务 → 定时 Cron Job 主动提醒未完成任务
|
||||
- 结论/价值：用户只需发一条消息即可完成"创建任务+设截止+加标签+分配项目"全套操作，AI 主动追踪逾期任务并定期推送简报
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent 通过自然语言理解，将"这周完成 Q1 报告"转换为 Todoist API 的结构化任务创建请求（主体+截止+项目+标签）
|
||||
- Todoist Sync API 支持实时双向同步，Agent 创建的任务可立即在 Todoist Web/移动端查看，反之亦然
|
||||
- Cron Job 定时扫描 Todoist 的"逾期任务"过滤器，主动推送提醒消息，比用户手动检查更可靠
|
||||
- 与日历工具（Google Calendar）联动：会议结束后自动创建跟进任务，实现"会议即任务"的闭环
|
||||
|
||||
## Key Quotes
|
||||
> "Simply message your AI agent: 'Remind me to call the dentist every 6 months' and it creates a recurring Todoist task with the right interval — no manual setup needed." — 使用场景示例
|
||||
|
||||
> "The agent monitors your Todoist inbox, extracting tasks from emails and messages, then categorizes and schedules them automatically." — 自动化任务录入
|
||||
|
||||
## Key Concepts
|
||||
- [[Todoist REST API]]：Todoist 官方 API，支持任务创建/更新/查询/评论，OAuth2 认证
|
||||
- [[Todoist Sync API]]：实时双向同步协议，支持 WebSocket 推送变更
|
||||
- [[Recurring Tasks]]：重复任务机制，支持自然语言周期描述（every Monday, every 6 months）
|
||||
- [[AI-Driven Task Extraction]]：从非结构化文本（邮件/消息/会议记录）中提取任务要素（谁/做什么/何时）
|
||||
- [[Task Automation Pipeline]]：自然语言 → 结构化解析 → API 调用 → 结果确认
|
||||
- [[Morning Briefing Integration]]：Todoist 逾期任务/今日任务接入晨间简报
|
||||
- [[Meeting-to-Task Workflow]]：会议结束 → 自动创建跟进任务 → 分配截止和项目
|
||||
|
||||
## Key Entities
|
||||
- [[Todoist]]：Doist 公司开发的跨平台任务管理工具，支持多设备同步、标签、项目、子任务
|
||||
- [[Todoist AI（Beta）]]：Todoist 内置的 AI 功能，支持自然语言创建任务，但 Agent 集成提供更深度的工作流自动化
|
||||
- [[Doist]]：Todoist 背后的公司，同时开发 Twist（团队沟通）和 Corona（健康追踪）
|
||||
- [[OpenClaw]]：多 Agent 框架，通过 sessions_spawn/sessions_send 调用外部 API，可集成 Todoist API 实现任务自动化
|
||||
- [[SuperCall]]：AI 语音电话系统，与 Todoist 结合可实现"电话确认任务 → 自动创建 Todoist 项目"的语音驱动工作流
|
||||
|
||||
## Connections
|
||||
- [[Custom Morning Brief]] ← depends_on ← [[Todoist Task Manager]]：Todoist 的今日任务和逾期任务构成晨报的重要内容来源
|
||||
- [[Phone-Based Personal Assistant]] ← extends ← [[Todoist Task Manager]]：语音指令 → Agent 解析 → Todoist API 创建任务
|
||||
- [[Multi-Channel Assistant]] ← depends_on ← [[Todoist Task Manager]]：Telegram/Discord/iMessage 的文字指令最终汇聚到 Todoist 作为任务执行层
|
||||
- [[Event Guest Confirmation]] ← extends ← [[Todoist Task Manager]]：确认出席的客人 → 自动创建"发送地址/准备材料"等跟进任务
|
||||
- [[Market Research & Product Factory]] ← extends ← [[Todoist Task Manager]]：AI 发现的产品机会 → 自动创建"验证 MVP/写 PRD"等任务并追踪
|
||||
- [[Todoist Task Manager]] ← depends_on ← [[n8n]]：n8n Workflow 可作为 Todoist 与其他工具（邮件/日历/CRM）集成的中间层
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project State Management]] 冲突：
|
||||
- 冲突点：Todoist 是传统的"任务列表+截止日"模式；[[Project State Management]] 强调用 Markdown 事件流记录每个决策/进展
|
||||
- 当前观点：对于简单任务管理，Todoist 的结构化字段（截止/优先级/项目）更直观，Agent API 调用简单
|
||||
- 对方观点：Markdown 事件流保留完整上下文，支持任意扩展字段，不需要账号授权，数据完全自托管
|
||||
---
|
||||
title: "Todoist Task Manager: Agent Task Visibility"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/todoist-task-manager.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 长时任务的可视化进度追踪系统，通过 Todoist 实现 Agent 内部推理外部化
|
||||
- 问题域：Agent 执行复杂多步任务（如构建全栈应用、深度研究）时，用户无法实时了解 Agent 在做什么、已完成哪些步骤、卡在哪里
|
||||
- 方法/机制：利用 Todoist 项目 + 分区（🟡 In Progress / 🟠 Waiting / 🟢 Done）+ Bash 脚本封装 REST API，实现：① 任务状态可视化 ② Agent 计划外化到任务描述 ③ 实时追加子步骤日志为评论 ④ 心跳脚本检测停滞任务并通知用户
|
||||
- 结论/价值：用户无需手动翻查聊天记录，在 Todoist 中即可透明查看 Agent 进展，提高多 Agent 协作和后台任务的可用性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Todoist 分区标签（🟡🟠🟢）可有效区分任务状态，提升可视化效果
|
||||
- 将 Agent 内部 Plan 外化到任务描述，可提升任务执行透明度
|
||||
- 子步骤日志以评论形式实时追加，可在不污染主对话的前提下保留完整执行轨迹
|
||||
- 心跳脚本自动检测停滞任务并通知用户，实现 Agent 故障的被动告警
|
||||
- 该方案无需预装 Skill，Agent 可通过 prompt 自主构建所需的 Bash 脚本
|
||||
|
||||
## Key Quotes
|
||||
> "When agents run complex, multi-step tasks (like building a full-stack app or performing deep research), the user often loses track of what the agent is currently doing, what steps have been completed, and where the agent might be stuck." — 痛点描述
|
||||
> "You don't need a pre-built skill. Simply prompt your OpenClaw agent to create the bash scripts described in the **Setup Guide** below." — 方案亮点：无需预装，直接 prompt 生成
|
||||
|
||||
## Key Concepts
|
||||
- [[TaskVisibility]]：AI Agent 任务执行过程的可视化透明度，使人类用户能追踪 Agent 的当前状态、已完成步骤和潜在阻塞
|
||||
- [[AgenticWorkflow]]：多步骤、长时间运行的 AI Agent 任务执行流程，需外部状态同步机制辅助用户理解
|
||||
- [[ExternalReasoning]]：将 Agent 内部推理过程外化到外部系统（如 Todoist）的方法，提高 Agent 行为的可观测性
|
||||
|
||||
## Key Entities
|
||||
- [[Todoist]]：任务管理工具，通过 REST API 实现任务创建、更新、评论功能；提供项目（Project）和分区（Section）组织结构
|
||||
- [[OpenClaw]]：OpenClaw 的工作空间，文中作为 Agent 的执行环境；支持文件系统管理和 shell 命令执行，可通过 prompt 自主构建 Todoist 集成脚本
|
||||
- [[TodoistRestApi]]：Todoist 官方 REST API v2，支持任务（Tasks）、评论（Comments）等端点的 CRUD 操作
|
||||
|
||||
## Connections
|
||||
- [[Todoist]] ← 使用 REST API ← [[TodoistTaskManager]]
|
||||
- [[OpenClaw]] ← 作为 Agent 执行环境 ← [[TodoistTaskManager]]
|
||||
- [[ProjectStateManagement]] ← 任务状态管理相关 ← [[TodoistTaskManager]]
|
||||
- [[AgenticWorkflow]] ← 属于更广泛的 Agent 任务编排范畴 ← [[TodoistTaskManager]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ProjectStateManagement]]：两者均关注任务状态管理，但 Project State Management 使用事件驱动方案（替代看板），而 Todoist Task Manager 直接利用现成 SaaS（Todoist）实现；应用场景不同，无直接冲突
|
||||
|
||||
Reference in New Issue
Block a user