Workspace sync: auto commit 2026-04-23 12:02:11

wiki/concepts/AI-Agent.md

@@ -2,7 +2,7 @@
 title: "AI Agent"
 type: concept
 tags: [ai-agent, autonomous, llm]
-last_updated: 2025-04-23
+last_updated: 2026-04-25
 ---
 
 ## Definition
@@ -31,6 +31,7 @@ AI Agent 通过一个连续循环过程实现其目标：
 ## Related Concepts
 - [[Large Language Model]] — Agent 的"大脑"
 - [[RAG]] — Agent 的"记忆"
+- [[Model Context Protocol]] — Agent 连接外部工具的标准协议
 - [[ReAct Pattern]] — Agent 的推理-行动模式
 - [[Agentic AI]] — 具备自主决策能力的 AI 系统
 
@@ -38,3 +39,4 @@ AI Agent 通过一个连续循环过程实现其目标：
 - [[llms-rag-ai-agent-三个到底什么区别]]
 - [[designing-for-agentic-ai]]
 - [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

wiki/concepts/AI开源平替.md

@@ -0,0 +1,36 @@
+---
+title: "AI开源平替"
+type: concept
+tags: [AI, 开源, 替代方案]
+last_updated: 2026-04-24
+---
+
+## Definition
+**AI开源平替**是指以 GitHub 等平台上的开源项目替代闭源商业 AI 产品，通过本地部署或自托管降低使用成本，同时实现数据隐私保护。
+
+## Core Categories（来源：[[2025-年-11-个神级-ai-开源平替-github-杀疯了]]）
+
+| 领域 | 闭源标杆 | 开源平替 | 代表项目 |
+|------|---------|---------|---------|
+| 大语言模型 | OpenAI GPT、Claude | DeepSeek、Qwen | DeepSeek R1/V3、Qwen 3 |
+| AI 生图 | Midjourney V7 | Flux、Stable Diffusion | Flux（人体解剖最正确）、SD 3.5（LoRA 生态最丰富） |
+| AI 生视频 | Google Veo 3 | HunyuanVideo | 腾讯混元视频，参数量最大 |
+| AI 智能体 | Manus | OpenManus | 规划→执行→反馈 |
+| AI 编码 | Cursor | Cline | VS Code 最强自主编程插件 |
+| 工作流自动化 | Zapier | n8n、Dify | n8n（16 万 Star）、Dify（LLM 应用平台） |
+| AI 搜索 | Perplexity | Perplexica | SearXNG+本地模型 |
+| AI 知识库 | NotebookLM | OpenNotebook、SurfSense | 文档问答+播客生成 |
+
+## Key Principles
+- 开源平替 ≠ 100% 等价替代，需根据具体场景评估效果
+- 本地部署可实现完全数据隐私，无需担心被大公司"炼丹"
+- 开源社区迭代速度快，部分领域已实现弯道超车（如 DeepSeek R1 对标 o1）
+
+## Related Concepts
+- [[AI Agent]] — AI 智能体领域
+- [[DeepSeek]] — 国产开源 LLM 代表
+- [[n8n]] — 开源工作流自动化
+- [[Perplexica]] — AI 搜索开源方案
+
+## Sources
+- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]

wiki/concepts/Adversarial-Debate-Pattern.md

@@ -0,0 +1,33 @@
+---
+title: "Adversarial Debate Pattern"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Adversarial Debate Pattern
+
+## 定义
+多智能体系统的对抗式辩论模式——一个Agent提出方案，另一个Agent攻击反驳，由第三个Agent（裁判）决定胜负。核心是用外部批评者和评判者模拟人类的"恐惧"动机。
+
+## 角色
+- **Generator**："Here is my plan."（生成方案）
+- **Critic**："Here are 3 reasons why that plan sucks."（扮演魔鬼代言人）
+- **Judge**："The Critic is right. Fix it."（裁判/主持人）
+
+## 核心洞察
+LLM是"Yes-Men"，一旦开始写作很少自我纠正——需要一个指定的反对者来打破这种惯性。
+
+## 关键机制
+- 三方应使用**不同模型**（不同训练/微调/提示），多样性有益
+- 顺序执行+循环特性导致速度可能非常慢
+- Agent可能陷入无限辩论——可使用**Watchdog**（确定性代码）在时间/次数超阈值时打破循环
+
+## 适用场景
+- 安全分析（Security Analysis）
+- 代码审查（Code Review）
+- 高风险内容审核（High-Stakes Content Moderation）
+
+## 来源
+- [[multi-agent-system-reliability]]

