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

从提示工程到上下文工程
过去,我们普遍认为构建更强大的AI系统关键在于写出完美的提示词(Prompt)。你可能听说过"提示工程"(Prompt Engineering)这个概念——它关注的核心问题是:如何措辞才能从大语言模型中获得想要的结果?
然而,随着大语言模型(LLM)和AI智能体(Agent)的快速发展,行业焦点正在从提示工程转向一个新的范式——上下文工程(Context Engineering)。根据IBM的定义,上下文工程是"有意识地组织和优化传递给LLM或智能体的信息,以产生更准确、更相关输出的实践"。
这里有必要理解LLM和Agent的本质区别。LLM本质上是一个文本预测引擎,它接收输入文本,输出最可能的后续文本。而AI智能体则是在LLM基础上构建的更高级系统,它具备自主规划、工具调用、环境感知和多步决策的能力。一个典型的智能体会在循环中运行:感知环境→思考推理→采取行动→观察结果→再次思考,如此迭代直到完成任务。正是这种多步骤、多轮交互的特性,让上下文管理从"锦上添花"变成了"生死攸关"的核心能力。
说个细节,提示工程并没有消失,它只是上下文工程的一个组成部分。当我们从"如何提问"转向"如何构建模型所看到的整个信息环境"时,这个区别在构建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。然而,上下文窗口的扩大并不意味着模型能均匀地关注其中所有信息。研究表明,LLM存在"中间遗失"(Lost in the Middle)现象——模型对上下文开头和结尾的信息关注度较高,而对中间部分的信息处理能力明显下降。
答案是:需要,而且更加需要。 IBM明确指出,更多的上下文并不意味着更好的性能,事实上,性能可能随着上下文的膨胀而下降。研究人员将这种现象称为"上下文腐烂(Context Rot)"——过多的无关信息、糟糕的结构或缺失的数据,都会导致更差的推理和更多的幻觉。
上下文腐烂这一概念与多项学术研究相互印证。2023年斯坦福大学和加州大学伯克利分校的研究论文《Lost in the Middle: How Language Models Use Long Contexts》系统证明了,当相关信息被放置在长上下文的中间位置时,模型的检索和推理准确率显著下降。此外,无关信息的注入还会触发"注意力稀释"效应——Transformer架构中的自注意力机制需要在所有token之间计算关联权重,当无关token大量增加时,关键信息获得的注意力权重被稀释,直接导致推理质量下降和幻觉(hallucination)增加。这从技术层面解释了为什么精心筛选和组织上下文比简单扩大上下文窗口更为重要。
打个比方:如果我给你一页纸的指导来完成"帮新同事入职"这样的任务,你能很快搞定。但如果我塞给你4000页Slack消息、邮件和零散笔记,你反而会不知从何下手。这正是上下文工程的意义所在——目标不是给模型更多信息,而是在正确的格式中提供正确的信息。

好的上下文包含哪些要素
上下文是模型在推理时所能看到的一切。以LLM为例,上下文包括:
- 系统提示(System Prompt)
- 用户查询(User Query)
- 外部检索信息:来自向量数据库或文档存储的文档
- 历史交互记录:LLM与用户过去的对话和响应
- 附加系统输出:工具输出、API返回、其他智能体的结果
其中,系统提示(System Prompt)是上下文工程中最基础但也最容易被低估的组件。它是在对话开始前注入的一段隐藏指令,用于定义模型的角色、行为边界、输出格式和核心规则。在现代AI系统中,系统提示的设计已经从简单的几句话演变为复杂的结构化文档,可能包含角色定义、操作指南、工具使用说明、安全约束、输出格式规范等多个模块。OpenAI等公司在内部实践中甚至将系统提示视为一种"软件配置",需要版本管理和持续迭代。一个精心设计的系统提示可以显著减少后续交互中所需的上下文补充量。
而"外部检索信息"则涉及当前AI应用中最重要的技术架构之一——检索增强生成(Retrieval-Augmented Generation, RAG)。RAG的核心思路是:不把所有知识都塞进提示中,而是在运行时根据用户查询动态检索最相关的信息片段。向量数据库(如Pinecone、Weaviate、Milvus等)将文本转换为高维数学向量(embedding),通过计算向量间的余弦相似度或欧氏距离来快速找到语义最相近的内容。这一技术正是上下文工程中"相关性"和"时机"原则的技术实现——它确保模型在需要时获得最相关的外部知识,而非一次性加载所有可能用到的信息。
虽然这是一大堆信息,但好的上下文有几个关键特征:
上下文质量的四大核心特征
- 相关性(Relevance):包含的每一条信息都应有助于模型完成任务,无关内容必须剔除。
- 结构性(Structure):信息应清晰组织,通常配以标签或格式,帮助模型区分不同类型的信息。
- 时机(Timing):尤其在智能体系统中,上下文应在需要时才引入,避免过早加载不必要的数据。
- 压缩(Compression):与其把原始数据一股脑塞进提示,不如总结或过滤出最有用的细节。
关于压缩,在实际工程中有多种实现方式。最直接的方法是摘要生成——用LLM本身对长文本进行总结,将数千token压缩为几百token的关键信息。更高级的方法包括:选择性检索(只提取文档中与查询最相关的段落)、递归摘要(对长对话历史进行分层总结,近期对话保留原文,远期对话只保留摘要)、以及信息蒸馏(将结构化数据转换为自然语言的关键事实陈述)。近期还出现了基于学习的上下文压缩技术,如LLMLingua等框架,能够在保留语义的前提下移除冗余token,将提示长度压缩至原来的五分之一甚至更少,同时将性能损失控制在最小范围。
这一系列转换步骤能产出可用的上下文,这个过程被称为上下文处理(Context Processing)。

