wiki-ingest: 4 Agent Use Cases (autonomous PM, content factory, product factory, knowledge base RAG) - 2026-04-15 evening batch
This commit is contained in:
@@ -11,41 +11,75 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 14 Octane Hub on AWS Real life experience moving production services into the new land
|
||||
# CTP Topic 14 Octane Hub on AWS: Real-Life Experiences
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 14_ Octane Hub on AWS_ Real life experience moving production services into the new land.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成摘要
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
Holger Rode(Octane Hub CTO 软件工厂团队负责人)分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。Octane Hub 团队主要使用 Docker 容器运行,之前托管在 Bibling Lab,拥有三台物理服务器和多台虚拟机。
|
||||
|
||||
### 现有工作负载
|
||||
|
||||
这些容器运行各种 Web 应用程序,包括 QuickSee、Release Manager、Patch Manager 和安全程序板。他们还处理后台作业,如支持集成、数据复制和内部空闲搜索。团队还管理大约 10TB 的文件存储和大型 MSSQL 服务器数据库。
|
||||
|
||||
### 云迁移动因
|
||||
|
||||
由于 Bibling 数据中心即将关闭,云迁移变得紧迫。云转型计划提供了帮助,团队在 5 月左右获得了概念验证 Landing Zone 账户的访问权限,随后在 6 月获得了生产账户。团队目标是实现无缝过渡,紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更。
|
||||
|
||||
### 技术选型与挑战
|
||||
|
||||
- 使用 AWS 定价计算器了解服务成本
|
||||
- 最初考虑 EFS 用于存储,但由于性能问题(数据库无法直接在 EFS 上运行)不适用
|
||||
- 改用 EBS 用于实时数据库,EFS 用于备份
|
||||
- 部署方式:从控制台脚本演变为使用 Packer 构建 AMI,使用 Terraform/TerraGrunt 部署
|
||||
- 网络问题需要多次 PCS 请求,与网络团队协作解决
|
||||
- 使用 VPC Transit Gateway 并实施标签系统管理访问
|
||||
- DNS 设置:使用 Cname 指向 AWS software infra.net 域,通过 Route 53 管理
|
||||
|
||||
### 下一步计划
|
||||
|
||||
- 改进 DR 和高可用性
|
||||
- 通过最佳匹配存储选项(S3)进行成本优化
|
||||
- 从 MSSQL 迁移到 Postgres
|
||||
- 可能迁移到 AWS ECS 服务
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **Docker 容器化**: Octane Hub 的主要部署模式
|
||||
- **Packer + Terraform/TerraGrunt**: 基础设施即代码的部署流程
|
||||
- **VPC Transit Gateway**: AWS 网络互联解决方案
|
||||
- **标签系统**: 基于角色和环境管理资源访问
|
||||
- **EFS vs EBS**: 文件存储与块存储的性能差异
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
- [ ] 评估现有工作负载是否适合容器化
|
||||
- [ ] 规划数据库从 MSSQL 到 Postgres 的迁移路径
|
||||
- [ ] 检查 EBS/EFS 存储选型是否合理
|
||||
- [ ] 制定 DR 和高可用性改进计划
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接(生成后填入)
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-7-saas-landing-zone-design.md]] — SaaS Landing Zone 设计
|
||||
> [[ctp-topic-25-labs-landing-zone-overview-itom-teams.md]] — Labs Landing Zone 概述
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -11,7 +11,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 44_ AWS Backup in Micro Focus.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 44 AWS Backup in Micro Focus
|
||||
@@ -20,32 +20,68 @@ status: raw
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成摘要
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
AWS Backup 是一个托管服务,用于在 AWS 云中集中化和自动化数据保护。它支持跨账户和跨区域备份,并提供不可变性以防止勒索软件等威胁。该服务为 S3 和 RDS 等服务提供时间点恢复,潜在恢复时间可在 1 秒以内。它还支持法律保留,允许隔离特定备份并保留以满足合规性要求。
|
||||
|
||||
### 灾难恢复策略
|
||||
|
||||
灾难恢复策略根据恢复时间目标(RTO)和恢复点目标(RPO)而有所不同。四种主要策略是:
|
||||
|
||||
- **备份和恢复**:适用于恢复时间为数小时的低优先级情况。
|
||||
- **Pilot Light**:数据复制到 DR 区域,允许在 1 小时内恢复。
|
||||
- **Warm Standby**:应用程序在生产和 DR 区域以较小规模运行,可在几分钟内恢复。
|
||||
- **Active-Active**:提供近乎零停机和数据丢失,但成本最高,应用程序在两个区域同时运行。
|
||||
|
||||
### 当前 AWS 备份流程
|
||||
|
||||
目前,应用程序所有者管理 EC2、EBS、EFS、S3 和数据库等资源的快照。这些快照在 CCIE 门户中注册,并根据标签复制到 DR 区域。对于客户管理的密钥,会执行转换过程。CCIE 门户更新标签以跟踪备份过程并提供错误通知。
|
||||
|
||||
### 当前流程的差距
|
||||
|
||||
当前备份流程是分散的,涉及多个团队,增加了错误风险。快照存储在与资源相同的账户中,一旦账户被攻破会带来风险。CCIE vault 将快照复制到不同区域,但由于成本原因,保留期仅限于三天。备份不是不可变的,CCIE vault 需要新插件来支持新的 AWS 服务。产品组之间的保留期不一致。
|
||||
|
||||
### AWS Backup 详情
|
||||
|
||||
AWS Backup 加密所有备份,包括静态和传输中的数据。一个限制是它无法排除附加到 EC2 实例的特定卷,强制备份所有附加卷。Amazon 不再建议数据库使用热备份,指出快照是崩溃一致的,支持增量备份。
|
||||
|
||||
### 演示亮点
|
||||
|
||||
演示展示了创建备份保管库(用于加密 AWS 备份)、创建备份计划(每日、每小时或自定义计划)、启用 S3 和 RDS 的时间点恢复、按需备份以及从备份保管库恢复(创建新的 EBS 卷或 RDS 实例)。该服务支持基于角色的访问控制,可以使用 CloudWatch 进行监控。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **AWS Backup**: AWS 托管的集中化数据保护服务
|
||||
- **不可变性 (Immutability)**: 防止备份被篡改或删除
|
||||
- **RTO (Recovery Time Objective)**: 恢复时间目标
|
||||
- **RPO (Recovery Point Objective)**: 恢复点目标
|
||||
- **备份和恢复**: 最基本的 DR 策略,适合低优先级场景
|
||||
- **法律保留 (Legal Holds)**: 用于合规性保留特定备份
|
||||
- **CCIE 门户**: 当前管理快照的内部平台
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
- [ ] 评估现有备份流程是否需要迁移到 AWS Backup
|
||||
- [ ] 审查当前备份的 RTO/RPO 是否满足业务需求
|
||||
- [ ] 考虑跨账户和跨区域备份以提高韧性
|
||||
- [ ] 检查数据库备份是否还在使用热备份模式(不推荐)
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接(生成后填入)
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] — 企业级 DR 策略实施
|
||||
> [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md]] — CTP AWS Backup 实施
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -11,7 +11,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 13_ Cloud FinOps_ Micro Focus Policies _ best practices to optimize the costs.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs
|
||||
@@ -20,32 +20,83 @@ status: raw
|
||||
|
||||
**Type:** VIDEO | **Category:** 05_FinOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成摘要
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
本次云转型学习会议的主题是"Cloud FinOps: Micro Focus 政策与成本优化最佳实践"。由 PCG(Public Cloud Governance)团队的 Uday 和 Vinay 主讲。
|
||||
|
||||
### 核心内容
|
||||
|
||||
1. **PCG 服务分层**
|
||||
- **成本管理**:账单支付、showback/chargeback、预算管理
|
||||
- **成本优化**:组织级和账户级优化,包括购买 Reserved Instances 和识别未充分利用的资源
|
||||
- **治理与自动化**:集中式上线、策略开发、自动报告
|
||||
|
||||
2. **核心策略**
|
||||
- **可见性**:确保账单可见
|
||||
- **标签合规**:强制标签要求
|
||||
- **预算责任**:账户负责人负责控制在预算内
|
||||
- **集中管理**:集中管理 Reserved Instances 和 Savings Plans
|
||||
- **区域限制**:限制区域使用以优化成本、安全和管理
|
||||
|
||||
3. **安全策略**
|
||||
- 预安装 Godrails
|
||||
- 通过联合身份管理访问(MFA 即将推出)
|
||||
- 供应商告警重定向到安全团队
|
||||
- 账户负责人需提供公共分发列表(PDL)用于告警
|
||||
- Cloud Security Postal Management 工具正在实施
|
||||
|
||||
4. **最佳实践**
|
||||
- 使用计算器了解成本
|
||||
- 检查资源清单
|
||||
- 监控月度账单
|
||||
- **Cloud Health**:关键工具,提供资源清单、成本分析和月度账单洞察
|
||||
- 标准化实例类型:
|
||||
- M 系列:通用场景
|
||||
- T 系列:突发性工作负载
|
||||
- C 系列:计算密集型应用
|
||||
- R/X 系列:内存优化工作负载
|
||||
- 使用 Graviton 实例节省成本
|
||||
|
||||
5. **研发环境优化**
|
||||
- 使用突发性实例
|
||||
- 使用实例调度器
|
||||
- 使用 Spot 实例
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **PCG (Public Cloud Governance)**:公共云治理框架,提供工作负载放置、成本和优化指导
|
||||
- **Showback/Chargeback**:成本分摊机制
|
||||
- **Cloud Health**:云成本分析和监控工具
|
||||
- **Godrails**:预安装安全控制
|
||||
- **Reserved Instances / Savings Plans**:承诺计划用于成本优化
|
||||
- **Graviton**:AWS ARM 处理器,比 Intel 更便宜
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
- [ ] 了解 Cloud Health 工具的使用
|
||||
- [ ] 审查并标准化实例类型选择
|
||||
- [ ] 确保所有资源使用正确的标签
|
||||
- [ ] 探索 Graviton 实例用于兼容的工作负载
|
||||
- [ ] 在研发环境中实施实例调度器
|
||||
- [ ] 检查月度账单并识别优化机会
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接(生成后填入)
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-63-optimise-resource-cost-using-automation.md]] — 深入讲解自动化调度优化资源成本
|
||||
> [[ctp-topic-27-aws-instance-scheduler.md]] — AWS 实例调度器详解
|
||||
> [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md]] — Rightsizing 最佳实践
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
27
wiki/concepts/Pattern-Key.md
Normal file
27
wiki/concepts/Pattern-Key.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Pattern-Key"
|
||||
type: concept
|
||||
tags: [self-improving, memory, pattern, tracking]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
经验记录(LEARNINGS.md)的唯一标识键,格式为 domain.subdomain(如 cron.telegram-delivery),用于发现重复踩坑和追踪系统性错误。
|
||||
|
||||
## Core Mechanism
|
||||
- 格式:点分层级,如 cron.daily-self-review / cron.telegram-delivery / cron.naming-convention
|
||||
- 用途:通过相同 Pattern-Key 发现同一问题的多次记录
|
||||
- 决策信号:Pattern-Key 重复出现 = 系统性问题需系统性解决,而非单点修复
|
||||
|
||||
## Example
|
||||
| Pattern-Key | 出现次数 | 含义 |
|
||||
|---|---|---|
|
||||
| cron.daily-self-review | 9次 | 每日复盘,持续活跃优化领域 |
|
||||
| cron.telegram-delivery | 2次 | Telegram 通知配置,第一次记了第二次解决 |
|
||||
|
||||
## Key Insight
|
||||
Pattern-Key 重复本身是信号——第一次记了,第二次就该解决了。Recurrence-Count ≥ 2 说明这不是偶发错误。
|
||||
|
||||
## Connections
|
||||
- [[Self-Improving Skill]] ← 核心机制 ← [[Pattern-Key]]
|
||||
- [[Recurrence-Count]] ← 量化 ← [[Pattern-Key]]
|
||||
23
wiki/concepts/Recurrence-Count.md
Normal file
23
wiki/concepts/Recurrence-Count.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Recurrence-Count"
|
||||
type: concept
|
||||
tags: [self-improving, memory, tracking, systematic-error]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
经验记录的重复次数计数器,记录同一 Pattern-Key 出现的次数,用于区分偶发一次性错误与需系统性解决的重复问题。
|
||||
|
||||
## Core Mechanism
|
||||
- 初始值:1(新记录)
|
||||
- 递增:同一 Pattern-Key 再次出现时 +1
|
||||
- 决策阈值:Recurrence-Count ≥ 2 说明这是重复问题,不是偶发错误
|
||||
|
||||
## Key Insight
|
||||
- Recurrence-Count = 1:一次性错误,记录后不再出现,关注 Suggested Action 即可
|
||||
- Recurrence-Count ≥ 2:系统性重复,需要检查上一次是否真正解决了根本原因
|
||||
- 高 Recurrence-Count(9次如 cron.daily-self-review):说明这是持续活跃的优化领域,每次复盘都在积累
|
||||
|
||||
## Connections
|
||||
- [[Pattern-Key]] ← 追踪 ← [[Recurrence-Count]]
|
||||
- [[Self-Improving Skill]] ← 量化机制 ← [[Recurrence-Count]]
|
||||
41
wiki/concepts/STATE-yaml.md
Normal file
41
wiki/concepts/STATE-yaml.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "STATE.yaml"
|
||||
type: concept
|
||||
tags: [coordination, multi-agent, state-management]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
去中心化项目协调文件格式,YAML 结构定义任务 ID、状态(in_progress/done/blocked)、owner、开始时间、备注、blocked_by 依赖关系。所有 agent 读写同一文件实现协调。
|
||||
|
||||
## Format Structure
|
||||
```yaml
|
||||
project: project-name
|
||||
updated: ISO-timestamp
|
||||
|
||||
tasks:
|
||||
- id: task-id
|
||||
status: in_progress | done | blocked
|
||||
owner: agent-label
|
||||
started: ISO-timestamp
|
||||
completed: ISO-timestamp
|
||||
blocked_by: other-task-id
|
||||
notes: "描述"
|
||||
|
||||
next_actions:
|
||||
- "agent-label: 具体下一步行动"
|
||||
```
|
||||
|
||||
## Key Properties
|
||||
- 单一事实来源(Single Source of Truth)
|
||||
- Git 版本控制可获取完整变更历史
|
||||
- blocked_by 字段实现自动依赖触发
|
||||
|
||||
## Compared To
|
||||
- [[Multi-Agent Hierarchy]]:层级架构 vs 平铺协调
|
||||
- [[共享内存模式]]:内存读写 vs 文件持久化
|
||||
|
||||
## Key Connections
|
||||
- [[Autonomous Project Management]] ← 核心协调机制
|
||||
- [[GitOps]] ← 审计日志集成
|
||||
- [[去中心化协调]] ← 协调模式
|
||||
42
wiki/concepts/Self-Improving-Skill.md
Normal file
42
wiki/concepts/Self-Improving-Skill.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Self-Improving Skill"
|
||||
type: concept
|
||||
tags: [openclaw, self-improvement, memory, agent, learning]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
OpenClaw 自改进技能,通过结构化经验记录系统让 Agent 在错误中学习、持续进化,避免同一错误重复出现。
|
||||
|
||||
## Core Mechanism
|
||||
- 工具:self_improvement_log,写入 LEARNINGS.md 或 ERRORS.md
|
||||
- 固定格式:Summary + Details + Suggested Action + Metadata(Pattern-Key/Recurrence-Count/See Also)
|
||||
- 记录类型:correction(错误修正)/ workflow(流程改进)/ config(配置发现)/ best_practice(最佳实践)
|
||||
|
||||
## Key Insight
|
||||
- 错误只犯一次:Pattern-Key 相同的问题第二次出现时应直接应用 Suggested Action
|
||||
- Recurrence-Count 是核心指标:重复次数高的 Pattern-Key 需要系统性解决,而非单点修复
|
||||
- Pattern-Key 重复本身是信号:第一次记了,第二次就该解决了
|
||||
|
||||
## LEARNINGS.md 格式示例
|
||||
```markdown
|
||||
## [LRN-20260325-001] correction
|
||||
**Logged**: 2026-03-25T14:09:53+08:00
|
||||
**Priority**: high
|
||||
**Status**: pending
|
||||
**Area**: config
|
||||
### Summary
|
||||
Telegram chat ID 在 cron job 配置中不应使用 "user:" 前缀
|
||||
### Details
|
||||
使用了 `--to user:5038825565` 格式,导致报错
|
||||
### Suggested Action
|
||||
使用纯数字 chat ID:`--to 5038825565`
|
||||
### Metadata
|
||||
- Pattern-Key: cron.telegram-delivery
|
||||
- Recurrence-Count: 1
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[双层记忆架构]] ← 包含 ← [[Self-Improving Skill]]
|
||||
- [[Pattern-Key]] ← 核心机制 ← [[Self-Improving Skill]]
|
||||
- [[每日复盘]] ← 触发 ← [[Self-Improving Skill]]
|
||||
26
wiki/concepts/Vibe-Kanban.md
Normal file
26
wiki/concepts/Vibe-Kanban.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Vibe-Kanban"
|
||||
type: concept
|
||||
tags: [vibe-coding, kanban, opencode, ubuntu, ai-pair-programming]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 结对编程任务看板,通过 Web UI(PORT 9999)管理编程任务,自动 spawn OpenCode Executor 在随机端口执行 AI 编程。
|
||||
|
||||
## Core Mechanism
|
||||
- 启动:RUST_LOG=debug HOST=0.0.0.0 PORT=9999 npx vibe-kanban
|
||||
- 自动 spawn:vibe-kanban 启动后自动 spawn executor(随机端口),无需手动启动
|
||||
- 工作目录:/var/tmp/vibe-kanban/worktrees/(需 shenwei 用户权限)
|
||||
- 配置目录:~/.vibe-kanban
|
||||
- 清理:rm -rf /var/tmp/vibe-kanban/worktrees/* ~/.vibe-kanban(解决权限/端口问题)
|
||||
|
||||
## Key Constraints
|
||||
- 不要用 root 启动 OpenCode serve
|
||||
- I/O error 通常是 executor 没启动或端口被占用
|
||||
- executor 随 vibe-kanban 进程一起管理,不单独用 pm2 管理
|
||||
|
||||
## Connections
|
||||
- [[Vibe-Kanban]] ← spawns ← [[OpenCode Executor]]
|
||||
- [[nvm]] ← 提供 Node ← [[Vibe-Kanban]]
|
||||
- [[pm2]] ← 管理进程 ← [[Vibe-Kanban]]
|
||||
21
wiki/concepts/nvm.md
Normal file
21
wiki/concepts/nvm.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "nvm"
|
||||
type: concept
|
||||
tags: [node, version-manager, ubuntu, installation]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Node Version Manager,通过 curl -fsSL 安装,管理多个 Node.js 版本,解决系统包版本冲突问题。
|
||||
|
||||
## Core Mechanism
|
||||
- 安装:curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
|
||||
- 环境变量:export NVM_DIR="$HOME/.nvm",[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
|
||||
- 常用命令:nvm install 20 / nvm use 20 / nvm alias default 20
|
||||
|
||||
## Use Case
|
||||
Ubuntu Server 安装 Node 20 以支持 Vibe-Kanban 和 OpenCode,避免系统包管理器版本过旧。
|
||||
|
||||
## Connections
|
||||
- [[Node 20]] ← 版本 ← [[nvm]]
|
||||
- [[Vibe-Kanban]] ← 依赖 ← [[nvm]]
|
||||
24
wiki/concepts/pm2.md
Normal file
24
wiki/concepts/pm2.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "pm2"
|
||||
type: concept
|
||||
tags: [process-manager, node, ubuntu, vibe-coding]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Node.js 进程管理器,提供进程守护、日志管理、开机自启功能,适合生产环境长期运行 Node 服务。
|
||||
|
||||
## Core Mechanism
|
||||
- 安装:npm install -g pm2
|
||||
- 启动:pm2 start "command" --name <app-name>
|
||||
- 日志:pm2 logs <app-name>
|
||||
- 保存:pm2 save(保存当前进程列表)
|
||||
- 开机自启:pm2 startup systemd -u <user> --hp <home-dir>
|
||||
- 进程列表:pm2 status
|
||||
|
||||
## Use Case
|
||||
管理 Ubuntu Server 上的 Vibe-Kanban Web UI 进程(PORT 9999),确保服务持续运行并开机自启。
|
||||
|
||||
## Connections
|
||||
- [[pm2]] ← 管理 ← [[Vibe-Kanban]]
|
||||
- [[OpenCode Executor]] ← spawn by ← [[Vibe-Kanban]]
|
||||
32
wiki/concepts/个人知识库.md
Normal file
32
wiki/concepts/个人知识库.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "个人知识库"
|
||||
type: concept
|
||||
tags: [rag, memory, knowledge-management, agent]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
基于 RAG 的个人第二大脑系统:自动从任意 URL 摄取内容(文章/tweets/YouTube/PDF),向量嵌入存储,语义搜索返回 ranked 结果+来源引文。支持其他 agent 工作流查询。
|
||||
|
||||
## Architecture
|
||||
```
|
||||
URL Drop → Content Fetch → Chunking → Embedding → Vector Store
|
||||
↓
|
||||
Query → Semantic Search → Ranked Results + Citations
|
||||
```
|
||||
|
||||
## Key Properties
|
||||
- 零摩擦摄入:Telegram/Slack 发 URL 即可
|
||||
- 语义搜索:自然语言查询,非关键词匹配
|
||||
- Source-grounding:每个回答附带原文引文
|
||||
- 主动供给:其他工作流可自动查询知识库
|
||||
|
||||
## Compared To
|
||||
- [[NotebookLM]]:NotebookLM 侧重已有文档管理,本概念侧重实时 URL 摄入+语义搜索
|
||||
- [[双层记忆架构]]:本概念是外部知识管理,vs 双层记忆是 agent 自身经验积累
|
||||
|
||||
## Key Connections
|
||||
- [[Personal Knowledge Base RAG]] ← 应用场景
|
||||
- [[RAG]] ← 技术基础
|
||||
- [[向量数据库]] ← 存储基础设施
|
||||
- [[Embedding]] ← 语义表示
|
||||
27
wiki/concepts/产品工厂.md
Normal file
27
wiki/concepts/产品工厂.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "产品工厂"
|
||||
type: concept
|
||||
tags: [agent, product, entrepreneurship, automation]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
市场研究到 MVP 构建的自动化管线:Last30Days 挖掘 Reddit/X 真实用户痛点 → ranked pain points → 选择痛点 → OpenClaw 构建 MVP → 用户验证。零技术要求,全流程通过对话完成。
|
||||
|
||||
## Pipeline
|
||||
```
|
||||
Last30Days 研究 → 痛点排名 → 选择痛点 → OpenClaw 构建 MVP → 分享验证
|
||||
```
|
||||
|
||||
## Key Properties
|
||||
- 真实数据驱动:用户帖子而非调查数据
|
||||
- 无需编码:OpenClaw 完成研究和构建
|
||||
- 每周定时研究保持市场洞察持续更新
|
||||
- 可从小痛点开始验证市场需求
|
||||
|
||||
## Key Connections
|
||||
- [[Market Research Product Factory]] ← 应用场景
|
||||
- [[Last30Days]] ← 研究能力
|
||||
- [[Content Factory]] ← 共享研究基础设施
|
||||
- [[AI产品经理]] ← 能力要求
|
||||
- [[超级个体]] ← 适用人群
|
||||
29
wiki/concepts/内容工厂.md
Normal file
29
wiki/concepts/内容工厂.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "内容工厂"
|
||||
type: concept
|
||||
tags: [agent, content, workflow, automation]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
多 agent 链式协作的内容创作管线:Research Agent 扫描趋势 → Writing Agent 生成脚本 → Thumbnail Agent 生成配图,全流程定时自动执行,结果输出到 Discord channel 供人工 review。
|
||||
|
||||
## Architecture
|
||||
```
|
||||
Research Agent → [趋势报告] → Writing Agent → [脚本/文章] → Thumbnail Agent → [配图]
|
||||
↓ ↓ ↓
|
||||
#research #scripts #thumbnails
|
||||
```
|
||||
|
||||
## Key Properties
|
||||
- 链式 agent:前序输出自动喂给后序
|
||||
- 平台无关:可适配 tweets/newsletter/LinkedIn/posts/podcast/blog
|
||||
- 定时执行:每日 8AM 自动运行
|
||||
- 本地模型(Nano Banana)降低图像生成成本
|
||||
|
||||
## Key Connections
|
||||
- [[Content Factory]] ← 应用场景
|
||||
- [[Market Research Product Factory]] ← 共享研究基础设施
|
||||
- [[Last30Days]] ← Research Agent 数据来源
|
||||
- [[baoyu-imagine]] ← 图像生成能力
|
||||
- [[Discord 集成]] ← 输出 channel
|
||||
29
wiki/concepts/去中心化协调.md
Normal file
29
wiki/concepts/去中心化协调.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "去中心化协调"
|
||||
type: concept
|
||||
tags: [multi-agent, coordination, architecture]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
多 agent 系统中无中央 orchestrator,各 agent 通过共享状态文件自主协调的架构模式。与中央协调模式相对,优势在于无单点瓶颈、高扩展性、高韧性。
|
||||
|
||||
## Key Properties
|
||||
- 无中央 orchestrator,各 agent 自主读写共享状态
|
||||
- 状态文件(如 [[STATE.yaml]])作为协调媒介
|
||||
- Agent 间无需直接通信,降低耦合
|
||||
- 失败隔离:一个 agent 崩溃不影响其他 agent
|
||||
|
||||
## Trade-offs
|
||||
| 维度 | 去中心化协调 | 中央 orchestrator |
|
||||
|------|------------|----------------|
|
||||
| 扩展性 | 高(线性扩展) | 低(主节点瓶颈) |
|
||||
| 全局控制 | 弱 | 强 |
|
||||
| 失败韧性 | 高 | 低(单点故障) |
|
||||
| 实现复杂度 | 中(需状态管理) | 低(结构简单) |
|
||||
|
||||
## Key Connections
|
||||
- [[Autonomous Project Management]] ← 应用场景
|
||||
- [[STATE.yaml]] ← 协调媒介
|
||||
- [[Multi-Agent Hierarchy]] ← 对比:层级协调
|
||||
- [[Multi-Agent Consensus]] ← 对比:共识协调
|
||||
36
wiki/concepts/双层记忆架构.md
Normal file
36
wiki/concepts/双层记忆架构.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "双层记忆架构"
|
||||
type: concept
|
||||
tags: [openclaw, memory, agent, long-term, short-term]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
OpenClaw Agent 的记忆体系,由短期记忆层、长期记忆层和 self-improving 层三层构成,各司其职实现上下文连续性和持续进化。
|
||||
|
||||
## 三层架构
|
||||
|
||||
### 短期记忆层
|
||||
- 媒介:memory/YYYY-MM-DD.md 每日文件
|
||||
- 职责:保存当天对话记录、操作、遇到的问题、未完成事项
|
||||
- 触发:每次 Session 启动时检查并创建当天文件(修复无对话日记忆断层问题)
|
||||
|
||||
### 长期记忆层
|
||||
- 媒介:memory-lancedb-pro(基于 LanceDB 的向量数据库)
|
||||
- 职责:重要的决策、用户偏好、反复使用的流程,通过语义搜索找回
|
||||
- 机制:hybrid retrieval(向量 + BM25),Weibull 衰减
|
||||
|
||||
### Self-Improving 层
|
||||
- 媒介:LEARNINGS.md / ERRORS.md
|
||||
- 职责:每次踩坑都记录,Pattern-Key 追踪重复,Recurrence-Count 量化系统性
|
||||
- 触发:每日 23:00 定时复盘
|
||||
|
||||
## 分工原则
|
||||
- 每日文件:管上下文(接上昨天的工作)
|
||||
- 向量数据库:管知识(语义搜索)
|
||||
- self-improving:管成长(错误不重复)
|
||||
|
||||
## Connections
|
||||
- [[Self-Improving Skill]] ← 成长层 ← [[双层记忆架构]]
|
||||
- [[memory-lancedb-pro]] ← 长期层 ← [[双层记忆架构]]
|
||||
- [[记忆断层]] ← 问题 ← [[双层记忆架构]]
|
||||
29
wiki/concepts/每日复盘.md
Normal file
29
wiki/concepts/每日复盘.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "每日复盘"
|
||||
type: concept
|
||||
tags: [openclaw, cron, self-improving, habit, agent]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
OpenClaw Agent 每天 23:00(北京时间)自动执行的自我复盘流程,通过 self-improving skill 记录学习、检查重复、同步长期记忆。
|
||||
|
||||
## 复盘流程
|
||||
1. 读取当天的 memory/YYYY-MM-DD.md 文件
|
||||
2. 调用 self_improvement_log 记录今日学习
|
||||
3. 检查 Pattern-Key 是否与之前重复(重复踩坑信号)
|
||||
4. 把有价值的经验同步到 memory-lancedb-pro(长期记忆)
|
||||
5. 通过 Telegram 发送复盘摘要
|
||||
|
||||
## 触发方式
|
||||
OpenClaw cron job,每天 23:00 执行,每个 Agent 独立运行自己的复盘流程。
|
||||
|
||||
## 关键价值
|
||||
- 从"每次重新教"变为"记得上次错哪"
|
||||
- 推动流程优化(如发现 3 月 27 日无 memory 文件 → 修改为 Session 启动时强制创建)
|
||||
- Recurrence-Count 累积让系统性问题和偶发错误清晰分层
|
||||
|
||||
## Connections
|
||||
- [[Self-Improving Skill]] ← 工具 ← [[每日复盘]]
|
||||
- [[双层记忆架构]] ← 架构 ← [[每日复盘]]
|
||||
- [[OpenClaw cron]] ← 触发 ← [[每日复盘]]
|
||||
28
wiki/concepts/记忆断层.md
Normal file
28
wiki/concepts/记忆断层.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "记忆断层"
|
||||
type: concept
|
||||
tags: [memory, openclaw, agent, bug, self-improvement]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
由于设计缺陷导致某些日期完全没有 memory 文件记录,造成 Agent 无法回溯特定时期工作的问题。根源是"第一次对话时创建文件"的逻辑,无对话日不触发文件创建。
|
||||
|
||||
## 问题表现
|
||||
- 3月27日 memory 文件为空 → 复盘时发现当天没有任何记录
|
||||
- Agent 后续无法回溯该日的工作内容
|
||||
- 知识孤岛:该日学到的经验没有积累
|
||||
|
||||
## 根因
|
||||
原设计:只在"第一次对话时"检查并创建 memory 文件 → 无对话日文件不创建 → 记忆断层
|
||||
|
||||
## 解决方案
|
||||
修改为:每次 Session 启动时都检查并创建当天 memory 文件,无论是否有对话
|
||||
|
||||
## 发现机制
|
||||
每日复盘时 Agent 主动检查前一天的文件,发现问题后记录为 LRN 并推动流程优化。
|
||||
|
||||
## Connections
|
||||
- [[双层记忆架构]] ← 存在于 ← [[记忆断层]]
|
||||
- [[Self-Improving Skill]] ← 发现机制 ← [[记忆断层]]
|
||||
- [[每日复盘]] ← 发现场景 ← [[记忆断层]]
|
||||
22
wiki/entities/Alex-Finn.md
Normal file
22
wiki/entities/Alex-Finn.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Alex Finn"
|
||||
type: entity
|
||||
tags: [content-creator, youtube]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Alex Finn
|
||||
|
||||
## Summary
|
||||
YouTube 内容创作者,发布 Life-changing OpenClaw Use Cases 视频,涵盖内容工厂、市场研究等多个 agent 应用场景,激发了大量用户的 OpenClaw 工作流搭建灵感。
|
||||
|
||||
## Key Contributions
|
||||
- OpenClaw Use Cases 视频系列
|
||||
- 内容工厂(Content Factory)工作流灵感
|
||||
- 市场研究产品工厂(Market Research & Product Factory)灵感
|
||||
|
||||
## Key Connections
|
||||
- [[Content Factory]] ← 灵感来源
|
||||
- [[Market Research Product Factory]] ← 灵感来源
|
||||
- [[Alex Finn YouTube Channel]] ← 发布渠道
|
||||
24
wiki/entities/ClawHub.md
Normal file
24
wiki/entities/ClawHub.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: [marketplace, plugin, openclaw, skills]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
按单个 skill 安装的 OpenClaw 插件市场协议。每个 skill 独立发布、单独安装,无需安装整个 marketplace。
|
||||
|
||||
## Aliases
|
||||
- ClawHub Registry
|
||||
- clawhub.com
|
||||
|
||||
## Key Facts
|
||||
- 发布命令:./scripts/sync-clawhub.sh --all
|
||||
- 安装命令:clawhub install <skill-name>(如 clawhub install baoyu-imagine)
|
||||
- 许可协议:MIT-0
|
||||
- 覆盖范围:内容生成(baoyu-xhs-images/infographic/cover-image 等)、AI 图像(baoyu-imagine)、工具技能(baoyu-translate 等)
|
||||
|
||||
## Connections
|
||||
- [[宝玉]] ← 发布者 ← [[ClawHub]]
|
||||
- [[baoyu-skills]] ← 发布到 ← [[ClawHub]]
|
||||
- [[OpenClaw]] ← 平台 ← [[ClawHub]]
|
||||
20
wiki/entities/Matt-Van-Horne.md
Normal file
20
wiki/entities/Matt-Van-Horne.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Matt Van Horne"
|
||||
type: entity
|
||||
tags: [developer, open-source, skill-author]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Matt Van Horne
|
||||
- mvanhorn
|
||||
|
||||
## Summary
|
||||
Last30Days skill 作者,为 OpenClaw 提供 Reddit/X/YouTube 等多平台热点聚合研究能力。其 skill 是市场研究与产品发现自动化管道的核心依赖。
|
||||
|
||||
## Key Contributions
|
||||
- Last30Days skill:8 大数据源热点聚合研究工具
|
||||
|
||||
## Key Connections
|
||||
- [[Last30Days]] ← Skill 作者
|
||||
- [[Market Research Product Factory]] ← 核心技术依赖
|
||||
21
wiki/entities/Nicholas-Carlini.md
Normal file
21
wiki/entities/Nicholas-Carlini.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Nicholas Carlini"
|
||||
type: entity
|
||||
tags: [researcher, ai]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Nicholas Carlini
|
||||
- Carlini
|
||||
|
||||
## Summary
|
||||
AI 研究者,自主编码 agent 方法论提出者。提出"让 agent 自我组织而非微观管理"理念,倡导通过共享状态文件(STATE.yaml)实现去中心化 agent 协调。
|
||||
|
||||
## Key Contributions
|
||||
- STATE.yaml 去中心化协调模式
|
||||
- 自主编码 agent 自组织方法论
|
||||
|
||||
## Key Connections
|
||||
- [[Autonomous Project Management]] ← 灵感来源
|
||||
- [[Anthropic]] ← Building Effective Agents 相关研究
|
||||
@@ -3,6 +3,12 @@
|
||||
## Overview
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources (2026-04-15 Evening Batch)
|
||||
- [Autonomous Project Management](sources/Autonomous-Project-Management.md) — 去中心化项目协调:STATE.yaml 替代中央 orchestrator,subagent 自主协作
|
||||
- [Content Factory](sources/Content-Factory.md) — Discord 多 agent 内容工厂:Research→Writing→Thumbnail 链式协作
|
||||
- [Market Research Product Factory](sources/Market-Research-Product-Factory.md) — Last30Days 挖掘痛点→OpenClaw 构建 MVP 自动化管线
|
||||
- [Personal Knowledge Base RAG](sources/Personal-Knowledge-Base-RAG.md) — 语义可搜索个人第二大脑,URL 自动摄取+向量检索
|
||||
|
||||
## Sources
|
||||
- [Multi-Agent Specialized Team (Solo Founder Setup)](sources/Agent-usecases-multi-Agent-Team.md) — 多 Agent 虚拟团队:Telegram 统一入口 + 共享内存 + 定时主动汇报
|
||||
- [DevOps Maturity Model: From Traditional IT to Advanced DevOps](sources/DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps.md) — DevOps 成熟度 5 阶段评估框架(Ad-Hoc → Mature)
|
||||
@@ -262,3 +268,35 @@
|
||||
|
||||
## Syntheses
|
||||
- [DevOps 核心理念](syntheses/DevOps核心理念.md)
|
||||
|
||||
## Sources (2026-04-15 PM Batch)
|
||||
- [baoyu-skills Claude Code 技能集](sources/baoyu-skills-claude-code-技能集.md) — 宝玉技能集:内容技能(xhs/infographic/cover/comic等)+ baoyu-imagine(9家服务商)+ 工具技能(translate/youtube-transcript等)
|
||||
- [Multi-Agent Specialized Team (Solo Founder Setup)](sources/Multi-Agent-Specialized-Team-Solo-Founder-Setup.md) — Solo founder 4 Agent 虚拟团队:Telegram 统一入口 + 共享记忆 + 定时主动任务
|
||||
- [Vibe-Kanban + OpenCode Ubuntu Server 安装管理指南](sources/Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南.md) — Ubuntu Server 安装 Node 20 + Vibe-Kanban + OpenCode,pm2 进程管理
|
||||
- [养虾日记2:OpenClaw + Self-Improving 复盘实战](sources/养虾日记2-OpenClaw-Self-Improving复盘实战.md) — 双层记忆架构 + Self-Improving + 每日复盘,Agent 在错误中持续进化
|
||||
|
||||
## Entities (2026-04-15 Evening Batch)
|
||||
- [Nicholas Carlini](entities/Nicholas-Carlini.md) — 自主编码 agent 方法论提出者,STATE.yaml 去中心化协调灵感来源
|
||||
- [Matt Van Horne](entities/Matt-Van-Horne.md) — Last30Days skill 作者
|
||||
- [Alex Finn](entities/Alex-Finn.md) — OpenClaw Use Cases YouTube 视频作者
|
||||
|
||||
## Entities (2026-04-15 PM Batch)
|
||||
- [ClawHub](entities/ClawHub.md) — 按单个 skill 安装的 OpenClaw 插件市场协议
|
||||
|
||||
## Concepts (2026-04-15 Evening Batch)
|
||||
- [STATE.yaml](concepts/STATE-yaml.md) — 去中心化项目协调文件格式,YAML 结构定义任务状态与依赖
|
||||
- [去中心化协调](concepts/去中心化协调.md) — 无中央 orchestrator,各 agent 通过共享状态文件自主协调
|
||||
- [内容工厂](concepts/内容工厂.md) — 多 agent 链式协作内容创作管线
|
||||
- [产品工厂](concepts/产品工厂.md) — 市场研究到 MVP 构建的自动化管线
|
||||
- [个人知识库](concepts/个人知识库.md) — 基于 RAG 的个人第二大脑
|
||||
|
||||
## Concepts (2026-04-15 PM Batch)
|
||||
- [nvm](concepts/nvm.md) — Node Version Manager,管理 Node.js 多版本
|
||||
- [pm2](concepts/pm2.md) — Node.js 进程管理器,进程守护+开机自启
|
||||
- [Vibe-Kanban](concepts/Vibe-Kanban.md) — AI 结对编程任务看板,Web UI + executor 自动 spawn
|
||||
- [Self-Improving Skill](concepts/Self-Improving-Skill.md) — 结构化经验记录系统,错误只犯一次
|
||||
- [双层记忆架构](concepts/双层记忆架构.md) — 短期记忆(每日文件)+ 长期记忆(LanceDB)+ self-improving(成长)
|
||||
- [Pattern-Key](concepts/Pattern-Key.md) — 经验记录唯一标识,追踪重复踩坑信号
|
||||
- [Recurrence-Count](concepts/Recurrence-Count.md) — 重复次数计数器,区分偶发错误与系统性问题
|
||||
- [每日复盘](concepts/每日复盘.md) — 23:00 定时复盘流程,self-improving 触发机制
|
||||
- [记忆断层](concepts/记忆断层.md) — 无对话日 memory 文件缺失问题,Session 启动时强制创建解决
|
||||
|
||||
28
wiki/log.md
28
wiki/log.md
@@ -207,3 +207,31 @@ Created/updated: 12 entity pages (DeepSeek, Qwen, Flux, Stable Diffusion, Hunyua
|
||||
- [不谈技术:普通人该怎么在AI时代赚钱](sources/普通人如何在AI时代赚钱.md)
|
||||
- Created entities: ComposioHQ, VoltAgent, BehiSecc, Yuri Pessa
|
||||
- Created concepts: 流程工程, 透明度, 控制权, 个性化, 对话式设计, 预判式设计, 精确去重, 小文件清理, 安全删除, 分批执行, AI Agent 思维方式, 品味, 端到端, 死亡过滤器, 引文追溯, 被动学习
|
||||
|
||||
## [2026-04-15 PM] ingest batch | 4 docs (baoyu-skills / Multi-Agent Team / Vibe-Kanban / 养虾日记2)
|
||||
- [baoyu-skills-claude-code-技能集](sources/baoyu-skills-claude-code-技能集.md)
|
||||
Key claims: ClawHub 按单个 skill 安装;baoyu-imagine 支持 9 家服务商自动选择;baoyu-translate 三模式(快速/标准/精翻);baoyu-comic 5×8 画风基调;EXTEND.md 支持用户级/项目级自定义
|
||||
Created: 1 entity (ClawHub), 2 concepts (内容技能, baoyu-imagine)
|
||||
- [Multi-Agent-Specialized-Team-Solo-Founder-Setup](sources/Multi-Agent-Specialized-Team-Solo-Founder-Setup.md)
|
||||
Key claims: 共享记忆(GOALS.md/DECISIONS.md)+ 私有上下文是多 Agent 协作核心;定时主动任务是价值飞轮;从 2 Agent 开始按瓶颈扩展;[[Trebuh]] 的 4 Agent 实践
|
||||
Created: 1 concept (共享内存模式, 定时主动任务, Telegram路由)
|
||||
- [Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南](sources/Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南.md)
|
||||
Key claims: nvm 管理 Node 20;不要用 root 启动 OpenCode serve;vibe-kanban 自动 spawn executor;pm2 管理进程并设置开机自启
|
||||
Created: 3 concepts (nvm, pm2, Vibe-Kanban)
|
||||
- [养虾日记2-OpenClaw-Self-Improving复盘实战](sources/养虾日记2-OpenClaw-Self-Improving复盘实战.md)
|
||||
Key claims: 双层记忆架构(每日文件+LanceDB+self-improving);LEARNINGS.md 固定格式含 Pattern-Key/Recurrence-Count;Pattern-Key 重复是系统性问题的信号;3月27日记忆断层推动流程优化
|
||||
Created: 6 concepts (Self-Improving Skill, 双层记忆架构, Pattern-Key, Recurrence-Count, 每日复盘, 记忆断层), 1 entity (ClawHub)
|
||||
|
||||
## [2026-04-15 Evening] ingest batch | Autonomous PM / Content Factory / Market Research Product Factory / Personal Knowledge Base RAG
|
||||
- [Autonomous-Project-Management](sources/Autonomous-Project-Management.md)
|
||||
Key claims: STATE.yaml 去中心化协调优于中央 orchestrator;Git 作为审计日志;薄主会话原则(CEO 模式)
|
||||
Created: 1 entity (Nicholas Carlini), 2 concepts (STATE.yaml, 去中心化协调)
|
||||
- [Content-Factory](sources/Content-Factory.md)
|
||||
Key claims: 链式 agent 是核心威力;Research→Writing→Thumbnail 每步自动喂给下一步;Discord channel 分离工作流便于 review
|
||||
Created: 1 entity (Alex Finn), 1 concept (内容工厂)
|
||||
- [Market-Research-Product-Factory](sources/Market-Research-Product-Factory.md)
|
||||
Key claims: Last30Days 提供真实未过滤用户情绪;创业自动化全流程零编码;每周定时研究保持市场洞察
|
||||
Created: 1 entity (Matt Van Horne), 1 concept (产品工厂)
|
||||
- [Personal-Knowledge-Base-RAG](sources/Personal-Knowledge-Base-RAG.md)
|
||||
Key claims: Drop any URL 自动摄取;语义搜索返回 ranked 结果+来源引文;其他工作流可主动查询知识库
|
||||
Created: 1 concept (个人知识库)
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Wiki Overview
|
||||
last_updated: 2026-04-15
|
||||
last_updated: 2026-04-15 Evening
|
||||
// 新增领域:Agent Use Cases 四大工作流(项目管理/内容工厂/产品工厂/知识库)(2026-04-15 Evening)
|
||||
// 新增领域:Last30Days 与多平台热点聚合(2026-04-15)
|
||||
// 新增领域:gog CLI 与 Google Workspace CLI(2026-04-15)
|
||||
// 新增领域:Cursor 2.0 与 AI 代码编辑器(2026-04-15)
|
||||
@@ -41,6 +42,20 @@ AI开源生态在2025年取得突破性进展,国产模型在多个领域成
|
||||
- 国产开源模型在多个领域实现差异化竞争
|
||||
- DevOps 向 GitOps、AI 赋能、Serverless 和 Edge Computing 方向演进
|
||||
|
||||
## 新增领域:Agent Use Cases 四大工作流
|
||||
|
||||
### 1. Autonomous Project Management(去中心化项目管理)
|
||||
基于 [[STATE.yaml]] 的去中心化协调模式,替代传统中央 orchestrator。subagent 通过读写共享状态文件自主协作,Git 作为审计日志,主会话保持薄(CEO 模式)。灵感来源:[[Nicholas Carlini]]。
|
||||
|
||||
### 2. Content Factory(内容工厂)
|
||||
Discord 多 agent 链式协作管线:Research Agent 扫描趋势 → Writing Agent 生成脚本 → Thumbnail Agent 生成配图,全部自动执行定时运行。[[Alex Finn]] YouTube 视频激发此工作流设计。
|
||||
|
||||
### 3. Market Research & Product Factory(产品工厂)
|
||||
[[Last30Days]] 挖掘 Reddit/X 真实用户痛点 → ranked pain points → [[OpenClaw]] 构建 MVP。零编码要求,每周定时追踪市场演变。核心依赖:[[Matt Van Horne]] 的 Last30Days skill。
|
||||
|
||||
### 4. Personal Knowledge Base RAG(个人知识库)
|
||||
基于 [[RAG]] 的第二大脑:Drop any URL 自动摄取 → 向量嵌入 → 语义搜索返回 ranked 结果+来源引文。支持其他 agent 工作流主动查询。
|
||||
|
||||
## 新增领域:Claude Skills 与流程工程
|
||||
|
||||
Claude Skills 的爆发标志着从"提示词工程"到"流程工程"的范式转移。Skills = 说明书 + SOP,将人类经验封装为可复用工作流。Anthropic 官方 Skills 仓库(github.com/anthropics/skills)收藏数突破 3.2 万,包含生产级 Skills:办公自动化、开发者工具箱、创意类 Skill。Vibe Coding 的尽头也是 Skills。
|
||||
@@ -586,3 +601,67 @@ Agentic AI(行动型 AI)与 GenAI(生成型 AI)的根本区别在于:A
|
||||
|
||||
### 关键洞察
|
||||
- AI 不会让普通人变富,但会让那些知道自己要做什么、且对品质有执念的人变得极其强大
|
||||
|
||||
// 新增领域:baoyu-skills Claude Code 技能集(2026-04-15 PM)
|
||||
// 新增领域:Multi-Agent 虚拟团队协作模式(2026-04-15 PM)
|
||||
// 新增领域:Vibe-Kanban + OpenCode Ubuntu 部署(2026-04-15 PM)
|
||||
// 新增领域:Self-Improving + 双层记忆架构(2026-04-15 PM)
|
||||
|
||||
## 新增领域:baoyu-skills Claude Code 技能集
|
||||
|
||||
宝玉(JimLiu)发布的 Claude Code 技能集,通过 ClawHub 协议按单个 skill 安装,覆盖内容生成、AI 图像、日常效率工具三大类。
|
||||
|
||||
### 技能架构
|
||||
- [[内容技能]]:baoyu-xhs-images(小红书 9×6 风格布局)、baoyu-infographic(20×17 布局风格)、baoyu-cover-image(5维封面定制)、baoyu-slide-deck(4维度16预设)、baoyu-comic(5×8 画风基调)、baoyu-article-illustrator
|
||||
- [[baoyu-imagine]]:9 家服务商自动选择(OpenAI/Google/Azure/OpenRouter/DashScope/MiniMax/即梦/豆包/Replicate),支持文生图/参考图/批量生成
|
||||
- [[工具技能]]:baoyu-translate(三模式翻译)、baoyu-youtube-transcript、baoyu-url-to-markdown、baoyu-x-to-markdown
|
||||
|
||||
### 发布协议
|
||||
- ClawHub 按单个 skill 安装(clawhub install baoyu-imagine),而非 marketplace 批量安装
|
||||
- EXTEND.md 支持用户级/项目级自定义,Env 配置支持 API Key 优先级覆盖
|
||||
|
||||
## 新增领域:Multi-Agent 虚拟团队协作模式
|
||||
|
||||
Solo founder 通过多 Agent 虚拟团队实现 24/7 全天候工作能力,每个 Agent 有独立角色/人格/模型,共享记忆,协作完成复杂任务。
|
||||
|
||||
### 核心机制
|
||||
- [[共享内存模式]]:GOALS.md(OKR 与优先级)+ DECISIONS.md(关键决策日志)+ PROJECT_STATUS.md(当前项目状态)
|
||||
- [[定时主动任务]]:Agent 主动在后台工作并推送结果,而非等待用户请求(早会摘要/指标推送/内容创意)
|
||||
- [[Telegram路由]]:单群聊入口 + @AgentName 路由 + 无@默认 Lead Agent
|
||||
- 从 2 Agent 开始,按瓶颈扩展,不是一上来建 4 个团队
|
||||
|
||||
### 实践案例
|
||||
- [[Trebuh]] 的 4 Agent 团队(Milo/Josh/Marketing/Dev)+ Telegram + VPS,描述为"真正的 24/7 小团队"
|
||||
|
||||
## 新增领域:Vibe-Kanban + OpenCode Ubuntu 部署
|
||||
|
||||
Ubuntu Server 上通过 nvm 管理 Node 20,安装 Vibe-Kanban 与 OpenCode,pm2 管理进程,实现远程 AI 结对编程。
|
||||
|
||||
### 核心组件
|
||||
- [[nvm]]:Node Version Manager(v0.39.7),安装和管理 Node 20
|
||||
- [[Vibe-Kanban]]:AI 结对编程任务看板,Web UI(PORT 9999),自动 spawn OpenCode Executor
|
||||
- [[pm2]]:进程管理器,pm2 start/logs/save/startup systemd
|
||||
- [[OpenCode Executor]]:vibe-kanban spawn 的 AI 编程执行器,随机端口运行
|
||||
|
||||
### 关键约束
|
||||
- 不要用 root 启动 OpenCode serve
|
||||
- executor 随 vibe-kanban 进程一起管理,不单独用 pm2 管理
|
||||
- I/O error 通常是 executor 没启动或端口被占用
|
||||
|
||||
## 新增领域:Self-Improving + 双层记忆架构
|
||||
|
||||
通过 self-improving skill + 双层记忆架构 + 每日定时复盘,实现 Agent 在错误中学习、持续进化,避免同一错误重复出现。
|
||||
|
||||
### 双层记忆架构
|
||||
- 短期记忆:memory/YYYY-MM-DD.md 每日文件,每次 Session 启动时强制创建(解决记忆断层)
|
||||
- 长期记忆:memory-lancedb-pro(LanceDB 向量数据库),语义搜索重要决策和偏好
|
||||
- self-improving 层:LEARNINGS.md,Pattern-Key 追踪,Recurrence-Count 量化系统性
|
||||
|
||||
### Self-Improving 核心机制
|
||||
- [[Pattern-Key]]:经验记录唯一标识(如 cron.telegram-delivery),重复出现 = 系统性问题需系统性解决
|
||||
- [[Recurrence-Count]]:重复次数计数器,≥2 说明这不是偶发错误
|
||||
- 固定格式:Summary + Details + Suggested Action + Metadata(Pattern-Key/Recurrence-Count/See Also)
|
||||
|
||||
### 每日复盘
|
||||
- 23:00 定时触发,读取当天 memory → self_improvement_log → 检查 Pattern-Key 重复 → 同步到长期记忆 → Telegram 摘要
|
||||
- 发现机制:复盘时发现 3月27日无 memory 文件 → 推动"Session 启动时强制创建"流程优化
|
||||
|
||||
48
wiki/sources/Autonomous-Project-Management.md
Normal file
48
wiki/sources/Autonomous-Project-Management.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Autonomous Project Management with Subagents"
|
||||
type: source
|
||||
tags: [agent, project-management, subagent]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-project-management.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:去中心化项目管理模式,多 subagent 通过共享 STATE.yaml 协调而非中央 orchestrator
|
||||
- 问题域:传统 orchestrator 模式造成主 agent 瓶颈,多 repo 重构/研究冲刺/内容管线等复杂项目需要并行执行
|
||||
- 方法/机制:STATE.yaml 作为单一事实来源 → 各 agent 自主认领任务 → 状态更新触发其他 agent 接力
|
||||
- 结论/价值:文件协调优于消息传递;Git 作为审计日志;薄主会话原则(CEO 模式)
|
||||
|
||||
## Key Claims
|
||||
- 传统 orchestrator 模式产生瓶颈——主 agent 成为交通指挥
|
||||
- STATE.yaml > orchestrator:文件协调比消息传递更具扩展性
|
||||
- Git 作为审计日志:提交 STATE.yaml 变更获取完整历史
|
||||
- Label 约定很重要:用 `pm-{project}-{scope}` 格式便于追踪
|
||||
- 薄主会话原则:主 agent 做得越少,响应越快
|
||||
|
||||
## Key Quotes
|
||||
> "Managing complex projects with multiple parallel workstreams is exhausting. You end up context-switching constantly." — 痛点陈述
|
||||
> "Let agents self-organize rather than micromanaging them." — [[Nicholas Carlini]] 方法论核心
|
||||
|
||||
## Key Concepts
|
||||
- [[STATE.yaml]]:项目协调文件,YAML 格式定义任务状态、owner、blocked_by 依赖关系
|
||||
- [[去中心化协调]]:无中央 orchestrator,各 agent 自主读写共享状态文件
|
||||
- [[薄主会话]]:主会话仅做策略/调度,所有执行下沉 subagent
|
||||
- [[CEO 模式]]:主 agent = 协调者,subagent = 执行者
|
||||
|
||||
## Key Entities
|
||||
- [[Nicholas Carlini]]:自主编码 agent 方法论提出者,STATE.yaml 协调模式灵感来源
|
||||
- [[Anthropic]]:Building Effective Agents 论文发布方
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent Hierarchy]] ← 架构基础 ← [[Autonomous Project Management]]
|
||||
- [[sessions_spawn]] ← 核心能力 ← [[Autonomous Project Management]]
|
||||
- [[sessions_send]] ← 核心能力 ← [[Autonomous Project Management]]
|
||||
- [[GitOps]] ← 审计日志机制 ← [[Autonomous Project Management]]
|
||||
|
||||
## Contradictions
|
||||
- 与中央 orchestrator 模式冲突:
|
||||
- 当前观点:去中心化文件协调,无单点瓶颈
|
||||
- 对方观点:中央 orchestrator 便于全局控制
|
||||
- 适用场景:复杂多任务 > 简单顺序任务
|
||||
46
wiki/sources/Content-Factory.md
Normal file
46
wiki/sources/Content-Factory.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Multi-Agent Content Factory"
|
||||
type: source
|
||||
tags: [agent, content, multi-agent, discord]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/content-factory.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Discord 内多 agent 内容工厂,研究→写作→设计链式协作
|
||||
- 问题域:内容创作三阶段(研究/写作/设计)全靠人工,AI 工具也需逐个 prompt
|
||||
- 方法/机制:Research Agent 扫描趋势 → Writing Agent 生成脚本 → Thumbnail Agent 生成配图,全流程定时自动执行
|
||||
- 结论/价值:链式 agent 威力在于前序输出喂给后序;Discord channel 便于分阶段 review
|
||||
|
||||
## Key Claims
|
||||
- 链式 agent 是核心:research → writing → thumbnails,每步输出自动喂给下一步
|
||||
- Discord channel 分离各 agent 工作便于 review 和反馈
|
||||
- 本地模型(如 Mac Studio 上的 Nano Banana)降低成本增加控制
|
||||
- 可适配任何内容格式:tweets/newsletter/LinkedIn/posts/podcast outlines/blog
|
||||
|
||||
## Key Quotes
|
||||
> "Content creation has three phases — research, writing, and design — and most creators are doing all three manually." — 痛点陈述
|
||||
> "The power is in the chained agents — research feeds writing, writing feeds thumbnails." — 核心价值
|
||||
|
||||
## Key Concepts
|
||||
- [[内容工厂]]:研究+写作+设计三阶段链式 agent 协作管线
|
||||
- [[链式 Agent]]:前序 agent 输出自动作为后序 agent 输入
|
||||
- [[Discord 集成]]:多 channel 分离各 agent 工作流
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Finn]]:Life-changing OpenClaw use cases 视频作者,本内容工厂灵感来源
|
||||
|
||||
## Connections
|
||||
- [[Market Research Product Factory]] ← 共享研究 agent 基础设施
|
||||
- [[Last30Days]] ← Research Agent 数据来源
|
||||
- [[baoyu-imagine]] ← Thumbnail Agent 图像生成能力
|
||||
- [[Agentic AI]] ← 自主执行多步骤工作流
|
||||
- [[multi-agent-team]] ← 多 agent 协作模式
|
||||
|
||||
## Contradictions
|
||||
- 与单人内容创作流程对比:
|
||||
- 当前观点:多 agent 链式协作,人工降至最低
|
||||
- 对方观点:单人全流程控制质量更一致
|
||||
- 结论:质量控制需人工 review 环节,不可完全自动化
|
||||
48
wiki/sources/Market-Research-Product-Factory.md
Normal file
48
wiki/sources/Market-Research-Product-Factory.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Market Research & Product Factory"
|
||||
type: source
|
||||
tags: [agent, market-research, product, last30days]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/market-research-product-factory.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Last30Days 挖掘 Reddit/X 真实痛点 → OpenClaw 构建 MVP 解决方案的自动化创业管线
|
||||
- 问题域: aspiring entrepreneur 面临"做什么产品"困境;传统市场研究耗时耗力
|
||||
- 方法/机制:Last30Days 研究痛点 → ranked pain points → 选择痛点 → OpenClaw 构建 MVP
|
||||
- 结论/价值:创业自动化:找问题→验证需求→构建方案,全流程通过文本对话完成
|
||||
|
||||
## Key Claims
|
||||
- Last30Days 给出真实、未经过滤的用户情绪,而非经过滤的调查数据
|
||||
- 不需要技术背景,OpenClaw 做研究和构建两部分
|
||||
- 每周定时研究保持对市场痛点演变的持续追踪
|
||||
- 研究→产品完整管线零编码
|
||||
|
||||
## Key Quotes
|
||||
> "Most aspiring entrepreneurs struggle with the 'what to build' problem." — 核心痛点
|
||||
> "This is entrepreneurship on autopilot: find problems → validate demand → build solutions, all through text messages." — 价值主张
|
||||
|
||||
## Key Concepts
|
||||
- [[产品工厂]]:市场研究到 MVP 构建的自动化管线
|
||||
- [[Last30Days]]:多平台热点聚合工具(Reddit/X/YouTube/Polymarket 等)
|
||||
- [[创业自动化]]:问题发现→需求验证→方案构建全链路
|
||||
- [[MVP 构建]]:最小可行产品快速原型
|
||||
|
||||
## Key Entities
|
||||
- [[Matt Van Horne]]:Last30Days skill 作者
|
||||
- [[Alex Finn]]:Life-changing OpenClaw use cases 视频作者
|
||||
|
||||
## Connections
|
||||
- [[Last30Days]] ← 核心技术能力
|
||||
- [[Content Factory]] ← 共享研究基础设施
|
||||
- [[AI产品经理]] ← 产品创意与需求分析能力
|
||||
- [[多平台热点聚合]] ← 研究方法论
|
||||
- [[社交信号权重]] ← 痛点评级框架
|
||||
|
||||
## Contradictions
|
||||
- 与传统市场研究方法冲突:
|
||||
- 当前观点:Last30Days 实时抓取真实用户帖子反映即时痛点
|
||||
- 对方观点:传统调研方法(访谈/问卷)结构化程度更高
|
||||
- 结论:两者互补,定量+定性结合最优
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Multi-Agent Specialized Team (Solo Founder Setup)"
|
||||
type: source
|
||||
tags: [openclaw, multi-agent, telegram, solo-founder, workflow]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/multi-agent-team.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Solo founder 通过多 Agent 虚拟团队实现 24/7 全天候工作能力
|
||||
- 问题域:单一 Agent 无法高效处理多领域工作;Context 切换破坏深度工作;知识孤岛导致洞察无法跨 Agent 流动
|
||||
- 方法/机制:专业化 Agent(各角色独立模型/人格)+ 共享记忆(GOALS.md/DECISIONS.md)+ 私有上下文 + Telegram 统一入口 + 定时主动任务
|
||||
- 结论/价值:从 2 Agent 开始按瓶颈扩展;定时任务是价值飞轮;团队协作产生真正价值
|
||||
|
||||
## Key Claims
|
||||
- 单一 Agent 无法高效处理战略/开发/营销/分析多领域,context window 快速填满
|
||||
- 共享记忆(GOALS.md/DECISIONS.md)+ 私有上下文是多 Agent 协作核心
|
||||
- 所有 Agent 通过同一 Telegram 群聊控制,各自只响应被 @ 的消息
|
||||
- 定时主动任务(早会摘要/指标推送/内容创意)是价值飞轮
|
||||
- 从 2 Agent 开始,不是一上来建 4 个团队
|
||||
- [[Trebuh]] 的实践:4 个 Agent(Milo/Josh/Marketing/Dev)+ Telegram + VPS,描述为"真正的 24/7 小团队"
|
||||
|
||||
## Key Quotes
|
||||
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks" — 实践总结
|
||||
> "The real value emerges when agents proactively surface insights, not just when you ask" — 定时任务价值
|
||||
> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to talk to your team" — Trebuh
|
||||
|
||||
## Key Concepts
|
||||
- [[共享记忆模式]]:GOALS.md(OKR与优先级,所有Agent可读)+ DECISIONS.md(关键决策日志)+ PROJECT_STATUS.md(当前项目状态)
|
||||
- [[定时主动任务]]:Agent 主动在后台工作并推送结果,而非等待用户请求
|
||||
- [[Multi-Agent Hierarchy]]:团队层级架构,Lead Agent 协调 + Specialist Agent 执行
|
||||
- [[Telegram路由]]:单群聊入口 + @AgentName 路由 + 无@默认 Lead Agent
|
||||
|
||||
## Key Entities
|
||||
- [[Trebuh]]:Solo founder,4 Agent 团队实践者,通过 X 分享案例
|
||||
- [[OpenClaw]]:多 Agent 管理平台,支持 sessions_spawn/sessions_send/Telegram skill
|
||||
|
||||
## Connections
|
||||
- [[Trebuh]] ← 实践者 ← [[Multi-Agent Specialized Team]]
|
||||
- [[OpenClaw]] ← 平台 ← [[Multi-Agent Specialized Team]]
|
||||
- [[共享记忆模式]] ← 核心机制 ← [[Multi-Agent Specialized Team]]
|
||||
- [[定时主动任务]] ← 价值飞轮 ← [[Multi-Agent Specialized Team]]
|
||||
45
wiki/sources/Personal-Knowledge-Base-RAG.md
Normal file
45
wiki/sources/Personal-Knowledge-Base-RAG.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Personal Knowledge Base (RAG)"
|
||||
type: source
|
||||
tags: [agent, rag, knowledge-base, memory]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/knowledge-base-rag.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:语义可搜索个人知识库,自动从任意 URL(文章/tweets/YouTube/PDF)摄取内容
|
||||
- 问题域:书签堆积无法检索,看过的内容找不到
|
||||
- 方法/机制:Drop URL 到 Telegram/Slack → 自动抓取内容 → 向量嵌入 → 语义搜索返回 ranked 结果+来源
|
||||
- 结论/价值:RAG 驱动的个人第二大脑;其他工作流可查询知识库获取相关已存内容
|
||||
|
||||
## Key Claims
|
||||
- Drop any URL 自动摄取:文章/tweets/YouTube transcripts/PDFs
|
||||
- 语义搜索:"What did I save about agent memory?" 返回 ranked 结果+来源引文
|
||||
- 喂入其他工作流:视频创意管线构建 research cards 时自动查询知识库
|
||||
- Zero maintenance:URL 即摄入触发器
|
||||
|
||||
## Key Quotes
|
||||
> "You read articles, tweets, and watch videos all day but can never find that one thing you saw last week." — 核心痛点
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]:Retrieval-Augmented Generation,基于向量嵌入的语义检索
|
||||
- [[个人知识库]]:第二大脑,内容自动积累+语义检索
|
||||
- [[语义搜索]]:自然语言查询,返回 ranked 相关结果
|
||||
- [[内容摄取]]:URL → 结构化文本 → 向量嵌入全流程
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[NotebookLM]] ← 共享 source-grounding 理念
|
||||
- [[向量数据库]] ← 底层存储检索基础设施
|
||||
- [[Embedding]] ← 语义表示核心机制
|
||||
- [[Agentic AI]] ← 自主触发知识库查询
|
||||
- [[Content Factory]] ← 可查询知识库获取背景信息
|
||||
|
||||
## Contradictions
|
||||
- 与传统书签/笔记工具冲突:
|
||||
- 当前观点:语义搜索+自动摄取优于手动书签整理
|
||||
- 对方观点:手动整理确保质量和结构
|
||||
- 结论:摄取自动化+人工审核结合最优
|
||||
42
wiki/sources/Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南.md
Normal file
42
wiki/sources/Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [ubuntu, vibe-coding, vibe-kanban, opencode, pm2, node, nvm]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:在 Ubuntu Server 上以非 root 用户(shenwei)安装 Node 20、Vibe-Kanban 与 OpenCode,并通过 pm2 管理进程
|
||||
- 问题域:权限冲突、端口占用、executor 启动失败、I/O error
|
||||
- 方法/机制:nvm 管理 Node 版本 → npm 全局安装 vibe-kanban + opencode → pm2 管理进程 → RUST_LOG=debug 调试
|
||||
- 结论/价值:不要用 root 启动;vibe-kanban 自动 spawn executor;pm2 只管理 vibe-kanban,executor 随进程管理
|
||||
|
||||
## Key Claims
|
||||
- nvm 管理 Node 版本(v0.39.7),安装 Node 20,nvm alias default 20
|
||||
- 不要用 root 启动 OpenCode serve,vibe-kanban 会自动 spawn executor
|
||||
- RUST_LOG=debug HOST=0.0.0.0 PORT=9999 npx vibe-kanban 启动,executor 在随机端口
|
||||
- pm2 start "RUST_LOG=debug HOST=0.0.0.0 PORT=9999 npx vibe-kanban" --name vibe-kanban
|
||||
- pm2 startup systemd -u shenwei --hp /home/shenwei 生成启动脚本
|
||||
- I/O error 通常是 executor 没启动或端口被占用
|
||||
- 清理旧工作树:rm -rf /var/tmp/vibe-kanban/worktrees/* 和 ~/.vibe-kanban
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve,vibe-kanban 会自动 spawn executor" — 操作规范
|
||||
> "pm2 只管理 vibe-kanban,executor 随进程一起管理" — 进程管理原则
|
||||
|
||||
## Key Concepts
|
||||
- [[nvm]]:Node Version Manager,通过 curl -fsSL 安装,管理多个 Node 版本
|
||||
- [[pm2]]:进程管理器,pm2 start/pm2 logs/pm2 save/pm2 startup systemd
|
||||
- [[Vibe-Kanban]]:AI 结对编程任务看板,Web UI(PORT 9999)+ executor 随机端口
|
||||
- [[OpenCode Executor]]:vibe-kanban spawn 的 AI 编程执行器,随机端口运行
|
||||
|
||||
## Key Entities
|
||||
- [[shenwei]]:Ubuntu 服务器非 root 用户,Vibe-Kanban + OpenCode 安装操作者
|
||||
|
||||
## Connections
|
||||
- [[nvm]] ← 安装工具 ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← spawns ← [[OpenCode Executor]]
|
||||
- [[pm2]] ← 管理 ← [[Vibe-Kanban]]
|
||||
48
wiki/sources/baoyu-skills-claude-code-技能集.md
Normal file
48
wiki/sources/baoyu-skills-claude-code-技能集.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "baoyu-skills Claude Code 技能集"
|
||||
type: source
|
||||
tags: [claude-code, skills, baoyu, openclaw, 内容生成, AI图像]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/baoyu-skills-claude-code-技能集.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:宝玉(JimLiu)发布的 Claude Code 技能集,通过 ClawHub 协议按单个 skill 安装
|
||||
- 问题域:内容创作者和开发者需要多平台内容发布、多服务商图像生成、日常效率工具
|
||||
- 方法/机制:技能分内容技能(内容发布)、AI生成技能(图像/文本)、工具技能(处理工具)三大类;ClawHub 按单个 skill 安装(clawhub install baoyu-imagine)
|
||||
- 结论/价值:覆盖小红书/X/微信/微博全平台,9家图像服务商自动选择,翻译/抓取/压缩等日常工具
|
||||
|
||||
## Key Claims
|
||||
- ClawHub 按单个 skill 安装,不是 marketplace 批量装(clawhub install baoyu-imagine)
|
||||
- baoyu-imagine 支持 9 家服务商(OpenAI/Google/Azure/OpenRouter/DashScope/MiniMax/即梦/豆包/Replicate),自动选择最优
|
||||
- baoyu-translate 三模式(快速/标准/精翻)覆盖从短文本到出版级文档
|
||||
- baoyu-comic 5种画风 × 8种基调,漫画生成支持预设(ohmsha/wuxia/shoujo)
|
||||
- baoyu-post-to-wechat 支持 API 方式和浏览器方式发布公众号文章
|
||||
- EXTEND.md 支持用户级/项目级自定义,覆盖样式/配置/个人预设
|
||||
|
||||
## Key Quotes
|
||||
> "ClawHub 按单个 skill 安装,不是把整个 marketplace 一次性装进去" — 宝玉
|
||||
> "最好的 Skill 是工具箱,而非写好的提示词" — Anthropic
|
||||
> "精翻模式完成后,可回复「继续润色」或「refine」继续审校润色步骤" — baoyu-translate
|
||||
|
||||
## Key Concepts
|
||||
- [[内容技能]]:内容生成与发布类技能子集,baoyu-xhs-images/infographic/cover-image/slide-deck/comic/article-illustrator
|
||||
- [[baoyu-imagine]]:9家服务商自动选择的AI图像生成,支持文生图/参考图/自定义尺寸/批量生成
|
||||
- [[baoyu-infographic]]:20种布局×17种视觉风格的专业信息图生成
|
||||
- [[baoyu-xhs-images]]:小红书信息图,9种风格×6种布局的二维系统
|
||||
- [[baoyu-translate]]:三模式翻译(快速/标准/精翻),支持受众预设和风格预设
|
||||
- [[baoyu-comic]]:知识漫画创作,5种画风×8种基调,支持预设(ohmsha/wuxia/shoujo)
|
||||
- [[工具技能]]:baoyu-youtube-transcript/url-to-markdown/x-to-markdown/compress-image/format-markdown/markdown-to-html/translate
|
||||
|
||||
## Key Entities
|
||||
- [[宝玉]](JimLiu):baoyu-skills 项目作者,Claude Code 技能集开发者
|
||||
- [[JimLiu]]:GitHub 账号,baoyu-skills 仓库维护方
|
||||
- [[ClawHub]]:按单个 skill 安装的插件市场协议
|
||||
|
||||
## Connections
|
||||
- [[宝玉]] ← 发布 ← [[baoyu-skills]]
|
||||
- [[baoyu-imagine]] ← 依赖 ← [[ClawHub]]
|
||||
- [[baoyu-xhs-images]] ← 属于 ← [[内容技能]]
|
||||
- [[baoyu-translate]] ← 属于 ← [[工具技能]]
|
||||
46
wiki/sources/养虾日记2-OpenClaw-Self-Improving复盘实战.md
Normal file
46
wiki/sources/养虾日记2-OpenClaw-Self-Improving复盘实战.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "养虾日记2:让Agent更懂你:OpenClaw + Self-Improving 复盘实战案例分享"
|
||||
type: source
|
||||
tags: [openclaw, self-improving, memory, agent, 复盘, 经验积累]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/微信公众号/养虾日记2:让Agent更懂你:OpenClaw + Self-Improving 复盘实战案例分享.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:通过 self-improving skill + 双层记忆架构 + 每日定时复盘,实现 Agent 在错误中学习、持续进化
|
||||
- 问题域:AI 每次对话都是白纸,没有记忆;同一个错误反复出现;无对话日出现记忆断层
|
||||
- 方法/机制:短期记忆(memory/YYYY-MM-DD.md)+ 长期记忆(memory-lancedb-pro)+ self-improving 复盘(LEARNINGS.md,Pattern-Key 追踪)
|
||||
- 结论/价值:错误只犯一次;Pattern-Key 重复是系统性问题的信号;Recurrence-Count 区分偶发错误与系统性问题
|
||||
|
||||
## Key Claims
|
||||
- 双层记忆架构:短期(每日文件)+ 长期(LanceDB 向量数据库)+ self-improving(成长追踪)
|
||||
- 每日 23:00 定时复盘,cron job 触发,agent 独立运行各自复盘流程
|
||||
- LEARNINGS.md 固定格式:Summary/Details/Suggested Action/Metadata(Pattern-Key/Recurrence-Count)
|
||||
- Pattern-Key 重复是信号:第一次记了,第二次就该解决了
|
||||
- Recurrence-Count 区分偶发一次性错误与需系统性解决的重复问题
|
||||
- 3月27日发现无对话日记忆文件缺失 → 推动流程优化:每次 Session 启动都检查并创建当天文件
|
||||
|
||||
## Key Quotes
|
||||
> "AI每次对话都是一张白纸。昨天说过不要用A方法,今天它照常用。" — 核心痛点
|
||||
> "错误只犯一次,第二次就知道怎么做对。" — self-improving 核心价值
|
||||
> "Pattern-Key 重复本身就是一个信号——第一次记了,第二次就该解决了。" — Pattern-Key 机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Self-Improving Skill]]:结构化经验记录系统,self_improvement_log 工具写入 LEARNINGS.md/ERRORS.md
|
||||
- [[双层记忆架构]]:短期记忆(每日文件)+ 长期记忆(memory-lancedb-pro)+ self-improving(成长追踪)
|
||||
- [[Pattern-Key]]:经验记录的唯一标识键,格式如 cron.telegram-delivery,用于发现重复踩坑
|
||||
- [[Recurrence-Count]]:重复次数计数器,区分偶发错误与系统性问题
|
||||
- [[每日复盘]]:23:00 定时任务,读取当天 memory → self_improvement_log → 检查 Pattern-Key 重复 → 同步到长期记忆
|
||||
- [[记忆断层]]:无对话日不生成 memory 文件的问题,通过 Session 启动时强制检查解决
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:多 Agent 管理平台,支持 cron job、memory-lancedb-pro、self-improving skill
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 平台 ← [[self-improving skill]]
|
||||
- [[双层记忆架构]] ← 包含 ← [[Self-Improving Skill]]
|
||||
- [[双层记忆架构]] ← 包含 ← [[memory-lancedb-pro]]
|
||||
- [[Pattern-Key]] ← 核心机制 ← [[Self-Improving Skill]]
|
||||
- [[每日复盘]] ← 触发 ← [[OpenClaw cron]]
|
||||
70
wiki/syntheses/GOG-CLI工具.md
Normal file
70
wiki/syntheses/GOG-CLI工具.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: GOG CLI 工具
|
||||
type: synthesis
|
||||
tags: [Google Workspace, CLI工具, Gmail, Calendar, Drive]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 概述
|
||||
GOG CLI(Google Workspace CLI)是由 steipete 开发的 macOS/Linux 命令行工具,通过 OAuth 为 Gmail、Google Calendar、Google Drive、Google Contacts、Google Sheets、Google Docs 提供命令行接口。
|
||||
|
||||
## 支持的 Google 服务
|
||||
|
||||
| 服务 | 支持功能 |
|
||||
|------|---------|
|
||||
| **Gmail** | 搜索(threads/messages)、发送(普通/HTML/回复)、草稿创建与发送 |
|
||||
| **Calendar** | 列表、创建、更新事件,支持颜色标记(11色) |
|
||||
| **Drive** | 文件搜索 |
|
||||
| **Contacts** | 联系人列表 |
|
||||
| **Sheets** | 读取、更新、追加、清除、元数据查询 |
|
||||
| **Docs** | 导出(txt)、读取内容(cat) |
|
||||
|
||||
## 认证方式
|
||||
1. 通过 `gog auth credentials /path/to/client_secret.json` 配置 OAuth 客户端
|
||||
2. 通过 `gog auth add <email> --services gmail,calendar,drive,contacts,docs,sheets` 授权所需服务
|
||||
3. 支持多账户:`--account <email>` 参数切换
|
||||
|
||||
## 核心命令示例
|
||||
|
||||
### Gmail
|
||||
```bash
|
||||
gog gmail search 'newer_than:7d' --max 10
|
||||
gog gmail messages search "in:inbox from:ryanair.com" --max 20 --account you@example.com
|
||||
gog gmail send --to a@b.com --subject "Hi" --body-file ./message.txt
|
||||
```
|
||||
|
||||
### Calendar
|
||||
```bash
|
||||
gog calendar events <calendarId> --from <iso> --to <iso>
|
||||
gog calendar create <calendarId> --summary "Title" --from <iso> --to <iso> --event-color 7
|
||||
gog calendar update <calendarId> <eventId> --summary "New Title"
|
||||
gog calendar colors # 查看可用颜色
|
||||
```
|
||||
|
||||
### Sheets
|
||||
```bash
|
||||
gog sheets get <sheetId> "Tab!A1:D10" --json
|
||||
gog sheets update <sheetId> "Tab!A1:B2" --values-json '[["A","B"],["1","2"]]'
|
||||
gog sheets append <sheetId> "Tab!A:C" --values-json '[["x","y","z"]]'
|
||||
```
|
||||
|
||||
### Docs
|
||||
```bash
|
||||
gog docs export <docId> --format txt --out /tmp/doc.txt
|
||||
gog docs cat <docId>
|
||||
```
|
||||
|
||||
## 环境变量
|
||||
- `GOG_ACCOUNT=you@gmail.com` — 避免每次重复 `--account` 参数
|
||||
|
||||
## 注意事项
|
||||
- 发送邮件或创建事件前需二次确认
|
||||
- Sheets 值传递推荐使用 `--values-json`
|
||||
- `--body` 参数不解析 `\n`,多行内容需用 `--body-file`
|
||||
- Docs 不支持原地编辑,需通过 Docs API 客户端实现
|
||||
|
||||
## 安装
|
||||
```bash
|
||||
brew install steipete/tap/gogcli
|
||||
```
|
||||
Reference in New Issue
Block a user