wiki/concepts/Consensus-Voting-Pattern.md

@@ -0,0 +1,37 @@
+---
+title: "Consensus Voting Pattern"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Consensus Voting Pattern
+
+## 定义
+多智能体系统的共识投票模式——将同一任务分配给N个LLM，选取出现次数最多的答案作为最终结果。
+
+## 核心公式
+若单个模型幻觉概率为 P，则N个模型同时幻觉相同谎言的概率为 P^N。
+- 示例：P=0.2（20%幻觉率），N=3 → 0.2³ = 0.008（0.8%）
+
+## 核心机制
+1. **Spawn N LLMs**：N需要通过试验找到成本与可靠性的平衡点
+2. **Fan out work**：给所有Agent完全相同的任务
+3. **Fan in results**：选取最常见的答案
+
+## 关键要求
+- Agent之间**无反馈回路**，否则群体思维（Groupthink）和从众效应会扭曲结果
+- 理想情况下各Agent使用不同模型，降低思维同质化风险
+- 实验应像盲测一样进行
+
+## 适用场景
+- 事实核查（Fact-checking）
+- 分类任务（如"这是垃圾邮件吗？"）
+
+## 缺点
+成本高——本质上是将同一任务分配给多个Agent，ROI需根据任务和失败成本计算。
+
+## 来源
+- [[multi-agent-system-reliability]]
+- [[Composite SLO]]（概率公式类比）

wiki/concepts/Context-Window.md

@@ -1,21 +1,32 @@
 ---
 title: "Context Window"
 type: concept
-last_updated: 2026-04-10
+tags: [llm, context-window, token, embedding, rag]
+last_updated: 2025-01-16
 ---
 
 ## Definition
-模型的 Context Window 是指单次 API 请求能处理的最大 token 数量（包括输入 prompt + 历史对话 + 输出 response）。超过这个上限就会触发"Context Limit Exceeded"错误。
+Context Window（上下文窗口）是 LLM 或 Embedding Model 一次性处理的最大 token 数量。超过该限制的内容无法被模型感知，必须切分或截断。
 
-## Key Facts
-- **DeepSeek-reasoner**: 16K tokens context window
-- **MiniMax-M2.7**: 200K tokens context window
-- 16K context 模型配合 OpenClaw safeguard 模式预留 16K tokens = 实际可用 0 tokens
+## Key Numbers
+- **Embedding Model**：通常 512~8192 token（如 BAAI/bge 系列）
+- **LLM**：差异极大，从 4K（GPT-3.5）到 200K+（Claude 3）不等
 
-## Related
-- [[Compaction]]: OpenClaw 通过上下文压缩管理 token 消耗
-- [[Model-Fallback]]: 模型切换的触发机制
-- [[Agent-Routing-Rules]]: Telegram channel 绑定特定模型的方式
+## Practical Impact
+### 对 Embedding Model
+- 决定单次可 Embedding 的最大文本长度
+- 超过则需 Split（切分文档）
 
-## Sources
-- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]
+### 对 LLM（Generation 阶段）
+- 决定用户问题 + 检索上下文 + 系统 Prompt 的总 token 预算
+- 超过则需截断（可能丢失关键信息）
+
+## Token Estimation
+- **英文**：1 token ≈ 3~4 个字母
+- **中文**：1 token ≈ 1 个汉字
+
+## Related Concepts
+- [[Split]] — 文档需要切分以满足 Context Window 约束
+- [[Embedding]] — Embedding Model 的 Context Window 限制
+- [[Token]] — Context Window 的计量单位
+- [[Generation]] — LLM 的 Context Window 决定最终可输入的上下文量

wiki/concepts/Coze-Workflow.md

