什么是上下文工程

如果说提示词工程解决的是”怎么问”的问题，那么上下文工程解决的是”给什么信息”的问题。上下文工程（Context Engineering）是系统性地设计、组装和管理输入到大语言模型的全部信息的工程实践。它涵盖了信息获取、筛选、排序、压缩、格式化和管理等一系列技术环节。

上下文工程与提示词工程的区别在于：提示词工程关注指令的设计——告诉模型”如何使用它的能力”；上下文工程关注信息的质量——告诉模型”基于什么来思考”。一个模型的能力上限由它的训练数据决定，但它在具体任务中的表现上限，很大程度上取决于你给它的上下文有多好。

在实践中，”上下文化”的提示词比零上下文的提示词普遍表现更好，但”更好的上下文”并不简单地等于”更多的上下文”。不加选择地塞入大量信息不仅消耗 token 成本，还可能导致模型注意力分散（lost-in-the-middle 现象）——在长上下文的中间位置，模型的信息提取能力会显著下降。

上下文窗口：一种需要管理的宝贵资源

LLM 的上下文窗口是一个有限的、有成本的资源。以当前的模型为例：

  • Claude 200K：可以容纳一本中等篇幅的小说，但处理 200K token 的每次调用需要数美元的成本和数秒的延迟。
  • GPT-4o 128K：足以应对大多数企业级任务，但当上下文接近极限时，处理速度会明显下降。
  • Gemini 2M：面向超大规模文档分析，但边际效益递减规律同样适用——前 20% 的上下文通常贡献了 80% 的效果。

上下文工程的核心挑战在于 token 预算管理：在单位成本下最大化信息价值。这需要回答三个问题：放什么信息（选择）、按什么顺序放（排序）、浓缩到多长（压缩）。

上下文组装流水线

生产级 AI 应用的上下文组装通常遵循一个多阶段流水线：

检索（Retrieval）：从外部知识库中召回可能与当前任务相关的信息。这是 RAG 系统的核心环节，通常通过向量搜索（语义相似度）或关键词搜索（精确匹配）实现。

过滤（Filtering）：并非所有检索到的内容都值得放入上下文。使用相关度阈值过滤、去重、冲突消解等手段，筛选出真正有用的子集。

排序（Ordering）：信息的排列顺序对模型表现影响显著。将最相关的信息放在开头（primacy effect）和结尾（recency effect），中等相关度的信息放在中间。对于有层级关系的信息，使用”先总后分”的结构。

压缩（Compression）：对单条文档片段进行信息提取和抽象，保留关键事实而去除冗余表述。可以使用小型模型做提取摘要，或者使用提示词让大模型在上下文中做”选择性关注”。

格式化（Formatting）：统一信息的表现形式——使用一致的标题层级、引用格式、分隔符。良好的格式化能让模型更准确地区分不同的信息来源，减少混淆。

信息密度优化

什么是”好”的上下文？不是越长越好，而是信息密度越高越好。信息密度 = 有效信息量 / 总 token 数。

提高信息密度的技巧：

  • 去重：删除重复出现的信息，包括语义相同但表述不同的内容。
  • 去噪：移除广告、导航、页脚等无关内容（对于网页来源）。
  • 精炼：将啰嗦的表述压缩为简洁的事实陈述。
  • 结构化：表格、列表、键值对的结构化信息比散文段落更适合模型解析。
  • 术语统一：确保上下文中对同一概念使用一致的术语，减少模型的认知负担。

动态上下文管理

静态的上下文策略无法适应多样化的用户需求。动态上下文管理根据任务特征和对话状态实时调整上下文策略：

渐进式披露（Progressive Disclosure）：不在第一次调用时就加载全部信息。首次调用只提供高层次的摘要和分类信息，当模型（或用户）深入某个具体方向时，再按需加载相关的详细信息。这种方式模拟了人类获取知识的自然方式——先看目录，再翻阅章节。

即时检索（Just-in-Time Retrieval）：不是在对话开始前就预先检索所有相关内容，而是在推理过程中，当模型表现出信息需求时（如”我需要查询 X 的具体数值”），再触发检索。Agent 架构中的工具调用天然支持这种模式。

上下文感知裁剪：根据用户的问题类型动态选择上下文策略。事实查询—短上下文、高精准度；分析类任务—中等上下文、多方观点；创作类任务—长上下文、丰富素材。

