简介

文章详细介绍了上下文工程的概念及其与提示工程的区别，强调上下文工程是管理和维护LLM推理过程中最佳信息的策略集，涉及工具、参考资料和记忆等动态元素。文章探讨了构建有效上下文的技术方法，包括动态检索、压缩、结构化笔记记录和子智能体架构，以及上下文工程未做好可能导致的问题。上下文工程作为Agent开发者的必备技能，能帮助更好地发挥大模型潜能。

---

随着大模型能力的快速发展，人们对大语言模型的使用方式越来越多的从简单的ChatBot，变成了各种Agent，而一个新的术语——上下文工程（Context Engineering），也逐步取代了提示工程（Prompt Engineering）。

最近Anthropic发表了一篇文章，分享了他们在上下文工程上的探索，本文基于原文做了适当解读，大家可以点击“阅读原文”查看官方原始文章（Effective context engineering for AI agents）。

一、上下文工程和提示工程的区别

简单来说，提示工程重点关注的是为了获得最佳结果而编写和组织的LLM指令的方法，各种在公众号、B站、小红书上所介绍的如何在某一款软件中输入特定的指令从而能够获得某种效果的方法，都属于提示工程，它通常涉及需要完成的任务、任务的背景信息、如何更好的完成任务、哪些是禁止的、受众是谁等，例如如何使用AI写文章、如何去除AI味、如何使用豆包生成特定的图片等。

而上下文工程指的是，在LLM推理过程中，如何管理和维护要输入给LLM的最佳信息的策略集，之所以叫信息，而没有叫Prompt或者提示语，是因为在上下文工程中，除了涉及给LLM安排任务，还涉及到工具、当前任务所需要的参考资料、之前交互过程中的记忆等，参考资料和记忆其实也看做是背景信息，但与提示工程中背景信息的区别是他们通常是随任务动态变化的，我们以用户输入“帮我调研一下新能源车目前的发展状况，并根据调研情况对未来的发展趋势做一个判断”为例，对比提示工程和上下文工程的区别：

• 提示工程：豆包、元宝之类的软件所能接收到的全部输入就是“帮我调研一下新能源车目前的发展状况，并根据调研情况对未来的发展趋势做一个判断”，如果开启了联网搜索可能会搜索一些背景信息，然后把这些信息送入大模型，让大模型直接生成调研报告，这个地方可能存在的问题包括：

• 报告的受众是什么
• 报告的篇幅是多少
• 行文风格是什么
• 是只调研与提问语言相同的地区对应市场的发展情况，还是全球
• 报告所引用的参考文件需不需要再核实一下信息源的权威性
• ……

• 上下文工程：用户输入问题后，Agent首先会尝试理解问题，检查用户问题是否需要澄清，如果不需要，则可能会开启如下流程：

• 检索Agent的记忆，获取用户对报告生成的偏好
• 根据用户意图组织不同的工具列表，对于报告生成最常用的可能就是网络搜索、获取网络正文，除此以外一般还有文件系统读写、TODO读写等
• 组织System Prompt，告知模型要完成什么任务、哪些是硬性约束、哪些是尽量避免的、工具使用原则、输出结果格式等
• 如果用户在提问时提供了额外的参考资料，或者用户知识库中有对应的领域知识，加入模型上下文
• 将这些上下文送入模型后，根据模型响应来调整上下文，包括移除部分工具、移除不需要的参考资料、对历史消息压缩等，并发起下一轮LLM调用

简而言之，提示工程更多的是说，作为一个用户，我该怎么组织输入，才能用好大模型，普通用户是可能会涉及的，只要你能够根据你的输入、大模型的响应来调整你的输入，让结果变得更好，那你就是在做提示工程的事情。

而上下文工程，更多的是某个Agent产品背后所用到的技术，普通用户是不会接触到的，同样是为了让结果变得更好，但它会使用更多的技术手段来组织模型的输入（上下文），涉及到更广阔的调整空间，因此会更底层，它主要是由Agent开发人员来进行的。

下图是Anthropic给出的提示工程和上下文工程的对比图：

对提示工程而言，使用编写好的提示语（Prompt）通常在一个轮次就可以得到结果，而上下文工程是迭代性的，它通常需要根据LLM的响应动态组织上下文，大家使用Manus、扣子空间之类的这些产品时，看它很忙碌的样子，背后就经历了多个轮次的上下文调整，而这些上下文该以什么方式进行调整，背后对应的就是上下文工程。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

二、上下文工程没做好会有什么问题

简单说，可能会答非所问、结果不理想，就好像你让Agent帮你写新能源车方面的调研报告，结果它给你输出了一篇“当前该买什么车”的文章。这个问题的底层原因在于，虽然大模型的长上下文能力越来越强，但当你给它输入越来越长时，它会在某个点失去注意力，就像一个思维混乱的领导，一直在给下属安排任务，说了几个小时，下属很有可能在某个时间点懵了——这领导到底要让我干啥。