@@ -0,0 +1,28 @@
+---
+title: "Coze Workflow"
+type: concept
+tags: [ai-agent, workflow, coze]
+last_updated: 2026-04-23
+---
+
+## Summary
+Coze（扣子）平台的工作流编排能力，允许用户通过可视化界面将多个 Bot 和插件串联，实现复杂业务流程的自动化执行。与传统的单 Bot 对话相比，Workflow 支持条件分支、循环、变量传递等编程逻辑，适用于需要多步骤处理的业务场景。
+
+## Core Features
+- **可视化编排**：拖拽式节点编辑器，无需编程基础
+- **多 Bot 串联**：将多个专业 Bot 按顺序或并行组合
+- **插件集成**：调用天气、地图、数据库、代码执行等外部工具
+- **条件分支**：根据变量值执行不同路径
+- **变量管理**：在节点间传递和转换数据
+- **输出定制**：控制最终输出的格式和内容
+
+## Use Cases (from Coze Training)
+- **滴滴计费解答_WorkFlow**：将计费规则问答 Agent 串联进业务流程
+- **骑手招聘助手_WorkFlow**：招聘场景的多步骤自动化处理
+- **SONY店员_WorkFlow**：零售门店场景的 AI 客服工作流
+
+## Relationship to General Workflow Engineering
+属于 [[Workflow-Engineering]] 在 Coze 平台的具体实现。与 [[n8n]] 的工作流自动化属同一方法论的不同工具平台——Coze 侧重 AI Agent 编排，n8n 侧重通用 API 连接与自动化。
+
+## Source
+- [[AI 解决方案专家培训课程]]

wiki/concepts/Generation.md

@@ -0,0 +1,33 @@
+---
+title: "Generation"
+type: concept
+tags: [rag, generation, llm, prompt, reasoning]
+last_updated: 2025-01-16
+---
+
+## Definition
+Generation（生成阶段）是 RAG Pipeline 的第三步，将用户问题与 Retrieval 阶段检索到的相关文档块组合为 Prompt，输入 LLM 生成最终答案。
+
+## Process
+1. **Context Assembly**：将用户问题（Question）与 Top-k 个相关文档块（Context）放入字典结构：`{"question": ..., "context": ...}`
+2. **Prompt Templating**：通过 PromptTemplate 将 Question 和 Context 组合为结构化的 Prompt String
+3. **LLM Inference**：将 Prompt 输入 LLM，LLM 严格基于上下文中提供的信息生成答案
+4. **Output Parsing**：从 LLM 输出中提取纯字符串结果
+
+## Key Requirements for Generation
+- **Source Grounding**：LLM 必须严格基于检索到的上下文生成，不能凭空发挥
+- **Answer Attribution**：理想情况下应提供答案的来源引用（哪些文档块支持该答案）
+
+## In RAG Pipeline
+- **上游**：接收 Retrieval 阶段返回的文档块作为上下文
+- **下游**：输出最终答案给用户
+
+## Frameworks Simplify This
+LangChain 和 LlamaIndex 将 Retrieval + Generation 封装为 RAG Chain（如 RetrievalQA Chain），只需几行代码即可完成端到端 Pipeline。
+
+## Related Concepts
+- [[RAG]] — Generation 是 RAG Pipeline 的第三阶段
+- [[Retrieval]] — Generation 的上游，提供上下文
+- [[PromptTemplate]] — 组装 Question + Context 的模板技术
+- [[Chain]] — LangChain 中串联 Retrieval 和 Generation 的抽象
+- [[Large Language Model]] — 实际执行生成任务的模型

wiki/concepts/Genetic-Algorithm.md

@@ -0,0 +1,23 @@
+---
+title: "Genetic Algorithm"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Genetic Algorithm
+
+## 定义
+遗传算法——传统机器学习中基于自然选择和遗传机制的优化算法，是[[Tree-of-Thoughts]]和[[Knock-out-Pattern]]的ML理论根源。
+
+## 核心要素
+1. **遗传表示**（Genetic Representation）：解决方案域的编码（模型+上下文）
+2. **适应度函数**（Fitness Function）：评估解决方案质量的函数（淘汰赛裁判）
+
+## 在多智能体系统中的应用
+- [[Knock-out-Pattern]]是遗传算法的精简实现——将适应度函数替换为验证器（Validator）
+- [[Tree-of-Thoughts]]通过验证器持续筛选Agent分支，可结合赢家的特征重组生成新Agent
+
+## 来源
+- [[multi-agent-system-reliability]]

wiki/concepts/Hierarchy-Agent-Pattern.md

