简而言之
上下文工程是指决定在语言模型工作的每一步中，哪些信息（指令、工具、示例、检索到的文档、对话历史和记忆）能够传递给它，从而使其拥有所需的信息，而几乎没有冗余。提示词工程是其中的一部分。当工作跨越多个会话时，记忆就是上下文的来源。
术语的来源
Anthropic 的工程团队在 2025 年 9 月的一篇博文中给出了最清晰的定义之一。“在 Anthropic，我们将上下文工程视为提示词工程的自然演进。”他们写道，提示词工程是关于编写和组织指令。而上下文工程“是指在 LLM 推理过程中，策划和维护最佳 Token（信息）集的一系列策略，包括可能落在提示词之外的所有其他信息。”
这种转变的发生是因为智能体是在循环中工作的。同一篇博文解释说：“在循环中运行的智能体会产生越来越多可能与下一轮推理相关的数据，这些信息必须循环提炼。”这使得这项工作具有持续性：“上下文工程是一门艺术和科学，旨在从不断演变的可能性信息宇宙中，策划出将进入有限上下文窗口的内容。”
因此，两者的区别在于范围和时机。提示词工程是你在对话前做一次的事情。而上下文工程则发生在智能体每次决定下一步要看什么的时候。
智能体的上下文中包含什么
Anthropic 列出了智能体工作所需的组成部分：“系统指令、工具、Model Context Protocol (MCP)、外部数据、消息历史等。”在实践中，大多数智能体依赖五种上下文。
指令。 系统提示词，以及编码智能体在会话开始时加载的类似 CLAUDE.md 或 AGENTS.md 的文件。
工具。 智能体可以执行的操作的定义，这些定义本身也会占用空间。Anthropic 警告说：“我们看到的最常见失败模式之一是工具集臃肿，涵盖了太多功能，或者导致在决定使用哪个工具时产生模糊的决策点。”
示例。 一组精简的经典示例，而不是穷尽所有的边缘情况。
检索到的信息。 在需要时拉取的文档、搜索结果和数据。
历史与记忆。 本次会话中之前发生的事情，以及在之前会话中学习到的内容。
好的上下文工程主要在于这些要素之间的平衡。Anthropic 的指导原则是：“好的上下文工程意味着寻找尽可能最小的高信号 Token 集，以最大化实现某种预期结果的可能性。”
为什么更大的上下文工程并不是解决方案
人们很容易认为，更大的上下文窗口会让这一切变得毫无必要。Anthropic 则持相反观点，并指出了其所谓的上下文腐烂（context rot）现象：“随着上下文窗口中 Token 数量的增加，模型从该上下文中准确召回信息的能力会下降。”他们的结论是：“因此，必须将上下文视为一种边际收益递减的有限资源。”
Claude 开发者平台的上下文编辑文档从产品角度阐述了同样的观点：“上下文是一种收益递减的有限资源，不相关的内容会降低模型的专注度。”Anthropic 的工程博文补充道：“在可预见的未来，各种大小的上下文窗口可能都会受到上下文污染和信息相关性问题的影响。”
阿里巴巴从企业端也得出了相同的结论。在云栖大会的主题演讲中，其观点是：你不能直接把一个公司的所有数据都灌进智能体里并期望它能正常工作；让窗口过载会浪费智能体执行任务所需的空间，因此必须先将数据压缩分层。
这也是为什么仅靠缩短提示词无法解决成本或质量问题的原因，这一观点在为什么更短的提示词还不够中进行了探讨。问题不在于你发送的信息有多么少，而在于你发送的信息是否正确。
跨越单一上下文窗口限制的三种技术
对于长期任务，Anthropic 描述了三种方法：“压缩（compaction）、结构化记笔记（structured note-taking）和多智能体架构（multi-agent architectures）”。
压缩。 “压缩是指在对话接近上下文窗口限制时，对其内容进行总结，并使用该总结重新启动一个新的上下文窗口。”它能让工作继续进行，但也存在已知风险：“过于激进的压缩可能会导致丢失微妙但关键的上下文，而这些上下文的重要性只有在以后才会显现出来。”
结构化记笔记。 “结构化记笔记，或智能体记忆（agentic memory），是一种智能体定期将笔记持久化保存到上下文窗口之外的记忆中的技术。这些笔记会在稍后被重新拉回到上下文窗口中。”待办事项列表或 NOTES.md 文件就是其简单版本。
子智能体。 “专门的子智能体可以使用干净的上下文窗口处理专注的任务”，仅将压缩后的结果返回给主智能体。
这三种方法中还贯穿着一种检索模式。智能体不是预先加载所有内容，而是“维护轻量级标识符（文件路径、存储的查询、网页链接等），并在运行时使用工具动态地将这些引用数据加载到上下文中。”Claude Code 是 Anthropic 自身混合模式的一个例子：“CLAUDE.md 文件在开始时被直接放入上下文中，而像 glob 和 grep 这样的原语则允许它浏览其环境并即时检索文件。”
检索并不等同于记忆，尽管两者经常被混淆。AI 记忆与 RAG 的对比详细介绍了这两者的区别。
为什么“上下文就是你所需的一切”成为了企业争论的焦点
2026 年 9 月，上下文工程从工程博客走向了公司战略。Alibaba Cloud 将其智能体云描述为“围绕三个核心场景构建——模型、控制台和上下文”，并推出了智能体上下文（Agent Context）服务，“为 AI 智能体提供实时上下文和长期记忆”。Qianwen Office 推出了一款名为企业上下文（Enterprise Context）的配套产品，这就是当范围扩大到整个公司时，AI 智能体的上下文层所呈现的样子。
Qianwen Office 的主题演讲将该问题的企业版分为三个部分：不了解业务的智能体、留在个人手中的实用诀窍，以及对数据安全的顾虑。提出的解决方案是以压缩为中心，连接公司数据、理解数据并使其可重用。
最有趣的观点来自随后的一次采访。Qianwen Office 副总裁舒俊良表示，上下文“与你最终使用的智能体是解耦的”，并且公司的上下文“必须属于这个企业”。他补充说，这种基础设施“还没有像数据库那样标准化”。
这就是每个上下文工程师最终都会遇到的原则的企业形式。上下文是按步骤组装的，但组装它所依据的知识是有所有者的，而这个所有者很少是智能体本身。
记忆在何处发挥作用——以及为什么它必须比智能体存活得更久
上下文工程决定了什么进入窗口。一旦工作跨越多个会话，记忆就是大部分内容的来源。一些作者现在将这后半部分称为记忆工程（memory engineering）：上下文工程在推理时起作用，而记忆则跨越时间起作用。
问题在于，如今的大多数记忆机制都与单一工具或单一位置绑定。
Claude Code 的自动记忆是一个具有清晰边界的合理设计范例：“自动记忆是机器本地的”，并且“文件不会在机器或云环境之间共享”。Anthropic 面向开发者的记忆工具在让你掌控主动权方面走得更远：“记忆工具在客户端运行：Claude 请求文件操作，而你的应用程序执行这些操作。你通过自己的基础设施控制数据的存储位置和方式。”在同一页面中，边界被清晰地陈述：“记忆完全存在于你的应用程序中。”Anthropic 的托管存储如何处理这一问题在解析 Claude 智能体记忆存储中进行了介绍。
消费级工具也划定了自己的界限。例如，在 ChatGPT 中，共享项目“无法访问单个成员在项目之外的上下文、自定义指令或记忆”。
这些都不是缺陷。每个边界都保护着一些东西——隐私、范围、可预测性。但它们共同意味着，智能体所需的知识分散在与你使用的工具一样多的地方。一个运行三个智能体的团队拥有三个不完整的记忆，每个记忆都受制于某个产品的规则。
这就是阿里巴巴采访中所指出的差距。如果上下文应该与智能体解耦，那么它所依赖的记忆也应该解耦。哪些类型的记忆重要是一个独立的主题，在 AI 记忆的六种类型中进行了阐述；这里的实际重点在于它们存放在哪里。
如何将上下文工程应用于你自己的智能体
你不需要框架就可以开始。三个步骤就能涵盖大部分价值。
步骤 1：区分常驻上下文与工作上下文
列出每个会话开始时应具备的内容：工作是为谁做的、约定、已确定的决策、任何模型都无法猜测的定义。这就是常驻上下文。然后列出任务在进行过程中拉取的内容：文件、搜索结果、最近的历史记录。这就是工作上下文。
常驻上下文属于指令和记忆。工作上下文应该即时检索。将两者混淆是智能体要么遗漏关键事实、要么淹没在不相关事实中最常见的原因。
步骤 2：将常驻上下文压缩分层
先写一个简短的索引，然后为每个项目、决策或流程写一个紧凑的条目，最后是源文档。为条目注明日期，以便较新的决策明显取代较旧的决策。保持示例的经典性，而不是面面俱到。
克制住保存一切的冲动。更多的记忆是否对智能体有帮助是一个现实问题，在应该给 AI 智能体多少记忆中进行了探讨。
步骤 3：将常驻上下文存储在每个智能体都能访问的地方
这是大多数配置都会跳过的步骤。如果你的常驻上下文存在于一个工具的记忆中，那么其他所有智能体在启动时都无法获取它。将其保存在任何单一产品之外的一个层中，并通过向两个不同的智能体询问关于你工作的同一个问题来进行测试。如果只有一个智能体知道答案，那么上下文就存在于该工具中。
在 MemoryLake 中进行设置
步骤 3 描述了一个属于你而不是智能体的记忆层。MemoryLake 就是为此而构建的：为 AI 智能体提供独立于任何单一工具之外的长期记忆，这样你设计过一次的常驻上下文就可以供你使用的每个助手使用。
你自己用自己的语言编写条目。不会从 Claude Code 的记忆目录、你智能体自身的存储或任何供应商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥属于你在记忆层中的工作区，独立于任何单一智能体或模型。
步骤 2：上传你的第一批记忆
从步骤 1 中的常驻上下文和步骤 2 中的分层条目开始：定义、已确定的决策、约定。每个条目一个事实，并注明日期。
步骤 3：连接你的 AI 和智能体
连接你使用的助手和智能体。然后，每一个都可以利用相同的常驻上下文，这在设计上就通过了解耦测试。
上下文工程的最佳实践
将上下文视为预算。 每个 Token 都在争夺模型的注意力；只保留真正有价值的内容。
保持工具精简且职责明确。 重叠的工具会给智能体带来模糊的选择。
即时检索工作上下文。 在任务需要时加载文件和数据，而不是预先加载。
谨慎压缩。 总结能让工作继续进行，但可能会遗漏以后才会显现其重要性的细节。
在窗口之外写笔记。 结构化笔记能让智能体在中断的地方重新开始。
保持常驻上下文独立于任何单一工具。 存在于一个产品内部的记忆只能帮助该产品。在决定保存什么时，值得记住智能体所说的和所做的之间的区别，这在AI 智能体的情景记忆中有所涵盖。
结论
上下文工程是提示词工程的自然继承者：在庞大但有限的窗口内，决定智能体在每一步中看到什么。Anthropic 的原则总结了这一点——寻找“尽可能最小的高信号 Token 集，以最大化实现某种预期结果的可能性”。
这些技术很容易理解：压缩、结构化笔记、子智能体和即时检索。尚未确定的是这一切背后的知识应该存放在哪里。Alibaba Cloud 的口号“Context is All You Need”也承认了上下文基础设施尚未标准化。
在此之前，实用的规则很简单。按步骤设计上下文，但将它所依赖的常驻知识保存在你拥有的一个地方，供你使用的每个智能体访问。有关该层的更广泛介绍，请参阅什么是 AI 记忆。