三、有效上下文应该是什么结构

简而言之，有效的上下文应该是不长不短，恰到好处。在这里有两个极端：

• 一个极端是过于复杂、脆弱的逻辑，期望能够让Agent精确按期望行动，但这种方式通常会造成脆弱性，一旦条件不满足，则会呈现垮塌的态势，而且随着时间推移会增加复杂性，比如“帮我判断一下这个句子好不好，如果…那么，如果…那么，如果…那么，如果…那么，如果…那么，如果…那么，如果…那么……”，作为一个人看到如此复杂的指令，恐怕都很难不出错
• 另一个极端是过于模糊、高层次的指示，比如“帮我判断一下这句话好不好”

Anthropic建议将提示语（这里更多的是指系统提示语System Prompt）组织成不同的部分，比如 <background_information> 、 <instructions> 、 ## Tool guidance 、 ## Output description 等，并使用XML 标签或 Markdown 标题等技术来区分这些部分。

无论怎么构建系统提示语，都应该完整地概述你的预期行为，这是最核心的信息。

Anthropic在实践中观察到，构建Agent最常见的失败模式之一是工具集冗余，导致模型在工具选择上出现困难。如果人类工程师在给定相关信息后无法判断该什么工具，那也别指望人工智能做得有多好。

提示样例，或者小样本提示（Few Shot），是一种众所周知的最佳实践，联想上面提到的过于复杂、脆弱的逻辑，开发者倾向于往提示中加入各种边缘判断情况，试图把LLM在特定情况下应遵循的所有规则都加入进去，Anthropic不建议这样做，建议使用提示样例。

四、如何构造有效的上下文

这里的核心，是需要对上下文做动态检索。

Claude Code的实践经验就是，将所有需要的数据进行预先处理，模型上下文中只保留这些处理结果的标识符（例如文件路径、存储插叙、网页链接等），让智能体采用按需取用的方式，通过工具动态将数据加载到上下文中。

这样会使上下文的使用效率很高，同时，放入上下文的引用元数据，还提供了额外的信息，例如文件夹的层级结果、文件名、时间戳等，它能帮助人类和Agent理解何时该如何使用信息。

让Agent自主探索和检索数据，还能实现额外的好处，例如文件大小通常暗示了文件的复杂性（越大的文件越复杂）、命名规范暗示了文件的用途（例如test.py结尾的文件可能是测试文件），这些信息，都可以让Agent在运行时自主探索，逐渐理解，仅在上下文中保留必要的信息，避免上下文被大量可能无关的信息淹没。

当然这种动态导航和探索的方式也不是没有缺点，最主要的一点就是，它会比直接加载预计算好的信息慢。

Anthropic的实践是采用混合策略，像CLAUDE.md（里面一般会有开发需要用到的配置信息、开发规范等）这样的文件，会直接加载入上下文，而其他信息，则会在需要的时候，通过glob、grep等工具动态检索。

混合策略算是效率和效果的一种平衡，可以理解成高频要用的信息，直接加载入上下文，不要再浪费时间探索了，低频信息采用动态检索的方式，这跟计算机压缩算法中，高频字符用短编码，低频信息用长编码的做法真是有异曲同工之妙。

压缩

压缩是指对接近模型最大上下文长度时对对话进行内容总结，并重新初始化一个新的上下文窗口。压缩通常作为上下文工程的第一种手段，以提升长期连贯性。其核心在于以高保真方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续执行。

像在Claude Code中，就会在上下文长度达到模型最大上下文长度的92%时自动压缩，通过将消息历史传递给模型来实现这一点，以总结和压缩最关键的信息。模型保留了架构决策、未解决的错误和实现细节，同时丢弃了冗余的工具输出或消息。

压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能导致后来才显现重要性的关键的上下文信息丢失。对于实施压缩系统的工程师，建议在复杂的Agent构建时仔细调整Prompt。调整Prompt时，首先从确保压缩后能最大化召回所有相关信息开始，然用开始迭代，通过逐步删除冗余内容的方式来提高精确度。

这个方法挺值得借鉴的，因为很难一次性写出一个完美的压缩Prompt，甚至你可能都不知道该怎么评价这个Prompt的好坏，这里给出的方法就是把目标分解成先确保信息少丢失（最大化召回），再权衡（还要精准），给出了一个清晰可操作的流程。 有点像分类模型调整分类阈值，先保Recall，然后开始提高分类阈值，让Precision升高、Recall下降别太多，来寻找一个最佳决策点。

一个可摘取的低垂果实是，清理工具调用和调用结果，为什么？因为调用工具通常是为了使用工具调用结果，一般大模型都会根据System Prompt中的指令对工具调用结果做处理（，既然已经有了模型处理结果，那原始的工具调用、工具调用结果信息就不再需要了，可以直接清除。