@@ -0,0 +1,34 @@
+---
+title: "Hierarchy Agent Pattern"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Hierarchy Agent Pattern
+
+## 定义
+多智能体系统的等级制度模式——由一个主管模型（Supervisor/Planner）制定计划、分解任务、分配工作给专业工作代理（Worker），再由验证代理（Validator）检验结果的质量。
+
+## 核心机制
+- **Planner**：智能模型（如 Opus）将用户目标分解为原子化小步骤
+- **Worker**：专门化智能体（通常用更小更快的模型），专注于单一任务
+- **Validator**：检查点——工作不合格则退回；可用确定性代码（单元测试/JSON schema）或LLM本身
+
+## 为什么有效
+依赖图强制协作——Worker必须等Planner分配任务才能开始，且无法作弊（会被Validator发现）。
+
+## 适用场景
+需要将上下文分开的复杂工作流（如不让"撰稿人"看到"研究员"的原始日志）。
+
+## 优点
+- 任务分解清晰，可独立验证每个步骤
+- 支持上下文隔离
+
+## 缺点
+- 顺序执行（Planner→Worker→Validator），速度慢、成本高
+- Validator建议使用与Planner/Worker不同的模型以提高客观性
+
+## 来源
+- [[multi-agent-system-reliability]]

wiki/concepts/Indexing.md

@@ -0,0 +1,29 @@
+---
+title: "Indexing"
+type: concept
+tags: [rag, indexing, document-processing, embedding]
+last_updated: 2025-01-16
+---
+
+## Definition
+Indexing（索引阶段）是 RAG Pipeline 的第一步，负责将外部文档转化为可检索的向量表示：文档加载 → 文本切分 → 向量化 → 存入向量数据库。
+
+## Process
+1. **Document Loading**：从多种来源（网页/PDF/数据库/API 等）加载原始文档
+2. **Text Splitting**：将长文档切分为满足 Embedding Model Context Window 的文本片段（Split）
+3. **Embedding**：使用 Embedding Model 将每个 Split 转化为固定长度的语义向量
+4. **Storage**：将向量 + 原始文本块存入 Vector Store（向量数据库）
+
+## Why Splitting is Necessary
+Embedding Model 的 Context Window 有限（通常 512~8192 token），无法直接处理整篇长文档，因此必须切分。切分策略直接影响检索质量——过小则语义不完整，过大则引入噪声。
+
+## In RAG Pipeline
+- **前置阶段**：Indexing 的输出（向量数据库）是 Retrieval 阶段的输入
+- **工具支撑**：LangChain 的 DocumentLoader、TextSplitter、Embedding、VectorStore 组件封装了全流程
+
+## Related Concepts
+- [[RAG]] — Indexing 是 RAG Pipeline 的第一阶段
+- [[Split]] — 切分后的文档片段
+- [[Embedding]] — 向量化的技术
+- [[Vector Store]] — 存储向量的数据库
+- [[Retrieval]] — Indexing 的下一阶段

wiki/concepts/Knock-out-Pattern.md

@@ -0,0 +1,36 @@
+---
+---
+title: "Knock-out Pattern"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Knock-out Pattern
+
+## 定义
+多智能体系统的淘汰制模式——将任务分配给N个Agent，用验证器决定哪些表现最差的被淘汰。核心是用"适者生存"替代LLM不存在的"死亡恐惧"。
+
+## 核心机制
+1. 将任务分配给N个Agent
+2. 用Validator决定要淘汰哪些Agent
+3. （可选）用通过验证的Agent特征组合创建新Agent填补空缺
+
+## ML渊源
+这是传统机器学习中[[Genetic-Algorithm]]（遗传算法）的精简实现，依赖两个要素：
+- **遗传表示**：解决方案域（模型+上下文）
+- **适应度函数**：淘汰决策依据
+
+## 关键要求
+需要**快速验证输出的方式**（如单元测试）——如果需要人工检查所有分支，成本太高。Eval是必要基础设施。
+
+## 适用场景
+迭代式智能体工程——主要用于开发/调试阶段，不适合生产环境的高用户负载。
+
+## 与Tree of Thoughts的关系
+Tree of Thoughts是Knock-out模式的进阶实现，通过验证器持续筛选。
+
+## 来源
+- [[multi-agent-system-reliability]]
+- [[Genetic-Algorithm]]

wiki/concepts/LangChain.md

