上下文工程：AI 智能体突破能力边界的核心密码

如果说 Prompt 是告诉 AI "做什么"，那么上下文工程就是决定 AI "能记住什么、能理解多深、能走多远"。

2025 年，主流大语言模型的上下文窗口已经突破 100 万 tokens，几乎能装下一整部《战争与和平》。然而一个被广泛观察到的现象是：上下文越长，模型的表现并非线性提升，反而经常出现"中段迷失"——模型对开头和结尾的信息记忆清晰，对中间部分频繁出现理解偏差甚至直接遗忘。

这背后的根本原因，并非模型"记不住"，而是信息组织和表达的方式决定了模型能否真正利用上下文。

上下文工程（Context Engineering）正是在这一背景下诞生的新学科：它研究如何高效地构造、压缩、组织和利用大模型的上下文，让模型在无限信息面前依然保持高度的任务一致性。

---

一、为什么上下文是 AI 能力的瓶颈

我们先厘清一个常见误解：上下文不是"内存"，而是"工作空间"。

内存是存储过去发生的事，工作空间是模型此刻正在处理的信息。模型对工作空间内的信息有直接的"注意力"，但这种注意力的分配并非均匀——模型天然对位置（开头/结尾）、频率（重复出现的概念）和层级（结构化信息优于扁平文本）敏感。

这意味着，即便你把全部信息都塞进上下文窗口，信息与信息之间的关系和结构仍然决定模型能否正确推理。

举一个真实案例：我让一个 GPT-4 级模型分析一份包含 50 条用户反馈的列表，找出其中与"支付失败"相关的条目，并在找到后总结共性原因。如果直接粘贴原始文本，模型会遗漏约 30% 的相关条目；但如果我将文本按"时间段+反馈类型"结构化重组后粘贴，遗漏率降至 5% 以下。

差异不在于信息量，而在于信息的组织方式。

---

二、上下文工程的四大核心维度

2.1 信息密度压缩

原始文本充满了人类交流中的冗余——语气词、重复表达、上下文隐含的常识。模型需要处理这些"噪音"，但这并不增加推理价值。

高质量的上下文压缩不是简单删除文字，而是用更少的 token 表达更多的确定意图。

实践技巧：

• 摘要先行：在长文档前附上 3-5 句的结构化摘要，标明核心结论和关键数据点
• 表格化：步骤列表、对比数据、参数配置等信息，优先使用 Markdown 表格而非段落
• 去除隐含常识：人类对话依赖大量背景常识，这些常识在上下文中并不"免费"，需要显式表达

2.2 结构感知设计

Transformer 架构的注意力机制对结构信号高度敏感。同样的信息，以不同结构呈现，模型的理解深度会有显著差异。

常见高效结构：

目标：优化登录模块的性能
├─ 背景：当前平均响应时间 2.3s，P99 为 8s
├─ 约束：不能改数据库 schema，不能加缓存层
├─ 已尝试：索引优化（无效）、连接池调整（无效）
└─ 期望：P99 降至 3s 以内

这种树形结构让模型能够快速定位问题边界，而不是在全文中搜索。

2.3 动态上下文管理

对于复杂、长时间运行的任务，静态上下文（即一次性输入全部内容）很快会遇到瓶颈。动态上下文管理通过选择性信息注入和淘汰来维持上下文质量。

主流策略包括：

对话历史压缩：保留每轮的核心语义增量，而非完整历史。例如使用"摘要+增量"模式，将前 N 轮对话压缩为一个摘要，后续只追加新的对话。

工具调用上下文分离：将工具返回的原始数据与模型的推理过程分开存储。工具返回的 JSON 直接放在独立的"数据区"，模型推理链放在"思维区"，避免数据噪音污染推理。

阶段性checkpoint：长任务中，在每个阶段完成后输出一段结构化的"阶段总结"，后续阶段以此为基础继续推理，形成向上累积的上下文结构。

2.4 检索增强的精细控制

RAG（检索增强生成）已经成为构建知识密集型 AI 应用的标准范式。但粗糙的 RAG 实现只是把相关文档一股脑塞进上下文，结果往往适得其反。

精细化 RAG 的核心原则是：检索的是答案，不是文档。

这意味着，不是检索"哪些文档与问题相关"，而是先明确"回答这个问题需要哪些具体知识点"，再针对性地检索这些知识点，并将其重新组织为适合推理的上下文结构。

具体实践中，可以采用"问题分解→知识点检索→上下文组装"的三段式流程，每段都有独立的优化空间。

---

三、上下文工程的工程实践

从 Prompt 到 Context Stack

传统开发中，我们关注的是 Prompt 设计。但在复杂系统中，Prompt 只是最顶层，其下还有多层上下文结构需要精心设计，我称之为 Context Stack：

L5: 任务指令层     — 做什么，怎么做，输出格式
L4: 角色/规范层    — 谁来做，应该遵循什么规范
L3: 背景知识层     — 相关领域常识和背景信息
L2: 当前数据层     — 本次任务涉及的具体数据
L1: 历史上下文层   — 本次会话中的前序交互

每一层的上下文有不同的更新频率和质量要求。L1/L2 更新频繁但容易引入噪音，需要严格过滤；L3/L4 相对稳定，但需要确保与具体任务的相关性。

上下文质量的度量

如何判断一个上下文设计的好坏？以下是实践中总结的三个核心指标：

任务完成率：在相同任务下，使用优化后的上下文与原始上下文对比，任务正确完成的比率。

Token 效率：每 1000 tokens 能支持多少有效推理步骤。好的上下文设计，Token 效率应该是差设计的 3-5 倍。

中段一致性：对于超长上下文（>50K tokens），模型对"中间位置"信息的引用准确度。如果模型频繁出现"根据上文第 X 段"但实际内容与 X 段不符，说明中段一致性差。

---

四、未来方向：主动上下文与自适应压缩

当前上下文工程的核心范式是被动的——我们根据任务需求手动设计上下文结构。但下一个突破方向是让模型拥有主动管理上下文的能力。

想象一个 AI 智能体，它能够：

• 在执行任务过程中，自动判断当前上下文的充足性
• 当发现信息不足时，主动调用检索工具补充特定知识
• 当上下文过长时，自动进行有语义保留的压缩
• 在多步推理中，主动维护一个"推理状态机"，只在状态变化时更新上下文

这些能力目前在学术研究和工业实验中都有探索，但尚未成为主流范式。可以预见，未来 1-2 年内，具备主动上下文管理能力的 AI 系统将在复杂任务表现上显著超越现有系统。

---

写在最后

上下文工程不是一门有完整理论体系的学科，它更像是一种工程哲学：如何在有限注意力中创造无限价值。

它的重要性将在 AI 能力持续提升的过程中越发凸显。当模型本身越来越强大，决定最终表现的不再是模型的上限，而是我们能否有效地将模型的注意力引导到正确的方向上。

上下文工程，正是那个引导注意力的罗盘。