上下文工程详解：从提示工程到AI智能体的信息架构设计

从提示工程到上下文工程

过去，我们普遍认为构建更强大的AI系统关键在于写出完美的提示词（Prompt）。你可能听说过"提示工程"（Prompt Engineering）这个概念——它关注的核心问题是：如何措辞才能从大语言模型中获得想要的结果？

然而，随着大语言模型（LLM）和AI智能体（Agent）的快速发展，行业焦点正在从提示工程转向一个新的范式——上下文工程（Context Engineering）。根据IBM的定义，上下文工程是"有意识地组织和优化传递给LLM或智能体的信息，以产生更准确、更相关输出的实践"。

这里有必要理解LLM和Agent的本质区别。LLM本质上是一个文本预测引擎，它接收输入文本，输出最可能的后续文本。而AI智能体则是在LLM基础上构建的更高级系统，它具备自主规划、工具调用、环境感知和多步决策的能力。一个典型的智能体会在循环中运行：感知环境→思考推理→采取行动→观察结果→再次思考，如此迭代直到完成任务。这种运行模式在学术界被称为ReAct（Reasoning + Acting）范式，由Yao等人在2022年提出。在每一轮迭代中，智能体都需要将先前的思考链（Chain of Thought）、工具调用结果、环境反馈等信息重新注入上下文窗口，这意味着上下文的内容会随着任务的推进不断膨胀和变化。一个执行10步操作的智能体，其上下文中可能累积了系统指令、用户原始请求、多轮中间推理、多次工具返回结果以及错误处理记录等大量异构信息。正是这种多步骤、多轮交互的特性，让上下文管理从"锦上添花"变成了"生死攸关"的核心能力。

说个细节，提示工程并没有消失，它只是上下文工程的一个组成部分。当我们从"如何提问"转向"如何构建模型所看到的整个信息环境"时，这个区别在构建AI智能体时变得尤为关键。

为什么上下文工程如此重要

从人类工作记忆说起

IBM在讲解中用了一个非常贴切的类比。研究表明，人类在处理任务时，工作记忆一次大约只能保持和处理3到5条信息，持续约20秒。当我们同时处理多任务时，就会产生认知过载，效率反而下降。为了应对这一点，我们会习惯性地把信息"分块"（chunking），拆解成更小的子任务。

这个类比有着扎实的认知心理学基础。"3到5条信息"的说法源自认知心理学中关于工作记忆容量的经典研究。1956年，心理学家乔治·米勒提出了著名的"神奇数字7±2"理论，后续研究者如Nelson Cowan在2001年将这一数字修正为更保守的3到5个信息块。工作记忆不同于长期记忆，它是我们在当下进行推理、理解和决策时主动操控信息的认知空间。信息分块（chunking）是一种将多个离散信息组合成有意义单元的策略，例如将电话号码分段记忆。这个类比精确地映射到了LLM的上下文窗口——它就是模型的"工作记忆"，容量有限且需要精心管理。

AI模型处理大型任务的方式与此高度相似。智能体不像传统问答那样只回答一个问题——它需要跨多步推理、调用工具、检索信息、更新记忆来做出决策。就像人类的工作记忆一样，AI模型的上下文也是有限的。

更多上下文≠更好性能：警惕上下文腐烂

有人可能会问：现在的模型不是已经支持超大的上下文窗口了吗？动辄200万+的token容量，我们还需要如此谨慎地设计上下文吗？

先解释一下上下文窗口的技术原理。上下文窗口（Context Window）是指LLM在一次推理过程中能够处理的最大token数量。Token是模型处理文本的基本单位，一个英文单词通常对应1到2个token，一个中文汉字通常对应1到2个token。早期GPT-3的上下文窗口仅有4096个token，而到2024-2025年，Claude的上下文窗口已达到200K token，Gemini更是宣称支持高达200万token。然而，上下文窗口的扩大带来了巨大的计算成本——Transformer架构中自注意力机制的计算复杂度为O(n²)，其中n是序列长度，这意味着上下文长度翻倍，计算量会增长到四倍。同时，推理过程中需要维护的KV缓存（Key-Value Cache）会线性占用GPU显存，200K token的上下文可能需要数十GB的显存仅用于缓存。此外，尽管旋转位置编码（RoPE）和ALiBi等技术在一定程度上改善了模型对长距离依赖的处理能力，但研究表明LLM仍然存在显著的"中间遗失"（Lost in the Middle）现象——模型对上下文开头和结尾的信息关注度较高，而对中间部分的信息处理能力明显下降。Google的"Needle in a Haystack"测试直观地展示了这一点：在长上下文中随机位置插入一条关键信息，模型在某些位置的检索成功率会显著低于其他位置。