@@ -0,0 +1,37 @@
+---
+title: "LangChain"
+type: concept
+tags: [llm, framework, agent, development]
+sources: [大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]
+last_updated: 2026-04-25
+---
+
+# LangChain
+
+## Definition
+
+LangChain 是一个快速实现 AI Agent 的开发框架，提供了标准接口，用于：
+- 将不同的 LLM 连接在一起
+- 与其他工具和数据源的集成
+
+LangChain 降低了构建基于 LLM 的应用程序的开发门槛，提供了链式调用（Chain）、代理（Agent）、记忆（Memory）等抽象，使开发者能够快速组装复杂的 LLM 应用。
+
+## Relationship to MCP
+
+LangChain 和 [[Model Context Protocol]] 都试图解决"LLM 与外部工具集成"的问题，但层次不同：
+
+- **[[Model Context Protocol]]** 是一个开放协议标准（协议层）
+- **LangChain** 是一个应用开发框架（框架层）
+
+LangChain 可视为 MCP 思想的具体实现之一——在 MCP 出现之前，LangChain 已是 Agent 开发的事实标准。
+
+## Related Concepts
+
+- [[AI Agent]]：LangChain 的核心目标产物
+- [[Prompt]]：LangChain 中 Chain 的基本输入形式
+- [[Model Context Protocol]]：协议层的互补方案
+- [[RAG]]：LangChain 的重要应用场景之一
+
+## Sources
+
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

wiki/concepts/Large-Language-Model.md

@@ -2,7 +2,7 @@
 title: "Large Language Model"
 type: concept
 tags: [llm, ai, nlp]
-last_updated: 2025-04-23
+last_updated: 2026-04-25
 ---
 
 ## Definition
@@ -25,3 +25,4 @@ last_updated: 2025-04-23
 
 ## Sources
 - [[llms-rag-ai-agent-三个到底什么区别]]
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

wiki/concepts/Model-Context-Protocol.md

@@ -0,0 +1,52 @@
+---
+title: "Model Context Protocol"
+type: concept
+tags: [llm, mcp, protocol, tool-calling]
+sources: [大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]
+last_updated: 2026-04-25
+---
+
+# Model Context Protocol (MCP)
+
+## Aliases
+- MCP
+- Model Context Protocol
+- 模型上下文协议
+
+## Definition
+
+Model Context Protocol（MCP，模型上下文协议）是一个开放协议，旨在为 LLM 应用提供**标准化接口**，使其能够连接外部数据源和各种工具进行交互。
+
+MCP 充当 LLM 与外部世界之间的**标准化通信层**：当 LLM 处理用户请求时需要访问外部信息或功能，MCP Client 向 MCP Server 发送请求；MCP Server 负责与相应的外部数据源或工具交互，获取数据并按 MCP 协议规范格式化后返回给 LLM。
+
+## Key Insight
+
+> "大模型是不会自己去调用外部数据源或者工具的，大模型只会告诉我们需要调用哪些工具，而我们需要自己去实现工具的调用。"
+
+MCP 解决的核心问题：**LLM 只能返回"需要调用什么工具和参数"的描述，不能自己执行**。MCP 提供了 LLM 与工具之间的标准桥梁。
+
+## Architecture
+
+```
+User Request
+    ↓
+LLM（分析请求，决定需要哪些工具）
+    ↓
+MCP Client（发送标准化请求）
+    ↓
+MCP Server（与外部数据源/工具交互）
+    ↓
+格式化结果
+    ↓
+LLM（整合结果，生成最终响应）
+```
+
+## Related Concepts
+
+- [[AI Agent]]：LLM + MCP + 工具执行 = 真正自主的 Agent
+- [[Prompt]]：MCP Server 的返回结果作为上下文注入 LLM 的 Prompt
+- [[Large Language Model]]：MCP 扩展了纯 LLM 的能力边界
+
+## Sources
+
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

wiki/concepts/Reliability-Engineering.md

