简介

文章探讨上下文工程作为提示工程的自然演进，强调其在构建AI Agent中的重要性。由于LLM上下文窗口有限且边际回报递减，随着上下文长度增加，模型准确获取信息能力会降低。文章详细介绍系统提示词设计、工具设计、示例提供和上下文检索策略，以及针对长期任务的上下文管理技术如压缩、结构化笔记和子代理架构，旨在帮助开发者最大化利用有限注意力预算构建更可靠的AI Agent。

---

如果你想了解关于Agent的Context Engineering的相关内容，比如：

1、上下文工程 vs 提示工程的演进由来

2、为什么上下文工程对于构建Agents的能力如此重要

3、上下文工程的使用细节

那可以看下这篇文章，有点长，不过会有很大收获。这篇博客是Anthropic在2025.9.29发布的Effective context engineering for AI agents的译文

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

正文

之前在AI应用领域一直使用提示词工程（Prompt Engineering），最近又有了一个新的名词：上下文工程（Context Engineering）。以前大家都在绞尽脑汁的想提示词，考究各种的短语专业名词，怎么才能找到合适的提示词得到更好的回复。现在更多的时候都在想哪种上下文配置才能使得模型产出期望的行为。

上下文（Context）指的是从大语言模型（LLM）中获得的一系列tokens集合。现在的工程问题是，在大语言模型（LLM）的固有约束下，优化这些tokens，使其产生一致的期望结果，而不是像抽卡那样。也就是说有了上下文（context）在任何时候大语言模型（LLM）输出的状态最好是稳定的。

【注】Tokens：可以理解为模型处理信息的基本单位，通常由单词、子词或字符经过分词算法（如BPE）产生。例如，句子“我爱学习”可能被分词为[“我”, “爱”, “学习”]这三个token。