上下文管理:持续维护的艺术
处理只是第一步,接下来是上下文管理(Context Management)——即跨交互、跨时间地持续维护模型上下文中所包含信息的过程。它包含几个关键环节:
决定保留与丢弃
判断哪些信息该保留、哪些该舍弃,确保相关信息得以维持,而不必要或过时的信息被移除或最小化。这一步直接决定了上下文窗口的使用效率。
维持对话连续性
在对话系统中,这意味着跟踪相关的用户输入、系统指令和先前响应,让模型能够始终如一地回应,并对早前的上下文保持感知。
信息优先级排序
并非所有信息都同等重要。上下文管理会根据相关性、时效性或对任务的重要性,为特定数据分配优先级。
处理信息生命周期
当新信息出现时更新上下文,让过时数据失效,确保上下文反映最准确、最新的知识状态。在信息随时间变化的动态环境中,这一点尤为重要。
最后,还需保持一致性和连贯性,确保检索到的信息被正确整合,整体上下文始终合乎逻辑。

实战案例:用上下文工程构建医疗预约助手
IBM给出了一个非常有说服力的真实案例。假设你正在为医疗机构构建一个帮助患者预约的AI助手。
如果只用简单的提示——"为这位患者预约"——会留下大量出错空间。模型不知道诊所的规则、不知道医生的空档时间、也不了解患者的病史。
而应用上下文工程后,系统会提供:
- 诊所的预约政策:如预约类型和时长
- 医生的实时可用时间
- 患者偏好:例如"只在上午"
- 相关病史
- 工具输出:如通过预约API获取的可用时段
此时,模型生成响应时不再是"猜测",而是在完整、结构化的上下文上进行推理。它不会只说"这里有一些可用时段",而是能说出:"您需要进行复诊,某某医生周三上午10点有空,正好符合您偏好上午的时间安排。这里有几个上午的预约选项,需要我帮您预定吗?"
两者的差距一目了然。
面向智能体时代的必备技能
无论你是在构建AI智能体、试验自动化工作流,还是仅仅想理解这个领域的发展方向,上下文工程都正在成为最重要的技能之一。它标志着AI应用开发从"雕琢一句话"到"设计整个信息生态"的思维转变。在智能体越来越承担复杂多步任务的今天,谁能更好地组织、管理和优化上下文,谁就能构建出更可靠、更智能的AI系统。
核心要点
相关推荐

EmbeddedSass for .NET:告别Node.js依赖的Sass编译方案
EmbeddedSass for .NET基于官方Embedded Sass协议,让.NET开发者无需Node.js即可原生编译Sass/SCSS。本文解析其技术原理、应用场景及与ASP.NET生态的集成方式。

旧金山到新加坡时差:硅谷科技人的跨太平洋日常
旧金山与新加坡之间存在15-16小时时差,频繁往返两地已成为科技从业者的常态。本文解析SF到SG时差挑战、两大科技中心的连接趋势,以及AI行业全球化布局背后的人才与资本流动。

Anthropic官方Claude Code插件目录发布:精选高质量扩展生态
Anthropic发布官方Claude Code插件目录claude-plugins-official,提供经过审核的高质量插件精选集。了解官方目录的定位、核心价值及对AI编程工具生态的深远影响。