漏斗架构

一句话理解

漏斗架构是”摘要 → 全文”的两层信息加载策略：先读摘要（~200-500 tokens）决定是否需要全文，再按需加载完整内容。这个架构是 Context 工程和 Loop 工程的交汇点——Context 工程决定”给什么信息”，Loop 工程决定”何时加载更多信息”。

核心概念

为什么需要漏斗架构

AI Agent 在处理知识库时面临一个核心矛盾：

信息完整性：需要获取足够的信息来做出正确决策
上下文预算：上下文窗口有限，加载所有全文会超出预算

漏斗架构解决这个矛盾：通过摘要层提供”足够判断的信息”，只在必要时加载全文。

两层架构

┌─────────────────────────────────────────┐
│              索引层 (Index)               │
│  文件列表、目录结构、WikiLink 图谱          │
│  Token 消耗: ~100                        │
│  作用: 让 Agent 知道有哪些内容              │
├─────────────────────────────────────────┤
│              摘要层 (Summary)             │
│  每个文件/文件夹的摘要 (~200-500 tokens)    │
│  Token 消耗: ~200-500/文件                │
│  作用: 让 Agent 判断是否需要全文            │
├─────────────────────────────────────────┤
│              全文层 (Full Text)           │
│  完整的文件内容                             │
│  Token 消耗: ~2000-10000/文件             │
│  作用: 提供完整信息                         │
└─────────────────────────────────────────┘

摘要层设计原则

摘要应该包含什么：

内容	说明	示例
一句话概括	文件/章节的核心主题	“本章介绍 PEFT 的三种主要方法”
关键概念列表	涉及的核心概念	“LoRA, Adapter, Prefix Tuning”
适用场景	什么情况下需要读全文	“需要选择 PEFT 方法时阅读”
前置知识	阅读前需要了解什么	“需要先了解 Transformer 架构”
与其他内容的关联	WikiLink 链接	“详见 LoRA（Low-Rank Adaptation）”

摘要不应该包含什么：

过于详细的实现细节（那是全文的责任）
冗长的背景介绍（摘要不是全文的压缩版）
模糊的概括（“本章讨论了一些重要话题”——这句话没有信息量）

全文层设计原则

完整性：全文层包含所有必要的细节
自包含：全文层不依赖摘要层的信息（摘要是全文的”预览”，不是”补充”）
结构化：使用标题、表格、列表组织信息，便于 Agent 快速定位

漏斗架构和 Loop 循环的关系

漏斗架构不是一次性的”加载策略”，而是嵌入在 Loop 循环中的动态过程：

Perceive: Agent 感知到用户提问
    ↓
Think: Agent 推理需要哪些信息来回答
    ↓
Act: Agent 读取相关文件的摘要层（漏斗第一层）
    ↓
Observe: Agent 观察摘要内容，判断哪些文件需要全文
    ↓
Perceive: Agent 感知到"需要文件 A、C 的全文"
    ↓
Think: Agent 推理加载顺序（先文件 A 还是先文件 C）
    ↓
Act: Agent 加载文件 A 的全文（漏斗第二层）
    ↓
Observe: Agent 观察全文内容，判断是否足够回答
    ↓
... 循环继续，直到信息足够

关键点：漏斗架构不是”一次性加载所有摘要”——Agent 在 Loop 中逐步判断、逐步加载，避免一次性消耗过多上下文。

本 Vault 的漏斗架构实现

实现方式

索引层：笔记/、深挖/、对比/ 文件夹结构
摘要层：每个文件夹的 摘要.md
全文层：具体的 .md 笔记文件
导航机制：[[概念-WikiLink]] 链接网络

摘要.md 示例结构

# 笔记文件夹摘要

## 核心主题
- AI 工程核心概念

## 包含内容
- [[概念-MCP+A2A]] - MCP+A2A 双协议生态
- [[概念-FunctionCalling演化]] - Function Calling 演化
- ...

## 适用场景
- 需要理解 AI 工程的核心概念时
- 需要了解 Agent 通信协议时

工作流程

Agent 收到用户问题，先读取相关文件夹的 摘要.md
根据摘要中的 WikiLink，判断哪些笔记与问题相关
加载相关笔记的全文
如果信息不足，回到步骤 1，搜索更多文件夹

和渐进式加载的关系

维度	漏斗架构	渐进式加载
定义	信息分层的静态架构	按需加载的动态策略
关系	提供了”分什么层”	决定了”何时加载哪层”
设计层面	内容组织层面	交互流程层面
核心问题	每层应该包含什么信息	什么时候加载更多信息

类比：漏斗架构是”图书馆的索引卡片系统”，渐进式加载是”读者如何查找和借阅图书的流程”。

什么时候不适合漏斗架构

场景	问题	替代方案
内容极其简短	摘要和全文几乎一样长，摘要没有意义	直接加载全文
高度关联的内容	摘要无法有效表达内容间的关联	使用知识图谱导航
实时对话	用户需要即时回答，无法等待多层加载	预加载+缓存
单一文件	只有一个文件，不需要漏斗	直接加载

漏斗架构的扩展：三层架构

在某些场景下，可以在摘要层和全文层之间增加一个”要点层 (Key Points)”：

层级	Token 消耗	内容
索引层	~100	文件列表
摘要层	~200-500	内容摘要
要点层	~500-1000	关键概念、数据、结论
全文层	~2000-10000	完整内容

要点层适合场景：需要快速获取关键数据但不需要完整上下文时。

来源

Anthropic Context Engineering: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
信息检索中的漏斗模型: https://blog.langchain.dev/context-engineering/
RAG 架构设计: https://arxiv.org/abs/2312.10997
渐进式上下文加载: https://arxiv.org/abs/2402.11550