答案是：需要，而且更加需要。 IBM明确指出，更多的上下文并不意味着更好的性能，事实上，性能可能随着上下文的膨胀而下降。研究人员将这种现象称为"上下文腐烂（Context Rot）"——过多的无关信息、糟糕的结构或缺失的数据，都会导致更差的推理和更多的幻觉。

上下文腐烂这一概念与多项学术研究相互印证。2023年斯坦福大学和加州大学伯克利分校的研究论文《Lost in the Middle: How Language Models Use Long Contexts》系统证明了，当相关信息被放置在长上下文的中间位置时，模型的检索和推理准确率显著下降。此外，无关信息的注入还会触发"注意力稀释"效应——Transformer架构中的自注意力机制需要在所有token之间计算关联权重，每个token的注意力总和被归一化为1，当无关token大量增加时，关键信息获得的注意力权重被稀释，就像在嘈杂的房间里试图听清一个人说话。更令人警惕的是，2024年的后续研究发现，即使模型在技术上"能看到"所有上下文内容，它在实际推理中对信息的有效利用率也会随着上下文长度的增加呈非线性下降。这些发现共同说明，上下文窗口的大小是一个"能力上界"，而非"性能保证"。这从技术层面解释了为什么精心筛选和组织上下文比简单扩大上下文窗口更为重要。

打个比方：如果我给你一页纸的指导来完成"帮新同事入职"这样的任务，你能很快搞定。但如果我塞给你4000页Slack消息、邮件和零散笔记，你反而会不知从何下手。这正是上下文工程的意义所在——目标不是给模型更多信息，而是在正确的格式中提供正确的信息。

好的上下文包含哪些要素

上下文是模型在推理时所能看到的一切。以LLM为例，上下文包括：

• 系统提示（System Prompt）
• 用户查询（User Query）
• 外部检索信息：来自向量数据库或文档存储的文档
• 历史交互记录：LLM与用户过去的对话和响应
• 附加系统输出：工具输出、API返回、其他智能体的结果

其中，系统提示（System Prompt）是上下文工程中最基础但也最容易被低估的组件。它是在对话开始前注入的一段隐藏指令，用于定义模型的角色、行为边界、输出格式和核心规则。在现代AI系统中，系统提示的设计已经从简单的几句话演变为复杂的结构化文档，可能包含角色定义、操作指南、工具使用说明、安全约束、输出格式规范等多个模块。以Anthropic公布的Claude系统提示为例，它包含了数千字的详细指令，涵盖了从回答风格到安全边界的方方面面。OpenAI等公司在内部实践中甚至将系统提示视为一种"软件配置"，需要版本管理和持续迭代。一个精心设计的系统提示可以显著减少后续交互中所需的上下文补充量，因为它预先建立了模型行为的"默认值"。

而"外部检索信息"则涉及当前AI应用中最重要的技术架构之一——检索增强生成（Retrieval-Augmented Generation, RAG）。RAG最早由Meta AI（当时的Facebook AI Research）在2020年提出，其核心思路是：不把所有知识都塞进提示中，而是在运行时根据用户查询动态检索最相关的信息片段。一个完整的RAG流程包括以下关键步骤：首先是文档分块（Chunking），将原始文档切分为适当大小的文本片段，分块策略（固定长度、按语义边界、递归分割等）直接影响检索质量；然后是向量化（Embedding），使用专门的嵌入模型（如OpenAI的text-embedding-3-large或开源的BGE系列模型）将每个文本块转换为高维数学向量；接着将这些向量存入向量数据库（如Pinecone、Weaviate、Milvus、Chroma等），建立高效的近似最近邻（ANN）索引；在用户查询时，系统将查询同样向量化，通过计算余弦相似度或欧氏距离在向量空间中找到语义最相近的文档片段；最后，检索到的片段还可能经过**重排序（Reranking）**模型的精筛，再注入到提示中供LLM生成最终回答。这一技术正是上下文工程中"相关性"和"时机"原则的技术实现——它确保模型在需要时获得最相关的外部知识，而非一次性加载所有可能用到的信息。