上下文策略模式

在实际工程中，以下几种上下文管理策略经过了广泛验证：

摘要缓冲区（Summary Buffer）：对于长对话，不是简单截断旧消息，而是对旧对话生成逐步更新的摘要。摘要 + 最近的原始消息，在完整性和效率之间取得了很好的平衡。这个模式被 LangChain 的 ConversationSummaryBufferMemory 实现了标准化。

滑动窗口（Sliding Window）：只保留最近 N 轮对话或最近 K 个 token 的上下文。简单直接，适用于短会话和实时性要求高的场景。缺点是丢失早期重要信息。

重要性剪枝（Importance-based Pruning）：为每条上下文信息计算重要性分数，保留高分的，丢弃低分的。重要性可以根据信息的新奇度（与模型已有知识的差异）、任务相关性、用户显式反馈等来评估。

多模态上下文管理

多模态 LLM 的出现让上下文工程变得更加复杂：

文本 + 图像：如何处理多张图片的上下文组织？图像是否需要附带描述文本？如何决定图像的显示顺序和大小？目前的实践是：在文本描述中标注图片的核心信息，将图片本身放在上下文靠近引用它的文本位置。

文本 + 音频：长音频（如会议录音）需要先转录为文本，然后对文本应用标准上下文管理策略。关键挑战在于转录可能很长，需要先做分段摘要再注入相关段落的原文。

成本权衡：多模态输入（尤其是图像和视频）的 token 消耗远超纯文本。一张高分辨率照片可能消耗数百到数千 token。多模态上下文管理需要更审慎的成本意识。

上下文污染与投毒

上下文不只是”可能不好”，它还可能”有害”：

上下文污染（Context Pollution）：当无关、误导或低质量的信息混入上下文时，模型的输出质量会显著下降。这在 RAG 系统中尤为常见——如果检索到的文档不够相关或包含错误信息，模型的回答也会跟着出错。

对抗性投毒（Adversarial Poisoning）：如果攻击者能够控制模型检索的知识源（如公开的网页、维基百科页面、共享文档），他们就可以预置恶意指令或误导信息。模型在检索到这些内容后，其行为可能被间接操纵——这正是间接提示词注入的一种形式。

缓解策略：对检索来源进行可信度评级；使用引用追溯让用户能够验证信息来源；在上下文中明确标注每段信息的来源和可信度。

测量上下文有效性

如何量化上下文的好坏？可以从三个维度评估：

相关性（Relevance）：上下文是否包含了回答用户问题所需的信息？使用信息检索指标如 NDCG、Recall@K 来评估检索环节的相关性。

覆盖率（Coverage）：上下文是否覆盖了问题的所有关键方面？是否存在信息盲区导致模型只能给出片面的回答？

简洁性（Conciseness）：上下文中有效信息与总信息量的比例。是否存在大量的冗余和噪声？可以使用压缩率（原始文档长度 vs 上下文长度）作为代理指标。

RAGAS（Retrieval Augmented Generation Assessment）评估框架中的 context precision 和 context recall 指标是专门为此设计的自动化评估方案。

不同场景的上下文策略

编程助手：代码文件本身就是最强的上下文。当前的代码文件 + 相关的类型定义 + 最近的 git 变更 + 相关的文档片段，构成典型的高质量编程上下文。IDE 编程助手的核心优势在于它们天然拥有丰富的本地上下文。

学术研究：以论文原文为权威上下文，搭配综述、引用关系图和关键数据表格。上下文组织上，先放核心论文的摘要和方法部分，再放对照组的比较数据。

客服系统：知识库文章 + 用户历史工单 + 当前对话上下文 + 用户的账户信息。关键是信息的权限控制——客服人员看到的信息不应被注入到面向用户的回答中。

创意写作：风格参考文本 + 世界设定 + 人物档案 + 情节大纲。创意任务的上下文管理更强调”灵感触发”而非”事实准确”，因此信息的多样性和丰富性比相关度更重要。

上下文工程不是一次性的配置工作，而是一个持续观测、度量和优化的过程。在 AI 应用从原型走向生产的过程中，上下文工程的能力往往决定了产品质量的天花板——这就是它成为核心竞争力的原因。