具体可以通过 (https://platform.openai.com/tokenizer) 查看一段文字会产生多少token

在这篇文章中，将探讨这个上下文工程（Context Engineering），并且提供一个构建可操作、有效的Agent指导思想。

上下文工程与提示词工程

在Anthropic，我们认为上下文工程（Context Engineering）是提示词工程（Prompt Engineering）的自然发展。提示工程指的是编写和组织LLM指令以获得最佳结果的方法。可参考 (https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview)。上下文工程（Context Engineering）指的是在LLM推理过程中，管理和维护最佳Tokens的策略集合，包括所有可能出现在提示之外的其他信息。

在LLMs工程初期，提示词（Prompt）是AI工程工作的最大组成部分，因为除了日常聊天之外的大多数用例都需要针对单次分类或文本生成任务进行优化的提示。提示词工程（Prompt Engineering）的主要焦点就是如何编写有效的提示，特别是系统提示（System prompt）。但是，随着我们面向工程化的发展，需要运行的Agent能够在多个推理回合和更长的时间范围内执行任务，就需要一系列管理整个上下文状态（系统指令、工具、模型上下文协议MCP、外部数据、历史消息等）的策略。

一个运行中的Agent是会在循环中不断的产生越来越多的数据，这些数据也会对下一次的推理产生影响，这些信息必须周期性的进行精炼。上下文工程（Context Engineering）就是在有限的大语言模型（LLM）的上下文窗口大小中整理不断产生变化的信息的艺术科学。

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

这是Andrej Karpathy在之前X上的推文。

与编写提示的离散任务相比，上下文工程是迭代的，每次我们决定传递给模型的内容时都会发生整理阶段。

【注】

提示词工程（Prompt Engineering）可以理解为，给每个任务单独提供的个性化输入，换个任务就得重新写一次，不能复用。

上下文工程（Context Engineering）可以理解为，是一个系统性的可复用的，带有前因后果的一大串信息，并且可以动态更新。

为什么上下文工程对于构建有能力的Agent很重要

虽然LLMs可以快速的处理越来越多的数据量，但是LLMs就像人类一样，在某个点会开小差或者迷茫。在Context Rot: How Increasing Input Tokens Impacts LLM Performance（ https://research.trychroma.com/context-rot ）文中的needle-in-a-haystackstyle基准测试中发现：随着上下文窗口中tokens的增加，模型从当前上下文窗口中准确获取信息的能力会降低。

虽然可能有一些模型比其他模型表现出更温和的退化，但是这种特征在所有模型中都出现了。大语言模型的上下文（Context）是一种有限的资源，它的边际回报递减。就像人类的记忆一样，大部分的记忆力是有限的。LLMs在解析大量上下文时有一个“注意力预算”。引入的每个新token都会以某种程度消耗这个预算，因此会增加LLMs在输出token时的负担，也就是会出现不准确的情况。

这种注意力稀缺来自LLMs的架构限制。LLMs基于Transformer架构 (https://arxiv.org/abs/1706.03762) ，因为Transformer架构的注意力机制(https://huggingface.co/blog/Esmail-AGumaan/attention-is-all-you-need) ，每个token都会关注到整个上下文中的其他token，导致了n个token之间的n2对数关系。

随着上下文长度的增加，模型捕捉这些成对关系的能力变得薄弱，从而在上下文大小和注意力之间产生问题。另外，模型在训练的时候，由于训练数据的数据集差异，其中较短的序列通常比较长的序列更常见，导致模型在长上下文范围内的依赖关系经验较少，且具有较少的专门参数。

虽然通过位置编码插值 (https://arxiv.org/pdf/2306.15595) 可以用来调整适应最初训练的较小上下文来处理更长的序列，但是会在token位置理解方面有一些退化。也就是模型在较长的上下文中仍然非常高效，但与较短的上下文相比，在信息检索和长距离推理方面可能表现出较低的精度。

基于以上分析，通过精心构建的上下文对于构建有能力的Agent是至关重要的。

有效上下文解剖

鉴于LLMs受限于有限的注意力预算，良好的上下文工程（Context Engineering）需要找到尽可能小的且高效的tokens，从而最大化某些期望结果的可能性。要实现这一做法，说起来容易做起来难，在后面，将概述这一指导原则在不同上下文组件中的实际意义。

系统提示词（System prompt）应该非常清晰，并且使用简单、直接的语言，表达出Agent的真实想法意图。在一种极端情况下，我们能看到工程师在提示词中硬编码复杂的逻辑想要Agent得到精确的行为。这种方法会随着需求的增加和时间的推移增加维护的复杂性。另一种极端情况下，工程师有时提供模糊的、抽象的指导，没有给LLM提供必要的相对具体的上下文信息或者是错误的共享上下文，导致得到的结果不符合预期。为了达到最佳平衡，需要足够具体有效的指导行为，同时还要灵活，为模型提供强大的启发式方法来指导输出。

我们建议将提示词组织成不同的部分（如<background_information>、、## Tool guidance、## Output description等），并且使用XML标签或Markdown标题等方法来区分这些部分，虽然随着模型能力的提升，提示的确切格式可能变得越来越不重要，但是这也是一种好的组织方式，方便后期维护修改。

无论你如何决定构建系统提示词的结构，都应该努力追求最小化的一组信息，这组信息能够完全表达出来你期望的行为。（最小化并不意味着简短，还是需要提前给Agent足够多的信息，确保能够输出你期望的行为）最好的做法是先使用最佳模型测试一个最小提示，看看它在你的任务上表现如何，然后根据初始测试中发现的失败模式添加清晰的指示和示例，以提高性能。

工具（Tools）使Agent能够在操作环境中运行，并在工作过程中添加新的额外的上下文。由于工具（Tools）定义了Agent与其信息/动作空间之间的契约，所以工具促进效率至关重要，这不仅能够返回有效信息还能鼓励Agent的行为。

在《为 AI 智能体编写工具——与 AI 智能体一起》中 (https://www.anthropic.com/engineering/writing-tools-for-agents)中讨论了构建LLMs能够很好理解且功能重叠的最小工具。和良好设计的代码库功能类似，工具应该是自包含的、健壮的、能够处理错误，并且在使用意图上非常清晰。输入参数应该同样具有描述性、明确，并且发挥模型的固有优势。

最常见的问题就是，给模型一大堆的工具集，就会导致过多的功能和工具的描述会存在歧义，使得Agent无法清晰明确的调用想要的工具。如果人类工程师都无法明确地说在特定情况下应该使用哪个工具，那么期望Agent做得更好是不现实的。我们后面将要讨论的，给Agent精选一套最小可行工具可以使得Agent在长时间交互中更可靠的维护和修剪上下文。

提供示例，也就是少样本提示（few-shot prompt）是一种众所周知的好做法，我们继续强烈建议这么做。但是，有的团队会将一系列边缘情况塞入提示词中，试图让LLM在特定任务中遵循每一个可能的规则。我们是不推荐这样做的。相反，我们建议尽可能整理一组多样化的、典范的示例，这些示例能够有效地描绘出Agen的预期行为。对于LLM来说就像一图胜千言一样。

以上是我们针对不同组件的上下文（系统提示词、工具、示例、历史消息等）的整体指导原则，接下来让我们深入了解在运行时的动态检索上下文。

上下文检索和Agent搜索

在构建有效的AIAgent (https://www.anthropic.com/engineering/building-effective-agents)时，我们强调了基于LLM的工作流和Agent之间的差异。自从我们写了那篇文章之后，我们能倾向于为Agent给出一个简单的定义：LLM自主地在循环中使用工具

与我们的客户合作，我们看到了这个简单范式在该领域的趋同。随着底层模型能力的提升，Agent的自主程度可以扩展：更智能模型允许Agent独立地导航复杂问题并且能够从错误中恢复。

我们现在看到工程师在设计Agent上下文时的思维方式发生了转变。现在，许多AI原生应用采用基于嵌入的预推理时间检索形式，以呈现对代理推理重要性的上下文。随着该领域向更多代理方法转变，我们越来越多地看到团队通过“即时”上下文策略来增强这些检索系统。

而不是预先处理所有相关的数据，采用“即时”方法的Agent维护轻量级标识符（文件路径、存储查询、网页链接等），并使用这些引用在运行时通过工具动态将数据加载到上下文中。Anthropic的Agent编码解决方案Claude Code采用这种方法在大型数据库上执行复杂的数据分析。该模型可以编写针对性查询、存储结果，利用head和tail等Bash命令分析发量数据，而无需将完整的数据对象加载到上下文中。这种方法反映了人类认知：我们通常不会记住整个信息库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以便按需检索相关信息。

除了存储效率之外，这些引用的元数据提供了一种机制，可以明确直观有效的细化行为。对于一个文件系统中运行的Agen来说，名为test_utils.py的文件位于tests文件夹中，与位于src/core_logic.py中的同名文件具有不同的目的。文件夹层级结构、命名约定和时间戳都提供了重要的信息，帮助人类和Agent理解如何以及何时利用信息。

允许Agent通过自主导航和检索数据，探索逐步发现相关上下文。每次交互都会产生上下文，为下一次决策提供信息：文件大小暗示复杂性；命名规范暗示目的；时间戳可以代表相关性。Agent可以逐层构建理解，只在工作记忆中保留必要的部分，并利用笔记策略进行额外的持久化。这个自我管理的上下文窗口使Agent专注于相对子集，而不是淹没在无关的信息海洋中。

当然这里有一个权衡：运行时检索比检索与计算数据要慢。不仅如此，还需要有见地和深思熟虑的工程实践，以确保LLM拥有有效导航其信息的正确工具和启发式方法。如果没有适当的指导，Agent可能会通过误用工具、钻牛角尖或未能识别关键信息从而浪费了上下文。

在某些环境中，最有效的智能体可能会采用混合策略，提前检索一些数据以提高数据，并在其自主判断下进行进一步探索。决定“正确”自主程度的界限取决于任务。Claude Code是一个采用这种混合模型的Agent：CLAUDE.md文件被提前放入上下文中，像glob和grep这样的原始命令允许它导航其环境并即时检索文件，有效地绕过过时检索和复杂语法树的难题。

混合策略可能更适合内容动态性较低的环境，例如法律或金融工作。随着模型能力的提升，Agent的设计趋势将倾向于让Agent模型智能行动，人类干预逐渐减少。鉴于该领域的进展速度，对于在Clause之上构建Agent的团队来说，“做最简单可行的事”可能仍然是我们的最佳建议。

长期任务的上下文工程

长时间的任务要求Agent在超过LLM上下文窗口的序列动作动作中保持连贯性、上下文和目标导向的行为。对于连续工作数十分钟到数小时的任务，如大型代码库迁移或全面的研究项目，Agent需要专门的技巧来克服上下文窗口大小的限制。

等待更大的上下文窗口似乎是一种明显的策略。但很可能在可预见的未来，所有大小的上下文窗口都将受到上下文污染和信息相关性问题的困扰–至少对于需要最强代理性能的情况是这样。为了使Agent能够在较长时间范围内有效工作，我们开发了一些直接解决这些上下文污染约束的技术：压缩、结构化笔记和多代理架构。

压缩

压缩是将接近上下文窗口限制的对话内容进行总结，并使用总结内容重新启动一个新的上下文窗口的做法。压缩通常作为上下文工程中的第一个杠杆，以驱动更好的长期一致性。在本质上，压缩以高保真度提炼上下文窗口的内容，使代理能够以最小的性能下降继续进行。

在Claude Code中，例如，我们通过将历史消息传递给模型来总结和压缩最关键细节来实现这一点。模型保留架构决策、未解决的bug和实现细节，同时丢弃冗余的工具输出或消息。然后，Agent可继续使用这个压缩后的上下文以及最近访问的五份文件。用户可以保持连贯性，无需担心上下文窗口的限制。

压缩的艺术在于选择保留什么丢弃什么，因为过于激进的压缩可能导致丢失微妙但至关重要的上下文，其重要性只有在之后才会显现。对于实施压缩系统的工程师，我们建议仔细调整对复杂代理跟踪的提示。首先，最大化召回率以确保你的压缩提示从跟踪中捕获每一条相关信息，然后迭代进行精确度，消除多余内容。

一个冗余内容示例是清除工具调用和结果–一旦工具在历史消息中深层次被调用，Agent为什么还需要再次看到原始结果呢？最安全的压缩形式之一是清除工具结果(https://www.anthropic.com/news/context-management)

结构化笔记

结构化笔记，或称代理记忆，是一种技术，其中代理定期将笔记持久化到上下文窗口之外的记忆中。这些笔记在稍后时间被拉回到上下文窗口中。

这种策略提供了具有最小开销的持久记忆。就像 Claude Code 创建待办事项列表，或者您的自定义代理维护 NOTES.md 文件一样，这种简单的模式允许代理跟踪复杂任务的进度，保持关键的上下文和依赖关系，否则这些关系会在数十次工具调用中丢失。

Claude玩宝可梦 (https://www.twitch.tv/claudeplayspokemon) 展示了记忆如何将Agent的能力转化为非编码领域。Agent在数千个游戏步骤中保持精确的计数——追踪目标如“在过去的 1,234 步中，我在 1 号道路训练我的宝可梦，皮卡丘已经提升了 8 级，朝着 10 级的目标前进。”无需任何关于记忆结构的提示，它就发展了探索区域的地图，记得它已经解锁的关键成就，并保持战略性的战斗策略笔记，帮助它学习哪些攻击对不同对手最有效。

在上下文重置后，Agent阅读自己的笔记并继续多小时的训练序列或地下城探险。这种在总结步骤中的连贯性使得在仅保留所有信息在 LLM 的上下文窗口中是不可能的长期策略成为可能。

作为我们 Sonnet 4.5 发布的部分，我们在 Claude 开发者平台上发布了公测版的记忆工具(https://www.anthropic.com/news/context-management) ，该工具通过基于文件的系统，使存储和查阅上下文窗口外的信息变得更加容易。这允许代理随着时间的推移建立知识库，在会话之间保持项目状态，并在不保持所有上下文的情况下参考以前的工作。

子代理架构

子代理架构为克服上下文限制提供了另一种方法。而不是一个代理试图在整个项目中维护状态，专门的子代理可以处理具有清晰上下文窗口的专注任务。主要代理与高级计划协调，而子代理执行深入的技术工作或使用工具查找相关信息。每个子代理可能广泛探索，使用数万个或更多的标记，但只返回其工作的浓缩、提炼总结（通常为 1,000-2,000 个标记）。

这种方法实现了关注点的清晰分离——详细的搜索上下文保持在子代理内部，而主代理则专注于综合和分析结果。在《我们如何构建我们的多代理研究系统》(https://www.anthropic.com/engineering/multi-agent-research-system) 一文中讨论的这种模式，在复杂的研究任务上比单代理系统有显著改进。

这些方法的选择取决于任务特征。例如：

• 压缩技术有助于保持需要大量来回交流的任务的对话流畅性；
• 笔记记录在具有明确里程碑的迭代开发中表现优异；
• 多智能体架构可以处理复杂的研究和分析任务，其中并行探索能带来回报。

即使模型持续改进，在延长交互中保持连贯性的挑战仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们在构建 LLMs 时的一种根本性转变。随着模型能力的提升，挑战不仅仅是制作出完美的提示——而是要深思熟虑地挑选出每一步进入模型有限注意力预算的信息。无论你是实施对长期任务进行压缩、设计高效能的标记工具，还是使代理能够即时探索其环境，指导原则始终如一：找到能够最大化你期望结果的最小高信号token集。

我们所概述的技术将随着模型的改进而持续发展。我们已经看到，更智能的模型需要更少的指令性工程，使得代理能够以更大的自主性运行。但即使能力扩展，将上下文视为宝贵且有限的资源仍将是构建可靠、有效代理的关键。

今天开始使用 Claude 开发者平台进行上下文工程，并通过我们的记忆和上下文管理 (https://github.com/anthropics/claude-cookbooks/blob/main/tool_use/memory_cookbook.ipynb) 获取有用的提示和最佳实践。

AI大模型学习和面试资源

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

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

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证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%免费】🆓