虽然这是一大堆信息，但好的上下文有几个关键特征：

上下文质量的四大核心特征

1. 相关性（Relevance）：包含的每一条信息都应有助于模型完成任务，无关内容必须剔除。
2. 结构性（Structure）：信息应清晰组织，通常配以标签或格式，帮助模型区分不同类型的信息。在实践中，XML标签（如<context>、<instructions>、<examples>）和Markdown格式被广泛用于结构化上下文。Anthropic的官方文档明确推荐使用XML标签来分隔不同类型的上下文内容，因为这种结构化标记能帮助模型更清晰地理解每部分信息的角色和用途，从而提升输出质量。
3. 时机（Timing）：尤其在智能体系统中，上下文应在需要时才引入，避免过早加载不必要的数据。这一原则在技术实现上体现为"惰性加载"（Lazy Loading）策略——系统不在初始化时将所有可能的信息塞入上下文，而是根据智能体当前的推理步骤和任务需求，通过函数调用或检索操作动态引入所需信息。
4. 压缩（Compression）：与其把原始数据一股脑塞进提示，不如总结或过滤出最有用的细节。

关于压缩，在实际工程中有多种实现方式。最直接的方法是摘要生成——用LLM本身对长文本进行总结，将数千token压缩为几百token的关键信息。更高级的方法包括：选择性检索（只提取文档中与查询最相关的段落）、递归摘要（对长对话历史进行分层总结，近期对话保留原文，远期对话只保留摘要）、以及信息蒸馏（将结构化数据转换为自然语言的关键事实陈述）。近期还出现了基于学习的上下文压缩技术，如微软研究院推出的LLMLingua和LongLLMLingua框架，它们利用小型语言模型来评估每个token的信息量（通过困惑度/perplexity指标），移除信息量低的冗余token，能够在保留核心语义的前提下将提示长度压缩至原来的五分之一甚至更少，同时将性能损失控制在最小范围。另一种思路是上下文蒸馏（Context Distillation），将长上下文中的关键知识"蒸馏"为更简洁的表述形式。这些压缩技术不仅节省了token成本（直接关系到API调用费用），还能通过减少噪声信息来提升模型的推理质量，可谓一举两得。

这一系列转换步骤能产出可用的上下文，这个过程被称为上下文处理（Context Processing）。

上下文管理：持续维护的艺术

处理只是第一步，接下来是上下文管理（Context Management）——即跨交互、跨时间地持续维护模型上下文中所包含信息的过程。它包含几个关键环节：

在深入各环节之前，有必要理解智能体系统中"记忆"的分层架构，因为上下文管理本质上就是记忆管理。类比人类认知系统，现代AI智能体框架通常设计了三层记忆结构：工作记忆（Working Memory）对应当前上下文窗口中的内容，是模型在本次推理中直接处理的信息；短期记忆（Short-term Memory）通常以对话历史的形式存在，通过滑动窗口或摘要机制保留近期交互的关键信息；长期记忆（Long-term Memory）则借助外部存储（如向量数据库、关系数据库或知识图谱）持久化重要信息，如用户偏好、历史决策结果、学习到的经验教训等。LangChain、LlamaIndex等主流智能体框架都内置了这种分层记忆管理机制。上下文管理的核心挑战就在于如何在这三层记忆之间高效地调度信息——将长期记忆中的相关片段检索到工作记忆中，将工作记忆中的重要发现写入长期记忆，以及定期对短期记忆进行压缩和归档。

决定保留与丢弃

判断哪些信息该保留、哪些该舍弃，确保相关信息得以维持，而不必要或过时的信息被移除或最小化。这一步直接决定了上下文窗口的使用效率。在工程实践中，常用的策略包括：基于时间衰减的淘汰机制（越久远的信息权重越低）、基于引用频率的保留机制（被多次引用的信息优先保留）、以及基于语义相关性的动态过滤（随着任务阶段的变化，实时调整哪些信息进入上下文）。