@@ -0,0 +1,31 @@
+---
+title: "Reliability Engineering"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Reliability Engineering
+
+## 定义
+可靠性工程——将LLM视为分布式系统中不可靠组件的工程哲学，而非"有感知"的智能体。
+
+## 核心原则
+停止要求模型"小心"，开始**强制**其正确：
+
+1. **Constrained（约束）**：通过架构约束（如依赖图强制执行）而非提示词约束
+2. **Verified（验证）**：每个步骤有检查点，不合格则退回
+3. **Pruned（修剪）**：淘汰表现最差的Agent
+4. **Challenged（挑战）**：通过对抗辩论让错误暴露
+
+## 核心转变
+从"AI原型"（Prototype AI）到"企业级AI"（Enterprise AI）的范式转变：
+- ❌ 将LLM视为神奇的聊天机器人
+- ✅ 将LLM视为不可靠的分布式组件
+
+## 关键人物
+- [[Alex Ewerlöf]]：可靠性工程专家，KTH系统工程硕士，27年经验，专注将人类系统协作模式迁移至AI架构
+
+## 来源
+- [[multi-agent-system-reliability]]

wiki/concepts/Retrieval.md

@@ -0,0 +1,34 @@
+---
+title: "Retrieval"
+type: concept
+tags: [rag, retrieval, vector-search, similarity]
+last_updated: 2025-01-16
+---
+
+## Definition
+Retrieval（检索阶段）是 RAG Pipeline 的第二步，根据用户问题的语义向量（Embedding Vector），在向量数据库中按相似度找出 Top-k 个最相关的文档块（Split）。
+
+## Process
+1. **Query Embedding**：将用户问题通过同一个 Embedding Model 转化为语义向量
+2. **Vector Search**：在 Vector Store 中按相似度（余弦相似度/点积/欧氏距离）检索最接近的 k 个向量
+3. **Result Selection**：返回对应的原始文本块（Split）作为上下文
+
+## Key Parameters
+- **Top-k（k值）**：决定返回多少个最相关的文档块，k 过小可能遗漏关键信息，k 过大则引入噪声
+- **Similarity Metric**：余弦相似度最常用，适合方向性语义匹配；点积适合归一化向量；欧氏距离适合几何距离度量
+
+## In RAG Pipeline
+- **上游**：依赖 Indexing 阶段构建的向量数据库
+- **下游**：检索结果传递给 Generation 阶段作为上下文
+
+## Challenges
+- **语义鸿沟**：用户问题的措辞与文档中相关内容可能不同（词汇不匹配）
+- **上下文窗口限制**：Top-k 个文档块的总 token 数不能超过 LLM 的 Context Window
+- **噪声召回**：向量相似度高但实际无关的文档块可能被召回
+
+## Related Concepts
+- [[RAG]] — Retrieval 是 RAG Pipeline 的第二阶段
+- [[Vector Store]] — 检索的数据库后端
+- [[Embedding]] — 检索的向量来源
+- [[Generation]] — Retrieval 的下一阶段，接收检索结果作为上下文
+- [[Hybrid Search]] — 结合向量检索与关键词检索以弥补单一向量检索的不足

wiki/concepts/Split.md

@@ -0,0 +1,31 @@
+---
+title: "Split"
+type: concept
+tags: [rag, document-processing, chunking, text-splitting]
+last_updated: 2025-01-16
+---
+
+## Definition
+Split（文档块/文本片段）是 Indexing 阶段将长文档切分后的产物，每个 Split 的 token 数量满足 Embedding Model 的 Context Window 限制，同时尽可能保持语义完整性。
+
+## Why Splitting Matters
+Embedding Model 的 Context Window 有限（通常 512~8192 token），无法直接处理整篇长文档，因此必须切分。切分质量直接影响检索效果：
+
+- **Split 过大**：超过 Context Window 无法处理，即使能处理也引入过多噪声
+- **Split 过小**：语义不完整，检索到的片段无法支撑 LLM 生成准确答案
+- **Split 不重叠**：相邻片段边界处的重要信息可能被切分点切断
+
+## Common Splitting Strategies
+1. **Fixed-size Split**：按固定 token 数切分（简单但可能切断句子）
+2. **Sentence-aware Split**：按句子或段落切分（语义更完整）
+3. **Recursive Split**：递归地按换行符→句子→单词逐级切分（平衡粒度与完整性）
+4. **Semantic Split**：按语义相似度聚类后切分（最理想但实现复杂）
+
+## In RAG Pipeline
+- **Indexing 阶段输出**：每个文档切分为多个 Split，分别 Embedding 后入库
+- **Retrieval 阶段处理**：用户问题检索到的是 Split 粒度的文档块，而非整篇文档
+
+## Related Concepts
+- [[Indexing]] — Split 是 Indexing 阶段的产物
+- [[Embedding]] — 每个 Split 独立进行向量化
+- [[Context Window]] — Split 大小的上限约束