结构化笔记记录

结构化笔记记录，或代理式记忆，是一种技术，其中代理定期将笔记保存在上下文窗口之外的存储（例如硬盘）中，这些笔记在稍后会被拉回上下文窗口。

把大模型的上下文窗口想象成电脑的内存，把上下文窗口之外的存储想象成硬盘，就好理解了，跟电脑内存不足，把内存中的页先交换到硬盘的真是一样一样的。

像有些介绍Cursor、Roo Code、Claude Code的教程，一开始先让Agent生成需求文档、设计文档和待办事项，并写入硬盘的做法，都属于这一类，在后续某个步骤需要这些内容时，再加载回上下文。

此处不知道大家有没有疑问，把原来一整段的内容先写入硬盘，需要的时候再读取回来放入上下文，上下文窗口不一样会变长吗，跟直接放到上下文中有啥区别？核心是Agent一般都会有文件读写的工具，而文件读取后，在大模型消化完这个信息后，读取的内容就可以丢弃了（回想一下上面提到的清理工具调用结果的部分），举个例子就好理解了，比如代码智能体前期做好了系统设计，并将设计文档写入了硬盘，等开始实现用户管理模块时，它只需要先检索到这部分内容（或者粗暴点，直接整个设计文档加载入上下文），那么当智能体将用户管理模块编码完成后，这个设计文档的内容就可以移出上下文了，所以这种按需取用的方式，可以显著降低上下文占用。

子智能体架构

原文中所说的这种子智能体架构模式（Sub-agent architectures），是多智能体架构中常见的一种设计方式，它通常由主智能体（Orchestrator）、子智能体组成。由主智能体分拆协调任务、子智能体处理特定任务。

这种架构最核心的作用是上下文隔离，这种方式从某种角度上看其实是扩大了模型所能支持的最大上下文长度，相当于把之前巨长、可能已经超过模型最大输入长度的上下文，分成了不同的部分，每个部分都不会超长，同时缓解了信息过载对模型造成的认知负担。

通过给每个智能体组织不同的上下文，让它集中所有能力解决它的问题，从而可以带来比单智能体更好的效果。

当然它的实现也是有挑战的，否则现在所有的智能体架构都是多智能体架构了，比如有如下几点：

• 任务拆分：主智能体在向各子智能体安排任务时，如何做到不重不漏，任务依赖关系合理，重复以外这更长的耗时和更多的token消耗，遗漏意味着最终任务可能无法完成，依赖关系不合理意味着某个智能体可能会存在信息缺失风险
• 上下文传递：主智能体安排了若干子智能体完成不同的任务，如何很好地将子智能体的结果传递给别的子智能体，比如编写一份调研报告时，报告撰写智能体已经完成了初版报告，审阅智能体看到后提出意见“调研报告不够全面，为什么报告中有中国市场、日韩市场、欧洲市场、东南亚市场相关的调研结果，没有北美市场的”，它不知道的是，报告撰写智能体其实调研了北美市场，只是没有找到相关信息
• 结果整合：任务拆解让各子任务完成时，肯定是希望最终解决用户原始问题的，但各子智能体的处理结果，很有可能互相之间是没有关联的，比如目标是开发一个FlappyBird游戏，一个子智能体负责生成能够上下移动不断前进的小鸟，一个负责生成有一些烟囱的草坪，当这两者整合时，发现生成草坪的智能体，生成的是类似超级马里奥那样的草坪，两者根本无法整合（案例来自https://cognition.ai/blog/dont-build-multi-agents）

上下文工程目前还是一个快速发展的技术领域，用好它，可以激发出大模型的巨大潜能，正如Andrej Karpathy 所说：上下文工程是一种微妙的艺术和科学（a delicate art and science）。

五、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

01.大模型风口已至：月薪30K+的AI岗正在批量诞生

2025年大模型应用呈现爆发式增长，根据工信部最新数据：

国内大模型相关岗位缺口达47万

初级工程师平均薪资28K（数据来源：BOSS直聘报告）

70%企业存在"能用模型不会调优"的痛点

真实案例：某二本机械专业学员，通过4个月系统学习，成功拿到某AI医疗公司大模型优化岗offer，薪资直接翻3倍！

02.大模型 AI 学习和面试资料

1️⃣ 提示词工程：把ChatGPT从玩具变成生产工具
2️⃣ RAG系统：让大模型精准输出行业知识
3️⃣ 智能体开发：用AutoGPT打造24小时数字员工

📦熬了三个大夜整理的《AI进化工具包》送你：
✔️ 大厂内部LLM落地手册（含58个真实案例）
✔️ 提示词设计模板库（覆盖12大应用场景）
✔️ 私藏学习路径图（0基础到项目实战仅需90天）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】