维持对话连续性

在对话系统中，这意味着跟踪相关的用户输入、系统指令和先前响应，让模型能够始终如一地回应，并对早前的上下文保持感知。在技术层面，这通常通过对话状态追踪（Dialogue State Tracking）来实现——系统维护一个结构化的状态对象，记录对话中已确认的实体、用户意图和待处理的事项，即使原始对话历史因长度被截断，关键状态信息仍然得以保留。

信息优先级排序

并非所有信息都同等重要。上下文管理会根据相关性、时效性或对任务的重要性，为特定数据分配优先级。

处理信息生命周期

当新信息出现时更新上下文，让过时数据失效，确保上下文反映最准确、最新的知识状态。在信息随时间变化的动态环境中，这一点尤为重要。例如在医疗场景中，患者的最新检查结果应该覆盖半年前的旧数据；在金融场景中，实时市场行情必须优先于历史分析报告。

最后，还需保持一致性和连贯性，确保检索到的信息被正确整合，整体上下文始终合乎逻辑。当来自不同来源的信息存在矛盾时（例如两个数据库中关于同一客户的地址信息不一致），上下文管理系统需要有明确的冲突解决策略，避免将相互矛盾的信息同时呈现给模型，从而导致混乱的输出或幻觉。

实战案例：用上下文工程构建医疗预约助手

IBM给出了一个非常有说服力的真实案例。假设你正在为医疗机构构建一个帮助患者预约的AI助手。

如果只用简单的提示——"为这位患者预约"——会留下大量出错空间。模型不知道诊所的规则、不知道医生的空档时间、也不了解患者的病史。

而应用上下文工程后，系统会提供：

• 诊所的预约政策：如预约类型和时长
• 医生的实时可用时间
• 患者偏好：例如"只在上午"
• 相关病史
• 工具输出：如通过预约API获取的可用时段

此时，模型生成响应时不再是"猜测"，而是在完整、结构化的上下文上进行推理。它不会只说"这里有一些可用时段"，而是能说出："您需要进行复诊，某某医生周三上午10点有空，正好符合您偏好上午的时间安排。这里有几个上午的预约选项，需要我帮您预定吗？"

两者的差距一目了然。值得注意的是，在这个案例中涉及到患者病史等敏感医疗数据，这提醒我们上下文工程还需要考虑数据隐私和合规性维度。在医疗（HIPAA）、金融（GDPR）等受监管行业，上下文中包含的信息必须经过脱敏处理或权限验证，确保敏感数据不会被不当暴露或记录在对话日志中。这是上下文工程从实验室走向生产环境时不可回避的现实约束。

面向智能体时代的必备技能

无论你是在构建AI智能体、试验自动化工作流，还是仅仅想理解这个领域的发展方向，上下文工程都正在成为最重要的技能之一。它标志着AI应用开发从"雕琢一句话"到"设计整个信息生态"的思维转变。在智能体越来越承担复杂多步任务的今天，谁能更好地组织、管理和优化上下文，谁就能构建出更可靠、更智能的AI系统。

这一趋势正在被新兴的行业标准所加速。2024-2025年间，Anthropic推出的模型上下文协议（Model Context Protocol, MCP）正试图标准化智能体与外部数据源和工具之间的连接方式，让上下文的获取和注入变得更加规范化。Google则推出了Agent-to-Agent（A2A）协议，定义了多个智能体之间如何共享和传递上下文信息。这些协议的出现表明，上下文工程正在从个人实践技巧演变为系统性的工程学科，拥有自己的标准、工具链和最佳实践。

同时值得思考的是上下文工程与模型微调（Fine-tuning）之间的关系。微调是将知识和行为模式"烘焙"进模型权重中的方法，而上下文工程是在推理时动态提供信息。两者并非互斥而是互补：对于稳定、通用的知识和行为规范，微调更为高效；对于频繁变化的实时信息和个性化需求，上下文工程则更为灵活。理解何时使用哪种方法（或两者结合），将是下一代AI工程师的核心判断力。

核心要点

核心要点