wiki/concepts/Tree-of-Thoughts.md

@@ -0,0 +1,25 @@
+---
+title: "Tree of Thoughts"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-25
+---
+
+# Tree of Thoughts
+
+## 定义
+思维之树——多智能体系统的树形探索模式，是[[Genetic-Algorithm]]（遗传算法）的精简实现。通过验证器决定哪些Agent分支被淘汰，持续筛选直至找到最优解。
+
+## 核心公式
+将任务分配给N个Agent → Validator决定淘汰哪些 → 可选：用通过验证的Agent特征生成新Agent填补空缺
+
+## 关键要求
+- 需要快速验证输出的方式（如Eval/单元测试）
+- 如果需要人工检查所有分支，太慢且容易出错
+
+## 与Knock-out Pattern的关系
+Tree of Thoughts是Knock-out模式的进阶——后者只是淘汰，前者还包括通过验证的Agent特征重组。
+
+## 来源
+- [[multi-agent-system-reliability]]

wiki/concepts/vLLM.md

@@ -0,0 +1,51 @@
+---
+title: "vLLM"
+type: concept
+tags: [llm, inference, gpu, optimization, kv-cache]
+sources: [大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]
+last_updated: 2026-04-25
+---
+
+# vLLM
+
+## Aliases
+- vLLM
+- Virtual Large Language Model
+- 虚拟大语言模型
+
+## Definition
+
+vLLM 是由 **vLLM 社区**维护的开源 LLM 推理框架，旨在通过更好地利用 GPU 内存来加快生成式 AI 应用的输出速度，实现高吞吐、低成本的推理服务。
+
+## Core Mechanisms
+
+### PagedAttention（分块注意力）
+
+传统方法按序列分配一大块连续内存存储 KV Cache，导致显存碎片化和 OOM（内存溢出）。
+
+vLLM 的 PagedAttention 将 KV Cache 切分为固定大小的**块（block）**，用类操作系统的**页表式映射**管理：
+
+- 避免按序列分配连续内存导致的碎片化
+- 支持动态并发与显存复用
+- 在多分支（beam search）和重复前缀场景下复用相同前缀产生的 KV 块，极大减少预填充（prefill）时间
+
+### Continuous Batching（连续批处理）
+
+传统批处理：攒满一批再跑，短任务被长任务阻塞（头阻塞）。
+
+连续批处理：
+- 在每个解码步骤（按 token 迭代）都把活跃请求组装成一个批
+- 序列长度不同也能高效合批
+- GPU 基本满负载运转
+- 基于 PagedAttention 的块式内存 + 步进级调度器，无需等待整批结束即可把新请求插入下一步的批次
+
+## Related Concepts
+
+- [[KV Cache]]：vLLM 优化的核心对象，PagedAttention 将 KV Cache 分块管理
+- [[Large Language Model]]：vLLM 服务的对象
+- [[PagedAttention]]：vLLM 提出的注意力机制
+- [[Continuous Batching]]：vLLM 使用的调度策略
+
+## Sources
+
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

wiki/concepts/九宫格法.md

@@ -0,0 +1,37 @@
+---
+title: "九宫格法"
+type: concept
+tags: ["AI图像生成", "画面一致性", "视频制作"]
+sources: ["固定镜头短视频制作的ai全流程解析"]
+last_updated: 2026-04-23
+---
+
+## 定义
+九宫格法是一种 AI 图像生成的一致性控制方法，通过一次性生成 3×3 共九个画面（在同一张图内），确保所有分镜的摄像机机位、角度、景深、光影完全一致，从而解决逐帧独立生成导致画面风格不一致的问题。
+
+## 核心问题
+逐帧独立生成图片会导致：
+- 光影关系错乱（同一光源在不同帧中方向/强度不一致）
+- 空间关系错乱（物体位置、比例关系变化）
+- 色彩风格不一致（色调、饱和度、明度不统一）
+- 摄像机机位漂移（角度、景深在系列画面中不连贯）
+
+## 九宫格法的工作流程
+1. 在 AI 图像生成工具（如 [[Midjourney]] 或 [[Nano Banana]]）中设计 3×3 网格布局
+2. 一次性输入提示词，同时生成九张连贯的分镜画面
+3. 使用工具（如 [[Google AI Studio]]）自动将九宫格图裁剪为九张独立的竖屏图（9:16 比例）
+4. 将九张独立图片配对，通过 [[首尾针动画]] 技术生成连贯视频片段
+
+## 核心优势
+- **机位固定**：同一张图内，机位和角度天然一致
+- **光影连贯**：同一光源设置贯穿所有分镜
+- **构图统一**：景深、视角保持一致
+- **效率提升**：一次生成九个画面，减少重复调整
+
+## 在 AI 短视频制作流程中的位置
+在 [[固定镜头短视频制作的AI全流程解析]] 中，九宫格法是**第二步（一致性图像生成）**的关键技术：
+1. 拆分镜头 → [[Google AI Studio]]
+2. **一致性图像生成 → 九宫格法**
+3. 首尾针动画制作
+4. 快速剪辑
+5. 声音设计

