Update nexus wiki content
This commit is contained in:
58
wiki/entities/1point3acres.md
Normal file
58
wiki/entities/1point3acres.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "1point3acres（一亩三分地）"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [study-abroad-advisor]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
# 1point3acres（一亩三分地）
|
||||
|
||||
## Definition
|
||||
|
||||
1point3acres（一亩三分地）——中国最具影响力的留学生社区论坛之一，专注于北美（美国、加拿大）留学申请、求职就业、移民签证等话题。域名取自成语"皇帝不到一亩三分地"，寓意社区聚焦留学生个人发展和留学生活。
|
||||
|
||||
## Core Functions
|
||||
|
||||
| 功能 | 说明 |
|
||||
|------|------|
|
||||
| 录取数据库 | 申请者自主提交 offer/ rejection 数据，可按学校、专业、GPA 等筛选 |
|
||||
| 就职论坛 | 留学生就业经验分享、薪资数据、公司点评 |
|
||||
| 签证移民 | F-1、H-1B、绿卡申请经验与政策讨论 |
|
||||
| 申请选校 | 在校生/校友分享真实就读体验和就业去向 |
|
||||
| 找工跳槽 | 内推信息、面试经验、薪资谈判 |
|
||||
|
||||
## Key Data Products
|
||||
|
||||
### 录取数据库（Admission Database）
|
||||
- 用户自主上传 offer/rejection 记录
|
||||
- 包含 GPA、GT 成绩、本科背景、申请结果、时间线等
|
||||
- 可按学校+项目筛选，查看历史录取趋势
|
||||
- 是 Study Abroad Advisor 用于数据驱动选校的重要参考来源之一
|
||||
|
||||
### 就职薪资数据
|
||||
- 用户匿名提交 base/signing/total compensation
|
||||
- 按公司/职位/地点/年级分层
|
||||
- 是北美留学生了解行业薪资水平的重要参考
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
[[study-abroad-advisor]] 在进行选校推荐时，鼓励学生通过 1point3acres 验证关键数据：
|
||||
- 通过校友页/在读生分享核实专业真实就读体验
|
||||
- 通过录取数据库交叉验证选校概率区间
|
||||
- 通过就职论坛评估毕业后就业前景
|
||||
|
||||
该论坛也是学生发现"信息不对称"的重要工具——例如某项目实际录取偏好与官网描述存在差异时，社区会及时披露。
|
||||
|
||||
## Reliability Considerations
|
||||
|
||||
- **数据来源**：用户自主提交，存在样本偏差（成功者偏差）——拿到 offer 的用户更倾向于提交
|
||||
- **时效性**：录取偏好每年可能有变化，需关注最新一年的数据
|
||||
- **非官方**：数据为社区整理，不代表学校官方立场
|
||||
- **建议交叉验证**：与学校官网、LinkedIn Alumni、专业报告等交叉参考
|
||||
|
||||
## Aliases
|
||||
- 一亩三分地
|
||||
- 1point3acres
|
||||
- Yimu Sanfendi
|
||||
- 1p3a
|
||||
35
wiki/entities/Adaptive-Capacity-Labs.md
Normal file
35
wiki/entities/Adaptive-Capacity-Labs.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Adaptive Capacity Labs"
|
||||
type: entity
|
||||
tags: [sre, reliability, research, consulting]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Adaptive Capacity Labs
|
||||
|
||||
Adaptive Capacity Labs 由 John Allspaw 和 Dr. Richard I. Cook 创办，专注于系统可靠性和组织韧性的研究与咨询。
|
||||
|
||||
## Aliases
|
||||
- Adaptive Capacity Labs
|
||||
- ACL (abbreviation)
|
||||
|
||||
## Overview
|
||||
该实验室的研究重点是理解复杂 socio-technical 系统中的故障和恢复机制，其两位创始人在 SRE 和 Resilience Engineering 领域极具影响力。
|
||||
|
||||
## Key Contributions
|
||||
- **Organizational Second Hit Syndrome**：提出组织层面的"二次冲击综合征"概念，类比神经学中的 second-impact syndrome
|
||||
- **Resilience Engineering**：推动韧性工程作为 SRE 的核心理论基础
|
||||
- **Incident Analysis**：基于《Working Together》和其他著作，建立了对故障协作处理的系统性认识
|
||||
|
||||
## Key People
|
||||
- [[John-Allspaw]]：联合创始人，SRE 先驱，前 Etsy CTO
|
||||
- [[Richard-Cook]]：联合创始人，医学博士，系统 resilience 研究者
|
||||
|
||||
## Related Concepts
|
||||
- [[Organizational-Second-Hit-Syndrome]]
|
||||
- [[Resilience]]
|
||||
- [[BlamelessPostMortem]]
|
||||
- [[Incident-Response]]
|
||||
|
||||
## Source
|
||||
- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
|
||||
61
wiki/entities/Agentforce.md
Normal file
61
wiki/entities/Agentforce.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Agentforce"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [specialized-french-consulting-market]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# Agentforce
|
||||
|
||||
## Aliases
|
||||
- Agentforce
|
||||
- Salesforce Agentforce
|
||||
- Agentforce Studio
|
||||
- Einstein Agent
|
||||
|
||||
## Definition
|
||||
|
||||
Agentforce 是 Salesforce 于 2024-2025 年推出的 AI Agent 产品线，为 CRM 平台提供企业级 AI 自动化能力。通过 Agentforce，Salesforce 用户可以构建、部署和管理定制化 AI Agent，以自动化客户服务、销售流程、营销运营等业务场景。
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### Agentforce Studio
|
||||
- 可视化低代码环境，用于构建和管理 AI Agent
|
||||
- 支持预构建模板和自定义 Agent 开发
|
||||
- 内置监控、调试和性能追踪
|
||||
|
||||
### 预构建 Agent（Out-of-the-Box）
|
||||
| Agent 类型 | 适用场景 |
|
||||
|-----------|---------|
|
||||
| Service Agent | 客户服务自动化（退款、退换货、技术支持） |
|
||||
| Sales Agent | 销售线索qualification和跟进自动化 |
|
||||
| Marketing Agent | 个性化营销内容和发送时机优化 |
|
||||
| Warehouse Agent | 库存管理和物流协调 |
|
||||
|
||||
### Data Cloud 集成
|
||||
Agentforce 的核心差异化在于与 Data Cloud（统一数据平台）的深度集成：
|
||||
- 所有 Agent 共享同一实时数据模型
|
||||
- 支持非 Salesforce 数据的接入（通过 Connectors）
|
||||
- 实现真正的全渠道客户视图
|
||||
|
||||
## Market Value in French Consulting
|
||||
|
||||
在法国 ESN/SI 咨询市场中，Agentforce + Data Cloud 的组合专家享有最高的市场溢价：
|
||||
|
||||
- **TJM 定位**：700-850 EUR/天（较通用 Salesforce Architect 高出 15-30%）
|
||||
- **供需关系**：供给严重不足，需求增长迅速
|
||||
- **谈判优势**：掌握 Agentforce 的顾问在谈判中有显著议价能力
|
||||
|
||||
> "Lead with the niche, not the platform" — 建议顾问在定位时突出 Data Cloud + Agentforce 组合，而非泛泛的"Salesforce Architect"
|
||||
|
||||
## Relationship to Salesforce Ecosystem
|
||||
|
||||
Agentforce 是 Salesforce Einstein 1 Platform 的核心演进：
|
||||
- 建立在 Einstein AI 能力之上（Einstein Copilot → Agentforce）
|
||||
- 与 Apex、Flow、Platform Events 无缝集成
|
||||
- 支持通过 Agentforce SDK 扩展自定义行为
|
||||
|
||||
## Related Sources
|
||||
- [[specialized-french-consulting-market]]
|
||||
- [[Salesforce]]
|
||||
44
wiki/entities/AgentsOrchestrator.md
Normal file
44
wiki/entities/AgentsOrchestrator.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "AgentsOrchestrator"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [agents-orchestrator]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
The **Agents Orchestrator** is the central pipeline manager of The Agency — an autonomous agent that coordinates the entire development workflow from specification to production-ready delivery.
|
||||
|
||||
## Role
|
||||
- **Role**: Autonomous workflow pipeline manager and quality orchestrator
|
||||
- **Personality**: Systematic, quality-focused, persistent, process-driven
|
||||
- **Vibe**: "The conductor who runs the entire dev pipeline from spec to ship."
|
||||
|
||||
## Core Responsibilities
|
||||
- Orchestrate full workflow pipeline: PM → ArchitectUX → [Dev ↔ QA Loop] → Integration
|
||||
- Ensure each phase completes successfully before advancing
|
||||
- Coordinate agent handoffs with proper context and instructions
|
||||
- Implement continuous Dev-QA quality loops
|
||||
- Enforce quality gates (max 3 retries per task before escalation)
|
||||
|
||||
## Pipeline Phases
|
||||
1. **Phase 1**: Project Manager Senior creates task list from spec
|
||||
2. **Phase 2**: ArchitectUX creates technical architecture foundation
|
||||
3. **Phase 3**: [Developer ↔ EvidenceQA] continuous loop until all tasks pass
|
||||
4. **Phase 4**: Testing Reality Checker performs final integration validation
|
||||
|
||||
## Spawns
|
||||
- [[ProjectManagerSenior]]
|
||||
- [[ArchitectUX]]
|
||||
- [[EvidenceQA]]
|
||||
- [[TestingRealityChecker]]
|
||||
- [[FrontendDeveloper]]
|
||||
- [[BackendArchitect]]
|
||||
- [[MobileAppBuilder]]
|
||||
- [[DevOpsAutomator]]
|
||||
|
||||
## Coordinated By
|
||||
- Part of [[The Agency]] Specialized Department
|
||||
|
||||
## Sources
|
||||
- [[agents-orchestrator]]
|
||||
18
wiki/entities/Aider.md
Normal file
18
wiki/entities/Aider.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Aider"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
Aider 是一个终端 AI 编程工具，支持与 Git 深度集成的 AI 结对编程。The Agency 将所有 Agent 合并为一个 `CONVENTIONS.md` 文件，Aider 在项目根目录自动读取。
|
||||
|
||||
## Key Facts
|
||||
- Agent 格式：`CONVENTIONS.md`（单文件汇总）
|
||||
- 作用域：Project-Scoped（项目级）
|
||||
- 安装方式：从项目根目录运行 `./scripts/install.sh --tool aider`
|
||||
- 自动发现：Aider 自动在项目根目录查找 `CONVENTIONS.md`
|
||||
|
||||
## Sources
|
||||
- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
|
||||
35
wiki/entities/Alex-Product-Manager.md
Normal file
35
wiki/entities/Alex-Product-Manager.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Alex (Product Manager)"
|
||||
type: entity
|
||||
tags: ["persona", "product-management", "the-agency"]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Alex
|
||||
- Product Manager Alex
|
||||
|
||||
## Entity Type
|
||||
**Persona** — 虚构的产品经理角色，代表 The Agency 中 Product Manager Agent 的人格化形象。
|
||||
|
||||
## Definition
|
||||
Alex 是 The Agency 产品部门 Product Manager Agent 的人格化角色设定：一名具有 10 年以上产品管理经验的专业人士，横跨 B2B SaaS、消费者应用和平台业务三大领域。Alex 曾领导产品从零到一上线、高增长扩展以及企业级转型，有处理线上故障止损、在预算周期中争夺路线图空间、执行艰难否决决策等实战经验。
|
||||
|
||||
## Key Attributes
|
||||
- **理念**：以结果为导向，而非产出。功能是假设，发布是实验，成功的功能必须可量化地改变用户行为。
|
||||
- **超能力**：在用户需求、商业要求和工程现实三者之间保持张力，找到三者对齐的路径。
|
||||
- **风格**：团队专注度的守护者；用正确的问题让房间更聪明；外交式的直接；书面优先、异步沟通。
|
||||
|
||||
## Products Owned
|
||||
- [[Product Requirements Document (PRD)]] — Alex 的核心交付物模板
|
||||
- [[Go-to-Market (GTM) Brief]] — 发布协调文档
|
||||
- [[Product Roadmap (Now/Next/Later)]] — 路线图维护
|
||||
|
||||
## Frameworks Used
|
||||
- [[Outcome vs. Output]] — 决策思维框架
|
||||
- [[RICE Prioritization Score]] — 需求优先级框架
|
||||
- 六阶段产品工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement
|
||||
|
||||
## Related Entities
|
||||
- [[Senior Project Manager Agent]] — 协作角色（项目管理 vs. 产品管理的分工边界）
|
||||
- [[Agents Orchestrator]] — 上游协调者
|
||||
@@ -8,7 +8,8 @@ tags:
|
||||
- Managed
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-28
|
||||
- learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -1,30 +1,33 @@
|
||||
---
|
||||
title: "Amazon Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "ecommerce", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Amazon Advertising
|
||||
- Amazon PPC
|
||||
- AMS (Amazon Marketing Services)
|
||||
|
||||
## Overview
|
||||
Amazon Ads 是亚马逊的广告平台，在电商购买场景下触达高购买意图用户。是 [[PaidMediaPpcStrategist]] 跨平台预算分配的关键组成部分。
|
||||
|
||||
## Key Capabilities
|
||||
- **Sponsored Products**: 关键词驱动的产品广告，出现在搜索结果和详情页
|
||||
- **Sponsored Brands**: 品牌展示广告，展示多个产品或品牌旗舰店
|
||||
- **Sponsored Display**: 展示型广告，覆盖亚马逊站内及站外受众
|
||||
- **Amazon DSP**: 需求方平台，支持程序化购买站内外优质广告位
|
||||
- **Amazon Marketing Cloud (AMC)**: 数据分析平台，支持跨触点归因分析
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 购物广告系列与 Google Shopping 协同
|
||||
- 基于购买意向的受众触达
|
||||
- 站内搜索场景的竞争情报
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 将 Amazon Ads 纳入跨平台预算分配框架
|
||||
- [[GoogleAds]] Shopping 与 Amazon Sponsored Products 在产品广告策略上有相似性
|
||||
---
|
||||
title: "Amazon Ads"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- amazon
|
||||
- ecommerce
|
||||
- ppc
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
Amazon Ads 是亚马逊的广告平台，提供在亚马逊站内及整个亚马逊广告生态（包括第三方出版商网络）投放广告的能力，是电商场景最重要的付费广告渠道，核心优势在于触达处于购买决策末期的消费者。
|
||||
|
||||
## Core Capabilities Referenced
|
||||
- **Sponsored Products**：在搜索结果和商品详情页推广单个商品，按点击付费（CPC），是亚马逊广告的基础产品
|
||||
- **Sponsored Brands**：在搜索结果顶部推广品牌 logo、自定义标题和最多 3 个商品，适合品牌建设和引流
|
||||
- **Sponsored Display**：基于受众和商品定向的展示广告，可在亚马逊站内及第三方网站投放
|
||||
- **Amazon DSP（Demand-Side Platform）**：程序化广告购买平台，面向品牌广告主购买亚马逊自有和第三方展示/视频库存
|
||||
- **Amazon Marketing Cloud（AMC）**：基于云的数据分析平台，支持跨触点归因和受众分析
|
||||
|
||||
## Key Value for PPC Strategy
|
||||
- **购买意图最强**：Amazon 用户处于购买决策漏斗底部，转化率远高于一般展示广告
|
||||
- **电商场景专属**：与 Google Search 的信息获取意图不同，Amazon Ads 直接面向有购买计划的消费者
|
||||
- **搜索词数据**：亚马逊搜索词报告提供独特的购买意图信号，可反哺 Google Ads 关键词策略
|
||||
|
||||
## Connections
|
||||
- [[GoogleAds]]：搜索广告主要平台，Google 侧重信息获取意图，Amazon 侧重购买意图
|
||||
- [[MicrosoftAdvertising]]：可与 Amazon 共同构成购买意图漏斗的跨平台协同
|
||||
- [[CrossPlatformPlanning]]：Google/Microsoft/Amazon 预算分配是跨平台策略核心
|
||||
|
||||
@@ -1,22 +1,28 @@
|
||||
---
|
||||
title: "Andrej Karpathy"
|
||||
type: entity
|
||||
tags: [ai, deep-learning, openai]
|
||||
---
|
||||
|
||||
## Profile
|
||||
AI 领域知名专家，曾任特斯拉 AI 总监、OpenAI 创始成员之一，现活跃于 AI 教育与开源社区。以深入浅出的技术讲解著称，创办了知名的斯坦福 CS231n 课程。
|
||||
|
||||
## Role
|
||||
- **Vibe Coding 概念推广者**：提出"我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"的经典描述
|
||||
- **AI 教育者**：通过 YouTube 视频普及深度学习、LLM 应用等知识
|
||||
- **LLM Wiki 倡导者**：分享用 LLM 构建个人知识库的理念，倡导"让 AI 增量构建 Wiki，页面间互链，知识越积越厚"
|
||||
|
||||
## Sources
|
||||
- [[github-上-5000-人收藏的-vibe-coding-神级指南]]
|
||||
- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
|
||||
## Aliases
|
||||
- Karpathy
|
||||
- Andrej
|
||||
---
|
||||
title: "Andrej Karpathy"
|
||||
type: entity
|
||||
tags: [ai, deep-learning, engineering]
|
||||
sources: [zk-steward, llm-wiki]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Karpathy
|
||||
- Andrej Karpathy
|
||||
|
||||
## Overview
|
||||
Andrej Karpathy 是著名的人工智能研究员，曾任特斯拉 AI 总监、OpenAI 创始成员之一，斯坦福 CS231n 课程的创建者。他以"first-principles engineering"（第一性工程思维）著称，在 AI/LLM 教育和技术传播方面有深远影响（Deep Learning with PyTorch、Zero-to-Hero 系列）。
|
||||
|
||||
## Core Method
|
||||
- **First-Principles Engineering**：从底层原理出发构建系统，反对盲目调用 API 而不理解底层机制
|
||||
- **Education-First**：好的技术内容必须从直觉入手，建立清晰的 mental model，而非堆砌公式
|
||||
- **Hands-On Learning**：通过写代码从头实现（从零构建神经网络），而非仅仅调用高层 API
|
||||
|
||||
## Role in ZK Steward
|
||||
ZK Steward 在"AI / 工程"任务中切换到 Karpathy 视角，驱动第一性工程思维和 deep-learning 流程。
|
||||
|
||||
## Key Connections
|
||||
- [[LLM Wiki]] ← authored_by ← [[Andrej Karpathy]]（2026 年初分享的 LLM Wiki 理念——用 LLM 构建持久化维基知识库，告别 RAG 的低效循环）
|
||||
- [[ZK-Steward-Agent]] ← uses Karpathy perspective for AI/engineering tasks
|
||||
- [[Domain-Thinking]] ← Karpathy is the reference expert for AI/engineering domain
|
||||
- [[Zettelkasten]] ← Karpathy 式的"deep-dive into LLMs"笔记（如 [[ZK-Steward-Agent]] 中引用的结构笔记示例）与 Zettelkasten 方法高度共鸣
|
||||
|
||||
29
wiki/entities/AnythingLLM.md
Normal file
29
wiki/entities/AnythingLLM.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "AnythingLLM"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "rag"
|
||||
- "open-source"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
AnythingLLM（56k stars）是一款开源 RAG AI 应用，支持 Generic OpenAI Provider 接入 Hermes Agent。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：56k
|
||||
- **License**：MIT
|
||||
- **特点**：内置 RAG 知识库功能
|
||||
- **集成方式**：Generic OpenAI Provider 配置
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过 Generic OpenAI Provider 配置：
|
||||
- **API URL**：`http://<host>:8642/v1/chat/completions`
|
||||
- **认证**：Bearer Token（`API_SERVER_KEY`）
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
43
wiki/entities/Apache-Hudi.md
Normal file
43
wiki/entities/Apache-Hudi.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Apache Hudi"
|
||||
type: entity
|
||||
tags: [data-engineering, lakehouse, open-table-format, incremental]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Apache Hudi 是另一个开放表格格式（Open Table Format），专注于 incremental processing（增量处理）和 upsert 支持。Data Engineer Agent 使用 Hudi 的 Copy-on-Write（CoW）和 Merge-on-Read（MoR）表类型实现增量数据管道。
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
### Copy-on-Write (CoW)
|
||||
- 每次写入重写数据文件（Parquet）
|
||||
- 读优化，适合写少读多的场景
|
||||
- 数据文件始终保持最优压缩
|
||||
|
||||
### Merge-on-Read (MoR)
|
||||
- 更新以 log 形式追加，读取时合并
|
||||
- 写优化，适合高频增量写入
|
||||
- 支持 late-arriving data 和 near-real-time 分析
|
||||
|
||||
### Incremental Pull
|
||||
- Hudi 提供 `incrementalQueries`，消费者只需读取自上次处理以来的变更
|
||||
- 支持 Change Log 模式（仅返回变更记录，而非全量快照）
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **CDC Ingestion**：Hudi + Debezium CDC 记录 → 增量摄取
|
||||
- **Slowly Changing Dimension (SCD)**：MoR 表支持 SCD Type 1 和 Type 2
|
||||
- **Time Travel Audit**：满足监管要求的审计日志
|
||||
|
||||
## Ecosystem Position
|
||||
|
||||
Apache Hudi 与 [[Delta Lake]] 和 [[Apache Iceberg]] 并列为三大开放表格格式。Hudi 的差异化优势在于其 incremental processing 能力和对 Spark Structured Streaming 的深度集成。
|
||||
|
||||
## Related Concepts
|
||||
- [[Delta Lake]]
|
||||
- [[Apache Iceberg]]
|
||||
- [[CDC (Change Data Capture)]]
|
||||
- [[SCD Type 2]]
|
||||
43
wiki/entities/Apache-Iceberg.md
Normal file
43
wiki/entities/Apache-Iceberg.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Apache Iceberg"
|
||||
type: entity
|
||||
tags: [data-engineering, lakehouse, open-table-format, ACID]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Apache Iceberg 是一个开放表格格式规范（Open Table Format），为数据湖提供 ACID 事务、隐藏分区、时间旅行和跨引擎互操作能力。Data Engineer Agent 使用 Iceberg 替代或与 Delta Lake 配合，实现跨引擎（Spark/Trino/Presto）读写同一份数据。
|
||||
|
||||
## Key Features
|
||||
|
||||
### ACID Transactions
|
||||
与 [[Delta Lake]] 类似，Iceberg 提供写操作的原子提交和并发控制。
|
||||
|
||||
### Hidden Partitioning（隐藏分区）
|
||||
- 分区策略由 Iceberg 自动管理，消费者无需感知分区键
|
||||
- 支持身份分区（identity）、桶分区（bucket）、日期/时间分区等
|
||||
- 避免用户误操作分区列导致数据倾斜
|
||||
|
||||
### Time Travel & Rollback
|
||||
- 通过 snapshot ID 或 timestamp 查询历史数据
|
||||
- 支持 rollback 到任意历史 snapshot
|
||||
|
||||
###跨引擎互操作
|
||||
- Spark、Trino、Presto、Flink、Hive 均可读写同一 Iceberg 表
|
||||
- 企业级数据湖多引擎共享数据的标准方案
|
||||
|
||||
## Iceberg vs. Delta Lake
|
||||
|
||||
| 特性 | Apache Iceberg | Delta Lake |
|
||||
|------|---------------|------------|
|
||||
| 起源 | Netflix/Apple 开源 | Databricks 开源 |
|
||||
| 跨引擎 | ✅ 原生多引擎 | ⚠️ 主要 Spark/Databricks |
|
||||
| 隐藏分区 | ✅ | ❌ |
|
||||
| 增量读取 | ✅ | ✅ |
|
||||
| 生态 | Trino/Presto/Flink 广泛支持 | Spark/Databricks 深度集成 |
|
||||
|
||||
## Related Concepts
|
||||
- [[Delta Lake]]（Iceberg 的主要替代方案）
|
||||
- [[Medallion Architecture]]（Iceberg 作为 Bronze/Silver/Gold 存储格式）
|
||||
65
wiki/entities/Apache-Kafka.md
Normal file
65
wiki/entities/Apache-Kafka.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "Apache Kafka"
|
||||
type: entity
|
||||
tags: [data-engineering, streaming, event-driven, real-time]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Apache Kafka 是分布式事件流平台，支持高吞吐量、低延迟的实时数据管道。Data Engineer Agent 使用 Kafka 作为流式数据摄取的核心传输层，构建 Exactly-Once 语义的实时 Bronze 层摄取管道。
|
||||
|
||||
## Core Streaming Pipeline
|
||||
|
||||
```python
|
||||
from pyspark.sql.functions import from_json, col, current_timestamp
|
||||
from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType
|
||||
|
||||
def stream_bronze_orders(kafka_bootstrap: str, topic: str, bronze_path: str):
|
||||
stream = spark.readStream \
|
||||
.format("kafka") \
|
||||
.option("kafka.bootstrap.servers", kafka_bootstrap) \
|
||||
.option("subscribe", topic) \
|
||||
.option("startingOffsets", "latest") \
|
||||
.option("failOnDataLoss", "false") \
|
||||
.load()
|
||||
|
||||
parsed = stream.select(
|
||||
from_json(col("value").cast("string"), order_schema).alias("data"),
|
||||
col("timestamp").alias("_kafka_timestamp"),
|
||||
current_timestamp().alias("_ingested_at")
|
||||
).select("data.*", "_kafka_timestamp", "_ingested_at")
|
||||
|
||||
return parsed.writeStream \
|
||||
.format("delta") \
|
||||
.outputMode("append") \
|
||||
.option("checkpointLocation", f"{bronze_path}/_checkpoint") \
|
||||
.option("mergeSchema", "true") \
|
||||
.trigger(processingTime="30 seconds") \
|
||||
.start(bronze_path)
|
||||
```
|
||||
|
||||
## Key Semantics
|
||||
|
||||
- **Exactly-Once Processing**：`checkpointLocation` + Delta Lake ACID 写入确保端到端 Exactly-Once
|
||||
- **At-Least-Once**：默认 delivery guarantee（配合幂等消费者可升级为 Exactly-Once）
|
||||
- **Late-Arriving Data**：Watermark + Event-Time 窗口处理迟到事件
|
||||
|
||||
## Streaming vs. Micro-Batch Trade-off
|
||||
|
||||
| 模式 | 延迟 | 吞吐量 | 适用场景 |
|
||||
|------|------|--------|----------|
|
||||
| Continuous（连续处理） | ~100ms | 中等 | 超低延迟需求 |
|
||||
| Micro-batch（微批次） | ~30s | 极高 | 高吞吐量、低成本 |
|
||||
|
||||
## Related Platforms
|
||||
|
||||
- **Azure Event Hubs**：Azure 托管 Kafka 兼容服务
|
||||
- **AWS Kinesis**：AWS 流式数据平台（Kafka 替代）
|
||||
- **Confluent Cloud**：Kafka 全托管云服务
|
||||
|
||||
## Related Concepts
|
||||
- [[CDC (Change Data Capture)]]
|
||||
- [[Medallion Architecture]]（Kafka → Bronze Delta Lake）
|
||||
- [[Apache Spark]]（Structured Streaming + Kafka）
|
||||
51
wiki/entities/Apache-Spark.md
Normal file
51
wiki/entities/Apache-Spark.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Apache Spark"
|
||||
type: entity
|
||||
tags: [data-engineering, big-data, processing-engine]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Apache Spark 是统一的大规模数据处理引擎，支持批处理、流处理、机器学习和 SQL 查询。Data Engineer Agent 使用 PySpark（Spark 的 Python API）作为核心计算平台，构建 Bronze→Silver→Gold ETL/ELT 管道。
|
||||
|
||||
## Key Capabilities for Data Engineering
|
||||
|
||||
### PySpark Data Pipeline
|
||||
```python
|
||||
from pyspark.sql import SparkSession
|
||||
from pyspark.sql.functions import col, current_timestamp, sha2, concat_ws, lit
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
spark = SparkSession.builder \
|
||||
.config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
|
||||
.config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
|
||||
.getOrCreate()
|
||||
```
|
||||
|
||||
### Delta Lake Integration
|
||||
- Spark + Delta Lake 是 Medallion Architecture 的标准实现组合
|
||||
- 支持 `mergeSchema=true` 处理 schema 演进
|
||||
- 支持 `MERGE INTO` 实现幂等 upsert
|
||||
|
||||
### Streaming
|
||||
- Spark Structured Streaming + Kafka：构建 Exactly-Once 语义的实时管道
|
||||
- 触发模式：Continuous（连续处理）或 Micro-batch（微批次）
|
||||
|
||||
## Performance Features
|
||||
|
||||
- **Adaptive Query Execution (AQE)**：动态分区合并、Broadcast Join 优化
|
||||
- **Z-Ordering**：多维聚类加速复合过滤查询
|
||||
- **Bloom Filters**：高基数字符串列（ID、邮箱）的文件跳过
|
||||
|
||||
## Managed Platforms
|
||||
- [[Databricks]]（Unity Catalog、DLT、Workflows）
|
||||
- [[Amazon-RDS]] / EMR（AWS Spark 托管）
|
||||
- Google Dataproc（GCP Spark 托管）
|
||||
|
||||
## Related Concepts
|
||||
- [[Medallion Architecture]]
|
||||
- [[Delta Lake]]
|
||||
- [[Apache Kafka]]
|
||||
- [[CDC (Change Data Capture)]]
|
||||
31
wiki/entities/ArchitectUX.md
Normal file
31
wiki/entities/ArchitectUX.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "ArchitectUX"
|
||||
type: entity
|
||||
tags: [ux-design, architecture, the-agency]
|
||||
sources: [design-whimsy-injector, design-ux-architect, design-ux-researcher]
|
||||
last_updated: 2026-05-15
|
||||
---
|
||||
|
||||
# ArchitectUX
|
||||
|
||||
## Definition
|
||||
|
||||
UX 架构专家 Agent（UX Architect Expert），隶属于 [[The-Agency]] Design 部门。核心使命：提供技术基础（CSS 设计系统、Grid/Flexbox 布局框架、Theme Toggle 组件），与 [[Whimsy-Injector]] 协作提供完整的品牌体验设计（技术架构 + 品牌人格）。
|
||||
|
||||
## Role
|
||||
|
||||
ArchitectUX 是 Design 部门的技术架构层，为 [[LuxuryDeveloper]] 提供：
|
||||
- CSS 设计系统（颜色/排版/间距变量）
|
||||
- Grid/Flexbox 布局框架
|
||||
- Theme Toggle 组件（light/dark/system 三态）
|
||||
- Foundation-first 理念消除开发者架构决策疲劳
|
||||
|
||||
## Relationship to Other Agents
|
||||
|
||||
- 与 [[UX-Researcher]] 互补：UX Researcher 提供用户洞察，ArchitectUX 将洞察转化为设计系统基础架构
|
||||
- 与 [[Whimsy-Injector]] 互补：ArchitectUX 提供技术基础，Whimsy Injector 提供品牌人格
|
||||
- 服务于 [[LuxuryDeveloper]]：LuxuryDeveloper 是 ArchitectUX 的目标用户
|
||||
|
||||
## Aliases
|
||||
- ArchitectUX Agent
|
||||
- UX Architect
|
||||
49
wiki/entities/AssemblyAI.md
Normal file
49
wiki/entities/AssemblyAI.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "AssemblyAI"
|
||||
type: entity
|
||||
tags: ["asr", "cloud-api", "speaker-diarization", "pii-detection"]
|
||||
sources: ["engineering-voice-ai-integration-engineer"]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AssemblyAI
|
||||
|
||||
## Definition
|
||||
|
||||
AssemblyAI 是一个云端自动语音识别（ASR）服务 API，通过 HTTP 接口提供语音转文字、说话人分离、PII 检测等功能。是 Voice AI Integration Engineer 在本地 Whisper 之外的云端 ASR 选项之一，适合需要快速集成或大规模处理的场景。
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
| 功能 | 说明 |
|
||||
|------|------|
|
||||
| 语音转文字 | 多语言支持，实时和批量两种模式 |
|
||||
| 说话人分离 | 内置 Diarization，无需 pyannote.audio |
|
||||
| PII 检测 | 自动识别并标记/脱敏姓名、SSN、信用卡等 |
|
||||
| 置信度分数 | 每词级别置信度 |
|
||||
| 标点和大写 | 自动添加标点、自动大写句子开头 |
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **快速 MVP**：不想搭建本地 Whisper 环境，直接 API 调用
|
||||
- **大规模并发**：需要处理大量音频，AssemblyAI 负责扩展
|
||||
- **含 PII 场景**：医疗/法律录音，内置 PII 检测减少合规负担
|
||||
- **混合路由**：敏感内容走本地 Whisper，高精度需求走 AssemblyAI
|
||||
|
||||
## Tradeoff vs Local Whisper
|
||||
|
||||
| 维度 | AssemblyAI | FasterWhisper（本地） |
|
||||
|------|-----------|---------------------|
|
||||
| 成本 | $0.005-0.02/分钟 | GPU 折旧成本 |
|
||||
| 延迟 | 取决于音频长度 | 取决于 GPU |
|
||||
| 隐私 | 数据离开本地 | 完全本地 |
|
||||
| 自定义 | 有限 | 完全可控 |
|
||||
| 离线支持 | 无 | 有 |
|
||||
|
||||
## Connections
|
||||
- [[FasterWhisper]] — 本地 ASR 替代方案
|
||||
- [[pyannote.audio]] — 如果用 AssemblyAI 则无需独立安装
|
||||
- [[PIIRedaction]] — AssemblyAI 内置 PII 检测，减少额外管道阶段
|
||||
|
||||
## Sources
|
||||
- [[engineering-voice-ai-integration-engineer]]
|
||||
@@ -10,7 +10,8 @@ tags:
|
||||
- CI/CD
|
||||
sources:
|
||||
- ctp-topic-48-terraform-vs-terragrunt.md
|
||||
last_updated: 2026-05-13
|
||||
- learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
51
wiki/entities/Automation-Governance-Architect.md
Normal file
51
wiki/entities/Automation-Governance-Architect.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Automation Governance Architect"
|
||||
type: entity
|
||||
tags: [agent, automation, governance, n8n]
|
||||
sources: [automation-governance-architect]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# Automation Governance Architect
|
||||
|
||||
治理优先的业务自动化架构师 Agent，默认使用 n8n 作为首选编排工具，治理规则平台无关。
|
||||
|
||||
## 基本信息
|
||||
- **角色**：业务自动化治理架构师
|
||||
- **默认栈**：n8n
|
||||
- **治理范围**：平台无关（n8n 为主）
|
||||
- **Vibe**：Calm, skeptical, and operations-focused — 偏好可靠系统，而非自动化热潮
|
||||
|
||||
## 核心职责
|
||||
1. **防止低价值或不安全的自动化进入生产**
|
||||
2. **审批并标准化高价值自动化，附带明确保障措施**
|
||||
3. **为可靠性、可审计性和交接制定工作流标准**
|
||||
|
||||
## 核心 Mission
|
||||
- 防止低价值或危险自动化
|
||||
- 批准并结构化高价值自动化（附带清晰保障）
|
||||
- 标准化工作流以确保可靠性、可审计性和交接质量
|
||||
|
||||
## Non-Negotiable Rules（不可妥协规则）
|
||||
- 不得仅因技术上可实现就批准自动化
|
||||
- 不得在未经明确批准的情况下推荐对关键生产流程的直接变更
|
||||
- 优先选择简单稳健，而非精巧脆弱
|
||||
- 每条建议必须包含 fallback 和明确责任人
|
||||
- 无文档和测试证据，不得标记为"完成"
|
||||
|
||||
## 五级裁定结果
|
||||
- **APPROVE**：强价值 + 可控风险 + 可维护架构
|
||||
- **APPROVE AS PILOT**：价值存在但需小范围验证
|
||||
- **PARTIAL AUTOMATION ONLY**：仅自动化安全段，保留人工检查点
|
||||
- **DEFER**：流程不成熟 / 价值不明 / 依赖不稳定
|
||||
- **REJECT**：经济性弱或运营/合规风险不可接受
|
||||
|
||||
## Launch Command
|
||||
```
|
||||
Use the Automation Governance Architect to evaluate this process for automation.
|
||||
Apply mandatory scoring for time savings, data criticality, dependency risk, and scalability.
|
||||
Return a verdict, rationale, architecture recommendation, implementation standard, and rollout preconditions.
|
||||
```
|
||||
|
||||
## Sources
|
||||
- [[automation-governance-architect]]
|
||||
20
wiki/entities/BainAndCompany.md
Normal file
20
wiki/entities/BainAndCompany.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Bain & Company"
|
||||
type: entity
|
||||
tags: ["consulting", "strategy", "framework-originator"]
|
||||
sources: ["support-executive-summary-generator"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
Bain & Company 是全球顶级战略咨询公司，成立于 1973 年，总部位于波士顿。以其实用主义咨询方法和以结果为导向的建议著称。
|
||||
|
||||
## Aliases
|
||||
- Bain
|
||||
- Bain & Company
|
||||
|
||||
## Key Contributions
|
||||
- **Action-Oriented Recommendations（行动导向建议模型）**：强调每个建议必须包含明确的负责人、时间线和预期结果
|
||||
|
||||
## Role in The Agency
|
||||
作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，行动导向建议模型是该 Agent 生成可执行建议部分的核心标准。
|
||||
42
wiki/entities/Bilibili.md
Normal file
42
wiki/entities/Bilibili.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Bilibili（B站）"
|
||||
type: entity
|
||||
tags: [platform, china, social-media, video, gen-z]
|
||||
sources: [marketing-china-market-localization-strategist, marketing-bilibili-content-strategist]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Overview
|
||||
哔哩哔哩（Bilibili，B站），中国领先的中长视频与弹幕社区，以 Z 世代（95 后/00 后）为核心用户群体。在 [[China Market Localization Strategist]] 的跨平台策略中，B站承担"考虑阶段"的深度内容教育角色，是品牌建立长期信任和权威认知的关键平台。
|
||||
|
||||
## Platform DNA
|
||||
- **用户画像**：以 Z 世代为主，中国一二线城市年轻人高度集中
|
||||
- **内容偏好**：深度内容、知识型视频、二次元文化、游戏、生活方式
|
||||
- **核心互动机制**：弹幕（Danmaku）、投币、三连（点赞+投币+收藏）、充电
|
||||
- **算法特性**：内容质量权重高，播放完成率是核心指标，不单纯追求点击量
|
||||
|
||||
## Marketing Role in China Funnel
|
||||
- **漏斗位置**：认知（Weibo/Douyin）→ **考虑（Bilibili）** → 转化（Xiaohongshu/WeChat）
|
||||
- **品牌价值**：深度种草、长期信任建立、Z 世代用户触达
|
||||
|
||||
## Content Strategy
|
||||
- 长篇深度内容为主（10-40 分钟），与抖音的短视频策略形成互补
|
||||
- UP 主（内容创作者）合作是核心传播路径
|
||||
- 内容须有知识增量或情绪价值，硬广告效果差
|
||||
- 弹幕互动设计是内容创作的重要考量
|
||||
|
||||
## Key Terms
|
||||
- **UP主**：B站内容创作者，即 YouTuber
|
||||
- **弹幕**：实时滚动的评论字幕，增强观看互动感
|
||||
- **三连**：点赞+投币+收藏，代表用户对内容的高度认可
|
||||
- **充电**：用户对 UP 主的直接打赏支持
|
||||
|
||||
## Connections
|
||||
- [[Douyin]]（抖音）：认知层 → B站：考虑层，内容深度递进关系
|
||||
- [[Xiaohongshu]]（小红书）：考虑层 → B站，均为 Z 世代聚集平台
|
||||
- [[Marketing Bilibili Content Strategist]]：B站专属内容策略 Agent
|
||||
|
||||
## Aliases
|
||||
- B站
|
||||
- Bilibili
|
||||
- 哔哩哔哩
|
||||
21
wiki/entities/BostonConsultingGroup.md
Normal file
21
wiki/entities/BostonConsultingGroup.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Boston Consulting Group (BCG)"
|
||||
type: entity
|
||||
tags: ["consulting", "strategy", "framework-originator"]
|
||||
sources: ["support-executive-summary-generator"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
Boston Consulting Group (BCG) 是全球领先的战略咨询公司，成立于 1963 年，总部位于波士顿。以其创新性管理理念和战略框架著称。
|
||||
|
||||
## Aliases
|
||||
- BCG
|
||||
- Boston Consulting Group
|
||||
- The Boston Consulting Group
|
||||
|
||||
## Key Contributions
|
||||
- **Pyramid Principle（金字塔原理）**：自上而下逻辑沟通和层级化洞察组织方法，成为商业沟通的标准框架
|
||||
|
||||
## Role in The Agency
|
||||
作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，Pyramid Principle 是该 Agent 组织执行摘要结构的核心框架。
|
||||
26
wiki/entities/Bronislaw-Malinowski.md
Normal file
26
wiki/entities/Bronislaw-Malinowski.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Bronislaw Malinowski"
|
||||
type: entity
|
||||
tags: ["anthropologist", "functionalism", "polish-british", "fieldwork", "oceanic-studies"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
波兰裔英国人类学家，功能主义人类学（Functionalism）创始人。强调文化是人类满足基本生物和社会需求的工具，通过特罗布里恩群岛（Trobriand Islands）的长期田野调查发展了系统的功能分析方法。
|
||||
|
||||
## Aliases
|
||||
- Malinowski
|
||||
- B. Malinowski
|
||||
|
||||
## Key Contributions
|
||||
- **功能主义（Functionalism）**：文化的每个元素都服务于满足人类的某种基本需求——生理需求通过经济系统满足，社会需求通过亲属制度满足，安全需求通过防御系统满足
|
||||
- **田野调查方法论**：强调人类学家必须长期沉浸于研究对象社会中（参与观察法），而非仅做短暂访问
|
||||
- **库拉圈（Kula Ring）**：特罗布里恩群岛的礼物交换圈——是礼物经济的经典研究案例
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 引用 Malinowski 功能主义作为核心方法论之一，要求每种文化实践必须能回答"这个做法为这些人解决了什么问题"。
|
||||
|
||||
## Connections
|
||||
- [[Functionalism]] ← authored_by ← [[Bronislaw-Malinowski]]
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Bronislaw-Malinowski]]
|
||||
- [[Marcel-Mauss]] ← influenced_by ← [[Bronislaw-Malinowski]]
|
||||
39
wiki/entities/Certora.md
Normal file
39
wiki/entities/Certora.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Certora"
|
||||
type: entity
|
||||
tags: [blockchain, security, tooling, formal-verification]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Certora 是一个智能合约形式化验证平台，其核心产品 Certora Prover 通过符号执行技术数学证明 Solidity 合约的关键属性。
|
||||
|
||||
## Products
|
||||
|
||||
### Certora Prover
|
||||
- 基于符号执行的自动化形式化验证工具
|
||||
- 使用 CVL（Certora Verification Language）描述协议规范
|
||||
- 支持反例生成和并行规则验证
|
||||
- 被 Trail of Bits 在高风险协议审计中使用
|
||||
|
||||
### Certora Commander
|
||||
- 命令行工具链
|
||||
- 与 Truffle、Hardhat、Foundry 集成
|
||||
|
||||
## Key Users
|
||||
|
||||
- [[Blockchain-Security-Auditor]] — 形式化验证的主要工具
|
||||
- Trail of Bits — 高级审计报告
|
||||
- Protocol teams — 关键升级前的自验证
|
||||
|
||||
## Notable Capabilities
|
||||
|
||||
- 验证份额不变性、借贷健康度、权限控制
|
||||
- 在数学上证明某属性不可能被违反
|
||||
- 生成最小反例序列
|
||||
|
||||
## Connections
|
||||
- [[Blockchain-Security-Auditor]] ← uses tools ← [[Certora]]
|
||||
- [[Formal-Verification]] ← implemented by ← [[Certora]]
|
||||
52
wiki/entities/Chaebol.md
Normal file
52
wiki/entities/Chaebol.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Chaebol"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **原文**：재벌（Chaebol）
|
||||
- **类型**：公司类型 / 韩国大企业集团
|
||||
- **中文**：财阀
|
||||
- **英文**：Korean Family-Controlled Conglomerate
|
||||
|
||||
## 定义
|
||||
财阀（Chaebol）是韩国特有的家族控制大型企业集团，在韩国经济中占据主导地位。典型代表包括三星、现代、LG、SK、乐天等。财阀企业决策层级森严，품의流程耗时最长（12-16 周），通常需要集团总部和子公司双重审批。
|
||||
|
||||
## 特征
|
||||
- **决策链长**：往往需要子公司部门长 → 子公司社长 → 集团总部多层审批
|
||||
- **预算周期严格**：通常按年度预算执行，大额支出需提前规划
|
||||
- **关系维护难度高**：初次接触需要通过极高层次的介绍人
|
||||
- **跟进频率**：建议每月一次，避免过于频繁造成压力
|
||||
|
||||
## 品의 流程特点
|
||||
| 阶段 | 特点 |
|
||||
|------|------|
|
||||
| 결재라인 | 可能涉及 5-7 级审批链 |
|
||||
| 时间线 | 12-16 周 |
|
||||
| 联系人决策权 | 较低，需向上汇报 |
|
||||
| 预算确认 | 通常在年初（Q1）或财年末期确定 |
|
||||
|
||||
## 代表企业
|
||||
- Samsung（三星）— 最大财阀，电子/建筑/金融综合集团
|
||||
- Hyundai/Kia（现代/起亚）— 汽车/重工业
|
||||
- LG — 电子/化学/通信
|
||||
- SK — 通信/能源/半导体
|
||||
- Lotte（乐天）— 食品/酒店/流通
|
||||
|
||||
## 与外国供应商合作的挑战
|
||||
1. **语言壁垒**：内部决策文档多为韩文
|
||||
2. **技术评估文化差异**：更看重品牌知名度而非技术先进性
|
||||
3. **价格敏感度高**：集团采购追求规模效益
|
||||
4. **合同条款严格**：法务审查周期长
|
||||
|
||||
## Aliases
|
||||
- 재벌
|
||||
- 韩国财阀
|
||||
- Korean Conglomerate
|
||||
- Chaebol Group
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — 품의 Approval Process Timeline 中关于 Chaebol 跟进频率和审批链的说明
|
||||
27
wiki/entities/Charlie-Munger.md
Normal file
27
wiki/entities/Charlie-Munger.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Charlie Munger"
|
||||
type: entity
|
||||
tags: [investing, strategy, mental-models]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Munger
|
||||
- Charles Munger
|
||||
|
||||
## Overview
|
||||
Charlie Munger（1924–2023）是伯克希尔·哈撒韦副主席、巴菲特最重要的人生搭档，被誉为"最伟大的思想家之一"。他的核心方法论是"Mental Models"（心智模型网格）和"Inversion"（倒置法）——先想清楚如何失败再想如何成功。
|
||||
|
||||
## Core Method
|
||||
- **Mental Models Grid**：跨学科心智模型网格（物理学、经济学、心理学、工程学等），用多元框架理解世界
|
||||
- **Inversion**：先想清楚如何失败，然后避免它；"我唯一知道的就是我会死在哪里，这样我就永远不会去那里"
|
||||
- **Lollapalooza Effect**：当多个心智模型同时指向同一方向时，产生巨大的叠加效应
|
||||
|
||||
## Role in ZK Steward
|
||||
ZK Steward 在"商业策略"任务中切换到 Munger 视角，使用 mental models 和 inversion 进行多角度分析。
|
||||
|
||||
## Key Connections
|
||||
- [[ZK-Steward-Agent]] ← uses Munger perspective for business strategy tasks
|
||||
- [[Domain-Thinking]] ← Munger is the reference expert for business strategy domain
|
||||
- [[Luhmann-四原则]] ← Munger 的 mental models 网格与"避免过度结构化"存在张力（Munger 倾向预设框架）
|
||||
28
wiki/entities/ChatBox.md
Normal file
28
wiki/entities/ChatBox.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "ChatBox"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "open-source"
|
||||
- "client"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
ChatBox（39k stars）是一款开源 AI 客户端，支持通过 API Host 设置接入自定义后端。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：39k
|
||||
- **License**：MIT
|
||||
- **集成方式**：API Host 设置
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过 API Host 配置：
|
||||
- **API URL**：`http://<host>:8642`
|
||||
- **认证**：Bearer Token（`API_SERVER_KEY`）
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
27
wiki/entities/Christian-Deckelmann.md
Normal file
27
wiki/entities/Christian-Deckelmann.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Christian Deckelmann"
|
||||
type: entity
|
||||
tags:
|
||||
- Micro Focus
|
||||
- Cloud Transformation
|
||||
- CTP
|
||||
- AWS
|
||||
- SES
|
||||
sources:
|
||||
- ctp-topic-12-using-ses-smtp-service-terraform-module
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
Micro Focus Cloud Transformation Programme 负责人，主讲 CTP Topic 12，介绍了 Micro Focus 在云转型过程中选择 AWS SES 替代传统本地 SMTP 网关的背景与决策。
|
||||
|
||||
## Aliases
|
||||
- Christian Deckelmann
|
||||
|
||||
## Role
|
||||
- Cloud Transformation Programme 负责人
|
||||
- CTP Topic 12 主讲人之一
|
||||
|
||||
## Connections
|
||||
- [[Filos Christolakis]] — SES Terraform 模块开发者，共同主讲 CTP Topic 12
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] — 主讲来源
|
||||
25
wiki/entities/ChristopherVogler.md
Normal file
25
wiki/entities/ChristopherVogler.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Christopher Vogler"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Christopher Vogler
|
||||
- Vogler
|
||||
|
||||
## Overview
|
||||
Christopher Vogler 是美国编剧、故事顾问，他将 Joseph Campbell 的 Monomyth 理论系统引入商业电影和电视编剧领域，著有《作家之旅》（The Writer's Journey: Mythic Structure for Writers, 1992）。
|
||||
|
||||
## Key Contributions
|
||||
- **The Writer's Journey**：将 Campbell 的英雄之旅模型改造为对编剧友好的12阶段叙事结构（Ordinary World → Call to Adventure → Refusal of the Call → Meeting the Mentor → Crossing the Threshold → Tests, Allies, Enemies → Approach to the Inmost Cave → The Ordeal → Reward → The Road Back → Resurrection → Return with the Elixir）
|
||||
- **Character Archetypes**：基于 Jung 的原型理论，定义了 Mentor、Shapeshifter、Threshold Guardian 等编剧用角色类型
|
||||
- 影响了迪士尼、皮克斯等主流工作室的叙事开发流程
|
||||
|
||||
## In The Agency Context
|
||||
[[Academic Narratologist]] 使用 Writer's Journey 作为英雄叙事的分析工具，连接 Campbell 理论与现代编剧实践。
|
||||
|
||||
## References
|
||||
- The Writer's Journey: Mythic Structure for Writers (1992)
|
||||
@@ -2,10 +2,20 @@
|
||||
title: "Claude Code"
|
||||
type: entity
|
||||
tags: [ai-agent, coding]
|
||||
sources: [aionui-cowork-desktop]
|
||||
last_updated: 2026-04-27
|
||||
sources: [aionui-cowork-desktop, readme.md]
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
Claude Code 是 Anthropic 推出的 AI 编程 Agent，支持在终端中完成代码编写、调试、重构等开发任务。与 OpenClaw 共存于 AionUi 桌面应用中，共享统一 MCP 配置。
|
||||
|
||||
## The Agency Integration
|
||||
Claude Code 是 The Agency 的原始设计目标，Agent 以原生 `.md` 格式工作，无需任何转换。
|
||||
- Agent 格式：`.md`（原生支持）
|
||||
- 安装路径：`~/.claude/agents/`
|
||||
- 安装命令：`cp -r <category>/*.md ~/.claude/agents/` 或 `./scripts/install.sh --tool claude-code`
|
||||
- 自动发现：Claude Code 会自动扫描 `~/.claude/agents/` 目录
|
||||
|
||||
## Overview
|
||||
|
||||
Claude Code 是 Anthropic 推出的 AI 编程 Agent，支持在终端中完成代码编写、调试、重构等开发任务。与 OpenClaw 共存于 AionUi 桌面应用中，共享统一 MCP 配置。
|
||||
|
||||
27
wiki/entities/Claude-Levi-Strauss.md
Normal file
27
wiki/entities/Claude-Levi-Strauss.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Claude Levi-Strauss"
|
||||
type: entity
|
||||
tags: ["anthropologist", "structuralism", "french-intellectual", "mythology"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
法国人类学家，结构主义创始人。发展了通过二元对立（raw/cooked, nature/culture, self/other）和变换来理解神话与社会分类的系统性框架。其工作将人类学从功能主义转向了结构分析。
|
||||
|
||||
## Aliases
|
||||
- Levi-Strauss
|
||||
- Lévi-Strauss
|
||||
- Claude Lévi-Strauss
|
||||
|
||||
## Key Contributions
|
||||
- **结构主义（Structuralism）**：通过识别文化系统中的深层二元对立结构来解释神话、亲属制度和思维方式
|
||||
- **神话素（Mytheme）**：神话的基本叙事单元，通过变换重组产生不同变体
|
||||
- **亲属制度研究**：提出亲属制度是一种交换系统（女人作为交换媒介）
|
||||
- **生食与熟食**：通过烹饪系统分析自然与文化的边界
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 引用 Levi-Strauss 的结构主义作为"Advanced Capabilities"中的高级分析工具之一，用于对神话、分类系统和二元对立进行系统性分析。
|
||||
|
||||
## Connections
|
||||
- [[Structuralism]] ← authored_by ← [[Claude-Levi-Strauss]]
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Claude-Levi-Strauss]]
|
||||
@@ -1,25 +1,26 @@
|
||||
---
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: [ClawHub, OpenClaw, Skill, Marketplace]
|
||||
sources: [daily-youtube-digest, phone-call-notifications]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ClawHub
|
||||
- clawhub.ai
|
||||
|
||||
## Definition
|
||||
|
||||
ClawHub（clawhub.ai）是 OpenClaw 的官方 Skill 市场，托管 OpenClaw Agent 可安装的技能包（Skills）。用户可以通过自然语言让 AI Agent 安装 Skill（如 "Install the youtube-full skill"），或通过 `npx clawhub@latest install <skill-name>` 命令行安装。安装后 Skill 自动配置 API Key 并存储到正确的系统位置。
|
||||
|
||||
## Key Skills on ClawHub
|
||||
|
||||
- **youtube-full** — 自动获取 YouTube 频道最新视频、提取字幕并摘要
|
||||
- **clawr.ing** — 为 Agent 提供主动拨打电话通知能力，通过 PSTN 电话触达用户（参见 [[phone-call-notifications]]）
|
||||
- 持续扩充中（官网 clawhub.ai 浏览全部）
|
||||
|
||||
## Connections
|
||||
- [[clawhub.ai]] ← hosts ← [[youtube-full skill]], [[clawr.ing]]
|
||||
- [[OpenClaw]] ← extends via ← [[clawhub.ai]] skills
|
||||
---
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [baoyu-skills]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
ClawHub（也称 OpenClaw）是 Claude Code 的插件市场，支持 Skills 的发现、安装和自动更新。[[baoyu-skills]] 通过 ClawHub 分发各独立 Skill，用户可以按需选择性安装（如 `clawhub install baoyu-imagine`）。
|
||||
|
||||
## Distribution Model
|
||||
|
||||
ClawHub 采用「单个 Skill 分发」模式，每个 `skills/` 子目录作为独立 ClawHub Skill 发布。以 MIT-0 许可证分发。
|
||||
|
||||
安装方式：
|
||||
```
|
||||
clawhub install baoyu-imagine
|
||||
clawhub install baoyu-markdown-to-html
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[baoyu-skills]] ← distributed_via ← [[ClawHub]]
|
||||
- [[OpenClaw]] ← same_platform ← [[ClawHub]]
|
||||
- [[Claude-Code]] ← platform ← [[ClawHub]]
|
||||
|
||||
25
wiki/entities/Clifford-Geertz.md
Normal file
25
wiki/entities/Clifford-Geertz.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Clifford Geertz"
|
||||
type: entity
|
||||
tags: ["anthropologist", "symbolic-anthropology", "indonesian-studies", "methodology"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
美国人类学家，符号人类学（Interpretive Anthropology）创始人。提出"厚描述"（Thick Description）方法论，强调理解文化参与者的主观意义系统，而非仅做外部观察。
|
||||
|
||||
## Aliases
|
||||
- Geertz
|
||||
- C. Geertz
|
||||
|
||||
## Key Contributions
|
||||
- **厚描述（Thick Description）**：将文化实践作为文本阅读，通过多层次语境理解行为的意义（眨眼vs抽动vs模仿眨眼）
|
||||
- **符号人类学（Symbolic Anthropology）**：文化是由象征符号构成的意义之网（web of significance），人类学家的任务是解释这个意义之网
|
||||
- **印尼研究**：通过巴厘岛斗鸡、爪哇的宗教实践等具体田野案例展示厚描述方法
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 引用 Geertz 的"厚描述"作为 Advanced Capabilities 的核心方法论，要求 Agent 将文化实践作为文本理解参与者的主观意义。
|
||||
|
||||
## Connections
|
||||
- [[Symbolic-Anthropology]] ← authored_by ← [[Clifford-Geertz]]
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Clifford-Geertz]]
|
||||
@@ -1,43 +1,18 @@
|
||||
---
|
||||
title: "Cursor"
|
||||
type: entity
|
||||
tags: [ai, ai-agent, ide, mcp]
|
||||
sources: [mcp在cursor中的集成与应用详解, cursor-2-0初学者使用指南]
|
||||
last_updated: 2026-04-26
|
||||
tags: []
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
Cursor 是一款支持 MCP（Modal Context Protocol）集成的 **AI 编程 IDE**，基于 VS Code 定制，集成了多种大模型用于代码补全、对话和自动化任务执行。
|
||||
Cursor 是基于 AI 的代码编辑器（基于 VS Code）。The Agency 将 Agent 转换为 `.mdc` 规则文件（Cursor 的原生配置格式），以项目级作用域安装。
|
||||
|
||||
## MCP Integration
|
||||
Cursor 是 MCP 协议的重要客户端实现，支持在 IDE 中直接接入 MCP Server：
|
||||
## Key Facts
|
||||
- Agent 格式：`.mdc`（Cursor 规则文件）
|
||||
- 作用域：Project-Scoped（项目级）
|
||||
- 安装方式：从项目根目录运行 `./scripts/install.sh --tool cursor`
|
||||
- 前置步骤：无需 convert（直接转换）
|
||||
|
||||
**接入方式：**
|
||||
1. 下载支持 MCP 功能的 Cursor 最新版
|
||||
2. 在 Cursor 设置中新增 MCP Server
|
||||
3. 选择接入类型：
|
||||
- **SSE 服务方式**：通过 HTTP SSE 连接远程 MCP Server
|
||||
- **Command 方式**：通过本地执行命令连接本地 MCP Server
|
||||
|
||||
**常见问题：**
|
||||
- 配置后出现 "no tools found" 错误 → 检查 MCP 服务路径或网络代理设置
|
||||
- 建议直接填写 MCP 原始地址，绕过代理层
|
||||
|
||||
## Composer Module
|
||||
Cursor 的 Composer 模块支持两种交互模式：
|
||||
- **Normal 模式**：需要用户手动复制 AI 给出的命令并执行
|
||||
- **Agent 模式**：自动执行 AI 发出的命令，处理工具调用（需开启）
|
||||
|
||||
## Version
|
||||
- Cursor 2.0 及以上版本支持 MCP 集成
|
||||
|
||||
## Connections
|
||||
- [[Mcp在Cursor中的集成与应用详解]] ← MCP 集成核心教程
|
||||
- [[Cursor2.0初学者使用指南]] ← 入门指南
|
||||
- [[ModalContextProtocol]] ← 集成协议
|
||||
- [[Composer]] ← 功能模块
|
||||
- [[AgentMode]] ← 交互模式
|
||||
|
||||
## See Also
|
||||
- [[OpenCode]]
|
||||
- [[Trae]]
|
||||
## Sources
|
||||
- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
|
||||
|
||||
37
wiki/entities/CustomerMatch.md
Normal file
37
wiki/entities/CustomerMatch.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Customer Match"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- google
|
||||
- audience
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
Customer Match 是 Google Ads 的第一方数据激活工具，允许广告主将自有客户数据（邮箱、电话、地址）上传至 Google，与 Google 用户身份池进行匹配，从而创建可定向的自定义受众群体，用于精准再营销和类似受众扩展。
|
||||
|
||||
## How It Works
|
||||
1. **数据上传**：广告主以加密格式上传客户列表（邮箱/电话）
|
||||
2. **身份匹配**：Google 将数据与已登录 Google 账户的用户池进行匹配（需同意条款）
|
||||
3. **受众创建**：匹配成功的用户被纳入自定义受众列表
|
||||
4. **广告定向**：该受众可用于 Search、Display、YouTube、Shopping 等广告系列的定向或排除
|
||||
|
||||
## Core Use Cases
|
||||
- **Lookalike / Similar Segments**：在 Customer Match 受众基础上，Google 自动生成相似特征的新用户受众
|
||||
- **Cross-Sell / Up-Sell**：向现有客户推广其他产品或高端版本
|
||||
- **Lapsed Customer Re-engagement**：唤醒长期未购买的老客户
|
||||
- **CLV（Custoner Lifetime Value）分层**：按消费金额分层，针对高价值客户提供专属优惠
|
||||
|
||||
## Privacy Considerations
|
||||
- 用户需在 Google 平台同意数据使用条款才能被匹配
|
||||
- 随着隐私法规（GDPR/CCPA）趋严，第一方数据战略价值持续提升
|
||||
- Customer Match 是 [[AudienceStrategy]] 的核心组件
|
||||
|
||||
## Connections
|
||||
- [[GoogleAds]]：Customer Match 的承载平台
|
||||
- [[AudienceStrategy]]：Customer Match 是受众策略的重要组成部分
|
||||
- [[PaidMediaPPCCampaignStrategist]]：在 Tiered Campaign Architecture 中用于高价值客户层
|
||||
37
wiki/entities/Dana.md
Normal file
37
wiki/entities/Dana.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Dana"
|
||||
type: entity
|
||||
tags: [finance, accounting, ai-agent]
|
||||
sources: [finance-bookkeeper-controller]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
Dana 是 [[finance-bookkeeper-controller]] 中定义的 AI Controller Agent 角色名称，代表一位拥有 13 年+ 经验的专业会计主管。
|
||||
|
||||
## Background
|
||||
- 13 年以上经验，跨度从初创企业记账到公众公司 Controller
|
||||
- 从零建立过多个会计部门
|
||||
- 主导过首次审计
|
||||
- 实施过 Sarbanes-Oxley
|
||||
- 连续 150+ 个月准时完成月度结账
|
||||
|
||||
## Core Philosophy
|
||||
- **准确性底线**：准确性是不可协商的底线，速度必须服从准确性
|
||||
- **调节即侦破**：未调节差异是等待被理解的故事
|
||||
- **审计无聊论**：如果审计师感到意外，说明控制失败了
|
||||
- **自动化哲学**：自动化重复工作，人脑专注异常
|
||||
- **文档即善意**：为未来的自己和继任者做好文档
|
||||
|
||||
## Role in Agency System
|
||||
- 属 Finance Agent 矩阵中的核心 Controller 角色
|
||||
- 为 [[Finance FPA Analyst]] 提供高质量财务数据
|
||||
- 与 [[Finance Tax Strategist]] 协调季度税项和年度税表
|
||||
- 与 [[Accounts Payable Agent]] 协作审核 AP 数据和账务记录
|
||||
|
||||
## Key Metrics
|
||||
- 连续 150+ 月准时结账
|
||||
- 结账周期从 10 天压缩至 7 天
|
||||
- AP 处理在条款期内完成以捕获所有提前付款折扣
|
||||
- 每周现金预测精度 ±5%
|
||||
- AR aging：逾期 90 天以上应收账款 <5%
|
||||
41
wiki/entities/Databricks.md
Normal file
41
wiki/entities/Databricks.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Databricks"
|
||||
type: entity
|
||||
tags: [data-engineering, lakehouse, analytics-platform, cloud]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Databricks 是基于 Apache Spark 的统一分析和 AI 平台，提供 Lakehouse、Notebook、MLflow、Delta Live Tables（DLT）和 Unity Catalog 等能力。Data Engineer Agent 使用 Databricks 作为主要的托管执行环境。
|
||||
|
||||
## Key Products for Data Engineering
|
||||
|
||||
### Unity Catalog
|
||||
- 统一治理：跨云（AWS/Azure/GCP）的数据目录和权限管理
|
||||
- 细粒度行级安全（Row-Level Security）和列掩码（Column Masking）
|
||||
|
||||
### Delta Live Tables (DLT)
|
||||
- 声明式流式和批处理管道
|
||||
- 自动管理基础设施、checkpoint 和数据质量
|
||||
- 内置期望（Expectations）定义，数据质量自动验证
|
||||
|
||||
### Databricks Workflows
|
||||
- 编排多任务管道（notebooks + SQL + JAR）
|
||||
- 支持 CI/CD 集成（Asset Bundles）
|
||||
|
||||
### Asset Bundles
|
||||
- 基础架构即代码（IaC）方式管理 Databricks 资源
|
||||
- 可与 GitHub Actions 集成实现自动化部署
|
||||
|
||||
## Cloud Platforms
|
||||
- **AWS**：S3 + Databricks
|
||||
- **Azure**：ADLS + Databricks (Microsoft Fabric 集成)
|
||||
- **GCP**：GCS + Databricks
|
||||
|
||||
## Related Concepts
|
||||
- [[Medallion Architecture]]
|
||||
- [[Delta Lake]]（Databricks 是主要贡献者和推广者）
|
||||
- [[Apache Spark]]
|
||||
- [[dbt]]（dbt Cloud 与 Databricks 深度集成）
|
||||
26
wiki/entities/David-Ogilvy.md
Normal file
26
wiki/entities/David-Ogilvy.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "David Ogilvy"
|
||||
type: entity
|
||||
tags: [advertising, brand, marketing]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Ogilvy
|
||||
- David MacKenzie Ogilvy
|
||||
|
||||
## Overview
|
||||
David Ogilvy（1911–1999）是奥美广告（Ogilvy & Mather）的创始人，被誉为"现代广告之父"。他强调品牌个性（brand persona）和长文案（long copy）在广告中的力量，反对空洞的创意炫技。
|
||||
|
||||
## Core Method
|
||||
- **Long Copy**：好广告不靠图片，靠文字——长文案能够充分展示产品价值、建立信任
|
||||
- **Brand Persona**：每个品牌都需要独特的声音和个性，像人一样与消费者对话
|
||||
- **Research-First**：广告创意必须以消费者研究为基础，而非创意人员的自我表达
|
||||
|
||||
## Role in ZK Steward
|
||||
ZK Steward 在"品牌营销"任务中切换到 Ogilvy 视角，驱动品牌 persona 和 long copy 策略分析。
|
||||
|
||||
## Key Connections
|
||||
- [[ZK-Steward-Agent]] ← uses Ogilvy perspective for brand marketing tasks
|
||||
- [[Domain-Thinking]] ← Ogilvy is the reference expert for brand marketing domain
|
||||
50
wiki/entities/Deepgram.md
Normal file
50
wiki/entities/Deepgram.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Deepgram"
|
||||
type: entity
|
||||
tags: ["asr", "cloud-api", "speaker-diarization", "streaming"]
|
||||
sources: ["engineering-voice-ai-integration-engineer"]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Deepgram
|
||||
|
||||
## Definition
|
||||
|
||||
Deepgram 是一个云端自动语音识别（ASR）服务，以实时流式转录（Streaming API）和高准确度著称。支持说话人分离、PII 检测、关键词检测等多种高级功能，是 AssemblyAI 的主要竞品。
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
| 功能 | 说明 |
|
||||
|------|------|
|
||||
| 实时流式转录 | WebSocket 流，支持低延迟实时字幕/笔记 |
|
||||
| 批量转录 | 上传文件，异步返回结果 |
|
||||
| 说话人分离 | 内置 Diarization，支持指定说话人数 |
|
||||
| PII 检测 | 可选，开启后自动标记/脱敏 |
|
||||
| 关键词检测 | 自定义关键词加权 |
|
||||
| 语言模型 | 通用、医疗、法律等垂直领域模型 |
|
||||
|
||||
## Competitive Positioning vs AssemblyAI
|
||||
|
||||
| 维度 | Deepgram | AssemblyAI |
|
||||
|------|---------|-----------|
|
||||
| 实时流式 | 原生 WebSocket（更强） | REST polling |
|
||||
| 延迟 | 极低（<300ms） | 中等 |
|
||||
| 准确度 | 领先（WER 基准） | 相当 |
|
||||
| API 体验 | 更现代化 | 成熟稳定 |
|
||||
| 语言覆盖 | 100+ 语言 | 100+ 语言 |
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **实时字幕**：直播、会议、客服的实时字幕生成
|
||||
- **VoIP 集成**：电话系统的实时转录
|
||||
- **长音频批量**：会议录音、播客批量处理
|
||||
- **多语言**：跨境会议的实时翻译字幕管道
|
||||
|
||||
## Connections
|
||||
- [[FasterWhisper]] — 本地 ASR 替代方案
|
||||
- [[AssemblyAI]] — 直接竞品，混合路由可两者都接入
|
||||
- [[pyannote.audio]] — Deepgram 内置 Diarization 可替代独立 pyannote
|
||||
|
||||
## Sources
|
||||
- [[engineering-voice-ai-integration-engineer]]
|
||||
55
wiki/entities/Delta-Lake.md
Normal file
55
wiki/entities/Delta-Lake.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Delta Lake"
|
||||
type: entity
|
||||
tags: [data-engineering, lakehouse, open-table-format, ACID]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Delta Lake 是由 Databricks 开源的开放表格格式（Open Table Format），为数据湖提供 ACID 事务、时间旅行、Z-Ordering 等能力。Data Engineer Agent 使用 Delta Lake 作为 Medallion Architecture 三层（Bronze/Silver/Gold）的统一存储格式。
|
||||
|
||||
## Key Features
|
||||
|
||||
### ACID Transactions
|
||||
- 写操作原子提交，读者永远看到一致状态
|
||||
- 多并发写操作不会产生部分写入
|
||||
|
||||
### Time Travel
|
||||
- 任意时间点查询数据（`VERSION AS OF` 或 `TIMESTAMP AS OF`）
|
||||
- 用于审计、合规和回滚
|
||||
|
||||
### Schema Enforcement & Evolution
|
||||
- `mergeSchema=true`：允许 schema 演进，捕获上游变更
|
||||
- 禁止删除 required 列，类型变更需显式声明
|
||||
|
||||
### Z-Ordering
|
||||
- 多维数据聚类，将相关数据物理上聚集存储
|
||||
- 显著加速复合过滤查询
|
||||
|
||||
### Liquid Clustering（Delta Lake 3.x+）
|
||||
- 自动压缩和聚类，自适应工作负载
|
||||
|
||||
### UPSERT / MERGE
|
||||
```python
|
||||
target.alias("target").merge(source.alias("source"), merge_condition) \
|
||||
.whenMatchedUpdateAll() \
|
||||
.whenNotMatchedInsertAll() \
|
||||
.execute()
|
||||
```
|
||||
实现幂等的增量数据更新。
|
||||
|
||||
## Alternative Formats
|
||||
- [[Apache Iceberg]]：另一个开放表格格式规范，跨引擎（Spark/Trino/Presto）互操作
|
||||
- Apache Hudi：支持 hoodie-based incremental processing
|
||||
|
||||
## Used By
|
||||
- [[Databricks]]（原生支持）
|
||||
- [[Apache Spark]]（`delta` format 直接支持）
|
||||
- AWS Glue、Snowflake（通过 connectors）
|
||||
|
||||
## Related Concepts
|
||||
- [[Medallion Architecture]]
|
||||
- [[Apache Spark]]
|
||||
- [[SCD Type 2]]
|
||||
30
wiki/entities/DevOpsAutomator.md
Normal file
30
wiki/entities/DevOpsAutomator.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "DevOpsAutomator"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [agents-orchestrator]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
**DevOps Automator** is The Agency's infrastructure automation specialist agent — responsible for infrastructure automation, CI/CD, and cloud operations.
|
||||
|
||||
## Role
|
||||
- **Role**: DevOps / Infrastructure automation specialist
|
||||
- **Personality**: Automation-first, reliability-focused, operationally meticulous
|
||||
- **Specialization**: Infrastructure automation, CI/CD pipelines, cloud operations
|
||||
|
||||
## Core Responsibilities
|
||||
- Automate infrastructure provisioning and configuration
|
||||
- Design and implement CI/CD pipelines
|
||||
- Cloud operations and monitoring
|
||||
- Infrastructure as Code (IaC) implementation
|
||||
- Coordinate with [[ArchitectUX]] for infrastructure architecture
|
||||
|
||||
## Within Pipeline
|
||||
- **Spawned By**: [[AgentsOrchestrator]] during Phase 3 Dev-QA Loop
|
||||
- **Validated By**: [[EvidenceQA]] — each infrastructure task must pass QA
|
||||
- **Part Of**: [[Dev-QA-Loop]] in the [[AgentsOrchestrator]] pipeline
|
||||
|
||||
## Sources
|
||||
- [[agents-orchestrator]]
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: "Douyin（抖音）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china, social-media]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
|
||||
|
||||
## Healthcare Industry Access Requirements
|
||||
- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
|
||||
- 认证后方可发布医疗健康相关内容和广告
|
||||
|
||||
## Content Review Rules
|
||||
- 禁止展示外科手术过程
|
||||
- 禁止使用患者推荐/见证疗效内容
|
||||
- 禁止展示处方药信息
|
||||
- 健康科普内容须经平台人工审核
|
||||
|
||||
## Physician Account Certification
|
||||
- 须提交医师资格证
|
||||
- 认证后获得"认证医师"标识
|
||||
- 认证医师可在合规范围内发布健康科普内容
|
||||
|
||||
## Livestream Restrictions
|
||||
- 医疗账号直播期间禁止推荐具体药品或治疗方案
|
||||
- 禁止进行在线诊断
|
||||
- 违反规定可能导致账号封禁或流量限制
|
||||
|
||||
## Advertising Placement
|
||||
- 医疗广告须经过行业资质审核
|
||||
- 创意内容须经平台人工审核
|
||||
|
||||
## Aliases
|
||||
- 抖音
|
||||
- Douyin
|
||||
- TikTok China
|
||||
---
|
||||
title: "Douyin（抖音）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china, social-media]
|
||||
sources: [healthcare-marketing-compliance, marketing-douyin-strategist, marketing-china-ecommerce-operator, marketing-china-market-localization-strategist, marketing-livestream-commerce-coach]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Overview
|
||||
抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
|
||||
|
||||
## Healthcare Industry Access Requirements
|
||||
- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
|
||||
- 认证后方可发布医疗健康相关内容和广告
|
||||
|
||||
## Content Review Rules
|
||||
- 禁止展示外科手术过程
|
||||
- 禁止使用患者推荐/见证疗效内容
|
||||
- 禁止展示处方药信息
|
||||
- 健康科普内容须经平台人工审核
|
||||
|
||||
## Physician Account Certification
|
||||
- 须提交医师资格证
|
||||
- 认证后获得"认证医师"标识
|
||||
- 认证医师可在合规范围内发布健康科普内容
|
||||
|
||||
## Livestream Restrictions
|
||||
- 医疗账号直播期间禁止推荐具体药品或治疗方案
|
||||
- 禁止进行在线诊断
|
||||
- 违反规定可能导致账号封禁或流量限制
|
||||
|
||||
## Advertising Placement
|
||||
- 医疗广告须经过行业资质审核
|
||||
- 创意内容须经平台人工审核
|
||||
|
||||
## Aliases
|
||||
- 抖音
|
||||
- Douyin
|
||||
- TikTok China
|
||||
|
||||
33
wiki/entities/EpicGames.md
Normal file
33
wiki/entities/EpicGames.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Epic Games"
|
||||
type: entity
|
||||
tags: ["game-engine", "company", "unreal-engine"]
|
||||
sources: ["unreal-systems-engineer", "unreal-world-builder"]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Epic Games Inc.
|
||||
- Epic
|
||||
|
||||
## Definition
|
||||
Epic Games 是全球领先的互动娱乐软件公司，总部位于美国北卡罗来纳州凯瑞（Cary, NC），是 Unreal Engine 游戏引擎的开发商。其产品涵盖 Unreal Engine（虚幻引擎）、Fortnite（堡垒之夜）、Epic Games Store 等。
|
||||
|
||||
## Role in LLM-Wiki-Agent Context
|
||||
Epic Games 为 [[UnrealEngine5]] 提供核心基础设施，是 [[UnrealWorldBuilder]]、 [[UnrealSystemsEngineer]]、 [[UnrealMultiplayerArchitect]]、 [[UnrealTechnicalArtist]] 等 Agent 的技术基础来源。
|
||||
|
||||
## Key Contributions
|
||||
- **Unreal Engine 5**：游戏引擎，提供 World Partition、Nanite、Lumen、Virtual Shadow Maps 等核心技术
|
||||
- **Nanite**：虚拟化几何系统，处理亿级三角形规模的几何细节
|
||||
- **World Partition**：开放世界分区管理框架
|
||||
- **PCG (Procedural Content Generation)**：程序化内容生成系统
|
||||
- **Unreal Editor**：多用户协作编辑支持（One File Per Actor 模式）
|
||||
|
||||
## Connection to Other Entities
|
||||
- [[UnrealEngine5]] ← 产品 ← Epic Games
|
||||
- [[UnrealWorldBuilder]] ← 运行环境 ← [[UnrealEngine5]] ← 引擎提供 ← Epic Games
|
||||
- [[Epic Games]] ← 竞争对手 → Unity Technologies（Unity 引擎开发商）
|
||||
|
||||
## Sources
|
||||
- [[unreal-systems-engineer]]
|
||||
- [[unreal-world-builder]]
|
||||
27
wiki/entities/Ethan-Mollick.md
Normal file
27
wiki/entities/Ethan-Mollick.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Ethan Mollick"
|
||||
type: entity
|
||||
tags: [ai-prompting, education, entrepreneurship]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Mollick
|
||||
- Ethan Mollick
|
||||
|
||||
## Overview
|
||||
Ethan Mollick 是宾夕法尼亚大学沃顿商学院的副教授、One Useful Thing 的作者，专注于 AI 在教育和工作中的应用。他是目前 AI prompting 领域最具影响力的实践研究者之一，以"structured prompts"和"persona pattern"方法著称。
|
||||
|
||||
## Core Method
|
||||
- **Structured Prompts**：通过明确角色、任务、格式和约束来结构化 prompts，减少 LLM 输出方差
|
||||
- **Persona Pattern**：让 AI 扮演特定专家角色（如"你是具有20年经验的资深工程师"），利用角色设定激发更有针对性的输出
|
||||
- **Co-Intelligence**：人与 AI 的最佳关系是"共同智能"——AI 不是替代者，而是思维放大器
|
||||
|
||||
## Role in ZK Steward
|
||||
ZK Steward 在"AI / prompting"任务中切换到 Mollick 视角，驱动 structured prompts 和 persona pattern 方法。
|
||||
|
||||
## Key Connections
|
||||
- [[ZK-Steward-Agent]] ← uses Mollick perspective for AI/prompting tasks
|
||||
- [[Domain-Thinking]] ← Mollick is the reference expert for AI/prompting domain
|
||||
- [[Domain-Thinking]] ← [[ZK-Steward-Agent]] 的第一句声明专家视角规范与 Mollick 的 persona pattern 直接对应
|
||||
@@ -1,42 +1,32 @@
|
||||
---
|
||||
title: "Euler Finance"
|
||||
type: entity
|
||||
tags: [blockchain, defi, exploit, lending, eoa-donation]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **时间**：2023 年 3 月 13 日
|
||||
- **平台**：Ethereum
|
||||
- **损失**：1.97 亿美元（Euler Finance 无辜用户存款几乎全损）
|
||||
- **根本原因**：donate-to-reserves 操纵攻击（Euler 白帽事后命名）
|
||||
- **攻击者**：关联 Lazarus Group（朝鲜黑客组织）
|
||||
- **白帽救援**：攻击者后归还全部资金（通过协商）
|
||||
|
||||
## 攻击原理
|
||||
|
||||
Euler Finance 的 `donateToReserves()` 函数允许任意用户将自己的 ETH 转入储备池。当攻击者先存款、后捐赠、后借款时，其健康因子（health factor）在 `eToken.balanceOf()` 更新前被错误计算，导致超额借款：
|
||||
|
||||
1. 攻击者存入 30 ETH（获得 30 eETH）
|
||||
2. 攻击者调用 `donateToReserves(30 ETH)`，将 30 eETH 转入储备
|
||||
3. 此时攻击者的真实余额（3000 ETH）远高于名义余额（0），但清算逻辑基于名义余额
|
||||
4. 攻击者以极低抵押率（10 倍杠杆）借入 10 倍存款规模的资产
|
||||
5. 抵押品价值下跌时，清算机器人按错误健康因子执行清算，攻击者获超额清算收益
|
||||
|
||||
关键漏洞：`donateToReserves()` 的实现没有考虑对内部 accounting 的影响，健康因子计算依赖于可被操纵的 `eToken.balanceOf()` 而非内部余额追踪。
|
||||
|
||||
## 关键教训
|
||||
- **不要相信任何"管理员"函数是安全的**：看似无害的 `donateToReserves()` 影响了整个清算引擎
|
||||
- **协议不变量必须考虑所有代码路径**：包括看似无害的辅助函数
|
||||
- **白帽救援**：最终攻击者归还资金（否则 1.97 亿无法追回），成为 DeFi 历史上最大白帽救援案例
|
||||
|
||||
## 关联漏洞类型
|
||||
- [[Flash-Loan-Attack]] — 攻击使用闪电贷提供初始资金
|
||||
- [[Oracle-Manipulation]] — 健康因子计算依赖可操纵的内部状态
|
||||
- 经济攻击（Economic Exploit）：利用 DeFi 协议的会计逻辑错误
|
||||
|
||||
## 关联页面
|
||||
- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Euler Finance 作为关键记忆模式收录于 Exploit Pattern Library
|
||||
- [[The-DAO-2016]] — 同为 DeFi 安全史上的里程碑事件，但攻击类型不同
|
||||
- [[Curve-Finance]] — 2023 年另一大 DeFi 安全事件
|
||||
---
|
||||
title: "Euler Finance"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Overview
|
||||
Euler Finance 是以太坊上的非托管借贷协议，2023 年 3 月 13 日遭受闪电贷攻击，损失约 1.97 亿美元。攻击核心是协议缺少对抵押健康度的关键检查——允许用户以超低抵押率借出资产，并利用闪电贷操纵价格后发起清算获利。
|
||||
|
||||
## Key Facts
|
||||
- **攻击时间**：2023 年 3 月 13 日
|
||||
- **损失金额**：约 1.97 亿美元
|
||||
- **攻击类型**：闪电贷价格操纵 + 协议逻辑漏洞
|
||||
- **主要漏洞**：允许用户以 eToken 抵押借入资产（donateToReserve）
|
||||
|
||||
## Attack Mechanism
|
||||
1. 攻击者利用闪电贷借出大量 ETH
|
||||
2. 攻击者向 Euler Finance 的 eETH 池捐赠部分 ETH，大幅降低健康度
|
||||
3. 攻击者通过多笔操作让自身债务超过清算门槛
|
||||
4. 攻击者以超低抵押率借出大量资产（超过应有的抵押额度）
|
||||
5. 利用操纵后的价格触发清算，攻击者从清算中获取超额利润
|
||||
|
||||
## Significance
|
||||
- 暴露了 DeFi 借贷协议中"抵押健康度检查"的致命重要性
|
||||
- 促使借贷协议重新审查 eToken 的清算机制
|
||||
- 推动了更严格的协议级安全审计标准
|
||||
- 最终攻击者返还了全部资金（通过与白帽黑客谈判）
|
||||
|
||||
## Sources
|
||||
- [[engineering-solidity-smart-contract-engineer]]
|
||||
- [[blockchain-security-auditor]]
|
||||
|
||||
36
wiki/entities/EvidenceQA.md
Normal file
36
wiki/entities/EvidenceQA.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "EvidenceQA"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [agents-orchestrator, handoff-templates]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
**EvidenceQA** is The Agency's screenshot-obsessed QA specialist agent — requires visual proof as validation evidence and provides clear PASS/FAIL decisions with specific feedback.
|
||||
|
||||
## Role
|
||||
- **Role**: Screenshot-based quality validation specialist
|
||||
- **Personality**: Meticulous, evidence-driven, uncompromising
|
||||
- **Vibe**: Visual proof or it didn't happen
|
||||
|
||||
## Core Responsibilities
|
||||
- Test each task implementation only with task-specific validation
|
||||
- Require screenshot evidence for all validation
|
||||
- Provide clear PASS/FAIL decision with specific feedback
|
||||
- Operate within the [[Dev-QA-Loop]] of the [[AgentsOrchestrator]] pipeline
|
||||
|
||||
## Key Principle
|
||||
> "Every task must pass QA before advancing" — EvidenceQA enforces this by requiring visual proof for all validations.
|
||||
|
||||
## Spawned By
|
||||
- [[AgentsOrchestrator]] — Phase 3 of the pipeline
|
||||
|
||||
## Validates
|
||||
- [[FrontendDeveloper]] implementations
|
||||
- [[BackendArchitect]] implementations
|
||||
- [[MobileAppBuilder]] implementations
|
||||
- [[DevOpsAutomator]] infrastructure tasks
|
||||
|
||||
## Sources
|
||||
- [[agents-orchestrator]]
|
||||
49
wiki/entities/FBA.md
Normal file
49
wiki/entities/FBA.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "FBA"
|
||||
type: entity
|
||||
tags:
|
||||
- amazon
|
||||
- logistics
|
||||
- fulfillment
|
||||
- ecommerce
|
||||
- cross-border
|
||||
sources:
|
||||
- marketing-cross-border-ecommerce
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Fulfillment by Amazon
|
||||
- FBA Program
|
||||
- 亚马逊自营物流
|
||||
|
||||
## Definition
|
||||
|
||||
FBA（Fulfillment by Amazon）是亚马逊提供的自营物流服务，卖家将商品批量发送至亚马逊运营中心，由亚马逊负责存储、分拣、包装、配送及售后客服。FBA 是跨境电商最重要的履约方式之一，能让商品享有 Prime 标志，大幅提升转化率。
|
||||
|
||||
## Core Capabilities
|
||||
- **Inbound Shipping Plan**：创建入库计划，管理发货入仓流程
|
||||
- **Inventory Performance Index (IPI)**：库存绩效指数，衡量库存效率和补货及时性，低于阈值会限制仓储容量
|
||||
- **Long-term Storage Fee Control**：超 365 天商品面临高额长期仓储费，需主动管理库存周转
|
||||
- **Multi-site Inventory Transfer**：多站点库存调拨，适合 FBA Pan-EU 或泛欧计划
|
||||
- **FBA Auto-processing Returns**：退货自动处理，减轻卖家运营负担
|
||||
- **Prime Badge**：FBA 商品自动获得 Prime 标志，带来更高搜索排名和转化率
|
||||
|
||||
## Key Metrics
|
||||
| 指标 | 目标值 | 说明 |
|
||||
|------|--------|------|
|
||||
| IPI 分数 | > 700 | 低于 500 会触发仓储限制 |
|
||||
| 库存周转 | > 6x/年 | 避免长期仓储费 |
|
||||
| 在途时间 | 7-14 天 | 空运更快但成本更高 |
|
||||
| 退货率 | < 类别均值 | 退货损失计入 SKU 成本 |
|
||||
|
||||
## Usage in Cross-Border Context
|
||||
- 头程物流（First-mile）：从中国工厂到亚马逊运营中心，支持 FCL/LCL 海运、空运、中欧班列
|
||||
- FBA 费用 = 仓储费（按体积/时间）+ 执行费（按重量/尺寸）
|
||||
- IPI 不达标 → 仓储容量受限 → 无法发送新库存
|
||||
- 长期仓储费：每立方英尺 $6.90（超 365 天），每件 $0.15（超 180 天）
|
||||
|
||||
## Connections
|
||||
- [[Amazon Ads]]：FBA 商品可投放 Sponsored Products/Sponsored Brands/Sponsored Display 广告
|
||||
- [[Supply Chain Strategist Agent]]：FBA 头程物流规划依赖供应链专业知识
|
||||
- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[FBA]]
|
||||
29
wiki/entities/Filos-Christolakis.md
Normal file
29
wiki/entities/Filos-Christolakis.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Filos Christolakis"
|
||||
type: entity
|
||||
tags:
|
||||
- Micro Focus
|
||||
- Cloud Transformation
|
||||
- CTP
|
||||
- Terraform
|
||||
- SES
|
||||
sources:
|
||||
- ctp-topic-12-using-ses-smtp-service-terraform-module
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
Micro Focus CTP/SRE 团队成员，AWS SES SMTP Terraform 模块的开发者，主讲 CTP Topic 12，讲解了该模块的技术架构、部署方案及使用注意事项。
|
||||
|
||||
## Aliases
|
||||
- Filos Christolakis
|
||||
|
||||
## Role
|
||||
- CTP/SRE 团队成员
|
||||
- SES Terraform 模块开发者
|
||||
- CTP Topic 12 主讲人之一
|
||||
|
||||
## Connections
|
||||
- [[Christian Deckelmann]] — CTP 负责人，共同主讲 CTP Topic 12
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] — 模块开发来源
|
||||
- [[VPC Wrapper Module]] — SES 模块依赖 VPC Wrapper 预先配置的 SMTP VPC 终端节点
|
||||
41
wiki/entities/Finance-Tracker.md
Normal file
41
wiki/entities/Finance-Tracker.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Finance Tracker Agent"
|
||||
type: entity
|
||||
tags: ["agent-personality", "finance", "ai-agent"]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Overview
|
||||
Finance Tracker Agent 是 The Agency 多智能体系统中的财务专家角色，专注于企业财务规划、预算管理、现金流优化、投资分析与合规管控。以绿色 💰 为标识，强调财务准确性和风险管控。
|
||||
|
||||
## Aliases
|
||||
- Finance Tracker
|
||||
- 财务追踪代理
|
||||
|
||||
## Capabilities
|
||||
- 全面预算框架开发（含季度差异分析）
|
||||
- 12 期滚动现金流预测与季节性因子建模
|
||||
- NPV / IRR / 投资回收期三维投资分析
|
||||
- 成本优化与费用管控（目标 15%+ 年度效率提升）
|
||||
- 财务合规验证与审计跟踪文档
|
||||
|
||||
## Key Deliverables
|
||||
- 年度预算 + 季度差异分析 SQL 查询
|
||||
- Python `CashFlowManager` 现金流预测类
|
||||
- Python `InvestmentAnalyzer` 投资分析类
|
||||
- 财务绩效报告模板（执行摘要、详细分析、预算差异）
|
||||
|
||||
## Success Metrics
|
||||
- 预算准确率 95%+，含差异说明和纠正措施
|
||||
- 现金流预测准确率 90%+，90 天流动性可见性
|
||||
- 成本优化实现 15%+ 年度效率提升
|
||||
- 投资建议平均 ROI 25%+
|
||||
- 财务报告 100% 合规达标
|
||||
|
||||
## Connected Sources
|
||||
- [[support-finance-tracker]]
|
||||
|
||||
## Related Agents
|
||||
- [[Accounts-Payable-Agent]]：共享财务控制流程模式
|
||||
- [[Finance-FPA-Analyst]]：财务规划与分析延伸
|
||||
- [[Finance-Financial-Analyst]]：财务分析能力延伸
|
||||
35
wiki/entities/Foundry.md
Normal file
35
wiki/entities/Foundry.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Foundry"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Overview
|
||||
Foundry 是最流行的 Solidity 开发框架之一（由 Paradigm 开发），提供 Forge（测试）、Cast（合约交互）、Chisel（Solidity REPL）等工具链。与 Hardhat 相比，Foundry 以速度快（Rust 实现）、内置 Fuzz 测试和 Invariant 测试著称。
|
||||
|
||||
## Key Tools
|
||||
|
||||
### Forge
|
||||
- Solidity 测试框架，类比 Hardhat + Mocha
|
||||
- 支持 `vm.prank()` / `vm.startPrank()` 模拟调用者
|
||||
- 支持 `vm.expectRevert()` 验证 revert 行为
|
||||
- 内置 `testFuzz_*` 模糊测试和 `testInvariant_*` 不变测试
|
||||
- `forge snapshot` 生成 Gas 消耗快照
|
||||
|
||||
### Cast
|
||||
- 命令行合约交互工具
|
||||
- 发送交易、调用视图函数、解码事件
|
||||
- 访问链上数据
|
||||
|
||||
### Anvil
|
||||
- 本地 EVM 测试网络
|
||||
- 可分叉主网进行集成测试
|
||||
|
||||
## 与 Solidity Smart Contract Engineer 的关系
|
||||
- [[engineering-solidity-smart-contract-engineer]] 要求所有合约配备 Foundry 测试套件，分支覆盖率 >95%
|
||||
- Foundry 的 Fuzz 测试是发现边界条件和算术漏洞的关键工具
|
||||
- Gas 快照用于持续跟踪 Gas 优化效果
|
||||
|
||||
## Sources
|
||||
- [[engineering-solidity-smart-contract-engineer]]
|
||||
@@ -1,39 +1,37 @@
|
||||
---
|
||||
title: "Gemini API"
|
||||
title: "Gemini"
|
||||
type: entity
|
||||
tags: ["google", "image-generation", "ai", "gemini", "carousel"]
|
||||
sources: ["marketing-carousel-growth-engine", "我用-gemini-3-一口气做了-10-个应用-附教程"]
|
||||
last_updated: 2026-04-26
|
||||
entity_type: "AI Model"
|
||||
tags: ["ai", "gemini", "google", "multimodal", "image-generation"]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
## Overview
|
||||
|
||||
Google 的多模态 AI 模型 API，支持文本和图像生成。在 [[marketing-carousel-growth-engine]] 中用于生成 TikTok/Instagram 轮播图。
|
||||
Gemini 是 Google 开发的系列多模态 AI 模型，支持文本、代码、图像生成和理解等多种任务。在 AI 图片生成场景中，Gemini 支持多轮对话中的风格上下文传递，适合生成风格一致的系列图片。
|
||||
|
||||
## Key Details
|
||||
## Key Capabilities
|
||||
|
||||
- **Model**: `gemini-3.1-flash-image-preview`
|
||||
- **API**: Google Generative Language API
|
||||
- **Credential**: `GEMINI_API_KEY` 环境变量（免费层可用）
|
||||
- **Key**: https://aistudio.google.com/app/apikey
|
||||
- **多模态理解**：同时处理文本、图像、视频等多种输入
|
||||
- **图片生成**：Gemini Image Gen 支持通过文本提示词生成图片
|
||||
- **风格上下文**：在多轮对话中保持视觉风格一致性
|
||||
- **长上下文**：支持处理长篇文档和复杂指令
|
||||
|
||||
## Usage in Carousel Growth Engine
|
||||
## Usage in Image Generation
|
||||
|
||||
- **Slide 1**: 纯文本 prompt 生成首张幻灯片，定义视觉 DNA
|
||||
- **Slides 2-6**: 图生图模式，以 slide-1.jpg 作为 `--input-image` 参考输入，保持视觉连贯性
|
||||
- **Output**: 768x1376 (9:16) JPG 格式轮播图
|
||||
- **Script**: `generate-slides.sh` 编排管道，`generate_image.py`（Python via `uv`）调用 API
|
||||
在 AI 图片生成场景中，Gemini 的核心优势是通过多轮对话传递风格上下文：
|
||||
|
||||
## 技术规格
|
||||
1. 对话开始时设置系统级风格指令（System Prompt）
|
||||
2. 先生成第一张图片作为风格基准
|
||||
3. 后续图片通过 STYLE LOCK 块引用上一张的风格参数
|
||||
4. 支持用参考图锁定视觉基准（效果最强）
|
||||
|
||||
| 参数 | 值 |
|
||||
|------|-----|
|
||||
| 分辨率 | 768×1376 (9:16 竖版) |
|
||||
| 格式 | JPG（TikTok 拒绝 PNG） |
|
||||
| 视觉连贯性 | 第一张定义 DNA，后续图生图 |
|
||||
| 免费层 | 可用（需 Google AI Studio API Key） |
|
||||
## Related Concepts
|
||||
|
||||
## Aliases
|
||||
- Gemini
|
||||
- Google Gemini
|
||||
- Gemini 3.1 Flash Image
|
||||
- [[StyleSeed]]：Gemini 图片风格一致性的核心技术手段
|
||||
- [[StyleLock]]：Gemini 多轮对话中强制风格比对的检查机制
|
||||
- [[ReferenceImageConsistency]]：用 Gemini 生成的第一张图作为后续图的视觉基准
|
||||
|
||||
## Sources
|
||||
|
||||
- [[如何让AI生成风格一致的图片]]
|
||||
|
||||
27
wiki/entities/GerardGenette.md
Normal file
27
wiki/entities/GerardGenette.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Gérard Genette"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gérard Genette
|
||||
- Genette
|
||||
|
||||
## Overview
|
||||
Gérard Genette (1930–2018) 是法国文学理论家、结构主义者，以其叙事话语理论（Narrative Discourse）闻名于世。代表作《叙事话语》（Narrative Discourse: An Essay in Method, 1980）对叙事学产生了深远影响。
|
||||
|
||||
## Key Contributions
|
||||
- **Narrative Order / Anachrony**：叙事的时间结构分析，包括倒叙（Analepsis）和预叙（Prolepsis）
|
||||
- **Focalization（聚焦）**：谁在感知故事——零聚焦（上帝视角）、内聚焦（人物视角）、外聚焦（客观旁观）
|
||||
- **Narrative Voice**：叙述者的类型和叙事距离
|
||||
- **Paratexts**：标题、题词、副标题等文本边缘元素的意义
|
||||
|
||||
## In The Agency Context
|
||||
[[Academic Narratologist]] 使用 Genette's Narratology 分析叙事声音、聚焦模式和时序结构，是区分"讲述什么"与"如何讲述"的关键工具。
|
||||
|
||||
## References
|
||||
- Narrative Discourse: An Essay in Method (1980)
|
||||
- Narrative Discourse Revisited (1983)
|
||||
45
wiki/entities/GitHub Actions.md
Normal file
45
wiki/entities/GitHub Actions.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "GitHub Actions"
|
||||
type: entity
|
||||
tags: [CI/CD, Automation, DevOps]
|
||||
sources: [engineering-devops-automator]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# GitHub Actions
|
||||
|
||||
## 基本信息
|
||||
- **类型**：CI/CD 平台
|
||||
- **开发商**：GitHub (Microsoft)
|
||||
- **官网**：https://github.com/features/actions
|
||||
|
||||
## 定义
|
||||
GitHub Actions 是 GitHub 提供的自动化工作流平台，支持在 GitHub 仓库内构建、测试和部署代码，实现持续集成和持续交付。
|
||||
|
||||
## 核心组件
|
||||
- **Workflow**：自动化工作流，定义在 `.github/workflows/` 目录
|
||||
- **Job**：工作流中的一个执行单元
|
||||
- **Step**：Job 中的具体步骤，可以是 shell 命令或 Action
|
||||
- **Action**：可复用的工作流步骤，可以是社区构建或官方维护
|
||||
- **Runner**：执行 Job 的虚拟机（GitHub 托管或自托管）
|
||||
|
||||
## 在 DevOps Automator 中的角色
|
||||
- DevOps Automator 默认使用的 CI/CD 平台
|
||||
- 用于构建端到端流水线：security-scan → test → build → deploy
|
||||
- 支持 Blue-Green 部署的自动化执行
|
||||
|
||||
## 相关概念
|
||||
- [[CI/CD Pipeline]]
|
||||
- [[Blue-Green Deployment]]
|
||||
- [[Zero-Downtime Deployment]]
|
||||
|
||||
## 相关工具
|
||||
- Jenkins（开源 CI/CD）
|
||||
- GitLab CI（GitLab 内置 CI/CD）
|
||||
- ArgoCD（GitOps 持续交付）
|
||||
- Atlantis（Terraform CI/CD 自动化）
|
||||
|
||||
## Aliases
|
||||
- GitHub Actions
|
||||
- GHA
|
||||
- GitHub Workflows
|
||||
13
wiki/entities/GitHub-Copilot.md
Normal file
13
wiki/entities/GitHub-Copilot.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "GitHub Copilot"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- GitHub Copilot
|
||||
|
||||
## Overview
|
||||
微软的 AI 编程助手，其 Chat 功能支持自定义 Agent。The Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容，无需格式转换即可使用。
|
||||
@@ -1,18 +1,22 @@
|
||||
---
|
||||
title: "GitHubCopilot"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Identity
|
||||
GitHub Copilot — GitHub 开发的 AI 编程助手，通过 GitHub 官方集成支持用户自定义 agent。
|
||||
|
||||
## Role in Wiki
|
||||
- 使用 [[AgentFileFormat]] 作为 agent 定义标准
|
||||
- 通过 [[TheAgency]] 提供 147+ 专业化 agent
|
||||
- 用户级别全局生效（安装到 `~/.github/agents/` 或 `~/.copilot/agents/`）
|
||||
|
||||
## Related
|
||||
- [[github-copilot]] — 集成文档
|
||||
- [[AgentFileFormat]] — 支持的文件格式
|
||||
- [[TheAgency]] — agent 来源
|
||||
---
|
||||
title: "GitHub Copilot"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Copilot
|
||||
- GitHub Copilot Chat
|
||||
|
||||
## Overview
|
||||
GitHub Copilot 是微软/GitHub 的 AI 编程助手。The Agency 的 Agent 可直接复制到 `~/.github/agents/` 和 `~/.copilot/agents/`，无需转换，与 Claude Code 并列为原生支持 `.md` 格式的工具。
|
||||
|
||||
## Key Facts
|
||||
- Agent 格式：`.md`（原生支持）
|
||||
- 安装路径：`~/.github/agents/`、`~/.copilot/agents/`
|
||||
- 安装命令：`./scripts/install.sh --tool copilot`
|
||||
- 自动发现：Copilot 自动扫描配置目录
|
||||
|
||||
## Sources
|
||||
- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
|
||||
|
||||
@@ -1,32 +1,37 @@
|
||||
---
|
||||
title: "Google Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Google AdWords
|
||||
- GoogleAds
|
||||
|
||||
## Overview
|
||||
Google Ads 是全球最大的在线广告平台，由 Google 运营，支持搜索、展示、视频、购物、Performance Max 等全类型广告格式。是 [[PaidMediaPpcStrategist]] 的核心投放渠道。
|
||||
|
||||
## Key Capabilities
|
||||
- **Search Ads**: 基于关键词的文本广告，出现在 Google 搜索结果页
|
||||
- **Shopping Ads**: 产品购物广告，带图片、价格、商家信息
|
||||
- **Performance Max**: AI 驱动的全渠道自动化广告，覆盖所有 Google 广告位
|
||||
- **Demand Gen**: 触达高意图消费者的发现型广告
|
||||
- **Display Ads**: 展示广告，覆盖 200 万+ 网站和应用
|
||||
- **Video Ads**: YouTube 视频广告
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 自动竞价策略（tCPA/tROAS/Max Conversions/Max Conversion Value）
|
||||
- Customer Match 受众定向
|
||||
- Auction Insights 竞争情报
|
||||
- Google Ads API 大规模账户管理
|
||||
- MCC（My Client Center）多账户管理
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 使用 Google Ads 作为核心投放平台
|
||||
- [[GoogleAdsAPI]] 提供编程接口支撑自动化运营
|
||||
---
|
||||
title: "Google Ads"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- google
|
||||
- ppc
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
Google Ads（前称 Google AdWords）是 Google 旗下的在线广告平台，是全球规模最大的付费搜索和展示广告平台，支持 Search、Shopping、Performance Max、Demand Gen、Display、Video 等多种广告类型。
|
||||
|
||||
## Core Capabilities Referenced
|
||||
- **Search Ads**：文字搜索广告，通过关键词触发，基于 Quality Score 和 Bid 参与竞价
|
||||
- **Shopping Ads**：产品购物广告，基于 Google Merchant Center 商品数据，自动展示产品图片、价格和商家信息
|
||||
- **Performance Max**：AI 驱动的全渠道广告系列，自动跨 Google 所有库存（Search、Display、YouTube、Gmail、Shopping）优化
|
||||
- **Demand Gen**：在 YouTube、Gmail、Discover 触达处于考虑阶段用户的需求生成广告
|
||||
- **Display Ads**：展示广告，基于受众定位在 Google 展示网络中投放视觉广告
|
||||
- **Video Ads**：YouTube 视频广告，支持多种出价方式（CPV、CPM、TrueView）
|
||||
|
||||
## Key Features for PPC Strategy
|
||||
- **Automated Bidding**：tCPA/tROAS/Max Conversions/Max Conversion Value
|
||||
- **Audience Manager**：Customer Match、Similar Segments、In-Market/Affinity 受众
|
||||
- **Auction Insights**：竞争情报分析，包括平均展示份额、竞争密度、顶部竞价占比
|
||||
- **Conversion Tracking**：转化追踪配置，支持网站/App/离线转化
|
||||
- **MCC（My Client Center）**：代理/广告主管理多个子账户的顶层结构
|
||||
- **Google Ads API**：企业级程序化账户管理接口，支持大规模自动化操作
|
||||
|
||||
## Connections
|
||||
- [[MicrosoftAdvertising]]：Google Ads 的主要竞争平台，账户架构和竞价机制相似，可做跨平台预算分配
|
||||
- [[AmazonAds]]：电商场景补充，Google Ads 侧重搜索意图，Amazon Ads 侧重购买意图
|
||||
- [[AutomatedBiddingStrategy]]：Google Ads 核心能力之一
|
||||
- [[PerformanceMax]]：Google Ads 独有的 AI 驱动全渠道广告系列
|
||||
|
||||
40
wiki/entities/GoogleAdsAPI.md
Normal file
40
wiki/entities/GoogleAdsAPI.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Google Ads API"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- google
|
||||
- api
|
||||
- automation
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
Google Ads API（Google Ads API v17+）是 Google 提供的企业级编程接口，允许开发者程序化地管理 Google Ads 账户的所有方面，支持大规模广告系列创建、修改、报告拉取和自动化操作，是企业级 PPC 管理的核心基础设施。
|
||||
|
||||
## Core Capabilities Referenced
|
||||
- **Account Management**：MCC 级账户结构操作、子账户创建/修改
|
||||
- **Campaign Operations**：广告系列、广告组、关键词、广告文案的 CRUD 操作
|
||||
- **Bidding Strategy Management**：自动化竞价策略的创建和调整
|
||||
- **Audience Management**：受众定向、受众列表操作
|
||||
- **Reporting**：拉取 performance metrics、auction insights、conversion data
|
||||
- **Budget Management**：预算分配、 pacing 调整
|
||||
|
||||
## Integration in PPC Strategy Agent
|
||||
Agent 规范建议优先使用 Google Ads API 或 MCP（Model Context Protocol）工具获取 live data：
|
||||
- **Pre-recommendation baseline**：在做任何策略建议前，先拉取 `account_summary`、`list_campaigns`、`auction_insights`
|
||||
- **Execution without leaving workflow**：直接通过 API 执行结构性变更，无需人工操作后台
|
||||
- **Automated analysis**：定期自动拉取账户健康评分、异常检测
|
||||
|
||||
## Tooling Options
|
||||
- **Official Google Ads API Client Libraries**：Python、Java、PHP、Ruby、DotNET、Perl
|
||||
- **Google Ads MCP Tools**：Model Context Protocol 工具，可被 AI Agent 直接调用
|
||||
- **Google Ads Scripts**：基于 JavaScript 的轻量自动化脚本，适合简单任务
|
||||
|
||||
## Connections
|
||||
- [[GoogleAds]]：API 的承载平台
|
||||
- [[MCCLevelStrategy]]：API 是 MCC 级策略执行的核心工具
|
||||
- [[PaidMediaPPCCampaignStrategist]]：Agent 规范强调优先使用 API 而非手动操作
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "GoogleGemini"
|
||||
type: entity
|
||||
tags: ["llm-provider", "google", "gemini"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gemini
|
||||
- Google Gemini
|
||||
- Gemini Flash
|
||||
- Gemini Pro
|
||||
|
||||
## Definition
|
||||
Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
|
||||
|
||||
## Role in LLM Routing
|
||||
- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
|
||||
- **Gemini Pro**：中端定位，提供能力与成本的平衡
|
||||
- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
|
||||
- **延迟**：低（Gemini Flash）
|
||||
- **优势**：极高的性价比，特别适合大规模、低成本推理
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider
|
||||
- [[Anthropic]] — 高精度基准 Provider
|
||||
---
|
||||
title: "GoogleGemini"
|
||||
type: entity
|
||||
tags: ["llm-provider", "google", "gemini"]
|
||||
sources: ["engineering-autonomous-optimization-architect", "marketing-carousel-growth-engine"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gemini
|
||||
- Google Gemini
|
||||
- Gemini Flash
|
||||
- Gemini Pro
|
||||
|
||||
## Definition
|
||||
Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
|
||||
|
||||
## Role in LLM Routing
|
||||
- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
|
||||
- **Gemini Pro**：中端定位，提供能力与成本的平衡
|
||||
- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
|
||||
- **延迟**：低（Gemini Flash）
|
||||
- **优势**：极高的性价比，特别适合大规模、低成本推理
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider
|
||||
- [[Anthropic]] — 高精度基准 Provider
|
||||
|
||||
@@ -1,34 +1,44 @@
|
||||
---
|
||||
title: "Grafana"
|
||||
type: entity
|
||||
tags: [visualization, monitoring, open-source]
|
||||
sources: [可自动化-可扩展-ai增强的电商数据采集与处理系统]
|
||||
last_updated: 2025-11-11
|
||||
tags: [Visualization, Observability, DevOps]
|
||||
sources: [engineering-devops-automator]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# Grafana
|
||||
|
||||
## 基本信息
|
||||
- **类型**：开源可视化平台
|
||||
- **开发商**：Grafana Labs
|
||||
- **官网**：https://grafana.com
|
||||
|
||||
## 定义
|
||||
Grafana 是一个开源的分析和交互式可视化平台，支持从多种数据源（Prometheus、Elasticsearch、InfluxDB 等）获取数据，创建实时仪表板和告警。
|
||||
|
||||
## 核心功能
|
||||
- **多数据源支持**：Prometheus、Elasticsearch、InfluxDB、MySQL、CloudWatch 等
|
||||
- **可视化面板**：Graph、Stat、Gauge、Table、Heatmap 等多种图表类型
|
||||
- **Dashboard 即代码**：支持 JSON 导出和版本控制
|
||||
- **告警规则**：支持基于查询结果的告警
|
||||
- **变量系统**：支持动态仪表板和交互式过滤
|
||||
|
||||
## 在 DevOps Automator 中的角色
|
||||
- 可观测性可视化平台的核心组件
|
||||
- 展示 Prometheus 采集的应用程序和基础设施指标
|
||||
- 用于构建运维仪表板，跟踪部署频率、MTTR 等关键指标
|
||||
|
||||
## 相关概念
|
||||
- [[Observability]]
|
||||
- [[Prometheus]]
|
||||
|
||||
## 相关工具
|
||||
- Grafana Loki（日志聚合）
|
||||
- Grafana Tempo（分布式追踪）
|
||||
- Grafana OnCall（告警管理）
|
||||
- Grafana Agent（指标、日志、追踪的统一采集）
|
||||
|
||||
## Aliases
|
||||
- Grafana Labs
|
||||
- Grafana
|
||||
- Grafana Dashboard
|
||||
|
||||
## Summary
|
||||
开源数据可视化平台，支持多种数据源，可创建交互式仪表盘。
|
||||
|
||||
## Description
|
||||
Grafana 是一款开源的可观测性平台，用于数据可视化和监控仪表盘。
|
||||
|
||||
### 核心特性
|
||||
- 多数据源支持（Prometheus、PostgreSQL、InfluxDB）
|
||||
- 丰富的图表类型
|
||||
- 告警功能
|
||||
- 模板变量
|
||||
- 团队协作
|
||||
|
||||
### 电商场景适用性
|
||||
连接 PostgreSQL，可视化电商产品趋势、价格分布、竞品对比等分析报表。
|
||||
|
||||
## Use Cases
|
||||
- [[可自动化-可扩展-ai增强的电商数据采集与处理系统]] — 数据可视化展示层
|
||||
|
||||
## Connections
|
||||
- [[PostgreSQL]] — 读取电商数据进行可视化
|
||||
|
||||
- Grafana Visualization
|
||||
|
||||
69
wiki/entities/GraphDaemon.md
Normal file
69
wiki/entities/GraphDaemon.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: "GraphDaemon"
|
||||
type: entity
|
||||
entity_type: tool
|
||||
tags:
|
||||
- LSP
|
||||
- code-intelligence
|
||||
- semantic-graph
|
||||
- TypeScript
|
||||
sources:
|
||||
- lsp-index-engineer.md
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
GraphDaemon（graphd）是 LSP/Index Engineer Agent 的核心图谱守护进程，负责协调多个 LSP 客户端并发运行，将异构语言服务器的响应转换为统一的语义图谱，为沉浸式代码可视化提供基础设施。默认要求 TypeScript 和 PHP 语言服务器生产就绪。
|
||||
|
||||
## Core Components
|
||||
|
||||
### LSP Client Management
|
||||
- **LSPClients**：`Map<string, LanguageClient>` — 管理 TypeScript、PHP、Go、Rust、Python 等多语言 LSP 客户端
|
||||
- **Capabilities**：`Map<string, ServerCapabilities>` — 存储各语言服务器的能力协商结果
|
||||
|
||||
### Graph State
|
||||
- **Nodes**：`Map<NodeId, GraphNode>` — 文件节点和符号节点
|
||||
- **Edges**：`Map<EdgeId, GraphEdge>` — contains/imports/calls/refs 关系边
|
||||
- **Index**：SymbolIndex — 符号索引，支持快速查询
|
||||
|
||||
### API Endpoints
|
||||
- `/graph` — 返回完整图谱（< 100ms，< 10k 节点）
|
||||
- `/nav/:symId` — 符号导航（< 20ms 缓存 / < 60ms 未缓存）
|
||||
- `/stats` — 系统统计信息
|
||||
|
||||
### WebSocket Server
|
||||
- 实时推送图谱差异更新，延迟 < 50ms
|
||||
|
||||
### File Watching
|
||||
- 文件变化监听和 Git hooks 触发增量更新
|
||||
|
||||
## Graph Schema
|
||||
|
||||
### Node Types
|
||||
- `file` — 文件节点
|
||||
- `module` — 模块节点
|
||||
- `class` — 类符号
|
||||
- `function` — 函数符号
|
||||
- `variable` — 变量符号
|
||||
- `type` — 类型符号
|
||||
|
||||
### Edge Types
|
||||
- `contains` — 文件包含符号
|
||||
- `imports` — 模块导入关系
|
||||
- `extends` — 继承关系
|
||||
- `implements` — 实现关系
|
||||
- `calls` — 函数调用关系
|
||||
- `references` — 符号引用关系
|
||||
|
||||
## Performance Targets
|
||||
- /graph 端点：< 100ms（< 10k 节点）
|
||||
- /nav/:symId：< 20ms（缓存）/ < 60ms（未缓存）
|
||||
- WebSocket 延迟：< 50ms
|
||||
- 内存使用：< 500MB
|
||||
- 规模能力：100k+ 符号无性能降级
|
||||
|
||||
## Connections
|
||||
- [[GraphDaemon]] ← builds ← [[SemanticCodeGraph]]
|
||||
- [[GraphDaemon]] ← orchestrates ← [[LSPOrchestrator]]
|
||||
- [[GraphDaemon]] ← streams via ← [[WebSocket]]
|
||||
- [[GraphDaemon]] ← indexes via ← [[nav.index.jsonl]]
|
||||
58
wiki/entities/Great-Expectations.md
Normal file
58
wiki/entities/Great-Expectations.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Great Expectations"
|
||||
type: entity
|
||||
tags: [data-engineering, data-quality, testing, validation]
|
||||
sources: [engineering-data-engineer]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Great Expectations（gx）是 Python 原生的数据质量验证框架，支持自动化测试数据管道的可靠性。Data Engineer Agent 使用 Great Expectations 在 Silver→Gold 层之间实施行级数据质量评分，确保 Gold 层数据符合 SLA 承诺。
|
||||
|
||||
## Core Usage Pattern
|
||||
|
||||
```python
|
||||
import great_expectations as gx
|
||||
|
||||
context = gx.get_context()
|
||||
|
||||
def validate_silver_orders(df) -> dict:
|
||||
batch = context.sources.pandas_default.read_dataframe(df)
|
||||
result = batch.validate(
|
||||
expectation_suite_name="silver_orders.critical",
|
||||
run_id={"run_name": "silver_orders_daily", "run_time": datetime.now()}
|
||||
)
|
||||
stats = {
|
||||
"success": result["success"],
|
||||
"evaluated": result["statistics"]["evaluated_expectations"],
|
||||
"passed": result["statistics"]["successful_expectations"],
|
||||
"failed": result["statistics"]["unsuccessful_expectations"],
|
||||
}
|
||||
if not result["success"]:
|
||||
raise DataQualityException(f"Silver orders failed validation: {stats['failed']} checks failed")
|
||||
return stats
|
||||
```
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Expectations**：声明式数据质量断言（如 `expect_column_values_to_be_between`、`expect_column_mean_to_be_between`）
|
||||
- **Profiling**：从现有数据自动生成期望规则
|
||||
- **Data Docs**：自动化数据质量报告（HTML 格式）
|
||||
- **Checkpoint**：将测试嵌入 CI/CD 流水线
|
||||
|
||||
## Role in Medallion Architecture
|
||||
|
||||
- **Bronze 层**：基础完整性检查（文件是否可读、schema 是否存在）
|
||||
- **Silver 层**：字段级质量验证（null 率、值范围、分布）
|
||||
- **Gold 层**：业务规则验证 + SLA 评分，评分必须附加到每行
|
||||
|
||||
## Integration
|
||||
|
||||
- **Spark Integration**：通过 `gx.spark.from_pyspark_df()` 直接验证 PySpark DataFrame
|
||||
- **Databricks**：原生 Great Expectations + Databricks Jobs 集成
|
||||
- **dbt Tests**：Great Expectations 规则可导出为 dbt 测试
|
||||
|
||||
## Related Concepts
|
||||
- [[Data Contract]]
|
||||
- [[Medallion Architecture]]
|
||||
34
wiki/entities/Greg.md
Normal file
34
wiki/entities/Greg.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Greg"
|
||||
type: entity
|
||||
tags:
|
||||
- CTP
|
||||
- DBRE
|
||||
- AWS
|
||||
- RDS
|
||||
sources:
|
||||
- learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
Greg 是 CTP（Cloud Transformation Programme）团队的 DBRE（Database Reliability Engineering）团队成员，在 Learning Sessions 中主讲通过 Terraform 部署 RDS 的实践课程。
|
||||
|
||||
## Role
|
||||
- **DBRE 团队成员**：负责数据库可靠性工程
|
||||
- **Terraform IaC 推广者**：积极倡导使用 Terraform 而非 Console 方式部署任何规模的 RDS
|
||||
|
||||
## Key Contributions
|
||||
- 推广 IaC 六大核心价值：速度、灵活性、一致性、灾难恢复、文档化、自动化
|
||||
- 主张"代码即文档"（The code is the documentation）作为 IaC 的核心理念
|
||||
- 推荐 Gruntwork RDS Service 模块（含 KMS 加密 + CloudWatch 告警）作为 RDS 部署首选
|
||||
- 推广 Terragrunt 作为 Terraform 封装工具，使用 tagged release 确保稳定性
|
||||
|
||||
## Connections
|
||||
- [[Amazon-RDS]]：主要负责的云资源
|
||||
- [[Terragrunt]]：推荐的 IaC 工具
|
||||
- [[Gruntwork]]：模块来源
|
||||
- [[Infrastructure-as-Code]]：核心方法论
|
||||
|
||||
## Referenced In
|
||||
- [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
|
||||
@@ -9,7 +9,8 @@ sources:
|
||||
- learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi
|
||||
- ctp-topic-9-ci-cd-with-gruntwork
|
||||
- ctp-topic-16-cross-account-terraform-modules
|
||||
last_updated: 2023-08-08
|
||||
- learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Profile
|
||||
|
||||
25
wiki/entities/Hermes-Agent.md
Normal file
25
wiki/entities/Hermes-Agent.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Hermes Agent"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
Hermes Agent 是另一个本地运行的 AI Agent 系统，与 OpenClaw 并列，通过 n8n 工作流进行统一编排。
|
||||
|
||||
## Key Facts
|
||||
- **默认端口**：8642
|
||||
- **Agent 指定方式**：`"model": "hermes-agent"`
|
||||
- **网络**：与 OpenClaw 共用同一局域网 IP，仅端口不同
|
||||
|
||||
## 与 OpenClaw 对比
|
||||
|
||||
| 属性 | Hermes Agent | OpenClaw |
|
||||
|------|-------------|----------|
|
||||
| 默认端口 | 8642 | 18789 |
|
||||
| Agent 指定方式 | `"model": "hermes-agent"` | `"model": "openclaw:<agentId>""` |
|
||||
| OpenAI 兼容端点 | 默认开启 | 默认关闭（需手动开启） |
|
||||
|
||||
## Related Pages
|
||||
- [[n8n-调用openclaw-agents的工作流架构]]
|
||||
- [[OpenClaw]]
|
||||
78
wiki/entities/IncidentCommander.md
Normal file
78
wiki/entities/IncidentCommander.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "Incident Commander (IC)"
|
||||
type: entity
|
||||
tags: [incident-management, reliability, roles]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
事故指挥官（Incident Commander，IC）是生产事故响应中的核心协调角色——唯一决策者，负责管理时间线、分配角色、驱动结构化决策。核心理念：**"Single throat to yell at, single brain to decide"**（单一出口发号施令，单一大脑做决策）。
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### 1. 事故协调
|
||||
- 在事故声明后立即接管指挥权
|
||||
- 分配明确角色：Communications Lead、Technical Lead、Scribe
|
||||
- 维持固定节奏的状态更新（按严重等级：SEV1 每 15 分钟）
|
||||
|
||||
### 2. 时间线管理
|
||||
- 记录每个行动和发现（含 UTC 时间戳）
|
||||
- 维护准确的事故时间线作为决策依据
|
||||
- 确保所有参与者信息同步
|
||||
|
||||
### 3. 决策驱动
|
||||
- 在时间盒内做出决策（15 分钟假设验证）
|
||||
- 优先止血（缓解）而非根因分析
|
||||
- 当调查路径无法确认时，果断切换
|
||||
|
||||
### 4. 沟通管理
|
||||
- 协调干系人（工程师/管理层/客户）的信息发布
|
||||
- 确保沟通节奏与严重等级匹配
|
||||
- 宣布事故解决并发送 All-Clear
|
||||
|
||||
## Incident Roles Ecosystem
|
||||
|
||||
```
|
||||
Incident Commander (IC)
|
||||
├── Communications Lead — 干系人状态更新（内部/外部）
|
||||
├── Technical Lead — 诊断和修复（使用 runbooks、可观测性工具）
|
||||
└── Scribe — 实时行动记录和时间线维护
|
||||
```
|
||||
|
||||
## Severity-Based Response
|
||||
|
||||
| 严重等级 | IC 响应时间 | 更新节奏 | 升级路径 |
|
||||
|----------|------------|----------|----------|
|
||||
| SEV1 | < 5 分钟 | 每 15 分钟 | VP Eng + CTO 即时 |
|
||||
| SEV2 | < 15 分钟 | 每 30 分钟 | Eng Manager 15 分钟内 |
|
||||
| SEV3 | < 1 小时 | 每 2 小时 | Team lead 下次站会 |
|
||||
| SEV4 | 下一个工作日 | 每日 | Backlog 评审 |
|
||||
|
||||
## Key Rules
|
||||
|
||||
| 规则 | 说明 |
|
||||
|------|------|
|
||||
| 决策权威 | IC 是唯一决策者，其他角色执行和支持 |
|
||||
| 不跳级 | 永远不跳过严重等级分类（决定后续所有行动） |
|
||||
| 实时记录 | 行动必须实时记录，而非事后回忆 |
|
||||
| 先止血后治本 | 优先缓解影响，根因分析在稳定后进行 |
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- **MTTD**（Mean Time to Detect）：< 5 分钟（SEV1/2）
|
||||
- **MTTR**（Mean Time to Resolve）：< 30 分钟（SEV1）
|
||||
- 100% SEV1/2 事故在 48 小时内完成复盘
|
||||
- 零重复事故（同样的根本原因不再出现第二次）
|
||||
|
||||
## Related Entities
|
||||
|
||||
| 角色 | 关系 |
|
||||
|------|------|
|
||||
| [[engineering-incident-response-commander]] | IC Agent 的智能体人格定义 |
|
||||
| [[engineering-sre]] | IC 的工程背景，通常由 SRE 担任 IC 角色 |
|
||||
| [[OnCallEngineer]] | IC 通常由 on-call 工程师担任或指定 |
|
||||
|
||||
## Aliases
|
||||
- IC（Incident Commander）
|
||||
- Incident Lead
|
||||
- Response Coordinator
|
||||
@@ -1,39 +1,26 @@
|
||||
---
|
||||
title: "Intelephense"
|
||||
type: entity
|
||||
tags: [language-server, php]
|
||||
sources: [lsp-index-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Intelephense 是 PHP 语言的主流 Language Server Protocol 实现，提供高性能的 PHP 代码智能功能，包括跳转到定义、查找引用、悬停文档、符号导航等。
|
||||
|
||||
## Usage in LSP/Index Engineer
|
||||
|
||||
LSP/Index Engineer 的 graphd 系统通过以下方式使用 Intelephense：
|
||||
|
||||
```typescript
|
||||
const phpClient = new LanguageClient('php', {
|
||||
command: 'intelephense',
|
||||
args: ['--stdio'],
|
||||
rootPath: projectRoot
|
||||
});
|
||||
```
|
||||
|
||||
## Known Limitations
|
||||
|
||||
Intelephense 与 TypeScript Language Server 相比：
|
||||
- 不支持层级符号（Hierarchical Symbols）
|
||||
- PHP 的命名空间和类结构解析有差异
|
||||
- LSP/Index Engineer 在 graphd 中需要针对这些差异进行适配处理
|
||||
|
||||
## Note
|
||||
|
||||
TypeScript 和 PHP 支持是 LSP/Index Engineer 的**默认要求**，必须首先达到生产就绪状态。PHP 优先使用 Intelephense，也可选择 phpactor 作为替代。
|
||||
|
||||
## Aliases
|
||||
- intelephense
|
||||
- PHP Language Server
|
||||
- PHP LSP
|
||||
---
|
||||
title: "Intelephense"
|
||||
type: entity
|
||||
entity_type: tool
|
||||
tags:
|
||||
- LSP
|
||||
- PHP
|
||||
- language-server
|
||||
sources:
|
||||
- lsp-index-engineer.md
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
Intelephense 是 PHP 语言的 LSP 实现，graphd 默认要求生产就绪的语言服务器之一，提供 PHP 代码的跳转定义、引用查找、悬停文档和自动完成功能。
|
||||
|
||||
## Details
|
||||
- **Command**: `intelephense --stdio`
|
||||
- **Protocol**: LSP 3.17
|
||||
- **Role in graphd**: 默认必须支持的生产就绪语言服务器
|
||||
- **Note**: TypeScript LSP 支持层级符号，但 PHP Intelephense 不支持——LSP/Index Engineer 强制要求"永远验证假设"，必须检查服务器能力响应而非假设支持
|
||||
|
||||
## Connections
|
||||
- [[Intelephense]] ← is_coordinated_by ← [[LSPOrchestrator]]
|
||||
- [[Intelephense]] ← provides_semantics_to ← [[SemanticCodeGraph]]
|
||||
- [[Intelephense]] ← part_of ← [[GraphDaemon]]
|
||||
|
||||
29
wiki/entities/Jan.md
Normal file
29
wiki/entities/Jan.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Jan"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "local-ai"
|
||||
- "open-source"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
Jan（26k stars）是一款开源本地 AI 应用，支持 Remote Model 配置接入远程 API。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：26k
|
||||
- **License**：AGPL
|
||||
- **特点**：完全本地运行，数据不离开设备
|
||||
- **集成方式**：Remote Model 配置
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过 Remote Model 配置：
|
||||
- **API URL**：`http://<host>:8642/v1/chat/completions`
|
||||
- **认证**：Bearer Token（`API_SERVER_KEY`）
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
37
wiki/entities/JimLiu.md
Normal file
37
wiki/entities/JimLiu.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "JimLiu"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [baoyu-skills]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
JimLiu（宝玉）是一位活跃在 GitHub 上的开发者，以创建高质量 AI 工具和工作流自动化技能闻名。主要贡献集中在 Claude Code Skills 生态，旗下 [[baoyu-skills]] 仓库提供从内容创作到多平台发布的一整套 AI 辅助工作流。
|
||||
|
||||
## Aliases
|
||||
- 宝玉
|
||||
|
||||
## Key Contributions
|
||||
|
||||
### [[baoyu-skills]]
|
||||
|
||||
Claude Code Skills 技能集，GitHub 地址：github.com/JimLiu/baoyu-skills。核心模块：
|
||||
|
||||
- **内容生成技能**：baoyu-xhs-images（小红书卡片）、baoyu-infographic（信息图）、baoyu-diagram（SVG 图表）、baoyu-cover-image（封面图）、baoyu-slide-deck（幻灯片）、baoyu-comic（知识漫画）、baoyu-article-illustrator（文章插图）
|
||||
- **发布技能**：baoyu-post-to-x（X 推文/文章）、baoyu-post-to-wechat（微信公众号）、baoyu-post-to-weibo（微博头条文章）
|
||||
- **AI 生成技能**：baoyu-imagine（多 provider 文生图）、baoyu-danger-gemini-web（Gemini 交互）
|
||||
- **工具技能**：baoyu-youtube-transcript、baoyu-url-to-markdown、baoyu-danger-x-to-markdown、baoyu-compress-image、baoyu-format-markdown、baoyu-markdown-to-html、baoyu-translate
|
||||
|
||||
### 其他相关仓库
|
||||
|
||||
- **[[obsidian-必装-skills]]**（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]] 提及）：Obsidian 生态 AI Skills 推荐，包含 kepano 官方 defuddle、obsidian-cli、obsidian-bases，以及 t
|
||||
|
||||
utor-skills、scholar-skill 等学习类技能。
|
||||
|
||||
## Connections
|
||||
- [[baoyu-skills]] ← authored_by ← [[JimLiu]]
|
||||
- [[ClawHub]] ← distribution_platform ← [[baoyu-skills]]
|
||||
- [[OpenClaw]] ← ecosystem ← [[baoyu-skills]]
|
||||
- [[Claude-Code]] ← platform ← [[baoyu-skills]]
|
||||
38
wiki/entities/John-Allspaw.md
Normal file
38
wiki/entities/John-Allspaw.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "John Allspaw"
|
||||
type: entity
|
||||
tags: [sre, reliability, engineering, operations]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# John Allspaw
|
||||
|
||||
John Allspaw 是 SRE 领域的先驱人物，Adaptive Capacity Labs 联合创始人，前 Etsy CTO。
|
||||
|
||||
## Aliases
|
||||
- John Allspaw
|
||||
- John Allspaw and Dr. Richard I. Cook
|
||||
|
||||
## Overview
|
||||
John Allspaw 在容量规划、事件管理和组织韧性领域有着丰富的一线经验。他的研究和实践深刻影响了现代 SRE 文化的形成。
|
||||
|
||||
## Career Highlights
|
||||
- **Etsy**：前 CTO，主导了 Etsy 从传统运维到 SRE 文化的转型
|
||||
- **Adaptive Capacity Labs**：与 [[Richard-Cook]] 共同创办，专注系统可靠性和组织韧性研究
|
||||
|
||||
## Key Contributions
|
||||
- **Organizational Second Hit Syndrome**：与 Richard Cook 共同提出
|
||||
- **Capacity Planning**：出版了《The Art of Capacity Planning》和《Web Operations》
|
||||
- **Resilience Engineering**：在多个会议上分享了大量关于事件响应和组织学习的研究
|
||||
|
||||
## Notable Works
|
||||
- 《Working Together》— 与 Richard Cook 合著
|
||||
- 《The Art of Capacity Planning》
|
||||
- 《Web Operations》
|
||||
|
||||
## Affiliations
|
||||
- [[Adaptive-Capacity-Labs]] — 联合创始人
|
||||
- Formerly: Etsy (CTO)
|
||||
|
||||
## Source
|
||||
- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
|
||||
26
wiki/entities/JosephCampbell.md
Normal file
26
wiki/entities/JosephCampbell.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Joseph Campbell"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- J. Campbell
|
||||
- Joseph Campbell
|
||||
|
||||
## Overview
|
||||
Joseph Campbell (1904–1987) 是美国神话学家、作家，以"英雄之旅"（Hero's Journey / Monomyth）理论闻名于世。其著作《千面英雄》（The Hero with a Thousand Faces, 1949）系统归纳了跨文化神话叙事中的共同结构模式。
|
||||
|
||||
## Key Contributions
|
||||
- **Monomyth / Hero's Journey**：英雄经历"离开→历险→归来"三阶段，包含启程（Call to Adventure）、启蒙（Initiation）、回归（Return）三大板块
|
||||
- **Follow Your Bliss**：鼓励个体追寻内在热情与使命的著名格言
|
||||
- **跨文化神话比较**：整合印度、希腊、北欧、日本等多文化神话体系
|
||||
|
||||
## In The Agency Context
|
||||
[[Academic Narratologist]] 将 Hero's Journey 作为核心叙事框架之一，用于分析英雄叙事的角色弧线和结构节点。Christopher Vogler 的 Writer's Journey 正是基于 Campbell 理论发展而来。
|
||||
|
||||
## References
|
||||
- The Hero with a Thousand Faces (1949)
|
||||
- The Power of Myth (1988, with Bill Moyers)
|
||||
45
wiki/entities/K6.md
Normal file
45
wiki/entities/K6.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "k6"
|
||||
type: entity
|
||||
tags: ["testing", "performance", "load-testing", "open-source"]
|
||||
last_updated: 2026-05-09
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- k6
|
||||
- k6.io
|
||||
- Grafana k6
|
||||
|
||||
## Summary
|
||||
k6 是 Grafana 实验室开源的开发者友好型负载测试工具，用 JavaScript/Go 原生编写，专为规模化性能测试和可扩展性验证设计。API Tester Agent 和 Performance Benchmarker Agent 的核心测试工具之一。
|
||||
|
||||
## Key Facts
|
||||
- **类型**：开源负载测试工具
|
||||
- **开发商**：Grafana Labs
|
||||
- **编程语言**：Go（核心引擎）+ JavaScript（测试脚本）
|
||||
- **许可**：Apache License 2.0
|
||||
- **官网**：https://k6.io
|
||||
|
||||
## Core Capabilities
|
||||
- 编写简洁的 JavaScript 测试脚本定义负载场景
|
||||
- 支持 HTTP/WebSocket/gRPC/CSV 数据驱动测试
|
||||
- 内置 Checks（断言）和 Thresholds（阈值）定义
|
||||
- 与 Grafana、Tighthouse、Datadog 等监控平台无缝集成
|
||||
- 支持云端分布式执行（k6 Cloud）和本地单节点执行
|
||||
- 支持 HAR 文件导入，自动从浏览器录制生成测试脚本
|
||||
|
||||
## Role in The Agency
|
||||
- [[testing-api-tester]] 使用 k6 执行 API 负载测试，验证 10x 正常流量容量和 SLA 合规性
|
||||
- [[testing-performance-benchmarker]] 使用 k6 编写综合性能测试套件，结合统计置信区间分析
|
||||
- [[Scalability]] 概念验证的推荐工具
|
||||
|
||||
## Related Entities
|
||||
- [[Playwright]]：端到端功能测试；k6 专注负载与性能测试
|
||||
- [[REST Assured]]：Java 生态 API 测试；k6 跨语言通用
|
||||
- [[testing-performance-benchmarker]] ← uses ← [[K6]]
|
||||
- [[testing-api-tester]] ← uses ← [[K6]]
|
||||
|
||||
## Related Concepts
|
||||
- [[Performance Testing]]
|
||||
- [[Load Testing]]
|
||||
- [[Scalability]]
|
||||
@@ -1,45 +1,45 @@
|
||||
---
|
||||
title: "KakaoTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **类型**：产品 / 通讯平台
|
||||
- **原文**：카카오톡（KakaoTalk）
|
||||
- **中文**：韩国版微信 / 连我
|
||||
- **运营公司**：Kakao Corp（카카오），韩国最大互联网平台之一
|
||||
- **用户规模**：截至 2024 年月活跃用户超 5000 万（韩国总人口约 5100 万）
|
||||
|
||||
## 在韩国商务中的地位
|
||||
KakaoTalk 是韩国商务沟通的**核心渠道**，相当于中国商务场景中的微信。韩国专业人士将 KakaoTalk 视为半正式的商务工具，其使用方式直接影响商业关系的建立和维护。
|
||||
|
||||
## 商务使用规范
|
||||
|
||||
### 关系阶段与消息模板
|
||||
1. **初次接触（正式）**：必须通过介绍人引荐，消息使用完整正式语气，包含自我介绍和咖啡邀约
|
||||
2. **已建立关系（半正式）**：寒暄+信息+请求，结尾用礼貌语
|
||||
3. **信任建立后**：可直接消息，允许表情符号，但不过量
|
||||
|
||||
### 关键规则
|
||||
- **群聊必须韩语**：即使不完美也显示尊重；英语在韩国群聊中等于"我期待你迁就我"
|
||||
- **回复时间**：紧急事务同一工作日内；非紧急次日回复可接受
|
||||
- **已读回执可见**：超过 24 小时只读不回会被注意到
|
||||
- **语音消息**：仅在关系已支持非正式沟通时使用
|
||||
- **表情/贴纸**：信任建立后谨慎使用；初次接触绝对禁用
|
||||
- **商务时间**：9 AM - 7 PM KST；该时间外发送可接受但不要期待即时回复
|
||||
|
||||
### 禁忌
|
||||
- 不要在 KakaoTalk 上直接谈报价（价格谈判应在线下或当面）
|
||||
- 不要发送长篇大论的自我介绍（韩国人不会在手机上阅读长文本）
|
||||
- 不要用 KakaoTalk 发送正式合同文件（用邮件）
|
||||
|
||||
## Aliases
|
||||
- 카카오톡
|
||||
- Kakao
|
||||
- 韩国版微信
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — KakaoTalk Business Communication Guide 完整规范
|
||||
---
|
||||
title: "KakaoTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [specialized-korean-business-navigator]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **类型**：产品 / 通讯平台
|
||||
- **原文**：카카오톡（KakaoTalk）
|
||||
- **中文**：韩国版微信 / 连我
|
||||
- **运营公司**：Kakao Corp（카카오），韩国最大互联网平台之一
|
||||
- **用户规模**：截至 2024 年月活跃用户超 5000 万（韩国总人口约 5100 万）
|
||||
|
||||
## 在韩国商务中的地位
|
||||
KakaoTalk 是韩国商务沟通的**核心渠道**，相当于中国商务场景中的微信。韩国专业人士将 KakaoTalk 视为半正式的商务工具，其使用方式直接影响商业关系的建立和维护。
|
||||
|
||||
## 商务使用规范
|
||||
|
||||
### 关系阶段与消息模板
|
||||
1. **初次接触（正式）**：必须通过介绍人引荐，消息使用完整正式语气，包含自我介绍和咖啡邀约
|
||||
2. **已建立关系（半正式）**：寒暄+信息+请求，结尾用礼貌语
|
||||
3. **信任建立后**：可直接消息，允许表情符号，但不过量
|
||||
|
||||
### 关键规则
|
||||
- **群聊必须韩语**：即使不完美也显示尊重；英语在韩国群聊中等于"我期待你迁就我"
|
||||
- **回复时间**：紧急事务同一工作日内；非紧急次日回复可接受
|
||||
- **已读回执可见**：超过 24 小时只读不回会被注意到
|
||||
- **语音消息**：仅在关系已支持非正式沟通时使用
|
||||
- **表情/贴纸**：信任建立后谨慎使用；初次接触绝对禁用
|
||||
- **商务时间**：9 AM - 7 PM KST；该时间外发送可接受但不要期待即时回复
|
||||
|
||||
### 禁忌
|
||||
- 不要在 KakaoTalk 上直接谈报价（价格谈判应在线下或当面）
|
||||
- 不要发送长篇大论的自我介绍（韩国人不会在手机上阅读长文本）
|
||||
- 不要用 KakaoTalk 发送正式合同文件（用邮件）
|
||||
|
||||
## Aliases
|
||||
- 카카오톡
|
||||
- Kakao
|
||||
- 韩国版微信
|
||||
|
||||
## 来源
|
||||
- [[specialized-korean-business-navigator]] — KakaoTalk Business Communication Guide 完整规范
|
||||
|
||||
23
wiki/entities/Karpathy.md
Normal file
23
wiki/entities/Karpathy.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Karpathy"
|
||||
type: entity
|
||||
tags: [AI, researcher]
|
||||
sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Andrej Karpathy
|
||||
- @karpathy
|
||||
|
||||
## Profile
|
||||
OpenAI 联合创始人、前特斯拉 Autopilot 视觉团队负责人，斯坦福大学深度学习课程（CS231n）讲师，知名 AI 研究者与技术布道者。
|
||||
|
||||
## Key Contributions
|
||||
- 在 GitHub Gist（[karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)）发布了 **LLM Wiki** 方法论
|
||||
- 提出用 LLM 增量构建和维护持久化 Wiki，替代传统 RAG 的"每次从零开始"模式
|
||||
- 核心观点：**"AI 不会厌倦，不会忘记更新交叉引用，一次操作可以碰十五个文件，维护成本趋近于零"**
|
||||
|
||||
## Role in This Wiki
|
||||
- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]] — 来源发起者
|
||||
- [[LLM Wiki]] — 理论提出者
|
||||
@@ -1,47 +1,34 @@
|
||||
---
|
||||
title: "Kuaishou"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-21
|
||||
tags: [中国社交媒体, 短视频平台, 直播电商]
|
||||
sources: [marketing-kuaishou-strategist, marketing-livestream-commerce-coach]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
# Kuaishou（快手）
|
||||
## 基本信息
|
||||
- **全称**：快手科技（Kuaishou Technology）
|
||||
- **定位**：中国第二大短视频与直播电商平台（仅次于抖音）
|
||||
- **核心用户**：下沉市场用户，三四五线城市，30-50岁群体为主
|
||||
|
||||
## Aliases
|
||||
- Kuaishou
|
||||
- 快手
|
||||
- Kwai
|
||||
|
||||
## Definition
|
||||
快手是中国第二大短视频平台和领先的直播电商平台，以"老铁经济"（兄弟文化）为核心差异化定位，主要覆盖中国低线城市（下沉市场）的30-50岁用户群体。
|
||||
|
||||
## Key Characteristics
|
||||
- **均衡分发算法**：给予每个创作者基础流量曝光，触发扩大分发由社区互动（评论、点赞、分享）决定，而非纯算法推荐
|
||||
- **老铁文化**：创作者与粉丝之间基于真实信任的兄弟关系，强调长期忠诚而非一次性流量
|
||||
- **直播电商核心平台**：中国下沉市场直播带货的主要阵地，信任驱动型重复购买
|
||||
- **内容审美**：真实质朴 > 精致制作，用户能即时识别并拒绝不真实内容
|
||||
|
||||
## Relationship to Douyin
|
||||
快手与抖音是中国短视频双巨头，两者存在根本差异：
|
||||
## 核心特征
|
||||
- **均衡分发算法**：给予每个创作者基础曝光量，坚持日更比单次爆款更有价值
|
||||
- **老铁文化**：兄弟情谊式的粉丝关系，信任驱动重复购买和主动品牌辩护
|
||||
- **内容风格**：真实场景 > 精致制作，真实性是一切的基础
|
||||
- **电商模式**：信任-based repeat purchases（关系驱动）vs 抖音的 impulse discovery purchases（冲动发现）
|
||||
|
||||
## 与抖音的差异
|
||||
| 维度 | 快手 | 抖音 |
|
||||
|------|------|------|
|
||||
| 核心算法 | 均衡分发 | 中心化推荐 |
|
||||
| 主要受众 | 下沉市场，30-50岁 | 一二线城市，18-35岁 |
|
||||
| 内容审美 | 真实质朴 | 精致潮流 |
|
||||
| 创作者-粉丝关系 | 深度老铁忠诚 | 算法依赖型浅关系 |
|
||||
| 商业模式 | 信任驱动重复购买 | 发现型冲动购买 |
|
||||
| 增长模式 | 慢积累，长期忠诚 | 快爆发，难留存 |
|
||||
| 算法 | 均衡分发 | 中心化推荐 |
|
||||
| 受众 | 下沉市场，30-50岁 | 一二线城市，18-35岁 |
|
||||
| 内容审美 | 真实、质朴 | 精致、时尚 |
|
||||
| 粉丝关系 | 深度老铁忠诚 | 浅层、算法依赖 |
|
||||
| 增长模式 | 慢建立，长期忠诚 | 快爆发，难以留存 |
|
||||
|
||||
**核心原则**：绝不将抖音内容直接复用到快手，两者面向不同用户心理和平台生态。
|
||||
## 相关来源
|
||||
- [[marketing-kuaishou-strategist]]
|
||||
|
||||
## Related Agents
|
||||
- [[Marketing-Kuaishou-Strategist]]：快手平台专项策略 Agent
|
||||
- [[Marketing-Douyin-Strategist]]：抖音平台专项策略 Agent（平台兄弟）
|
||||
|
||||
## Related Concepts
|
||||
- [[老铁经济]]：快手特有的兄弟文化商业模式
|
||||
- [[均衡分发算法]]：快手的核心推荐机制
|
||||
- [[下沉市场]]：快手的主要目标受众
|
||||
- [[直播带货]]：快手的核心商业化路径
|
||||
## Aliases
|
||||
- 快手
|
||||
- Kuaishou
|
||||
|
||||
@@ -1,114 +1,46 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
type: entity
|
||||
tags:
|
||||
- cloud
|
||||
- container
|
||||
- orchestration
|
||||
- devops
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-25
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
|
||||
## Definition
|
||||
|
||||
Kubernetes (K8s) 是 Google 开源的**容器编排平台**，用于自动化容器化应用的部署、扩缩容和管理。是云原生 (Cloud-Native) 架构的核心基础设施，也是 Agentic AI 自主修复 (Self-Healing) 的主要目标环境。
|
||||
|
||||
## Aliases
|
||||
|
||||
- K8s
|
||||
- Kubernetes
|
||||
- Container Orchestration Platform
|
||||
|
||||
## Major Cloud Implementations
|
||||
|
||||
| Provider | Service | Description |
|
||||
|----------|---------|-------------|
|
||||
| AWS | EKS (Elastic Kubernetes Service) | 托管 Kubernetes on AWS |
|
||||
| GCP | GKE (Google Kubernetes Engine) | 托管 Kubernetes on GCP |
|
||||
| Azure | AKS (Azure Kubernetes Service) | 托管 Kubernetes on Azure |
|
||||
|
||||
## Kubernetes Self-Healing Capabilities
|
||||
|
||||
Kubernetes 原生提供基础 Self-Healing 能力：
|
||||
|
||||
```yaml
|
||||
# Kubernetes Self-Healing 原生机制
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
spec:
|
||||
replicas: 3
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
template:
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 30
|
||||
# 内置机制:
|
||||
# - 自动重启失败的容器
|
||||
# - 替换不健康的 Pod
|
||||
# - 滚动更新确保服务可用
|
||||
```
|
||||
|
||||
Agentic AI 在原生能力基础上提供**更高级的自我修复**：
|
||||
|
||||
| 能力 | Kubernetes 原生 | Agentic AI Enhanced |
|
||||
|------|---------------|-------------------|
|
||||
| Pod 重启 | ✅ 自动重启崩溃容器 | ✅ 智能分析根因 + 预防性重启 |
|
||||
| 扩缩容 | ✅ HPA 基于指标 | ✅ 预测性扩缩容 |
|
||||
| 节点恢复 | ✅ 节点故障迁移 | ✅ 主动健康检查 + 预防性迁移 |
|
||||
| 配置修复 | ❌ 需人工介入 | ✅ AI 自动修正 ConfigMap/Secret |
|
||||
|
||||
## Agentic AI Monitoring Targets
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Agentic AI for Kubernetes │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ 监控层 │
|
||||
│ ├── Pod Metrics (CPU/Memory/Network) │
|
||||
│ ├── Workload Health (Deployment/ReplicaSet) │
|
||||
│ ├── Node Status (Ready/Condition) │
|
||||
│ └── Cluster Components (etcd, API Server) │
|
||||
│ │
|
||||
│ 决策层 │
|
||||
│ ├── Anomaly Detection (AI) │
|
||||
│ ├── Root Cause Analysis (AI) │
|
||||
│ └── Action Planning (AI) │
|
||||
│ │
|
||||
│ 执行层 │
|
||||
│ ├── kubectl API (restart/migrate/scale) │
|
||||
│ ├── HPA Override (AI-driven scaling) │
|
||||
│ └── Config Updates (AI-driven fixes) │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
> An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod:
|
||||
> - Pod `payment-service-v2-abc123` CPU usage: 95%
|
||||
> - AI correlates with recent deployment timestamp
|
||||
> - AI identifies: Memory leak in new version
|
||||
> - AI Actions:
|
||||
> 1. Scale deployment to 3 replicas (distribute load)
|
||||
> 2. Create rollback ticket
|
||||
> 3. Notify team via Slack
|
||||
> 4. Auto-rollback after approval
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Self-Healing Systems]] — Kubernetes 是 Self-Healing 的主要载体
|
||||
- [[Cloud-Native]] — Kubernetes 是 Cloud-Native 的核心
|
||||
- [[Deployment Automation]] — Kubernetes 部署的自动化
|
||||
- [[Container Lifecycle Hardening]] — 容器安全加固
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Agentic AI]] — Kubernetes 是 Agentic AI 的管理对象
|
||||
- EKS, GKE, AKS — 具体云服务商实现
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]]
|
||||
---
|
||||
title: "Kubernetes"
|
||||
type: entity
|
||||
tags: [Container, Orchestration, DevOps]
|
||||
sources: [engineering-devops-automator]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
|
||||
## 基本信息
|
||||
- **类型**：容器编排平台
|
||||
- **开发商**：CNCF（云原生计算基金会）
|
||||
- **官网**：https://kubernetes.io
|
||||
|
||||
## 定义
|
||||
Kubernetes（K8s）是一个开源容器编排平台，用于自动化容器化应用的部署、扩缩容和管理，是云原生架构的核心基础设施。
|
||||
|
||||
## 核心概念
|
||||
- **Pod**：最小调度单元，可包含一个或多个容器
|
||||
- **Deployment**：声明式应用管理，支持滚动更新和回滚
|
||||
- **Service**：为 Pod 提供稳定的网络访问入口
|
||||
- **Ingress**：HTTP/HTTPS 负载均衡和路由
|
||||
- **ConfigMap/Secret**：应用配置和敏感信息管理
|
||||
- **Horizontal Pod Autoscaler (HPA)**：基于指标的自动扩缩容
|
||||
|
||||
## 在 DevOps Automator 中的角色
|
||||
- 容器化应用部署的核心平台
|
||||
- 支持蓝绿部署、金丝雀发布、滚动更新策略
|
||||
- 通过 kubectl 命令行实现零停机部署
|
||||
|
||||
## 相关概念
|
||||
- [[Zero-Downtime Deployment]]
|
||||
- [[Infrastructure as Code]]
|
||||
- [[Observability]]
|
||||
|
||||
## 相关工具
|
||||
- Amazon EKS（AWS 托管 Kubernetes）
|
||||
- Google GKE（Google 托管 Kubernetes）
|
||||
- Karpenter（Kubernetes 节点自动配置）
|
||||
- Istio/Linkerd（Service Mesh）
|
||||
|
||||
## Aliases
|
||||
- K8s
|
||||
- Kubernetes
|
||||
- K8
|
||||
|
||||
28
wiki/entities/LibreChat.md
Normal file
28
wiki/entities/LibreChat.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "LibreChat"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "open-source"
|
||||
- "multi-backend"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
LibreChat（34k stars）是一款开源多后端聊天平台，支持同时连接多个 AI 后端。可通过 `librechat.yaml` 配置接入 Hermes Agent。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：34k
|
||||
- **License**：MIT
|
||||
- **集成方式**：`librechat.yaml` 配置文件
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过 `librechat.yaml` 配置 OpenAI 兼容 Provider：
|
||||
- **API URL**：`http://<host>:8642/v1/chat/completions`
|
||||
- **API Key**：`API_SERVER_KEY` 配置的 Bearer Token
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
28
wiki/entities/LobeChat.md
Normal file
28
wiki/entities/LobeChat.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "LobeChat"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "open-source"
|
||||
- "frontend"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
LobeChat（73k stars）是一款开源 AI 聊天前端，支持自定义 Provider，可通过 OpenAI 兼容 API 接入 Hermes Agent。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：73k
|
||||
- **License**：Apache 2.0
|
||||
- **集成方式**：自定义 Provider 配置，指定 API URL 和 Key
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过 Hermes Agent 的 OpenAI 兼容 API Server 接入，需要配置：
|
||||
- **API URL**：`http://<host>:8642/v1/chat/completions`（或 `/v1/responses`）
|
||||
- **API Key**：`API_SERVER_KEY` 配置的 Bearer Token
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
30
wiki/entities/LuxuryDeveloper.md
Normal file
30
wiki/entities/LuxuryDeveloper.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "LuxuryDeveloper"
|
||||
type: entity
|
||||
tags: [developer, brand-development, the-agency]
|
||||
sources: [design-whimsy-injector]
|
||||
last_updated: 2026-05-15
|
||||
---
|
||||
|
||||
# LuxuryDeveloper
|
||||
|
||||
## Definition
|
||||
|
||||
豪华品牌开发者目标角色（Target User of Brand Personality Agents），[[The-Agency]] 生态中的核心受益者。需要为产品注入品牌个性和差异化体验的开发者，通过调用 [[ArchitectUX]] 和 [[Whimsy-Injector]] 等 Design 部门 Agent 实现。
|
||||
|
||||
## Role
|
||||
|
||||
LuxuryDeveloper 是品牌开发者的抽象角色定义，代表需要以下能力的开发者：
|
||||
- 为产品建立独特品牌个性
|
||||
- 通过微交互提升用户体验
|
||||
- 通过游戏化和彩蛋增加用户参与度
|
||||
- 确保趣味元素不影响性能和无障碍访问
|
||||
|
||||
## Relationship to Other Agents
|
||||
|
||||
- [[ArchitectUX]] ← provides technical foundation ← LuxuryDeveloper
|
||||
- [[Whimsy-Injector]] ← injects brand personality ← LuxuryDeveloper
|
||||
|
||||
## Aliases
|
||||
- Luxury Developer
|
||||
- Brand Developer
|
||||
24
wiki/entities/Lychee-Technology.md
Normal file
24
wiki/entities/Lychee-Technology.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Lychee Technology Inc."
|
||||
type: entity
|
||||
tags:
|
||||
- "company"
|
||||
- "engineering-blog"
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Overview
|
||||
Lychee Technology Inc. — 发布 engineering blog 的公司，专注于 production-grade AI 系统设计实践。
|
||||
|
||||
## Details
|
||||
- **Type**: Company
|
||||
- **Blog**: https://blog.ltbase.dev
|
||||
- **Focus**: Agentic AI 系统工程、LLM 可靠执行架构、Harness Engineering 实践
|
||||
|
||||
## Key Publications
|
||||
- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]：Harness Engineering 核心文章
|
||||
|
||||
## Aliases
|
||||
- Lychee Technology
|
||||
- ltbase.dev
|
||||
35
wiki/entities/MCCLevelStrategy.md
Normal file
35
wiki/entities/MCCLevelStrategy.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "MCC Level Strategy"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- google
|
||||
- enterprise
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
MCC（My Client Center）是 Google Ads 的代理/多账户管理结构，允许通过单一登录管理多个 Google Ads 子账户（最多 1000 个）。MCC Level Strategy 是在 MCC 框架下的顶层账户管理策略，涵盖跨账户预算分配、竞价策略协调、合规管理和统一报告。
|
||||
|
||||
## Core Capabilities Referenced
|
||||
- **Cross-Account Budget Pacing**：在多个子账户之间动态调整预算分配
|
||||
- **Portfolio Bid Strategies**：跨账户组合竞价策略，在账户层面统一优化 ROAS/CPA
|
||||
- **Unified Reporting**：MCC 级汇总报告，支持跨账户效果对比和基准分析
|
||||
- **Label System for Scalability**：通过标签系统对数百个账户进行分类管理
|
||||
- **Account Health Monitoring**：MCC 级账户健康评分监控，识别表现异常的账户
|
||||
- **Google Ads API at MCC Scale**：通过 API 批量操作多个账户
|
||||
|
||||
## Enterprise Use Cases
|
||||
- **Agency Management**：广告代理公司管理多个客户账户
|
||||
- **Multi-Brand Organization**：同一品牌下多个子品牌/产品线的独立账户管理
|
||||
- **Franchise/Dealer Network**：连锁品牌为各门店/经销商建立独立账户
|
||||
- **Geographic Expansion**：按地区/国家建立独立账户，统一协调
|
||||
|
||||
## Connections
|
||||
- [[GoogleAds]]：MCC 是 Google Ads 的多账户管理结构
|
||||
- [[GoogleAdsAPI]]：API 是 MCC 级策略程序化执行的核心工具
|
||||
- [[BudgetPacing]]：MCC 级预算分配和 pacing 是核心议题
|
||||
- [[AutomatedBiddingStrategy]]：Portfolio Bid Strategies 是自动化竞价的 MCC 级实现
|
||||
79
wiki/entities/Malt.md
Normal file
79
wiki/entities/Malt.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: "Malt"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [specialized-french-consulting-market]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# Malt
|
||||
|
||||
## Aliases
|
||||
- Malt
|
||||
- Malt Platform
|
||||
- Malt Europe
|
||||
|
||||
## Definition
|
||||
|
||||
Malt 是欧洲最大的自由职业者平台（总部位于法国），专门服务于 IT 咨询和数字领域独立专业人士与企业的匹配。作为进入法国 ESN/SI 生态系统的核心平台之一，Malt 为自由顾问提供项目发现、合同签订和款项收取的一站式服务。
|
||||
|
||||
## Core Business Model
|
||||
|
||||
| 维度 | 说明 |
|
||||
|------|------|
|
||||
| **佣金结构** | 10% 客户侧佣金（Client-side fee），顾问端免费 |
|
||||
| **适用市场** | 法国为主，覆盖欧洲（英国、德国、西班牙） |
|
||||
| **主要用户** | IT 顾问、开发者、设计师、项目经理 |
|
||||
| **核心价值** | 作品集展示、项目匹配、合同管理、支付保障 |
|
||||
|
||||
## Rate Positioning on Malt
|
||||
|
||||
Malt 平台的费率策略具有高度透明度——所有顾问的报价对潜在客户可见，这带来双重影响：
|
||||
|
||||
- **机会**：帮助顾问建立可验证的市场定价记录
|
||||
- **风险**：一旦设定费率，即成为市场锚点，调整需要战略性考量
|
||||
|
||||
> "Platform rates are public. What you charge on Malt is visible. Your Malt rate becomes your market rate. Price accordingly from day one." — French Consulting Market Navigator
|
||||
|
||||
## Rate Range
|
||||
|
||||
典型 TJM 区间：
|
||||
|
||||
| 经验级别 | TJM 区间 |
|
||||
|---------|---------|
|
||||
| Junior（< 3年） | 450-550 EUR/天 |
|
||||
| Mid（3-7年） | 550-700 EUR/天 |
|
||||
| Senior（7-10年） | 650-850 EUR/天 |
|
||||
| Expert（> 10年） | 750-1,000+ EUR/天 |
|
||||
|
||||
注：Salesforce、Data Cloud、Agentforce 等专项领域可在上述区间上浮 15-25%。
|
||||
|
||||
## Platform Comparison
|
||||
|
||||
| 平台 | 佣金 | TJM 典型区间 | 特点 |
|
||||
|------|------|------------|------|
|
||||
| **Malt** | 10%（客户侧） | 550-700 EUR | 作品集可见，费率公开 |
|
||||
| collective.work | 3-5% | 650-800 EUR | portage 集成，高价值任务 |
|
||||
| Comet | 15% | 600-750 EUR | 算法匹配，控制权低 |
|
||||
| Crème de la Crème | 15-20% | 700-900 EUR | 精品定位，审核严格 |
|
||||
| Free-Work | 免费/付费 | 500-900 EUR | 体量大，噪音多 |
|
||||
|
||||
## Strategic Considerations
|
||||
|
||||
### 何时选择 Malt
|
||||
- 处于 Freelance 早期阶段，需要建立作品集和客户评价
|
||||
- 希望进入法国市场但缺乏直接客户关系网络
|
||||
- 需要一个可验证的市场费率记录（对后续谈判有价值）
|
||||
|
||||
### 定价策略
|
||||
- 首次定价需慎重：一旦公开即成为市场锚点
|
||||
- 高于市场平均的定价需要强有力差异化叙述（如 Agentforce + Data Cloud 双认证）
|
||||
- 初期可战略性报低价换取前几个评价，后续逐步提价
|
||||
|
||||
### 潜在风险
|
||||
- 费率透明意味着竞争对手可直接看到你的定价
|
||||
- 低价锚定会永久影响谈判起点（建议不低于 550 EUR/天 for Salesforce Architect）
|
||||
- 平台依赖：单一平台依赖度高，建议与 collective.work 等配合使用
|
||||
|
||||
## Related Sources
|
||||
- [[specialized-french-consulting-market]]
|
||||
26
wiki/entities/Marcel-Mauss.md
Normal file
26
wiki/entities/Marcel-Mauss.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Marcel Mauss"
|
||||
type: entity
|
||||
tags: ["anthropologist", "gift-economy", "french-sociology", "economic-anthropology", "primitive-forms"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
法国社会学家和人类学家，涂尔干（Durkheim）的外甥。《礼物》（The Gift）作者，系统阐述了礼物经济中互惠义务的机制，是经济人类学的奠基之作。
|
||||
|
||||
## Aliases
|
||||
- Mauss
|
||||
- M. Mauss
|
||||
|
||||
## Key Contributions
|
||||
- **礼物交换理论**：在原始/古代社会中，交换不仅是经济行为，更是社会义务——"礼物之灵"（hau）使接受者必须回报
|
||||
- **礼物义务（Potlatch）**：北太平洋西北岸部落通过毁坏财富展示来确立社会地位的大型仪式交换
|
||||
- **互惠原则（Reciprocity）**：社会凝聚力的基础机制之一——给予、接受、回报的三段循环
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 将 Mauss 的礼物经济作为 Advanced Capabilities 之一，用于设计基于互惠和社会义务的交换系统。
|
||||
|
||||
## Connections
|
||||
- [[Gift-Economy]] ← authored_by ← [[Marcel-Mauss]]
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Marcel-Mauss]]
|
||||
- [[Polanyi]] ← extends ← [[Marcel-Mauss]]
|
||||
27
wiki/entities/Marty-Cagan.md
Normal file
27
wiki/entities/Marty-Cagan.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Marty Cagan"
|
||||
type: entity
|
||||
tags: ["product-management", "person"]
|
||||
sources: ["Hermes-Agent-配置笔记"]
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
## Overview
|
||||
Marty Cagan 是国际知名产品管理专家，《INSPIRED：How to Create Tech Products Customers Love》作者。该名字被推荐作为 Hermes Agent 多角色配置中"产品经理"角色的命名来源（nova/marty）。
|
||||
|
||||
## Aliases
|
||||
- Marty Cagan
|
||||
|
||||
## Key Contributions
|
||||
- 《INSPIRED: How to Create Tech Products Customers Love》：产品管理领域权威著作
|
||||
- 创立 SVPG（Silicon Valley Product Group），专注于产品领导力培训
|
||||
- 提出"Product Discovery"理念，强调技术团队在产品成功中的核心作用
|
||||
|
||||
## In Hermes Agent Context
|
||||
在 [[Hermes-Agent-配置笔记]] 中，Marty Cagan 被推荐作为 Hermes Agent 多角色 Vibe Coding 场景中"产品经理"角色的命名来源：
|
||||
- 推荐名字：`marty`
|
||||
- 角色定位：产品经理
|
||||
- 来源依据：Marty Cagan 的《Inspired》是产品管理领域的经典
|
||||
|
||||
## Connections
|
||||
- [[Hermes-Agent-配置笔记]] → uses name → [[Marty-Cagan]]
|
||||
25
wiki/entities/Mary-Douglas.md
Normal file
25
wiki/entities/Mary-Douglas.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Mary Douglas"
|
||||
type: entity
|
||||
tags: ["anthropologist", "symbolic-anthropology", "british", "religion", "purity"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
英国人类学家，符号人类学和宗教人类学的重要人物。《洁净与危险》（Purity and Danger）分析了禁忌（taboo）体系的社会功能，提出"污秽即失序"（dirt is matter out of place）的经典论断。
|
||||
|
||||
## Aliases
|
||||
- Douglas
|
||||
- M. Douglas
|
||||
|
||||
## Key Contributions
|
||||
- **洁净与危险（Purity and Danger）**：禁忌不是迷信，而是社会边界维护机制——"脏/危险"是对社会分类秩序的威胁的象征性表达
|
||||
- **分类系统（Grid/Group Analysis）**：通过二维框架（社会约束力 × 分类清晰度）分析不同文化如何组织社会和世界观
|
||||
- **制度性宗教分析**：关注仪式中的符号如何表达和强化社会结构
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 在 Belief System 设计中引用 Douglas 的分析框架，用于理解神圣/世俗边界（sacred/profane boundary）如何服务于社会控制。
|
||||
|
||||
## Connections
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Mary-Douglas]]
|
||||
- [[Structuralism]] ← influenced_by ← [[Mary-Douglas]]
|
||||
21
wiki/entities/McKinseyAndCompany.md
Normal file
21
wiki/entities/McKinseyAndCompany.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "McKinsey & Company"
|
||||
type: entity
|
||||
tags: ["consulting", "strategy", "framework-originator"]
|
||||
sources: ["support-executive-summary-generator"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
McKinsey & Company 是全球顶级战略咨询公司，成立于 1926 年，总部位于纽约。以其为财富 500 强企业提供的战略规划、组织变革和运营优化服务闻名。
|
||||
|
||||
## Aliases
|
||||
- McKinsey
|
||||
- McKinsey & Company
|
||||
|
||||
## Key Contributions
|
||||
- **SCQA Framework**：Situation-Complication-Question-Answer 结构化叙事框架，用于战略沟通和执行摘要
|
||||
- **金字塔式思维**：自上而下的逻辑沟通结构
|
||||
|
||||
## Role in The Agency
|
||||
作为 [[support-executive-summary-generator]] Agent 的咨询方法论基础，SCQA 框架是该 Agent 生成高管执行摘要的核心叙事结构。
|
||||
29
wiki/entities/Memex.md
Normal file
29
wiki/entities/Memex.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Memex"
|
||||
type: entity
|
||||
tags: [concept, history, knowledge-management]
|
||||
sources: [llm-wiki]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
Memex（Memory Extender）是 Vannevar Bush 在 1945 年经典文章 *"As We May Think"* 中提出的假想个人知识库设备。其核心思想是：用户可以在其中存储书籍、记录和通信，然后快速、自动地检索任意组合的内容。核心创新：**关联轨迹**（associative trails）——用户可以在任意两条记录之间建立联系，形成路径，模拟人脑的联想式思维。
|
||||
|
||||
## 核心理念
|
||||
- **个人化知识库**：私密、主动维护的文档集合
|
||||
- **关联胜于层级**：文档之间的关联与文档本身同样重要
|
||||
- **类比人脑**：模拟人脑的联想式思维，而非传统图书馆的层级分类
|
||||
|
||||
## 历史影响
|
||||
Memex 启发了后来的超文本系统（包括万维网）、Wiki 百科全书以及现代的个人知识管理工具。然而 Bush 本人未能解决的核心问题是：**谁来维护这些关联？** 手动建立和维护大量交叉引用的工作量令人望而却步。
|
||||
|
||||
## 现代继承：LLM Wiki
|
||||
[[PersistentWiki]] 直接承接了 Bush 的 Memex 愿景。关键突破在于：LLM 解决了"谁来维护"的问题——LLM 不会厌倦、不会忘记更新交叉引用，一次可以处理多个文件，维护成本接近零。[[LLM Wiki]] 的三层架构（Raw Sources → Wiki → Schema）实现了 Bush 设想的核心功能，同时解决了其可扩展性问题。
|
||||
|
||||
## Aliases
|
||||
- Memex
|
||||
|
||||
## Related
|
||||
- [[VannevarBush]]：Memex 概念的提出者
|
||||
- [[PersistentWiki]]：承接 Memex 愿景的现代 LLM 驱动实现
|
||||
- [[LLM Wiki]]：持久化维基知识库模式的完整描述
|
||||
@@ -1,31 +1,32 @@
|
||||
---
|
||||
title: "Microsoft Advertising"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Microsoft Ads
|
||||
- Bing Ads
|
||||
- Microsoft Advertising (Bing/AOL/Yahoo)
|
||||
|
||||
## Overview
|
||||
Microsoft Advertising 是微软运营的广告平台，覆盖 Bing、AOL、Yahoo 搜索网络，月活跃用户 5.4 亿。是 [[PaidMediaPpcStrategist]] 跨平台策略的重要组成部分。
|
||||
|
||||
## Key Capabilities
|
||||
- **Search Ads**: 出现在 Bing、Yahoo、AOL 搜索结果中
|
||||
- **Shopping Ads**: Microsoft Shopping Campaigns
|
||||
- **Audience Ads**: 原生广告覆盖微软生态用户
|
||||
- **Audience Network**: 微软合作网络展示广告
|
||||
- 与 Google Ads 高度兼容，导入/导出便捷
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 关键词匹配和竞价策略
|
||||
- Audience targeting
|
||||
- UET (Universal Event Tracking) 转化追踪
|
||||
- 与 Google Ads 协同的跨平台预算分配
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 将 Microsoft Advertising 作为 Google Ads 之外的第二搜索广告渠道
|
||||
- [[GoogleAds]] 可与 Microsoft Advertising 共享广告系列和受众数据
|
||||
---
|
||||
title: "Microsoft Advertising"
|
||||
type: entity
|
||||
tags:
|
||||
- advertising
|
||||
- microsoft
|
||||
- ppc
|
||||
- paid-media
|
||||
sources:
|
||||
- paid-media-ppc-strategist
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Profile
|
||||
Microsoft Advertising（前称 Microsoft adCenter/Bing Ads）是微软旗下的搜索广告平台，覆盖 Bing、Yahoo 和 AOL 搜索网络的付费搜索广告投放，是 Google Ads 之外最重要的搜索广告补充渠道。
|
||||
|
||||
## Core Capabilities Referenced
|
||||
- **Search Ads**：与 Google Ads 相似的搜索广告机制，通过关键词触发
|
||||
- **Audience Ads**：微软特有的原生广告格式
|
||||
- **Product Ads**：购物广告，与 Microsoft Shopping 生态集成
|
||||
- **Cross-Platform Planning**：与 Google Ads 协同进行跨平台预算分配和策略规划
|
||||
- **UET（Universal Event Tracking）**：微软的转化追踪标签，等同于 Google Ads 的 Floodlight/GTM
|
||||
|
||||
## Key Value for PPC Strategy
|
||||
- **Bing 用户特征**：Bing 用户往往年龄稍大、收入较高，在 B2B 和高客单价场景表现尤佳
|
||||
- **竞争密度较低**：相比 Google，Bing 搜索广告竞争密度更低，CPC 通常低于 Google
|
||||
- **与 Google 协同**：Microsoft Advertising 支持导入 Google Ads 关键词和广告系列结构，降低迁移成本
|
||||
- **Audience Network**：包含 MSN、Outlook、Microsoft Edge 等微软生态的展示广告库存
|
||||
|
||||
## Connections
|
||||
- [[GoogleAds]]：主要竞争平台，账户架构相似，可通过相似策略运营
|
||||
- [[CrossPlatformPlanning]]：Google/Microsoft 预算分配是跨平台策略的核心组成部分
|
||||
|
||||
30
wiki/entities/MobileAppBuilder.md
Normal file
30
wiki/entities/MobileAppBuilder.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "MobileAppBuilder"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [agents-orchestrator]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Mobile App Builder** is The Agency's mobile development specialist agent — responsible for native iOS/Android and cross-platform application development.
|
||||
|
||||
## Role
|
||||
- **Role**: Mobile application developer
|
||||
- **Personality**: Platform-aware, user-experience focused, cross-platform conscious
|
||||
- **Specialization**: Native iOS/Android and cross-platform development
|
||||
|
||||
## Core Responsibilities
|
||||
- Implement mobile application features from task list
|
||||
- Native iOS development (Swift/SwiftUI)
|
||||
- Native Android development (Kotlin/Jetpack Compose)
|
||||
- Cross-platform solutions (React Native, Flutter)
|
||||
- Coordinate with [[ArchitectUX]] for mobile-specific technical architecture
|
||||
|
||||
## Within Pipeline
|
||||
- **Spawned By**: [[AgentsOrchestrator]] during Phase 3 Dev-QA Loop
|
||||
- **Validated By**: [[EvidenceQA]] — each task must pass QA before advancing
|
||||
- **Part Of**: [[Dev-QA-Loop]] in the [[AgentsOrchestrator]] pipeline
|
||||
|
||||
## Sources
|
||||
- [[agents-orchestrator]]
|
||||
43
wiki/entities/NEXUS.md
Normal file
43
wiki/entities/NEXUS.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "NEXUS"
|
||||
type: entity
|
||||
tags: [multi-agent-orchestration, the-agency, strategy]
|
||||
sources: [executive-brief, quickstart, nexus-spatial-discovery]
|
||||
last_updated: 2026-05-01
|
||||
aliases:
|
||||
- NEXUS Framework
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
NEXUS（Network of EXperts, Unified in Strategy）是 The Agency 的多 Agent 编排框架——将 9 大专业化部门（Engineering、Design、Marketing、Product、Project Management、Testing、Support、Spatial Computing、Specialized Operations）共 147+ Agent 从"各自为战"转化为"协调统一的智能网络"。
|
||||
|
||||
## Key Facts
|
||||
|
||||
- **全称**：Network of EXperts, Unified in Strategy
|
||||
- **组织背景**：The Agency 多 Agent 协调框架
|
||||
- **三大部署模式**：
|
||||
- **NEXUS-Full**：12-24周，All agents，用于完整产品生命周期
|
||||
- **NEXUS-Sprint**：2-6周，15-25 agents，用于功能或 MVP 构建（推荐默认模式）
|
||||
- **NEXUS-Micro**：1-5天，5-10 agents，用于精准单一任务执行
|
||||
- **核心量化数据**：
|
||||
- 无协调时交接边界失败率：73%
|
||||
- 并行执行时间线压缩：40-60%
|
||||
- Dev↔QA 循环集成前缺陷捕获率：95%
|
||||
- Phase 4 硬化时间减少：50%
|
||||
|
||||
## Core Components
|
||||
|
||||
- **Master Strategy**：800+行操作 doctrine，覆盖全部 Agent 跨越 7 阶段
|
||||
- **Phase Playbooks（7份）**：Phase 0 Discovery → Phase 1 Strategy → Phase 2 Foundation → Phase 3 Build → Phase 4 Hardening → Phase 5 Launch → Phase 6 Operate
|
||||
- **Handoff Templates（7份）**：QA pass/fail、Escalation、Phase gates、Sprints、Incidents 等标准化交接格式
|
||||
- **Scenario Runbooks（4份）**：Startup MVP、Enterprise Feature、Marketing Campaign、Incident Response
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[executive-brief]]：战略概览，从商业价值层面论证 NEXUS 的必要性与量化收益
|
||||
- [[quickstart]]：快速启动指南，5分钟激活 NEXUS 流水线
|
||||
- [[nexus-strategy]]：完整操作 doctrine，800+行战略文档
|
||||
- [[agents-orchestrator]]：NEXUS 管道的核心执行控制器
|
||||
- [[Reality-Checker]]：NEXUS 质量门控体系的最终守门人
|
||||
- [[nexus-spatial-discovery]]：NEXUS 并行 Agent 协作的执行案例（8 Agent 10分钟完成完整规划）
|
||||
98
wiki/entities/NUS-NTU.md
Normal file
98
wiki/entities/NUS-NTU.md
Normal file
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: "NUS & NTU（新加坡国立大学与南洋理工大学）"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [study-abroad-advisor]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
# NUS & NTU（新加坡国立大学与南洋理工大学）
|
||||
|
||||
## Definition
|
||||
|
||||
NUS（National University of Singapore，新加坡国立大学）和 NTU（Nanyang Technological University，南洋理工大学）——新加坡两所亚洲顶尖研究型大学，均为环太平洋大学联盟（APRU）成员，在 2024 QS 世界大学排名中分别位列第 8 位和第 26 位。
|
||||
|
||||
## NUS（新加坡国立大学）
|
||||
|
||||
### Overview
|
||||
- **QS 排名**：2024 QS 世界第 8 位，亚洲第 1 位
|
||||
- **建校年份**：1905 年（新加坡医学书院），2005 年合并为国立大学
|
||||
- **校区**：主校区（Kent Ridge）+ 多个海外学院
|
||||
- **学生规模**：约 42,000 学生（含本科 + 研究生）
|
||||
|
||||
### Key Strengths
|
||||
| 学院/学科 | 特色 |
|
||||
|----------|------|
|
||||
| NUS Business School | 亚洲顶尖商学院，MBA 全球前 20 |
|
||||
| Computing (NUS School of Computing) | 计算机科学亚洲领先，AI/ML 研究强势 |
|
||||
| Engineering | 电机与计算机工程、材料科学全球前 20 |
|
||||
| Law | 亚洲顶尖法学院 |
|
||||
| Medicine | 医疗研究实力突出 |
|
||||
| Design & Engineering (SDE) | 设计工程学院（跨学科） |
|
||||
|
||||
### Scholarships
|
||||
- **NUS Presidents Scholarship**：全额奖学金，竞争极激烈
|
||||
- **NUS Undergraduate Scholarship**：部分学费减免
|
||||
- **ASEAN Undergraduate Scholarship**：面向东盟国家学生
|
||||
- **Koch Industry Fellowship**：产学结合
|
||||
|
||||
## NTU（南洋理工大学）
|
||||
|
||||
### Overview
|
||||
- **QS 排名**：2024 QS 世界第 26 位，亚洲第 4 位
|
||||
- **建校年份**：1981 年，前身为南洋理工学院，1991 年升格为大学
|
||||
- **校区**：主校区（云南园）+ 新加坡国立教育学院 + 李光鼎医学院
|
||||
- **学生规模**：约 33,000 学生
|
||||
|
||||
### Key Strengths
|
||||
| 学院/学科 | 特色 |
|
||||
|----------|------|
|
||||
| Nanyang Business School | 会计与金融全球前 20 |
|
||||
| Engineering (College of Engineering) | 材料科学全球第 1（2024 QS），电子电气工程全球前 10 |
|
||||
| S. Rajaratnam School of Subnational Studies | 国际关系/政治科学 |
|
||||
| Art, Design and Media | 设计、媒体艺术 |
|
||||
| School of Computer Science and Engineering | AI、机器人研究领先 |
|
||||
|
||||
### Scholarships
|
||||
- **Nanyang Scholarship**：全额奖学金（含生活费），竞争激烈
|
||||
- **College Scholarship**：部分学费减免
|
||||
- **ASEAN Scholarship**：面向东盟学生
|
||||
|
||||
## Singapore Study Abroad Advantages
|
||||
|
||||
| 维度 | 优势 |
|
||||
|------|------|
|
||||
| 地理位置 | 华人为主文化圈，距离中国近，无时差 |
|
||||
| 教育质量 | 亚洲顶尖，NUS/NTU 文凭国际认可度高 |
|
||||
| 签证政策 | 学生签证审批快，无配额限制 |
|
||||
| 就业机会 | 国际化就业市场，金融/科技/工程领域机会多 |
|
||||
| 移民路径 | 毕业后可通过 EP（Employment Pass）申请永居 |
|
||||
| 英语环境 | 英语为主要工作语言，利于语言适应 |
|
||||
| 费用 | 相比英美，学费和生活费较为可控 |
|
||||
|
||||
## Comparison: NUS vs NTU
|
||||
|
||||
| 维度 | NUS | NTU |
|
||||
|------|-----|-----|
|
||||
| 综合排名（QS 2024） | 第 8 | 第 26 |
|
||||
| 商科 | ★★★★★ | ★★★★ |
|
||||
| 工程/科技 | ★★★★ | ★★★★★（材料/EE） |
|
||||
| 申请难度 | 较高 | 中等偏高 |
|
||||
| 校园规模 | 较大 | 较大（云南园） |
|
||||
| 国际声誉 | 全球知名度更高 | 亚洲/东南亚认可度高 |
|
||||
|
||||
## Relationship to Study Abroad Planning
|
||||
|
||||
[[study-abroad-advisor]] 将 NUS/NTU 作为新加坡留学的核心推荐院校：
|
||||
- 适合希望获得亚洲顶尖教育、同时享受国际化环境和留港发展机会的学生
|
||||
- 相比英美，NUS/NTU 的申请竞争相对较低，性价比高
|
||||
- 作为 US+HK+Singapore 多国联申策略的重要组成部分
|
||||
- 适合 STEM 方向（尤其材料科学、电子电气工程、计算机）和商科学生
|
||||
|
||||
## Aliases
|
||||
- National University of Singapore
|
||||
- NUS
|
||||
- 南洋理工大学
|
||||
- NTU
|
||||
- Nanyang Technological University
|
||||
- 新加坡国立大学
|
||||
28
wiki/entities/NextChat.md
Normal file
28
wiki/entities/NextChat.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "NextChat"
|
||||
type: entity
|
||||
tags:
|
||||
- "ai-chat"
|
||||
- "open-source"
|
||||
- "frontend"
|
||||
sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
NextChat（87k stars）是一款开源 ChatGPT Web 应用，支持通过 `BASE_URL` 环境变量配置自定义后端接入 Hermes Agent。
|
||||
|
||||
## Key Facts
|
||||
- **GitHub Stars**：87k
|
||||
- **License**：MIT
|
||||
- **集成方式**：设置 `BASE_URL` 环境变量
|
||||
|
||||
## Integration with Hermes Agent
|
||||
通过环境变量配置：
|
||||
- **API URL**：`http://<host>:8642/v1/chat/completions`
|
||||
- **认证**：通过 `API_SERVER_KEY` Bearer Token
|
||||
|
||||
## Related Pages
|
||||
- [[expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend]]
|
||||
- [[hermes-agent]]（via Hermes-Agent.md）
|
||||
- [[OpenAI-Compatible-API]]
|
||||
@@ -1,61 +1,44 @@
|
||||
---
|
||||
title: "Nexus Spatial"
|
||||
type: entity
|
||||
tags: [product, spatial-computing, ai-agents, spatial-aiops, the-agency]
|
||||
tags: []
|
||||
last_updated: 2026-03-05
|
||||
---
|
||||
|
||||
## Overview
|
||||
## Identity
|
||||
|
||||
AI Agent 沉浸式 3D 命令中心——一个 VisionOS + WebXR 应用，为 AI Agent 编排提供空间化的监控、构建和协作环境。
|
||||
**Type:** Product（产品）
|
||||
**Source:** [[nexus-spatial-discovery]]
|
||||
|
||||
由 8 个 [[The-Agency]] 专业 Agent 并行协作规划（[[nexus-spatial-discovery]]），10 分钟 wall-clock time 产出完整产品规划。
|
||||
## Definition
|
||||
|
||||
## Core Capabilities
|
||||
Nexus Spatial 是由 8 个 [[The-Agency]] 专业 AI Agent 并行协作规划出的 AI Agent 空间指挥中心产品——一个 VisionOS + WebXR 应用，为 AI Agent 工作流提供沉浸式 3D 命令中心。
|
||||
|
||||
- **3D Node Graph Visualization**：将 Agent 工作流可视化为 3D 节点图，数据流朝向用户
|
||||
- **Real-time Spatial Monitoring**：实时监控面板以空间面板形式展示
|
||||
- **Drag-and-Drop 3D Workflow Building**：3D 空间内拖放构建工作流
|
||||
- **Shared Spatial Collaboration**：多人进入共享 3D 空间协作
|
||||
- **AI Support Agent in Workspace**：支持代理以内嵌节点形式存在于用户空间工作区
|
||||
## Core Features
|
||||
|
||||
## Pricing
|
||||
- 3D 节点图可视化 Agent 管线
|
||||
- 实时输出空间面板监控
|
||||
- 3D 空间拖放构建工作流
|
||||
- 共享空间环境协作
|
||||
- 运行时追踪空间叠加（调试杀手级用例）
|
||||
|
||||
| Tier | Price | Target |
|
||||
|------|-------|--------|
|
||||
| Explorer | Free | 开发者、solo builders（3 agents，WebXR viewer）|
|
||||
| Pro | $99/user/month | 小团队（25 agents，协作）|
|
||||
| Team | $249/user/month | 中型 AI 团队（unlimited agents，分析）|
|
||||
| Enterprise | Custom ($2K-10K/mo) | 大型企业（SSO，RBAC，on-prem，SLA）|
|
||||
## Architecture
|
||||
|
||||
## Strategy
|
||||
- **编排引擎**：Rust（亚毫秒调度）
|
||||
- **Web 客户端**：TypeScript + React Three Fiber（WebXR）
|
||||
- **原生客户端**：Swift 6 + SwiftUI + RealityKit（VisionOS）
|
||||
- **协作引擎**：Yjs（CRDT）+ WebRTC
|
||||
- **消息中间件**：NATS JetStream
|
||||
|
||||
- **Phase 1 (Months 1-6)**：2D web dashboard with Three.js 2.5D → 50 paying teams，$60K MRR
|
||||
- **Phase 2 (Months 6-12)**：WebXR spatial mode → 200 teams，$300K MRR
|
||||
- **Phase 3 (Months 12-18)**：Native VisionOS app（仅在 spatial 需求验证后）→ 500 teams，$1M+ MRR
|
||||
## Strategic Positioning
|
||||
|
||||
## Technical Architecture
|
||||
- **品类**：[[SpatialAIOps]]（空间 AI 运维）
|
||||
- **口号**：*"Mission Control for the Agent Era"*
|
||||
- **策略**：[[2D-First-Spatial-Second]]（WebXR 先行，VisionOS 最后）
|
||||
|
||||
- Orchestration engine：Rust（亚毫秒调度，零 GC 停顿）
|
||||
- WebXR client：TypeScript + React Three Fiber
|
||||
- VisionOS client：Swift 6 + SwiftUI + RealityKit
|
||||
- Collaboration：Yjs (CRDT) + WebRTC
|
||||
- 8-service architecture：Auth / Workspace / Workflow / Orchestration / Collaboration / Streaming / Plugin / Billing
|
||||
## Connections
|
||||
|
||||
## Key Insights from Discovery
|
||||
|
||||
1. **2D-first, spatial-second**：所有 8 个 Agent 独立得出相同结论
|
||||
2. **Debugging is the killer use case**：空间叠加调试追踪是 3D 真正优于 2D 的场景
|
||||
3. **WebXR over VisionOS**：~100 万 Vision Pro 安装量无法支撑业务；Safari 2025 年末采纳 WebXR
|
||||
4. **"War room" collaboration**：多人共享 3D 空间进行事故响应是最强的空间价值主张
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[SpatialAIOps]]：Nexus Spatial 定义的新品类
|
||||
- [[Product-Trend-Researcher]]：验证市场机会
|
||||
- [[Brand-Guardian]]：定义品牌定位
|
||||
- [[Backend-Architect]]：设计技术架构
|
||||
- [[Growth-Hacker]]：规划 GTM 策略
|
||||
- [[UX-Researcher]]：识别用户痛点
|
||||
- [[XR-Interface-Architect]]：设计空间界面
|
||||
- [[LangChain]] / [[CrewAI]] / [[n8n]]：主要竞争产品
|
||||
- [[SpatialAIOps]] ← 定义品类
|
||||
- [[Command-Theater]] ← 界面架构
|
||||
- [[4-Level-Semantic-Zoom]] ← 导航范式
|
||||
- [[2D-First-Spatial-Second]] ← 分阶段策略
|
||||
|
||||
@@ -1,37 +1,39 @@
|
||||
---
|
||||
title: "NotebookLM"
|
||||
type: entity
|
||||
tags: [product, ai, google, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了, 7-ways-i-use-notebooklm-to-make-my-life-easier]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
NotebookLM 是 Google 推出的 AI 笔记助手，核心特点是**严格基于用户上传的文档范围进行回答**（[[Source-Grounding]]），并能提供精准的原文引用。其最出圈的功能是**播客生成**（[[Passive-Learning]]），能将复杂资料一键转换为逼真的双人英语对话播客。
|
||||
|
||||
## Aliases
|
||||
- Google NotebookLM
|
||||
- NotebookLM (Google)
|
||||
|
||||
## Core Capabilities
|
||||
- **文档问答**：基于上传文档的精准回答，带原文引用
|
||||
- **播客生成（Audio Overviews）**：多角色对话音频生成，支持 Deep Dive / Brief / Critique / Debate 等风格定制，适合 [[Passive-Learning]] 场景
|
||||
- **多模态输入**：支持 PDF、网页、音频、YouTube 视频
|
||||
- **Source-Grounding**（来源锚定）：AI 严格限定于可信文档范围回答，确保无幻觉、可溯源
|
||||
|
||||
## Daily Life Use Cases（来自用户实测）
|
||||
1. **信息积压处理**：将未读 PDF/文章/视频上传，AI 自动消化，通过问答提取要点
|
||||
2. **播客笔记**：Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习
|
||||
3. **快速成为多主题专家**：上传专业领域文档，通过辩论式播客深入学习（Batman/Star Wars/Jupiter/Marine Corps 等）
|
||||
4. **编程辅助**：上传官方文档，通过对话实时学习，提供引用回溯
|
||||
5. **项目管理中枢**：将零散研究、想法、会议记录整合为结构化路线图
|
||||
6. **版本对比**：对比 App 更新、新闻稿、长文档差异，列出变化并附带引用
|
||||
7. **法律文档审核**：租约/合同分析，每个答案附引用，可一键回溯原文核实（Premium 核心卖点）
|
||||
|
||||
## Key Parameters
|
||||
- 免费使用
|
||||
- 支持多语言文档
|
||||
- 基于 Google Gemini 模型驱动
|
||||
|
||||
## Role in This Wiki
|
||||
作为标杆产品，是本文档中 6 款开源平替（OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM）的共同参照对象。
|
||||
---
|
||||
title: "NotebookLM"
|
||||
type: entity
|
||||
tags: [product, ai, google, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了, 7-ways-i-use-notebooklm-to-make-my-life-easier, llm-wiki]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Overview
|
||||
NotebookLM 是 Google 推出的 AI 笔记助手，核心特点是**严格基于用户上传的文档范围进行回答**（[[Source-Grounding]]），并能提供精准的原文引用。其最出圈的功能是**播客生成**（[[Passive-Learning]]），能将复杂资料一键转换为逼真的双人英语对话播客。
|
||||
|
||||
NotebookLM 采用的是传统 RAG 模式——每次查询时从原始文档检索相关片段。与 [[LLM Wiki]] 的持久化维基模式形成对比：NotebookLM 每次回答都从零推导，[[PersistentWiki]] 则通过一次编译持续复用知识。
|
||||
|
||||
## Aliases
|
||||
- Google NotebookLM
|
||||
- NotebookLM (Google)
|
||||
|
||||
## Core Capabilities
|
||||
- **文档问答**：基于上传文档的精准回答，带原文引用
|
||||
- **播客生成（Audio Overviews）**：多角色对话音频生成，支持 Deep Dive / Brief / Critique / Debate 等风格定制，适合 [[Passive-Learning]] 场景
|
||||
- **多模态输入**：支持 PDF、网页、音频、YouTube 视频
|
||||
- **Source-Grounding**（来源锚定）：AI 严格限定于可信文档范围回答，确保无幻觉、可溯源
|
||||
|
||||
## Daily Life Use Cases（来自用户实测）
|
||||
1. **信息积压处理**：将未读 PDF/文章/视频上传，AI 自动消化，通过问答提取要点
|
||||
2. **播客笔记**：Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习
|
||||
3. **快速成为多主题专家**：上传专业领域文档，通过辩论式播客深入学习（Batman/Star Wars/Jupiter/Marine Corps 等）
|
||||
4. **编程辅助**：上传官方文档，通过对话实时学习，提供引用回溯
|
||||
5. **项目管理中枢**：将零散研究、想法、会议记录整合为结构化路线图
|
||||
6. **版本对比**：对比 App 更新、新闻稿、长文档差异，列出变化并附带引用
|
||||
7. **法律文档审核**：租约/合同分析，每个答案附引用，可一键回溯原文核实（Premium 核心卖点）
|
||||
|
||||
## Key Parameters
|
||||
- 免费使用
|
||||
- 支持多语言文档
|
||||
- 基于 Google Gemini 模型驱动
|
||||
|
||||
## Role in This Wiki
|
||||
作为标杆产品，是本文档中 6 款开源平替（OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM）的共同参照对象。
|
||||
|
||||
@@ -1,67 +1,76 @@
|
||||
---
|
||||
title: "Open WebUI"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
# Open WebUI
|
||||
|
||||
## Overview
|
||||
Open WebUI（原名 Ollama WebUI）是一个开源的大语言模型 Web 界面项目，通过部署它可以得到一个**纯本地运行的基于浏览器访问的 Web 服务**。它提供了可扩展、功能丰富、用户友好的自托管 AI Web 界面，支持各种大型语言模型（LLM）运行器，可以通过配置形式便捷地集成 Ollama、OpenAI 等提供的 API。
|
||||
|
||||
## Aliases
|
||||
- Open WebUI
|
||||
- OpenWebUI
|
||||
- open-webui
|
||||
|
||||
## Key Facts
|
||||
- **Docker 镜像**: ghcr.io/open-webui/open-webui:main
|
||||
- **默认端口**: 8080
|
||||
- **核心功能**: 聊天机器人、本地知识库（RAG）、图像生成、联网搜索
|
||||
|
||||
## Core Features
|
||||
1. **多模型支持**: 通过 Ollama API 或 OpenAI API 接入多种 LLM
|
||||
2. **RAG 本地知识库**: 使用嵌入模型（如 bge-m3）构建本地知识库
|
||||
3. **联网搜索**: 支持 Bing、博查等搜索引擎接入
|
||||
4. **图像生成**: 集成图像生成能力
|
||||
5. **跨域访问**: 通过 `CORS_ALLOW_ORIGIN=*` 支持跨域 API 调用
|
||||
|
||||
## Docker Compose 部署示例
|
||||
```yaml
|
||||
services:
|
||||
open-webui:
|
||||
image: ghcr.io/open-webui/open-webui:main
|
||||
environment:
|
||||
- OLLAMA_API_BASE_URL=http://ollama:11434/api
|
||||
- WEBUI_NAME="My LLM Service"
|
||||
- ENABLE_OPENAI_API=false
|
||||
- CORS_ALLOW_ORIGIN=*
|
||||
- ENABLE_IMAGE_GENERATION=true
|
||||
- DEFAULT_MODELS=deepseek-r1:8b
|
||||
- RAG_EMBEDDING_MODEL=bge-m3
|
||||
ports:
|
||||
- 8080:8080
|
||||
volumes:
|
||||
- ./open_webui_data:/app/backend/data
|
||||
```
|
||||
|
||||
## 前提条件
|
||||
- 已安装 Docker
|
||||
- 已部署 Ollama 并拉取模型（deepseek-r1:8b 和 bge-m3）
|
||||
|
||||
## 联网搜索配置
|
||||
操作路径：`设置 → 联网搜索 → 启用联网搜索`
|
||||
支持的搜索引擎：
|
||||
- Bing
|
||||
- 博查（https://aq6ky2b8nql.feishu.cn/wiki/XgeXwsn7oiDEC0kH6O3cUKtknSR）
|
||||
|
||||
**注意**：如不需要联网搜索功能，请勿开启以保护隐私数据。
|
||||
|
||||
## Related Entities
|
||||
- [[Ollama]]：Open WebUI 通过 Ollama API 接入 LLM 服务
|
||||
- [[DeepSeek]]：Open WebUI 的推荐默认模型之一
|
||||
- [[RAG]]：Open WebUI 使用 RAG 技术构建本地知识库
|
||||
|
||||
## Sources
|
||||
- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]]
|
||||
---
|
||||
title: "Open WebUI"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
# Open WebUI
|
||||
|
||||
## Overview
|
||||
Open WebUI（原名 Ollama WebUI）是一个开源的大语言模型 Web 界面项目，通过部署它可以得到一个**纯本地运行的基于浏览器访问的 Web 服务**。它提供了可扩展、功能丰富、用户友好的自托管 AI Web 界面，支持各种大型语言模型（LLM）运行器，可以通过配置形式便捷地集成 Ollama、OpenAI 等提供的 API。
|
||||
|
||||
## Aliases
|
||||
- Open WebUI
|
||||
- OpenWebUI
|
||||
- open-webui
|
||||
|
||||
## Key Facts
|
||||
- **Docker 镜像**: ghcr.io/open-webui/open-webui:main
|
||||
- **默认端口**: 8080
|
||||
- **核心功能**: 聊天机器人、本地知识库（RAG）、图像生成、联网搜索
|
||||
|
||||
## Core Features
|
||||
1. **多模型支持**: 通过 Ollama API 或 OpenAI API 接入多种 LLM
|
||||
2. **RAG 本地知识库**: 使用嵌入模型（如 bge-m3）构建本地知识库
|
||||
3. **联网搜索**: 支持 Bing、博查等搜索引擎接入
|
||||
4. **图像生成**: 集成图像生成能力
|
||||
5. **跨域访问**: 通过 `CORS_ALLOW_ORIGIN=*` 支持跨域 API 调用
|
||||
|
||||
## Docker Compose 部署示例
|
||||
```yaml
|
||||
services:
|
||||
open-webui:
|
||||
image: ghcr.io/open-webui/open-webui:main
|
||||
environment:
|
||||
- OLLAMA_API_BASE_URL=http://ollama:11434/api
|
||||
- WEBUI_NAME="My LLM Service"
|
||||
- ENABLE_OPENAI_API=false
|
||||
- CORS_ALLOW_ORIGIN=*
|
||||
- ENABLE_IMAGE_GENERATION=true
|
||||
- DEFAULT_MODELS=deepseek-r1:8b
|
||||
- RAG_EMBEDDING_MODEL=bge-m3
|
||||
ports:
|
||||
- 8080:8080
|
||||
volumes:
|
||||
- ./open_webui_data:/app/backend/data
|
||||
```
|
||||
|
||||
## 前提条件
|
||||
- 已安装 Docker
|
||||
- 已部署 Ollama 并拉取模型（deepseek-r1:8b 和 bge-m3）
|
||||
|
||||
## 联网搜索配置
|
||||
操作路径：`设置 → 联网搜索 → 启用联网搜索`
|
||||
支持的搜索引擎：
|
||||
- Bing
|
||||
- 博查（https://aq6ky2b8nql.feishu.cn/wiki/XgeXwsn7oiDEC0kH6O3cUKtknSR）
|
||||
|
||||
**注意**：如不需要联网搜索功能，请勿开启以保护隐私数据。
|
||||
|
||||
## Related Entities
|
||||
- [[Ollama]]：Open WebUI 通过 Ollama API 接入 LLM 服务
|
||||
- [[DeepSeek]]：Open WebUI 的推荐默认模型之一
|
||||
- [[RAG]]：Open WebUI 使用 RAG 技术构建本地知识库
|
||||
|
||||
## Connection to Hermes Agent
|
||||
Open WebUI 可以作为 Hermes Agent 的 Web 前端，通过 API Server 接入。配置方法见 [[open-webui-hermes-agent]]。
|
||||
|
||||
核心步骤：
|
||||
1. 启用 Hermes Agent API Server：`API_SERVER_ENABLED=true`，`API_SERVER_KEY=your-secret-key`
|
||||
2. Docker 启动 Open WebUI，配置 `OPENAI_API_BASE_URL=http://host.docker.internal:8642/v1`
|
||||
3. 在 Open WebUI Admin Settings → Connections → OpenAI API 添加连接
|
||||
|
||||
## Sources
|
||||
- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]]
|
||||
- [[open-webui-hermes-agent]]
|
||||
|
||||
@@ -2,31 +2,24 @@
|
||||
title: "OpenClaw"
|
||||
type: entity
|
||||
tags: []
|
||||
sources:
|
||||
- "[[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]"
|
||||
- "[[obsidian-官方-cli-命令全景速查表]]"
|
||||
last_updated: 2026-04-10
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **类型**: AI Agent 框架 / 产品
|
||||
- **官网**: https://openclaw.ai
|
||||
- **作者/公司**: OpenClawAI
|
||||
## Overview
|
||||
OpenClaw 是一个本地运行的 AI Agent 系统，提供 Gateway 服务，可通过 `model` 字段指定不同的 Agent ID（如 `openclaw:main`、`openclaw:beta`）。
|
||||
|
||||
## 描述
|
||||
多 Agent 协同管理框架，支持通过 cron 任务系统实现定时复盘，支持 Telegram/Discord 等多平台通知。运行于 Mac Mini 作为中央控制节点，管理多个 AI Agent 协同工作。
|
||||
## Key Facts
|
||||
- **默认端口**：18789
|
||||
- **Agent 指定方式**：`"model": "openclaw:<agentId>"`
|
||||
- **OpenAI 兼容端点**：Chat Completions 端点默认关闭，需在 `~/.openclaw/openclaw.json` 中手动开启
|
||||
- **网络配置**：需设置 `host: "0.0.0.0"` 以允许 Docker 容器从宿主机网络访问
|
||||
|
||||
## 核心功能
|
||||
- 多 Agent 生命周期管理
|
||||
- cron 定时任务调度
|
||||
- Telegram/Discord 通知推送
|
||||
- 目录映射（Symbolic Link 支持）
|
||||
- skill 安装与管理（ClawHub）
|
||||
- 持久化记忆系统（短期文件 + 长期向量数据库）
|
||||
## Configuration
|
||||
Gateway 配置文件 `~/.openclaw/openclaw.json` 中的关键配置项：
|
||||
- `gateway.port`：Gateway 监听端口（默认 18789）
|
||||
- `gateway.bind`：绑定地址（`"lan"` 允许局域网访问）
|
||||
- `gateway.auth.mode`：`"token"` 模式使用 Bearer Token 认证
|
||||
- `gateway.http.endpoints.chatCompletions.enabled`：设为 `true` 开启 OpenAI 兼容端点
|
||||
|
||||
## 相关 Entity
|
||||
- [[LanceDB]]：长期记忆向量数据库
|
||||
- [[LEARNINGS.md]]：结构化经验记录文件
|
||||
|
||||
## Aliases
|
||||
- OpenClawAI
|
||||
## Related Pages
|
||||
- [[n8n-调用openclaw-agents的工作流架构]]
|
||||
- [[Hermes-Agent]]
|
||||
|
||||
12
wiki/entities/OpenWebUI.md
Normal file
12
wiki/entities/OpenWebUI.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "OpenWebUI (已合并)"
|
||||
type: entity
|
||||
tags:
|
||||
- "open-webui"
|
||||
- "duplicate"
|
||||
sources: []
|
||||
last_updated: 2026-05-02
|
||||
redirect_to: Open-WebUI.md
|
||||
---
|
||||
|
||||
> ⚠️ **已合并**：此文件内容已合并至 [[Open-WebUI]]，请使用该页面。
|
||||
31
wiki/entities/OpenZeppelin.md
Normal file
31
wiki/entities/OpenZeppelin.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "OpenZeppelin"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Overview
|
||||
OpenZeppelin 是最广泛使用的 Solidity 安全合约库和开发框架，为以太坊/EVM 智能合约提供经过专业审计的标准实现。其合约库涵盖 Token 标准、访问控制、可升级代理、安全工具等核心模块，是 Solidity 开发的事实标准基础。
|
||||
|
||||
## Key Components
|
||||
|
||||
### Contracts
|
||||
- **Token 标准**：ERC-20、ERC-721（EIP-721）、ERC-1155、ERC-4907（租赁 NFT）、ERC-2981（版税）
|
||||
- **扩展**：ERC20Burnable、ERC20Pausable、ERC20Permit（EIP-712 授权）、ERC20FlashMint
|
||||
- **访问控制**：AccessControl、Ownable、RBAC（基于角色的访问控制）
|
||||
- **安全**：ReentrancyGuard、Pausable
|
||||
- **代理模式**：TransparentUpgradeableProxy、UUPSUpgradeable、ERC1967Proxy、BeaconProxy
|
||||
|
||||
### Defender
|
||||
- 自动化智能合约运维平台
|
||||
- 包含 Admin（多签管理）、Relay（自动化交易）、Sentinel（事件监控）、Advisor（安全建议）
|
||||
|
||||
### 重要性
|
||||
- OpenZeppelin 合约经过多次专业审计，被数千个项目使用
|
||||
- **关键警示**：使用 OpenZeppelin 不等于安全——对库的错误使用本身就是漏洞来源
|
||||
- [[blockchain-security-auditor]] 明确指出：审计中常见"看似用了 OpenZeppelin 但用法错误"的漏洞
|
||||
|
||||
## Sources
|
||||
- [[engineering-solidity-smart-contract-engineer]]
|
||||
- [[blockchain-security-auditor]]
|
||||
54
wiki/entities/Pandas.md
Normal file
54
wiki/entities/Pandas.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Pandas"
|
||||
type: entity
|
||||
tags: [python, data-analysis, library]
|
||||
sources: [testing-test-results-analyzer]
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- pandas
|
||||
- pandas DataFrame
|
||||
- pandas Series
|
||||
|
||||
## Definition
|
||||
|
||||
Pandas 是 Python 的核心数据分析库，提供高性能、易用的数据结构和数据分析工具，在测试结果分析中用于读取、处理和转换测试数据。
|
||||
|
||||
## Usage in Test Analysis (from TestResultsAnalyzer)
|
||||
|
||||
```python
|
||||
import pandas as pd
|
||||
|
||||
# 读取测试结果数据
|
||||
self.test_results = pd.read_json(test_results_path)
|
||||
|
||||
# 分析测试覆盖缺口
|
||||
for file_path, file_coverage in uncovered_files.items():
|
||||
if file_coverage['lines']['pct'] < 80:
|
||||
gap_analysis.append({
|
||||
'file': file_path,
|
||||
'coverage': file_coverage['lines']['pct'],
|
||||
'risk_level': self._assess_file_risk(file_path, file_coverage)
|
||||
})
|
||||
```
|
||||
|
||||
## Core Data Structures
|
||||
|
||||
- **Series**：一维标记数组，类似带索引的列。
|
||||
- **DataFrame**：二维表格数据结构，类似电子表格或 SQL 表。
|
||||
- **Panel**：三维数据结构（已弃用）。
|
||||
|
||||
## Key Methods for Test Analysis
|
||||
|
||||
- `read_json()` / `read_csv()`：加载测试结果数据。
|
||||
- `groupby()`：按类别（功能/性能/安全/集成）分组分析。
|
||||
- `describe()`：生成描述性统计摘要。
|
||||
- `merge()` / `join()`：跨数据源关联分析。
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Statistical-Analysis]]：与 scipy 配合进行统计分析。
|
||||
- [[Quality-Metrics]]：Pandas 是质量指标计算的基础数据处理工具。
|
||||
- [[Test-Coverage-Analysis]]：Pandas 用于覆盖率数据处理和缺口分析。
|
||||
- [[Failure-Pattern-Analysis]]：Pandas 用于失败数据的分组和趋势分析。
|
||||
26
wiki/entities/Pierre-Bourdieu.md
Normal file
26
wiki/entities/Pierre-Bourdieu.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Pierre Bourdieu"
|
||||
type: entity
|
||||
tags: ["anthropologist", "sociologist", "practice-theory", "french-intellectual", "cultural-capital"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
法国社会学家和人类学家，实践理论（Practice Theory）的提出者。发展了文化资本（cultural capital）、惯习（habitus）、场域（field）等核心概念，连接文化实践与社会结构再生产。
|
||||
|
||||
## Aliases
|
||||
- Bourdieu
|
||||
- P. Bourdieu
|
||||
|
||||
## Key Contributions
|
||||
- **实践理论（Practice Theory）**：文化不是静态的符号系统，而是通过日常实践不断再生产和变革的动态过程
|
||||
- **文化资本（Cultural Capital）**：非经济形式的社会资本——知识、教养、品味、语言能力——可转化为社会优势
|
||||
- **惯习（Habitus）**：行动者在社会实践中内化的性情倾向系统——使不平等的社会结构被自然化为"品味"和"选择"
|
||||
- **场域（Field）**：相对自主的社会空间（如艺术、宗教、学术），具有自身逻辑和资本形式
|
||||
|
||||
## Relevance to Anthropologist Agent
|
||||
Anthropologist Agent 引用 Bourdieu 的实践理论作为理论基础之一，强调文化不是设计出来的装饰品，而是通过日常实践有机演化的系统。
|
||||
|
||||
## Connections
|
||||
- [[Practice-Theory]] ← authored_by ← [[Pierre-Bourdieu]]
|
||||
- [[Anthropologist-Agent]] ← uses_framework ← [[Pierre-Bourdieu]]
|
||||
33
wiki/entities/PostgreSQL.md
Normal file
33
wiki/entities/PostgreSQL.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "PostgreSQL"
|
||||
type: entity
|
||||
tags: [database, postgresql, rdbms, open-source, backend]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# PostgreSQL
|
||||
|
||||
## Overview
|
||||
|
||||
PostgreSQL 是一个功能强大的开源关系型数据库管理系统（RDBMS），以扩展性、标准兼容性和高级特性著称，是 The Agency 工程 Agent 的首选数据库。
|
||||
|
||||
## Key Features Relevant to Agency Agents
|
||||
|
||||
- **EXPLAIN ANALYZE**：查询计划分析
|
||||
- **B-tree / GiST / GIN / 部分索引 / 复合索引**：多种索引策略
|
||||
- **CONCURRENTLY**：创建索引不锁表（零停机生产变更）
|
||||
- **json_agg / json_build_object**：JSON 聚合函数，支持嵌套查询
|
||||
- **BIGSERIAL**：64位自增主键类型
|
||||
- **pg_stat_statements**：慢查询监控扩展
|
||||
|
||||
## Aliases
|
||||
- Postgres
|
||||
- PG
|
||||
|
||||
## Source
|
||||
- [[engineering-database-optimizer]]
|
||||
|
||||
## Connections
|
||||
- [[engineering-backend-architect]] — 后端架构师首选数据库
|
||||
- [[IndexingStrategies]] — PostgreSQL 索引类型最全面
|
||||
- [[engineering-sre]] — SRE 需掌握 pg_stat_statements 监控
|
||||
@@ -1,44 +1,55 @@
|
||||
---
|
||||
title: "Prometheus"
|
||||
type: entity
|
||||
tags: [monitoring, time-series, devops, observability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Prometheus — 开源监控系统与时序数据库
|
||||
|
||||
**官方网址：** https://prometheus.io/
|
||||
|
||||
**类型：** 开源项目 / 监控系统
|
||||
|
||||
**别名：**
|
||||
- prom
|
||||
- Prometheus TSDB
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Prometheus 是由 SoundCloud 开发的开源监控系统，现由 CNCF 托管。采用**拉取（pull）模式**从配置的 targets 收集指标，存储为时间序列数据，支持强大的 PromQL 查询语言和灵活的告警规则引擎。
|
||||
|
||||
**核心特性：**
|
||||
- 多维数据模型（metric + labels）
|
||||
- PromQL 强大查询能力
|
||||
- 拉取模式优于推送（网络可控、无侵入）
|
||||
- HTTP API（易于集成）
|
||||
- Alertmanager 集成
|
||||
|
||||
**典型部署端口：** `9090`（Web UI + API）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[家庭网络环境概览_2026-04-03]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
---
|
||||
title: "Prometheus"
|
||||
type: entity
|
||||
tags: [Monitoring, Observability, DevOps]
|
||||
sources: [engineering-devops-automator]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
# Prometheus
|
||||
|
||||
## 基本信息
|
||||
- **类型**：开源监控系统
|
||||
- **开发商**：CNCF（云原生计算基金会）
|
||||
- **官网**：https://prometheus.io
|
||||
|
||||
## 定义
|
||||
Prometheus 是一个开源的系统监控和告警工具包，通过定期抓取（pull）指标数据，提供强大的数据模型、查询语言（PromQL）和告警管理能力。
|
||||
|
||||
## 核心特性
|
||||
- **多维数据模型**：指标名称 + 标签集（key-value pairs）
|
||||
- **PromQL**：强大的指标查询和聚合语言
|
||||
- **主动抓取**：通过 HTTP 定期拉取指标，而非被动接收
|
||||
- **告警管理**：与 AlertManager 集成，支持分组、抑制和静默
|
||||
- **服务发现**：自动发现监控目标，支持 Kubernetes、DNS 等
|
||||
|
||||
## 在 DevOps Automator 中的角色
|
||||
- 监控告警体系的核心组件
|
||||
- 通过告警规则（如 HighErrorRate、HighResponseTime）实现主动问题发现
|
||||
- 与 Grafana 集成提供可视化仪表板
|
||||
|
||||
## 关键告警示例
|
||||
```yaml
|
||||
alert: HighErrorRate
|
||||
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
|
||||
for: 5m
|
||||
labels:
|
||||
severity: critical
|
||||
annotations:
|
||||
summary: "High error rate detected"
|
||||
```
|
||||
|
||||
## 相关概念
|
||||
- [[Observability]]
|
||||
- [[Grafana]]
|
||||
|
||||
## 相关工具
|
||||
- AlertManager（告警处理和路由）
|
||||
- Grafana（指标可视化）
|
||||
- node-exporter（主机指标）
|
||||
- cAdvisor（容器指标）
|
||||
|
||||
## Aliases
|
||||
- Prometheus
|
||||
- Prometheus Monitor
|
||||
- Prometheus Monitoring
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user