或许你已是一名AI应用提示工程高手，但随着对话的推进，你的聊天机器人常常会忘记你最初且最重要的指令内容，你的代码助手会丢失项目架构的线索，而你的检索增强生成（RAG）工具无法在复杂文档与不同领域间建立信息关联。
随着AI应用场景日益复杂，编写精妙的提示词只是更大挑战中的一小部分——这个挑战就是上下文工程。
在本指南中，我将阐释什么是上下文工程、它如何运作、何时应替代常规提示工程使用它，以及能让AI系统更智能、更具上下文感知能力的实用技巧。
一、什么是上下文工程？
上下文工程是指设计相关系统的实践，该系统能决定AI模型在生成响应前应获取哪些信息。
尽管这个术语是新兴的，但上下文工程背后的原理早已存在。这种新的抽象概念使我们能够思考AI系统信息流入与流出设计中一个核心且始终存在的问题。
不同于为单个请求编写完美提示词，上下文工程旨在构建能从多个来源收集相关细节，并在模型的上下文窗口内对这些细节进行整理的系统。这意味着你的系统会整合对话历史、用户数据、外部文档和可用工具，然后对这些信息进行格式化处理，以便模型能够利用它们。
图片
这种方法需要管理构成完整上下文的多种不同类型信息，包括：
• 设定行为与规则的系统指令
• 对话历史与用户偏好
• 从文档或数据库中检索到的信息
• 可用工具及其说明
• 结构化输出格式与模式
• 实时数据与外部API响应
主要挑战在于，要在上下文窗口的限制范围内运作，同时长期维持连贯的对话。你的系统需要判断每个请求最相关的信息是什么，这通常意味着要构建检索系统，以便在需要时找到恰当的细节。
这涉及构建记忆系统，该系统既要跟踪短期对话流程，也要记录长期用户偏好，同时还需删除过时信息，为当前需求腾出空间。
当不同类型的上下文协同作用，构建出更智能、更具感知力的AI系统时，上下文工程的真正价值便得以体现。当你的AI助手能够同时参考过往对话、访问你的日程表并理解你的沟通风格时，互动不再显得重复，反而会让你感觉自己在与一个“记得你”的对象协作。
二、上下文工程与提示工程的对比
如果你让ChatGPT“写一封专业邮件”，这属于提示工程——你在为单个任务编写指令。但如果你正在构建一个客服机器人，它需要记住过往工单、访问用户账户详情，并在多次互动中维持对话历史，那么这就属于上下文工程。
安德烈·卡帕西（Andrej Karpathy）对此有精辟的解释：“人们通常将提示词与日常使用大语言模型（LLM）时给出的简短任务描述联系在一起。但在所有工业级LLM应用中，上下文工程是一门精妙的技艺与科学，它旨在为上下文窗口填充下一步所需的恰好合适的信息。”
大多数AI应用会同时运用提示工程与上下文工程。在上下文工程系统中，你仍需编写优质的提示词，不同之处在于，这些提示词如今会与经过精心管理的背景信息协同工作，而非每次都从零开始。
方法（Approach） | 最适用场景（Best Used For） |
提示工程（Prompt Engineering） | 一次性任务、内容生成、特定格式输出 |
上下文工程（Context Engineering） | 对话式AI、文档分析工具、编程助手 |
两者结合（Both Together） | 需要稳定、可靠性能的生产级AI应用 |
三、实际应用中的上下文工程
当你开始构建需要处理复杂、互联信息的AI应用时，上下文工程便从理论走向实践。以客服机器人为例，它需要访问过往支持工单、查询账户状态、参考产品文档，同时还要保持有帮助的对话语气。在这种场景下，传统提示工程会失效，而上下文工程则变得必不可少。
1. 检索增强生成（RAG）系统
可以说，上下文工程起源于检索增强生成（RAG）系统。RAG是最早能让大语言模型（LLM）接触到其原始训练数据之外信息的技术之一。
RAG系统运用先进的上下文工程技巧，更高效地组织和呈现信息。它们会将文档拆分为有意义的片段，按相关性对信息进行排序，并将最有用的细节纳入令牌（token）限制范围内。
在RAG出现之前，若想让AI回答关于公司内部文档的问题，你必须重新训练或微调整个模型。而RAG通过构建能检索文档、找到相关片段，并将这些片段与你的问题一同纳入上下文窗口的系统，改变了这一局面。
这意味着LLM能够突然分析多个文档和来源，回答那些通常需要人类阅读数百页内容才能解答的复杂问题。
2. AI智能体（AI Agents）
RAG系统为AI获取外部信息打开了大门，而AI智能体则更进一步，使上下文具备动态性和响应性。智能体不再只是检索静态文档，而是会在对话过程中使用外部工具。
AI会判断哪种工具最适合解决当前问题。一个智能体可以开启对话，意识到需要最新股票数据后，调用金融API，然后利用这些实时信息继续对话。
AI智能体简介
LLM令牌成本的降低也使多智能体系统成为可能。你无需将所有内容硬塞进单个模型的上下文窗口，而是可以设置专门的智能体来处理问题的不同方面，并通过A2A或MCP等协议在它们之间共享信息。
3. AI编程助手
AI编程助手（如Cursor或Windsurf）是上下文工程最先进的应用之一，因为它们在处理高度结构化、互联信息的同时，融合了RAG和智能体的原理。
这些系统不仅需要理解单个文件，还需掌握整个项目架构、模块间的依赖关系以及整个代码库中的编码模式。
当你要求编程助手重构一个函数时，它需要了解该函数的调用位置、期望的数据类型，以及修改可能对项目其他部分产生的影响等上下文信息。
此时上下文工程变得至关重要，因为代码之间的关联跨越多个文件，甚至多个代码仓库。一个优秀的编程助手会持续维护与项目结构、你最近的修改、你的编码风格以及所使用框架相关的上下文信息。
这就是为什么像Cursor这样的工具在项目中使用时间越长，效果越好。它们会逐步积累关于你特定代码库的上下文信息，并能根据你的模式和偏好提供更相关的建议。
四、上下文失效及缓解技巧
在阅读本文的过程中，你可能会认为上下文工程是不必要的，或者随着前沿模型的上下文窗口不断扩大，在不久的将来会变得不必要。这种假设很自然，因为如果上下文窗口足够大，你似乎可以将所有内容（工具、文档、指令等）都塞进提示词中，然后让模型处理剩下的事情。
然而，德鲁·布洛伊尼格（Drew Breunig）撰写的这篇出色文章指出，即便模型支持100万令牌的上下文窗口，上下文仍会以四种意想不到的方式失控。在本节中，我将简要介绍德鲁·布洛伊尼格提出的这些问题，以及能解决这些问题的上下文工程模式——强烈建议你阅读布洛伊尼格的文章以获取更多细节。
1. 上下文污染（Context Poisoning）
当幻觉信息或错误信息进入AI系统的上下文，并在后续响应中被反复引用时，就会发生上下文污染。DeepMind团队在构建一个玩《宝可梦》（Pokémon）的智能体时，在其Gemini 2.5技术报告中发现了这一问题。当该智能体有时对游戏状态产生幻觉时，这些虚假信息会污染其上下文中的“目标”部分，导致智能体制定无意义的策略，并在长时间内追求不可能实现的目标。
在信息不断累积的智能体工作流程中，这个问题会变得非常严重。一旦被污染的上下文形成，修复起来可能需要很长时间，因为模型会持续将虚假信息当作真实信息来引用。
最佳解决方案是上下文验证与隔离。你可以将不同类型的上下文隔离在单独的线程中，并在信息被添加到长期记忆前对其进行验证。上下文隔离指的是，当检测到潜在污染时，开启新的线程，从而防止不良信息扩散到未来的互动中。
2. 上下文干扰（Context Distraction）
当上下文规模扩大到一定程度，导致模型过度关注累积的历史信息，而不再运用训练期间学到的知识时，就会发生上下文干扰。玩《宝可梦》的Gemini智能体就体现了这一点——当上下文规模超过10万个令牌后，该智能体开始重复其庞大历史记录中的行为，而非制定新策略。
Databricks的一项研究（非常有趣的研究，绝对值得一读）发现，对于Llama 3.1 405B模型，当上下文规模达到约3.2万个令牌时，模型的准确性就开始下降，而更小的模型会更早达到性能极限。这意味着，远在上下文窗口实际填满之前，模型就已经开始出错，这不禁让人质疑超大上下文窗口在复杂推理任务中的实际价值。
最佳方法是上下文总结。不要让上下文无限扩大，而是可以将累积的信息压缩成更简短的摘要，保留重要细节的同时删除冗余历史。当你遇到干扰上限时，这种方法会很有帮助——你可以总结到目前为止的对话，在保持一致性的前提下重新开始。
3. 上下文混淆（Context Confusion）
当你在上下文中包含额外信息（即便这些信息与当前任务无关），而模型却利用这些信息生成不良响应时，就会发生上下文混淆。伯克利函数调用排行榜（Berkeley Function-Calling Leaderboard）的数据证明了这一点——当为所有模型提供不止一个工具时，它们的性能都会下降，而且模型有时会调用与任务无关的工具。
模型越小、工具越多，这个问题就越严重。最近的一项研究发现，当为量化后的Llama 3.1 8B模型提供全部46个可用工具时，即便上下文规模远在1.6万令牌的窗口限制内，该模型在Geo Engine基准测试中仍以失败告终。但当研究人员只为该模型提供19个工具时，它的表现却十分良好。
解决方案是利用RAG技术进行工具加载管理。甘甜甜（Tiantian Gan）和孙启尧（Qiyao Sun）的研究表明，将RAG应用于工具说明能显著提升性能。通过将工具说明存储在向量数据库中，你可以为每个任务只选择最相关的工具。他们的研究发现，将工具选择数量控制在30个以内，工具选择的准确率能提升两倍（即达到原来的三倍），且提示词长度也会大幅缩短。
4. 上下文冲突（Context Clash）
当你在上下文中收集的信息和工具与已存在的其他信息直接冲突时，就会发生上下文冲突。微软（Microsoft）和Salesforce联合开展的一项研究证明了这一点：研究人员将基准测试提示词的信息“分片”到多个对话轮次中提供，而非一次性给出所有信息。结果十分显著——模型的平均性能下降了39%，其中OpenAI的O3模型性能从98.1降至64.1。
产生这个问题的原因是，当信息分阶段输入时，整合后的上下文中会包含模型在获取全部信息前对问题做出的初步回答尝试。这些不正确的初步回答会留在上下文中，并在模型生成最终响应时对其产生影响。
最佳解决方案是上下文修剪与卸载。上下文修剪指的是，随着新细节的输入，删除过时或冲突的信息。上下文卸载（如Anthropic的“思考”（Think）工具）为模型提供了一个独立的工作空间来处理信息，而不会占用主上下文的空间。这种“草稿本”式的方法通过防止内部矛盾干扰推理，在专门的智能体基准测试中能将性能提升高达54%。
五、结论
上下文工程代表了AI发展的下一阶段，在这一阶段，重点从编写完美提示词转向构建能长期管理信息流动的系统。能否在多次互动中维持相关上下文，决定了你的AI给人的感觉是智能的，还是仅仅能给出优质的一次性响应。
本指南涵盖的技术——从RAG系统到上下文验证与工具管理——已被应用于服务数百万用户的生产级系统中。
如果你正在构建的系统比简单的内容生成器更复杂，那么你很可能需要运用上下文工程技术。好消息是，你可以从基础的RAG实现入手，从小规模开始，然后随着需求的增长，逐步添加更复杂的记忆管理和工具管理功能。
六、常见问题（FAQs）
1. 何时应开始使用上下文工程而非仅依赖提示词？
当你的AI需要在对话之间记住信息、处理多个信息来源，或维持长期运行的任务时，就应开始使用上下文工程。如果你正在构建的系统比简单的内容生成器更复杂，那么你很可能需要这些技术。
2. 上下文工程与提示工程的主要区别是什么？
提示工程专注于为单个任务编写指令，而上下文工程则旨在设计能跨多个互动管理信息流动的系统。上下文工程构建记忆与检索系统，而提示工程则编写单个请求的提示词。
3. 能否用更大的上下文窗口替代上下文工程？
更大的上下文窗口无法解决核心问题。研究表明，即便使用百万令牌规模的上下文窗口，由于上下文干扰和混淆，模型性能在约3.2万个令牌时就会开始下降。无论上下文窗口规模多大，你仍需运用总结、修剪和智能信息选择等技术。
4. 为什么为AI模型提供更多工具或信息后，其性能会下降？
这被称为上下文混淆——模型会被无关信息干扰，并可能使用与任务不匹配的工具。解决方案是工具加载管理：利用RAG技术为每个特定任务只选择最相关的工具，并将选择的工具数量控制在30个以内。
参考资料
- Context Engineering: A Guide With Examples, Bex Tuychiev,
- https://www.datacamp.com/blog/context-engineering
