Auto-sync
This commit is contained in:
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "AI拟人化谬误"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
将 LLM 拟人化（赋予名字、情感、恐惧、动机）是一种设计谬误。LLM 没有生物体的局限性——不会死亡、饥饿或害怕；它们在推理时只存在几秒钟来生成响应，缺乏真正的同理心或情感。
|
||||
|
||||
## Why It's Wrong
|
||||
- LLM 天生的不可靠性（幻觉、逻辑谬误、上下文漂移）与人类不同
|
||||
- 对 LLM 的"威胁"或"激励"只是利用训练数据中高风险→高质量输出的相关性
|
||||
- 拟人化会掩盖 LLM 真正的问题：将其视为可靠组件而非需要工程保障的系统
|
||||
|
||||
## The Correct Approach
|
||||
- [[Alex Ewerlöf]] 主张：将 LLM 视为分布式系统中不可靠的组件
|
||||
- 构建系统时：约束（Constrained）、验证（Verified）、修剪（Pruned）、挑战（Challenged）
|
||||
- 不需要"关心"的 AI，需要的是经过工程保障的 AI
|
||||
|
||||
## Related Concepts
|
||||
- [[泰勒主义软件工厂]]
|
||||
- [[LLM不可靠性]]
|
||||
- [[多Agent可靠性模式]]
|
||||
|
||||
## Sources
|
||||
- [[The-Picture-They-Paint-of-You.md]]
|
||||
- [[Multi-Agent-System-Reliability.md]]
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: ai-voice
|
||||
title: "AI配音"
|
||||
type: concept
|
||||
tags: [TTS, voice, audio]
|
||||
sources:
|
||||
- "[[AI配音与声音克隆工具合集]]"
|
||||
last_updated: 2025-03-06
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AI配音是文本转语音（TTS）技术，将文字内容转化为自然语音。
|
||||
|
||||
## Key Technologies
|
||||
|
||||
- **TTS**：Text-to-Speech，文字转语音
|
||||
- **声音克隆**：用少量样本重建个人声音
|
||||
|
||||
## Popular Tools
|
||||
|
||||
| 平台 | 特点 | 价格 |
|
||||
|------|------|------|
|
||||
| ElevenLabs | 国际顶流，30+语言，情感变化 | 付费较贵 |
|
||||
| 海螺AI | 小白友好，30秒克隆，中文好 | 免费 |
|
||||
| F5-TTS | 开源免费，2秒克隆，技术流 | 免费 |
|
||||
| TTSMaker | 每周3万字，50+语言，300+音色 | 免费限额 |
|
||||
| 剪映 | 抖音官方，短视频首选 | 部分VIP |
|
||||
| AnyVoice | 3秒克隆，中英日韩 | 免费无限 |
|
||||
|
||||
## Connections
|
||||
- [[二创视频]] ← uses ← [[AI配音]]
|
||||
- [[内容创作]] ← uses ← [[AI配音]]
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: agent
|
||||
title: "Agent"
|
||||
type: concept
|
||||
tags: [AI, autonomous, tool-use]
|
||||
sources:
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Agent（智能体）是LLM+MCP的组合，LLM负责给出步骤，MCP负责实际执行。
|
||||
|
||||
## How It Works
|
||||
|
||||
1. LLM理解用户意图
|
||||
2. LLM规划执行步骤
|
||||
3. MCP调用外部工具执行
|
||||
4. 结果反馈给LLM
|
||||
5. LLM继续下一步或返回结果
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- 自主决策
|
||||
- 工具调用
|
||||
- 任务分解
|
||||
- 迭代优化
|
||||
|
||||
## vs Vanilla LLM
|
||||
|
||||
| 维度 | Vanilla LLM | Agent |
|
||||
|------|-------------|-------|
|
||||
| 能力 | 仅生成文本 | 执行实际操作 |
|
||||
| 工具调用 | 无 | 有 |
|
||||
| 自主性 | 低 | 高 |
|
||||
| 幻觉风险 | 高 | 低（可验证） |
|
||||
|
||||
## Connections
|
||||
- [[Agent]] ← combines ← [[LLM]] + [[MCP]]
|
||||
- [[Agent]] ← extends ← [[LLM]]
|
||||
- [[Agent]] ← uses ← [[工具调用]]
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: agent-skill-design-pattern
|
||||
title: "AgentSkill设计模式"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: [Google-5个Agent-Skill设计模式.md]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# AgentSkill设计模式
|
||||
|
||||
将领域知识或工作流有效封装进Skill的五种设计模式，Google与Anthropic经验总结。
|
||||
|
||||
## 五种模式
|
||||
|
||||
| 模式 | 核心机制 | 适用场景 |
|
||||
|------|----------|----------|
|
||||
| [[ToolWrapper]] | 按需动态加载知识文档 | 编码规范、框架最佳实践 |
|
||||
| [[Generator]] | 模板+变量填充生成一致输出 | API文档、报告生成 |
|
||||
| [[Reviewer]] | 检查标准与执行逻辑分离 | 代码审查、安全审计 |
|
||||
| [[Inversion]] | 先问再做，延迟执行 | 需求分析、项目规划 |
|
||||
| [[Pipeline]] | 硬性检查点强制顺序执行 | 复杂流水线、质量控制 |
|
||||
|
||||
## 核心问题
|
||||
|
||||
SKILL.md格式标准化后（已被30+主流工具支持），同等格式的skill执行效果天差地别。差距在于**内容设计**，而非格式。
|
||||
|
||||
## 模式组合
|
||||
|
||||
五种模式并非互斥，可以组合使用：
|
||||
- Pipeline末尾可加Reviewer进行double-check
|
||||
- Generator开始可用Inversion收集必要变量
|
||||
- Reviewer可嵌入Pipeline作为质量关卡
|
||||
|
||||
## 理论基础
|
||||
|
||||
- [[Anthropic]]经验：最好的Skill是「工具箱」，不是大prompt；三条铁律：只写Agent不知道的、重点写踩坑清单、给工具不给指令
|
||||
- [[Google]]ADK：SkillToolset和渐进式披露机制，agent只在运行时需要时才消耗上下文token加载特定模式
|
||||
|
||||
## 与AgenticAI关系
|
||||
|
||||
[[AgenticAI]]的发展使得Skill设计从"写好提示词"转向"设计好工作流结构"。五种模式将[[AgenticAI]]的能力通过结构化Skill封装为可复用模块。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[AgentSkill]]：Skill的实例化
|
||||
- [[AgenticAI]]：Agent具备自主行动能力
|
||||
- [[工作流自动化]]：Pipeline模式的技术基础
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: agentic-ai
|
||||
title: "Agentic AI"
|
||||
type: concept
|
||||
tags: [AI, agent, autonomous, proactive]
|
||||
sources:
|
||||
- "[[Designing for Agentic AI]]"
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Agentic AI是能够自主行动和决策的AI系统，能够预判用户需求并主动执行任务。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **主动预判**：不需要用户明确指令，主动分析并行动
|
||||
- **实时反馈**：持续向用户展示决策过程
|
||||
- **用户控制**：确保用户对AI行为有最终决定权
|
||||
- **行动执行**：不仅生成内容，而是执行具体操作
|
||||
|
||||
## Five Design Principles
|
||||
|
||||
1. **透明性**：让用户理解AI的决策过程
|
||||
2. **控制权**：用户始终保持对AI行为的最终决定权
|
||||
3. **个性化**：AI适应用户的偏好和习惯
|
||||
4. **对话**：通过自然语言进行持续交互
|
||||
5. **预判**：AI主动识别并满足用户潜在需求
|
||||
|
||||
## vs GenAI
|
||||
|
||||
| 维度 | GenAI | Agentic AI |
|
||||
|------|-------|------------|
|
||||
| 核心能力 | 内容生成 | 行动执行 |
|
||||
| 交互模式 | 被动响应 | 主动预判 |
|
||||
| 反馈机制 | 单次响应 | 实时反馈 |
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← extends ← [[GenAI]]
|
||||
- [[AI产品设计]] ← uses ← [[Agentic AI设计原则]]
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: "Agent模式"
|
||||
type: concept
|
||||
tags: [interaction-mode, ai-agent, cursor]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Agent mode
|
||||
- 代理模式
|
||||
|
||||
## Summary
|
||||
Agent 模式是 [[Cursor]] 中 Composer 模块的一种交互状态。与需要用户手动复制执行命令的 Normal 模式不同，Agent 模式能够让 AI 模型自动运行内置的工具命令并处理返回结果，极大地提升了自动化任务的执行效率。配合 `enable yolo mode` 可以跳过二次确认（但具有一定风险）。
|
||||
|
||||
## Key Connections
|
||||
- [[Agent模式]] → enables → [[SequentialThinking]]
|
||||
- [[Agent模式]] 存在于 [[Cursor]] 的 Composer 中
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
id: claude-skills
|
||||
title: "Claude Skills"
|
||||
type: concept
|
||||
tags: [Anthropic, Claude, skill, SOP]
|
||||
sources:
|
||||
- "[[Claude Skills最值得研究的AI范式]]"
|
||||
last_updated: 2026-01-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Claude Skills是Anthropic官方发布的AI技能指南，本质是写给Claude的"说明书"和"SOP"。
|
||||
|
||||
## What It Contains
|
||||
|
||||
- Prompt结构定义
|
||||
- 参数含义说明
|
||||
- 容错策略
|
||||
- 使用示例
|
||||
|
||||
## Official Skills Categories
|
||||
|
||||
- 办公自动化四大件（Word/PDF/PPT/Excel）
|
||||
- 开发者工具箱
|
||||
- 创意类Skill
|
||||
|
||||
## Awesome Claude Skills
|
||||
|
||||
三大社区仓库：
|
||||
- ComposioHQ
|
||||
- VoltAgent
|
||||
- BehiSecc
|
||||
|
||||
## Skills聚合站
|
||||
|
||||
- skillsmp.com
|
||||
- aitmpl.com/skills
|
||||
- claudemarketplaces.com
|
||||
|
||||
## Significance
|
||||
|
||||
Skills的爆发标志着从**提示词工程**到**流程工程**的关键转变：
|
||||
- 将经验沉淀为SOP
|
||||
- 交给AI稳定执行
|
||||
- 实现可复用的工作流
|
||||
|
||||
## Connection to Vibe Coding
|
||||
|
||||
Vibe Coding的尽头也是Skills，通过AI编程方式构建的流程最终需要Skills来标准化和复用。
|
||||
|
||||
## Connections
|
||||
- [[提示词工程]] ← evolves_to ← [[流程工程]]
|
||||
- [[Claude Skills]] ← implements ← [[SOP标准化]]
|
||||
- [[Vibe Coding]] ← uses ← [[Claude Skills]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: embedding
|
||||
title: "Embedding"
|
||||
type: concept
|
||||
tags: [LLM, vector, representation]
|
||||
sources:
|
||||
- "[[RAG从入门到精通系列1：基础RAG]]"
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Embedding（向量化）是将文本转换为数值向量的技术，使计算机能够计算词与词之间的距离和语义关系。
|
||||
|
||||
## Mechanism
|
||||
|
||||
- 将文本映射到高维向量空间
|
||||
- 语义相似的文本在向量空间中距离更近
|
||||
- 支持相似度搜索和聚类分析
|
||||
|
||||
## Use Cases
|
||||
|
||||
- RAG系统的文档索引
|
||||
- 语义搜索
|
||||
- 文本相似度比较
|
||||
- 推荐系统
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[Embedding]]
|
||||
- [[RAG]] ← uses ← [[Embedding]]
|
||||
- [[向量数据库]] ← stores ← [[Embedding]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: genai
|
||||
title: "GenAI"
|
||||
type: concept
|
||||
tags: [AI, generation, content-creation]
|
||||
sources:
|
||||
- "[[Designing for Agentic AI]]"
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
GenAI（生成式AI）擅长创作内容，如文本、图像、代码、音乐等。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- 内容生成能力强
|
||||
- 被动响应用户请求
|
||||
- 适合创意类任务
|
||||
|
||||
## vs Agentic AI
|
||||
|
||||
| 维度 | GenAI | Agentic AI |
|
||||
|------|-------|------------|
|
||||
| 核心能力 | 内容生成 | 行动执行 |
|
||||
| 交互模式 | 被动响应 | 主动预判 |
|
||||
| 代表任务 | 写作、绘画 | 自动化工作流 |
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← evolves_from ← [[GenAI]]
|
||||
- [[AI产品设计]] ← uses ← [[GenAI]]
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: generator
|
||||
title: "Generator"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Generator
|
||||
|
||||
通过模板和变量填充流程，从用户需求生成结构化、一致性输出的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Generator模式利用预定义的输出模板和样式指南，由Agent扮演项目经理角色，通过"收集缺失变量→填充模板→输出结果"的流程，保证每次运行生成格式完全一致的文档或代码。
|
||||
|
||||
## 机制
|
||||
|
||||
- assets/目录存放输出模板
|
||||
- references/目录存放样式指南
|
||||
- SKILL.md作为协调器，指导Agent加载模板、读取指南、收集变量、填充内容
|
||||
- 变量未齐全时，Agent主动向用户询问
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 统一API文档生成
|
||||
- 标准化commit信息格式
|
||||
- 项目脚手架初始化
|
||||
- 报告/简报批量生成
|
||||
|
||||
## 优点
|
||||
|
||||
- 输出格式完全一致可预期
|
||||
- 模板与内容分离，便于更新样式
|
||||
- 变量收集机制确保信息完整
|
||||
|
||||
## 缺点
|
||||
|
||||
- 模板维护成本较高
|
||||
- 变量收集可能增加交互轮次
|
||||
- 不适合高度创造性任务
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Inversion]]（用Inversion收集变量）
|
||||
- 可组合：[[Reviewer]]（用Reviewer检查输出）
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: inversion
|
||||
title: "Inversion"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Inversion
|
||||
|
||||
将Agent工作流从"先做后问"反转为"先问再做"的Skill设计模式。Agent变为面试官，通过阶段性提问收集必要信息后才会开始执行。
|
||||
|
||||
## 定义
|
||||
|
||||
Inversion模式通过硬性门控指令（gate）控制工作流：明确规定"不到所有阶段完成就不开始构建"。Agent逐阶段提问，等待用户回答，确认后才进入下一阶段，最终才执行核心任务。
|
||||
|
||||
## 机制
|
||||
|
||||
- 硬性门控指令：不到所有阶段完成就不开始构建
|
||||
- 阶段化提问：Agent按阶段逐一提问
|
||||
- 等待确认：每个阶段需用户明确回答后才进入下一阶段
|
||||
- 延迟执行：收集完所有必要信息后才执行实际操作
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 项目规划（收集需求、约束、优先级）
|
||||
- 需求分析（功能范围、技术栈、时间线）
|
||||
- 决策咨询（收集选项、偏好、限制条件）
|
||||
- 内容创作（主题、受众、风格偏好）
|
||||
|
||||
## 优点
|
||||
|
||||
- 确保执行前信息完整
|
||||
- 用户参与度高，减少返工
|
||||
- 避免Agent盲目猜测导致浪费
|
||||
|
||||
## 缺点
|
||||
|
||||
- 初始交互轮次多，用户可能不耐烦
|
||||
- 问题设计需要精心规划
|
||||
- 不适合紧急/简单任务
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Generator]]（用Inversion收集Generator所需的变量）
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: llm
|
||||
title: "LLM"
|
||||
type: concept
|
||||
tags: [AI, language-model, foundation-model]
|
||||
sources:
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
LLM（Large Language Model，大语言模型）是参数规模≥1B的深度学习模型，能够理解和生成人类语言。
|
||||
|
||||
## Core Properties
|
||||
|
||||
- **参数规模**：通常≥10亿参数
|
||||
- **语言理解**：能够理解复杂语义
|
||||
- **文本生成**：能够生成连贯、合法的文本
|
||||
- **上下文学习**：能从少量示例中学习
|
||||
|
||||
## Key Metrics
|
||||
|
||||
- **Token**：基本输入单元
|
||||
- 1英文字符 ≈ 0.3 token
|
||||
- 1中文字符 ≈ 0.6 token
|
||||
- **Context Window**：模型能接受的上下文长度
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Token]]：LLM的基本输入单元
|
||||
- [[MCP]]：LLM与外部工具的连接协议
|
||||
- [[Agent]]：LLM+MCP的智能体
|
||||
- [[RAG]]：扩展LLM能力的技术
|
||||
- [[Embedding]]：LLM理解文本的基础
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[Token]]
|
||||
- [[LLM]] ← uses ← [[MCP]]
|
||||
- [[Agent]] ← combines ← [[LLM]] + [[MCP]]
|
||||
- [[RAG]] ← extends ← [[LLM]]
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: mcp
|
||||
title: "MCP"
|
||||
type: concept
|
||||
tags: [AI, protocol, tool-integration]
|
||||
sources:
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
MCP（Model Context Protocol，模型上下文协议）是一种标准化接口，用于连接大模型与外部数据和工具。
|
||||
|
||||
## Purpose
|
||||
|
||||
解决LLM无法访问实时数据和外部工具的问题：
|
||||
- LLM给出执行步骤
|
||||
- 实际执行需要配合MCP
|
||||
- 实现智能体（Agent）功能
|
||||
|
||||
## Architecture
|
||||
|
||||
- **Client**：运行在AI应用端
|
||||
- **Server**：运行在外部服务或本地
|
||||
|
||||
## Use Cases
|
||||
|
||||
- 文件系统访问
|
||||
- API调用
|
||||
- 数据库查询
|
||||
- 代码执行
|
||||
|
||||
## Connection to Agent
|
||||
|
||||
Agent = LLM + MCP
|
||||
- LLM负责理解和规划
|
||||
- MCP负责执行具体操作
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[MCP]]
|
||||
- [[Agent]] ← combines ← [[LLM]] + [[MCP]]
|
||||
- [[MCP]] ← enables ← [[工具调用]]
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
id: pipeline
|
||||
title: "Pipeline"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Pipeline
|
||||
|
||||
在复杂任务中设置硬性检查点，强制Agent按严格顺序执行工作流的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Pipeline模式通过实现明确的门控条件，确保Agent无法跳过步骤或忽略指令。每个关键节点设置检查点，用户必须在进入下一步之前确认，否则流程不会继续。
|
||||
|
||||
## 机制
|
||||
|
||||
- 工作流步骤明确定义在SKILL.md中
|
||||
- 每步有明确的进入前置条件
|
||||
- 门控条件未满足时阻止进入下一步
|
||||
- 文档流水线示例：解析清点→生成文档字符串→组装文档→质量检查
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 复杂多步骤任务（文档生成流水线）
|
||||
- 需要严格质量控制的流程
|
||||
- 合规/审计要求不能跳过的步骤
|
||||
- 多人协作中需要明确交接点
|
||||
|
||||
## 优点
|
||||
|
||||
- 步骤不会被跳过
|
||||
- 质量控制点明确
|
||||
- 流程可追溯可审计
|
||||
- 减少因跳过步骤导致的错误
|
||||
|
||||
## 缺点
|
||||
|
||||
- 灵活性低，急救场景不适用
|
||||
- 用户可能觉得检查点过多
|
||||
- 流程僵化，难以适应特殊情况
|
||||
|
||||
## 与Inversion对比
|
||||
|
||||
| 维度 | Pipeline | Inversion |
|
||||
|------|----------|-----------|
|
||||
| 方向 | 强制顺序执行 | 先问再做 |
|
||||
| 控制点 | 技术门控（条件判断） | 问答门控（收集信息） |
|
||||
| 适用场景 | 复杂技术流程 | 需求分析决策 |
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Reviewer]]（Pipeline末尾加Reviewer步骤）
|
||||
- 示例应用：[[文档流水线]]
|
||||
|
||||
## 相关实体
|
||||
|
||||
- [[Google]]：发布Pipeline模式的云服务提供商
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
id: prompt-ability
|
||||
title: "Prompt能力"
|
||||
type: concept
|
||||
tags: [prompt-engineering, communication]
|
||||
sources:
|
||||
- "[[如何写出完美的Prompt]]"
|
||||
last_updated: 2025-12-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Prompt能力是清晰界定需求+结构化思维表达的能力，本质是需求拆解+结构化表达能力。
|
||||
|
||||
## Core Elements
|
||||
|
||||
人与AI的协作协议，定义：
|
||||
- **做什么**：明确任务目标
|
||||
- **为什么**：任务背景和目的
|
||||
- **给谁**：目标受众
|
||||
- **怎么做**：执行方式和约束
|
||||
- **做到什么标准**：质量要求和验收标准
|
||||
|
||||
## Four Key Elements
|
||||
|
||||
1. **角色**：AI扮演的身份
|
||||
2. **受众对齐**：明确目标用户
|
||||
3. **场景对齐**：使用环境上下文
|
||||
4. **目标对齐**：预期成果定义
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- 越复杂越专业
|
||||
- 说清做什么就行
|
||||
- 一键生成即终点
|
||||
|
||||
## Connections
|
||||
- [[AI协作]] ← requires ← [[Prompt能力]]
|
||||
- [[结构化思维]] ← enables ← [[Prompt能力]]
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: rag
|
||||
title: "RAG"
|
||||
type: concept
|
||||
tags: [LLM, retrieval, augmentation]
|
||||
sources:
|
||||
- "[[RAG从入门到精通系列1：基础RAG]]"
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
RAG（Retrieval Augmented Generation，检索增强生成）是一种结合检索系统和LLM生成的技术，解决LLM缺乏最新和私有数据的问题。
|
||||
|
||||
## Three-Step Process
|
||||
|
||||
1. **索引（Indexing）**：将文档切分并转换为Embedding向量存入向量数据库
|
||||
2. **检索（Retrieval）**：根据问题语义向量检索相关文档块
|
||||
3. **生成（Generation）**：将问题和相关文档输入LLM生成答案
|
||||
|
||||
## Key Components
|
||||
|
||||
- **Embedding**：将文本转换为数值向量
|
||||
- **向量数据库**：存储和检索向量表示（如Qdrant）
|
||||
- **文档切分**：将长文档分割成符合Embedding窗口的块
|
||||
- **Context Window**：模型能接受的上下文长度限制（512-8192 token）
|
||||
|
||||
## Why It Matters
|
||||
|
||||
解决LLM的幻觉问题，让模型能够：
|
||||
- 访问最新信息
|
||||
- 利用私有数据
|
||||
- 提供可溯源的回答
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[RAG]]
|
||||
- [[RAG]] ← includes ← [[索引]]
|
||||
- [[RAG]] ← includes ← [[检索]]
|
||||
- [[RAG]] ← includes ← [[生成]]
|
||||
- [[RAG]] ← extends ← [[LLM]]
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
id: reviewer
|
||||
title: "Reviewer"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Reviewer
|
||||
|
||||
将"检查什么"（审查标准）与"怎么检查"（执行逻辑）完全分离的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Reviewer模式将审查规则与执行机制解耦：审查标准存放于references/review-checklist.md，可替换为Python风格检查、安全审计、数据质量检查等；执行逻辑保持静态，Agent动态加载对应审查标准并输出结构化结果。
|
||||
|
||||
## 机制
|
||||
|
||||
- references/目录存放可替换的审查清单
|
||||
- SKILL.md定义静态审查指令
|
||||
- Agent动态加载特定审查标准
|
||||
- 输出按严重程度分组的结构化结果
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 代码审查（Python风格、PEP8等）
|
||||
- 安全审计（OWASP Top 10等）
|
||||
- 文档质量检查
|
||||
- 数据质量验证
|
||||
|
||||
## 优点
|
||||
|
||||
- 一套skill基础设施，换清单即换专项
|
||||
- 审查标准独立维护，便于更新
|
||||
- 结构化输出便于后续处理
|
||||
|
||||
## 缺点
|
||||
|
||||
- 清单设计需要领域专业知识
|
||||
- 多标准并存时可能冲突
|
||||
- 动态加载机制增加复杂度
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Pipeline]]（Pipeline末尾加Reviewer double-check）
|
||||
- 审查清单类型：[[代码审查]]、[[安全审计]]
|
||||
|
||||
## 相关实体
|
||||
|
||||
- [[Anthropic]]：Reviewer模式被用于Claude Code代码审查Skill
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: "SSE"
|
||||
type: concept
|
||||
tags: [protocol, integration]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Server-Sent Events
|
||||
- SSE连接
|
||||
|
||||
## Summary
|
||||
SSE (Server-Sent Events) 是一种服务器向客户端单向推送实时事件的技术。在 [[MCP]] 的生态中，SSE 是除命令行 (Command) 之外的另一种服务端接入方式，允许客户端实时监听服务端发出的数据和状态更新。
|
||||
|
||||
## Key Connections
|
||||
- [[SSE]] 是接入 [[MCP]] 的两种主要方式之一
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "SequentialThinking"
|
||||
type: concept
|
||||
tags: [reasoning, ai-capability]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- 序列化思考
|
||||
- Sequential Thinking
|
||||
- 步骤化推理
|
||||
|
||||
## Summary
|
||||
Sequential Thinking 是一种优化大语言模型（LLM）逻辑推理过程的机制或工具。它通过将复杂的任务分步拆解，并允许与外部服务（例如通过 [[MCP]] 集成的新闻源）互相调用，从而显著提升 AI 在面对复杂环境时的思考深度和响应准确率。
|
||||
|
||||
## Key Connections
|
||||
- [[SequentialThinking]] ← depends_on ← [[Agent模式]]
|
||||
- [[SequentialThinking]] 配合 [[MCP]] 使用提升能力
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: source-grounding
|
||||
title: "Source-Grounding"
|
||||
type: concept
|
||||
tags: [NotebookLM, accuracy, grounding]
|
||||
sources:
|
||||
- "[[7 ways I use NotebookLM to make my life easier]]"
|
||||
last_updated: 2025-11-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Source-Grounding是NotebookLM的核心机制，限制知识库仅包含用户上传的文档，确保AI回答准确且可溯源。
|
||||
|
||||
## Mechanism
|
||||
|
||||
- 用户上传文档后，NotebookLM只在这个文档范围内回答
|
||||
- 避免AI幻觉，确保回答有据可查
|
||||
- 每个回答都附带源文档引用
|
||||
|
||||
## Why It Matters
|
||||
|
||||
解决通用LLM的幻觉问题，特别适用于：
|
||||
- 法律文档审查
|
||||
- 学术研究
|
||||
- 精确信息查询
|
||||
|
||||
## Connections
|
||||
- [[NotebookLM]] ← uses ← [[Source-Grounding]]
|
||||
- [[AI准确性]] ← requires ← [[Source-Grounding]]
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: token
|
||||
title: "Token"
|
||||
type: concept
|
||||
tags: [LLM, tokenization, input-unit]
|
||||
sources:
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Token是大模型的基本输入单元，是文本处理的最小单位。
|
||||
|
||||
## Tokenization Rules
|
||||
|
||||
- 1英文字符 ≈ 0.3 token
|
||||
- 1中文字符 ≈ 0.6 token
|
||||
- 标点符号和空格也占用token
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- 影响API调用成本
|
||||
- 决定上下文长度限制
|
||||
- 影响生成速度
|
||||
|
||||
## Context Window
|
||||
|
||||
模型能接受的token数量限制：
|
||||
- 较短的模型：4K-8K tokens
|
||||
- 中等模型：32K-128K tokens
|
||||
- 长上下文模型：1M+ tokens
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[Token]]
|
||||
- [[Token]] → affects → [[成本计算]]
|
||||
- [[Token]] → affects → [[上下文限制]]
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: tool-wrapper
|
||||
title: "ToolWrapper"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# ToolWrapper
|
||||
|
||||
将某个库或框架的规范文档打包成skill的包装模式。Agent只有在真正用到该技术时才会动态加载相关文档（references/目录），而非将所有规则塞入system prompt。
|
||||
|
||||
## 定义
|
||||
|
||||
ToolWrapper是一种Skill设计模式，核心机制是**按需加载**——将领域知识、编码规范、最佳实践封装为可触发的文档模块，仅在Agent检测到相关关键词时激活对应知识。
|
||||
|
||||
## 机制
|
||||
|
||||
- references/目录存放具体技术文档（如conventions.md）
|
||||
- SKILL.md监听特定关键词或事件
|
||||
- 当用户开始使用某技术时，动态加载对应规范
|
||||
- 规范被Agent当作"绝对真理"执行
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 团队内部编码规范分发
|
||||
- 特定框架最佳实践封装
|
||||
- 减少system prompt信息过载
|
||||
- 需要精确控制规范版本和加载时机
|
||||
|
||||
## 优点
|
||||
|
||||
- 按需加载，不浪费上下文token
|
||||
- 规范独立，便于单独更新维护
|
||||
- Agent只在需要时才加载，避免干扰
|
||||
|
||||
## 缺点
|
||||
|
||||
- 需要预先识别和封装所有相关知识
|
||||
- 关键词触发机制可能遗漏边界情况
|
||||
- 多skill并发时可能有加载冲突
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 并列模式：[[Generator]]、[[Reviewer]]、[[Inversion]]、[[Pipeline]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: vibe-coding
|
||||
title: "Vibe Coding"
|
||||
type: concept
|
||||
tags: [AI, programming, coding]
|
||||
sources:
|
||||
- "[[Claude Skills最值得研究的AI范式]]"
|
||||
last_updated: 2026-01-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Vibe Coding是一种AI编程方式，通过自然语言与AI协作编写代码。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- 自然语言为主
|
||||
- AI生成代码
|
||||
- 人类审核和调整
|
||||
- 降低编程门槛
|
||||
|
||||
## The End State
|
||||
|
||||
Vibe Coding的尽头是Skills：
|
||||
- 通过对话构建的代码和流程
|
||||
- 需要标准化为Skills以便复用
|
||||
- 最终沉淀为可维护的系统
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← uses ← [[Claude Skills]]
|
||||
- [[AI编程]] ← extends ← [[Vibe Coding]]
|
||||
- [[提示词工程]] ← relates_to ← [[Vibe Coding]]
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: "Workspace"
|
||||
type: concept
|
||||
tags: [openclaw, workspace, configuration]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# Workspace
|
||||
|
||||
OpenClaw中Agent的工作台目录，决定Agent如何工作。
|
||||
|
||||
## 核心文件
|
||||
|
||||
### AGENTS.md
|
||||
定义Agent的：
|
||||
- 岗位职责
|
||||
- 行为边界
|
||||
- 多Agent协调规则
|
||||
|
||||
### SOUL.md
|
||||
定义Agent的：
|
||||
- 性格叙事
|
||||
- 沟通风格
|
||||
- 价值观和边界
|
||||
|
||||
### USER.md
|
||||
固化用户的：
|
||||
- 偏好设定
|
||||
- 背景知识假设
|
||||
- 常见任务
|
||||
|
||||
### TOOLS.md
|
||||
声明工具的：
|
||||
- 可用工具
|
||||
- 使用原则
|
||||
- 受限工具
|
||||
|
||||
### IDENTITY.md
|
||||
结构化身份档案：
|
||||
- 名字
|
||||
- 角色类型
|
||||
- Emoji
|
||||
- 头像
|
||||
|
||||
### BOOTSTRAP.md
|
||||
一次性启动引导，完成后应删除。
|
||||
|
||||
### memory/
|
||||
长期记忆目录：
|
||||
- 按日期滚动的记忆笔记
|
||||
- 实现跨会话上下文保留
|
||||
|
||||
## 配置要点
|
||||
|
||||
1. **边界比能力更重要**：明确"不要做什么"
|
||||
2. **场景触发优于通用指令**：具体场景下的具体规则
|
||||
3. **简洁有效**：300-500字的AGENTS.md比2000字的更有效
|
||||
|
||||
## 与openclaw.json的关系
|
||||
- Workspace文件：管"Agent平时怎么干活"
|
||||
- openclaw.json：管"系统怎么跑Agent"
|
||||
|
||||
## 相关概念
|
||||
- [[OpenClaw]]
|
||||
- [[AGENTS.md]]
|
||||
- [[SOUL.md]]
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "YouTube RSS"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
通过 YouTube 频道的 channel_id 拼接的 Atom/RSS 订阅格式，允许用户通过 RSS 阅读器订阅频道更新。YouTube 已移除官方 RSS 订阅按钮，需通过"查看页面源码"获取 channel_id。
|
||||
|
||||
## How to Get
|
||||
1. 访问 YouTube 频道页面（如 https://www.youtube.com/@CHANNEL_NAME）
|
||||
2. 右键 → "查看页面源码"（View Page Source）
|
||||
3. 搜索 "channel_id="
|
||||
4. 拼接 RSS URL：https://www.youtube.com/feeds/videos.xml?channel_id=<CHANNEL_ID>
|
||||
|
||||
## Why It Matters
|
||||
- YouTube 移除 RSS 按钮以迫使用户访问网站（商业动机）
|
||||
- RSS 是获取频道更新的无平台锁定方式
|
||||
|
||||
## Related Tools
|
||||
- 任意 RSS 阅读器（如 Feedly、Inoreader 等）
|
||||
|
||||
## Sources
|
||||
- [[YouTube-RSS-Feed.md]]
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
id: vllm
|
||||
title: "vLLM"
|
||||
type: concept
|
||||
tags: [LLM, inference, GPU, optimization]
|
||||
sources:
|
||||
- "[[LLM Terms Framework]]"
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
vLLM是一个高效LLM推理框架，通过KV Cache和连续批处理提升GPU利用率。
|
||||
|
||||
## Key Optimizations
|
||||
|
||||
### KV Cache
|
||||
- 缓存已计算的Key-Value矩阵
|
||||
- 避免重复计算
|
||||
- 大幅提升推理速度
|
||||
|
||||
### Continuous Batching
|
||||
- 动态批处理多个请求
|
||||
- 提高GPU利用率
|
||||
- 降低延迟
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- 官方HuggingFace推理速度慢
|
||||
- vLLM可提升10-24倍速度
|
||||
- 支持高并发推理
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← uses ← [[vLLM]]
|
||||
- [[推理优化]] ← uses ← [[vLLM]]
|
||||
- [[GPU利用率]] ← improves ← [[vLLM]]
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
id: nine-grid
|
||||
title: "九宫格法"
|
||||
type: concept
|
||||
tags: [video, AI, image-generation]
|
||||
sources:
|
||||
- "[[固定镜头短视频AI全流程制作]]"
|
||||
last_updated: 2025-03-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
九宫格法是一次性生成3x3共九个分镜画面的方法，确保多个镜头之间的画面一致性。
|
||||
|
||||
## Mechanism
|
||||
|
||||
1. 将视频分割为9个分镜
|
||||
2. 一次性生成3x3网格图像
|
||||
3. 每个格子是一个分镜的关键帧
|
||||
4. 确保人物/场景在多个格子中保持一致
|
||||
|
||||
## Why It Works
|
||||
|
||||
- AI在单张图像内保持一致性更容易
|
||||
- 避免逐帧生成导致的人物变形
|
||||
- 提高多镜头视频的整体质量
|
||||
|
||||
## Five-Step Formula
|
||||
|
||||
1. 拆分镜头
|
||||
2. 一致性图像生成（九宫格法）
|
||||
3. 首尾针动画
|
||||
4. 快速剪辑
|
||||
5. 声音设计
|
||||
|
||||
## Connections
|
||||
- [[AI视频制作]] ← uses ← [[九宫格法]]
|
||||
- [[分镜设计]] ← uses ← [[九宫格法]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
title: "共识投票"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
多智能体系统中 N 个独立 LLM 对同一任务生成答案，取出现最频繁的结果作为最终输出的模式。核心机制是利用 LLM 随机性，让不同运行的噪声相互抵消。
|
||||
|
||||
## Mathematical Basis
|
||||
- 假设单模型幻觉率 = 20%（P_hallucination = 0.2）
|
||||
- N 个模型同时产生相同幻觉的概率 = P_hallucination^N
|
||||
- N = 3 时：0.2³ = 0.008 = 0.8%
|
||||
- 该公式与 SRE 中的 composite SLO 原理相同
|
||||
|
||||
## Implementation
|
||||
1. Spawn N LLMs（N 需要在成本和可靠性之间找到平衡）
|
||||
2. Fan out：给所有模型分配完全相同的任务
|
||||
3. Fan in：选取出现最频繁的答案
|
||||
|
||||
## Diversity Requirement
|
||||
- 各 Agent 最好使用不同模型（同质化噪声会放大而非抵消）
|
||||
- 确保参与者之间无反馈回路（防止群体思维和从众效应）
|
||||
- 实验应像盲测一样运行
|
||||
|
||||
## Best For
|
||||
- 事实核查
|
||||
- 分类任务（如"这是垃圾邮件吗？"）
|
||||
|
||||
## Sources
|
||||
- [[Multi-Agent-System-Reliability.md]]
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: fixed-camera
|
||||
title: "固定机位"
|
||||
type: concept
|
||||
tags: [video-production, cinematography]
|
||||
sources:
|
||||
- "[[固定镜头短视频AI全流程制作]]"
|
||||
last_updated: 2025-03-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
固定机位是摄像机位置固定不变的拍摄方式，是固定镜头短视频的核心特征。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- 摄像机位置不变
|
||||
- 只有画面内容变化
|
||||
- 适合展示时间流逝
|
||||
- 便于AI生成一致性画面
|
||||
|
||||
## Use Cases
|
||||
|
||||
- 家装视频
|
||||
- 产品展示
|
||||
- 教程演示
|
||||
- 时间压缩视频
|
||||
|
||||
## Connection to AI Video
|
||||
|
||||
固定机位降低AI视频生成的复杂度，通过：
|
||||
- 九宫格法保证画面一致性
|
||||
- 首尾针动画实现平滑过渡
|
||||
|
||||
## Connections
|
||||
- [[AI视频制作]] ← uses ← [[固定机位]]
|
||||
- [[短视频制作]] ← uses ← [[固定机位]]
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: "固定点语义"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
在递归自我优化生成系统中，稳定的生成能力对应于元生成算子 Φ 的不动点 G*，满足 Φ(G*) = G*。该生成器在自身的"生成→优化→更新"循环下保持不变。
|
||||
|
||||
## Core Properties
|
||||
- 不动点定义：G* ∈ G，满足 Φ(G*) = G*
|
||||
- 收敛条件：Φ 满足连续性或收缩性条件时，可通过迭代获得：G* = lim(n→∞) Φⁿ(G₀)
|
||||
- 自洽性：不动点的输出已编码其自身改进所需的标准
|
||||
|
||||
## Related Concepts
|
||||
- [[自举Meta生成]]：通过不动点实现递归自我优化的过程
|
||||
- [[生成器空间]]：Φ 作用的空间
|
||||
|
||||
## Sources
|
||||
- [[A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: voice-cloning
|
||||
title: "声音克隆"
|
||||
type: concept
|
||||
tags: [TTS, voice, cloning]
|
||||
sources:
|
||||
- "[[AI配音与声音克隆工具合集]]"
|
||||
last_updated: 2025-03-06
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
声音克隆是用少量音频样本重建个人声音特征的技术。
|
||||
|
||||
## How It Works
|
||||
|
||||
1. 收集目标声音的短音频（2-30秒）
|
||||
2. 提取声音特征
|
||||
3. 生成新的语音内容
|
||||
|
||||
## Speed Comparison
|
||||
|
||||
| 工具 | 克隆速度 | 技术门槛 |
|
||||
|------|----------|----------|
|
||||
| F5-TTS | 2秒 | 高（需代码） |
|
||||
| 海螺AI | 30秒 | 低 |
|
||||
| AnyVoice | 3秒 | 低 |
|
||||
| ElevenLabs | 30秒 | 低 |
|
||||
|
||||
## Connections
|
||||
- [[AI配音]] ← uses ← [[声音克隆]]
|
||||
- [[内容创作]] ← uses ← [[声音克隆]]
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "多Agent可靠性模式"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
多智能体系统中用于克服 LLM 不可靠性（幻觉、逻辑谬误、上下文漂移）的四大架构模式：层级结构、共识、 adversarial debate 和淘汰制。
|
||||
|
||||
## Four Patterns
|
||||
|
||||
### 1. 层级结构（Hierarchy）
|
||||
- **角色**：Planner（规划器）+ Worker（工作者）+ Validator（验证器）
|
||||
- **依赖图强制协作**：Worker 必须等待 Planner 分配任务，且无法作弊（Validator 会发现）
|
||||
- **适用场景**：需要将上下文分开的复杂工作流程
|
||||
|
||||
### 2. 共识（Consensus / Voting）
|
||||
- **机制**：N 个 LLM 独立生成同一任务答案，取多数票
|
||||
- **数学基础**：3 个模型同时产生相同幻觉的概率 = 0.2³ = 0.8%（假设单模型幻觉率 20%）
|
||||
- **适用场景**：事实核查、分类任务
|
||||
|
||||
### 3. 对抗辩论（Adversarial Debate）
|
||||
- **角色**：Generator → Critic（反对） → Judge（裁决）
|
||||
- **机制**：Truth survives the fight，真理越辩越明
|
||||
- **适用场景**：安全分析、代码审查、高风险内容审核
|
||||
|
||||
### 4. 淘汰制（Knock-out）
|
||||
- **类比**：SRE 中服务器是"cattle"（可替换）而非"pets"（独一无二）
|
||||
- **机制**：N 个 Agent 执行任务，最差者被淘汰；可选择用获胜者特征替换已淘汰者
|
||||
- **适用场景**：迭代式 Agent 工程、开发调试
|
||||
|
||||
## Core Insight
|
||||
> "Stop treating LLMs like magic chatbots. Start treating them like unreliable components in a distributed system."
|
||||
|
||||
## Related Concepts
|
||||
- [[LLM不可靠性]]
|
||||
- [[验证器模式]]
|
||||
- [[共识投票]]
|
||||
- [[AI拟人化谬误]]
|
||||
|
||||
## Sources
|
||||
- [[Multi-Agent-System-Reliability.md]]
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "多Agent系统"
|
||||
type: concept
|
||||
tags: [multi-agent, collaboration, agent]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# 多Agent系统
|
||||
|
||||
多个专业Agent协同工作的架构模式，每个Agent有独特的角色和职责。
|
||||
|
||||
## 核心模式
|
||||
|
||||
### 分散式协调
|
||||
通过共享STATE.yaml文件协调，而非中央orchestrator：
|
||||
- Agent读写共享状态文件
|
||||
- 多子Agent并行工作
|
||||
- 主会话保持精简（CEO模式）
|
||||
|
||||
### STATE.yaml
|
||||
项目协调文件，作为单一事实来源：
|
||||
```yaml
|
||||
project: website-redesign
|
||||
tasks:
|
||||
- id: homepage-hero
|
||||
status: in_progress
|
||||
owner: pm-frontend
|
||||
```
|
||||
|
||||
### 团队配置示例
|
||||
- [[Milo]]：策略Lead
|
||||
- [[Josh]]：商业分析
|
||||
- Marketing Agent：营销研究
|
||||
- Dev Agent：开发
|
||||
|
||||
## 关键优势
|
||||
|
||||
1. **专业化分工**：每个Agent专注特定领域
|
||||
2. **并行执行**：多任务同时处理
|
||||
3. **可扩展性**：新增Agent无需修改主逻辑
|
||||
4. **共享记忆**：团队成员共享项目上下文
|
||||
|
||||
## 协作机制
|
||||
|
||||
- **Telegram路由**：通过标签分配到不同Agent
|
||||
- **共享内存**：项目文档、目标、决策
|
||||
- **私有上下文**：每个Agent独有会话历史
|
||||
- **定时任务**：Agent主动工作
|
||||
|
||||
## Race Condition处理
|
||||
|
||||
当多个Agent编辑同一文件时：
|
||||
1. AUTONOMOUS.md：仅主会话编辑
|
||||
2. memory/tasks-log.md：仅追加，子Agent只添加新行
|
||||
|
||||
## 使用场景
|
||||
|
||||
- [[多Agent专业团队]]
|
||||
- [[多Agent内容工厂]]
|
||||
- [[自主项目管理]]
|
||||
- [[动态仪表板]]
|
||||
|
||||
## 相关链接
|
||||
- [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
title: "工作流自动化"
|
||||
type: concept
|
||||
tags: [automation, workflow, n8n]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# 工作流自动化
|
||||
|
||||
使用工具自动执行重复性任务，减少人工干预。
|
||||
|
||||
## 核心概念
|
||||
|
||||
### 工作流（Workflow）
|
||||
由多个任务节点按一定顺序执行的自动化流程。
|
||||
|
||||
### 节点（Node）
|
||||
工作流中的单个操作单元：
|
||||
- 触发器：启动工作流
|
||||
- 动作：执行具体操作
|
||||
- 工具：辅助功能
|
||||
- 代码：自定义逻辑
|
||||
- AI节点：嵌入AI能力
|
||||
|
||||
## 与AI Agent的关系
|
||||
|
||||
- **Workflow**：预定义自动化，一致输出
|
||||
- **Agent**：基于LLM动态决定工具和输出
|
||||
- **Agentic系统**：结合两者优势
|
||||
|
||||
## 平台
|
||||
|
||||
### N8N
|
||||
- 可视化拖拽界面
|
||||
- 400+预构建集成
|
||||
- 支持自托管
|
||||
|
||||
### OpenClaw
|
||||
- 通过skill扩展能力
|
||||
- 自然语言配置
|
||||
- 记忆和上下文保留
|
||||
|
||||
## 安全集成模式
|
||||
|
||||
[[OpenClaw + n8n工作流编排]]：
|
||||
- Webhook调用n8n
|
||||
- 凭证隔离在n8n
|
||||
- 工作流可锁定
|
||||
|
||||
## 使用场景
|
||||
|
||||
- [[会议纪要自动化]]
|
||||
- [[邮件管理自动化]]
|
||||
- [[日历聚合]]
|
||||
- [[社交媒体自动化]]
|
||||
|
||||
## 相关链接
|
||||
- [N8N官网](https://n8n.io/)
|
||||
- [OpenClaw文档](https://docs.openclaw.ai)
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: chain-of-thought
|
||||
title: "思维链引导"
|
||||
type: concept
|
||||
tags: [prompt-engineering, reasoning]
|
||||
sources:
|
||||
- "[[如何写出完美的Prompt]]"
|
||||
last_updated: 2025-12-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
思维链引导是一种提示词技术，让AI逐步推理而非直接给出答案。
|
||||
|
||||
## Mechanism
|
||||
|
||||
通过在提示词中要求AI展示推理过程：
|
||||
- 先分析问题
|
||||
- 再列出步骤
|
||||
- 最后给出答案
|
||||
|
||||
## Benefits
|
||||
|
||||
- 提高AI推理准确性
|
||||
- 减少幻觉发生
|
||||
- 让用户理解决策过程
|
||||
- 便于发现AI思维漏洞
|
||||
|
||||
## Connections
|
||||
- [[Prompt能力]] ← uses ← [[思维链引导]]
|
||||
- [[需求拆解]] ← extends ← [[思维链引导]]
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "技能系统"
|
||||
type: concept
|
||||
tags: [skill, openclaw, extension]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# 技能系统
|
||||
|
||||
OpenClaw的扩展机制，通过技能包添加新能力。
|
||||
|
||||
## 技能结构
|
||||
|
||||
```
|
||||
skills/
|
||||
├── skill-name/
|
||||
│ └── SKILL.md
|
||||
```
|
||||
|
||||
## 常用技能
|
||||
|
||||
### 集成技能
|
||||
- [[Telegram]]：消息通道
|
||||
- [[Discord]]：协作平台
|
||||
- [[Slack]]：团队通讯
|
||||
|
||||
### 数据技能
|
||||
- [[YouTube]]：视频内容获取
|
||||
- [[Reddit]]：社区内容聚合
|
||||
- [[GitHub]]：代码和项目数据
|
||||
|
||||
### 工具技能
|
||||
- [[arxiv-reader]]：学术论文读取
|
||||
- [[latex-compiler]]：LaTeX编译
|
||||
- [[youtube-full]]：YouTube完整集成
|
||||
|
||||
### MCP技能
|
||||
- [[n8n-mcp]]：N8N节点访问
|
||||
- [[idea-reality-mcp]]：创意验证
|
||||
|
||||
## 技能安装
|
||||
|
||||
通过ClawHub安装：
|
||||
```bash
|
||||
npx clawhub@latest install skill-name
|
||||
```
|
||||
|
||||
或通过OpenClaw：
|
||||
```text
|
||||
Install the youtube-full skill
|
||||
```
|
||||
|
||||
## 技能开发
|
||||
|
||||
技能是包含SKILL.md的目录，定义：
|
||||
- 工具列表
|
||||
- 使用方法
|
||||
- 配置要求
|
||||
|
||||
## 使用场景
|
||||
|
||||
详见各use case中的"Skills you Need"部分。
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: prompt-framework
|
||||
title: "提示词框架"
|
||||
type: concept
|
||||
tags: [Nano Banana, prompt-engineering, image-generation]
|
||||
sources:
|
||||
- "[[Nano Banana提示词框架]]"
|
||||
last_updated: 2025-03-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
提示词框架是结构化描述图像生成需求的模板，通过标准化字段确保生成质量可控。
|
||||
|
||||
## Framework Types
|
||||
|
||||
### 物件描述框架
|
||||
- shot：镜头类型
|
||||
- subject：包含item/materials/details/condition
|
||||
- environment：环境描述
|
||||
- lighting：光线
|
||||
- camera：相机设置
|
||||
- color_grade：色彩分级
|
||||
- style：风格
|
||||
- quality：质量参数
|
||||
- negatives：负面提示
|
||||
|
||||
### 人物描述框架
|
||||
- subject：包含age/appearance/pose等字段
|
||||
|
||||
## Connections
|
||||
- [[AI图像生成]] ← uses ← [[提示词框架]]
|
||||
- [[Nano Banana]] ← supports ← [[提示词框架]]
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: "泰勒主义软件工厂"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
将开发者定位为高层控制者、周围是大量无面孔 Agent 的软件工程架构思维。源自泰勒科学管理思想——将人视为可替换的生产单元，通过标准化流程最大化效率。
|
||||
|
||||
## Core Pattern
|
||||
- 开发者 = 高层控制者（Product Manager / Commander）
|
||||
- Agent = 无面孔、可替换的生产单元（类似于泰勒制中的流水线工人）
|
||||
- 关系 = 控制与执行，而非协作
|
||||
|
||||
## Related Debate
|
||||
- 与 [[Agentic AI]] 的协作型定位（Claude Code、Copilot 等命名伙伴角色）形成鲜明对比
|
||||
- [[AI拟人化谬误]] 提供工具命名和定位如何反映工作价值认知的分析框架
|
||||
|
||||
## Criticism
|
||||
- 简化了开发工作的复杂性和创造性价值
|
||||
- 忽视了开发者作为决策者和创新者的角色
|
||||
- [[Ferdinand]] 指出这种框架缺乏对工作的尊重
|
||||
|
||||
## Related Concepts
|
||||
- [[AI拟人化谬误]]
|
||||
- [[Agentic AI]]
|
||||
- [[多Agent系统]]
|
||||
|
||||
## Sources
|
||||
- [[The-Picture-They-Paint-of-You.md]]
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
id: workflow-engineering
|
||||
title: "流程工程"
|
||||
type: concept
|
||||
tags: [AI, workflow, SOP, engineering]
|
||||
sources:
|
||||
- "[[Claude Skills最值得研究的AI范式]]"
|
||||
last_updated: 2026-01-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
流程工程是将重复任务拆解为AI能理解、稳定复用的流程，并通过Skills实现标准化的工程化方法。
|
||||
|
||||
## vs 提示词工程
|
||||
|
||||
| 维度 | 提示词工程 | 流程工程 |
|
||||
|------|------------|----------|
|
||||
| 核心 | 单次Prompt优化 | 全流程标准化 |
|
||||
| 稳定性 | 依赖模型表现 | SOP固化 |
|
||||
| 复用性 | 低 | 高 |
|
||||
| 目标 | 一次好结果 | 稳定可重复 |
|
||||
|
||||
## Key Elements
|
||||
|
||||
- **SOP标准化**：将经验沉淀为操作步骤
|
||||
- **Skills封装**：AI技能的模块化
|
||||
- **自动化执行**：交给AI稳定运行
|
||||
- **反馈迭代**：持续优化流程
|
||||
|
||||
## Connections
|
||||
- [[提示词工程]] ← evolves_to ← [[流程工程]]
|
||||
- [[Claude Skills]] ← implements ← [[流程工程]]
|
||||
- [[SOP标准化]] ← enables ← [[流程工程]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: structured-expression
|
||||
title: "结构化表达"
|
||||
type: concept
|
||||
tags: [prompt-engineering, communication]
|
||||
sources:
|
||||
- "[[如何写出完美的Prompt]]"
|
||||
last_updated: 2025-12-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
结构化表达是用清晰逻辑组织信息的方法，确保AI准确理解人类意图。
|
||||
|
||||
## Principles
|
||||
|
||||
- 层次分明：按重要性和逻辑顺序组织
|
||||
- 格式统一：使用一致的标记和分隔符
|
||||
- 信息完整：不遗漏关键上下文
|
||||
- 表达精准：避免歧义和模糊表述
|
||||
|
||||
## Techniques
|
||||
|
||||
- 使用编号列表组织要点
|
||||
- 使用标题区分不同部分
|
||||
- 使用表格呈现结构化数据
|
||||
- 使用引用标记重要信息
|
||||
|
||||
## Connections
|
||||
- [[Prompt能力]] ← enables ← [[结构化表达]]
|
||||
- [[结构化思维]] ← implements ← [[结构化表达]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "自举Meta生成"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
通过递归优化循环实现系统自我超越的过程：α-提示词（生成器）和 Ω-提示词（优化器）通过迭代不断优化自身，无限逼近理想状态。
|
||||
|
||||
## Bootstrap Cycle
|
||||
1. **创生（Bootstrap）**：用 AI 生成 α-提示词 和 Ω-提示词 的初始版本 (v1)
|
||||
2. **自省与进化（Self-Correction）**：用 Ω-提示词(v1) 优化 α-提示词(v1)，得到更强的 α-提示词(v2)
|
||||
3. **创造（Generation）**：用进化后的 α-提示词(v2) 生成所有目标提示词和技能
|
||||
4. **循环与飞跃（Recursive Loop）**：将新生成的产物反馈给系统，启动下一轮进化
|
||||
|
||||
## Relationship to Fixed Points
|
||||
- 稳定生成能力 = Φ 的不动点
|
||||
- 递归优化循环 → 逼近不动点
|
||||
- 不动点 = 自举过程的极限状态
|
||||
|
||||
## Related Concepts
|
||||
- [[固定点语义]]：自举过程的稳定状态定义
|
||||
- [[生成器空间]]：α-提示词 和 Ω-提示词 迭代的空间
|
||||
|
||||
## Sources
|
||||
- [[A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md]]
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: "记忆系统"
|
||||
type: concept
|
||||
tags: [memory, openclaw, context]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# 记忆系统
|
||||
|
||||
AI Agent跨会话保留上下文和知识的能力。
|
||||
|
||||
## OpenClaw记忆机制
|
||||
|
||||
### 内置方案（builtin）
|
||||
原始记忆存储在Markdown文件中，系统维护本地索引方便检索。
|
||||
|
||||
### QMD方案
|
||||
围绕workspace中的Markdown文件，使用更强的检索/索引方式。
|
||||
|
||||
### 记忆流程
|
||||
```
|
||||
对话发生
|
||||
↓
|
||||
Agent通过普通文件工具把重要信息写入memory/或MEMORY.md
|
||||
↓
|
||||
下次对话开始
|
||||
↓
|
||||
Agent通过memory_search/memory_get检索相关记忆
|
||||
↓
|
||||
相关记忆被注入到当前对话上下文
|
||||
↓
|
||||
Agent表现出"我记得你说过……"的能力
|
||||
```
|
||||
|
||||
## 向量语义搜索
|
||||
|
||||
[[Semantic Memory Search]]使用memsearch：
|
||||
- 索引Markdown记忆文件到向量数据库
|
||||
- 通过含义搜索而非关键词
|
||||
- SHA-256内容哈希避免重复嵌入
|
||||
|
||||
## Workspace记忆文件
|
||||
|
||||
- [[memory/]]：按日期滚动的记忆笔记
|
||||
- [[MEMORY.md]]：长期知识总表
|
||||
- 与memory/目录兼容
|
||||
|
||||
## 关键洞察
|
||||
|
||||
- 对Agent来说，真正算数的长期记忆是Markdown文件
|
||||
- 向量索引只是派生缓存，可以随时重建
|
||||
- 文件永不修改
|
||||
|
||||
## 使用场景
|
||||
|
||||
- [[第二大脑]]
|
||||
- [[个人CRM]]
|
||||
- [[健康症状追踪]]
|
||||
|
||||
## 相关工具
|
||||
|
||||
- [[memsearch]]：向量语义搜索工具
|
||||
- [[Milvus]]：向量数据库后端
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
id: requirement-decomposition
|
||||
title: "需求拆解"
|
||||
type: concept
|
||||
tags: [prompt-engineering, structured-thinking]
|
||||
sources:
|
||||
- "[[如何写出完美的Prompt]]"
|
||||
last_updated: 2025-12-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
需求拆解是将模糊目标转化为具体可执行子任务的过程。
|
||||
|
||||
## Methods
|
||||
|
||||
### 基础方法
|
||||
- **需求拆解法**：将复杂任务分解为简单步骤
|
||||
- **上下文补全法**：补充背景信息让AI理解场景
|
||||
- **格式定义法**：明确输出格式要求
|
||||
- **示例引导法**：提供参考案例
|
||||
|
||||
### 进阶策略
|
||||
- **思维链引导**：让AI逐步推理
|
||||
- **任务拆分**：大任务分解为子任务
|
||||
- **角色赋能**：赋予AI特定专业角色
|
||||
- **预填回复**：提供初始回答框架
|
||||
|
||||
### 高阶技巧
|
||||
- **跨模态联动**：结合多种输入输出形式
|
||||
- **领域知识注入**：嵌入专业知识
|
||||
- **反馈循环嵌入**：建立迭代优化机制
|
||||
|
||||
## Connections
|
||||
- [[Prompt能力]] ← requires ← [[需求拆解]]
|
||||
- [[结构化表达]] ← enables ← [[需求拆解]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: audio-overview
|
||||
title: "音频概览"
|
||||
type: concept
|
||||
tags: [NotebookLM, learning, podcast]
|
||||
sources:
|
||||
- "[[7 ways I use NotebookLM to make my life easier]]"
|
||||
last_updated: 2025-11-23
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
音频概览是NotebookLM的功能，将文档转化为AI双人播客格式，适合被动学习。
|
||||
|
||||
## Mechanism
|
||||
|
||||
- AI分析文档内容
|
||||
- 生成两个AI声音的对话
|
||||
- 用户可以收听而非阅读
|
||||
|
||||
## Use Cases
|
||||
|
||||
- 通勤时学习
|
||||
- 视觉疲劳时继续学习
|
||||
- 将长文档转化为可听的摘要
|
||||
|
||||
## Connections
|
||||
- [[NotebookLM]] ← implements ← [[音频概览]]
|
||||
- [[被动学习]] ← uses ← [[音频概览]]
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: frame-interpolation
|
||||
title: "首尾针动画"
|
||||
type: concept
|
||||
tags: [video, AI, animation]
|
||||
sources:
|
||||
- "[[固定镜头短视频AI全流程制作]]"
|
||||
last_updated: 2025-03-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
首尾针动画是通过AI自动补齐首尾帧之间中间动作的技术，实现平滑过渡效果。
|
||||
|
||||
## Mechanism
|
||||
|
||||
1. 确定起始帧和结束帧
|
||||
2. AI分析首尾帧的差异
|
||||
3. 自动生成中间过渡帧
|
||||
4. 输出流畅视频
|
||||
|
||||
## Tools
|
||||
|
||||
- 海螺AI
|
||||
- KAI
|
||||
- 其他AI动效工具
|
||||
|
||||
## Connection to Fixed-Camera Video
|
||||
|
||||
固定机位视频天然适合首尾针动画，因为：
|
||||
- 背景固定，减少AI生成负担
|
||||
- 只需关注主体变化
|
||||
- 更容易保持一致性
|
||||
|
||||
## Connections
|
||||
- [[AI视频制作]] ← uses ← [[首尾针动画]]
|
||||
- [[固定机位]] ← enables ← [[首尾针动画]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "验证器模式"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
多智能体系统中 Validator（验证器）检查 Worker 输出质量，不合格则退回的机制。验证器可以是确定性代码（单元测试、JSON Schema 验证）或 LLM 本身。
|
||||
|
||||
## Validation Methods
|
||||
- **确定性代码验证**：单元测试、JSON Schema 验证、正则表达式匹配
|
||||
- **LLM 验证**：单独训练或提示的验证模型判断输出质量
|
||||
- **双模式**：可单独验证每个 Worker 输出，或在汇总所有结果后整体验证
|
||||
|
||||
## Placement in Multi-Agent Patterns
|
||||
- [[层级结构]]（Hierarchy）：Validator 是关键角色，位于 Planner → Worker → Validator 链路的末端
|
||||
- [[淘汰制]]（Knock-out）：Validator 决定哪些 Agent 被淘汰
|
||||
- [[对抗辩论]]（Adversarial Debate）：Watchdog（确定性代码）打破辩论死循环
|
||||
|
||||
## Best Practice
|
||||
- Validator 最好使用与 Generator/Worker 不同的模型（提高质量和客观性）
|
||||
- 验证器可以在同一 LLM 会话中与规划器协作（PLAN → VALIDATION loop）
|
||||
|
||||
## Sources
|
||||
- [[Multi-Agent-System-Reliability.md]]
|
||||
Reference in New Issue
Block a user