wiki/concepts/固定机位.md

@@ -0,0 +1,25 @@
+---
+title: "固定机位"
+type: concept
+tags: ["视频制作", "镜头语言", "短视频"]
+sources: ["固定镜头短视频制作的ai全流程解析"]
+last_updated: 2026-04-23
+---
+
+## 定义
+固定机位是指摄像机位置在整个拍摄过程中保持完全不变的一种拍摄方式，不使用任何推、拉、摇、移等镜头运动。
+
+## 核心价值
+- **画面一致性**：摄像机位置固定使所有画面具有天然的空间和光影连贯性
+- **降低设备需求**：无需斯坦尼康、滑轨等复杂摄像设备
+- **AI 友好**：AI 对固定机位视频的时间推移处理表现优异，适合 AI 生成中间过渡帧
+- **内容驱动**：观众注意力完全集中在画面内容变化上，而非镜头语言
+
+## 在 AI 短视频制作中的应用
+在 [[固定镜头短视频制作的AI全流程解析]] 中，固定机位是三大核心关键词之一（另外两个是 [[内容连续变化]] 和 [[时间压缩]]）。固定机位使 [[九宫格法]] 能够一次性生成风格一致的多个画面，避免逐帧独立生成导致的光影错乱问题。
+
+## 适用场景
+- 家装/装修：从毛坯到精装的完整过程
+- 产品制作：食品烹饪、手工制作、园艺等
+- 建筑变化：四季变化、日出日落等
+- 不适合需要丰富镜头语言的叙事性视频

wiki/concepts/首尾针动画.md

@@ -0,0 +1,35 @@
+---
+title: "首尾针动画"
+type: concept
+tags: ["AI视频生成", "动画技术", "短视频制作"]
+sources: ["固定镜头短视频制作的ai全流程解析"]
+last_updated: 2026-04-23
+---
+
+## 定义
+首尾针动画（Keyframe Animation）是一种 AI 视频生成技术，通过上传两个关键帧图片——首针图（Start Frame）和尾针图（End Frame）——让 AI 自动补齐两个阶段之间的中间画面，从而产生连贯流畅的动画效果。
+
+## 技术原理
+1. **上传首尾两张关键图**：首针图定义起点状态，尾针图定义终点状态
+2. **AI 分析两张图之间的变化**：识别主体、背景、光影等元素的差异
+3. **自动生成中间过渡帧**：AI 在两张图之间插值计算，生成平滑过渡的连续画面
+4. **输出连贯视频片段**：最终生成从首针到尾针的完整动画视频
+
+## 在 AI 短视频制作流程中的作用
+在 [[固定镜头短视频制作的AI全流程解析]] 描述的五步公式中，**首尾针动画制作**是第三步：
+1. 拆分镜头（[[Google AI Studio]]）
+2. 一致性图像生成（[[九宫格法]]，[[Midjourney]]/[[Nano Banana]]）
+3. **首尾针动画制作**（海螺AI/KAI/[[KAI]]）
+4. 快速剪辑（[[剪映]]）
+5. 声音设计
+
+## 核心优势
+- **平滑过渡**：AI 自动补齐中间变化，避免手动逐帧制作的繁琐
+- **时间压缩**：将漫长的过程（如装修数月）浓缩为几秒的流畅动画
+- **自然感强**：过渡效果由 AI 智能计算，比硬切更平滑自然
+
+## 支持工具
+- [[海螺AI]]（MiniMax）
+- [[KAI]]
+- 即梦AI（字节跳动）
+- 可灵AI（快手）