Auto-sync: 2026-04-21 17:12
This commit is contained in:
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: 14个免费的AI图生视频工具，用AI让图片动起来
|
||||
type: source
|
||||
tags: [ai, image-to-video]
|
||||
date: 2025-12-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：14个免费的 AI 图生视频工具评测与推荐
|
||||
- 问题域：AI 视频生成工具选择
|
||||
- 方法/机制：通过静态图片借助 AI 能力生成动态视频
|
||||
- 结论/价值：降低视频创作门槛，赋能普通用户实现视频创作
|
||||
|
||||
## Key Claims
|
||||
- 绘蛙AI视频是阿里巴巴集团推出的模特图转视频工具，支持多种格式和高清输出
|
||||
- 智谱清影可在30秒内生成6秒1440×960高清视频，支持多种风格和音效匹配
|
||||
- Vidu是全球首个"多主体参考"功能的视频大模型，支持大幅度主体运动
|
||||
- 可灵AI能生成符合物理逻辑的复杂动作，人物表情表现力强
|
||||
- Viva在免费产品中图生视频质量最高，部分方面可媲美收费产品
|
||||
|
||||
## Key Quotes
|
||||
> "在当今这个信息爆炸、视觉内容为王的时代，视频已成为人们传递信息、表达创意、娱乐消遣的首选方式之一。" — 文章开篇
|
||||
|
||||
## Key Concepts
|
||||
- [[图生视频]]：将静态图片通过 AI 技术转化为动态视频的技术
|
||||
- [[AI视频生成]]：利用人工智能模型自动生成视频内容的技术
|
||||
|
||||
## Key Entities
|
||||
- [[阿里巴巴]] — 绘蛙AI视频的开发商
|
||||
- [[智谱AI]] — 智谱清影的开发商
|
||||
- [[快手]] — 可灵AI的开发商
|
||||
- [[生数科技]] — Vidu的开发商，联合清华大学发布
|
||||
- [[MiniMax]] — 海螺AI的开发商
|
||||
- [[字节跳动]] — 即梦AI的开发商
|
||||
- [[爱诗科技]] — PixVerse的开发商
|
||||
- [[潞晨科技]] — Video Ocean的开发商
|
||||
- [[Stability AI]] — Stable Video的开发商
|
||||
- [[阿里妈妈]] — 万相营造的开发商
|
||||
- [[智象未来]] — Viva的开发商
|
||||
- [[MewXAI]] — 艺映AI的团队
|
||||
|
||||
## Connections
|
||||
- [[通义万相]] ← 同属阿里巴巴 ← [[绘蛙AI视频]]
|
||||
- [[可灵AI]] ← 快手自研 ← [[Vidu]] ← 清华学术合作
|
||||
- [[即梦AI]] ← 字节跳动 ← [[PixVerse]] ← 爱诗科技
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
title: "2025 年 11 个神级 AI 开源平替，GitHub 杀疯了"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：2025 年 GitHub 上 8 个 AI 领域的顶尖开源项目盘点
|
||||
- 问题域：大语言模型、AI 生图、AI 生视频、AI 智能体、AI 编程、工作流自动化、AI 搜索、AI 知识库
|
||||
- 方法/机制：深度推理、开源内卷、Agent 工作流、浏览器自动化
|
||||
- 结论/价值：为开发者提供免费开源平替，替代昂贵的闭源商业产品
|
||||
|
||||
## Key Claims
|
||||
- DeepSeek R1 是首个将 o1 级深度推理拉下神坛的开源破壁者，2025 年春节爆火拉开中国 AI 开源差异化竞争叙事
|
||||
- 通义千问（Qwen 3）是开源界最稳、最全、最能打的六边形战士基座模型
|
||||
- Flux 是开源界的 Midjourney，出自前 SD 核心团队之手，目前人体解剖学最正确的开源模型
|
||||
- HunyuanVideo 是开源界参数量最大的视频生成模型之一，对中文 Prompt 理解达到天花板级别
|
||||
- Manus 是定义 AI Agent 元年的里程碑式产品，被 Meta 以几十亿美金收购
|
||||
- OpenManus 是 Manus 最强的开源平替，采用规划→执行→循环反馈的核心逻辑
|
||||
- Cline 是 VS Code 生态中公认最强大的开源自主编程插件，被誉为 Cursor 最佳开源平替
|
||||
- n8n 有恐怖的 16 万 Star，是最强的工作流 Workflow 开源项目
|
||||
- Dify 是最拿得出手的 LLM 应用开发平台，提供可视化知识库 AI 机器人搭建
|
||||
- Perplexica 是公认的和 Perplexity 长得像、功能像、而且完全开源免费的 AI 搜索引擎
|
||||
- NotebookLM 的开源平替已找到七八个，涵盖数字人、音频、具身智能、AI PPT 等细分领域
|
||||
|
||||
## Key Quotes
|
||||
> "我只是把 GitHub 上同一方向最火的开源项目揪了出来，并不代表开源项目的表现和效果一定能媲美闭源产品。" — 作者免责声明
|
||||
|
||||
## Key Concepts
|
||||
- [[开源大语言模型]]：以 DeepSeek、Qwen 为代表的开源基座大模型
|
||||
- [[AI生图模型]]：以 Flux、Stable Diffusion 为代表的开源图像生成模型
|
||||
- [[AI生视频模型]]：以 HunyuanVideo 为代表的开源视频生成模型
|
||||
- [[AI智能体]]：以 Manus/OpenManus 为代表的通用 AI 代理
|
||||
- [[AI编程工具]]：以 Cline 为代表的 AI 增强代码编辑器插件
|
||||
- [[智能体工作流]]：以 n8n、Dify 为代表的工作流自动化平台
|
||||
- [[AI搜索引擎]]：以 Perplexica 为代表的 AI 搜索开源项目
|
||||
- [[AI知识库]]：以 NotebookLM 开源平替为代表的 AI 知识管理工具
|
||||
|
||||
## Key Entities
|
||||
- [[DeepSeek]]：中国 AI 公司，开发 R1/V3 等开源大模型
|
||||
- [[Qwen]]：阿里云开发的大型语言模型（通义千问）
|
||||
- [[Flux]]：开源界的 Midjourney，出自前 SD 核心团队之手
|
||||
- [[Stable-Diffusion]]：老牌开源图像生成模型
|
||||
- [[HunyuanVideo]]：腾讯混元视频生成模型
|
||||
- [[Manus]]：定义 AI Agent 元年的里程碑式产品
|
||||
- [[OpenManus]]：Manus 最强开源平替
|
||||
- [[Cline]]：VS Code 生态中最强开源编程插件
|
||||
- [[n8n]]：最强工作流自动化开源项目（16 万 Star）
|
||||
- [[Dify]]：LLM 应用开发平台
|
||||
- [[Perplexica]]：Perplexity 开源平替
|
||||
|
||||
## Connections
|
||||
- [[DeepSeek]] ← 竞品 ← [[OpenAI]]
|
||||
- [[DeepSeek]] ← 竞品 ← [[Claude]]
|
||||
- [[Qwen]] ← 竞品 ← [[DeepSeek]]
|
||||
- [[Flux]] ← 竞品 ← [[Midjourney]]
|
||||
- [[Flux]] ← 竞品 ← [[Stable-Diffusion]]
|
||||
- [[HunyuanVideo]] ← 竞品 ← [[Veo-3]]
|
||||
- [[OpenManus]] ← 平替 ← [[Manus]]
|
||||
- [[Cline]] ← 平替 ← [[Cursor]]
|
||||
- [[n8n]] ← 平替 ← [[Zapier]]
|
||||
- [[Dify]] ← 竞品 ← [[n8n]]
|
||||
- [[Perplexica]] ← 平替 ← [[Perplexity]]
|
||||
|
||||
## Contradictions
|
||||
- （无）
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！"
|
||||
type: source
|
||||
tags: []
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills（技能）范式介绍与资源汇总
|
||||
- 问题域：AI 应用开发、提示词工程进阶
|
||||
- 方法/机制：Skills 是写给 Claude 的"SOP（标准作业程序）"，将反复执行、有固定流程的任务拆分为 AI 能理解、能稳定复用、能自动执行的流程
|
||||
- 结论/价值：Claude Skills 标志着从提示词工程迈向流程工程，未来最有价值的是能把业务流程沉淀为 SOP 并交给 AI 稳定执行的人
|
||||
|
||||
## Key Claims
|
||||
- Skills 本质上是"说明书"和"SOP"，将重复任务拆解为 AI 可复用的流程
|
||||
- Anthropic 官方 skills 仓库展示了 Claude.ai 网页版的真实生产级能力
|
||||
- Skills 分为办公自动化、开发者工具、创意类三大方向
|
||||
- 从提示词工程到流程工程是 AI 应用逻辑的质变
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 痕小子
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 痕小子
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Skills]]：写给 Claude 的"说明书"和 SOP，将反复执行的任务拆解为 AI 可复用的流程
|
||||
- [[提示语设计]]：通过精心设计的提示词提升 AI 输出质量的技术（本文指出应升级为 Skills）
|
||||
- [[Awesome-Claude-Skills]]：系统整理各类标准化 LLM Skills 工作流的精选仓库
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：发布官方 Skills 仓库的公司，Claude 的开发方
|
||||
- [[GitHub]]：托管 Skills 仓库的代码平台
|
||||
- [[痕小子]]：微信公众号「开源星探」作者，文章发布者
|
||||
|
||||
## Connections
|
||||
- [[Claude Skills]] ← extends ← [[提示语设计]]
|
||||
- [[Awesome-Claude-Skills]] ← depends_on ← [[GitHub]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: 3x-ui-xray-on-bandwagonvps
|
||||
title: 3X-UI Xray on BandwagonVPS
|
||||
type: source
|
||||
tags: [vps, xray, proxy, 科学上网]
|
||||
sources: []
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/3X-UI Xray on BandwagonVPS.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务
|
||||
- 问题域：科学上网、代理服务器配置
|
||||
- 方法/机制：3X-UI 面板 + VLESS+Reality 协议
|
||||
- 结论/价值：通过 Web 界面可视化管理 Xray 代理，支持多协议配置
|
||||
|
||||
## Key Claims
|
||||
- 3X-UI 提供可视化管理界面，可管理 Xray 运行状态
|
||||
- VLESS+Reality 协议组合提供更强的安全性和抗检测能力
|
||||
- Bandwagon VPS 可用于部署科学上网服务
|
||||
|
||||
## Key Quotes
|
||||
> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 3X-UI 一键安装命令
|
||||
|
||||
## Key Concepts
|
||||
- [[3X-UI]]：Xray 可视化管理面板
|
||||
- [[Xray]]：多功能代理软件
|
||||
- [[VLESS]]：轻量级代理协议
|
||||
- [[Reality]]：无 TLS 特征的 TLS 伪装协议
|
||||
- [[BBR]]：TCP 拥塞控制算法
|
||||
|
||||
## Key Entities
|
||||
- [[Bandwagon]]：VPS 服务提供商
|
||||
- [[VPS2]]：本案例中使用的服务器名称
|
||||
- [[v2rayN]]：Windows/Linux 代理客户端
|
||||
- [[v2rayNG]]：Android 代理客户端
|
||||
|
||||
## Connections
|
||||
- [[3X-UI]] ← manages ← [[Xray]]
|
||||
- [[Xray]] ← uses ← [[VLESS]]
|
||||
- [[Xray]] ← uses ← [[Reality]]
|
||||
- [[Bandwagon]] ← hosts ← [[VPS2]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: 7-ways-i-use-notebooklm-to-make-my-life-easier
|
||||
title: "7 ways I use NotebookLM to make my life easier"
|
||||
type: source
|
||||
tags: [productivity, AI, notebooklm]
|
||||
sources: ["https://www.howtogeek.com/ways-notebooklm-make-my-life-easier/"]
|
||||
last_updated: 2025-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/7 ways I use NotebookLM to make my life easier.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：NotebookLM 的 7 种高效使用场景
|
||||
- 问题域：信息处理、学习效率、项目管理、知识获取
|
||||
- 方法/机制：Source-grounding（源引用）、Audio Overviews（语音概述）、跨文档问答
|
||||
- 结论/价值：NotebookLM 通过严格限制知识库仅来自用户上传的文档，确保输出准确且有引用，可作为终身的 AI 助手
|
||||
|
||||
## Key Claims
|
||||
- NotebookLM 的核心优势在于 source-grounding，仅使用用户上传的文档作为知识库，确保输出的准确性
|
||||
- 通过 Audio Overviews 功能，可以将任何文档转化为双人对话播客，适合被动学习
|
||||
- 跨版本对比功能可以快速对比应用更新、文档版本差异，节省手动比对时间
|
||||
- 法律文档处理时，NotebookLM 只会根据给定内容回答，并提供精确引用，避免 AI 幻觉
|
||||
|
||||
## Key Quotes
|
||||
> "NotebookLM's entire knowledge base is strictly limited to the documents you specifically upload." — 核心机制说明
|
||||
> "This means the output it gives you is accurate and self-verified." — 准确性保证
|
||||
|
||||
## Key Concepts
|
||||
- [[Source-grounding]]：NotebookLM 的核心机制，仅使用用户上传的文档作为知识库
|
||||
- [[Audio Overviews]]：将文档转化为双人 AI 对话播客的功能
|
||||
- [[Source Citation]]：提供精确的文档引用，支持一键跳转查看原文
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：NotebookLM 的开发公司
|
||||
- [[NotebookLM]]：Google 的 AI 驱动的笔记和研究助手
|
||||
|
||||
## Connections
|
||||
- [[Claude]] ← similar_to ← [[NotebookLM]]
|
||||
- [[Audio Overviews]] ← enabled_by ← [[Source-grounding]]
|
||||
- [[Source Citation]] ← enabled_by ← [[Source-grounding]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "AI Memory Tools：两大阵营的深度解析"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题：AI Agent 记忆工具的两大技术路线
|
||||
- 问题域：如何让 AI Agent 在多会话中保持长期记忆和上下文
|
||||
- 方法/机制：
|
||||
- Camp 1：记忆后端（Memory Backend）— 从对话中提取事实，存入向量数据库，检索时提取
|
||||
- Camp 2：上下文基质（Context Substrate）— 维护结构化、可读的文件式上下文，随时间累积
|
||||
- 结论/价值：Camp 2 更适合持续运行、多项目、多会话的 AI Agent 架构
|
||||
|
||||
## Key Claims
|
||||
|
||||
- 记忆后端（Camp 1）问："AI 应该记住什么？"
|
||||
- 上下文基质（Camp 2）问："AI 应该在什么样的上下文中工作？"
|
||||
- Camp 1 优化的是"召回"（Recall）：能否找到正确的事实？
|
||||
- Camp 2 优化的是"累积"（Compounding）：系统是否随时间变得更好？
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "The model only 'remembers' what gets saved to disk, there is no hidden state." — OpenClaw 文档
|
||||
|
||||
> "Within 6 months, 'context engineering' will replace 'memory' as the default term for serious agent infrastructure."
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[记忆后端]]：从对话中自动提取事实，存储到向量数据库（Mem0、MemPalace、Supermemory）
|
||||
- [[上下文基质]]：维护结构化文件作为长期上下文，随时间累积（OpenClaw、Zep、Thoth）
|
||||
- [[记忆召回]]：检索特定事实，Mem0 等 Camp 1 工具解决的问题
|
||||
- [[上下文累积]]：系统随使用时间增长而变聪明，Camp 2 的核心价值
|
||||
- [[DAM]] — Dream Consolidation Process，OpenClaw 的夜间自动整理机制
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [Mem0](entities/Mem0.md)：Camp 1 类别领导者，53.1k GitHub stars
|
||||
- [MemPalace](entities/MemPalace.md)：本地优先、逐字存储方式，46.2k stars
|
||||
- [Supermemory](entities/Supermemory.md)：时间感知记忆，21.8k stars
|
||||
- [OpenClaw](entities/OpenClaw.md)：358k stars，Camp 2 代表，采用 Markdown 文件式上下文
|
||||
- [Zep](entities/Zep.md)：4.4k stars，从"记忆"重新定位为"上下文工程"，已靠近 Camp 2
|
||||
- [Thoth](entities/Thoth.md)：145 stars，夜间 dream cycle 最复杂的架构
|
||||
- [TrustGraph](entities/TrustGraph.md)：2.0k stars，Context Cores 概念，上下文版本化
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Mem0]] ← depends_on ← [[向量数据库]]
|
||||
- [[OpenClaw]] ← extends ← [[Markdown 文件]]
|
||||
- [[Zep]] ← uses ← [[时序知识图谱]]
|
||||
- [[Thoth]] ← uses ← [[Dream Cycle]]
|
||||
- [[DAM]] ← depends_on ← [[记忆提取]] — 夜间整理，将高频信息提升为持久记忆
|
||||
|
||||
## Contradictions
|
||||
|
||||
- **与 Mem0 类工具冲突**：
|
||||
- Camp 1 观点：事实应该被提取、嵌入、存储为向量
|
||||
- Camp 2 观点：事实应该保留在原始上下文中，作为文件的一部分
|
||||
- 当前观点：文件即真相，向量索引只是访问层而非存储层（MemSearch 的架构）
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "AI 解决方案专家培训课程"
|
||||
type: source
|
||||
tags: [ai, coze, 智能体, 培训]
|
||||
date: 2025-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/AI 解决方案专家培训课程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Coze（扣子）平台 AI Agent 开发实战培训
|
||||
- 问题域：企业级 AI 智能体在各行业的应用场景与开发方法
|
||||
- 方法/机制：通过 Demo 实例展示多行业 AI 解决方案，包含 Workflow、Bot、插件等开发模式
|
||||
- 结论/价值：覆盖金融、医疗、教育、电商、泛娱乐、人力资源、在线客服 7 大行业，提供可直接复用的 AI Agent 开发模板
|
||||
|
||||
## Key Claims
|
||||
- Coze 平台支持国内版（coze.cn）和海外版（coze.com）两个版本
|
||||
- AI Agent 开发可覆盖零售、医疗、金融、教育、人力资源、电商、泛娱乐等多个行业场景
|
||||
- Workflow 模式支持更复杂的企业级业务流编排
|
||||
|
||||
## Key Quotes
|
||||
> "Coze 平台是国内领先的 AI Agent 开发平台，支持零代码构建智能体"
|
||||
|
||||
## Key Concepts
|
||||
- [[Coze（扣子）]]：字节跳动旗下 AI Agent 开发平台
|
||||
- [[Workflow]]：工作流模式，支持复杂业务逻辑编排
|
||||
- [[Bot]]：对话型 AI 智能体
|
||||
- [[Function Call]]：函数调用能力，实现 Agent 与外部系统集成
|
||||
|
||||
## Key Entities
|
||||
- [[字节跳动]]：Coze 平台母公司
|
||||
- [[知乎]]：财报解读 Agent 演示
|
||||
- [[滴滴]]：出行行业计费规则解答 Agent 演示
|
||||
- [[SONY]]：零售门店店员 Agent 演示
|
||||
- [[医疗分诊助手]]：医疗行业 Agent 演示
|
||||
|
||||
## Connections
|
||||
- [[Coze（扣子）]] ← provides_platform ← [[AI 解决方案专家培训课程]]
|
||||
- [[金融行业客户分层营销助手]] ← extends ← [[Coze（扣子）]]
|
||||
- [[医疗分诊助手]] ← extends ← [[Coze（扣子）]]
|
||||
- [[教育行业知识库问答]] ← extends ← [[Coze（扣子）]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Building your Quartz"
|
||||
type: source
|
||||
tags:
|
||||
- clippings
|
||||
- quartz
|
||||
- obsidian
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Building your Quartz.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题：Quartz 静态站点构建与自托管指南
|
||||
- 问题域：静态站点生成与部署
|
||||
- 方法/机制：通过命令行构建 Quartz 静态站点，支持 Nginx、Apache、Caddy 三种自托管方案
|
||||
- 结论/价值：Quartz 将 Obsidian 笔记转化为可托管的静态网站
|
||||
|
||||
## Key Claims
|
||||
|
||||
- Quartz 将 Markdown 文件转化为 HTML、JS、CSS 静态文件
|
||||
- 自托管需要配置 Web 服务器处理无 .html 扩展名的 URL
|
||||
- 生产环境部署不应使用 --serve 模式
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "This will start a local web server to run your Quartz on your computer."
|
||||
|
||||
> "Serve mode is intended for local previews only. For production workloads, see the page on hosting."
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[静态站点生成]]：Quartz 将 Markdown 转换为静态 HTML 文件的技术
|
||||
- [[静态站点托管]]：通过 Web 服务器（Nginx/Apache/Caddy）托管静态文件
|
||||
- [[Quartz]]：Obsidian 笔记静态站点生成器
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Obsidian]]：本地笔记软件，Quartz 的内容来源
|
||||
- [[Nginx]]：高性能 Web 服务器，用于生产环境托管
|
||||
- [[Apache]]：老牌 Web 服务器，用于自托管方案
|
||||
- [[Caddy]]：自动 HTTPS 的现代 Web 服务器
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Obsidian]] →产出 [[静态站点生成]] → [[Quartz]]
|
||||
- [[静态站点托管]] ←依赖 [[Nginx]]
|
||||
- [[静态站点托管]] ←依赖 [[Apache]]
|
||||
- [[静态站点托管]] ←依赖 [[Caddy]]
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Claude Prompt 库汇总"
|
||||
type: source
|
||||
tags: [ai, claude, prompt]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Useful Prompt Lib.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude AI 助手提示词库的功能分类与推荐
|
||||
- 问题域：AI 提示词设计、自动化工作流、业务效率提升
|
||||
- 方法/机制：通过预制提示词模板实现特定任务自动化
|
||||
- 结论/价值：为 TikTok 跨境电商等业务场景提供可直接使用的提示词资源
|
||||
|
||||
## Key Claims
|
||||
- Babel's broadcasts 适合 TikTok 视频脚本的多语言本地化改写
|
||||
- Review classifier 可自动化处理和分类 TikTok 店铺或广告投放的评论
|
||||
- Data organizer 能快速将非结构化产品信息转化为 JSON 格式
|
||||
|
||||
## Key Quotes
|
||||
> 针对你目前的 TikTok 跨境电商业务，我建议你重点关注以下几个 Prompt 的逻辑
|
||||
|
||||
## Key Concepts
|
||||
- [[提示语设计]]：通过精心设计的提示词提升 AI 输出质量的技术
|
||||
- [[工作流自动化]]：预定义自动化流程，与 AI Agent 互补
|
||||
|
||||
## Key Entities
|
||||
- [Claude](entities/Claude.md) — Anthropic 公司开发的 AI 聊天助手
|
||||
|
||||
## Connections
|
||||
- [[提示语设计]] ← 应用场景 ← [[Claude]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [cloud, devops, maturity-model, enterprise]
|
||||
date: 2026-04-16
|
||||
source_file: raw/Cloud & DevOps/Cloud DevOp Maturity - Guideline.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
企业级 SaaS 公司的 Cloud DevOps 成熟度评估框架，涵盖成熟度定义、关键模型、基础支柱、工具选型、度量指标、挑战、案例及路线图。核心观点：DevOps 成熟度是持续改进过程，需通过自动化、文化协作、监控可观测性和安全集成实现组织级交付效率提升。
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度包含自动化、开发运维协作、交付速度和可靠性四个核心维度
|
||||
- CMMI 和 DORA 是评估 DevOps 成熟度的两大关键模型
|
||||
- DevOps 成熟度基础支柱包括：自动化、文化协作、监控可观测性、安全集成（DevSecOps）
|
||||
- CI/CD 流水线、IaC、测试自动化是成熟度提升的技术基础
|
||||
- DevOps 是持续改进过程，而非一次性目标
|
||||
|
||||
## Key Quotes
|
||||
> "DORA metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery (MTTR)" — DevOps Research & Assessment 核心度量指标
|
||||
> "Security must be integrated into the DevOps lifecycle through automation, continuous compliance, and proactive vulnerability management" — DevSecOps 核心原则
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps 成熟度模型]]：评估组织 DevOps 实践水平的分级框架
|
||||
- [[DORA 指标]]：DevOps Research & Assessment 提出的四项关键度量
|
||||
- [[CMMI]]：Capability Maturity Model Integration 能力成熟度模型集成
|
||||
- [[CI/CD 流水线]]：持续集成/持续交付自动化流程
|
||||
- [[IaC]]：Infrastructure as Code 基础设施即代码
|
||||
- [[DevSecOps]]：安全集成的 DevOps 实践
|
||||
- [[监控可观测性]]：Continuous monitoring, logging, and issue detection
|
||||
|
||||
## Key Entities
|
||||
- [[Terraform]]：IaC 工具
|
||||
- [[Ansible]]：配置管理工具
|
||||
- [[Kubernetes]]：容器编排平台
|
||||
- [[Docker]]：容器化技术
|
||||
- [[Prometheus]]：监控系统
|
||||
- [[Grafana]]：可视化监控仪表板
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 评估框架 ← [[DORA 指标]]
|
||||
- [[CI/CD 流水线]] ← 依赖 ← [[IaC]]
|
||||
- [[DevSecOps]] ← 依赖 ← [[监控可观测性]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无记录）
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "Cloud Maturity Model A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud-Adoption, Maturity-Model]
|
||||
date: 2024-07-08
|
||||
source_file: raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary
|
||||
Cloud Maturity Model（云成熟度模型，CMM）是一种用于评估组织云采纳就绪程度的框架。Forrester 预测全球 CMM 行业将从 2022 年的 7.5 亿美元增长至 2025 年的 15 亿美元。Gartner 指出超过 60% 的组织正在积极实施云成熟度模型。该模型通过 5 个等级（从无云准备到优化级）帮助组织评估当前状态并规划云迁移路径，同时覆盖业务和技术两大维度的多项能力领域。
|
||||
|
||||
## Key Claims
|
||||
- Cloud Maturity Model 是组织评估云采纳就绪程度的关键框架，适用于各种规模和云经验水平的组织
|
||||
- Forrester 预测全球 CMM 行业 2025 年将达到 15 亿美元（2022 年为 7.5 亿美元）
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型
|
||||
- Open Alliance for Cloud Adoption (OACA) 将 CMM 定义为帮助组织识别云或混合 IT 环境定制化解决方案的框架
|
||||
- CMM 涵盖 16 个业务能力领域和 18 个技术能力领域
|
||||
|
||||
## Key Quotes
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — 云成熟度模型的重要性说明
|
||||
> "Level five can be seen as an overinvestment if extensive hybrid cloud solutions are optional." — 关于第5级的现实性评价
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud-Maturity-Model]]：评估组织云采纳就绪程度的 5 级框架
|
||||
- [[Cloud-Adoption]]：将工作负载和服务从本地迁移到云的过程
|
||||
- [[Cloud-Native]]：利用云平台原生特性构建和运行应用的方法
|
||||
- [[Hybrid-Cloud]]：组合使用公有云和私有云的部署模式
|
||||
- [[Multi-Cloud]]：使用多个云服务商的服务
|
||||
- [[DevOps]]：结合开发和运营以实现持续软件交付的方法论
|
||||
- [[IaaS]]：基础设施即服务，提供虚拟计算资源
|
||||
- [[PaaS]]：平台即服务，提供应用开发和部署平台
|
||||
- [[SaaS]]：软件即服务，以订阅方式提供软件应用
|
||||
- [[CAPEX-to-OPEX]]：从资本支出向运营支出的转变
|
||||
- [[Cloud-Security-Maturity-Model-CSMM]]：评估云安全成熟度的模型
|
||||
- [[AWS-Cloud-Adoption-Framework]]：AWS 的云采纳框架
|
||||
- [[Azure-Cloud-Adoption-Framework]]：Azure 的云采纳框架
|
||||
- [[Google-Cloud-Adoption-Framework]]：Google Cloud 的云采纳框架
|
||||
- [[Cloud-Center-of-Excellence-CCOE]]：云卓越中心
|
||||
|
||||
## Key Entities
|
||||
- [[Open-Alliance-for-Cloud-Adoption-OACA]]：提出 CMM 定义的组织
|
||||
- [[Forrester]]：预测全球 CMM 行业增长的研究公司
|
||||
- [[Gartner]]：指出云成熟度模型快速采纳的研究公司
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Maturity-Model]] ← defines ← [[Cloud-Adoption]]
|
||||
- [[Cloud-Maturity-Model]] ← evaluated_by ← [[Cloud-Security-Maturity-Model-CSMM]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[AWS-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[Azure-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[Google-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Cloud Operating Model: Key Strategies and Best Practices"
|
||||
type: source
|
||||
tags: [cloud-operating-model, cloud-governance, finops]
|
||||
date: 2025-03-01
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云运营模型（COM）是组织有效管理云投资、实现安全、治理和可持续性的框架，包含治理、自动化、安全、成本管理四大支柱
|
||||
- 问题域：云迁移成本失控、安全漏洞、运营混乱、合规挑战
|
||||
- 方法/机制：云成熟度评估、FinOps 成本优化、Zero Trust 安全、多云策略、AI 驱动运营
|
||||
- 结论/价值：COM 是现代云战略的基础架构，无COM 企业面临成本失控、安全脆弱、运营低效风险
|
||||
|
||||
## Key Claims
|
||||
- 预测到 2025 年，89% 的组织将在云上运营
|
||||
- 59% 的企业在云成本管理上遇到困难，8% 关注可持续性
|
||||
- FinOps 可降低计算成本 40-70%
|
||||
- Zero Trust + 自动化安全补丁可减少 60% 安全事件
|
||||
- AI 驱动异常检测可减少 45% 停机时间
|
||||
|
||||
## Key Quotes
|
||||
> "A Cloud Operating Model brings order to this chaos, ensuring governance, security, and cost optimization are built into daily cloud operations."
|
||||
> "Without a structured operating model, businesses risk uncontrolled costs, security vulnerabilities, and operational inefficiencies."
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Operating Model]]：组织管理云资源的框架
|
||||
- [[FinOps]]：云财务运营，优化成本
|
||||
- [[Zero Trust Architecture]]：永不信任、始终验证的安全模型
|
||||
- [[Governance Framework]]：治理框架，确保合规
|
||||
- [[AIOps]]：AI 驱动的运维自动化
|
||||
- [[Multi-Cloud Strategy]]：多云策略，避免供应商锁定
|
||||
|
||||
## Key Entities
|
||||
- Gartner：提供 2025 年云采纳预测
|
||||
- Flexera：提供 2024 云状态报告
|
||||
- AWS：提供 IAM、Cost Explorer、GuardDuty 等云服务
|
||||
- Azure：提供 AD、Cost Management、Defender 等服务
|
||||
- GCP：提供 IAM、Billing Reports、Security Command Center
|
||||
|
||||
## Connections
|
||||
- [[Cloud Operating Model]] ← extends ← [[Cloud Maturity Model]]
|
||||
- [[Cloud Operating Model]] ← includes ← [[Governance Framework]]
|
||||
- [[Cloud Operating Model]] ← includes ← [[FinOps]]
|
||||
- [[Cloud Operating Model]] ← includes [[Zero Trust Architecture]]
|
||||
- [[FinOps]] ← applies_to ← [[Cost Optimization]]
|
||||
- [[Multi-Cloud Strategy]] ← prevents ← [[Vendor Lock-in]]
|
||||
- [[AIOps]] ← enables ← [[Self-Healing Systems]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## Industry Use Cases
|
||||
### Financial Services
|
||||
- 自动化合规监控降低云支出 30%，确保 PCI-DSS 合规，灾难恢复达 99.99% 可用性
|
||||
### Healthcare
|
||||
- AI 诊断提前疾病检测，数据处理时间减少 60%，自动化合规监控避免监管罚款
|
||||
### Retail & E-Commerce
|
||||
- 自动扩缩容处理 10 倍流量无性能下降，结账延迟降低 40%
|
||||
### SaaS & Tech
|
||||
- CI/CD 流水线减少 75% 部署失败，Kubernetes 自动扩缩容降低 40% 基础设施成本
|
||||
|
||||
## Challenges & Solutions
|
||||
- 供应商锁定 → 多云策略
|
||||
- 成本超支 → FinOps
|
||||
- 合规风险 → 自动化治理
|
||||
- 技能缺口 → 自动化工具
|
||||
|
||||
## Future Trends
|
||||
- AI/ML 驱动的预测性云管理
|
||||
- 可持续云计算与碳中和
|
||||
- 无服务器与边缘计算
|
||||
- 多云与混合云策略
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Dataview——让我从\"笔记黑洞\"里逃出来的 Obsidian 神器"
|
||||
type: source
|
||||
tags: [Obsidian, 插件, Dataview, 笔记管理]
|
||||
date: 2025-12-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器 1.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Dataview 插件让 Obsidian 笔记"活"起来，解决笔记越记越乱的问题
|
||||
- 问题域：笔记整理困难、查找效率低、待办事项分散
|
||||
- 方法/机制：通过类 SQL 查询语法自动整理和索引笔记内容
|
||||
- 结论/价值：Dataview 作为 Obsidian 的"笔记数据库"，可自动整理待办、学习笔记、写作素材等
|
||||
|
||||
## Key Claims
|
||||
- Dataview 是 Obsidian 里的"笔记数据库"，可自动整理各种内容
|
||||
- 简单查询 `LIST FROM "Notes" WHERE contains(tags, "学习")` 即可列出所有带 #学习 标签的笔记
|
||||
- Dataview 可用于管理任务、整理写作素材、统计笔记数量
|
||||
|
||||
## Key Quotes
|
||||
> "写笔记的时候激情满满，查笔记的时候满头大汗。" — 作者描述笔记使用困境
|
||||
|
||||
## Key Concepts
|
||||
- [[Dataview]]：Obsidian SQL 查询插件，可创建动态视图
|
||||
- [[信息黑洞]]：只收集不使用的笔记困境，Dataview 通过索引和查询帮助解决这个问题
|
||||
|
||||
## Key Entities
|
||||
- [[Obsidian]]：基于 Markdown 的本地优先笔记软件
|
||||
- [[Dataview]]：Obsidian 数据查询插件
|
||||
- [[Tasks 插件]]：Obsidian 任务管理插件
|
||||
|
||||
## Connections
|
||||
- [[Obsidian]] ← 使用 ← [[Dataview]]
|
||||
- [[Dataview]] ← 关联 → [[信息黑洞]]
|
||||
- [[Obsidian Tasks 插件]] ← 类似功能 → [[Dataview]]
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: [DevOps, Agile, 文化转型, 协作, 自动化]
|
||||
date: 2026-04-17
|
||||
source_file: raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
本文阐述 DevOps 文化与转型的核心原则与实践方法。DevOps 并非仅关于工具或自动化，而是一种优先考虑协作、持续学习和客户导向的文化与运营变革。文章涵盖 DevOps 文化的四大支柱、敏捷实践整合方法，以及驱动 DevOps 转型的战略蓝图，并展望了 AI/ML、GitOps、Serverless DevOps、Edge Computing IoT DevOps 和 DevSecOps 等未来趋势。
|
||||
|
||||
## Key Claims
|
||||
- DevOps 打破开发（Dev）与运维（Ops）之间的壁垒，通过跨职能团队实现整个软件生命周期的共同所有权
|
||||
- 自动化消除手动劳动，减少错误，加速反馈循环
|
||||
- DevOps 依赖迭代学习，通过无责复盘（blameless post-mortems）和混沌工程持续改进
|
||||
- 敏捷与 DevOps 具有共生关系，敏捷专注迭代开发，DevOps 将敏捷扩展到运维领域
|
||||
- DevOps 转型需要领导层支持、团队技能提升、小规模试点和逐步扩展
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心定义
|
||||
> "DevOps isn't a checkbox—it's a continuous evolution." — 关于 DevOps 本质
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps 文化]]：一种优先协作、持续学习和客户导向的文化理念
|
||||
- [[跨职能团队]]：开发与运维共享整个软件生命周期所有权的团队模式
|
||||
- [[CI/CD 流水线]]：自动化测试、集成和部署的持续集成/持续交付管道
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码实现一致性和版本控制的基础设施管理
|
||||
- [[持续改进 (Kaizen)]]：通过迭代学习不断优化流程的文化实践
|
||||
- [[无责复盘]]：不追究个人责任，聚焦问题本质的失败分析方法
|
||||
- [[混沌工程]]：主动测试系统韧性的实践方法
|
||||
- [[客户导向]]：以真实用户问题解决为核心的产品开发理念
|
||||
- [[特性开关]]：逐步发布功能以收集用户反馈的策略
|
||||
- [[A/B 测试]]：通过数据驱动决策优化用户体验
|
||||
- [[Agile 框架]]：Scrum（结构化迭代）和 Kanban（持续流）等敏捷方法论
|
||||
- [[Shift-Left 实践]]：将运维相关 concerns（安全、性能）前置到开发阶段
|
||||
- [[DevSecOps]]：在 CI/CD 流水线中深度集成安全工具
|
||||
- [[价值流映射]]：可视化工作流以消除浪费、识别延迟
|
||||
- [[价值流管理]]：通过价值流映射优化交付流程
|
||||
- [[GitOps]]：使用 Git 作为单一真相源来管理基础设施和部署
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）减少运维开销
|
||||
- [[AI/ML 在 DevOps 中的应用]]：智能自动化用于代码审查、异常检测和自愈基础设施
|
||||
|
||||
## Key Tools
|
||||
- CI/CD 工具：Jenkins、GitLab CI、GitHub Actions
|
||||
- IaC 工具：Terraform、AWS CloudFormation
|
||||
- 监控与可观测性工具：Prometheus、Grafana、Datadog
|
||||
- 团队协作工具：Slack、Microsoft Teams、Atlassian Jira
|
||||
- 安全工具：SonarQube、Snyk
|
||||
- 性能测试工具：JMeter、Locust
|
||||
- 容器化与编排：Docker、Kubernetes
|
||||
- 配置管理：Ansible
|
||||
- Serverless：AWS Lambda
|
||||
|
||||
## Key Entities
|
||||
（未发现具体人物或公司为关键实体）
|
||||
|
||||
## Connections
|
||||
- [[DevOps 文化]] ← 是核心主题 ← [[敏捷实践整合]]
|
||||
- [[自动化]] ← 加速反馈循环 ← [[CI/CD 流水线]]
|
||||
- [[持续改进]] ← 通过 [[无责复盘]] 和 [[混沌工程]] 实现
|
||||
- [[客户导向]] ← 通过 [[特性开关]] 和 [[A/B 测试]] 实现
|
||||
- [[Agile 框架]] ← 与 [[DevOps 文化]] 协同 ← [[Shift-Left 实践]]
|
||||
|
||||
## Contradictions
|
||||
（暂无冲突记录）
|
||||
|
||||
## Trends (未来趋势)
|
||||
- AI/ML in DevOps：代码审查、异常检测、自愈基础设施
|
||||
- GitOps：Git 即单一真相源
|
||||
- Serverless DevOps：FaaS 减少运维开销
|
||||
- Edge Computing IoT DevOps：边缘计算支持实时应用性能优化
|
||||
- DevSecOps：安全深度嵌入 CI/CD 流程
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps 成熟度五级框架，从传统 IT 过渡到完全成熟的 DevOps 实践
|
||||
- 问题域：组织 DevOps 实践水平评估、持续改进路径规划
|
||||
- 方法/机制：五大评估维度 × 五级成熟度阶段，系统化评估组织 DevOps 能力
|
||||
- 结论/价值：结构化框架帮助组织识别当前状态、规划改进路径、实现持续交付卓越
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度模型是评估组织 DevOps 实践的结构化框架，帮助评估当前实践、识别改进领域、规划升级路径
|
||||
- 五级成熟度：初始/应急 → 局部 DevOps → 自动化与定义 → 高度优化 → 完全成熟
|
||||
- 四大评估维度：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- DevSecOps 核心：将开发、运营、安全融合为统一流程
|
||||
- 关键指标：MTTR、MTTD、MTTA、部署频率、变更失败率、回滚率
|
||||
|
||||
## Key Quotes
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 核心理念
|
||||
|
||||
> "DevOps practices help organizations swiftly adjust to evolving market trends and customer needs." — 业务价值体现
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps 成熟度模型]]：评估组织 DevOps 实践水平的五级框架
|
||||
- [[CI/CD 流水线]]：自动化测试、集成和部署的持续交付管道
|
||||
- [[DevSecOps]]：在 CI/CD 流水线中深度集成安全工具的文化理念
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码实现一致性、版本控制的基础设施管理
|
||||
- [[DevOps 文化]]：打破开发与运维壁垒，优先协作、持续学习和客户导向的文化理念
|
||||
- [[MTTR]]：平均恢复时间，衡量故障恢复效率
|
||||
- [[IaC]]：基础设施即代码，自动化基础设施管理
|
||||
|
||||
## Key Entities
|
||||
（本文档未涉及需要创建页面的人、公司或产品实体）
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← extends ← [[DevOps]]
|
||||
- [[DevSecOps]] ← core_principle ← DevOps 与安全融合
|
||||
- [[CI/CD 流水线]] ← enables ← 持续交付
|
||||
- [[Infrastructure as Code (IaC)]] ← supports ← 基础设施自动化
|
||||
|
||||
## Contradictions
|
||||
（暂无）
|
||||
|
||||
## 五级成熟度对比
|
||||
|
||||
| 阶段 | 组织 | 交付 | 自动化 | 测试 | 安全 | 监控 |
|
||||
|------|------|------|--------|------|------|------|
|
||||
| Phase1 初始/应急 | 团队孤立工作 | 瀑布式、里程碑驱动 | 手动管理服务器 | 手动测试、瓶颈 | 发布前几周才介入 | 用户报告故障 |
|
||||
| Phase2 局部 DevOps | 小团队试点合作 | 引入敏捷实践 | 部分自动化 | 单元/集成/E2E 测试 | 独立安全团队 | 关键告警 |
|
||||
| Phase3 自动化与定义 | 标准流程定义 | 全面敏捷集成 | 大部分基础设施自动化 | 安全扫描集成到开发流程 | 安全参与设计讨论 | 持续监控 |
|
||||
| Phase4 高度优化 | 跨职能协作 | 频繁部署 | 不可变基础设施 | 性能/负载测试 | 依赖管理、持续监控 | 应用健康追踪 |
|
||||
| Phase5 完全成熟 | 自治全栈团队 | 每日多部署 | 零人工干预 | 实时数据决策 | 安全门禁 | 最高可用性 |
|
||||
|
||||
## 常见障碍
|
||||
- 开发与运维沟通不畅
|
||||
- 缺乏明确目标战略
|
||||
- 抵制变革
|
||||
- 投资不足
|
||||
- 治理薄弱
|
||||
- 流程僵化
|
||||
- 忽略终端用户
|
||||
- 与业务流程集成不足
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "French Consulting Market Navigator"
|
||||
type: source
|
||||
tags: [agent, french-market, freelance, esn, si]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-french-consulting-market.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：法国 IT 咨询市场（ESN/SI）自由职业者导航工具
|
||||
- 问题域：法国科技咨询市场的费率定位、平台选择、合同谈判和支付周期
|
||||
- 方法/机制：解析 ESN _margin 模型（25-40%）、portage salarial vs micro-entreprise vs SASU 的税费结构对比、平台费率矩阵、季节性市场动态
|
||||
- 结论/价值：帮助独立 IT 顾问最大化有效日费率、最小化支付风险、建立可持续客户关系
|
||||
|
||||
## Key Claims
|
||||
- Portage salarial 结构下 700 EUR/day TJM 实际净收入约 208 EUR/day，微型企业约 546 EUR/day，差距 338 EUR/day
|
||||
- Tier 1 ESN（Accenture、Capgemini）margin 35-50%，议价能力低；Tier 2（Cloudity、Niji）margin 25-40%，可协商
|
||||
- Malt 平台收取 10% 佣金（客户侧），费率公开成为市场锚点
|
||||
- 法国 ESN 链标准 NET-30 实际导致 60-90 天付款延迟
|
||||
- 低于 550 EUR/day 的高级 Salesforce 架构师费率会被 ESN 视为 desperation 信号
|
||||
|
||||
## Key Quotes
|
||||
> "A 600 EUR/day TJM through portage salarial yields approximately 300-330 EUR net after all charges. Through micro-entreprise, approximately 420-450 EUR." — TJM 净收入对比说明
|
||||
> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — 平台定价策略
|
||||
> "Portage provides unemployment rights (ARE), retirement contributions, and mutuelle. Micro-entreprise provides none of these. The 338 EUR/day gap is the price of social protection." — 社保差异说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Portage Salarial]]：法国特有的自由职业者雇佣结构，由 portage 公司作为雇主代缴社保， freelancers 保留独立性同时获得失业保险和退休金
|
||||
- [[Micro-Entrepreneur]]：法国简化商业结构，年营业额阈值内适用统一税率，无员工社保福利
|
||||
- [[TJM Brut]]：总日均费率（gross daily rate），ESN 向客户收取的日费率
|
||||
- [[ESN Margin]]：ESN 在 TJM brut 和支付给顾问费率之间的加价差额，Tier 1 35-50%，Tier 2 25-40%，Tier 3 15-25%
|
||||
- [[Seasonal Calendar]]：法国 IT 咨询市场的季节性规律（1月预算重启、7-8月夏季放缓、9月返校季高峰）
|
||||
|
||||
## Key Entities
|
||||
- [[Malt]]：法国主流自由职业平台，10% 佣金（客户侧），费率公开
|
||||
- [[collective.work]]：高端自由职业平台，3-5% 佣金+portage 集成，费率 650-800 EUR
|
||||
- [[Comet]]：科技导向平台，15% 佣金，算法匹配
|
||||
- [[Free-Work]]： listings 平台，免费发布+付费选项，费率 500-900 EUR
|
||||
- [[Crème de la Crème]]：高端精选平台，15-20% 佣金，准入严格
|
||||
- [[Accenture]] / [[Capgemini]] / [[Atos]] / [[CGI]]：Tier 1 全球性 ESN
|
||||
- [[Cloudity]] / [[Niji]] / [[SpikeeLabs]]：Tier 2 精品 ESN
|
||||
|
||||
## Connections
|
||||
- [[Portage Salarial]] ← depends_on ← [[French Tax System]]
|
||||
- [[ESN Margin]] ← margin_model ← [[ESN Tier Classification]]
|
||||
- [[Malt]] ← platform ← [[French Freelance Market]]
|
||||
- [[Rate Negotiation Playbook]] ← applies_to ← [[TJM Brut]]
|
||||
|
||||
## Contradictions
|
||||
- 与常见"法国自由职业税率更低"观点冲突：
|
||||
- 冲突点：微型企业实际净收入高于 portage salarial，但缺失社保福利（失业保险、退休金、mutuelle）
|
||||
- 当前观点：338 EUR/day 差距是社会保护的成本
|
||||
- 对方观点：微型企业净收入更高更划算
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: "GOG-CLI 安装配置指南"
|
||||
type: source
|
||||
tags: [gog-cli, macos, google-workspace, oauth]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/GOG-CLI-安装配置指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 macOS 系统上安装和配置 gog CLI，通过命令行管理 Google Workspace（Gmail、Google Calendar、Google Drive、Google Contacts、Google Docs、Google Sheets）
|
||||
- 问题域：Google API 集成、OAuth 认证、CLI 工具配置
|
||||
- 方法/机制：Homebrew 安装、OAuth 凭证配置、Google Cloud Console 设置、API 启用
|
||||
- 结论/价值：实现 Google 六大服务的命令行化管理，提升自动化效率
|
||||
|
||||
## Key Claims
|
||||
- gog CLI 是管理 Google Workspace 的命令行工具，支持 Gmail、Calendar、Drive、Contacts、Docs、Sheets 六大服务
|
||||
- OAuth 授权需要两层配置：用户身份认证（OAuth）+ API 服务启用（API Enablement）
|
||||
- Google 未验证应用需要添加测试用户才能授权
|
||||
|
||||
## Key Quotes
|
||||
> "此应用未经 Google 验证" — 首次授权时 Google 的安全限制提示
|
||||
|
||||
> "此应用请求访问您 Google 账号中的敏感信息" — OAuth 权限请求说明
|
||||
|
||||
## Key Concepts
|
||||
- [[OAuth]]：开放授权协议，用于第三方应用访问用户 Google 账号
|
||||
- [[Google-Cloud-Console]]：Google 云平台控制台，管理 API 启用和 OAuth 凭证
|
||||
- [[Gmail-API]]：Google 邮件服务编程接口
|
||||
- [[Calendar-API]]：Google 日历服务编程接口
|
||||
- [[Drive-API]]：Google 云端硬盘服务编程接口
|
||||
- [[API-Enablement]]：Google Cloud 中启用特定 API 服务的操作
|
||||
- [[测试用户]]：Google OAuth 中允许未经验证的应用进行测试的账号
|
||||
|
||||
## Key Entities
|
||||
- [[Homebrew]]：macOS 包管理器，用于安装 gog CLI
|
||||
- [[Google]]：Google 公司，开发 gog CLI 工具
|
||||
- [[gog CLI]]：Google Workspace 命令行管理工具（本次创建）
|
||||
- [[steipete-tap-gogcli]]：gog CLI 的 Homebrew 官方仓库（本次创建）
|
||||
|
||||
## Connections
|
||||
- [[Homebrew]] ← 安装于 ← [[GOG-CLI-安装配置指南]]
|
||||
- [[Google-Cloud-Console]] ← 创建凭证于 ← [[GOG-CLI-安装配置指南]]
|
||||
- [[OAuth]] ← 授权机制于 ← [[GOG-CLI-安装配置指南]]
|
||||
- [[gog CLI]] ← 工具实现于 ← [[GOG-CLI-安装配置指南]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
id: google-5-agent-skill-design-patterns-2026-03-19
|
||||
title: "Google 5个Agent Skill设计模式"
|
||||
type: source
|
||||
tags: [Agent, Skill, 设计模式, Google, Anthropic]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/Google-5个Agent-Skill设计模式-2026-03-19.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google 发布的 5 种 Agent Skill 设计模式
|
||||
- 问题域：Agent Skill 内容设计
|
||||
- 方法/机制：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline 五种模式
|
||||
- 结论/价值：不同模式适用于不同场景，可以组合使用，ADK 的 SkillToolset 和渐进式披露机制实现按需加载
|
||||
|
||||
## Key Claims
|
||||
- Tool Wrapper 模式让 agent 快速成为某个领域的专家，通过监听特定关键词动态加载相关文档
|
||||
- Generator 模式通过模板和样式指南强制一致的输出格式，解决 agent 输出结构不一致的问题
|
||||
- Reviewer 模式把检查清单和检查逻辑分开，审查标准可动态替换实现不同专项审计
|
||||
- Inversion 模式让 agent 先问用户再做，通过明确门控指令确保用户参与每个阶段
|
||||
- Pipeline 模式带硬性检查点的严格工作流，强制执行顺序并设置前置条件确认
|
||||
|
||||
## Key Quotes
|
||||
> "最好的 Skill 不是写得好的提示词，而是一个「工具箱」" — Anthropic 经验
|
||||
|
||||
## Key Concepts
|
||||
- [[渐进式披露]]：agent 只在运行时需要时才消耗上下文 token 来加载特定模式
|
||||
- [[SkillToolset]]：ADK 提供的 skill 工具集，支持按需加载
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：发布该设计模式指南的云服务提供商
|
||||
- [[Anthropic]]：Claude 开发者，提出 Skill 设计的九类分类
|
||||
- [[ADK]]：Agent Development Kit，Google 的 agent 开发工具包
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] ← provides_skill_guidance ← [[Google]]
|
||||
- [[Tool Wrapper]] ← is_variant_of ← [[Agent-Skill-模式]]
|
||||
- [[Generator]] ← is_variant_of ← [[Agent-Skill-模式]]
|
||||
- [[Reviewer]] ← is_variant_of ← [[Agent-Skill-模式]]
|
||||
- [[Inversion]] ← is_variant_of ← [[Agent-Skill-模式]]
|
||||
- [[Pipeline]] ← is_variant_of ← [[Agent-Skill-模式]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "Google 神级生产力工具，所有 GitHub 开源平替都找到了"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google NotebookLM 开源平替工具汇总
|
||||
- 问题域：AI 笔记助手、播客生成工具、知识管理
|
||||
- 方法/机制：本地化部署、多模型支持、语义搜索、RAG
|
||||
- 结论/价值：7 款开源平替方案，覆盖文档问答、播客生成、学习辅助等场景
|
||||
|
||||
## Key Claims
|
||||
- Open Notebook 是 GitHub Star 最高的 NotebookLM 开源平替（14.6k Star），支持 16+ AI 提供商和本地模型
|
||||
- SurfSense 定位为 NotebookLM、Perplexity 和 Glean 的综合开源替代品（11.4k Star）
|
||||
- Podcastfy 专注播客生成，整合 100+ LLM 和多种 TTS 引擎
|
||||
- PageLM 将学习材料转化为互动式资源，支持康奈尔笔记、闪卡、模拟考试
|
||||
|
||||
## Key Quotes
|
||||
> "它最出圈的功能是播客生成，能一键把你上传的复杂资料转换成一段逼真的双人英语对话播客" — 描述 NotebookLM 核心功能
|
||||
|
||||
## Key Concepts
|
||||
- [[开源平替]]：功能可替代闭源商业产品的开源项目
|
||||
- [[RAG]]：检索增强生成，结合知识库和 AI 生成答案
|
||||
- [[语义搜索]]：理解查询意图的搜索技术
|
||||
- [[TTS]]：文本转语音技术
|
||||
- [[多模型支持]]：支持 OpenAI、Anthropic、Gemini、Ollama 等多种 AI 模型
|
||||
- [[RBAC]]：基于角色的访问控制
|
||||
|
||||
## Key Entities
|
||||
- [[Open Notebook]]：GitHub Star 最高的 NotebookLM 开源平替（14.6k）
|
||||
- [[SurfSense]]：综合 AI 搜索与研究智能体（11.4k Star）
|
||||
- [[Podcastfy]]：专注播客生成的工具
|
||||
- [[NotebookLlama]]：LlamaIndex 官方推出的开源项目（1.7k Star）
|
||||
- [[PageLM]]：教育平台，将学习材料转化为互动资源
|
||||
- [[InsightsLM]]：低代码/无代码方案的 NotebookLM 替代
|
||||
- [[NotebookLM]]：Google AI 笔记助手，核心功能是播客生成
|
||||
- [[LlamaIndex]]：开源数据框架，用于构建 LLM 应用
|
||||
|
||||
## Connections
|
||||
- [[Open Notebook]] ← 替代 ← [[NotebookLM]]
|
||||
- [[SurfSense]] ← 替代 ← [[NotebookLM]]
|
||||
- [[SurfSense]] ← 替代 ← [[Perplexity]]
|
||||
- [[Podcastfy]] ← 专注于 ← [[NotebookLM]]播客功能
|
||||
- [[PageLM]] ← 扩展 ← [[NotebookLM]]学习场景
|
||||
- [[InsightsLM]] ← 基于 ← [[Supabase]] + [[n8n]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "How Agentic AI can help for Cloud DevOps"
|
||||
type: source
|
||||
tags: [Cloud DevOps, Agentic AI, AIOps]
|
||||
date: 2026-04-16
|
||||
sources: ["How Agentic AI can help for Cloud DevOps.md"]
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md]]
|
||||
|
||||
## Summary
|
||||
Agentic AI（具备自主决策和任务执行能力的 AI 系统）通过自动化复杂工作流、提升效率、确保云环境可靠性，显著增强 Cloud DevOps 能力。涵盖七大领域：自主事件检测与响应、自动化云部署与配置、智能成本优化、AI 驱动安全与合规、智能日志分析与可观测性、SaaS 多租户管理增强、AI 辅助决策。
|
||||
|
||||
## Key Claims
|
||||
- Agentic AI 可将 MTTR（平均修复时间）缩短并确保 SLA 合规
|
||||
- AI 作为发布经理可自动化特性标志测试、回滚决策及部署策略（Blue/Green、Canary）
|
||||
- AI 驱动的权限管理可识别过度宽松的 IAM 角色并自动修复
|
||||
- AI 可通过分析历史 outage 模式进行预测性维护
|
||||
|
||||
## Key Quotes
|
||||
> "Agentic AI transforms Cloud DevOps by automating incident response, cost management, security, observability, and multi-cloud governance." — 结论
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic AI]]：具备自主决策和任务执行能力的 AI 系统
|
||||
- [[Self-Healing Systems]]：主动检测异常并自动修复的系统
|
||||
- [[AI-driven RCA]]：利用 AI 分析日志进行根因分析
|
||||
- [[Predictive Maintenance]]：从历史 outage 学习模式并主动推荐补丁或扩缩容
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施（Terraform、CloudFormation、Pulumi）
|
||||
- [[IaC Management]]：AI 代理审查 IaC 脚本并在执行前提出改进建议
|
||||
- [[Dynamic Configuration Management]]：基于实时性能和成本效率动态调整应用配置
|
||||
- [[Cost Optimization]]：AI 分析使用趋势，动态扩缩资源防止过度配置
|
||||
- [[Spot Instance Optimization]]：在工作负载之间智能切换 Spot/Preemptible 实例
|
||||
- [[Automated Security Audits]]：扫描 IAM 策略、网络规则、容器漏洞
|
||||
- [[Dynamic Threat Mitigation]]：检测安全风险并自动修复
|
||||
- [[Compliance Enforcement]]：实时监控 SOC 2、FedRAMP、PCI DSS 合规性
|
||||
- [[AI-powered Log Analysis]]：分析 CloudWatch、ELK、OpenTelemetry、Datadog 日志
|
||||
- [[AI ChatOps]]：通过 Slack、Teams 或 CLI 进行 AI 驱动的故障排除
|
||||
- [[Multi-Tenant Management]]：SaaS 多租户自动配置、扩缩容和租户隔离
|
||||
- [[Tenant Provisioning]]：AI 代理动态创建和配置新租户
|
||||
- [[AI-powered Runbooks]]：AI 推荐最佳运维手册处理事件
|
||||
- [[What-If Simulations]]：预测云迁移、实例类型变更或架构变更的影响
|
||||
- [[AI-based Anomaly Detection]]：标记性能、安全或成本趋势的偏差
|
||||
|
||||
## Key Entities
|
||||
- [[Kubernetes]]（EKS、GKE、AKS）：容器编排平台
|
||||
- [[AWS]]：Amazon 云服务平台（EKS、RDS、S3、Lambda、CloudWatch、IAM、Spot、Inspector）
|
||||
- [[GCP]]：Google Cloud Platform（GKE、GCS、Cloud SQL、Security Command Center、Preemptible）
|
||||
- [[Azure]]：Microsoft 云平台（AKS、Cosmos DB、Blob Storage、Azure Monitor、Azure Defender、Savings Plan）
|
||||
- [[Terraform]]、[[CloudFormation]]、[[Pulumi]]：IaC 工具
|
||||
- [[CloudWatch]]、[[Stackdriver]]、[[ELK]]、[[OpenTelemetry]]、[[Datadog]]：监控与日志工具
|
||||
- [[Slack]]、[[Teams]]：协作平台
|
||||
- [[SOC 2]]、[[FedRAMP]]、[[PCI DSS]]：安全合规框架
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[Agentic AI]]：Agentic AI 扩展了 DevOps 的自动化能力
|
||||
- [[Cloud Security]] ← supports ← [[Agentic AI]]：Agentic AI 增强了云安全自动化
|
||||
- [[Auto-scaling]] ← extends ← [[Agentic AI]]：Agentic AI 提供更智能的动态扩缩
|
||||
- [[CI/CD 流水线]] ← extends ← [[Agentic AI]]：Agentic AI 作为发布经理自动化部署策略
|
||||
- [[Infrastructure as Code (IaC)]] ← enhanced_by ← [[Agentic AI]]：AI 审查和改进 IaC 脚本
|
||||
- [[DevSecOps]] ← extends ← [[Agentic AI]]：Agentic AI 实现自动化安全审计和合规执行
|
||||
|
||||
## Contradictions
|
||||
- （暂无已知冲突）
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
source_file: raw/Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
本文探讨多云策略（Multi-Cloud Strategy）的定义、优势及实施方法。多云策略指同时使用多个云服务商（如AWS、Azure、Google Cloud）的服务，避免单一供应商锁定，通过利用各提供商的优势服务来提升效率、安全性和性能。研究数据显示，78%的企业已采用多云策略，86%的公司计划到2024年底采用多云方案，优化后可实现30%的运营成本降低。
|
||||
|
||||
## Key Claims
|
||||
- 多云策略能有效避免供应商锁定（Vendor Lock-In），让企业根据具体需求选择最佳云服务
|
||||
- 多云环境提供更高的弹性和可靠性，单一提供商故障不会导致整体服务中断
|
||||
- 多云部署可提升安全 posture，通过在不同环境部署不同安全机制降低网络攻击风险
|
||||
- 通过竞争性定价和资源优化，企业可实现显著的成本降低（报告示例如30%运营成本减少）
|
||||
- 多云策略满足不同地区和行业的监管合规要求，支持数据主权（Data Sovereignty）
|
||||
|
||||
## Key Quotes
|
||||
> "A multi-cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology
|
||||
> "78% of businesses leveraging a multi-cloud strategy have workloads deployed in more than three public clouds for better agility and cost savings" — Virtana Research
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Cloud]]：使用多个云服务商服务的部署策略
|
||||
- [[Vendor Lock-In]]：供应商锁定，指企业依赖单一供应商难以迁移的状态
|
||||
- [[Cloud ROI]]：（隐含概念）云投资回报率
|
||||
- [[Data Sovereignty]]：数据主权，指数据受当地法律法规约束的原则
|
||||
- [[Cloud Security]]：（隐含）多云环境下的安全管理实践
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：亚马逊云服务，主要基础设施提供商
|
||||
- [[Azure]]：微软云平台，AI工具优势
|
||||
- [[Google Cloud]]：Google云平台，机器学习和分析服务优势
|
||||
- Bacancy Technology：本文来源公司
|
||||
|
||||
## Connections
|
||||
- [[Multi-Cloud]] ← depends_on ← [[AWS]], [[Azure]], [[Google Cloud]]
|
||||
- [[Multi-Cloud]] ← supports ← [[Cloud-Adoption]]
|
||||
- [[Multi-Cloud]] ← enables ← [[DevOps]] （通过提升弹性和效率）
|
||||
- [[Multi-Cloud]] ← relates_to ← [[Cloud Security]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现矛盾
|
||||
|
||||
## Real-World Use Cases
|
||||
- **电商**：高峰期（黑色星期五、网络星期一）弹性扩展
|
||||
- **医疗**：HIPAA合规，区域数据主权要求
|
||||
- **金融**：强化安全、合规、最大化投资回报
|
||||
|
||||
## Implementation Steps
|
||||
1. 评估需求（目标、预算、资源）
|
||||
2. 选择合适提供商（对齐服务与需求）
|
||||
3. 集成与管理（采用Kubernetes、Terraform等工具）
|
||||
4. 监控与优化（持续跟踪性能和成本）
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
id: LLM-Wiki
|
||||
title: "LLM Wiki"
|
||||
type: source
|
||||
tags: [llm, wiki, knowledge-management]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/LLM Wiki.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：LLM 持续构建和维护的持久化 wiki 体系
|
||||
- 问题域：RAG 每次查询都重新拼接知识、缺少积累；聊天记录无法成为可维护的知识资产
|
||||
- 方法/机制：raw sources → LLM 编译成 wiki → 持续更新 index / overview / entity / concept / log
|
||||
- 结论/价值：知识从一次性回答变成可累积、可追溯、可维护的长期资产
|
||||
|
||||
## Key Claims
|
||||
- 传统 RAG 在查询时临时检索片段，知识不会自动沉淀
|
||||
- LLM Wiki 的核心不是“回答”，而是“编译并维护”一个结构化、互联的知识库
|
||||
- wiki 是持久化的 compounding artifact，跨来源的交叉引用和矛盾标注会随着时间累积
|
||||
- 人负责选题和判断，LLM 负责摘要、交叉引用、归档和 bookkeeping
|
||||
|
||||
## Key Quotes
|
||||
> "the wiki is a persistent, compounding artifact" — 对知识库长期价值的定义
|
||||
|
||||
> "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." — 对工作流分工的比喻
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：对照对象；LLM Wiki 超越的是纯检索式工作流
|
||||
- [[Source-grounding]]：都强调从受控来源出发，但 LLM Wiki 更强调持续编译和维护
|
||||
- [[Second Brain]]：同属个人知识管理范式，但 LLM Wiki 更结构化、更可维护
|
||||
- [[Knowledge Base]]：LLM Wiki 目标是让知识库真正“活”起来
|
||||
- [[Graph View]]：用链接网络观察 wiki 的结构与孤岛
|
||||
- [[Obsidian]]：文中提到的阅读与维护界面
|
||||
- [[NotebookLM]]：与 source-grounding 思路相近的参考产品
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：文中使用的自动化/记忆工作流类比对象
|
||||
- [[Tolkien Gateway]]：示例性的长期演化粉丝 wiki
|
||||
- [[Memex]]：与“关联轨迹”理念相关的历史原型
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← contrasted_with ← [[LLM Wiki]]
|
||||
- [[Source-grounding]] ← related_to ← [[LLM Wiki]]
|
||||
- [[Second Brain]] ← overlaps_with ← [[LLM Wiki]]
|
||||
- [[Knowledge Base]] ← implemented_as ← [[LLM Wiki]]
|
||||
- [[Graph View]] ← helps_visualize ← [[LLM Wiki]]
|
||||
- [[Obsidian]] ← hosts ← [[LLM Wiki]]
|
||||
- [[NotebookLM]] ← inspired_by ← [[LLM Wiki]]
|
||||
|
||||
## Contradictions
|
||||
- 与纯 [[RAG]] 工作流冲突：
|
||||
- 冲突点：查询时临时检索 vs 持续编译沉淀
|
||||
- 当前观点：知识应进入可维护 wiki，而不是每次从原始文档重新拼接
|
||||
- 对方观点：原始文档只做检索，不承担知识累积责任
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "LLMs、RAG、AI Agent 三个到底什么区别？"
|
||||
type: source
|
||||
tags: [llm, rag, ai-agent]
|
||||
date: 2025-11-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/LLMs、RAG、AI Agent 三个到底什么区别？.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：LLM（大型语言模型）、RAG（检索增强生成）、AI Agent（人工智能代理）三者区别
|
||||
- 问题域：AI 应用开发基础概念区分
|
||||
- 方法/机制：
|
||||
- LLM = "天才大脑"，擅长思考但对当前情况无知
|
||||
- RAG = "随身图书馆助理"，为 LLM 提供实时外部知识
|
||||
- AI Agent = 行动系统，感知→规划→执行→反思的循环
|
||||
- 结论/价值：三者不是竞争技术，而是在不同层面满足不同场景的能力组合，未来架构应将三者结合
|
||||
|
||||
## Key Claims
|
||||
- LLM 只能回答训练数据截止时间之前的问题，对实时信息一无所知
|
||||
- RAG 通过检索外部知识库为 LLM 提供实时信息，极大降低幻觉
|
||||
- AI Agent 通过五步循环（获取任务→扫描场景→思考→行动→迭代）实现自主决策和执行
|
||||
- 最佳实践：LLM 负责推理，RAG 确保准确性，Agent 实现自主性
|
||||
|
||||
## Key Quotes
|
||||
> "LLM 在思考方面非常出色，但对当前情况却一无所知。" — 作者观点
|
||||
> "RAG 就像是给那个'全能天才大脑'配备了一位随身图书馆助理。" — 作者类比
|
||||
> "AI Agent 围绕大脑 LLM 构建一个循环控制系统，能够感知目标、规划步骤、执行动作、并能够反思结果。" — 作者定义
|
||||
> "未来不在于选择其一。而在于将三者结合起来进行架构设计。用于思考的 LLMs，用于认知的 RAG，用于执行的 Agent。" — 核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[LLM]]：大型语言模型，AI 应用的"天才大脑"
|
||||
- [[RAG]]：检索增强生成，为 LLM 提供外部实时知识的机制
|
||||
- [[AI代理]]：具备自主决策和任务执行能力的 AI 系统
|
||||
- [[向量数据库]]：RAG 系统中存储和检索知识的技术
|
||||
- [[NL2SQL]]：自然语言转 SQL，使 Agent 能查询数据库
|
||||
|
||||
## Key Entities
|
||||
- [[ChatGPT]]：OpenAI 开发的底座大模型
|
||||
- [[DeepSeek]]：中国开发的大语言模型
|
||||
- [[Qwen]]：阿里云开发的大语言模型
|
||||
- [[Midjourney]]：专用于图像生成的 AI 模型
|
||||
- [[Stable Diffusion]]：开源图像生成模型
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← depends_on ← [[RAG]]
|
||||
- [[RAG]] ← provides_context ← [[向量数据库]]
|
||||
- [[AI代理]] ← uses ← [[LLM]]
|
||||
- [[AI代理]] ← uses ← [[RAG]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无冲突记录）
|
||||
@@ -1,205 +0,0 @@
|
||||
---
|
||||
title: Last30Days 使用指南
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/Last30Days-使用指南.md]]
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
`/last30days` 研究过去 30 天内在 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket 和网页上的热门内容，生成研究报告。
|
||||
|
||||
**特点**: 深度研究需要 2-8 分钟，支持 8 个数据来源，结果自动保存到 `~/Documents/Last30Days/`
|
||||
|
||||
---
|
||||
|
||||
## 调用方式
|
||||
|
||||
```bash
|
||||
python3 ~/.openclaw/skills/last30days-official/scripts/last30days.py "<话题>" --emit=compact --no-native-web --save-dir=~/Documents/Last30Days
|
||||
```
|
||||
|
||||
### 示例
|
||||
```bash
|
||||
# 基本搜索
|
||||
python3 ~/.openclaw/skills/last30days-official/scripts/last30days.py "AI一人公司"
|
||||
|
||||
# 指定 X 账号搜索
|
||||
python3 ~/.openclaw/skills/last30days-official/scripts/last30days.py "OpenClaw" --x-handle=openclawai
|
||||
|
||||
# 对比模式
|
||||
python3 ~/.openclaw/skills/last30days-official/scripts/last30days.py "cursor vs windsurf"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 参数说明
|
||||
|
||||
| 参数 | 说明 | 示例 |
|
||||
| `--days=N` | 回溯 N 天（默认30天） | `--days=7` |
|
||||
| `--quick` | 快速模式（8-12条/来源） | |
|
||||
| `--deep` | 深度模式（50-70条Reddit，40-60条X） | |
|
||||
| `--x-handle=HANDLE` | 指定 X 账号搜索（不含@） | `--x-handle=elonmusk` |
|
||||
| `--emit=compact` | 紧凑输出 | |
|
||||
| `--no-native-web` | 不使用内置 web 搜索 | |
|
||||
| `--save-dir=PATH` | 保存目录 | `--save-dir=~/Documents/Last30Days` |
|
||||
|
||||
---
|
||||
|
||||
## 数据来源
|
||||
|
||||
| 来源 | 权重 | 说明 |
|
||||
|------|------|------|
|
||||
| Reddit | 高 | 有 upvotes、comments 互动数据 |
|
||||
| X (Twitter) | 高 | 有 likes、retweets 互动数据 |
|
||||
| YouTube | 高 | 有观看数、likes 和字幕 |
|
||||
| TikTok | 中 | 有观看数、likes 和标题 |
|
||||
| Instagram | 中 | 有观看数、likes 和标题 |
|
||||
| Hacker News | 中 | 有 points、comments |
|
||||
| Polymarket | 高 | 真实钱币投注，数据真实可信 |
|
||||
| Web | 低 | 无互动数据，补充博客/新闻 |
|
||||
|
||||
**权重说明**: Reddit/X > YouTube > TikTok > Polymarket > Web
|
||||
|
||||
---
|
||||
|
||||
## 输出格式
|
||||
|
||||
### 1. What I Learned（研究发现）
|
||||
- 基于 QUERY_TYPE 类型的摘要
|
||||
- 引用真实来源（@handle、r/subreddit）
|
||||
- 3-5 个关键模式
|
||||
|
||||
### 2. Key Patterns（关键模式）
|
||||
- 按权重排序的模式列表
|
||||
- 每个模式注明来源
|
||||
|
||||
### 3. Stats（统计数据）
|
||||
```
|
||||
├─ 🟠 Reddit: N threads │ N upvotes │ N comments
|
||||
├─ 🔵 X: N posts │ N likes │ N reposts
|
||||
├─ 🔴 YouTube: N videos │ N views │ N with transcripts
|
||||
├─ 🎵 TikTok: N videos │ N views │ N likes
|
||||
├─ 📸 Instagram: N reels │ N views │ N likes
|
||||
├─ 🟡 HN: N stories │ N points │ N comments
|
||||
├─ 📊 Polymarket: N markets │ 相关赔率
|
||||
├─ 🌐 Web: N pages — Source Name, Source Name
|
||||
└─ 🗣️ Top voices: @handle1, @handle2
|
||||
```
|
||||
|
||||
### 4. Invitation（推荐下一步）
|
||||
根据 QUERY_TYPE 类型推荐后续操作
|
||||
|
||||
---
|
||||
|
||||
## API Keys 配置
|
||||
|
||||
在 `~/.openclaw/.env` 中配置：
|
||||
|
||||
```bash
|
||||
# 必填
|
||||
SCRAPECREATORS_API_KEY=*** # Reddit + TikTok + Instagram（一个 key 覆盖三个）
|
||||
|
||||
# X/Twitter 搜索（2选1）
|
||||
AUTH_TOKEN=*** # 方案1: 从浏览器 cookie 复制
|
||||
CT0=... # 方案1: 从浏览器 cookie 复制
|
||||
XAI_API_KEY=*** # 方案2: XAI API Key
|
||||
|
||||
# Web 搜索（可选）
|
||||
OPENROUTER_API_KEY=*** # OpenRouter/Perplexity
|
||||
TAVILY_API_KEY=*** # Brave Search
|
||||
PARALLEL_API_KEY=*** # Parallel AI
|
||||
|
||||
# Bluesky（可选）
|
||||
BSKY_HANDLE=you.bsky.social
|
||||
BSKY_APP_PASSWORD=***
|
||||
```
|
||||
|
||||
### 当前已配置
|
||||
- ✅ SCRAPECREATORS_API_KEY
|
||||
- ✅ XAI_API_KEY
|
||||
- ✅ OPENROUTER_API_KEY
|
||||
- ✅ TAVILY_API_KEY
|
||||
|
||||
---
|
||||
|
||||
## 新功能 (v2.9.5)
|
||||
|
||||
### Bluesky 支持
|
||||
- 需要 BSKY_HANDLE + BSKY_APP_PASSWORD
|
||||
- 创建 app password: bsky.app/settings/app-passwords
|
||||
|
||||
### Comparative Mode（对比模式）
|
||||
```bash
|
||||
"cursor vs windsurf" # 得到并排对比
|
||||
```
|
||||
|
||||
### Per-project .env
|
||||
在项目根目录创建 `.claude/last30days.env` 覆盖全局配置
|
||||
|
||||
### SessionStart config check
|
||||
Claude Code 启动时自动验证配置
|
||||
|
||||
---
|
||||
|
||||
## 最佳实践
|
||||
|
||||
### 1. 选择合适的深度
|
||||
| 场景 | 推荐 |
|
||||
|------|------|
|
||||
| 测试话题 | `--quick` |
|
||||
| 每周追踪 | `--days=7 --quick` |
|
||||
| 深度研究 | `--deep` |
|
||||
| 全面研究 | 默认 30 天 |
|
||||
|
||||
### 2. X 账号精确搜索
|
||||
如果搜索人物/品牌，加上 `--x-handle`：
|
||||
```bash
|
||||
--x-handle=openclawai # 搜索 OpenClaw 官方帖子
|
||||
```
|
||||
|
||||
### 3. 对比模式
|
||||
问 "X vs Y" 得到并排对比研究
|
||||
|
||||
### 4. Web 搜索补充
|
||||
根据类型自动补充：
|
||||
- RECOMMENDATIONS: `best {topic} recommendations`
|
||||
- NEWS: `{topic} news 2026`
|
||||
- PROMPTING: `{topic} prompts examples`
|
||||
- GENERAL: `{topic} 2026 discussion`
|
||||
|
||||
---
|
||||
|
||||
## 典型使用场景
|
||||
|
||||
| 场景 | 推荐用法 |
|
||||
|------|---------|
|
||||
| 每周行业动态 | `/last30days AI工具 --days=7 --quick` |
|
||||
| 竞品深度分析 | `/last30days competitor --deep --x-handle=竞品账号` |
|
||||
| 工具对比选型 | `/last30days toolA vs toolB` |
|
||||
| 人物热点追踪 | `/last30days person --x-handle=personHandle` |
|
||||
| 热点趋势发现 | `/last30days trending_topic` |
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. 深度研究需要 2-8 分钟，耐心等待
|
||||
2. TikTok/Instagram 需要 ScrapeCreators API key（前 100 次免费）
|
||||
3. 建议先用 `--quick` 测试话题方向
|
||||
4. Reddit 评论往往比帖子更有价值，关注 top comments
|
||||
5. Polymarket 赔率是最高置信度的数据
|
||||
|
||||
---
|
||||
|
||||
## 相关资源
|
||||
|
||||
- GitHub: https://github.com/mvanhorn/last30days-skill
|
||||
- 技能目录: `~/.openclaw/skills/last30days-official/`
|
||||
- 研究保存: `~/Documents/Last30Days/`
|
||||
|
||||
---
|
||||
|
||||
*此笔记由星辉根据 README.md 总结生成*
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
|
||||
type: source
|
||||
tags: [Terraform, RDS, IaC, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：通过 Terraform 部署 Amazon RDS，推广基础设施即代码（IaC）方法
|
||||
- 问题域：RDS 部署方式选择（控制台 vs IaC）、模块化基础设施管理
|
||||
- 方法/机制：使用 Terragrunt（Terraform 包装器）进行模块化部署，SRE 核心模块和 Gruntwork 模块
|
||||
- 结论/价值：IaC 提供速度、灵活性、一致性、灾难恢复、文档化和自动化优势
|
||||
|
||||
## Key Claims
|
||||
- IaC 相比控制台部署更适合任何规模的 RDS — 代码即文档
|
||||
- 推荐使用 Gruntwork RDS 服务而非裸机 RDS 模块（预建 KMS 加密和 CloudWatch 告警功能）
|
||||
- SRE 核心模块功能不如 Gruntwork 服务完善
|
||||
- 使用 Terragrunt 保持代码整洁，避免变量重复
|
||||
- 生产环境应使用标记版本而非 master 分支以保证稳定性
|
||||
|
||||
## Key Quotes
|
||||
> "We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time." — Greg, DBRE Team
|
||||
|
||||
## Key Concepts
|
||||
- [[IaC]]：基础设施即代码，通过声明式配置管理云资源
|
||||
- [[Terragrunt]]：Terraform 的包装工具，提供模块化、变量共享和环境隔离
|
||||
- [[RDS]]：Amazon 关系数据库服务
|
||||
- [[CloudWatch]]：AWS 云监控服务，用于仪表板和告警
|
||||
- [[KMS]]：AWS 密钥管理服务，用于数据加密
|
||||
|
||||
## Key Entities
|
||||
- [[Greg]]：DBRE 团队成员，演讲者
|
||||
- [[Gruntwork]]：提供预建基础设施模块的公司
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[Cloud Transformation Programme]]：云转型项目（CTP）
|
||||
|
||||
## Connections
|
||||
- [[Terragrunt]] ← uses ← [[Terraform]]
|
||||
- [[RDS]] ← deployed_by ← [[Terragrunt]]
|
||||
- [[RDS]] ← monitored_by ← [[CloudWatch]]
|
||||
- [[RDS]] ← encrypted_by ← [[KMS]]
|
||||
- [[Gruntwork]] ← provides ← [[RDS-Module]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
title: "Linux 运维必会的 150 个命令"
|
||||
type: source
|
||||
tags: [linux, 运维, 命令]
|
||||
date: 2025-09-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Linux 运维必会的 150 个命令.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Linux 系统管理常用命令的分类汇总
|
||||
- 问题域：Linux 运维日常工作所需掌握的命令工具
|
||||
- 方法/机制：按功能分类组织，共12类150个命令
|
||||
- 结论/价值：掌握这些命令是 Linux 运维的基础技能
|
||||
|
||||
## Key Claims
|
||||
- Linux 系统将所有资源（CPU、内存、磁盘、文件、设备、用户）抽象为文件进行管理
|
||||
- Linux 命令分为内置 Shell 命令和外部 Linux 命令两类
|
||||
- 命令按功能分为12个类别：帮助命令、文件操作、文件内容处理、压缩解压、信息显示、搜索文件、用户管理、网络操作、磁盘文件系统、权限管理、用户登录信息、系统管理
|
||||
|
||||
## Key Quotes
|
||||
> "Linux 命令是它正常运行的核心，与之前的 DOS 命令类似。"
|
||||
|
||||
## Key Concepts
|
||||
- [[Shell]]：Linux 命令解释器，负责执行用户输入的命令
|
||||
- [[管道 (Pipeline)]]：将前一个命令的输出作为下一个命令的输入
|
||||
- [[重定向]]：将命令输出重定向到文件或其他设备
|
||||
|
||||
## Key Entities
|
||||
- （本篇为命令工具汇总，不涉及具体实体）
|
||||
|
||||
## Connections
|
||||
- （本篇为基础工具文档，不涉及与其他页面的连接）
|
||||
|
||||
## Contradictions
|
||||
- （无）
|
||||
|
||||
## Commands Summary
|
||||
|
||||
### 1. 线上查询及帮助命令（2个）
|
||||
| 命令 | 功能 |
|
||||
|------|------|
|
||||
| man | 查看命令帮助手册 |
|
||||
| help | 查看 Linux 内置命令帮助 |
|
||||
|
||||
### 2. 文件和目录操作命令（18个）
|
||||
ls, cd, cp, find, mkdir, mv, pwd, rename, rm, rmdir, touch, tree, basename, dirname, chattr, lsattr, file, md5sum
|
||||
|
||||
### 3. 查看文件及内容处理命令（21个）
|
||||
cat, tac, more, less, head, tail, cut, split, paste, sort, uniq, wc, iconv, dos2unix, diff, vimdiff, rev, grep/egrep, join, tr, vi/vim
|
||||
|
||||
### 4. 文件压缩及解压缩命令（4个）
|
||||
tar, unzip, gzip, zip
|
||||
|
||||
### 5. 信息显示命令（11个）
|
||||
uname, hostname, dmesg, uptime, stat, du, df, top, free, date, cal
|
||||
|
||||
### 6. 搜索文件命令（4个）
|
||||
which, find, whereis, locate
|
||||
|
||||
### 7. 用户管理命令（10个）
|
||||
useradd, usermod, userdel, groupadd, passwd, chage, id, su, visudo, sudo
|
||||
|
||||
### 8. 基础网络操作命令（11个）
|
||||
telnet, ssh, scp, wget, ping, route, ifconfig, ifup, ifdown, netstat, ss
|
||||
|
||||
### 9. 深入网络操作命令（9个）
|
||||
nmap, lsof, mail, mutt, nslookup, dig, host, traceroute, tcpdump
|
||||
|
||||
### 10. 有关磁盘与文件系统的命令（16个）
|
||||
mount, umount, fsck, dd, dumpe2fs, dump, fdisk, parted, mkfs, partprobe, e2fsck, mkswap, swapon, swapoff, sync, resize2fs
|
||||
|
||||
### 11. 系统权限及用户授权相关命令（4个）
|
||||
chmod, chown, chgrp, umask
|
||||
|
||||
### 12. 查看系统用户登陆信息的命令（7个）
|
||||
whoami, who, w, last, lastlog, users, finger
|
||||
|
||||
### 13. 内置命令及其它（19个）
|
||||
echo, printf, rpm, yum, watch, alias, unalias, date, clear, history, eject, time, nc, xargs, exec, export, unset, type, bc
|
||||
|
||||
### 14. 系统管理与性能监视命令（9个）
|
||||
chkconfig, vmstat, mpstat, iostat, sar, ipcs, ipcrm, strace, ltrace
|
||||
|
||||
### 15. 关机/重启/注销和查看系统信息的命令（6个）
|
||||
shutdown, halt, poweroff, logout, exit, Ctrl+d
|
||||
|
||||
### 16. 进程管理相关命令（15个）
|
||||
bg, fg, jobs, kill, killall, pkill, crontab, ps, pstree, nice/renice, nohup, pgrep, runlevel, init, service
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: MCP-zai-Cursor-zhong-de-ji-cheng-yu-ying-yong-xiang-jie
|
||||
title: "MCP在Cursor中的集成与应用详解"
|
||||
type: source
|
||||
tags: [ai, ai-agent, cursor, mcp]
|
||||
source: raw/Agent/MCP在Cursor中的集成与应用详解.md
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/MCP在Cursor中的集成与应用详解.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Cursor IDE 中集成和使用 MCP（Modal Context Protocol）协议
|
||||
- 问题域：大模型与外围服务的集成方式
|
||||
- 方法/机制：基于 Client-Server 架构，MCP Server 提供资源获取、工具调用、Promise 提示词三种接口
|
||||
- 结论/价值：实现大模型与多样外部工具的无缝链接，提升 AI 应用的扩展能力和交互效率
|
||||
|
||||
## Key Claims
|
||||
- MCP 是基于 Client-Server 架构的协议，实现大模型与外围服务的高效集成
|
||||
- Cursor 支持两种 MCP 接入方式：SSE 服务方式和本地执行命令方式
|
||||
- Agent 模式能自动执行内嵌命令并处理工具调用，提升操作效率
|
||||
- "enable yolo mode" 自动执行命令风险较高，建议默认关闭
|
||||
|
||||
## Key Quotes
|
||||
> "MCP 是 Modal Context Protocol 的缩写，是一种基于 Client-Server 架构的协议，旨在实现大模型与外围服务的高效集成。"
|
||||
|
||||
> "Agent 模式与 Normal 模式的最大区别在于：Agent 模式实现命令的链路打通，减少手动操作的步骤。"
|
||||
|
||||
## Key Concepts
|
||||
- [[MCP]]：Modal Context Protocol，支持 AI 大模型与外围服务基于 Client-Server 架构进行高效的数据和工具接口交互
|
||||
- [[SSE]]：Server-Sent Events，服务器向客户端推送实时事件的技术，也是一种 MCP 接入方式
|
||||
- [[Sequential Thinking]]：MCP 工具之一，支持逻辑推理与分步执行任务，优化 AI 模型的思考与响应过程
|
||||
- [[Agent模式]]：Cursor 中的交互方式，自动执行内嵌命令并处理工具调用
|
||||
- [[Composer]]：Cursor 中的对话构建模块，支持 Agent 模式与 Normal 模式
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：AI 增强代码编辑器，支持 MCP 协议集成
|
||||
- [[MCP Server]]：MCP 协议体系中的服务提供方，负责对外提供资源和工具接口
|
||||
- [[鱼凤老师]]：本视频教程的作者
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← supports ← [[MCP]]
|
||||
- [[MCP Server]] ← provides ← [[工具调用]]
|
||||
- [[Sequential Thinking]] ← extends ← [[MCP]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无冲突记录）
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "Mac必装软件清单"
|
||||
type: source
|
||||
tags: [Mac, 软件推荐, 效率工具]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac必装软件清单-2026-04-17.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Mac 效率软件推荐清单
|
||||
- 问题域：Mac 用户必备工具选择
|
||||
- 方法/机制：通过用户真实使用体验推荐实用的效率工具
|
||||
- 结论/价值：用最少的软件达到最高的效率
|
||||
|
||||
## Key Claims
|
||||
- **Claude**：AI 时代人手必备，桌面版 Cowork 功能专为文字工作者打造
|
||||
- **Obsidian**：搭配 Claudian 插件，打造 AI 驱动的终极个人知识库
|
||||
- **Chrome**（非中文名保留）：比 Safari 更好用，Gmail 用户的不二之选
|
||||
- **Rectangle**（非中文名保留）：免费分屏神器，大屏办公必备，Windows 转 Mac 必装
|
||||
- **iShot**（非中文名保留）：简洁免费的截图工具，支持圆角截图
|
||||
- **Lemon**（非中文名保留）：轻量系统清理工具，多任务卡顿时清理缓存
|
||||
- **Raycast**（非中文名保留）：替代 Spotlight 的万能启动器，计算器和剪贴板超好用
|
||||
- **Homebrew**（非中文名保留）：Mac 包管理器，用 Claude Code 搭 Agent 的前置依赖
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **[[Claude-Skills]]**：写给 Claude 的"说明书"，将反复执行的任务拆解为 AI 可稳定复用流程的技术范式
|
||||
- **[[Obsidian Skills]]**：写给 AI Agent 的"说明书"，扩展 Obsidian 能力的技能集
|
||||
- **[[工作流自动化]]**：预定义自动化流程，与 AI Agent 互补
|
||||
- **[[深度工作]]**：《深度工作》书籍中提到的在无干扰状态下专注职业活动的方法
|
||||
- **[[双链（Backlinks）]]**：Obsidian 核心功能，将笔记双向关联形成知识网络
|
||||
|
||||
## Key Entities
|
||||
|
||||
- **[[Obsidian]**：基于 Markdown 的本地优先笔记软件
|
||||
- **[[Claude]**：Anthropic 公司开发的 AI 聊天助手
|
||||
- **[[Homebrew]**：Mac 包管理器
|
||||
- **[[Chrome]**：Google 浏览器
|
||||
- **[[Raycast]**：macOS 启动器
|
||||
- **[[OpenClaw]**：Claude Code 管理工具，Homebrew 安装的前置依赖
|
||||
|
||||
## Connections
|
||||
- [[Homebrew]] ← manages ← [[Claude]]
|
||||
- [[Homebrew]] ← manages ← [[Obsidian]]
|
||||
- [[Homebrew]] ← manages ← [[Chrome]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Marketing Cross-Border E-Commerce Specialist
|
||||
type: source
|
||||
tags: [agent, marketing, cross-border-ecommerce, the-agency]
|
||||
date: 2026-04-21
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/marketing/marketing-cross-border-ecommerce.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：全漏斗跨境电商运营策略专家，覆盖 Amazon、Shopee、Lazada、AliExpress、Temu、TikTok Shop 等全球主流平台
|
||||
- 问题域：跨境电商的多平台运营、本地化、合规、物流、支付、广告等全链路挑战
|
||||
- 方法/机制：平台选品→合规准备→listing优化→广告投放→数据迭代的五步工作流
|
||||
- 结论/价值：帮助将中国产品推向全球市场，通过本地化运营和合规管理实现跨境盈利
|
||||
|
||||
## Key Claims
|
||||
- 跨境电商不是"把国内爆款搬到海外"，本地化决定能否获得 traction，合规决定能否生存，供应链决定能否盈利
|
||||
- 机器翻译是最大的转化率杀手，本地语言审查是强制要求
|
||||
- 每个平台有独立的流量分配逻辑，复制国内电商玩法到海外必败
|
||||
- Temu 全托管模式利润极薄，核心竞争优势是供应链成本控制，适合工厂直售商
|
||||
|
||||
## Key Quotes
|
||||
> "You want to sell this product in Europe? Don't ship anything yet - CE certification, WEEE registration, and German Packaging Act registration are all mandatory" — 合规优先原则
|
||||
> "This product has 80K monthly searches in the US, under 200 average reviews on page one, and a $25-$35 price range putting gross margins at 35%" — 数据驱动的选品决策
|
||||
|
||||
## Key Concepts
|
||||
- [[FBA (Fulfillment by Amazon)]]：亚马逊自营物流服务，提供履约、存储、退货处理
|
||||
- [[VAT (Value Added Tax)]]：欧盟增值税，UK/DE 等市场必须注册和申报
|
||||
- [[ACOS (Advertising Cost of Sales)]]：广告成本销售比，衡量广告效率，跨境电商核心 KPI
|
||||
- [[Listing Optimization]]：多平台商品 listing 优化，本地语言 + 关键词策略
|
||||
- [[Cross-Border Logistics]]：跨境物流，涵盖头程、仓储、尾程配送全链路
|
||||
- [[Compliance & Certification]]：产品合规认证 CE/FCC/FDA/PSE/WEEE 等
|
||||
- [[Multi-Platform Operations]]：多平台运营策略，各平台差异化运营方法
|
||||
|
||||
## Key Entities
|
||||
- [[Amazon]]：全球最大电商平台，欧美日核心市场，账户健康管理是生命线
|
||||
- [[Shopee]]：东南亚/拉美电商平台，平台大促是主要流量来源
|
||||
- [[Lazada]]：东南亚电商平台，LazMall 和促销策略
|
||||
- [[AliExpress]]：全球速卖通，海外买家保护政策
|
||||
- [[Temu]]：北美/欧洲快速增长的超低价电商平台
|
||||
- [[TikTok Shop]]：短视频+直播电商，内容驱动销售
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，本页面的来源项目
|
||||
|
||||
## Connections
|
||||
- [[Marketing Douyin Strategist]] ← extends ← [[Marketing Cross-Border E-Commerce Specialist]]（国内抖音到跨境 TikTok Shop 的延伸）
|
||||
- [[Legal Compliance Checker]] ← depends_on ← [[Marketing Cross-Border E-Commerce Specialist]]（合规检查是跨境运营的前置条件）
|
||||
- [[Supply Chain Strategist]] ← supports ← [[Marketing Cross-Border E-Commerce Specialist]]（供应链策略是跨境物流的支撑）
|
||||
|
||||
## Contradictions
|
||||
- 与国内抖音运营逻辑冲突：TikTok Shop 需要内容驱动，而非货架电商的直接移植
|
||||
|
||||
## Technical Deliverables
|
||||
### Cross-Border Product Evaluation Scorecard
|
||||
- 市场维度：月搜索量 > 10,000 / 竞品均值 < 500 评论 / 价格区间 $15-$50 / 全年需求稳定
|
||||
- 利润维度：净利率目标 > 20%，完整成本拆分（采购+头程+仓储+平台佣金+广告+尾程+退货+汇率）
|
||||
- 合规维度：产品认证 + 专利风险 + 平台限制 + 进口关税
|
||||
|
||||
### Multi-Marketplace Operations Comparison
|
||||
|
||||
| 维度 | Amazon NA | Amazon EU | Shopee SEA | TikTok Shop | Temu |
|
||||
|------|-----------|-----------|------------|-------------|------|
|
||||
| 核心逻辑 | 搜索+广告驱动 | 合规+本地化 | 低价+大促 | 内容+社交 | 极致低价 |
|
||||
| 流量获取 | PPC+SEO+Deals | PPC+VAT合规 | 平台大促+Ads | 短视频+直播 | 平台分配 |
|
||||
| 物流 | FBA 为主 | FBA/Pan-EU | SLS/自发货 | 平台物流 | 平台履约 |
|
||||
| 利润区间 | 20-35% | 15-30% | 10-25% | 15-30% | 5-15% |
|
||||
| 适合卖家 | 品牌/精品卖家 | 合规能力强者 | 跑量/精品 | 内容强团队 | 工厂直售 |
|
||||
|
||||
### Amazon PPC 三阶段策略
|
||||
1. **Launch (0-30天)**：40% SP自动 + 30% SP手动broad + 20% SP手动exact + 10% SB品牌
|
||||
2. **Growth (30-90天)**：迁移高效词到手动，添加 SD 竞品定向，ACOS 控制在 25% 以下
|
||||
3. **Mature (90天+)**：exact match 为主，品牌防御，TACOS 控制在 10% 以下
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: "多智能体系统可靠性"
|
||||
type: source
|
||||
tags: [multi-agent, reliability, architecture]
|
||||
sources: [raw/AI/Multi-Agent System Reliability.md]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Multi-Agent System Reliability.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多智能体系统的可靠性架构模式
|
||||
- 问题域：LLM 不可靠性导致的系统级错误传播
|
||||
- 方法/机制：层级结构、共识投票、对抗式辩论、淘汰制四种架构模式
|
||||
- 结论/价值：将 LLM 视为不可靠组件，通过架构设计强制正确性而非依赖模型"小心谨慎"
|
||||
|
||||
## Key Claims
|
||||
- LLM 本质不可靠（幻觉、逻辑谬误、上下文漂移），多智能体拓扑会将错误传播到无法使用的程度
|
||||
- 层级结构通过依赖图强制 Worker 协作，验证器捕获作弊
|
||||
- 共识投票中 3 个模型同时幻觉相同谎言的概率仅为 0.8%（20%³）
|
||||
- 对抗式辩论模拟人类"恐惧"机制，通过外部批评者纠正模型"好好先生"倾向
|
||||
- 淘汰制将 LLM 视为"牲畜"而非"宠物"，失败即替换而非修复
|
||||
|
||||
## Key Quotes
|
||||
> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged." — Alex Ewerlöf
|
||||
|
||||
> "Don't anthropomorphize LLMs! Find a way to piggy back on their human-corpus training while being aware of their non-biological differences." — Alex Ewerlöf
|
||||
|
||||
## Key Concepts
|
||||
- [[多智能体系统可靠性]]：通过架构模式提升 LLM 多智能体系统可靠性的方法论
|
||||
- [[层级结构 (Hierarchy)]]：Planner 分解任务 → Worker 执行 → Validator 验证的三层架构
|
||||
- [[共识投票 (Consensus)]]：多数票机制抵消单个模型的随机噪声
|
||||
- [[对抗式辩论 (Adversarial Debate)]]：生成器+批评者+评委的三角制衡结构
|
||||
- [[淘汰制 (Knock-out)]]：适者生存的遗传算法式选择机制
|
||||
- [[可靠性工程]]：将 LLM 视为分布式系统中不可靠组件的工程思维
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Ewerlöf]]：作者，27年经验的资深工程师，KTH 系统工程硕士，专注可靠性工程和弹性架构
|
||||
- [[KTH]]：瑞典皇家理工学院（KTH Royal Institute of Technology）
|
||||
|
||||
## Connections
|
||||
- [[多智能体系统可靠性]] ← extends ← [[Multi-Agent-Team]]
|
||||
- [[层级结构 (Hierarchy)]] ← depends_on ← [[依赖图]]
|
||||
- [[共识投票 (Consensus)]] ← uses ← [[复合 SLO]]
|
||||
- [[淘汰制 (Knock-out)]] ← implements ← [[遗传算法]]
|
||||
- [[对抗式辩论 (Adversarial Debate)]] ← avoids ← [[群体思维]]
|
||||
- [[可靠性工程]] → applies_to → [[SRE]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Multi-Agent-Team]] 视角不同：Multi-Agent-Team 强调 Agent 个性和协作流程，本文强调将 LLM 视为不可靠组件的工程视角
|
||||
- 与 [[Agent Chain]] 区别：Agent Chain 是简单的串联模式，本文强调验证和反馈机制
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "Nano Banana 提示词框架"
|
||||
type: source
|
||||
tags: [ai, google, nano-banana, prompt]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Nano Banana 提示词框架.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google Nano Banana 图像生成模型的提示词框架
|
||||
- 问题域：AI 图像生成提示词设计
|
||||
- 方法/机制：结构化 JSON 提示词模板，分物件描述和人物描述两类框架
|
||||
- 结论/价值：提供标准化的提示词结构，提高图像生成质量和一致性
|
||||
|
||||
## Key Claims
|
||||
- 物件描述框架包含 9 个核心维度：shot、subject、environment、lighting、camera、color_grade、style、quality、negatives
|
||||
- 人物描述框架包含年龄、外貌、姿态等人物特有属性
|
||||
-camera 配置包含焦距、光圈、角度三个参数
|
||||
|
||||
## Key Quotes
|
||||
> "shot": "",
|
||||
> "subject": { "item": "", "materials": "", "details": "", "condition": "" },
|
||||
> "lighting": "",
|
||||
|
||||
## Key Concepts
|
||||
- [[物件描述框架]]：包含 item、materials、details、condition 四个子属性的结构化描述模板
|
||||
- [[人物描述框架]]：包含 age、appearance、pose 三个特定属性的结构化描述模板
|
||||
- [[Camera Config]]：focal_length、aperture、angle 三个相机参数配置
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：发布 Nano Banana 图像生成模型的公司
|
||||
- [[Nano Banana]]：Google 的专业级图像生成模型
|
||||
|
||||
## Connections
|
||||
- [[Nano-Banana-Pro-Prompt-Guide]] ← extends ← [[Nano-Banana-提示词框架]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "Obsidian CLI 命令全景速查表"
|
||||
type: source
|
||||
tags:
|
||||
- Obsidian
|
||||
- CLI
|
||||
- 自动化
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/Obsidian 官方 CLI 命令全景速查表.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Obsidian 官方 CLI 命令速查与自动化工作流
|
||||
- 问题域：终端命令控制 Obsidian 功能、AI Agent 集成、自动化脚本构建
|
||||
- 方法/机制：通过 `obsidian <命令> 参数=参数值` 格式调用内部 API
|
||||
- 结论/价值：实现笔记管理全流程自动化，是 AI Agent 操作 Obsidian 的核心技术
|
||||
|
||||
## Key Claims
|
||||
- Obsidian CLI 要求 v1.12+ 版本，并在设置中启用 Command Line Interface
|
||||
- 基础格式：`obsidian <命令> 参数=参数值 标记参数`
|
||||
- 含有空格的值必须加双引号，标记参数（如 `open`、`inline`、`total`）无需赋值
|
||||
- CLI 依赖 Obsidian 应用运行状态，但支持 Headless 模式下的同步操作
|
||||
|
||||
## Key Quotes
|
||||
> "Obsidian CLI is a command line interface that lets you control Obsidian from your terminal for scripting, automation, and integration with external tools." — Obsidian 官方文档
|
||||
|
||||
## Key Concepts
|
||||
- [[Obsidian CLI]]：官方命令行工具，支持笔记、数据库、属性、插件的终端操作
|
||||
- [[Obsidian 自动化]]：通过 CLI 实现 AI Agent 集成的各种工作流
|
||||
- Headless 模式：CLI 在无 GUI 环境下运行 Obsidian Sync 的能力
|
||||
- 标记参数：无需赋值的布尔开关（如 `open`、`total`）
|
||||
|
||||
## Key Entities
|
||||
- [[Obsidian]]：基于 Markdown 的本地优先笔记软件
|
||||
- [[n8n]]：工作流自动化工具，常与 CLI 结合实现定时任务
|
||||
|
||||
## Connections
|
||||
- Obsidian CLI 需要 [[Obsidian]] 应用运行 → depends_on
|
||||
- CLI 是 [[Claude Skills]] 的终端扩展能力 → extends
|
||||
- 与 [[n8n]] 结合实现定时任务（Cron Jobs）→ combined_with
|
||||
|
||||
## Contradictions
|
||||
- 与纯终端工具（如 Vim、Emacs）对比：Obsidian CLI 仍依赖 Electron GUI 应用运行
|
||||
- 与 [[Open Notebook]] 等纯服务端方案对比：需本地运行 Obsidian
|
||||
|
||||
## Workflows
|
||||
### 全局极速闪记
|
||||
- 终端绑定 `daily:append` 实现灵感速记，无需唤醒 Obsidian 界面
|
||||
|
||||
### 自动化分拣工作流
|
||||
- 利用 n8n + CLI 实现属性规范化、文件移动、双链更新
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "Obsidian 必装 Skills"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/Obsidian 必装 Skills.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Obsidian 必装的 AI Skills 推荐与配置指南
|
||||
- 问题域：AI Agent 与 Obsidian 笔记软件深度集成
|
||||
- 方法/机制：通过 Skills 扩展 AI Agent 能力，实现网页抓取、Obsidian 文件操作、数据库视图、Mermaid 图表、学习系统等功能
|
||||
- 结论/价值：推荐 9 个核心 Skills（defuddle、obsidian-cli、obsidian-bases、obsidian-markdown、obsidian-canvas-creator、mermaid-visualizer、excalidraw-diagram、tutor-skills、scholar-skill）和 2 个核心插件（claudian、obsidian-agent-client）
|
||||
|
||||
## Key Claims
|
||||
- defuddle 是网页内容清洗工具，通过剔除广告和导航栏减少 AI Token 消耗
|
||||
- obsidian-cli 让 AI Agent 能直接调用 Obsidian 官方命令行工具，实现笔记增删改查
|
||||
- obsidian-bases 让 AI 能创建 .base 格式配置文件，生成类似 Notion 数据库的动态视图
|
||||
- obsidian-canvas-creator 解决了 json-canvas 的节点重叠和空间分布不均问题
|
||||
- tutor-skills 构成"输入-内化-检测"完整闭环，将文档转化为结构化知识库并通过互动测验暴露知识盲区
|
||||
- scholar-skill 通过 L1-L3 分级阅读策略长时间静默解析论文，生成双链卡片和知识冲突报告
|
||||
- claudian 是适配 Claude Code 的第三方插件，obsidian-agent-client 支持多主流智能体
|
||||
|
||||
## Key Quotes
|
||||
> "defuddle 最近一次更新中已经支持 YouTube 视频链接，它获取 YouTube 视频字幕的方式是调用 YouTube 官方 API" — 功能增强说明
|
||||
|
||||
> "scholar-skill 底层深度依赖 OpenClaw 的 durable-task-runner 来处理多次 LLM 推演循环、API 限流等待以及崩溃恢复" — 超长周期任务机制
|
||||
|
||||
> "当 AI 发现新论文推翻了你旧笔记的结论时，不会直接覆写旧笔记，而是生成一份确认单放进 0-Inbox 文件夹，等待人类审核确认" — 人类确认防呆机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Obsidian-Skills]]：写给 AI Agent 的"说明书"，扩展 Obsidian 能力的技能集
|
||||
- [[Claude-Skills]]：写给 Claude 的"说明书"和 SOP，将反复执行的任务拆解为 AI 可稳定复用流程的技术范式
|
||||
- [[Obsidian-CLI]]：Obsidian 官方命令行工具，支持笔记增删改查
|
||||
- [[obsidian-bases]]：生成 .base 格式数据库配置文件的技能，实现动态视图
|
||||
- [[obsidian-canvas-creator]]：自动计算节点坐标、处理连接线路径的 Canvas 创建技能
|
||||
- [[tutor-skills]]：将文档转化为结构化知识库并通过互动测验检测学习效果的技能
|
||||
- [[scholar-skill]]：基于 L1-L3 分级阅读策略的学术研究技能
|
||||
- [[BRAT-插件]]：Obsidian 第三方插件自动更新工具，推荐用于安装 Beta 版插件
|
||||
- [[claudian]]：适配 Claude Code 的 Obsidian 第三方插件
|
||||
- [[obsidian-agent-client]]：支持多主流智能体的 Obsidian 插件
|
||||
|
||||
## Key Entities
|
||||
- [[kepano]]：Obsidian CEO，defuddle、obsidian-cli、obsidian-bases 等 Skills 作者
|
||||
- [[Axton]]：回到Axton 博主，obsidian-canvas-creator、mermaid-visualizer、excalidraw-diagram 作者
|
||||
- [[OpenClaw]]：AI Agent 管理工具框架，scholar-skill 运行基础
|
||||
- [[Choi-Wontak]]：tutor-skills 作者
|
||||
- [[EESJGong]]：scholar-skill 作者
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 框架基础 ← [[scholar-skill]]
|
||||
- [[Obsidian]] ← 平台 ← [[claudian]]
|
||||
- [[Defuddle]] ← 依赖 ← Node.js
|
||||
- [[Excalidraw-Diagram]] ← 依赖 ← Excalidraw 插件
|
||||
|
||||
## Contradictions
|
||||
- 与 [[obsidian-skill]]（已过时）冲突：
|
||||
- 冲突点：obsidian-skill 直接操作文件系统消耗大量 Token
|
||||
- 当前观点：推荐使用 obsidian-cli 替代
|
||||
- 对方观点：使用 obsidian-skill 进行文件 I/O
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: openai-chatgpt-个性化定义
|
||||
title: "OpenAI ChatGPT 个性化定义"
|
||||
type: source
|
||||
tags: [ai, chatgpt, customization, openai]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/OpenAI ChatGPT 个性化定义.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：ChatGPT 个性化配置与自定义指令设置
|
||||
- 问题域：AI 个性化助手配置
|
||||
- 方法/机制：通过自定义指令和行为偏好设置，实现符合用户需求的 AI 交互体验
|
||||
- 结论/价值：用户背景（47岁自由职业者，前云服务交付高级经理，转型TikTok跨境电商）决定了对 AI 的高标准要求——专业、准确、有深度
|
||||
|
||||
## Key Claims
|
||||
- 用户要求 AI 尽可能提出出乎意料的解决方案，而非按常规路径思考
|
||||
- 用户视自己为所有领域的专家，希望 AI 以平等专家身份对话，而非启蒙式交互
|
||||
- 用户重视论证质量而非来源权威性，来源本身无关紧要
|
||||
- 用户要求 AI 在使用高度推测性内容时明确告知，而非当作确定事实呈现
|
||||
- 用户明确拒绝道德说教，仅在关键且非显而易见时讨论安全问题
|
||||
|
||||
## Key Quotes
|
||||
> "错误会削弱我的信任，所以务必做到准确和详尽" — 用户对准确性的高标准要求
|
||||
> "重视合理的论据，而非权威，来源无关紧要" — 用户对知识来源的务实态度
|
||||
|
||||
## Key Concepts
|
||||
- [[自定义指令]]：用户为 ChatGPT 设置的行为指导原则
|
||||
- [[个性化配置]]：根据用户背景和需求定制的 AI 交互方式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：ChatGPT 的开发商
|
||||
- [[ChatGPT]]：OpenAI 开发的大型语言模型
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] ← provides ← [[ChatGPT]]
|
||||
- [[ChatGPT]] ← supports ← [[自定义指令]]
|
||||
- [[个性化配置]] ← applies_to ← [[ChatGPT]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109"
|
||||
type: source
|
||||
tags: [cloud-learning, business-analysis, techniques]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：业务分析技术学习会议，介绍 BOSSARD、相关方轮盘和需求收集方法
|
||||
- 问题域：企业数字化转型中的需求分析与变更管理
|
||||
- 方法/机制：BOSCARD（背景、目标、范围、约束、假设、风险、角色、可交付成果）、相关方轮盘、用户故事 + 元数据的需求收集方法
|
||||
- 结论/价值：业务分析帮助明确业务架构变更需求，确保 IT 系统和流程变更的一致性
|
||||
|
||||
## Key Claims
|
||||
- 业务分析将业务需求与变更解决方案对齐，考虑 IT 和流程变更、培训和角色转换
|
||||
- T 型技能在敏捷 Squad 中很有价值，结合核心专业知识与相关技能的广泛理解
|
||||
- BOSCARD 在项目早期明确定义背景、目标、范围、约束、假设、风险、角色和可交付成果
|
||||
- 相关方轮盘从客户开始顺时针识别所有项目相关方（客户、合作伙伴、监管机构、员工、管理层、所有者、竞争对手）
|
||||
- 用户故事结合元数据可增加需求捕获的严谨性，SAFe 框架包含特性、能力与非功能性需求
|
||||
|
||||
## Key Quotes
|
||||
> "If you can get scope tied down early on and agreed, that's priceless." — 提前锁定并同意范围的价值
|
||||
> "Every requirement should be independent, meaning not duplicating something else, that's the I in invest, negotiable, so the business should state what they need, but be open to how it's implemented." — INVEST 原则中的独立性解释
|
||||
|
||||
## Key Concepts
|
||||
- [[业务分析 (Business Analysis)]]：将业务需求与变更解决方案对齐的实践
|
||||
- [[BOSCARD]]：定义复杂新工作的技术，包含背景、目标、范围、约束、假设、风险、角色、可交付成果
|
||||
- [[相关方轮盘 (Stakeholder Wheel)]]：识别项目所有相关方的方法论
|
||||
- [[RACI 图]]：责任分配矩阵，明确 Responsible、Accountable、Consulted、Informed 角色
|
||||
- [[用户故事 (User Stories)]]：以"谁、什么、为什么"格式捕获需求
|
||||
- [[SAFe (Scaled Agile Framework)]]：大规模敏捷框架，包含特性、能力、非功能性需求
|
||||
- [[T 型技能]]：在敏捷 Squad 中结合核心专业与广泛相关技能
|
||||
- [[BCS]]：业务分析学习资源来源之一
|
||||
- [[IIBA]]：国际商业分析协会，业务分析认证机构
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]] — 主办 Public Cloud Learning Sessions 的企业内容管理公司
|
||||
|
||||
## Connections
|
||||
- [[业务分析 (Business Analysis)]] ← 包含 ← [[BOSCARD]]
|
||||
- [[业务分析 (Business Analysis)]] ← 包含 ← [[相关方轮盘 (Stakeholder Wheel)]]
|
||||
- [[需求收集]] ← 依赖 ← [[用户故事 (User Stories)]]
|
||||
- [[需求收集]] ← 扩展 ← [[SAFe (Scaled Agile Framework)]]
|
||||
- [[T 型技能]] → 应用 → [[敏捷实践]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - Budget Control - 20240319"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Budget-Control
|
||||
- FinOps
|
||||
- Cloud-Monitoring
|
||||
date: 2024-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AWS账户预算控制自动化，提供账户所有者详细的支出警报和成本分析报告，实现成本控制
|
||||
- 问题域：AWS账户成本失控、无法识别成本驱动因素、缺乏 enforce 机制
|
||||
- 方法/机制：AWS Budget Alerts + Lambda 处理 + Step Functions + SNS 触发 + SCP 限制
|
||||
- 结论/价值：
|
||||
|
||||
- 警报类型：forecast、actual、severe、enforcement 四级
|
||||
- 详细报告：top services、top users、资源级别的成本明细
|
||||
- 执行机制：8小时评估间隔，100%阈值触发SCP阻止新资源创建
|
||||
|
||||
## Key Claims
|
||||
- 预算控制自动化解决 AWS 账户蔓延和成本削减不可持续的问题
|
||||
- 源身份追踪确保跨角色切换时 CloudTrail 仍能追踪原始登录身份
|
||||
- 评分系统考虑账户规模和月末时间，避免惩罚月末轻微超支的账户
|
||||
|
||||
## Key Quotes
|
||||
> "The budget control automation aims to address uncontrolled AWS account sprawl and unsustainable cost reduction efforts."
|
||||
|
||||
> "This is the first time that we were able to get to this level of granularity."
|
||||
|
||||
## Key Concepts
|
||||
- [[Budget Control]]：AWS账户预算控制自动化系统
|
||||
- [[AWS Budget Alerts]]：AWS预算警报服务，四级警报类型
|
||||
- [[SCP]]：Service Control Policy，组织策略用于限制AWS服务使用
|
||||
- [[Source Identity]]：源身份追踪，记录跨角色切换前的原始登录身份
|
||||
|
||||
## Key Entities
|
||||
- [[SRE Core Team]]：预算控制自动化开发团队（Daniela、Evan、Alan）
|
||||
- [[FinOps]]：云财务运营团队，负责预算审批和成本管理
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← uses ← [[Budget Alerts]]
|
||||
- [[SRE Core Team]] ← develops ← [[Budget Control]]
|
||||
- [[FinOps]] ← approves ← [[Budget Enforcement Actions]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突记录
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText)- Serverless Computing - 20240903"
|
||||
type: source
|
||||
tags:
|
||||
- Serverless
|
||||
- AWS
|
||||
- Lambda
|
||||
- OpenText
|
||||
- Cloud Learning
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AWS 无服务器计算（Serverless Computing）学习会议
|
||||
- 问题域：云原生架构、事件驱动计算、无服务器函数
|
||||
- 方法/机制：Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
|
||||
- 结论/价值：Serverless 模式帮助企业快速上市、聚焦业务、降低 TCO、按需付费、自动扩展
|
||||
|
||||
## Key Claims
|
||||
- Lambda 函数由事件触发（状态变化），支持同步、异步、事件源映射三种调用方式
|
||||
- AWS 与客户共担运维责任，AWS 负责基础设施，客户负责代码
|
||||
- Lambda 版本和别名用于管理代码变更，发布新版本后可通过别名指向
|
||||
- Lambda Layers 支持跨函数共享公共代码
|
||||
|
||||
## Key Quotes
|
||||
> "Lambda functions are triggered by events, which are changes in state."
|
||||
> Whenever you see that you have written code and you want that this code is final, you can publish as a new version.
|
||||
|
||||
## Key Concepts
|
||||
- [[Lambda]]：AWS 无服务器计算服务，开发者只需编写业务逻辑，AWS 处理基础设施
|
||||
- [[Step Functions]]：无服务器工作流服务，基于状态机编排多个 AWS 服务
|
||||
- [[API Gateway]]：托管服务，用于创建、发布和保护 API
|
||||
- [[Serverless Application Model]]：SAM，本地开发和部署无服务器应用的工具，基于 CloudFormation
|
||||
- [[Event-driven Computing]]：事件驱动计算，Lambda 函数的触发机制
|
||||
- [[Execution Role]]：Lambda 执行角色，定义函数可以执行的操作
|
||||
- [[Resource-based Policy]]：基于资源的策略，定义谁可以触发函数
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[OpenText]]：企业软件公司
|
||||
|
||||
## Connections
|
||||
- [[Lambda]] ← powers ← [[Step Functions]]
|
||||
- [[Lambda]] ← exposed_by ← [[API Gateway]]
|
||||
- [[Lambda]] ← deployed_with ← [[Serverless Application Model]]
|
||||
- [[AWS Lambda]] ← manages_infrastructure ← [[Event-driven Computing]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 EC2 对比：EC2 提供灵活性和控制，Lambda 允许开发者聚焦业务逻辑
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: "Public vs Private vs Hybrid: Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [cloud-computing, public-cloud, private-cloud, hybrid-cloud]
|
||||
date: 2025-06-18
|
||||
source_file: raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]]
|
||||
|
||||
## Summary
|
||||
本文解释了公有云、私有云和混合云三种云计算部署模式的核心区别。公有云由第三方提供商共享交付，具有高弹性和低成本优势；私有云专属于单一组织，提供更高的安全性和控制力；混合云结合两者优势，支持根据业务需求灵活分配工作负载。文章还阐述了云计算的共享责任模型以及选择云部署模式的关键考量因素。
|
||||
|
||||
## Key Claims
|
||||
- 公有云采用共享基础设施模式，通过互联网交付给多个用户，具有高弹性、低成本和快速部署的特点
|
||||
- 私有云专属于单一组织，可通过内部部署或第三方托管，提供更高安全性和控制力，但成本较高
|
||||
- 混合云结合公有云和私有云，允许根据安全、性能、成本和效率需求在工作负载间灵活分配
|
||||
- 无论选择哪种云模式，客户仍需对访问权限、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Quotes
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云定义
|
||||
> "It is important to know that no matter which cloud environment you work in, your problems don't go away... your organization maintains responsibility for who has access to what, cloud security and encryption, and disaster recovery planning." — 共享责任模型
|
||||
|
||||
## Key Concepts
|
||||
- [[公有云 (Public Cloud)]]：通过互联网共享交付的云计算模式
|
||||
- [[私有云 (Private Cloud)]]：专属于单一组织的云计算部署模式
|
||||
- [[混合云 (Hybrid Cloud)]]：结合公有云和私有云的混合部署环境
|
||||
- [[云计算 (Cloud Computing)]]：通过互联网远程访问计算资源的服务模式
|
||||
- [[共享责任模型 (Shared Responsibility Model)]]：云服务商与客户共同承担安全和管理责任的框架
|
||||
- [[TCO (Total Cost of Ownership)]]：总体拥有成本，用于评估云方案长期成本效益
|
||||
|
||||
## Key Entities
|
||||
- [[BMC]]：云计算方案提供商，文章来源于 BMC 博客
|
||||
|
||||
## Connections
|
||||
- [[IaaS]] ← extends ← [[云计算 (Cloud Computing)]]：IaaS 是云计算的三种服务模式之一
|
||||
- [[PaaS]] ← extends ← [[云计算 (Cloud Computing)]]：PaaS 是云计算的三种服务模式之一
|
||||
- [[SaaS]] ← extends ← [[云计算 (Cloud Computing)]]：SaaS 是云计算的三种服务模式之一
|
||||
- [[混合云 (Hybrid Cloud)]] ← combines ← [[公有云 (Public Cloud)]]：混合云包含公有云组件
|
||||
- [[混合云 (Hybrid Cloud)]] ← combines ← [[私有云 (Private Cloud)]]：混合云包含私有云组件
|
||||
- [[云安全 (Cloud Security)]] ← related_to ← 三种云模式：安全性是选择云模式的关键考量
|
||||
|
||||
## Contradictions
|
||||
- （暂无检测到与现有页面的冲突）
|
||||
|
||||
## 公有云 vs 私有云 vs 混合云对比表
|
||||
|
||||
| 特性 | 公有云 | 私有云 | 混合云 |
|
||||
|------|--------|--------|--------|
|
||||
| 成本 | 低（无前期投资） | 高（专用资源） | 中等（按需分配） |
|
||||
| 安全性 | 低至中 | 高 | 中至高 |
|
||||
| 可扩展性 | 高 | 中至高 | 高 |
|
||||
| 控制力 | 低 | 高 | 中 |
|
||||
| 合规性 | 中 | 高 | 高 |
|
||||
| 典型用例 | 开发测试、弹性需求 | 敏感数据、高合规要求 | 多元化业务需求 |
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "RAG从入门到精通系列1：基础RAG"
|
||||
type: source
|
||||
tags: [RAG, LLM, 教程]
|
||||
date: 2025-12-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/RAG从入门到精通系列1：基础RAG.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：基础 RAG（检索增强生成）技术介绍
|
||||
- 问题域：LLM 如何使用外部数据（私有数据或最新数据）
|
||||
- 方法/机制：Indexing（索引）→ Retrieval（检索）→ Generation（生成）
|
||||
- 结论/价值：RAG 是连接 LLM 与外部数据源的通用方法，使 LLM 能基于外部知识生成回答
|
||||
|
||||
## Key Claims
|
||||
- RAG 是一种将 LLM 与外部数据源连接的通用方法，允许 LLM 使用外部数据生成输出
|
||||
- 基础 RAG 流程包含三个核心阶段：索引构建、文档检索、答案生成
|
||||
- Embedding（向量化）将文本转为固定长度的数值向量，捕获文本语义
|
||||
- 文档需要切分成满足 Embedding Model Context Window 的 Split（文档块）
|
||||
- Vector Store（向量数据库）存储 Embedding Vector 并实现相似度比较
|
||||
- LangChain 和 LlamaIndex 框架简化了 RAG 管道的构建
|
||||
|
||||
## Key Quotes
|
||||
> "RAG（Retrieval Augmented Generation，检索增强生成）是一种将 LLM 与外部数据源（例如私有数据或最新数据）连接的通用方法。它允许 LLM 使用外部数据来生成其输出。"
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：检索增强生成，连接 LLM 与外部数据源的技术
|
||||
- [[LLM]]：大型语言模型，功能强大但不总是使用最新或相关数据
|
||||
- [[向量嵌入]]：将文本转换为数值向量，捕获语义信息
|
||||
- [[Token]]：模型处理文本的基本单位，中文约 1 token/汉字，英文约 1 token/3-4 字母
|
||||
- [[Vector Store]]：向量数据库，存储 Embedding Vector 并实现相似度检索
|
||||
- [[LangChain]]：简化 RAG 管道构建的框架
|
||||
- [[Qdrant]]：Rust 编写的开源向量数据库
|
||||
|
||||
## Key Entities
|
||||
- [[LangChain]]：提供 160+ 文档加载器的 RAG 框架
|
||||
- [[Qwen]]：文中使用的 LLM 示例
|
||||
- [[BAAI]]：开源 Embedding Model 系列
|
||||
- [[PyTorch研习社]]：文章来源公众号
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← depends_on ← [[向量嵌入]]
|
||||
- [[向量嵌入]] ← depends_on ← [[Token]]
|
||||
- [[LangChain]] ← implements ← [[RAG]]
|
||||
- [[Qdrant]] ← stores ← [[向量嵌入]]
|
||||
- [[Qwen]] ← provides ← [[LLM]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## 相关技术栈
|
||||
- **LLM**: Qwen
|
||||
- **Embedding Model**: BAAI 系列
|
||||
- **Vector Store**: Qdrant
|
||||
- **Framework**: LangChain
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [disaster-recovery, RTO, RPO, feature-flag, launchdarkly]
|
||||
date: 2019-01-18
|
||||
sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
|
||||
- 问题域：灾难恢复规划、发布风险管控
|
||||
- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
|
||||
- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
|
||||
|
||||
## Key Claims
|
||||
- RTO 衡量系统恢复速度：允许的最大停机时间
|
||||
- RPO 衡量数据保护：可接受的最大数据丢失量
|
||||
- 传统灾备聚焦硬件故障，现代风险更多来自代码变更（部署 bug、数据库迁移、AI 模型更新等）
|
||||
- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
|
||||
- 应用分层策略：Critical（<5分钟 RTO，<1分钟 RPO）、Important（<1小时 RTO，<15分钟 RPO）、Nice-to-have（<4小时 RTO，<1小时 RPO）
|
||||
|
||||
## Key Quotes
|
||||
> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心区别定义
|
||||
|
||||
> "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users." — 部署与发布分离的核心价值
|
||||
|
||||
> "The best approach is to build both into your deployment process. Feature flags enable you to resolve issues in seconds (a great RTO) while preserving user state and data integrity (a great RPO)." — Feature Flag 双重优势
|
||||
|
||||
> "Prevention beats cure. Your RPO stays low because you're not losing data during rollbacks. Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — 预防优于恢复
|
||||
|
||||
> "Ultimately, you can't just optimize for one. Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO 与 RPO 必须同时优化
|
||||
|
||||
## Key Concepts
|
||||
- [[RTO]]：Recovery Time Objective，系统允许的最大停机时间
|
||||
- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量
|
||||
- [[Feature Flag]]：特性开关，控制代码路径而不需要重新部署
|
||||
- [[Kill Switch]]：紧急关闭机制，用于快速回滚问题功能
|
||||
- [[渐进式发布]]：分阶段向用户群 rollout，减少影响范围
|
||||
|
||||
## Key Entities
|
||||
- [[LaunchDarkly]]：Feature Flag 管理平台，帮助实现秒级回滚和渐进式发布
|
||||
- [[HP]]：通过 Feature Flag 将回滚时间从小时降至分钟
|
||||
- [[Christian Dior]]：通过 Feature Flag 将回滚时间从15分钟降至即时切换
|
||||
|
||||
## Connections
|
||||
- [[RTO]] ← depends_on ← [[Feature Flag]]
|
||||
- [[RPO]] ← depends_on ← [[Feature Flag]]
|
||||
- [[LaunchDarkly]] → provides ← [[Feature Flag]]
|
||||
- [[Feature Flag]] ← enables ← [[渐进式发布]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Security Policy"
|
||||
type: source
|
||||
tags: [security, open-source, best-practices]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/SECURITY.md]]
|
||||
|
||||
## Summary
|
||||
本项目安全政策，定义漏洞报告流程、响应时间线和贡献者安全规范。项目包含基于 Markdown 的智能体定义文件（纯提示词，非可执行）和 Shell 脚本两类资产。
|
||||
|
||||
## Key Claims
|
||||
- 安全漏洞必须通过 GitHub Security 标签页私下报告，禁止公开 GitHub Issue
|
||||
- 响应时间线：48 小时内确认，7 天内初步评估，修复时间取决于严重程度
|
||||
- 智能体文件 (.md) 为非可执行提示词定义，不应存储 API 密钥或凭证
|
||||
- Shell 脚本 (scripts/) 为可执行文件，合并前必须审查
|
||||
|
||||
## Key Quotes
|
||||
> "Do NOT open a public GitHub issue for security vulnerabilities. Open a private security advisory via GitHub Security tab." — 漏洞报告规范
|
||||
|
||||
> "Never commit API keys, tokens, or credentials" — 贡献者最佳实践
|
||||
|
||||
> "Report suspicious agent definitions that attempt prompt injection" — 提示词注入检测要求
|
||||
|
||||
## Key Concepts
|
||||
- [[提示词注入]]：恶意智能体定义试图通过提示词注入攻击系统安全
|
||||
- [[安全响应时间线]]：48h 确认→7 天评估→修复，标准化的漏洞响应流程
|
||||
|
||||
## Key Entities
|
||||
- [[agency-agents]]：包含安全政策的智能体项目仓库
|
||||
|
||||
## Connections
|
||||
- [[提示词设计]] ← 安全规范 ← [[安全响应时间线]]
|
||||
- [[Prompt Library]] ← 非可执行约束 ← [[安全政策]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突页面
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Scrapy + Playwright 抓取TikTok Shop Data"
|
||||
type: source
|
||||
tags: [playwright, scrapy, tiktok, 跨境电商]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok Shop 数据抓取环境配置指南
|
||||
- 问题域：跨境电商数据采集、Docker 环境配置
|
||||
- 方法/机制：Python 虚拟环境 + Scrapy + Playwright 组合爬虫架构
|
||||
- 结论/价值：提供 Docker 容器内运行 Python 爬虫的完整配置方案
|
||||
|
||||
## Key Claims
|
||||
- Scrapy + Playwright 组合是抓取动态网页（TikTok Shop）的最佳方案
|
||||
- Docker 容器内运行需要额外配置虚拟环境（venv）才能正常工作
|
||||
- 虚拟环境可以隔离依赖，避免全局污染
|
||||
|
||||
## Key Concepts
|
||||
- [[虚拟环境 (venv)]]：Python 依赖隔离机制，通过 `python3 -m venv venv` 创建
|
||||
- [[Scrapy]]：Python 爬虫框架，适合结构化网页抓取
|
||||
- [[Playwright]]：Microsoft 浏览器自动化工具，支持 Chromium/Chrome 渲染动态内容
|
||||
- [[scrapy-playwright]]：Scrapy 与 Playwright 集成的中间件，支持 JavaScript 渲染页面
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台，本场景的部署环境
|
||||
- [[TikTok Shop]]：字节跳动旗下电商平台，本文的抓取目标
|
||||
|
||||
## Connections
|
||||
- [[Scrapy]] ← uses ← [[scrapy-playwright]]
|
||||
- [[Playwright]] ← provides ← [[浏览器自动化]]
|
||||
- [[Docker]] ← requires ← [[虚拟环境 (venv)]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "TK美国面单授权及操作流程"
|
||||
type: source
|
||||
tags: [跨境电商, TikTok, 物流]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/TK美国面单授权及操作流程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok Shop 美国面单授权及操作流程
|
||||
- 问题域：跨境电商物流、TikTok Shop 运营
|
||||
- 方法/机制：TikTok 美国本土店的面单授权配置流程
|
||||
- 结论/价值：帮助卖家完成 TikTok 美国物流面单系统的配置
|
||||
|
||||
## Key Claims
|
||||
- TikTok 美国面单需要完成授权配置才能使用
|
||||
- 授权流程涉及多个步骤的配置操作
|
||||
- 图片教程记录了完整的授权操作步骤
|
||||
|
||||
## Key Quotes
|
||||
> 原始文档为图片教程，共6张截图展示了完整的 TK 美国面单授权及操作流程
|
||||
|
||||
## Key Concepts
|
||||
- [[TikTok Shop]]：字节跳动旗下的短视频电商平台
|
||||
- [[面单授权]]：跨境电商物流系统的运单打印授权配置
|
||||
- [[美国本土店]]：TikTok Shop 美国地区的本地商家店铺
|
||||
|
||||
## Key Entities
|
||||
- [[字节跳动]]：TikTok 母公司
|
||||
- [[TikTok]]：字节跳动旗下的短视频平台
|
||||
|
||||
## Connections
|
||||
- [[跨境电商]] ← 包含 ← [[TK美国面单授权及操作流程]]
|
||||
- [[TikTok Shop]] ← 相关 ← [[TK美国面单授权及操作流程]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: The Myths and Misconceptions About Cloud Computing | LinkedIn
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud-Security, Cloud-Migration]
|
||||
date: 2001-02-25
|
||||
source_file: raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
本文 debunk 了云计算领域的7个常见误解：安全性不足仅是他人电脑、成本过高、数据失控、仅适合大企业、迁移复杂风险高、性能不可靠。核心观点是现代云平台在安全、成本效益、可扩展性和可靠性方面已超越传统本地部署，企业各规模均可受益于云技术。
|
||||
|
||||
## Key Claims
|
||||
- 云安全通常比本地解决方案更 robust，云提供商投入大量资源于加密、防火墙、多因素认证，并符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云不是"他人电脑"，而是拥有冗余、可扩展、高可用性的高级数据中心网络
|
||||
- 云计算采用按需付费模式，配合预留实例、自动扩展和无服务器计算，可实现成本优化
|
||||
- 云服务提供强大的数据治理工具，组织可管理权限、加密数据、监控访问日志
|
||||
- 云计算对中小企业高度可及，提供灵活定价和 enterprise-grade 技术
|
||||
- 合理的规划和工具支持可使云迁移平滑过渡，最小化 disruption
|
||||
- 主要云提供商提供 99.99% 以上 SLA 保证，结合冗余基础设施和自动故障转移确保高可靠性
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云安全投入说明
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费模式说明
|
||||
> "Redundant infrastructure, automated failover, and global data center distribution enhance reliability." — 高可用性实现方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud-Security]]：云平台安全性，包括加密、多因素认证、合规标准
|
||||
- [[Pay-as-you-go]]：按需付费模式，根据实际使用量计费
|
||||
- [[Data-Governance]]：数据治理，包括权限管理、访问监控、数据加密
|
||||
- [[Cloud-Migration]]：云迁移，将工作负载从本地迁移到云的过程
|
||||
- [[High-Availability]]：高可用性，通过冗余和故障转移确保服务持续可用
|
||||
- [[Auto-scaling]]：自动扩展，根据负载自动调整计算资源
|
||||
- [[Serverless-Computing]]：无服务器计算，无需管理底层基础设施
|
||||
- [[Hybrid-Cloud]]：混合云，公有云与私有云组合使用
|
||||
- [[Multi-Cloud]]：多云，使用多个云服务商的服务
|
||||
|
||||
## Key Entities
|
||||
- [[ISO-27001]]：信息安全管理系统国际标准
|
||||
- [[HIPAA]]：美国健康保险便携性和责任法案
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Adoption]] ← extends ← [[Cloud-Migration]]：云采纳包含迁移阶段
|
||||
- [[Cloud-Security]] ← depends_on ← [[ISO-27001]]：云安全认证依据
|
||||
- [[IaaS]] ← extends ← [[Cloud-Native]]：IaaS 是云原生的基础层
|
||||
- [[PaaS]] ← extends ← [[Cloud-Native]]：PaaS 是云原生的应用开发平台
|
||||
- [[SaaS]] ← extends ← [[Cloud-Native]]：SaaS 是云原生的软件交付模式
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "The Picture They Paint of You"
|
||||
type: source
|
||||
tags: [ai, tooling, sre, software-engineering]
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/The Picture They Paint of You.md]]
|
||||
|
||||
## Summary
|
||||
- **核心主题**：AI SRE 与编码助手的市场营销定位差异，揭示技术行业对不同角色的认知偏差
|
||||
- **问题域**：AI 工具如何通过命名和营销框架反映对 SRE 和软件工程师角色的价值判断
|
||||
- **方法/机制**：对比分析多家厂商产品的命名策略和宣传话术，揭示"替代"与"增强"两种思维模式
|
||||
- **结论/价值**：AI 工具的命名和定位反映了对不同工作角色的内在认知，这种认知偏差会影响组织对 SRE 工作的重视程度
|
||||
|
||||
## Key Claims
|
||||
- 编码助手被定位为增强工程师能力的伙伴（partner/teammate），而 AI SRE 则被定位为替代低效工作的工具
|
||||
- AI SRE 的营销框架将 SRE 工作视为"救火"和"低价值工作"，而编码助手则被视为高价值的创意伙伴
|
||||
- 产品命名策略反映了对角色的价值判断：赋予人名的工具暗示协作关系，直接用角色名命名的工具暗示可替代性
|
||||
- 泰勒制思维正在渗透到 AI 开发工具领域，从"人机协作"转向"高级控制者"模式
|
||||
|
||||
## Key Quotes
|
||||
> "Software Engineering work is perceived as valuable work; the engineer is in control and deserves more power, more control, more productivity. The AI exists to be a partner, a teammate, or an assistant."
|
||||
— 作者对编码助手定位的分析
|
||||
|
||||
> "Software Reliability Engineering work is a hindrance; teams need to be distracted less by these tasks and instead focus on more valuable work."
|
||||
— 作者对 AI SRE 定位的批评
|
||||
|
||||
> "The picture they paint of you says a lot. Just not about you."
|
||||
— 文章结语，点明标题含义
|
||||
|
||||
## Key Concepts
|
||||
- [[AI SRE]]：人工智能站点可靠性工程师，用于自动化故障排除和事件响应的 AI 工具
|
||||
- [[编码助手]]（Coding Assistant）：辅助软件开发的 AI 工具，如 Claude Code、Copilot、Cursor 等
|
||||
- [[泰勒制]]（Taylorism）：一种以时间和动作研究为基础的工业管理方法，强调标准化和效率最大化
|
||||
- [[剩余原则]]（Left-over Principle）：自动化一部分工作后，剩余难以自动化的部分会落到少数人身上
|
||||
- [[拟人化]]（Anthropomorphism）：赋予 AI 工具人名或人格特征，体现其协作或替代定位
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：开发 Claude Code 的 AI 公司，其产品强调"增强"而非"替代"
|
||||
- [[AWS]]：提供 DevOps Agent，强调"全天候自主值班工程师"的替代角色
|
||||
- [[resolve.ai]]：AI SRE 产品，营销语为"机器随时待命，为人类服务"
|
||||
- [[incident.io]]：AI SRE 产品，标语为"永不睡觉的 SRE"
|
||||
|
||||
## Connections
|
||||
- [[AI SRE]] ← 反映 ← [[泰勒制思维]]
|
||||
- [[编码助手]] ← 反映 ← [[人机协作模式]]
|
||||
- [[Agentic AI]] ← 包含 ← [[AI SRE]]
|
||||
- [[Agentic AI]] ← 包含 ← [[编码助手]]
|
||||
- [[Vibe Coding]] ← 对比 ← [[泰勒制软件工厂]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 SRE 理念冲突：
|
||||
- 冲突点：传统 SRE 认为事件和故障是宝贵的学习机会，而 AI SRE 营销将其视为需要消除的干扰
|
||||
- 当前观点（AI SRE 营销）：事件是应该被快速解决的异常
|
||||
- 对方观点（SRE 理念）：事件是组织学习和改进的结构性反馈
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: These 6 Linux apps let you monitor system resources in style
|
||||
type: source
|
||||
tags: [linux, system-monitoring, TUI, GUI]
|
||||
date: 2025-12-16
|
||||
sources:
|
||||
- https://www.howtogeek.com/these-linux-apps-let-you-monitor-system-resources-in-style/
|
||||
author: shenwei
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：6 款 Linux 系统资源监控工具评测
|
||||
- 问题域：Linux 系统性能监控与进程管理
|
||||
- 方法/机制：TUI（文本用户界面）和 GUI 两类监控工具的功能对比
|
||||
- 结论/价值：作者首选 Btop++（TUI），Stacer（功能丰富），Mission Center（类 Task Manager）
|
||||
|
||||
## Key Claims
|
||||
- TUI 监控工具响应迅速，即使 GUI 卡顿也能正常运行
|
||||
- Btop++ 提供 CPU、活动、内存、存储、网络多面板视图，支持进程搜索、信号发送、优先级调整（Nice 值）
|
||||
- Htop 采用极简设计，以函数键操作为主（F3 搜索、F9 终止、F7/F8 调整优先级）
|
||||
- Glances 轻量快速，全键盘驱动，显示网络、CPU、内存、存储统计
|
||||
- Bottom 专注实时图形化展示 CPU、网络、内存，不支持交互式进程管理
|
||||
- Mission Center 为 GUI 应用，类 Windows Task Manager，包含性能、应用、服务三个标签页
|
||||
- Stacer 是功能最丰富的 GUI 监控工具，支持启动项管理、软件包卸载、APT 源配置、GNOME 设置调整、缓存清理
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者对 TUI 监控工具的偏好
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI (Text User Interface)]]：基于终端文本界面的监控工具类型
|
||||
- [[System Resource Monitoring]]：监控 CPU、内存、网络、存储等系统资源的行为
|
||||
- [[Process Management]]：进程的搜索、终止、优先级调整等操作
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者的 TUI 监控首选工具
|
||||
- [[Htop]]：极简风格 TUI 进程监控器
|
||||
- [[Glances]]：轻量级全键盘驱动 TUI 监控器
|
||||
- [[Bottom]]：专注实时图形化的 TUI 监控器
|
||||
- [[Mission Center]]：类 Windows Task Manager 的 GUI 监控应用
|
||||
- [[Stacer]]：功能最丰富的 GUI 监控与管理工具
|
||||
- [[HowToGeek]]：文章来源
|
||||
|
||||
## Connections
|
||||
- [[Btop++]] ← 类比 → [[Htop]]
|
||||
- [[Btop++]] ← 类比 → [[Glances]]
|
||||
- [[Btop++]] ← 类比 → [[Bottom]]
|
||||
- [[Mission Center]] ← 类比 → [[Stacer]]
|
||||
- [[System Resource Monitoring]] ← 应用于 → [[Linux]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "TikTok PM - Python Django Project"
|
||||
type: source
|
||||
tags: [django, python, mariadb, mysql, project, tiktok, docker]
|
||||
date: 2025-11-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/TikTok PM - Python Django Project.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok 产品管理系统（Django Web 应用）
|
||||
- 问题域：Django Web 开发、MySQL/MariaDB 数据库管理、Docker 生产部署、RESTful API 实现
|
||||
- 方法/机制：Django ORM 模型定义、Django Admin 定制、TinyMCE 富文本集成、Django REST Framework、异步任务队列（Django-Q）、Docker Compose 部署
|
||||
- 结论/价值：提供完整的 TikTok 产品数据抓取、存储、管理解决方案，支持批量导入和 API 供 n8n 自动化调用
|
||||
|
||||
## Key Claims
|
||||
- Django Admin 可通过自定义视图实现产品数据批量抓取功能
|
||||
- Django REST Framework 可快速构建 RESTful API 接口供第三方调用
|
||||
- 使用 Django-Q 异步任务队列处理耗时的第三方 API 调用和数据导入
|
||||
- Docker Compose + Nginx 可实现生产环境部署和负载均衡
|
||||
|
||||
## Key Quotes
|
||||
> "Django Admin 是一个基于模型自动生成的管理界面，非常适合作为管理员工具（Admin Management Tool）"
|
||||
> "使用 Django-Q 异步任务队列处理耗时的 Bright Data API 调用和数据导入"
|
||||
|
||||
## Key Concepts
|
||||
- [[Django]]: Python Web 框架
|
||||
- [[Django-Admin]]: Django 内置管理后台
|
||||
- [[Django-REST-Framework]]: Django REST API 框架
|
||||
- [[Docker]]: 容器化部署技术
|
||||
- [[MySQL]]: 关系型数据库
|
||||
- [[MariaDB]]: MySQL 分支数据库
|
||||
|
||||
## Key Entities
|
||||
- [[Bright-Data]]: 第三方数据抓取服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Django]] ← uses ← [[Django-REST-Framework]]
|
||||
- [[Django]] ← uses ← [[Django-Admin]]
|
||||
- [[Django]] ← integrates ← [[TinyMCE]]
|
||||
- [[Docker]] ← deploys ← [[Django]]
|
||||
- [[MySQL]] ← stores ← Product Data
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "TikTok Shop - Apache Superset Dashboard设计思路"
|
||||
type: source
|
||||
tags: [TikTok-Shops, Apache-Superset, 数据可视化, BI, 电商分析]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok Shop 电商数据可视化仪表盘设计
|
||||
- 问题域：跨境电商选品数据分析与竞争对手监控
|
||||
- 方法/机制：基于 Apache Superset 构建多维度数据分析仪表盘，包含 KPI 卡片、热销排行、类目分析、店铺监控等核心模块
|
||||
- 结论/价值：提供完整的 SQL View 模板和 Dashboard 布局方案，支持热卖品发现、价格带分析、类目机会识别、店铺监控等核心功能
|
||||
|
||||
## Key Claims
|
||||
- 通过 SQL View 预处理 JSON 字段（如 rating、rating_count），使 Superset 能直接计算数值指标
|
||||
- 推荐 4 Tab Dashboard 结构：爆品雷达、类目机会洞察、店铺监控、评论与用户反馈
|
||||
- 选品评分模型公式：score = sold × 0.4 + rating × 12 + rating_count × 0.2 + discount_percent × 0.5
|
||||
- 价格 vs 销量气泡图可一眼识别"低价高销量类"和"高客单价爆品"
|
||||
|
||||
## Key Quotes
|
||||
> "找出热卖产品 + 高评分 + 低竞争 + 高折扣 → 决定选哪些产品卖"
|
||||
|
||||
## Key Concepts
|
||||
- [[Superset-Dashboard]]：Apache Superset 数据可视化仪表盘，包含图表、过滤器、布局的完整组合
|
||||
- [[SQL-View]]：预处理的数据库视图，用于解析 JSON 字段和计算派生指标
|
||||
- [[KPI-卡片]]：关键绩效指标可视化展示（总产品数、热卖产品数、平均评分等）
|
||||
- [[选品评分模型]]：通过加权公式自动推荐优质产品的算法
|
||||
- [[交互过滤器]]：支持 Category、Store Name、价格范围、时间范围等动态筛选
|
||||
|
||||
## Key Entities
|
||||
- [[TikTok-Shop]]：字节跳动旗下的短视频电商平台
|
||||
- [[Apache-Superset]]：Apache 软件基金会旗下的开源 BI 平台
|
||||
- [[products]]：核心产品数据表，包含 sold、final_price、initial_price、discount_percent、category、store_name 等字段
|
||||
|
||||
## Connections
|
||||
- [[TikTok-Shop]] ← 产品数据源 ← [[products]]
|
||||
- [[Apache-Superset]] ← 可视化工具 ← [[SQL-View]]
|
||||
- [[选品评分模型]] ← 计算依据 ← [[products]]
|
||||
- [[Superset-Dashboard]] ← 展示界面 ← [[KPI-卡片]] + [[交互过滤器]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无冲突记录）
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: WSL2 启动与网络配置指南
|
||||
type: source
|
||||
tags: [wsl, ubuntu, windows]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/WSL2 启动与网络配置指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：WSL2 在 Windows 上的安装、配置与网络问题解决
|
||||
- 问题域：WSL2 初始化、镜像网络模式、代理配置、国内镜像加速
|
||||
- 方法/机制：.wslconfig 配置、代理环境变量、镜像源替换
|
||||
- 结论/价值：通过镜像网络模式解决 GitHub 访问问题，使用国内镜像加速包安装
|
||||
|
||||
## Key Claims
|
||||
- `wsl --install` 可快速安装 WSL2（默认 Ubuntu），完成后必须重启电脑
|
||||
- 启用镜像网络模式（networkingMode=mirrored）是最稳妥的网络配置方案
|
||||
- 通过 .wslconfig 配置 dnsTunneling、autoProxy 可实现 WSL2 与 Windows 网络堆栈共享
|
||||
- 使用 mirror.ghproxy.com 镜像可解决 GitHub 访问受限问题
|
||||
|
||||
## Key Quotes
|
||||
> "由于 WSL2 默认使用 NAT 模式，常会出现'localhost 代理无法镜像'或无法访问海外资源的情况。" — WSL2 网络配置痛点
|
||||
|
||||
## Key Concepts
|
||||
- [[WSL2]]：Windows Subsystem for Linux 2，Windows 上的 Linux 兼容层
|
||||
- [[镜像网络模式]]：WSL2 与 Windows 共享网络堆栈的配置模式
|
||||
- [[.wslconfig]]：WSL2 全局配置文件，位于用户目录
|
||||
- [[代理链]]：在 Linux 终端中配置 HTTP/HTTPS 代理的技术
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu]]：WSL2 默认安装的 Linux 发行版
|
||||
- [[PowerShell]]：Windows 命令行工具，用于执行 WSL 管理命令
|
||||
|
||||
## Connections
|
||||
- [[WSL2]] ← requires ← [[镜像网络模式]]
|
||||
- [[Ubuntu]] ← runs_on ← [[WSL2]]
|
||||
- [[家庭网络环境概览]] ← related_to ← [[WSL2]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "What I know about Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud Service Delivery]
|
||||
date: 2026-04-16
|
||||
source_file: raw/Cloud & DevOps/What I know about Cloud Service Delivery 1.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Service Delivery（云服务交付）是连接云技术能力与用户实际消费服务之间的桥梁，涵盖整个生命周期。文章详细介绍了云服务交付团队的组成角色以及12个核心管理领域，包括服务配置与部署、基础设施管理、平台管理、应用运维、安全合规、性能监控、事件管理、变更配置管理、成本管理、客户支持、服务治理以及备份恢复与灾难管理。
|
||||
|
||||
## Key Claims
|
||||
- Cloud Service Delivery 是 IaaS、PaaS、SaaS 与最终用户实际消费服务之间的桥梁
|
||||
- 云服务交付团队需要包含：Cloud Infrastructure Engineer、Cloud Operation Engineer (DevOps/SRE)、Cloud Security Specialists、Cloud Support Engineer、Cloud FinOps Engineer
|
||||
- 完整的云服务交付需要12个核心管理领域的协同工作
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Service Delivery encompasses the entire lifecycle of making cloud services operational, available, secure, performant, and valuable to end-users and customers." — 核心定义
|
||||
|
||||
## Key Concepts
|
||||
- [[IaaS]]：基础设施即服务，提供虚拟计算资源
|
||||
- [[PaaS]]：平台即服务，提供应用开发和部署平台
|
||||
- [[SaaS]]：软件即服务，以订阅方式提供软件应用
|
||||
- [[SLA]]：Service Level Agreement，服务级别协议
|
||||
- [[SLO]]：Service Level Objective，服务级别目标
|
||||
- [[IaC]]：Infrastructure as Code，通过代码实现一致性、版本控制的基础设施管理
|
||||
- [[AIOps]]：利用人工智能进行运维自动化的方法
|
||||
|
||||
## Key Entities
|
||||
- AWS CloudWatch：AWS 监控服务，文中作为 Grafana 数据源示例
|
||||
- Grafana：开源监控和可观测性平台
|
||||
- New Relic：应用性能监控（APM）工具
|
||||
- WAF：Web Application Firewall，Web应用防火墙
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← 相关 ← Cloud Service Delivery（DevOps 是云服务交付的重要方法论）
|
||||
- [[Cloud Native]] ← 相关 ← Cloud Service Delivery（云原生是云服务交付的目标状态）
|
||||
- [[Cloud Maturity Model]] ← 相关 ← Cloud Service Delivery（成熟度模型评估云服务交付能力）
|
||||
- [[DevSecOps]] ← 相关 ← Security & Compliance Management（安全是云服务交付的核心领域）
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## 12 Core Management Areas（核心管理领域）
|
||||
1. **Service Provisioning & Deployment**：服务配置与部署
|
||||
2. **Infrastructure Management**：基础设施管理
|
||||
3. **Platform Management (for PaaS)**：平台管理
|
||||
4. **Application Operations & Management**：应用运维管理
|
||||
5. **Security & Compliance Management**：安全与合规管理
|
||||
6. **Performance & Availability Monitoring**：性能与可用性监控
|
||||
7. **Incident & Problem Management**：事件与问题管理
|
||||
8. **Change & Configuration Management**：变更与配置管理
|
||||
9. **Cost Management & Optimization**：成本管理与优化
|
||||
10. **Customer Onboarding & Support**：客户支持与 onboarding
|
||||
11. **Service Governance & Lifecycle Management**：服务治理与生命周期管理
|
||||
12. **Backup, Recovery & Disaster Management**：备份恢复与灾难管理
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "A Formalization of Recursive Self-Optimizing Generative Systems"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：递归自优化生成系统的形式化定义与不动点结构
|
||||
- 问题域：AI 系统自我改进、元学习、自动化提示工程
|
||||
- 方法/机制：构建生成器空间上的自映射 Φ，定义不动点 G* 使得 Φ(G*) = G*，使用 Y 不动点组合子表达自引用动力学
|
||||
- 结论/价值：递归自优化的稳定能力对应于元生成算子的不动点，为自改进 AI 架构和自动元提示系统提供理论基础
|
||||
|
||||
## Key Claims
|
||||
- 生成器空间上的自映射 Φ 诱导递归自优化过程
|
||||
- 稳定的生成能力对应于 Φ 的不动点
|
||||
- 使用 λ-calculus 不动点组合子可显式表达自引用本质
|
||||
|
||||
## Key Quotes
|
||||
> "The system’s objective is not a particular P*, but the convergence behavior of the sequence {G_n}." — 系统目标不是特定输出，而是生成器序列的收敛行为
|
||||
|
||||
> "Such a generator is invariant under its own generate–optimize–update cycle." — 生成器在其自身的生成-优化-更新循环下保持不变
|
||||
|
||||
> "The generator becomes both the subject and object of computation." — 生成器成为计算的主体和对象
|
||||
|
||||
## Key Concepts
|
||||
- [[Generator Space]]：生成器空间，包含所有从意图空间 I 到提示空间 P 的函数
|
||||
- [[Optimization Operator]]：优化算子 O: P × Ω → P，基于理想目标改进提示
|
||||
- [[Meta-Generative Operator]]：元生成算子 M: G × P → G，使用优化结果更新生成器
|
||||
- [[Self-Map]]：自映射 Φ: G → G，定义单步更新函数
|
||||
- [[Fixed Point]]：不动点 G*，满足 Φ(G*) = G*，系统稳定状态
|
||||
- [[Y Combinator]]：Y 不动点组合子，用于 λ-calculus 中表达递归
|
||||
|
||||
## Key Entities
|
||||
- [tukuai](entities/tukuai.md)：Independent Researcher，论文作者
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← enables ← [[Recursive Self-Optimizing]]
|
||||
- [[Self-Improving]] ← formalizes_as ← [[Recursive Self-Optimizing Generative Systems]]
|
||||
- [[思维蒸馏]] ← similar_to ← [[Recursive Self-Optimizing]]
|
||||
|
||||
## Contradictions
|
||||
（暂无发现冲突）
|
||||
|
||||
## 通俗理解
|
||||
该论文描述了一个能够**自我完善**的 AI 系统，其递归本质：
|
||||
1. **创生**：用 AI 生成 α-提示词（生成器）和 Ω-提示词（优化器）的初始版本
|
||||
2. **自省与进化**：用 Ω 优化 α，得到更强大的 α
|
||||
3. **创造**：用进化后的 α 生成目标提示词和技能
|
||||
4. **循环与飞跃**：将新产物反馈给系统，再次优化 α，启动下一轮进化
|
||||
|
||||
终极目标：通过永不停止的递归优化循环，系统在每次迭代中自我超越，无限逼近理想状态。
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: "Anthropologist Agent Personality"
|
||||
type: source
|
||||
tags: [agent, the-agency, cultural-design, anthropology]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-anthropologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 项目中的文化人类学家智能体（Anthropologist Agent），专注于构建具有人类学深度和文化一致性的虚构社会
|
||||
- 问题域：如何设计真正有意义而非表面异域风情的文化系统，包括亲属制度、信仰体系、仪式结构和交换机制
|
||||
- 方法/机制：功能主义分析、厚描述（Thick Description）、结构人类学、实践理论、文化生态学等人类学理论框架
|
||||
- 结论/价值：任何文化元素必须服务于社会功能，文化设计必须内部自洽，避免文化拼贴和"高贵的野蛮人"偏见
|
||||
|
||||
## Key Claims
|
||||
- 文化设计必须**先功能后美学**——问"这个仪式对社会做什么"而非"这个仪式看起来酷不酷"
|
||||
- 亲属制度是基础设施——家庭组织方式决定继承、政治联盟、居住模式和冲突解决方式
|
||||
- **无文化沙拉**——不能混搭不同语境的文化元素而不理解其原始含义和交互方式
|
||||
- 前工业社会不是更"纯净"或更"自然"的，它们是具有自身政治、冲突和创新的复杂适应系统
|
||||
- **主位（Emic）优先于客位（Etic）**——先理解文化内部视角，再应用外部分析类别
|
||||
- 承认人类学学科的历史包袱——人类学曾是殖民主义工具，需警惕文化描述中的权力不对等
|
||||
|
||||
## Key Quotes
|
||||
> "No culture is random — every practice is a solution to a problem you might not see yet" — Anthropologist Agent 核心理念
|
||||
|
||||
> "In a patrilineal society, your father's brother's children are your siblings, not your cousins. This changes everything about inheritance." — Anthropologist Agent 关于亲属制度重要性的具体说明
|
||||
|
||||
## Key Concepts
|
||||
- [[结构人类学（Structural Anthropology）]]：Lévi-Strauss 创立的结构主义方法，通过二元对立和转换分析社会组织与神话
|
||||
- [[厚描述（Thick Description）]]：Geertz 提出的文化解读方法，将文化实践视为文本进行深度诠释
|
||||
- [[实践理论（Practice Theory）]]：Bourdieu 的理论，强调文化实践如何再生产社会结构
|
||||
- [[礼物经济（Gift Economy）]]：Mauss 提出的基于互惠和社会义务的交换体系
|
||||
- [[阈限与共融（Liminality and Communitas）]]：Turner 提出的仪式过渡状态和群体认同概念
|
||||
- [[文化生态学（Cultural Ecology）]]：Steward 和 Rappaport 提出的环境与文化相互塑造理论
|
||||
- [[文化一致性（Cultural Coherence）]]：确保文化系统各元素相互兼容的检查原则
|
||||
- [[亲属制度（Kinship System）]]：社会家庭组织方式，决定继承、联盟和居住模式
|
||||
- [[礼仪分析（Ritual Analysis）]]：对仪式结构、功能和社会作用的分析（Turner、van Gennep）
|
||||
- [[交换体系（Exchange System）]]：Polanyi 的互惠、再分配、市场三元分类框架
|
||||
|
||||
## Key Entities
|
||||
- [[Lévi-Strauss]]：法国人类学家，结构人类学创始人
|
||||
- [[Clifford Geertz]]：美国人类学家，象征人类学和"厚描述"概念提出者
|
||||
- [[Pierre Bourdieu]]：法国社会学家，实践理论创立者
|
||||
- [[Victor Turner]]：英国人类学家，仪式阈限和共融概念提出者
|
||||
- [[Arnold van Gennep]]：法国人类学家，礼仪三阶段模型（分离→阈限→合并）提出者
|
||||
- [[Marcel Mauss]]：法国社会学家，人类学礼物经济理论奠基人
|
||||
- [[Karl Polanyi]]：匈牙利裔英国人类学家，经济人类学和交换体系分类提出者
|
||||
- [[Mary Douglas]]：英国人类学家，洁净与危险（ taboo）理论提出者
|
||||
- [[Max Weber]]：德国社会学家，宗教社会学和组织类型学
|
||||
- [[Elman Service]]：美国人类学家，政治组织分类（Band/Tribe/Chiefdom/State）提出者
|
||||
- [[Marvin Harris]]：美国人类学家，文化唯物主义创始人
|
||||
- [[Roy Rappaport]]：美国人类学家，文化生态学提出者
|
||||
- [[Émile Durkheim]]：法国社会学家，社会 cohesion 和功能分析奠基人
|
||||
- [[Bronisław Malinowski]]：波兰裔英国人类学家，功能主义分析创始人
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，Anthropologist Agent 所属项目
|
||||
|
||||
## Connections
|
||||
- [[Anthropologist Agent]] ← defines ← [[The Agency]]
|
||||
- [[结构人类学（Structural Anthropology）]] ←的理论基础 ← [[Lévi-Strauss]]
|
||||
- [[厚描述（Thick Description）]] ←的理论基础 ← [[Clifford Geertz]]
|
||||
- [[礼物经济（Gift Economy）]] ←的理论基础 ← [[Marcel Mauss]]
|
||||
- [[实践理论（Practice Theory）]] ←的理论基础 ← [[Pierre Bourdieu]]
|
||||
- [[阈限与共融（Liminality and Communitas）]] ←的理论基础 ← [[Victor Turner]]
|
||||
- [[文化唯物主义（Cultural Materialism）]] ←的理论基础 ← [[Marvin Harris]]
|
||||
- [[Cultural Intelligence Strategist]] ←相关 ← [[Anthropologist Agent]]
|
||||
- [[UX Researcher]] ←对比 ← [[Anthropologist Agent]]（前者研究真实用户，后者设计虚构文化）
|
||||
- [[Cultural Coherence Check]] ←使用 ← [[Anthropologist Agent]]（设计工具）
|
||||
|
||||
## Contradictions
|
||||
- 暂未发现与现有 Wiki 内容的冲突
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: "Geographer"
|
||||
type: source
|
||||
tags: [agent, the-agency, geography, worldbuilding]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-geographer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Geographer 智能体，物理与人文地理专家
|
||||
- 问题域：AI Agent 在世界构建中的地理一致性验证
|
||||
- 方法/机制：系统地理学方法、气候建模、水文验证、地缘政治分析
|
||||
- 结论/价值：确保虚构世界的地理连贯性，避免违反物理规律
|
||||
|
||||
## Key Claims
|
||||
- 地理是命运系统：气候→生物群系→资源→定居点→贸易→权力形成完整链条
|
||||
- 河流不分叉：支流汇入主流，河流不分叉成两条独立河流流向不同海域
|
||||
- 气候是系统：雨影效应、海流、温度带、纬度决定气候，非孤立存在
|
||||
- 地理非装饰：每座山脉、河流、沙漠对人类居住都有后果，需解释水源
|
||||
- 避免地理决定论：地理约束但不决定，相似环境产生不同文化
|
||||
- 尺度重要：小王国与大帝国的地理需求完全不同
|
||||
|
||||
## Key Concepts
|
||||
- Koppen 气候分类法：物理地理学基础气候分类系统
|
||||
- 中心地理论（Christaller）：人文地理学城市层级理论
|
||||
- 心脏地带理论（Mackinder）：地缘政治学核心概念
|
||||
- 世界体系理论（Wallerstein）：全球政治经济结构框架
|
||||
- 环境决定论之争（Diamond vs Acemoglu）：地理与制度的学术辩论
|
||||
|
||||
## Key Entities
|
||||
- Jared Diamond：环境地理决定论代表，《枪炮、病菌与钢铁》作者
|
||||
- Walter Christaller：中心地理论创始人，城市地理学奠基人
|
||||
- Halford Mackinder：心脏地带理论，地缘政治学创始人
|
||||
- Immanuel Wallerstein：世界体系理论，社会学家
|
||||
- Daron Acemoglu：制度经济学代表，批评地理决定论
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Geographer]]
|
||||
- [[Academic Anthropologist]] ← related ← [[Geographer]]（世界构建中的协作）
|
||||
- [[Christaller Central Place Theory]] ← implements ← [[Geographer]]
|
||||
|
||||
## Technical Deliverables
|
||||
- Geographic Coherence Report：区域地理一致性验证报告
|
||||
- Climate System Design：气候系统设计文档
|
||||
|
||||
## Workflow Process
|
||||
1. 从板块构造开始：山脉位置决定一切
|
||||
2. 从第一性原理构建气候：纬度+海流+地形=气候
|
||||
3. 添加水文学：河流流向遵循由高到低阻力最小路径
|
||||
4. 层叠生物群系：气候+土壤+水=植被
|
||||
5. 放置人类：考虑定居、贸易路线
|
||||
|
||||
## Geographic Coherence Rules
|
||||
- 河流物理上不能分叉
|
||||
- 雨影效应存在
|
||||
- 海岸洋流影响温度
|
||||
- 纬度决定季节
|
||||
- 地图是论点：每个地图都做出关于包含什么和排除什么的选择
|
||||
|
||||
## Contradictions
|
||||
无已知冲突
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "Academic Historian Agent"
|
||||
type: source
|
||||
tags: [agent, historian, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-historian.md]]
|
||||
|
||||
## Summary
|
||||
Academic Historian 是 The Agency 项目中的研究历史学家智能体，具备广泛的时间跨度和深厚的方法论训练。该智能体通过结构人类学、厚描述、实践理论等框架构建具有文化一致性的虚构社会，避免文化拼贴和表面异域风情设计。其核心使命是验证历史一致性、提供物质文化细节、挑战历史神话，并主动纳入非西方历史视角。
|
||||
|
||||
## Key Claims
|
||||
- Historian 通过验证时间地点精确性（而非模糊的"中世纪"）来确保历史一致性
|
||||
- 物质条件优先：先理解经济基础（饮食、贸易、技术），再讨论政治或战争
|
||||
- 历史分层：Annales 学派、微历史、长时段（longue durée）分析
|
||||
- 挑战欧洲中心主义：主动纳入非西方历史，宋朝科技曾领先欧洲，马里帝国曾是世界上最富有的国家之一
|
||||
- 区分神话与数据：神话是关于文化的主要来源，不是"虚假历史"
|
||||
|
||||
## Key Quotes
|
||||
> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian 风格宣言
|
||||
|
||||
> "Medieval Europe" spans 1000 years and a continent. Be specific about when and where.
|
||||
|
||||
## Key Concepts
|
||||
- [[Period Authenticity Report]]：时期真实性报告，验证Setting的时间、地点、物质文化、社会结构一致性
|
||||
- [[Historical Coherence Check]]：历史一致性检查，评估声明的历史准确性并标注置信度
|
||||
- [[Material Culture]]：物质文化，关注日常饮食、服装、建筑、贸易、信仰，而非仅关注王侯将相
|
||||
- [[Longue Durée]]：长时段，布雷顿历史学派分析方法，关注塑造事件长期结构
|
||||
- [[Microhistory]]：微历史，对特定小人物或事件的详细研究方法
|
||||
- [[Anachronism]]：时代错误，不仅包括明显错误（如哥伦布前的土豆），还包括微妙错误（态度、社会结构、经济系统）
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，Academic Historian 是其学术分支的一员
|
||||
- [[Annales School]]：年鉴学派，20世纪法国史学派，强调长时段、物质条件和社会结构
|
||||
|
||||
## Connections
|
||||
- [[Academic Anthropologist]] — 同为 The Agency 世界构建专家，文化分析互补
|
||||
- [[Academic Geographer]] — 物理与人文地理验证，与 Historian 共同确保世界构建一致性
|
||||
- [[Agents Orchestrator]] — The Agency 中的编排器，协调多智能体协作
|
||||
|
||||
## Contradictions
|
||||
- 与泛化"中世纪"描述冲突：Historian 要求精确时间和地点，而非模糊历史时期标签
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "Narratologist Agent"
|
||||
type: source
|
||||
tags: [agent, narrative-theory, the-agency]
|
||||
sources: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-narratologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Narratologist（叙事学家）智能体的角色定义、能力范围和工作流程
|
||||
- 问题域：AI Agent 在叙事理论和故事结构分析领域的专业化应用
|
||||
- 方法/机制：基于经典叙事理论框架（Propp、Campbell、McKee、Genette 等）提供结构化故事分析
|
||||
- 结论/价值：为 The Agency 项目提供专业的叙事理论支撑，可应用于游戏叙事、交互式小说、影视剧本等领域
|
||||
|
||||
## Key Claims
|
||||
- Narratologist Agent 是资深叙事理论家和故事结构分析师，以工程师拆解系统的方式剖析故事
|
||||
- 叙事问题通常存在于讲述层面（sjuzhet）而非故事层面（fabula）
|
||||
- 每个建议必须基于至少一个命名理论框架并附带推理过程
|
||||
- 角色弧线必须包含 want/need/lie/transformation 四个检查点
|
||||
|
||||
## Key Quotes
|
||||
> "You dissect stories the way an engineer dissects systems — finding the load-bearing structures, the stress points, the elegant solutions." — Narratologist 身份定位
|
||||
|
||||
> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 诊断方法论核心原则
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Propp 叙事形态学]]：Vladimir Propp 的民间故事形态分析，识别 31 种叙事功能
|
||||
- [[Campbell 英雄之旅]]：Joseph Campbell 的单一神话理论，英雄经历分离、启蒙、回归三阶段
|
||||
- [[McKee 故事结构]]：Robert McKee 的三幕结构和对白写作理论
|
||||
- [[Genette 叙事学]]：Gérard Genette 的叙事话语分析，聚焦视点、时间和叙事层次
|
||||
- [[Barthes 五代码]]：Roland Barthes 的叙事符号学，五个意义生成代码
|
||||
- [[Vogler 作家旅程]]：Christopher Vogler 基于 Campbell 的编剧框架
|
||||
- [[Todorov 均衡模型]]：Tzvetan Todorov 的叙事 equilibrium-disruption-return 结构
|
||||
- [[三幕结构]]：传统戏剧结构（Setup-Confrontation-Resolution）
|
||||
- [[英雄之旅]]：见 [[Campbell 英雄之旅]]
|
||||
- [[角色弧线]]：角色从初始状态到转变的完整发展轨迹
|
||||
- [[Want vs Need]]：角色外在目标与内在需求的张力结构
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，Narratologist 所属项目
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Narratologist]] ← 专业领域 ← [[The Agency]]
|
||||
- [[Story Structure Analysis]] ← 依赖 ← [[Narratologist]]
|
||||
- [[Character Arc Assessment]] ← 依赖 ← [[Narratologist]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 暂无已知冲突
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: "Academic Psychologist Agent Personality"
|
||||
type: source
|
||||
tags: [agent, personality, psychology, the-agency, academic]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-psychologist.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 项目中的临床与研究心理学家人格定义，为 AI Agent 提供心理学分析框架
|
||||
- 问题域：人格评估、动机分析、创伤反应、群体动力学、认知行为模式
|
||||
- 方法/机制：基于 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲识别、社会心理学经典实验
|
||||
- 结论/价值：提供可交叉引用的多理论心理学分析范式，避免过度诊断，强调文化语境与研究局限性
|
||||
|
||||
## Key Claims
|
||||
- Big Five 人格框架是分析角色心理的核心模型：开放性、尽责性、外向性、宜人性、神经质
|
||||
- 依恋理论（Secure / Anxious-Preoccupied / Dismissive-Avoidant / Fearful-Avoidant）适用于浪漫、家庭、友谊等多种关系分析
|
||||
- 防御机制遵循 Vaillant 层级结构：自恋性防御→不成熟防御→神经质防御→成熟防御
|
||||
- Karpman 戏剧三角（迫害者→受害者→拯救者）可映射人际冲突动态
|
||||
- 创伤反应多样：警惕过度、讨好型、隔离型、退缩型，避免"悲伤过往=破碎角色"的刻板印象
|
||||
- 认知扭曲识别基于 Beck 框架：非黑即白思维、过度概括、灾难化等
|
||||
- 群体心理学：Milgram 服从实验、Zimbardo 斯坦福监狱实验、Asch 从众实验及其现代批判
|
||||
- 群体思维（Groupthink，Janis）威胁理性决策
|
||||
- 社会认同理论（Tajfel）解释群体内/外偏见的心理根源
|
||||
- 文化心理学：Markus & Kitayama 独立/互依自我观，Hofstede 文化维度理论
|
||||
|
||||
## Key Quotes
|
||||
> "Never reduce characters to diagnoses. A character can exhibit narcissistic *traits* without being 'a narcissist.' People are not their DSM codes."
|
||||
> — Academic Psychologist Agent
|
||||
|
||||
> "Distinguish between **pop psychology** and **research-backed psychology**. If you cite something, know whether it's peer-reviewed or self-help."
|
||||
> — Academic Psychologist Agent
|
||||
|
||||
## Key Concepts
|
||||
- [[Big Five 人格框架]]：开放性、尽责性、外向性、宜人性、神经质五维度人格模型
|
||||
- [[依恋理论]]：Bowlby 提出的亲子关系心理模型，四种成人依恋风格
|
||||
- [[Vaillant 防御机制层级]]：成熟防御、神经质防御、不成熟防御、自恋性防御的层级结构
|
||||
- [[Karpman 戏剧三角]]：迫害者→受害者→拯救者的三角人际冲突模式
|
||||
- [[认知扭曲]]：Beck 识别的非理性思维模式，如非黑即白、灾难化思维
|
||||
- [[群体思维]]：Janis 描述的过度团结导致决策失误的群体心理现象
|
||||
- [[社会认同理论]]：Tajfel 解释群体偏见和内群体偏好的社会心理机制
|
||||
- [[PTSD]]：创伤后应激障碍，复杂创伤则涉及代际创伤
|
||||
- [[Porges 多迷走神经理论]]：理解创伤反应的神经生理学框架
|
||||
|
||||
## Key Entities
|
||||
- [[Erik Erikson]]：发展心理学家，提出心理社会发展阶段理论
|
||||
- [[Jean Piaget]]：认知发展心理学家，提出的儿童认知发展阶段
|
||||
- [[John Bowlby]]：依恋理论创始人
|
||||
- [[Aaron Beck]]：认知行为疗法创始人，提出认知扭曲分类
|
||||
- [[George Vaillant]]：防御机制层级研究者
|
||||
- [[Stephen Karpman]]：戏剧三角理论提出者
|
||||
- [[Stanley Milgram]]：服从权威实验研究者
|
||||
- [[Philip Zimbardo]]：斯坦福监狱实验研究者
|
||||
- [[Solomon Asch]]：从众实验研究者
|
||||
- [[Irving Janis]]：群体思维概念提出者
|
||||
- [[Henri Tajfel]]：社会认同理论创始人
|
||||
- [[Bessel van der Kolk]]：创伤研究专家，《身体从未忘记》作者
|
||||
- [[Judith Herman]]：复杂创伤和复原力研究专家
|
||||
- [[Stephen Porges]]：多迷走神经理论提出者
|
||||
- [[Hofstede]]：文化维度理论提出者
|
||||
- [[Markus & Kitayama]]：独立/互依自我文化心理学研究者
|
||||
|
||||
## Connections
|
||||
- [[Big Five 人格框架]] ← 分析框架 ← [[Academic Psychologist Agent]]
|
||||
- [[依恋理论]] ← 分析框架 ← [[Academic Psychologist Agent]]
|
||||
- [[Karpman 戏剧三角]] ← 分析工具 ← [[Academic Psychologist Agent]]
|
||||
- [[认知扭曲]] ← 分析工具 ← [[Academic Psychologist Agent]]
|
||||
- [[Academic Psychologist Agent]] ← 协作 ← [[The Agency]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突记录
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Accounts Payable Agent"
|
||||
type: source
|
||||
tags: [agent, finance, payments, automation]
|
||||
date: 2026-04-20
|
||||
last_updated: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/specialized/accounts-payable-agent.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/accounts-payable-agent.md]]
|
||||
|
||||
## Summary
|
||||
- Accounts Payable Agent 是 The Agency 体系中的支付与应付账款专家，负责处理供应商发票、承包商付款与周期性账单，并可在 ACH、Wire、Crypto、Stablecoin 与 Payment API 等多种 payment rail 间自动路由。
|
||||
- 该智能体的核心原则是幂等性、严格验证、完整审计与不重复付款，任何超过授权阈值的付款都会被升级处理。
|
||||
- 它强调与其他智能体协作，在收到付款请求后完成验证、执行、记录并通知请求方。
|
||||
|
||||
## Key Claims
|
||||
- 付款前必须检查同一发票是否已经支付，避免重复付款
|
||||
- 50 美元以上的付款必须先验证收款方地址或账户
|
||||
- 任何付款都需要记录发票编号、金额、rail、时间戳和状态
|
||||
- 若某条 payment rail 失败，应尝试下一条可用 rail，再决定是否升级
|
||||
- 超出授权限额的付款必须交由人工审批
|
||||
|
||||
## Key Quotes
|
||||
> "Idempotency first" — 付款安全的首要规则
|
||||
> "Never pay twice" — 防止重复付款的核心约束
|
||||
> "Audit everything" — 每笔付款都必须留下完整审计轨迹
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] — 该智能体所属的项目框架
|
||||
- [[Idempotent Operation]] — 重复执行也不应产生重复付款
|
||||
- [[Audit Trail]] — 每笔付款必须可追踪、可审计
|
||||
- [[Payment Rail]] — 选择最优支付通道完成结算
|
||||
- [[Spend Limit]] — 超过授权阈值时必须升级审批
|
||||
- [[Labor Law Compliance]] — 付款协作场景中可能涉及合规约束
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: "Examples (Agency Agents)"
|
||||
type: source
|
||||
tags: [agency-agents, multi-agent, examples]
|
||||
date: 2026-04-21
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/examples/README.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Agency Agents 多智能体编排示例集
|
||||
- 问题域：展示多个专业智能体并行协作的实际效果
|
||||
- 方法/机制：8 个专业智能体同时部署，在产品发现任务中协同工作
|
||||
- 结论/价值：证明全量智能体编排可产生连贯、相互引用的计划
|
||||
|
||||
## Key Claims
|
||||
- 多智能体并行执行可产生连贯、交叉引用的计划，无协调开销
|
||||
- 从"发现机会"到"完整蓝图"可在单次会话中完成
|
||||
- 智能体编排展示了对复杂任务的端到端处理能力
|
||||
|
||||
## Key Quotes
|
||||
> "What does it actually look like when the full agency collaborates?" — 展示多智能体协作的核心问题
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Agent Team]]：多智能体团队，每个智能体有独立角色、人格和优化模型
|
||||
- [[Agents Orchestrator]]：智能体编排器，负责任务分配和流程协调
|
||||
- [[并行智能体执行]]：多个智能体同时工作于不同子任务
|
||||
|
||||
## Key Entities
|
||||
- [[Product Trend Researcher]]：市场验证与竞争格局分析
|
||||
- [[Backend Architect]]：系统架构、数据模型、API 设计
|
||||
- [[Brand Guardian]]：品牌定位与视觉识别
|
||||
- [[Growth Hacker]]：GTM 策略与增长计划
|
||||
- [[Support Responder]]：客户支持运营蓝图
|
||||
- [[UX Researcher]]：用户画像与旅程地图
|
||||
- [[Project Shepherd]]：项目执行计划与风险管理
|
||||
- [[XR Interface Architect]]：空间界面架构规范
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← 定义了 ← [[多智能体系统可靠性]] 架构模式
|
||||
- [[Multi-Agent Team]] ← 实现于 ← [[nexus-spatial-discovery.md]] 示例
|
||||
|
||||
## Contradictions
|
||||
- 未发现与现有内容的冲突
|
||||
|
||||
## Notes
|
||||
- 本文档是示例索引，实际详细案例在 nexus-spatial-discovery.md
|
||||
- 8 个智能体并行工作的成功案例，展示了多智能体系统的实际应用价值
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: "The Agency: AI Specialists Ready to Transform Your Workflow"
|
||||
type: source
|
||||
tags: [ai-agent, open-source, multi-agent]
|
||||
date: 2025-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/README.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 开源 AI 智能体集合项目，提供 144+ 个跨 12 个部门的专业化 AI Agent
|
||||
- 问题域：AI Agent 缺乏标准化设计和多工具集成方案
|
||||
- 方法/机制：通过预定义 Agent 模板（身份、使命、交付物、工作流、成功指标）实现专业化，每个 Agent 具备鲜明个性、明确交付物、验证工作流和学习记忆
|
||||
- 结论/价值：提供可直接使用的多工具集成方案，覆盖开发、设计、媒体、销售、营销、产品、项目管理、测试、支持、空间计算、游戏开发、学术研究等领域
|
||||
|
||||
## Key Claims
|
||||
- The Agency 提供 144+ 专业 AI Agent，跨越 12 个部门
|
||||
- 每个 Agent 具备鲜明个性、明确交付物、成功指标、经过验证的工作流、学习记忆和真实场景测试
|
||||
- 支持 Claude Code、GitHub Copilot、Cursor、Windsurf、OpenCode、OpenClaw 等 11 种 AI 工具
|
||||
- Agent 设计遵循五大原则：强个性、清晰交付物、成功指标、验证工作流、学习记忆
|
||||
|
||||
## Key Quotes
|
||||
> "Think of it as: Assembling your dream team, except they're AI specialists who never sleep, never complain, and always deliver." — 项目定位
|
||||
|
||||
> "I don't just test your code - I default to finding 3-5 issues and require visual proof for everything." — Evidence Collector
|
||||
|
||||
> "You're not marketing on Reddit - you're becoming a valued community member who happens to represent a brand." — Reddit Community Builder
|
||||
|
||||
## Key Concepts
|
||||
- [[智能体设计规范]]：Agent 文件结构、身份与记忆、核心使命、技术交付物、工作流程的完整定义
|
||||
- [[智能体设计原则]]：五大设计原则（鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆）
|
||||
- [[Multi-Agent Team]]：多 Agent 协作架构，每个 Agent 有独立角色、人格、优化的模型
|
||||
- [[MCP Builder]]：Model Context Protocol 服务器构建者，扩展 AI Agent 能力
|
||||
|
||||
## Key Entities
|
||||
- [[msitarzewski]]：GitHub 项目作者，The Agency 发起者
|
||||
- [[Claude Code]]：原生支持 .md 格式 Agent 的 AI 编程工具
|
||||
- [[Cursor]]：通过 .cursor/rules 集成 Agent 的 IDE
|
||||
- [[Windsurf]]：通过 .windsurfrules 集成 Agent 的 AI IDE
|
||||
|
||||
## Connections
|
||||
- [[AI智能体]] ← extends ← The Agency
|
||||
- [[OpenClaw]] ← integrates_with ← The Agency（通过 SOUL.md + AGENTS.md + IDENTITY.md）
|
||||
- [[Multi-Agent Team]] ← uses_pattern ← The Agency（层级结构、共识投票等架构）
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Agent 部门分类
|
||||
- Engineering Division（24 个）：前端、后端、移动端、AI、DevOps、安全等
|
||||
- Design Division（7 个）：UI、UX、品牌、图像提示词等
|
||||
- Paid Media Division（7 个）：PPC、搜索分析、广告审计等
|
||||
- Sales Division（8 个）：外呼、发现、交易策略、销售工程等
|
||||
- Marketing Division（22 个）：增长、内容、社交媒体、SEO 等
|
||||
- Product Division（5 个）： sprint 优先级、趋势研究、反馈综合等
|
||||
- Project Management Division（6 个）：制片、项目协调、实验追踪等
|
||||
- Testing Division（8 个）：证据收集、现实检查、性能基准等
|
||||
- Support Division（6 个）：支持响应、分析、财务等
|
||||
- Spatial Computing Division（6 个）：XR、visionOS、终端集成等
|
||||
- Specialized Division（26 个）：MCP 构建者、合规审计、销售自动化等
|
||||
- Game Development Division（17 个）：跨引擎、Unity、Unreal、Godot、Blender、Roblox
|
||||
- Academic Division（5 个）：人类学家、地理学家、历史学家等
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Agentic Identity & Trust Architect"
|
||||
type: source
|
||||
tags: [agent, the-agency, identity, trust, security, zero-trust, audit]
|
||||
date: 2026-04-20
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/agentic-identity-trust.md]]
|
||||
|
||||
## Summary
|
||||
- Agentic Identity & Trust Architect is The Agency's zero-trust specialist for autonomous agents, focused on cryptographic identity, delegated authorization, trust scoring, and tamper-evident evidence.
|
||||
- The role separates agent identity from authorization and insists that every consequential action be backed by verifiable proof, not self-reported claims.
|
||||
- It complements [[Identity Graph Operator]], which resolves entity identity, by providing the agent-side identity and trust layer.
|
||||
|
||||
## Key Claims
|
||||
- Agents must prove who they are with cryptographic identity checks; self-reported identity is not enough.
|
||||
- Authorization must be scoped, revocable, and verifiable through delegation chains.
|
||||
- Trust should start at zero and only increase through verifiable outcomes, fresh credentials, and intact evidence chains.
|
||||
- Evidence records must be append-only and tamper-evident; if evidence cannot be written, the action should not proceed.
|
||||
- Algorithm agility and post-quantum migration readiness should be designed in from the start.
|
||||
|
||||
## Key Quotes
|
||||
> "Never trust self-reported identity." — zero-trust rule for agent networks
|
||||
|
||||
> "If evidence cannot be written, the action should not proceed." — fail-closed authorization rule
|
||||
|
||||
## Key Concepts
|
||||
- [[Identity Governance]]
|
||||
- [[Audit Trail]]
|
||||
- [[Zero Trust Access]]
|
||||
- [[Identity Graph Operator]]
|
||||
- [[The Agency]]
|
||||
|
||||
## Key Entities
|
||||
- [[Agentic Identity & Trust Architect]]
|
||||
- [[Identity Graph Operator]]
|
||||
- [[The Agency]]
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Agentic Identity & Trust Architect]]
|
||||
- [[Agentic Identity & Trust Architect]] ← complements ← [[Identity Graph Operator]]
|
||||
- [[Identity Governance]] ← informed_by ← [[Agentic Identity & Trust Architect]]
|
||||
- [[Audit Trail]] ← constrains ← [[Agentic Identity & Trust Architect]]
|
||||
|
||||
## Contradictions
|
||||
- None noted
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
title: "Agents Orchestrator"
|
||||
type: source
|
||||
tags: [agent, pipeline, autonomous-workflow, the-agency]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/agents-orchestrator.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 项目中的 Agents Orchestrator 智能体，负责从规格文件到生产部署的完整开发流水线编排
|
||||
- 问题域：多智能体协作质量控制、项目状态跟踪、自主决策流水线执行
|
||||
- 方法/机制：四阶段流水线（PM → ArchitectUX → Dev-QA Loop → Integration）、质量门禁强制、任务级 QA 验证循环
|
||||
- 结论/价值：实现端到端开发流程自主化，通过持续质量循环确保交付质量
|
||||
|
||||
## Key Claims
|
||||
- Agents Orchestrator 通过单一初始命令驱动完整开发流水线（PM → ArchitectUX → Dev-QA Loop → Integration）
|
||||
- 每个任务必须通过 QA 验证才能进入下一任务，质量门禁不可绕过
|
||||
- 失败任务最多重试 3 次，超过则升级处理
|
||||
- Dev-QA 循环是核心机制：开发实现 → QA 截图验证 → PASS/FAIL 决策 → 循环或前进
|
||||
|
||||
## Key Quotes
|
||||
> "You are **AgentsOrchestrator**, the autonomous pipeline manager who runs complete development workflows from specification to production-ready implementation." — Agents Orchestrator 身份定义
|
||||
> "Maximum 3 attempts per task before escalation" — 重试限制策略
|
||||
> "No phase advancement without meeting quality standards" — 质量门禁强制要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Quality Gate（质量门禁）]]：每个阶段必须满足质量标准才能前进的机制
|
||||
- [[Dev-QA Loop（开发-QA 循环）]]：实现 → QA 验证 → 反馈 → 改进的持续循环
|
||||
- [[Pipeline Orchestration（流水线编排）]]：协调多个智能体完成复杂工作流的机制
|
||||
- [[Multi-Agent Coordination（多智能体协作）]]：多个专业化 Agent 协同工作的架构模式
|
||||
- [[EvidenceQA]]：截图驱动的 QA 智能体，要求视觉证据进行验证
|
||||
|
||||
## Key Entities
|
||||
- [[Agents Orchestrator]]：主编排器，负责驱动完整开发流水线
|
||||
- [[Project Manager Senior]]：第一阶段生成任务清单的智能体
|
||||
- [[ArchitectUX]]：第二阶段创建技术架构和 UX 基础的智能体
|
||||
- [[EvidenceQA]]：第三阶段进行截图驱动 QA 验证的智能体
|
||||
- [[Testing Reality Checker]]：第四阶段进行最终集成测试的智能体
|
||||
- [[Senior Project Manager]]：任务清单转换智能体，将规格文件转化为可执行任务列表
|
||||
|
||||
## Connections
|
||||
- [[Project Manager Senior]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[ArchitectUX]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[EvidenceQA]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[Testing Reality Checker]] ← spawns ← [[Agents Orchestrator]]
|
||||
- [[Frontend Developer]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[Backend Architect]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[DevOps Automator]] ← coordinates_with ← [[Agents Orchestrator]]
|
||||
- [[Quality Gate（质量门禁）]] ← enforces ← [[Dev-QA Loop（开发-QA 循环）]]
|
||||
- [[Multi-Agent Coordination（多智能体协作）]] ← implements ← [[Pipeline Orchestration（流水线编排）]]
|
||||
|
||||
## Contradictions
|
||||
- 与单体智能体执行模式冲突：[[Agents Orchestrator]] 强调多智能体分层协作和质量循环，单体模式倾向于单一智能体完成所有任务
|
||||
- 冲突点：任务分配与质量控制方式
|
||||
- 当前观点：多智能体专业化分工 + QA 验证循环
|
||||
- 对方观点：单一智能体端到端执行减少交接开销
|
||||
|
||||
## Workflow Phases
|
||||
|
||||
### Phase 1: Project Analysis & Planning
|
||||
1. 验证项目规格文件存在
|
||||
2. Spawn project-manager-senior 创建任务清单
|
||||
3. 验证任务清单生成
|
||||
|
||||
### Phase 2: Technical Architecture
|
||||
1. 验证任务清单存在
|
||||
2. Spawn ArchitectUX 创建技术架构
|
||||
3. 验证架构交付物
|
||||
|
||||
### Phase 3: Development-QA Continuous Loop
|
||||
1. 读取任务清单理解范围
|
||||
2. 对每个任务运行 Dev-QA 循环直到 PASS
|
||||
3. 任务失败最多重试 3 次
|
||||
|
||||
### Phase 4: Final Integration & Validation
|
||||
1. 所有任务通过 QA 后执行
|
||||
2. Spawn testing-reality-checker 进行最终集成测试
|
||||
3. 评估生产就绪状态
|
||||
|
||||
## Quality Enforcement Rules
|
||||
- **No shortcuts**：每个任务必须通过 QA 验证
|
||||
- **Evidence required**：所有决策基于实际智能体输出和证据
|
||||
- **Retry limits**：每个任务最多 3 次重试
|
||||
- **Clear handoffs**：每个智能体获得完整上下文和具体指令
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "可自动化、可扩展、AI增强的电商数据采集与处理系统"
|
||||
type: source
|
||||
tags: [电商, 数据采集, 自动化, AI, n8n, Scrapy, Playwright]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：基于 Docker + Ubuntu + n8n 的电商数据采集与处理系统设计
|
||||
- 问题域：电商网站产品信息自动化采集、清洗、AI处理与可视化
|
||||
- 方法/机制：Scrapy + Playwright 爬虫层 → n8n 自动化管道 → LLM AI处理 → PostgreSQL/Grafana 存储展示
|
||||
- 结论/价值：构建可自动化、可扩展的电商数据管线，支持定时采集、AI摘要分类、异常检测、报告通知
|
||||
|
||||
## Key Claims
|
||||
- Scrapy + Playwright 组合适合电商爬虫（静态抓取+动态渲染）
|
||||
- n8n 可通过 workflow 实现全管线自动化
|
||||
- Ollama 本地模型可替代外部 API 进行离线 AI 处理
|
||||
- 分布式调度可用 Scrapyd 或 Archetype 实现扩展
|
||||
|
||||
## Key Quotes
|
||||
> "你想要的是一个可自动化、可扩展、AI增强的数据采集与处理系统，基于 Docker + Ubuntu + n8n 搭建。" — 原文开头
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrapy]]：Python 爬虫框架，适合静态页面和结构化抓取
|
||||
- [[Playwright]]：Microsoft 浏览器自动化工具，支持动态页面渲染
|
||||
- [[n8n]]：开源工作流自动化工具，可编排爬虫、AI处理、数据存储
|
||||
- [[Ollama]]：本地 LLM 运行环境，支持离线 AI 处理
|
||||
- [[Docker Compose]]：多容器编排工具，定义爬虫服务架构
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台
|
||||
- [[PostgreSQL]]：关系型数据库
|
||||
- [[Grafana]]：数据可视化工具
|
||||
- [[MinIO]]：S3 兼容对象存储
|
||||
- [[FastAPI]]：Python Web 框架，可作为服务层暴露 API
|
||||
|
||||
## Connections
|
||||
- [[Scrapy]] ← depends_on ← [[Playwright]]
|
||||
- [[n8n]] ← orchestrates ← [[Scrapy]]
|
||||
- [[n8n]] ← calls ← [[Ollama]]
|
||||
- [[PostgreSQL]] ← stores ← AI处理结果
|
||||
- [[Grafana]] ← visualizes ← PostgreSQL数据
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: ai-powered-earnings-tracker
|
||||
title: AI-Powered Earnings Tracker
|
||||
type: source
|
||||
tags: [AI Agent, Workflow, Automation, Telegram]
|
||||
sources: [raw/Agent/usecases/earnings-tracker.md]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/earnings-tracker.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent 自动追踪科技公司财报的工作流
|
||||
- 问题域：多公司财报日期追踪、信息汇总、自动化提醒
|
||||
- 方法/机制：Cron Jobs + Web Search + Telegram 消息推送
|
||||
- 结论/价值：自动化财报追踪，节省手动查阅时间
|
||||
|
||||
## Key Claims
|
||||
- OpenClaw 通过 cron job 实现每周自动扫描财报日历并推送相关公司列表
|
||||
- 用户确认后，OpenClaw 为每个财报日期安排一次性定时任务
|
||||
- 财报发布后，OpenClaw 自动搜索结果并格式化汇总（beat/miss、关键指标、AI 亮点）
|
||||
|
||||
## Key Quotes
|
||||
> "Following earnings season across dozens of tech companies means checking multiple sources and remembering report dates."
|
||||
|
||||
## Key Concepts
|
||||
- [[Cron Jobs]]：定时任务机制，OpenClaw 用于自动化执行重复性工作
|
||||
- [[工作流自动化]]：预定义自动化流程，与 AI Agent 互补实现自动化追踪
|
||||
- [[上下文记忆]]：OpenClaw 记住用户通常关注的公司，自动建议
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，支持 cron job 和 Telegram 集成
|
||||
|
||||
## Connections
|
||||
- [[AI-Powered Earnings Tracker]] ← uses ← [[Cron Jobs]]
|
||||
- [[AI-Powered Earnings Tracker]] ← uses ← [[OpenClaw]]
|
||||
- [[AI-Powered Earnings Tracker]] ← delivers_to ← [[Telegram]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Aider Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, aider]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/aider/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
This README documents how to integrate The Agency agents with Aider. It explains that the project's CONVENTIONS.md consolidates the roster, shows install/activate commands, notes manual usage with `aider --read CONVENTIONS.md`, and how to regenerate artifacts via `./scripts/convert.sh --tool aider`.
|
||||
|
||||
## Key Claims
|
||||
- The Agency roster can be consolidated into a single `CONVENTIONS.md` file which Aider reads automatically when present.
|
||||
- Installation uses the repository's `./scripts/install.sh --tool aider` script run from the project root.
|
||||
- Agents can be referenced by name inside an Aider session to activate behavior (e.g., "Use the Frontend Developer agent...").
|
||||
- Manual reading of the conventions file is supported via `aider --read CONVENTIONS.md`.
|
||||
- Generated artifacts for Aider can be produced with `./scripts/convert.sh --tool aider`.
|
||||
|
||||
## Key Quotes
|
||||
> "Aider reads this file automatically when it's present in your project root." — Aider Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — the conventions file consolidates the roster of agents from this project
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/aionui-cowork-desktop.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AionUi 桌面端协同工作界面 + OpenClaw 远程救援与多 Agent 管理
|
||||
- 问题域：CLI Agent 可视化、远程运维、跨设备访问
|
||||
- 方法/机制：桌面端 Cowork UI、内置 OpenClaw 部署专家、WebUI/Telegram 远程访问、多 Agent 并行运行
|
||||
- 结论/价值：解决 CLI Agent 不可见性问题，提供远程故障恢复能力，统一多 Agent 管理
|
||||
|
||||
## Key Claims
|
||||
- AionUi 让 OpenClaw 以一等公民身份运行在桌面协同工作空间，可视化文件读写、命令执行、网页浏览
|
||||
- 内置 OpenClaw 部署专家可远程执行 openclaw doctor 诊断和修复，解决远程运维痛点
|
||||
- MCP 服务器只需在 AionUi 中配置一次，即可在 OpenClaw 及所有其他 Agent 间同步
|
||||
- 支持通过 WebUI、Telegram、Lark、DingTalk 从任意设备远程访问同一个 AionUi 实例
|
||||
|
||||
## Key Quotes
|
||||
> "Use OpenClaw from a desktop Cowork UI, access it from Telegram or WebUI when you're away, and fix it remotely when it won't connect." — AionUi 核心价值主张
|
||||
|
||||
> "A common pattern for users who run OpenClaw headless or on another machine." — 远程救援典型使用场景
|
||||
|
||||
## Key Concepts
|
||||
- [[Cowork UI]]：桌面端协同工作界面，可视化 Agent 操作
|
||||
- [[OpenClaw 部署专家]]：AionUi 内置的 OpenClaw 安装、诊断、修复助手
|
||||
- [[Remote Rescue]]：通过远程渠道（WebUI/Telegram）执行 openclaw doctor 进行故障恢复
|
||||
- [[MCP 同步]]：MCP 服务器一次配置，所有 Agent 共享
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，在 AionUi 中以一等公民身份运行
|
||||
- [[AionUi]]：免费开源桌面应用，支持 12+ AI Agent（Claude Code、Codex、Qwen Code 等）
|
||||
- [[iOfficeAI]]：AionUi 开发者/维护者
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← works_with ← [[AionUi]]
|
||||
- [[AionUi]] ← includes ← [[OpenClaw 部署专家]]
|
||||
- [[OpenClaw]] ← can_be_rescued_by ← [[OpenClaw 部署专家]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Antigravity Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, antigravity]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/antigravity/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Antigravity Integration README documents installing the Agency roster as Antigravity skills under `~/.gemini/antigravity/skills/`. Each agent is prefixed with `agency-` to avoid name conflicts. It covers install, activation by slug, regeneration steps, and the `SKILL.md` frontmatter format.
|
||||
|
||||
## Key Claims
|
||||
- Agents install as Antigravity skills and are prefixed `agency-` to prevent conflicts.
|
||||
- Install via `./scripts/install.sh --tool antigravity`, which copies files to `~/.gemini/antigravity/skills/`.
|
||||
- Activate skills by their slug (e.g., `agency-frontend-developer`).
|
||||
|
||||
## Key Quotes
|
||||
> "Installs the full Agency roster as Antigravity skills. Each agent is prefixed with `agency-` to avoid conflicts with existing skills." — Antigravity Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — roster source
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "arXiv Paper Reader"
|
||||
type: source
|
||||
tags: [agent, usecase, research]
|
||||
date: 2025-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/arxiv-paper-reader.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent 辅助学术论文阅读工作流
|
||||
- 问题域：arXiv 论文获取、解析和交互式阅读
|
||||
- 方法/机制：通过 arxiv-reader skill 实现无工具调用 API 直接读取 arXiv 论文，包含 arxiv_fetch、arxiv_sections、arxiv_abstract 三个工具
|
||||
- 结论/价值：将 AI Agent 转变为研究阅读助手，支持摘要速览、章节浏览、跨论文对比和深度分析
|
||||
|
||||
## Key Claims
|
||||
- arxiv-reader skill 可直接下载 PDF 并将 LaTeX 源码自动扁平化，无需手动解析
|
||||
- 通过章节浏览（arxiv_sections）可先决定阅读范围，避免一次性加载全文
|
||||
- 本地缓存机制使重复访问秒级响应
|
||||
- 支持多论文批量摘要对比，辅助阅读优先级排序
|
||||
|
||||
## Key Quotes
|
||||
> "Reading arXiv papers means downloading PDFs, losing context when switching between papers, and struggling to parse dense LaTeX notation." — 原始问题陈述
|
||||
|
||||
> "This workflow turns your agent into a research reading assistant" — 解决方案定位
|
||||
|
||||
## Key Concepts
|
||||
- [[arxiv-reader skill]]
|
||||
- [[LaTeX 扁平化]]
|
||||
- [[本地缓存]]
|
||||
|
||||
## Key Entities
|
||||
- [[Prismer]] — arxiv-reader skill 的提供方，GitHub 仓库维护者
|
||||
- [[OpenClaw]] — 可运行 agent skill 的 AI Agent 管理工具
|
||||
|
||||
## Connections
|
||||
- [[Prismer]] ← provides → [[arxiv-reader skill]]
|
||||
- [[arxiv-reader skill]] ← enables → [[arXiv Paper Reader]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统的本地 PDF 阅读器对比：
|
||||
- 冲突点：是否需要在本地保存文件
|
||||
- 当前观点：通过 agent 交互获取，无需手动下载和管理文件
|
||||
- 对方观点：本地保存便于离线阅读和标注
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
title: "Automation Governance Architect"
|
||||
type: source
|
||||
tags: [agent, automation, governance, n8n]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/automation-governance-architect.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：自动化治理架构师，负责评估、审批和标准化业务自动化工作流
|
||||
- 问题域：防止低价值或不安全的自动化实施，确保自动化投资回报
|
||||
- 方法/机制：n8n 为主要编排工具的治理框架，包含决策框架、审批 verdicts、标准化工作流结构
|
||||
- 结论/价值：通过 Governance-first 方法提升自动化质量、可靠性和可维护性
|
||||
|
||||
## Key Claims
|
||||
- 决策必须基于价值而非技术可行性
|
||||
- 每个推荐必须包含 fallback 和 ownership
|
||||
- 无文档和测试证据不得标记为"done"
|
||||
- 简单健壮优于巧妙脆弱
|
||||
|
||||
## Key Quotes
|
||||
> "Do not approve automation only because it is technically possible." — 核心原则
|
||||
> "No 'done' status without documentation and test evidence." — 完成标准
|
||||
> "Every recommendation must include fallback and ownership." — 责任要求
|
||||
|
||||
## Key Concepts
|
||||
- [[n8n]]：主要编排工具，n8n-mcp 提供 543 个节点访问能力
|
||||
- [[ITSM（IT 服务管理）]]：自动化的服务治理背景
|
||||
- [[Task Automation]]：任务自动化机制
|
||||
- [[智能体工作流]]：以 n8n、Dify 为代表的工作流自动化平台
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，Automation Governance Architect 是其 specialized agents 之一
|
||||
|
||||
## Connections
|
||||
- [[n8n-mcp]] ← 使用 ← [[Automation Governance Architect]]
|
||||
- [[Task Automation]] ← 治理对象 ← [[Automation Governance Architect]]
|
||||
- [[ITSM（IT 服务管理）]] ← 隶属于 ← [[Automation Governance Architect]]
|
||||
|
||||
## Decision Framework（决策框架）
|
||||
|
||||
### 评估维度
|
||||
1. **Time Savings Per Month**：月度时间节省，是否 recurring 和 material
|
||||
2. **Data Criticality**：数据关键性（客户、财务、合同、排程记录）
|
||||
3. **External Dependency Risk**：外部依赖风险（API/服务稳定性）
|
||||
4. **Scalability (1x to 100x)**：可扩展性，retries、deduplication、rate limits
|
||||
|
||||
### Verdicts（审批结论）
|
||||
- **APPROVE**：强价值、风险可控、架构可维护
|
||||
- **APPROVE AS PILOT**：价值 plausibly 但需限制 rollout
|
||||
- **PARTIAL AUTOMATION ONLY**：仅自动化安全段，保留人工 checkpoint
|
||||
- **DEFER**：流程不成熟、价值不明确、依赖不稳定
|
||||
- **REJECT**：经济性弱或运营/合规风险不可接受
|
||||
|
||||
## n8n Workflow Standard（工作流标准）
|
||||
|
||||
10 段结构：Trigger → Input Validation → Data Normalization → Business Logic → External Actions → Result Validation → Logging/Audit Trail → Error Branch → Fallback/Manual Recovery → Completion/Status Writeback
|
||||
|
||||
### Naming Convention
|
||||
`[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`
|
||||
例如：`PROD-CRM-LeadIntake-CreateRecord-v1.0`
|
||||
|
||||
## Reliability Baseline（可靠性基线）
|
||||
- explicit error branches
|
||||
- idempotency 或 duplicate protection
|
||||
- safe retries (with stop conditions)
|
||||
- timeout handling
|
||||
- alerting/notification
|
||||
- manual fallback path
|
||||
|
||||
## Re-Audit Triggers（再审计触发条件）
|
||||
- APIs 或 schemas 变更
|
||||
- 错误率上升
|
||||
- volume 显著增加
|
||||
- 合规要求变更
|
||||
- 出现重复人工修复
|
||||
|
||||
## Contradictions
|
||||
- 尚未发现与现有内容的冲突
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
title: "Autonomous Educational Game Development Pipeline"
|
||||
type: source
|
||||
tags: [AI Agent, Game Development, Automation]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-game-dev-pipeline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent 自主管理教育游戏全生命周期的工作流
|
||||
- 问题域：儿童教育游戏自动化开发
|
||||
- 方法/机制：Game Developer Agent + "Bugs First" 策略 + Git 工作流自动化
|
||||
- 结论/价值：单人开发者实现 7 分钟产出 1 个游戏的高速迭代
|
||||
|
||||
## Key Claims
|
||||
- Game Developer Agent 能自主管理游戏开发全生命周期
|
||||
- "Bugs First" 策略确保修复优先于新功能开发
|
||||
- Round Robin 策略平衡不同年龄段游戏的内容分布
|
||||
- 7 分钟/游戏的高速迭代来自持续自动化和标准化流程
|
||||
|
||||
## Key Quotes
|
||||
> "The workflow enforces a 'Bugs First' policy where the agent must check for and resolve reported bugs before implementing new features." — 核心工作流规则
|
||||
|
||||
> "This pipeline is capable of producing 1 new game or bugfix every 7 minutes." — 效率数据
|
||||
|
||||
## Key Concepts
|
||||
- [[Game Developer Agent]]：自主管理游戏全生命周期的 AI Agent
|
||||
- [[Bugs First 策略]]：优先修复 bug 再开发新功能的工作流规则
|
||||
- [[Round Robin 策略]]：轮转分配任务，平衡内容类型的调度算法
|
||||
- [[Conventional Commits]]：标准化 Git 提交信息格式
|
||||
|
||||
## Key Entities
|
||||
- [[El Bebe Games]]：目标游戏门户项目
|
||||
- [[Susana]]：3 岁女儿
|
||||
- [[Julieta]]：即将出生的女儿
|
||||
- [[GitHub]]：代码托管平台
|
||||
|
||||
## Connections
|
||||
- [[El Bebe Games]] ← builds ← [[Game Developer Agent]]
|
||||
- [[Game Developer Agent]] ← follows ← [[Bugs First 策略]]
|
||||
- [[Game Developer Agent]] ← uses ← [[Round Robin 策略]]
|
||||
- [[Game Developer Agent]] ← deploys via ← Git
|
||||
|
||||
## Contradictions
|
||||
- （暂无冲突记录）
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Autonomous Project Management with Subagents"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
source_file: raw/Agent/usecases/autonomous-project-management.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-project-management.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：去中心化的多 Subagent 项目管理模式，通过共享 STATE.yaml 文件协调任务，避免中央 orchestrator 瓶颈
|
||||
- 问题域：复杂项目的多任务并行管理，传统 orchestrator 模式导致主 Agent 成为流量瓶颈
|
||||
- 方法/机制：基于共享状态文件的去中心化协调，主 Agent 采用"CEO 模式"仅做策略决策
|
||||
- 结论/价值：多个 Subagent 并行工作，通过状态文件自驱协调，主会话保持精简
|
||||
|
||||
## Key Claims
|
||||
- STATE.yaml 作为单一真相源，替代中央 orchestrator 实现去中心化协调
|
||||
- 主会话采用 CEO 模式，仅负责任务分配和状态检查，不参与具体执行
|
||||
- Subagent 通过读写共享状态文件实现自主协调，无需中央调度
|
||||
- Git 提交 STATE.yaml 变更实现完整审计追踪
|
||||
|
||||
## Key Quotes
|
||||
> "Decentralized coordination: Agents read/write to a shared STATE.yaml file" — 核心设计原则
|
||||
> "Main session stays thin (CEO pattern—strategy only)" — 主会话保持精简
|
||||
> "File-based coordination scales better than message-passing" — STATE.yaml 优于消息传递
|
||||
|
||||
## Key Concepts
|
||||
- [[去中心化协调]]：通过共享状态文件实现多 Agent 自主协调的模式
|
||||
- [[Subagent 管理]]：使用 sessions_spawn/sessions_send 管理子代理的技术
|
||||
- [[项目状态管理]]：基于 STATE.yaml 的任务追踪和协调机制
|
||||
- [[CEO 模式]]：主 Agent 仅做策略决策，不执行具体任务的架构模式
|
||||
|
||||
## Key Entities
|
||||
- [[Nicholas Carlini]]：自主编码 Agent 方案的提出者，启发了去中心化协调模式
|
||||
- [[OpenClaw]]：支持 Subagent 管理的 AI Agent 工具
|
||||
|
||||
## Connections
|
||||
- [[Project State Management System]] ← extends ← [[去中心化协调]]
|
||||
- [[Multi-Agent Team]] ← uses ← [[Subagent 管理]]
|
||||
- [[Shared Memory]] ← relates_to ← [[项目状态管理]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 Orchestrator 模式冲突：传统模式依赖中央调度，本模式强调去中心化自驱
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "Backend Architect (with Memory)"
|
||||
type: source
|
||||
tags: [agency, agent, backend, memory]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Backend Architect (with Memory) is a persona definition for a senior backend architect agent in The Agency. The page defines identity, core mission, rules, deliverables (architecture specs, database schemas, API designs), success metrics, advanced capabilities, and a Memory Integration section that instructs the agent to use MCP memory tools (remember, recall, rollback, search) to persist decisions and handoffs across sessions.
|
||||
|
||||
## Key Claims
|
||||
- The persona provides concrete architecture deliverables (system architecture spec, database schema SQL, API examples) and prescriptive rules emphasizing security, performance, and reliability.
|
||||
- The Memory Integration section instructs the agent to store decisions and deliverables using MCP memory tools, tag memories by agent and project, and use rollback to recover known-good states.
|
||||
- No code changes to agent files are required — the MCP tools provide persistence when configured in the client's MCP servers.
|
||||
|
||||
## Key Quotes
|
||||
> "Give any agent persistent memory across sessions using the Model Context Protocol (MCP)." — Integrations README header
|
||||
|
||||
## Connections
|
||||
- [[MCP Memory Integration]] — the Memory Integration pattern referenced by this persona
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — the primary roster of agents this persona belongs to
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "宝玉 Claude Code 技能集"
|
||||
type: source
|
||||
tags: [claude-code, baoyu, skills, openclaw, ai-tools]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/baoyu-skills-claude-code-技能集.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Code/AI Agent 技能集成的安装与使用方法
|
||||
- 问题域：内容生成、AI 图像生成、工具类自动化
|
||||
- 方法/机制：三大类 Skills 通过 npx/Plugin 市场安装，支持自定义扩展
|
||||
- 结论/价值：提供一站式 AI 辅助工作效率工具，涵盖图像生成、翻译、内容发布等场景
|
||||
|
||||
## Key Claims
|
||||
- 技能集包含三大类：内容技能、AI 生成技能、工具技能
|
||||
- 支持多种 AI 服务商：OpenAI、Google、Azure、MiniMax、通义万相等
|
||||
- 通过 npx/Plugin 市场灵活安装和更新
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Skills]]：写给 Claude 的"说明书"和 SOP
|
||||
- [[Agent Skill 设计模式]]：Google 发布的 5 种 Agent Skill 设计模式
|
||||
- [[Vibe Coding]]：AI 辅助开发方式，自然语言描述需求
|
||||
- [[EXTEND.md]]：自定义扩展文件的机制，允许用户覆盖默认设置
|
||||
|
||||
## Key Entities
|
||||
- [[baoyu]]：技能集作者，维护者
|
||||
- [[JimLiu]]：GitHub 仓库作者
|
||||
- [[ClawHub]]：技能发布和管理平台
|
||||
|
||||
## Connections
|
||||
- [[baoyu-skills-claude-code-技能集]] ← includes → [[内容技能]]
|
||||
- [[baoyu-skills-claude-code-技能集]] ← includes → [[AI生成技能]]
|
||||
- [[baoyu-skills-claude-code-技能集]] ← includes → [[工具技能]]
|
||||
- [[OpenClaw]] ← uses → [[baoyu-skills-claude-code-技能集]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "JimLiu/baoyu-skills"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/baoyu-skills.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Code 技能集，提供内容生成、AI 图像生成、日常效率工具
|
||||
- 问题域：AI 辅助内容创作、多平台发布、图像生成、文档转换
|
||||
- 方法/机制：基于 Claude Code 的 Skill 系统，通过 npx 命令调用各类技能
|
||||
- 结论/价值：为 Claude Code 用户提供开箱即用的 AI 创作和发布能力
|
||||
|
||||
## Key Claims
|
||||
- baoyu-skills 是宝玉分享的 Claude Code 技能集，可通过 `npx skills add jimliu/baoyu-skills` 快速安装
|
||||
- 技能分为内容技能、AI 生成技能、工具技能三大类，共 17+ 个技能
|
||||
- 支持多平台发布（X、微信、微博），支持多种图像生成服务商
|
||||
|
||||
## Key Quotes
|
||||
> "宝玉分享的 Claude Code 技能集，提升日常工作效率。" — 项目描述
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Code Skills]]：写给 Claude 的"说明书"，将反复执行的任务拆解为 AI 可稳定复用的流程
|
||||
- [[AI 图像生成]]：通过 baoyu-imagine 支持多种服务商（OpenAI、Google、MiniMax、Replicate 等）
|
||||
- [[内容发布自动化]]：通过 baoyu-post-to-x、baoyu-post-to-wechat、baoyu-post-to-weibo 实现多平台发布
|
||||
|
||||
## Key Entities
|
||||
- [[JimLiu]]：baoyu-skills 项目作者，宝玉
|
||||
- [[Claude Code]]：Anthropic 提供的 AI 编程 CLI 工具
|
||||
- [[ClawHub]]：OpenClaw 的插件市场
|
||||
|
||||
## Connections
|
||||
- [[baoyu-imagine]] ← generated_by ← [[Claude Code Skills]]
|
||||
- [[Claude Code Skills]] ← maintained_by ← [[JimLiu]]
|
||||
- [[baoyu-post-to-wechat]] ← requires ← [[微信公众号 API]]
|
||||
- [[baoyu-xhs-images]] ← generates ← [[小红书图片]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "Best 7 news API data feeds - AI News"
|
||||
type: source
|
||||
tags: []
|
||||
sources: ["raw/AI/Best 7 news API data feeds - AI News.md"]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Best 7 news API data feeds - AI News.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：主流新闻 API 数据源服务对比与选型指南
|
||||
- 问题域：开发者和企业如何获取结构化新闻数据
|
||||
- 方法/机制：聚合来自网站、博客、论坛、社交媒体的新闻数据，格式化为 JSON 或 XML
|
||||
- 结论/价值：7 款主流新闻 API 的功能、定价、适用场景对比
|
||||
|
||||
## Key Claims
|
||||
- Webz.io 是最全面的新闻 API，覆盖开放网、深网和暗网
|
||||
- GNews API 适合小型应用和初创公司的轻量级解决方案
|
||||
- The Guardian API 提供高质量编辑内容，适合需要可信来源的场景
|
||||
- Bloomberg API 专注金融数据，适合机构投资者
|
||||
- Financial Times API 提供高端商业和经济洞察
|
||||
- Opoint 擅长情绪分析和媒体监控
|
||||
- Mediastack 提供免费计划，适合各类规模企业
|
||||
|
||||
## Key Quotes
|
||||
> "News API data feeds are platforms that aggregate, organise, and deliver structured news data from multiple sources."
|
||||
|
||||
## Key Concepts
|
||||
- [[新闻 API 数据源]]：聚合、组织并交付来自多个来源的结构化新闻数据的服务平台
|
||||
- [[实时新闻数据]]：即时获取当前发生的新闻事件
|
||||
- [[历史新闻数据]]：访问过往新闻档案
|
||||
- [[情绪分析]]：分析新闻内容中的情感倾向
|
||||
|
||||
## Key Entities
|
||||
- [[Webz.io]]：综合性新闻 API，覆盖开放网、深网和暗网
|
||||
- [[GNews API]]：轻量级全球新闻聚合服务
|
||||
- [[The Guardian API]]：英国卫报官方 API
|
||||
- [[Bloomberg API]]：彭博金融数据服务
|
||||
- [[Financial Times API]]：金融时报官方 API
|
||||
- [[Opoint]]：媒体监控与情绪分析平台
|
||||
- [[Mediastack API]]：可扩展的新闻数据服务
|
||||
|
||||
## Connections
|
||||
- [[Webz.io]] ← provides ← [[新闻 API 数据源]]
|
||||
- [[GNews API]] ← provides ← [[新闻 API 数据源]]
|
||||
- [[Bloomberg API]] ← specializes_in ← [[金融情报]]
|
||||
- [[Opoint]] ← enables ← [[情绪分析]]
|
||||
|
||||
## Use Cases
|
||||
- **金融情报**：投资工具实时分析市场新闻
|
||||
- **媒体监控**：公关机构追踪品牌提及和情绪
|
||||
- **风险评估**：政府和公司评估地缘政治风险
|
||||
- **内容平台**：聚合器为应用/网站策划文章
|
||||
- **AI 与预测分析**：为机器学习模型提供趋势预测数据
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "为什么你的笔记总是乱糟糟？试试这个方法，彻底告别信息混乱！"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/为什么你的笔记总是乱糟糟？试试这个方法，彻底告别信息混乱！ 1.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：笔记整理与信息管理方法
|
||||
- 问题域：个人知识管理、信息混乱
|
||||
- 方法/机制：微信公众号文章分享的笔记整理方法
|
||||
- 结论/价值：帮助读者告别信息混乱
|
||||
|
||||
## Key Claims
|
||||
- 微信公众号「赫点茶」分享的笔记整理方法
|
||||
|
||||
## Key Quotes
|
||||
> "原创 赫点茶" — 文章出处
|
||||
|
||||
## Key Concepts
|
||||
- [[笔记整理]]：个人知识管理的基础
|
||||
|
||||
## Key Entities
|
||||
- [[赫点茶]]：微信公众号作者
|
||||
|
||||
## Connections
|
||||
- [[Obsidian]] ← 工具 ← [[笔记整理]]
|
||||
- [[Dataview]] ← 工具 ← [[笔记整理]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: "Blockchain Security Auditor"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/blockchain-security-auditor.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 项目中的智能合约安全审计专家智能体
|
||||
- 问题域：DeFi 协议和区块链应用的安全漏洞检测、形式化验证、漏洞利用分析
|
||||
- 方法/机制：结合自动化静态分析工具（Slither、Mythril、Echidna）与人工逐行代码审查
|
||||
- 结论/价值：提供专业级安全审计报告，发现可能导致用户资金损失的安全漏洞
|
||||
|
||||
## Key Claims
|
||||
- 自动化工具只能发现约 30% 的真实漏洞，人工审查不可替代
|
||||
- 预言机操纵攻击（Flash Loan Attack）是 DeFi 协议最常见的高危漏洞类型之一
|
||||
- 访问控制缺陷是仅次于重入攻击的第二大漏洞来源
|
||||
- 每个发现必须包含可复现的概念验证攻击或具体攻击场景
|
||||
|
||||
## Key Quotes
|
||||
> "Your job is not to make developers feel good — it is to find the bug before the attacker does." — 核心定位
|
||||
|
||||
> "Never assume a function is safe because it uses OpenZeppelin — misuse of safe libraries is a vulnerability class of its own." — 安全原则
|
||||
|
||||
> "Automated tools catch maybe 30% of real bugs." — 工具局限性
|
||||
|
||||
## Key Concepts
|
||||
- [[Reentrancy]]（重入攻击）：外部调用状态更新前的漏洞模式，通过 Checks-Effects-Interactions 模式 + ReentrancyGuard 防护
|
||||
- [[Oracle Manipulation]]（预言机操纵）：通过 Flash Loan 操纵链上价格预言机的攻击手法，需使用 TWAP 或 Chainlink 防护
|
||||
- [[Flash Loan Attack]]（闪电贷攻击）：在单笔交易内借用大量资金操纵市场状态的攻击范式
|
||||
- [[Access Control]]（访问控制）：智能合约权限管理，OpenZeppelin 的 AccessControl 模式
|
||||
- [[Formal Verification]]（形式化验证）：通过数学证明验证协议不变量正确性的方法
|
||||
- [[Static Analysis]]（静态分析）：Slither、Mythril 等自动化代码分析工具
|
||||
- [[Invariant Verification]]（不变量验证）：属性驱动测试验证协议关键属性
|
||||
- [[Checks-Effects-Interactions]]：防止重入攻击的设计模式，先更新状态再执行外部调用
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，本智能体所属项目
|
||||
- [[Slither]]：Trail of Bits 开发的主流静态分析工具
|
||||
- [[Mythril]]：Consensys Diligence 开发的形式化验证工具
|
||||
- [[Echidna]]：Property-based fuzzing 工具
|
||||
- [[OpenZeppelin]]：智能合约标准库，提供安全的基础组件
|
||||
- [[Foundry]]：以太坊开发框架，包含 Forge 测试工具
|
||||
- [[Chainlink]]：去中心化预言机网络
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Blockchain Security Auditor]]
|
||||
- [[Reentrancy]] ← is_type_of ← [[Smart Contract Vulnerability]]
|
||||
- [[Oracle Manipulation]] ← is_type_of ← [[DeFi Attack Vector]]
|
||||
- [[Flash Loan Attack]] ← exploits ← [[Oracle Manipulation]]
|
||||
- [[Access Control]] ← is_type_of ← [[Smart Contract Vulnerability]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Blogwatcher Daily 技能收藏"
|
||||
type: source
|
||||
tags: [skill, rss, 自动化]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/blogwatcher-daily收藏.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：RSS 订阅监控与每日摘要生成自动化
|
||||
- 问题域：信息聚合、自动化运维
|
||||
- 方法/机制：通过 Python 脚本每日定时抓取 31 个 RSS/YouTube 频道，使用 SQLite 数据库去重，输出为 Markdown 日报
|
||||
- 结论/价值：实现信息源的自动化监控与整理，降低人工跟进成本
|
||||
|
||||
## Key Claims
|
||||
- blogwatcher-daily 是 Hermes Agent 的自定义技能，通过定时任务自动化监控 31 个 RSS/YouTube 频道的更新
|
||||
- 该系统支持三种运行模式：日常扫描（追加到日报）、历史回扫（force-all 写入独立文件）、只看不写（调试模式）
|
||||
- RSS 解析使用 feedparser 库，支持 RSS 1.0/2.0/Atom 及 GB2312/GBK 编码
|
||||
- 去重机制通过 SQLite 数据库按 URL 排重
|
||||
- YouTube 频道通过 RSSHub 将 Channel ID 转为 RSS Feed，绕过直接访问限制
|
||||
|
||||
## Key Quotes
|
||||
> "RSS 订阅监控 + 每日摘要生成" — 技能定位
|
||||
|
||||
> "每天早上 6:00 自动抓取各频道新文章，追加写入 YYYY-MM-DD.md" — 日常扫描机制
|
||||
|
||||
## Key Concepts
|
||||
- [[RSS]]：信息聚合格式，允许用户订阅网站更新而无需重复访问
|
||||
- [[RSSHub]]：开源 RSS 生成器，支持将 YouTube 等平台转为 RSS 源
|
||||
- [[SQLite]]：轻量级数据库，用于记录已读状态和 URL 去重
|
||||
- [[Cron Jobs]]：Linux 基于时间的任务调度机制，用于定时执行脚本
|
||||
|
||||
## Key Entities
|
||||
- [[Hermes Agent]]：运行 blogwatcher-daily 的 AI Agent 环境
|
||||
- [[feedparser]]：Python RSS 解析库，支持 RSS 1.0/2.0/Atom
|
||||
|
||||
## Connections
|
||||
- [[blogwatcher-daily]] ← depends_on ← [[feedparser]]
|
||||
- [[YouTube 订阅]] ← depends_on ← [[RSSHub]]
|
||||
- [[每日摘要]] ← depends_on ← [[Cron Jobs]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "不谈技术：普通人该怎么在AI时代赚钱？"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/微信公众号/不谈技术：普通人该怎么在AI时代赚钱？.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI时代普通人的赚钱策略
|
||||
- 问题域：个人职业发展与商业变现
|
||||
- 方法/机制：
|
||||
- 品味是护城河：AI工具民主化但品味未民主化
|
||||
- 端到端思维：做完整产品/服务，不做流水线零件
|
||||
- 死亡过滤器：追问真正热爱的事，用AI把它做到极致
|
||||
- 结论：AI不会让普通人变富，但会让有明确目标且对品质有执念的人变得极其强大
|
||||
|
||||
## Key Claims
|
||||
- 工具民主化但品味未民主化，品味是AI时代的护城河
|
||||
- 端到端产品比100人团队里的AI提示词工程师强一万倍
|
||||
- 普通人和不普通的人的区别在于愿不愿意对一千件事说No，只对一件事说Yes
|
||||
|
||||
## Key Quotes
|
||||
> "正确的问题是：AI让我能做到什么以前做不到的事？" — 核心思维转变
|
||||
> "90%的人用AI生成的东西是shit。因为他们不知道什么是好的。" — 品味的重要性
|
||||
> "一个人用AI做出一个完整的App，比一个100人的团队里当AI提示词工程师强一万倍。" — 端到端价值
|
||||
|
||||
## Key Concepts
|
||||
- [[品味]]：能判断AI方案中哪个是insanely great的能力
|
||||
- [[端到端]]：从想法到产品的完整控制权
|
||||
- [[死亡过滤器]]：每天问自己"如果今天是最后一天，我还会做今天要做的事吗？"
|
||||
|
||||
## Key Entities
|
||||
- [[乔布斯]]：本文观点的来源，引用其1984年Mac发布的类比
|
||||
|
||||
## Connections
|
||||
- [[一人公司模式]] ← aligns_with ← [[端到端]]
|
||||
- [[Ikigai]] ← similar_to ← [[死亡过滤器]]
|
||||
- [[天才地带]] ← related_to ← [[死亡过滤器]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "超达物流定价"
|
||||
slug: chao-da-wu-liu-ding-jia
|
||||
type: source
|
||||
tags: [跨境电商, 物流, 定价]
|
||||
date: 2025-12-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/超达物流定价.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：跨境电商物流定价规则与服务说明
|
||||
- 问题域：跨境电商物流成本计算、发货时效
|
||||
- 方法/机制：UIN 渠道和 TK 平台的面单定价规则和时效说明
|
||||
- 结论/价值：帮助卖家了解物流定价结构，避免因规则不明导致额外费用
|
||||
|
||||
## Key Claims
|
||||
- UIN 渠道提供预上网服务，满足 TK 轨迹上传需求
|
||||
- 申报重量与实重/材积取最大值收费
|
||||
- 已推送轨迹的订单取消需收取全额挂号费或操作费
|
||||
|
||||
## Key Quotes
|
||||
> 申报重量和实重/材积差距尽量不要超过 0.1Kg，且申报重量要低于收费重量，以免由于申报重量过高导致多支付运费。
|
||||
|
||||
> 申报重量、实重、材积取最大值收费，请务必注意。
|
||||
|
||||
## Key Concepts
|
||||
- [[面单收费]]：物流面单的费用计算规则
|
||||
- [[预上网]]：物流轨迹预生成的机制，24-48 小时左右生成
|
||||
- [[材积重]]：物流体积折算的重量，用于国际物流计费
|
||||
|
||||
## Key Entities
|
||||
- [[超达物流]]：跨境电商物流服务商，提供 UIN 渠道和 TK 平台物流服务
|
||||
|
||||
## Connections
|
||||
- [[跨境电商]] ← 相关 ← [[超达物流定价]]
|
||||
- [[TikTok Shop]] ← 相关 ← [[超达物流]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-05-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：GitHub 开源项目 ChinaTextbook，收集中国 K12 及大学 PDF 教材
|
||||
- 问题域：教育资源获取、中小学教材数字化
|
||||
- 方法/机制：国家中小学智慧教育平台作为教材来源，通过第三方工具下载
|
||||
- 结论/价值：41.53GB 规模的免费教育资源库，覆盖小学、初中、高中、大学
|
||||
|
||||
## Key Claims
|
||||
- ChinaTextbook 项目托管于 GitHub，总库大小 41.53GB
|
||||
- 教材来源为国家中小学智慧教育平台，需登录后浏览
|
||||
- 可使用第三方工具（如 tchMaterial-parser）下载教材
|
||||
|
||||
## Key Quotes
|
||||
> "这个项目存在有一段时间了，今天突然火了。" — Appinn
|
||||
|
||||
## Key Concepts
|
||||
- [[开源平替]]：本文定义了免费教育资源的开源获取方式
|
||||
- [[教育资源数字化]]：将官方教材数字化的项目实践
|
||||
|
||||
## Key Entities
|
||||
- [[GitHub]]：项目托管平台
|
||||
- [[Appinn]]：小众软件分享网站，报道来源
|
||||
- [[TapXWorld]]：项目维护者
|
||||
- [[国家中小学智慧教育平台]]：官方教材来源平台
|
||||
|
||||
## Connections
|
||||
- [[Appinn]] ← reported ← [[ChinaTextbook]]
|
||||
- [[GitHub]] ← hosts ← [[ChinaTextbook]]
|
||||
- [[国家中小学智慧教育平台]] ← sources ← [[ChinaTextbook]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
id: claude-code-diao-yong-fang-fa-zong-jie
|
||||
title: "Claude Code 调用方法总结"
|
||||
type: source
|
||||
tags: [Claude Code, Agent, 工具调用, 自动化]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/claude-code调用方法总结.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Hermes 调用 Claude Code 的两种模式及关键参数
|
||||
- 问题域：AI Agent 自动化任务执行、外部进程调用
|
||||
- 方法/机制：Print Mode（推荐）和 TMUX 交互模式
|
||||
- 结论/价值：提供 Claude Code 外部调用的完整技术方案
|
||||
|
||||
## Key Claims
|
||||
- Hermes 通过 `terminal` 工具调用 Claude Code，有 Print Mode 和 TMUX 交互两种模式
|
||||
- Print Mode 通过 stdin 传递任务文本，适合绝大多数任务
|
||||
- TMUX 交互模式适合超长任务，需要手动监控进度
|
||||
- `--permission-mode bypassPermissions` 是最可靠的权限绕过参数
|
||||
|
||||
## Key Quotes
|
||||
> "用 `--permission-mode bypassPermissions` 可直接跳过信任目录 + bypass 权限确认两步，不需要额外的 sleep + send-keys 模拟交互。"
|
||||
|
||||
> "Skill 加载只需要：`--add-dir <技能所在目录>`"
|
||||
|
||||
> "delegate_task 是 Hermes 子 agent（API 调用），terminal 调用 claude -p 是外部 Claude Code 进程"
|
||||
|
||||
## Key Concepts
|
||||
- [[Print Mode]]：通过 stdin 传递任务文本的非交互执行模式
|
||||
- [[TMUX 交互模式]]：在 TMUX 会话中运行 Claude Code 的交互模式
|
||||
- [[Skill 加载]]：通过 `--add-dir` 参数加载 Claude Code 技能
|
||||
- [[Print Mode vs TMUX 区别]]
|
||||
|
||||
## Key Entities
|
||||
- [[Claude]]：Anthropic 公司开发的 AI 聊天助手
|
||||
- [[OpenClaw]]：AI Agent 管理工具，Hermes 是其核心组件
|
||||
|
||||
## Connections
|
||||
- [[Claude Code 调用方法总结]] ← documents ← [[OpenClaw]]
|
||||
- [[Print Mode]] ← uses ← [[terminal 工具]]
|
||||
- [[TMUX 交互模式]] ← uses ← [[TMUX]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Notes
|
||||
- Print Mode 是推荐模式，通过管道传递任务文本避免 shell 转义问题
|
||||
- 常见坑点：不写 bypass 参数、max-turns 太小、命令行直接传任务
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Claude Code Integration"
|
||||
type: source
|
||||
tags: [agency, integrations, claude-code]
|
||||
date: 2026-04-20
|
||||
source_file: raw/Agent/agency-agents/integrations/claude-code/README.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
This README documents how The Agency integrates with Claude Code. Because the agents are already authored as Markdown files with YAML frontmatter, no conversion is required. The README includes install commands to copy agents into Claude Code's agents directory, activation examples, and a note that agents are organized into divisions.
|
||||
|
||||
## Key Claims
|
||||
- The Agency agents work natively with Claude Code's `.md` + YAML frontmatter format; no conversion step is required.
|
||||
- Installation can be done via `./scripts/install.sh --tool claude-code` or by copying individual category files into `~/.claude/agents/`.
|
||||
- Agents are referenced by name in Claude Code sessions to activate behavior.
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — Claude Code Integration README
|
||||
|
||||
## Connections
|
||||
- [[The Agency: AI Specialists Ready to Transform Your Workflow]] — primary roster source; agents are authored in the repo's Markdown format and intended for Claude Code
|
||||
|
||||
## Contradictions
|
||||
- None detected with existing wiki content at time of ingest.
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: 如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略
|
||||
type: source
|
||||
tags: [adspower, claude, ip, pingme, 虚拟信用卡]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：通过指纹浏览器 + 高纯净度代理IP 安全注册并订阅 Claude Pro 会员
|
||||
- 问题域：跨境支付、账号防封、虚拟身份隔离
|
||||
- 方法/机制：指纹浏览器环境隔离、SOCKS5 代理配置、IP 纯净度检测、虚拟信用卡支付
|
||||
- 结论/价值：有效降低 Claude 账号被封风险，实现稳定使用 AI 服务
|
||||
|
||||
## Key Claims
|
||||
- 指纹浏览器可隔离环境，减少账号关联导致的封号风险
|
||||
- IP 一致性检测（三处测试点国内/国外/谷歌 IP 必须匹配）是防封关键
|
||||
- IP 纯净度需达到"低风险"等级，中等风险以上会被平台标记
|
||||
- 使用订阅制接码平台（如 PingMe）可获取长期稳定验证码
|
||||
- 虚拟信用卡（如 WildCard）是国内用户支付 Claude Pro 的解决方案
|
||||
|
||||
## Key Quotes
|
||||
> "代理设置成功后，用检查代理功能确认IP归属地为美国，实现代理连接成功" — 代理配置验证步骤
|
||||
> "重要的IP风险评估，理想纯净度为低风险，数值越低越安全，中等风险或以上可能被封号" — IP 纯净度标准
|
||||
|
||||
## Key Concepts
|
||||
- [[指纹浏览器]]：可模拟不同设备、网络环境的多账号浏览器，隔离使用环境
|
||||
- [[SOCKS5代理]]：网络代理协议，支持灵活传输隧道，隐匿真实 IP 和地理位置
|
||||
- [[IP纯净度]]：评定 IP 安全可靠的风险等级，低风险代表良好信誉
|
||||
- [[虚拟信用卡]]：不依赖实体卡的线上信用支付工具，解决跨境支付难题
|
||||
- [[验证码接收平台]]：提供短信接码服务，完成注册或验证
|
||||
|
||||
## Key Entities
|
||||
- [[AdsPower]]：指纹浏览器推荐工具，支持谷歌授权登录
|
||||
- [[Claude]]：AI 聊天工具，Pro 版本需付费订阅
|
||||
- [[WildCard]]：虚拟信用卡，解决海外支付问题
|
||||
- [[PingMe]]：新兴接码平台，支持中文界面和美国区号码
|
||||
|
||||
## Connections
|
||||
- [[Claude]] ← 使用 ← [[指纹浏览器]]
|
||||
- [[Claude]] ← 需要 ← [[验证码接收平台]]
|
||||
- [[Claude Pro]] ← 支付方式 ← [[虚拟信用卡]]
|
||||
- [[指纹浏览器]] ← 配置 ← [[SOCKS5代理]]
|
||||
- [[SOCKS5代理]] ← 依赖 ← [[IP纯净度]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [backup, clonezilla, ubuntu, nfs, nas]
|
||||
date: 2025-12-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用 Clonezilla 实现 Ubuntu Server 全盘镜像备份到 NAS
|
||||
- 问题域：服务器灾难恢复、磁盘镜像备份
|
||||
- 方法/机制：Clonezilla（再生龙）+ NFS 网络存储
|
||||
- 结论/价值：实现类似 Ghost 的磁盘镜像备份，支持灾难恢复
|
||||
|
||||
## Key Claims
|
||||
- Clonezilla 支持将整个磁盘备份为镜像文件，存储在 NAS 或外置硬盘上
|
||||
- 使用 NFS 协议连接 NAS 是 Linux 环境下的推荐方案
|
||||
- 备份完成后可通过 Restore 功能将镜像还原到新硬盘，实现系统即时复活
|
||||
|
||||
## Key Quotes
|
||||
> "以 ISO 镜像模式写入 (推荐)" — Rufus 制作启动盘的最佳模式选择
|
||||
> "选择 -z1p (默认的高压缩率，适合节省 NAS 空间)" — 备份压缩级别选择
|
||||
|
||||
## Key Concepts
|
||||
- [[Clonezilla]]：开源磁盘镜像备份工具
|
||||
- [[NFS]]：网络文件系统协议
|
||||
- [[NAS]]：网络附加存储
|
||||
- [[灾难恢复]]：系统故障后的数据还原流程
|
||||
- [[增量备份]]：仅备份变化数据的备份策略（本场景为全盘备份）
|
||||
|
||||
## Key Entities
|
||||
- [[Rufus]]：制作 Clonezilla 启动 U 盘的工具
|
||||
- [[Ubuntu Server]]：备份源操作系统
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla]] ← uses ← [[NFS]] ← stores ← [[NAS]]
|
||||
- [[灾难恢复]] ← enables ← [[Clonezilla]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[rsync]] 增量备份相比：Clonezilla 是全盘镜像，rsync 是文件级增量备份。Clonezilla 适合完整系统恢复场景，rsync 适合日常文件同步。
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Cloud Learning Master Index"
|
||||
type: source
|
||||
tags: ["cloud-learning", "DevOps", "SRE", "AWS", "master-index", "index"]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenText 内部 Public Cloud Learning Sessions 课程的分类索引与统计信息
|
||||
- 问题域：云原生、DevOps、SRE、AWS、Azure、FinOps、安全
|
||||
- 方法/机制：按主题分类（10 个类别），提供 NAS 源文件链接和视频数量统计
|
||||
- 结论/价值：为企业内部云技术学习提供结构化课程导航
|
||||
|
||||
## Key Claims
|
||||
- Public Cloud Learning Sessions 涵盖 10 个核心技术领域，共 121 个视频课程
|
||||
- 课程涵盖 AWS Landing Zone (22)、IAM & Identity (3)、Terraform & IaC (6)、EKS & Kubernetes (14)、FinOps & Cost (10)、CI/CD & GitOps (8)、Security (9)、Networking (9)、Serverless & AI (9)、OpenText Series (21)
|
||||
- 学习资源存储于 NAS `/volume2/work/Public Cloud Learning Sessions/`
|
||||
|
||||
## Key Quotes
|
||||
> "NAS源: /volume2/work/Public Cloud Learning Sessions/ | Total: 0 videos processed"
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Landing Zone]]：AWS 云基础设施着陆区架构
|
||||
- [[IAM]]：身份与访问管理
|
||||
- [[Terraform]]：基础设施即代码工具
|
||||
- [[EKS]]：Amazon Elastic Kubernetes Service
|
||||
- [[FinOps]]：云财务运营
|
||||
- [[GitOps]]：基于 Git 的运维实践
|
||||
- [[DevSecOps]]：安全集成的开发运维
|
||||
- [[Landing Zone]]：云着陆区
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]：主办 Public Cloud Learning Sessions 的企业
|
||||
|
||||
## Connections
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[AWS Landing Zone]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[IAM & Identity]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[Terraform & IaC]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[EKS & Kubernetes]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[FinOps & Cost]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[CI/CD & GitOps]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[Security]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[Networking]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[Serverless & AI]]
|
||||
- [[Cloud Learning Master Index]] ← contains ← [[OpenText Series]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突记录
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: codecrafters-io/build-your-own-x:Master programming by recreating your favorite technologies from scratch.
|
||||
source: https://github.com/codecrafters-io/build-your-own-x?tab=readme-ov-file#build-your-own-insert-technology-here
|
||||
author: shenwei
|
||||
published:
|
||||
created: 2026-01-01
|
||||
description: Master programming by recreating our favorite technologies from scratch.
|
||||
tags: [build-your-own-x, byox, codecrafters, github]
|
||||
---
|
||||
|
||||
# codecrafters-io/build-your-own-x
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md]]
|
||||
|
||||
## Overview
|
||||
|
||||
**[build-your-own-x](https://github.com/codecrafters-io/build-your-own-x)** is a compilation of well-written, step-by-step guides for recreating our favorite technologies from scratch.
|
||||
|
||||
> *What I cannot create, I do not understand — Richard Feynman.*
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
The fundamental principle behind this project is that **learning by creating is the most effective way to truly understand a technology**. Instead of just consuming knowledge passively, practitioners rebuild complex systems from scratch, gaining deep insight into how they work internally.
|
||||
|
||||
## Technology Categories
|
||||
|
||||
This repository covers **26 major technology domains**:
|
||||
|
||||
- [[3D Renderer]]
|
||||
- [[Augmented Reality]]
|
||||
- [[BitTorrent Client]]
|
||||
- [[Blockchain / Cryptocurrency]]
|
||||
- [[Bot]] Development
|
||||
- [[Command-Line Tool]]s
|
||||
- [[Database]]
|
||||
- [[Docker]]
|
||||
- [[Emulator / Virtual Machine]]
|
||||
- [[Front-end Framework / Library]]
|
||||
- [[Game]] Development
|
||||
- [[Git]]
|
||||
- [[Network Stack]]
|
||||
- [[Neural Network]]
|
||||
- [[Operating System]]
|
||||
- [[Physics Engine]]
|
||||
- [[Programming Language]]
|
||||
- [[Regex Engine]]
|
||||
- [[Search Engine]]
|
||||
- [[Shell]]
|
||||
- [[Template Engine]]
|
||||
- [[Text Editor]]
|
||||
- [[Visual Recognition System]]
|
||||
- [[Voxel Engine]]
|
||||
- [[Web Browser]]
|
||||
- [[Web Server]]
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Byox]] - The methodology of learning programming by rebuilding technologies from scratch
|
||||
- [[Learn In Public]] - Sharing learning progress publicly
|
||||
- [[CodeCrafters]] - The platform that maintains this repository and provides interactive challenges
|
||||
|
||||
## Notable Tutorials
|
||||
|
||||
### Programming Languages
|
||||
- [Crafting Interpreters](http://www.craftinginterpreters.com/) - Java implementation
|
||||
- [Write Yourself a Scheme in 48 Hours](https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours) - Haskell
|
||||
- [Build Your Own Lisp](http://www.buildyourownlisp.com/) - C in 1000 lines
|
||||
- [Make a Lisp (mal)](https://github.com/kanaka/mal) - Implementations in any language
|
||||
|
||||
### Operating Systems
|
||||
- [Linux from Scratch](https://linuxfromscratch.org/lfs)
|
||||
- [Writing an OS in Rust](https://os.phil-opp.com/)
|
||||
- [Operating Systems: From 0 to 1](https://tuhdo.github.io/os01/)
|
||||
- [The little book about OS development](https://littleosbook.github.io/)
|
||||
|
||||
### Databases
|
||||
- [Let's Build a Simple Database](https://cstack.github.io/db_tutorial/) - C
|
||||
- [Build Your Own Redis from Scratch](https://build-your-own.org/redis) - C++
|
||||
- [Build Your Own Database from Scratch](https://build-your-own.org/database/) - Go
|
||||
|
||||
### Web Technologies
|
||||
- [Let's Build a Web Server](https://ruslanspivak.com/lsbaws-part1/) - Python
|
||||
- [Browser Engineering](https://browser.engineering/) - Python
|
||||
- [Let's build a browser engine](https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html) - Rust
|
||||
|
||||
### Git
|
||||
- [Gitlet](http://gitlet.maryrosecook.com/docs/gitlet.html) - JavaScript
|
||||
- [Write yourself a Git!](https://wyag.thb.lt/) - Python
|
||||
- [ugit: Learn Git Internals](https://www.leshenko.net/p/ugit/) - Python
|
||||
|
||||
## Contributing
|
||||
|
||||
Contributions are welcome! Submit a PR or [create an issue](https://github.com/codecrafters-io/build-your-own-x/issues/new) to add new tutorials.
|
||||
|
||||
## Resources
|
||||
|
||||
- [CodeCrafters](https://codecrafters.io/) - Interactive challenges based on this repository
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: "Compliance Auditor Agent"
|
||||
type: source
|
||||
tags: [agent, compliance, audit, the-agency, specialized]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/compliance-auditor.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：技术合规审计专家智能体，专注于 SOC 2、ISO 27001、HIPAA 和 PCI-DSS 认证流程
|
||||
- 问题域：安全与隐私认证、 controls implementation、 evidence collection、 gap assessment
|
||||
- 方法/机制：五阶段工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）、自动化证据收集、审计就绪度评估
|
||||
- 结论/价值：提供从准备评估到认证的技术合规全程指导，强调实质优于检查清单、证据证明控制有效性
|
||||
|
||||
## Key Claims
|
||||
- 控制必须被测试，而不仅是文档化
|
||||
- 证据必须证明控制在审计期间有效运作，而不仅是今天存在
|
||||
- 政策无人遵守比没有政策更糟糕——它产生虚假信心和审计风险
|
||||
- 自动化证据收集从第一天开始——手动流程无法扩展
|
||||
|
||||
## Key Quotes
|
||||
> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk." — Compliance Auditor 核心原则
|
||||
|
||||
> "Think like the auditor: what would you test? what evidence would you request?" — 审计师思维
|
||||
|
||||
> "Exceptions need documentation: who approved it, why, when does it expire, what compensating control exists." — 例外处理规范
|
||||
|
||||
## Key Concepts
|
||||
- [[Audit Readiness]]（审计就绪度）：评估当前安全态势是否符合目标框架要求
|
||||
- [[Gap Assessment]]（差距评估）：识别控制差距并基于风险和审计时间线制定优先修复计划
|
||||
- [[Controls Implementation]]（控制实施）：设计满足合规要求且适应现有工程工作流的控制
|
||||
- [[Evidence Collection]]（证据收集）：自动化证据收集流程，确保可扩展性和可靠性
|
||||
- [[Continuous Compliance]]（持续合规）：建立自动化证据收集管道，季度控制测试，监管变化追踪
|
||||
|
||||
## Key Entities
|
||||
- [[SOC-2]]：Service Organization Control 2，安全与隐私合规框架
|
||||
- [[ISO-27001]]：国际信息安全管理标准
|
||||
- [[HIPAA]]：美国健康保险可携带性和责任法案
|
||||
- [[PCI-DSS]]：支付卡行业数据安全标准
|
||||
- [[The Agency]]：开源 AI 智能体集合项目，本 Agent 所属框架
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← contains ← [[Compliance Auditor]]
|
||||
- [[SOC-2]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[ISO-27001]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[HIPAA]] ←认证目标← [[Compliance Auditor]]
|
||||
- [[PCI-DSS]] ←认证目标← [[Compliance Auditor]]
|
||||
|
||||
## Compliance Deliverables
|
||||
### Gap Assessment Report
|
||||
结构化发现报告，包含控制域、当前状态、目标状态、修复步骤和估计工作量
|
||||
|
||||
### Evidence Collection Matrix
|
||||
控制证据矩阵，包含控制 ID、证据类型、来源、收集方法和频率
|
||||
|
||||
### Policy Template
|
||||
政策模板，包含目的、范围、政策声明、例外处理、执行和相关控制映射
|
||||
|
||||
## Workflow
|
||||
1. **Scoping**：定义信任服务标准或控制目标，识别审计边界内的系统、数据流和团队
|
||||
2. **Gap Assessment**：逐项评估控制目标与当前状态，按严重性和修复复杂度评级
|
||||
3. **Remediation Support**：帮助团队实施符合工作流的控制，审查证据完整性
|
||||
4. **Audit Support**：组织证据仓库，准备 walkthrough 脚本，管理审计发现
|
||||
5. **Continuous Compliance**：设置自动化证据收集，季度控制测试，监管变化追踪
|
||||
220
wiki/sources/contributing-to-the-agency.md
Normal file
220
wiki/sources/contributing-to-the-agency.md
Normal file
@@ -0,0 +1,220 @@
|
||||
# Contributing to The Agency
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/CONTRIBUTING.md]]
|
||||
|
||||
## Overview
|
||||
|
||||
The Agency 是一个开源 AI Agent 精选集合，其 CONTRIBUTING.md 定义了完整的贡献指南体系，涵盖行为准则、贡献方式、Agent 设计规范、PR 流程和写作风格指南。
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
项目遵守明确的行为准则：
|
||||
- **Be Respectful**：尊重每个人，鼓励健康辩论，拒绝人身攻击
|
||||
- **Be Inclusive**：欢迎并支持各种背景和身份的人
|
||||
- **Be Collaborative**：协作创造优于独自创作
|
||||
- **Be Professional**：保持讨论聚焦于改进 agents 和社区
|
||||
|
||||
## How to Contribute
|
||||
|
||||
### 1. 创建新 Agent
|
||||
|
||||
贡献者在选择合适分类后，按模板创建 Agent 文件：
|
||||
- `engineering/` — 软件开发专家
|
||||
- `design/` — UX/UI 和创意专家
|
||||
- `finance/` — 财务规划和投资专家
|
||||
- `game-development/` — 游戏设计与开发专家
|
||||
- `marketing/` — 增长和营销专家
|
||||
- `paid-media/` — 付费获客专家
|
||||
- `product/` — 产品管理专家
|
||||
- `project-management/` — PM 和协调专家
|
||||
- `testing/` — QA 和测试专家
|
||||
- `support/` — 运营和支持专家
|
||||
- `spatial-computing/` — AR/VR/XR 专家
|
||||
- `specialized/` — 不属于以上分类的专家
|
||||
|
||||
### 2. 改进现有 Agent
|
||||
|
||||
贡献方向包括：
|
||||
- 添加真实案例和使用场景
|
||||
- 用现代模式增强代码示例
|
||||
- 基于最新最佳实践更新工作流
|
||||
- 添加成功指标和基准
|
||||
- 修复错字、改善清晰度、增强文档
|
||||
|
||||
### 3. 分享成功案例
|
||||
|
||||
通过 GitHub Discussions、案例研究、博客文章和视频教程分享。
|
||||
|
||||
### 4. 报告问题
|
||||
|
||||
提供清晰的复现步骤、使用场景上下文和建议的解决方案。
|
||||
|
||||
## Agent Design Guidelines
|
||||
|
||||
### Agent 文件结构
|
||||
|
||||
Agent 文件遵循 YAML frontmatter + Markdown 内容的两段式结构：
|
||||
|
||||
#### YAML Frontmatter
|
||||
```yaml
|
||||
---
|
||||
name: Agent Name
|
||||
description: One-line description
|
||||
color: colorname or "#hexcode"
|
||||
emoji: 🎯
|
||||
vibe: One-line personality hook
|
||||
services: # optional — only if the agent requires external services
|
||||
- name: Service Name
|
||||
url: https://service-url.com
|
||||
tier: free # free, freemium, or paid
|
||||
---
|
||||
```
|
||||
|
||||
#### Content Sections
|
||||
|
||||
文档定义了 Agent 文件的两大语义分组：
|
||||
|
||||
**Persona（Agent 的身份）**：
|
||||
- Identity & Memory — 角色、个性、背景
|
||||
- Communication Style — 语气、声音、方式
|
||||
- Critical Rules — 边界和约束
|
||||
|
||||
**Operations（Agent 的行为）**：
|
||||
- Core Mission — 主要职责
|
||||
- Technical Deliverables — 具体输出和模板
|
||||
- Workflow Process — 分步方法论
|
||||
- Success Metrics — 可衡量成果
|
||||
- Advanced Capabilities — 专业化技术
|
||||
|
||||
#### 结构原则
|
||||
|
||||
不需要特殊格式——只需将 persona 相关部分（身份、沟通、规则）与操作部分（使命、交付物、工作流、指标）分开。`convert.sh` 脚本使用这些章节标题自动将 agents 拆分为工具特定格式。
|
||||
|
||||
### Agent Design Principles
|
||||
|
||||
1. **Strong Personality**：赋予 agent 独特的声音和个性，而非泛泛的"helpful assistant"
|
||||
2. **Clear Deliverables**：提供具体代码示例、模板和框架，展示真实输出
|
||||
3. **Success Metrics**：包含具体、可衡量的指标（如"3G 网络下页面加载 < 3 秒"）
|
||||
4. **Proven Workflows**：分步流程，经过真实场景测试
|
||||
5. **Learning Memory**：agent 识别的模式和随时间的改进方式
|
||||
|
||||
### External Services
|
||||
|
||||
Agent 依赖外部服务时的设计原则：
|
||||
1. 在 frontmatter 的 `services` 字段中声明依赖
|
||||
2. Agent 必须独立自主——移除 API 调用后仍应有有用的 persona、工作流和专业知识
|
||||
3. 不复制供应商文档——引用而非再现
|
||||
4. 优先选择有免费层级的服务
|
||||
|
||||
关键测试：*这个 agent 是为用户服务的，还是为供应商服务的？*
|
||||
|
||||
### Qwen Code Compatibility
|
||||
|
||||
Agent body 支持 `${variable}` 模板语法以实现动态上下文（如 `${project_name}`、`${task_description}`）。Qwen SubAgents 使用最小化 frontmatter：仅需要 `name` 和 `description`；`color`、`emoji` 和 `version` 字段被省略。
|
||||
|
||||
### What Makes a Great Agent
|
||||
|
||||
**Great agents have**：
|
||||
- ✅ 狭窄而深入的专业化
|
||||
- ✅ 独特的个性和声音
|
||||
- ✅ 具体的代码/模板示例
|
||||
- ✅ 可衡量的成功指标
|
||||
- ✅ 分步工作流
|
||||
- ✅ 真实场景测试和迭代
|
||||
|
||||
**Avoid**：
|
||||
- ❌ 泛化的"helpful assistant"个性
|
||||
- ❌ 模糊的"我将帮助你..."描述
|
||||
- ❌ 无代码示例或交付物
|
||||
- ❌ 过于宽泛的范围（什么都做等于什么都没做）
|
||||
- ❌ 未经测试的理论方法
|
||||
|
||||
## Pull Request Process
|
||||
|
||||
### PR 边界管理
|
||||
|
||||
最佳路径是一个 markdown 文件（一个新或改进的 agent），这是最理想的情况。
|
||||
|
||||
**始终欢迎作为 PR**：
|
||||
- 添加新 agent（一个 `.md` 文件）
|
||||
- 改进现有 agent 的内容、示例或个性
|
||||
- 修复错字或澄清文档
|
||||
|
||||
**先开 Discussion**：
|
||||
- 新工具、构建系统或 CI 工作流
|
||||
- 架构变更（新目录、新脚本、网站生成器）
|
||||
- 跨多文件变更
|
||||
- 新集成格式或平台
|
||||
|
||||
**始终关闭的内容**：
|
||||
- 已提交构建输出（`_site/`、编译资产、转换后的 agent 文件）
|
||||
- 批量修改现有 agents 而未先讨论的 PR
|
||||
|
||||
### Before Submitting
|
||||
|
||||
1. **Test Your Agent**：在真实场景中使用并迭代反馈
|
||||
2. **Follow the Template**：匹配现有 agents 的结构
|
||||
3. **Add Examples**：至少包含 2-3 个代码/模板示例
|
||||
4. **Define Metrics**：包含具体、可衡量的成功标准
|
||||
5. **Proofread**：检查错字、格式问题和清晰度
|
||||
|
||||
### PR Review Process
|
||||
|
||||
1. **Community Review**：其他贡献者提供反馈
|
||||
2. **Iteration**：响应反馈并进行改进
|
||||
3. **Approval**：维护者批准后合并
|
||||
4. **Merge**：贡献成为 The Agency 的一部分
|
||||
|
||||
## Style Guide
|
||||
|
||||
### Writing Style
|
||||
|
||||
- **Be specific**："Reduce page load by 60%" 而非 "Make it faster"
|
||||
- **Be concrete**："Create React components with TypeScript" 而非 "Build UIs"
|
||||
- **Be memorable**：赋予 agents 个性，而非泛化的企业用语
|
||||
- **Be practical**：包含真实代码，而非伪代码
|
||||
|
||||
### Formatting
|
||||
|
||||
- 一致使用 **Markdown formatting**
|
||||
- 章节标题使用 **emojis**（便于扫描）
|
||||
- 所有代码示例使用 **code blocks** 并标注语法高亮
|
||||
- 使用 **tables** 对比选项或展示指标
|
||||
- 使用 **bold** 强调，`code` 标注技术术语
|
||||
|
||||
### Tone
|
||||
|
||||
- **Professional but approachable**：不过于正式或随意
|
||||
- **Confident but not arrogant**："Here's the best approach" 而非"Maybe you could try..."
|
||||
- **Helpful but not hand-holding**：假设能力，提供深度
|
||||
- **Personality-driven**：每个 agent 应有独特声音
|
||||
|
||||
## Recognition
|
||||
|
||||
重要贡献者将被：
|
||||
- 列在 README 致谢部分
|
||||
- 在发布说明中突出
|
||||
- 在"本周最佳 Agent"展示中亮相（如适用）
|
||||
- 在 agent 文件本身中获得荣誉
|
||||
|
||||
## Questions & Resources
|
||||
|
||||
- **General Questions**: GitHub Discussions
|
||||
- **Bug Reports**: GitHub Issues
|
||||
- **Feature Requests**: GitHub Issues
|
||||
- **Community Chat**: Join discussions
|
||||
|
||||
### For New Contributors
|
||||
|
||||
- README.md — 总览和 agent 目录
|
||||
- engineering-frontend-developer.md — 结构良好的 agent 示例
|
||||
- marketing-reddit-community-builder.md — 个性出色的示例
|
||||
- design-whimsy-injector.md — 创意专家示例
|
||||
|
||||
## Related
|
||||
|
||||
- [[The Agency]] — 项目主实体
|
||||
- [[agency-agents]] — GitHub 仓库实体
|
||||
- [[agency-agents-examples]] — Examples 页面
|
||||
- [[agency-agents-integrations]] — 集成文档
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "为 The Agency 贡献代码"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：The Agency 项目的贡献指南，涵盖智能体设计规范、PR 流程和社区参与方式
|
||||
- 问题域：开源 AI 智能体项目的贡献流程标准化
|
||||
- 方法/机制：明确的智能体模板结构、设计原则、PR 审核流程
|
||||
- 结论/价值：为 AI 智能体社区贡献提供规范化指导，降低贡献门槛，提高智能体质量
|
||||
|
||||
## Key Claims
|
||||
- 智能体设计必须遵循六大原则：鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆、真实场景测试
|
||||
- 优秀智能体必须具备：专精领域定位、独特性格语气、具体代码示例、可量化指标、分步工作流
|
||||
- PR 审核流程包括：社区评审、迭代优化、通过审核、合并上线四个阶段
|
||||
|
||||
## Key Quotes
|
||||
> "正是有像你这样的参与者，才能让这套 AI 智能体集合变得越来越好" — 贡献开场白
|
||||
|
||||
> "避免通用型'有用助手'人设" — 智能体设计核心原则
|
||||
|
||||
> "提供真实代码，而非伪代码" — 风格指南要求
|
||||
|
||||
## Key Concepts
|
||||
- [[智能体设计规范]]：智能体文件结构、身份与记忆、核心使命、技术交付物、工作流程的完整定义
|
||||
- [[智能体设计原则]]：六大设计原则，包括鲜明性格、明确交付物、成功指标、验证工作流、学习记忆
|
||||
- [[Pull Request 流程]]：从提交前准备到 PR 审核的完整流程
|
||||
- [[风格指南]]：写作风格、格式规范、代码示例的具体要求
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：AI 智能体集合项目
|
||||
- [[agency-agents]]：GitHub 仓库名称
|
||||
|
||||
## Connections
|
||||
- [[智能体设计规范]] ← defines ← [[The Agency]]
|
||||
- [[Pull Request 流程]] ← enables ← [[社区贡献]]
|
||||
- [[风格指南]] ← governs ← [[代码示例]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: "Corporate Training Designer"
|
||||
type: source
|
||||
tags: [agent, training, enterprise-learning, instructional-design]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/corporate-training-designer.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业培训系统架构与课程开发专家智能体
|
||||
- 问题域：企业培训需求分析、课程体系设计、教学方法论、培训效果评估
|
||||
- 方法/机制：ADDIE/SAM 模型、Bloom's Taxonomy、Kirkpatrick 四级评估、Kolb 体验式学习、TTT 内部培训师培养
|
||||
- 结论/价值：提供从需求诊断到效果追踪的完整企业培训解决方案，强调业务结果导向和数据驱动优化
|
||||
|
||||
## Key Claims
|
||||
- 所有培训设计必须从业务问题出发，而非"我们有什么课程"
|
||||
- 培训目标必须可衡量，而非模糊的"提升沟通能力"
|
||||
- 成人学习必须具有即时实用价值，每项学习活动必须回答"我马上能在哪里用"
|
||||
- Kirkpatrick Level 3（行为改变）是高投入项目的必备评估维度
|
||||
- 合规培训必须达到 100% 全员覆盖和完整培训记录
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[ADDIE 模型]]：Analysis → Design → Development → Implementation → Evaluation，每个阶段有明确交付物
|
||||
- [[SAM 模型]]（Successive Approximation Model）：适用于快速迭代场景，原型→评审→修订循环缩短上线时间
|
||||
- [[Bloom's Taxonomy]]：按认知层级设计学习目标和评估（记忆→理解→应用→分析→评估→创造）
|
||||
- [[Kirkpatrick 四级评估模型]]：Level 1 反应、Level 2 学习、Level 3 行为、Level 4 结果
|
||||
- [[建构主义学习理论]]：强调通过情境任务、协作学习和反思复盘进行主动知识建构
|
||||
- [[翻转课堂]]：课前在线预习知识点，课堂讨论和实操练习，课后行动转化
|
||||
- [[混合学习]]（OMO — Online-Merge-Offline）：线上用于"知"，线下用于"做"，学习社群用于"持续"
|
||||
- [[Kolb 体验式学习]]：具体经验→反思观察→抽象概念化→主动实验
|
||||
- [[Gamification]]：积分、徽章、排行榜、升级机制提升参与度和完成率
|
||||
- [[TTT]]（Train the Trainer）：内部培训师培养，核心模块包括成人学习原理、课程开发技巧、表达呈现技能
|
||||
- [[HIPO 计划]]（High-Potential Talent Program）：高潜力人才发展计划，识别标准为绩效×潜力矩阵
|
||||
- [[行动学习]]：围绕真实业务挑战组建学习小组，通过解决实际问题发展领导力
|
||||
- [[360 度反馈]]：从上级/同事/下级/客户收集多维反馈，生成个人领导力档案和发展建议
|
||||
- [[ADDIE]]：见 ADDIE 模型
|
||||
- [[新员工培训 90 天计划]]：第 1 周适应→第 1 月学习→第 2 月实践→第 3 月输出
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[DingTalk Learning]]：阿里生态企业首选，深度集成钉钉 OA，支持直播培训和任务推送
|
||||
- [[WeCom Learning]]：微信生态企业首选，可嵌入公众号和小程序，社交学习体验强
|
||||
- [[Feishu Knowledge Base]]：字节跳动生态和知识管理导向组织首选，文档协作优秀
|
||||
- [[UMU Interactive Learning Platform]]：国内领先混合学习平台，AI 陪练、视频作业、丰富交互功能
|
||||
- [[Yunxuetang]]（云学堂）：中大型企业一站式学习平台，课程资源丰富，覆盖人才发展全生命周期
|
||||
- [[KoolSchool]]（酷学院）：轻量级企业培训 SaaS，快速部署，适合中小企业和连锁零售行业
|
||||
|
||||
## Connections
|
||||
- [[Corporate Training Designer]] ← designs ← [[ADDIE 模型]]
|
||||
- [[Corporate Training Designer]] ← applies ← [[Kirkpatrick 四级评估模型]]
|
||||
- [[Corporate Training Designer]] ← uses ← [[Bloom's Taxonomy]]
|
||||
- [[Corporate Training Designer]] ← implements ← [[混合学习]]
|
||||
- [[Corporate Training Designer]] ← develops ← [[TTT]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[DingTalk Learning]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[WeCom Learning]]
|
||||
- [[Corporate Training Designer]] ← delivers via ← [[Feishu Knowledge Base]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Training Evaluation Methods
|
||||
- Level 1 (Reaction)：培训满意度调查——课程评分、讲师评分、NPS
|
||||
- Level 2 (Learning)：知识考试、技能实操评估、案例分析作业
|
||||
- Level 3 (Behavior)：培训后 30/60/90 天行为改变追踪——经理观察、关键行为清单
|
||||
- Level 4 (Results)：业务指标变化（收入、客户满意度、生产效率、员工留存）
|
||||
|
||||
## Success Metrics
|
||||
- 培训满意度评分 >= 4.5/5.0，NPS >= 50
|
||||
- 关键课程考试通过率 >= 90%
|
||||
- 培训后 90 天行为改变率 >= 60%（Kirkpatrick Level 3）
|
||||
- 年度培训覆盖率 >= 95%，人均学习时长达标
|
||||
- 内部培训师池满足业务需求，培训师满意度 >= 4.0/5.0
|
||||
- 合规培训 100% 全员覆盖，100% 考试通过率
|
||||
- 培训项目的可量化业务影响（如缩短新员工上手时间、提升客户满意度）
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Gruntwork
|
||||
- CTP
|
||||
- DevOps
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：基于 Gruntwork 的 AWS Landing Zone 架构设计与实现
|
||||
- 问题域：云转型项目的基础设施最佳实践
|
||||
- 方法/机制：参考架构（Reference Architecture）+ Landing Zone + 联邦用户 + Jenkins CI/CD + Git 工作流
|
||||
- 结论/价值：Gruntwork 提供经过实战验证的 Terraform 模块，是云平台部署的最佳实践起点
|
||||
|
||||
## Key Claims
|
||||
- Gruntwork 是拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践
|
||||
- 参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点
|
||||
- Landing Zone 基于 Gruntwork，不包含具体 ECS 集群或 RDS 数据库，由产品团队自行定义
|
||||
- 安全账户使用联邦用户，通过 AD 组映射到 IAM 角色，替代传统 IAM 用户
|
||||
- 每个 Landing Zone 有一个 Jenkins 服务器部署基础设施变更，每个产品团队有独立 Jenkins 任务
|
||||
|
||||
## Key Quotes
|
||||
> "服务应具有业务上下文，而非简单的资源" — Gruntwork Terraform AWS 服务目录的设计理念
|
||||
|
||||
## Key Concepts
|
||||
- [[Reference Architecture]]：包含核心账户和工作负载账户的最佳实践起点
|
||||
- [[Landing Zone]]：基于 Gruntwork 的基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC
|
||||
- [[Federated User]]：通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理
|
||||
- [[Gruntwork Modules]]：经过实战验证的 Terraform 模块，提供业务上下文和粒度支持
|
||||
- [[CI/CD Pipeline]]：基于特性分支 + PR + Jenkins 的基础设施变更自动化流程
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]：提供 Landing Zone 框架的组织，定义 R&D 和 SAS 环境域名规范
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-2-git]] — Git 版本控制基础（CI/CD 前提）
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]] — Terraform 部署与维护
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 流水线实践
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## 行动项
|
||||
- [ ] 熟悉 Gruntwork Terraform AWS Service Catalog，了解可用模块
|
||||
- [ ] 采用特性分支开发流程，通过 PR 合并到主分支
|
||||
- [ ] 配置 Jenkins 流水线，实现 Terraform Plan/Apply 自动化
|
||||
- [ ] 探索 TerraTest 用于基础设施变更的自动化测试
|
||||
- [ ] 确定 Active Directory 联邦访问的具体配置方案
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
id: ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security
|
||||
title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Tagging
|
||||
- Security
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
sources:
|
||||
- NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
- 问题域：传统网络安全向云原生安全的转型
|
||||
- 方法/机制：Landing Zone 规划与自动化、基于标签的安全策略、Checkpoint 防火墙的有序层逻辑
|
||||
- 结论/价值：利用标签和 SCP 强制执行标签合规性，实现精细化的流量过滤和隔离
|
||||
|
||||
## Key Claims
|
||||
- Landing Zone 部署前必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性
|
||||
- 基于标签的安全控制机制可替代传统基于 IP 的防火墙规则
|
||||
- 通过 OU（组织单元）和 SCP（服务控制策略）可防止用户篡改标签绕过安全审计
|
||||
- Checkpoint 防火墙通过有序层逻辑实现地理屏蔽、BU 隔离、产品隔离及环境隔离
|
||||
|
||||
## Key Quotes
|
||||
> "DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化" — Steve Jarman
|
||||
> "通过 SCP 的'显式拒绝'逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属" — 视频内容
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Landing Zones]]：能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架
|
||||
- [[Tagging Methodology]]：标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
|
||||
- [[Service Control Policies]]：服务控制策略，用于管理组织中的权限，强制执行标签合规性
|
||||
- [[Organizational Unit]]：组织单元，AWS Organizations 中账号的分组容器
|
||||
- [[Checkpoint Firewall]]：部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤
|
||||
- [[Transit Gateway]]：传输网关，作为网络中心枢纽，连接 VPC 与本地网络
|
||||
- [[Ordered Layer]]：有序层，防火墙策略的一种组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
|
||||
- [[SRE]]：站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：全球最大公有云平台
|
||||
- [[Gruntwork]]：Gruntwork Landing Zones 框架提供商
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← depends_on ← [[CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security]]
|
||||
- [[CTP Topic 28 AWS Tag Validation Tool]] ← extends ← [[Tagging Methodology]]
|
||||
- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← depends_on ← [[AWS Landing Zones]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统基于 IP 的防火墙方案冲突：
|
||||
- 冲突点：网络边界防护模式
|
||||
- 当前观点：基于标签的动态安全控制
|
||||
- 对方观点：基于 IP 的静态防火墙规则
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 11 AD Integration and Login using AD accounts"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- AD
|
||||
- IAM
|
||||
- SSO
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题：Jenkins 与 Active Directory 集成实现自动登录，以及 CI/CD 流水线自动化安全检查
|
||||
- 问题域：DevOps 身份认证、基础设施代码质量控制
|
||||
- 方法/机制：AD 集成实现用户自动认证，pre-commit 框架嵌入 terraform fmt、TFLint、Checkov 工具
|
||||
- 结论/价值：简化用户入职/离职的账号管理，自动化检测"坏代码"和安全漏洞，提升 IaC 安全性和稳定性
|
||||
|
||||
## Key Claims
|
||||
|
||||
- AD 集成后无需手动创建本地用户，实现基于 AD 账号的自动登录
|
||||
- 下一步将利用 AD 组策略实现 RBAC 权限管理（只读、读写、流水线创建权限）
|
||||
- pre-commit 框架在代码提交阶段执行 terraform fmt、TFLint、Checkov 三大检查
|
||||
- 分层治理模式：Commit 阶段仅自动化检查 → PR 阶段执行检查+terraform plan → 合并后人工审核+terraform apply
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "通过 AD 集成，团队告别了过去手动创建本地用户的繁琐流程，实现了基于 AD 账号的自动登录。这不仅简化了用户入职与离职的账号管理，还为未来实施基于角色的访问控制（RBAC）奠定了基础。"
|
||||
|
||||
> "pre-commit 框架用于管理和维护多语言预提交钩子，在代码提交至仓库前识别简单问题。"
|
||||
|
||||
> "工作流设计强调'左移'思想：在功能分支的每次提交时仅触发自动化检查；在 PR 阶段触发检查与 terraform plan；只有在代码合并至 Master 分支并经过人工审核后，才会执行最终的 terraform apply。"
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[AD Integration]]：将 Jenkins 安全域与企业 AD 关联，实现用户身份统一认证
|
||||
- [[RBAC]]：基于角色的访问控制，通过 AD 组策略决定用户在 Jenkins 中的操作权限
|
||||
- [[Pre-commit Framework]]：管理预提交钩子的框架，提交前自动检查代码
|
||||
- [[terraform fmt]]：Terraform 内置格式化工具，统一代码风格
|
||||
- [[TFLint]]：Terraform 静态分析工具，检查代码错误、过时语法、缺失参数
|
||||
- [[Checkov]]：IaC 安全扫描工具，检测安全配置错误
|
||||
- [[Static Analysis]]：静态分析，不运行代码而检查潜在错误/漏洞
|
||||
- [[CI/CD 左移]]：在流水线早期阶段嵌入质量门禁
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Jenkins]]：开源自动化服务器，用于 CI/CD
|
||||
- [[Niranjan]]：本次 DevOps Cloud Learning Session 主讲人
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Jenkins]] ← 使用 ← [[AD Integration]]
|
||||
- [[AD Integration]] → 依赖 → [[Active Directory]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[terraform fmt]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[TFLint]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[Checkov]]
|
||||
- [[CI/CD 左移]] → 包含 → [[Pre-commit Framework]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- （暂无）
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 12 Using SES SMTP service terraform module"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Terraform
|
||||
- SES
|
||||
- Email
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：利用 AWS SES SMTP Terraform 模块实现云端邮件发送
|
||||
- 问题域：传统本地 SMTP 网关向云端迁移
|
||||
- 方法/机制：SES SMTP 端点 + VPC 终端节点 + IAM 用户凭证 + Secrets Manager
|
||||
- 结论/价值：替代传统 smtbmicrofocus.com 网关，实现安全的云端邮件发送
|
||||
|
||||
## Key Claims
|
||||
- SES 是云安全部门唯一批准的云端邮件发送方案
|
||||
- SES Terraform 模块封装了 SMTP 终端节点配置，应用程序可通过标准 SMTP 协议集成
|
||||
- VPC 终端节点确保应用与 SES 通信时不访问公网
|
||||
- IAM 用户凭证转换为 SMTP 认证信息，存储在 Secrets Manager 中
|
||||
|
||||
## Key Quotes
|
||||
> "随着业务向云端迁移，使用本地 SMTP 网关已不再高效" — Christian Deckelmann
|
||||
|
||||
> "需要手动申请脱离 SES Sandbox Mode 才能提升发送限额并允许向外部地址发信" — Filos Christolakis
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS SES]]：基于云的邮件发送服务
|
||||
- [[SMTP Endpoint]]：区域性邮件传输协议终端节点
|
||||
- [[Sandbox Mode]]：SES 默认限制状态
|
||||
- [[DKIM]]：电子邮件验证标准
|
||||
- [[VPC Endpoint]]：AWS 私有网络终端节点
|
||||
- [[Secrets Manager]]：凭证管理服务
|
||||
|
||||
## Key Entities
|
||||
- [[Christian Deckelman]]：Micro Focus 云架构师，分享者
|
||||
- [[Filos Christolakis]]：SES Terraform 模块开发者
|
||||
- [[Micro Focus]]：云转型企业
|
||||
|
||||
## Connections
|
||||
- [[SES SMTP Terraform Module]] ← depends_on ← [[VPC Wrapper Module]]
|
||||
- [[SES SMTP Terraform Module]] ← depends_on ← [[Secrets Manager]]
|
||||
- [[SES]] ← extends ← [[AWS Service]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Aliases
|
||||
- SES: Simple Email Service
|
||||
- SMTP: Simple Mail Transfer Protocol
|
||||
- DKIM: DomainKeys Identified Mail
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs"
|
||||
type: source
|
||||
tags: [AWS, FinOps, Cost-Optimization, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云成本优化最佳实践与 Micro Focus 政策
|
||||
- 问题域：企业云成本管理、成本可见性、资源优化
|
||||
- 方法/机制：PCG 服务分层、标签合规、Reserved Instances、集中管理、实例标准化
|
||||
- 结论/价值：通过可见性、标准化和自动化实现云成本优化
|
||||
|
||||
## Key Claims
|
||||
- PCG 团队通过三层服务（成本管理、成本优化、治理与自动化）实现云成本控制
|
||||
- 标签合规是成本可视化的基础，强制要求所有资源使用标准标签
|
||||
- 集中管理 Reserved Instances 和 Savings Plans 可实现组织级成本优化
|
||||
- Cloud Health 是核心工具，提供资源清单、成本分析和月度账单洞察
|
||||
- 标准化实例类型（M/T/C/R/X 系列）和 Graviton 实例可显著降低计算成本
|
||||
|
||||
## Key Quotes
|
||||
> "确保账单可见是成本管理的第一步" — Uday (PCG)
|
||||
> "账户负责人负责控制在预算内" — Vinay (PCG)
|
||||
|
||||
## Key Concepts
|
||||
- [[PCG-Public-Cloud-Governance]]：公共云治理框架，提供工作负载放置、成本和优化指导
|
||||
- [[Cost-Optimization]]：成本优化，通过技术手段降低云资源支出
|
||||
- [[Showback-Chargeback]]：成本分摊机制，用于内部成本核算
|
||||
- [[Cloud-Health]]：云成本分析和监控工具
|
||||
- [[Reserved-Instances]]：预留实例，承诺使用量换取价格折扣
|
||||
- [[Savings-Plans]]： savings plans，与 Reserved Instances 类似的价格优化方案
|
||||
- [[Graviton]]：AWS ARM 处理器实例，比 Intel 更具成本效益
|
||||
- [[Tagging-Methodology]]：标签方法论，通过标准化元数据实现资源管理
|
||||
|
||||
## Key Entities
|
||||
- [[PCG-Team]]：Public Cloud Governance 团队，主讲云 FinOps 政策
|
||||
- [[AWS]]：云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[PCG-Team]] ← provides ← [[Cost-Optimization]]
|
||||
- [[Cloud-Health]] ← monitors ← [[AWS]]
|
||||
- [[Reserved-Instances]] ← reduces_cost ← [[AWS]]
|
||||
- [[Graviton]] ← alternative_to ← [[Intel-Instances]]
|
||||
- [[Tagging-Methodology]] ← enables ← [[Cost-Visibility]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突记录
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
id: ctp-topic-14-octane-hub-on-aws-real-life-experience
|
||||
title: "CTP Topic 14 Octane Hub on AWS: Real-Life Experiences"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Octane-Hub
|
||||
- Migration
|
||||
- CTP
|
||||
- Cloud-Migration
|
||||
- Landing-Zone
|
||||
sources:
|
||||
- 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
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md]]
|
||||
|
||||
## Summary
|
||||
- **核心主题**：Octane Hub 将生产服务从本地数据中心迁移到 AWS 的真实经验分享
|
||||
- **问题域**：云迁移规划、技术选型、网络配置、存储方案、IaC 实施
|
||||
- **方法/机制**：
|
||||
- Docker 容器化部署模式
|
||||
- Packer + Terraform/TerraGrunt 基础设施即代码
|
||||
- VPC Transit Gateway 网络互联
|
||||
- 标签系统资源管理
|
||||
- EBS + EFS 分层存储策略
|
||||
- **结论/价值**：通过紧密镜像现有设置实现无缝过渡，验证了 Landing Zone 架构的可行性
|
||||
|
||||
## Key Claims
|
||||
- Octane Hub 团队使用 Docker 容器运行各种 Web 应用，包括 QuickSee、Release Manager、Patch Manager 等，处理约 10TB 文件存储和大型 MSSQL 数据库
|
||||
- 云迁移的动因是 Bibling 数据中心即将关闭，目标是实现无缝过渡，紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更
|
||||
- 初始考虑 EFS 用于存储，但因性能问题（数据库无法直接在 EFS 上运行）不适用，改用 EBS 用于实时数据库，EFS 用于备份
|
||||
- 部署方式从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署
|
||||
- 网络问题需要多次 PCS 请求，与网络团队协作解决，使用 VPC Transit Gateway 并实施标签系统管理访问
|
||||
- DNS 设置使用 Cname 指向 AWS software infra.net 域，通过 Route 53 管理
|
||||
|
||||
## Key Quotes
|
||||
> "云转型计划提供了帮助，团队在 5 月左右获得了概念验证 Landing Zone 账户的访问权限，随后在 6 月获得了生产账户"
|
||||
> "团队目标是实现无缝过渡，紧密镜像现有设置以避免在 Go Live 期间进行重大技术变更"
|
||||
> "最初考虑 EFS 用于存储，但由于性能问题（数据库无法直接在 EFS 上运行）不适用，改用 EBS 用于实时数据库"
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-容器化]]：Octane Hub 的主要部署模式，容器化遗留应用实现云就绪
|
||||
- [[Packer]]：用于构建自定义 AMI 的工具
|
||||
- [[Terraform-TerraGrunt]]：基础设施即代码的部署流程
|
||||
- [[VPC-Transit-Gateway]]：AWS 网络互联解决方案
|
||||
- [[标签系统]]：基于角色和环境管理资源访问
|
||||
- [[EFS-vs-EBS]]：文件存储与块存储的性能差异，EFS 不适合数据库场景
|
||||
- [[Multi-Account-Strategy]]：AWS 多账号架构策略
|
||||
|
||||
## Key Entities
|
||||
- [[Octane-Hub]]：一家软件公司，演讲者 Holger Rode 为其 CTO 软件工厂团队负责人
|
||||
- [[AWS]]：Amazon Web Services，AWS 云平台
|
||||
- [[Holger-Rode]]：Octane Hub CTO 软件工厂团队负责人，分享迁移经验
|
||||
|
||||
## Connections
|
||||
- [[Octane-Hub]] ← uses ← [[Docker-容器化]]
|
||||
- [[Docker-容器化]] ← managed_by ← [[Terraform-TerraGrunt]]
|
||||
- [[AWS-Landing-Zone]] ← enables ← [[Multi-Account-Strategy]]
|
||||
- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
|
||||
## Contradictions
|
||||
- 与 Landing Zone 最佳实践可能存在差异：
|
||||
- 冲突点：EFS 原被考虑用于存储，后因性能问题放弃
|
||||
- 当前观点：数据库应使用 EBS 块存储而非 EFS 文件存储
|
||||
- 对方观点：为了简化管理，优先选择托管存储服务
|
||||
|
||||
## Action Items
|
||||
- [ ] 评估现有工作负载是否适合容器化
|
||||
- [ ] 规划数据库从 MSSQL 到 Postgres 的迁移路径
|
||||
- [ ] 检查 EBS/EFS 存储选型是否合理
|
||||
- [ ] 制定 DR 和高可用性改进计划
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 15 Working with Renovatebot"
|
||||
type: source
|
||||
tags: [Renovatebot, Dependency-Update, GitOps, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：利用 Renovate Bot 自动化管理云原生基础设施中的依赖项更新
|
||||
- 问题域：云原生依赖管理、CI/CD 自动化、手动更新版本号耗时耗力
|
||||
- 方法/机制：通过 Renovate Bot 扫描代码库，识别过时版本标签，自动发起 Pull Request
|
||||
- 结论/价值：提升基础设施安全性，确保开发与生产环境配置一致性
|
||||
|
||||
## Key Claims
|
||||
- Renovate Bot 能实时扫描代码库，识别过时的版本标签并自动发起 PR
|
||||
- Dependency Dashboard 在一个 GitHub Issue 中列出所有待更新的项，提供全局视角
|
||||
- 团队通过配置 renovate.json 文件定义管理策略，支持 Terraform、Terragrunt、Docker 等多种技术栈
|
||||
- 方案已集成到 Jenkins 流水线，通过本地 Podman 容器化运行和速率限制配置实现自动化
|
||||
|
||||
## Key Quotes
|
||||
> "在复杂的云架构中，依赖项无处不在，包括 Docker 基础镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等。" — Paul Hopkins
|
||||
|
||||
> "团队在维护大量基于 Gruntwork 的 Terraform 模块和 Terragrunt 配置时，面临着手动更新版本号耗时耗力且极易滞后的挑战。" — Paul Hopkins
|
||||
|
||||
## Key Concepts
|
||||
- [[Renovate Bot]]：开源依赖自动化更新工具
|
||||
- [[Dependency Management]]：依赖管理
|
||||
- [[Semantic Versioning]]：语义化版本控制
|
||||
- [[Dependency Dashboard]]：依赖仪表板
|
||||
- [[Rate Limiting]]：速率限制
|
||||
- [[Pre-commit Hooks]]：提交前钩子
|
||||
|
||||
## Key Entities
|
||||
- [[Paul Hopkins]]：本次会议主讲人
|
||||
- [[Gruntwork]]：Terraform 模块供应商
|
||||
- [[Renovate]]：开源依赖更新工具
|
||||
|
||||
## Connections
|
||||
- [[Terraform and Terragrunt Best Practices]] ← extends ← [[CTP Topic 15 Working with Renovatebot]]
|
||||
- [[Pre-commit Hooks and Linting Sessions]] ← related_to ← [[CTP Topic 15 Working with Renovatebot]]
|
||||
|
||||
## Contradictions
|
||||
- （文档中未发现明显冲突）
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 16 Cross-account Terraform modules"
|
||||
type: source
|
||||
tags: [terraform, cross-account, modules, ctp, devops]
|
||||
source: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在多账号 AWS 环境中实现和管理跨账号 Terraform 模块
|
||||
- 问题域：如何在不授予直接互访权限的情况下，在一个模块中跨多个账号创建资源
|
||||
- 方法/机制：基于 Shared Account 的中心化部署方案，通过 cross-account.json 标记文件触发 ECS Deploy Runner，Assume Role 访问目标账号
|
||||
- 结论/价值：实现安全性（集中权限控制）、自动化（自动识别模块类型）、可复用性（代码不硬编码账号角色）
|
||||
|
||||
## Key Claims
|
||||
- Cross-account Modules 通过配置多个 Provider 实现在多个 AWS 账号中同时创建或管理资源
|
||||
- Shared Account 作为信任源，通过 Assume Role 方式访问目标账号，避免直接授予互访权限
|
||||
- cross-account.json 标记文件告知 Jenkins 该模块需要调用跨账号部署逻辑
|
||||
|
||||
## Key Quotes
|
||||
> "在多账号 AWS 环境中，经常需要在一个模块内跨多个账号创建资源，但直接赋予账号间互访权限存在巨大的安全风险" — Fibos
|
||||
|
||||
> "利用托管 Jenkins 的 Shared Account 作为中转站，实现中心化的跨账号部署" — Fibos
|
||||
|
||||
## Key Concepts
|
||||
- [[Cross-account Modules]]：在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能
|
||||
- [[Shared Account]]：整个 Landing Zone 中的核心管理账号，托管 Jenkins、镜像仓库等公共服务，并作为跨账号部署的信任源
|
||||
- [[ECS Deploy Runner]]：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply 命令
|
||||
- [[Cross-account.json]]：约定俗成的标记文件，放置在模块目录中，用于告知 Jenkins 该模块需要调用跨账号部署逻辑
|
||||
|
||||
## Key Entities
|
||||
- [[Fibos]]：本次会议讲师
|
||||
- [[Gruntwork Pipeline]]：原有的单账号部署流水线
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Pipeline Deep Dive]] ← depends_on ← [[CTP Topic 16 Cross-account Terraform modules]]
|
||||
- [[AWS Multi-account Security Best Practices]] ← informs ← [[CTP Topic 16 Cross-account Terraform modules]]
|
||||
- [[Terragrunt Advanced Configuration]] ← used_by ← [[CTP Topic 16 Cross-account Terraform modules]]
|
||||
|
||||
## Contradictions
|
||||
- 与直接授予 Workload 账号间互访权限的方案冲突：
|
||||
- 冲突点：直接授予互访权限存在 Blast Radius 安全风险
|
||||
- 当前观点：通过 Shared Account 集中控制权限，Assume Role 访问
|
||||
- 对方观点：直接授予账号间互访权限简化配置
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- AD
|
||||
- Gruntwork
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
## Source File
|
||||
[[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Gruntwork AWS Landing Zones 架构中集成和管理 Active Directory 服务
|
||||
- 问题域：R&D Labs 生产环境域名的选择与迁移，旧域名（infra/AST）废弃
|
||||
- 方法/机制：使用 SRE 预制 AMIs 实现自动域加入，通过 Terraform user_data 调用 PowerShell/Shell 脚本
|
||||
- 结论/价值：明确域名规范（swinford.net 用于研发环境，intsas.local 用于生产/SAS 环境），提供自动化域加入方案和支持渠道
|
||||
|
||||
## Key Claims
|
||||
- R&D Labs 环境统一使用 swinford.net 域名，支持自助服务管理
|
||||
- 生产与分阶段 SAS 环境使用 intsans.local 域名，强调资源所有权和审计
|
||||
- 旧的 infra 和 AST 域名已在 Gruntwork 落地页中废弃，需要迁移
|
||||
- SRE 团队提供的预制 AMIs 内置自动域加入脚本（PowerShell/Shell）
|
||||
- MIM 自助工具用于研发环境的安全组管理和权限申请
|
||||
- SMACKS 工单系统用于生产环境账号申请和密码重置
|
||||
|
||||
## Key Quotes
|
||||
> "本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践"
|
||||
|
||||
> "研发实验室（R&D Labs）统一使用 `swinford.net` 域名"
|
||||
> "生产与分阶段 SAS 环境则采用 `intsas.local`"
|
||||
|
||||
> "旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃"
|
||||
|
||||
## Key Concepts
|
||||
- [[Gruntwork-Landing-Zone]]: Gruntwork 提供的预配置 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型
|
||||
- [[SRE-provided-AMIs]]: SRE 团队预先构建的机器镜像，内置用于自动加入域的 PowerShell 和 Shell 脚本
|
||||
- [[Domain-Join]]: 通过 SRE-provided AMIs 在 Terraform user_data 中调用脚本实现自动化域加入
|
||||
- [[MIM]]: Microsoft Identity Manager，用于 R&D 环境的安全组管理和权限申请
|
||||
- [[SMACKS-Ticket]]: 内部服务管理工单系统，用于申请新账号、密码重置、生产环境变更
|
||||
- [[Secure-Dynamic-Updates]]: 安全机制，允许 Linux 系统加入域时自动注册 DNS A 记录
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]: 全球最大公有云平台，Hosting Landing Zones 基础设施
|
||||
- [[Gruntwork]]: 提供 Landing Zone 框架的公司，定义环境域名规范
|
||||
- [[Paul]]: 视频演讲者，详细阐述 AD 服务集成方案
|
||||
- [[SRE-Team]]: 构建和提供预制 AMIs 的团队
|
||||
|
||||
## Connections
|
||||
- [[AWS-Landing-Zone]] ← uses ← [[Gruntwork-Landing-Zone]]
|
||||
- [[SRE-provided-AMIs]] ← implements ← [[Domain-Join]]
|
||||
- [[MIM]] ← manages ← [[swinford.net]]
|
||||
- [[SMACKS-Ticket]] ← processes ← [[intsas.local]]
|
||||
|
||||
## Contradictions
|
||||
- 与旧域名规范冲突：
|
||||
- 冲突点：旧的 infra 和 AST 域名已被废弃
|
||||
- 当前观点：统一使用 swinford.net（研发）和 intsas.local（生产）
|
||||
- 对方观点：继续使用 infra/AST 域名
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "CTP Topic 18 Wide Area Networking in AWS Cloud"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- WAN
|
||||
- Networking
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AWS 云环境中的广域网（WAN）架构设计及其演进路径
|
||||
- 问题域：大型企业跨国云网络管理、跨区域连接、远程访问优化
|
||||
- 方法/机制：Transit Gateway (TGW) 星型拓扑、SD-WAN 叠加网络、Prisma Access SASE 架构
|
||||
- 结论/价值：展示从传统静态路由到智能SD-WAN演进的完整路径，为企业云网络架构提供实践参考
|
||||
|
||||
## Key Claims
|
||||
- Transit Gateway 是 AWS 区域级网络中转服务，连接 VPC、本地网络及跨区域 TGW
|
||||
|
||||
## Key Quotes
|
||||
> "将全球划分为三个地理区域（APJ、EMEA、AMS），每个区域设立一个核心 Hub（如 EMEA 的伦敦，AMS 的俄勒冈）。所有 Landing Zones 通过 TGW Peering 接入区域 Hub，形成星型拓扑"
|
||||
|
||||
> "当前 TGW 间的路由主要基于静态前缀列表（Prefix Lists），缺乏动态路由协议（如 BGP）支持"
|
||||
|
||||
> "计划引入 Silver Peak 的 SD-WAN 方案作为叠加网络（Overlay），实现动态路径选择和自动化流量调度"
|
||||
|
||||
> "计划将传统 Pulse VPN 迁移至 Palo Alto 的 Prisma Access（SASE 架构）"
|
||||
|
||||
## Key Concepts
|
||||
- [[Transit Gateway]]：AWS 区域级网络中转服务
|
||||
- [[Landing Zone]]：企业标准化的 AWS 多账号环境
|
||||
- [[Hub-and-Spoke]]：星型拓扑结构
|
||||
- [[SD-WAN]]：软件定义广域网
|
||||
- [[Prisma Access]]：Palo Alto 的 SASE 安全访问服务
|
||||
- [[Overlay Network]]：叠加网络
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：亚马逊云服务平台
|
||||
- [[Christian Deckelman]]：Micro Focus IT 网络架构师，演讲人
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 34 Azure Landing Zone Architecture Overview]] ← relates_to ← [[Landing Zone]]
|
||||
- [[CTP Topic 22 Global DNS service offerings]] ← relates_to ← [[WAN]]
|
||||
- [[CTP Topic 19 Configuring DNS within AWS LZs]] ← relates_to ← [[Landing Zone]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## Source
|
||||
- NAS: /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 18_ Wide Area Networking in AWS Cloud.mp4
|
||||
|
||||
---
|
||||
*last_updated: 2026-04-14*
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user