Context 工程

一句话理解

Context 工程的核心是”让模型看见什么”——不是改模型，而是管理模型的输入。在模型能力固定的前提下，Context 工程决定了模型能获取多少有效信息，从而直接影响输出质量。2026年，随着长上下文窗口（1M+ tokens）的普及，Context 工程策略正在从”信息压缩”转向”信息组织”。

核心概念

上下文窗口 (Context Window)

模型的上下文窗口是它能”看到”的文本总量。这个窗口限制了模型在一次推理中能处理的信息量。

模型	2023年窗口	2024年窗口	2026年窗口
GPT-4 → GPT-5.5	8K / 32K	128K	200K+
Claude → Claude Opus 4.8	100K	200K	200K / 500K
Gemini → Gemini 3.5 Pro	32K	1M	2M
DeepSeek → DeepSeek-V4	—	128K	1M

关键认知：窗口变大不等于信息利用率变高。研究表明，模型对窗口中间位置的注意力较弱（“Lost in the Middle” 问题），对开头和结尾的信息关注度最高。

信息密度 (Information Density)

信息密度 = 有用信息量 / Token 消耗量

不是所有 Token 都是等价的。一个 Token 可能包含关键信息，也可能只是填充词。Context 工程的核心目标之一就是最大化信息密度。

信息密度优化策略：

策略	方法	适用场景
摘要替代全文	用 200 Token 摘要替代 2000 Token 原文	A 端导航、初步筛选
结构化表达	用表格、列表替代散文	对比、列表类信息
精确检索	只返回最相关的片段	RAG 场景
去冗余	移除重复、无关信息	所有场景
代码最小化	只保留关键代码段	代码相关场景

漏斗模型 (Funnel Model)

漏斗模型是 Context 工程中最核心的信息加载策略：

全量知识库 (100%)
    ↓ 漏斗第一层：摘要筛选
摘要层 (10%)  ← 模型先读摘要
    ↓ 漏斗第二层：按需加载
全文层 (100%) ← 只加载需要的全文

三层漏斗架构：

层级	内容	Token 消耗	作用
索引层	文件列表、目录结构	极低 (~100 tokens)	让模型知道有哪些内容
摘要层	每个文件的摘要.md	低 (~200-500 tokens/文件)	让模型判断是否需要全文
全文层	完整的文件内容	高 (~2000-10000 tokens/文件)	提供完整信息

渐进式加载 (Progressive Loading)

渐进式加载是漏斗模型的动态实现：不一次性加载所有信息，而是根据对话进展逐步加载。

渐进式加载流程：

用户提问 → 模型先搜索索引层，找到相关文件
模型读取相关文件的摘要层
模型根据摘要判断哪些文件需要全文
模型只加载必要的全文
对话深入 → 模型继续搜索和加载更多信息

Context 工程 vs Prompt 工程

维度	Prompt 工程	Context 工程
核心问题	怎么说？	给什么信息？
操作对象	提示词文本	上下文内容
设计重点	语言表达、格式约束	信息选择、组织、密度
动态性	相对静态（预设的提示词）	高度动态（按需加载）
主要挑战	模型理解偏差	上下文窗口限制 + 信息密度
与 RAG 的关系	为 RAG 检索结果提供”指令”	管理 RAG 检索到的内容
2026年趋势	从手工调参走向结构化	从压缩走向组织

协同关系：Prompt 工程告诉模型”怎么理解信息”，Context 工程决定”给模型什么信息”。两者缺一不可。

本 Vault 的漏斗架构实现

本 Obsidian Vault 的 Context 工程实现：

索引层：文件夹结构 (笔记/、深挖/、对比/) 提供知识导航
摘要层：每个文件夹有 摘要.md，Agent 先读摘要
全文层：按需加载具体笔记文件
WikiLink 约束：[[概念-WikiLink]] 必须是存在的笔记，无链接即不存在
渐进式加载：Agent 先读摘要 → 判断需要哪些全文 → 逐个加载

2026年：长上下文窗口改变 Context 工程

长窗口带来的变化

从”压缩”到”组织”：不再需要极致压缩信息，但需要更好的信息组织
全量上下文成为可能：将整个知识库放入上下文窗口（1M tokens 可容纳约 3000 页文本）
新的挑战：注意力衰减（Lost in the Middle）、信息检索效率

长窗口下的 Context 工程策略

策略	短窗口时代 (<32K)	长窗口时代 (1M+)
信息选择	极度精选，每个 Token 都很珍贵	可以宽松选择，但需要好的组织
架构设计	漏斗模型非常重要	漏斗模型仍然重要，但可以在摘要层放更多信息
主要挑战	信息压缩	信息组织 + 注意力管理
检索策略	精确检索，严格控制返回数量	可以返回更多候选，让模型自行筛选

长窗口不等于不需要 Context 工程

即使上下文窗口足够大，Context 工程仍然至关重要：

注意力瓶颈：模型不是对所有位置同等关注
成本：更多 Token 意味着更高的 API 成本和更长的推理时间
信号噪声比：大量无关信息会淹没关键信息

来源

Anthropic Context Engineering: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Lost in the Middle 论文: https://arxiv.org/abs/2307.03172 (Liu et al., 2023)
上下文窗口研究: https://arxiv.org/abs/2402.11550
信息密度优化: https://blog.langchain.dev/context-engineering/
Gemini 1M 上下文窗口: https://blog.google/technology/ai/gemini-long-context-window/