随着大模型能力的快速发展，人们对大语言模型的使用方式越来越多的从简单的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、扣子空间之类的这些产品时，看它很忙碌的样子，背后就经历了多个轮次的上下文调整，而这些上下文该以什么方式进行调整，背后对应的就是上下文工程。

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

简单说，可能会答非所问、结果不理想，就好像你让Agent帮你写新能源车方面的调研报告，结果它给你输出了一篇“当前该买什么车”的文章。这个问题的底层原因在于，虽然大模型的长上下文能力越来越强（可以参考使用RAG技术构建企业级文档问答系统：生成优化(1)超长上下文LLM vs. RAG了解这个能力的评估方式），但当你给它输入越来越长时，它会在某个点失去注意力，就像一个思维混乱的领导，一直在给下属安排任务，说了几个小时，下属很有可能在某个时间点懵了——这领导到底要让我干啥。

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

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

• 一个极端是过于复杂、脆弱的逻辑，期望能够让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中的指令对工具调用结果做处理（可以阅读动手学Agent：工具使用(2)工具使用基础来了解工具调用基础流程），既然已经有了模型处理结果，那原始的工具调用、工具调用结果信息就不再需要了，可以直接清除。

结构化笔记记录

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

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

像有些介绍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大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。 

 这份《LLM项目+学习笔记+电子书籍+学习视频》已经整理好，还有完整版的大模型 AI 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