美国姓名的Gmail帐户
DESCRIPTION / 资源参数说明
最近，Prompt Engineering（提示词工程）的概念正在飞速演化。当许多人还在琢磨如何优化一句话的指令时，构建顶尖 AI 应用的前沿开发者们早已超越于此，进入了一个更为深邃和强大的新领域——Context Engineering（上下文工程）。
这个概念并非空穴来风，其核心思想最早由 AI 领域的顶尖专家、OpenAI 联合创始人 Andrej Karpathy 明确提出。他指出，人们常说的“Prompt”一词，实际上低估了其背后相当复杂的组件；真正的工业级应用并非简单地给模型一个提示，而是会（精心）为 LLMs 构建一个完整的“上下文系统”来解决定制任务。
那么，到底什么是上下文工程？它为何能决定一个 AI 应用的成败？本文将为您一一拆解，并用通俗易懂的方式，讲透其中的核心逻辑与实践策略。
在大型语言模型（LLM）的应用实践中，常常混淆“提示词工程”（Prompt Engineering）与“上下文工程”（Context Engineering）这两个概念。然而，这两者代表了LLM应用范式演进的不同阶段，且后者在构建具备长期记忆与自主决策能力的智能体时，扮演着更为核心的角色。
提示词工程主要关注单次、孤立的交互。其核心任务在于通过精心设计的输入（提示词、角色设定、少数样本示例等），以最有效的方式激发LLM的特定能力，从而获得高质量的即时输出。这是一种静态的、旨在优化LLM作为无状态函数调用的技术。与之形成鲜明对比的是，上下文工程则是一项系统性的工程学，其视角超越了单轮交互，聚焦于整个任务生命周期中信息的动态管理、表示与利用。它旨在为LLM智能体提供一个连续、可更新的“工作记忆”和“背景知识”，使其能够处理多步复杂任务、维护长期目标、并在不同回合的交互中保持连贯性。因此，上下文工程是实现LLM从一个无状态的“查询引擎”向一个有记忆、有目标、有状态的“智能体”（stateful agent）转变的基石。
为了更深入地理解上下文工程，有必要对上下文进行细致的分类。通常，上下文可以被划分为显式上下文与隐式上下文两大类。显式上下文（Explicit Context）： 这部分上下文是指在每次调用时直接作为输入注入LLM的外部信息流。它包括用户当前的输入、从外部知识库检索到的相关文档片段、工具调用所返回的结果、以及历史对话的精炼摘要等。显式上下文的作用类似于人类的“工作记忆”，它为LLM提供了完成当前步骤所需的即时、高保真信息。其质量和完整性直接决定了LLM在当前环节的推理准确性和输出质量。隐式上下文（Implicit Context）： 这部分上下文是指智能体在长期交互中逐步积累、但并未全部直接注入当前LLM调用窗口的背景知识。它包括用户的画像与偏好、任务的宏观目标与已完成进度、智能体自身的内部状态（例如，其正在执行的计划步骤）以及通过长期学习积累的通用知识或特定领域知识。隐式上下文的作用类似于人类的“长期记忆”或“背景认知”，它指导着智能体的行为和决策方向，确保其在多轮交互中保持目标一致性和行为连贯性。
显式上下文因其容量受限于LLM的Token窗口而易于管理，但其容量有限；而隐式上下文虽然容量几乎无限，但其有效编码、检索与利用却是一个巨大的技术挑战。
构建一个真正智能的LLM智能体，其核心任务正是解决如何在显式与隐式上下文之间进行高效、动态的转换与协同。这揭示了LLM智能体架构设计中的一个基本矛盾：即时性的、高保真的信息（显式）与长期的、高抽象度的知识（隐式）之间的权衡与融合。上下文工程正是旨在通过技术手段，系统性地解决这一深层次的矛盾。
在从概念走向实践的过程中，上下文工程面临着三重核心挑战，这些挑战并非孤立存在，而是相互关联、互为因果。容量限制（Capacity）： 这是最显而易见的挑战。传统的LLM因其Transformer架构的二次方复杂度，其上下文窗口长度存在固有的物理瓶颈。当交互或任务所需的信息量超出这一窗口时，就会发生不可避免的“信息遗忘”或“上下文丢失”，导致智能体的性能急剧下降。动态更新（Dynamicity）： 与容量限制紧密相关的是动态更新的难题。在多轮交互中，上下文是不断变化的。智能体不仅需要新增信息，还需要根据新的情况淘汰过时信息、更新错误信息、并对整个上下文进行凝练和重组。简单地追加信息会导致上下文窗口迅速被填满，而如何高效、智能地管理和更新这一动态信息流，而非仅进行简单的追加操作，是构建长时任务智能体的关键。多模态融合（Modality）： 随着LLM向多模态方向发展，上下文工程的挑战也进一步复杂化。未来的智能体需要处理并理解来自不同模态的信息，如文本、图像、音频、视频等。如何将这些异构信息统一表示、并在上下文中建立起有效的关联，以支持跨模态的复杂任务，不仅仅是Token数量的问题，更是一个关于知识图谱构建和高维信息编码的根本性挑战。
这三重挑战并非彼此独立。容量限制直接导致了动态更新的困难——当上下文不断增长时，我们无法将其全部塞入窗口，这反过来促使了压缩和摘要技术的发展。而多模态融合的挑战则进一步复杂化了上下文的表示和管理，因为它要求模型能够理解和关联来自不同感官的信息。
一个成功的上下文工程方案必须系统性地应对这三方面的挑战，而不仅仅是解决某一个点的问题。
本部分将深入探讨如何应对第一部分提出的技术挑战。我们将系统化地梳理当前主流的技术路径，并进行详细分析，以应对构建高效LLM智能体所面临的技术策略与挑战 。
根据LangChain团队提出的框架，上下文工程的实践策略可以归纳为四大支柱：写入（Write）、筛选（Select）、压缩（Compress） 和 隔离（Isolate） 。这些策略为构建上下文感知的智能体系统提供了全面的蓝图 。
1、写入上下文（Write Context）
核心思想： 将任务执行过程中产生的中间状态或关键信息存储到上下文窗口之外的持久化存储中，以备后续使用。这有效地为智能体创建了超越单次LLM调用的“记忆” 。
落地实践：草稿板（Scratchpads）： 类似于人类做笔记，智能体可以在任务执行过程中将想法、中间步骤或关键数据写入一个临时存储区，这个“草稿板”可以是文件系统中的一个文件，也可以是运行时状态对象中的一个字段 。例如，一个研究智能体在制定多步研究计划后，会将该计划写入记忆中，以防止其在后续的长篇幅交互中被截断或遗忘 。长期记忆存储（Memories）： 智能体需要将知识持久化，以便跨多个会话使用。这可以是通过Reflexion框架实现的“自我反思”式记忆 ，即智能体从过去的失败中学习并生成语言强化线索存储下来 ；也可以是像Claude那样的自动记忆摘要，系统会每24小时自动总结对话关键信息，为新会话提供上下文 。
核心思想： 从外部知识源或记忆存储中，动态地将与当前任务最相关的信息拉取到LLM的上下文窗口中 。这种“按需加载”的策略旨在为模型提供
恰到好处的信息，既避免信息不足，也防止不相关的信息引入噪声 。
落地实践：检索增强生成（RAG）： 这是最典型的筛选策略。通过从向量数据库等外部知识库中检索与查询相关的文档片段，为LLM提供事实依据和外部知识 。记忆检索： 如果智能体具备记忆存储能力，它需要能够筛选出与当前任务相关的记忆 。这可以通过语义相似性搜索来检索相关的“情景记忆”（如过去的用户对话）或“事实记忆”（如用户的偏好） 。工具筛选： 当智能体拥有大量可用工具时，一次性将所有工具描述注入上下文会造成混乱和高成本 。有效的策略是仅检索与当前任务最相关的工具描述，甚至可以使用RAG技术来筛选工具 。
? 例如像Manus中提到的【遮蔽，而非移除】：
Agent选择工具的时候，你不用动态地把用不着的工具从列表中移除，而可以在提示词里边通过预填充特定工具的前缀，来匹配特定类型的工具。
举个，Manus先是设计了具有一致前缀的动作名称—例如，所有与浏览器相关的工具都以"browser_"开头，命令行工具以"shell_"开头。
然后，在 Agent的某些特定场景下就要用浏览器工具的时候，在提示词里预填充返回值： >assistant 核心思想： 减少信息所占用的Token数量，从而在有限的上下文窗口内装入更多内容，并降低推理成本 。 落地实践：上下文摘要（Context Summarization）： 使用LLM或其他算法对长篇幅的对话历史、文档或工具输出进行摘要，保留核心要点而丢弃冗余细节 。例如，Claude Code在上下文窗口超过95%时，会自动运行“自动压缩”功能，总结整个用户-智能体交互轨迹 。上下文修剪（Context Trimming）： 这是一种更简单的启发式方法，通常通过硬编码规则来过滤或“裁剪”上下文 。例如，当对话历史过长时，系统可以简单地删除最旧的消息。 核心思想： 通过将上下文拆分，以帮助智能体更好地完成任务，防止不同类型的信息相互干扰 。 落地实践：多智能体系统（Multi-Agent Systems）： 这是最主流的隔离方法之一 。一个复杂的任务被分解为多个子任务，每个子任务由一个专门的智能体来处理。每个智能体都有自己独立的上下文窗口、工具集和指令，从而实现了“关注点分离”，提高了效率和性能 。 沙盒环境（Sandboxed Environments）： 通过在沙盒环境中运行代码或执行工具调用，将高Token消耗的对象（如图像、大量数据）或运行时状态与LLM的上下文隔离开 。只有精炼后的返回结果才被传回给LLM，这使得智能体能够更高效地处理状态并管理大型对象 。 这些策略共同构成了上下文工程的完整框架，提供了从宏观架构到微观优化的全方位解决方案。 检索增强生成（Retrieval-Augmented Generation, RAG）是一种强大的上下文扩展范式。其核心思想并非将所有知识预先训练到模型参数中，而是将外部知识库作为事实来源，通过一个独立的检索系统，在需要时动态地将相关信息作为上下文注入LLM 。原理： RAG框架通常包含三个主要组件：一个知识库（如文档、网页集合）、一个检索器（如基于向量搜索的系统）以及一个生成模型（LLM）。当用户提出问题时，检索器首先从知识库中找出与问题最相关的文档片段，然后将这些片段与用户问题一起作为上下文提供给LLM，由LLM进行综合生成最终答案。优势： RAG显著提升了LLM的事实准确性与可追溯性，有效减少了“幻觉”（hallucination）现象。此外，它使得知识的更新变得高效，只需更新知识库而无需重新训练模型，极大地降低了维护成本，并能够接入实时或专有数据。局限性： RAG的性能高度依赖于检索召回率和文档切块（chunking）策略。如果检索器未能找到相关信息，或者文档切块过小/过大导致上下文不完整，则最终输出质量将受到影响。此外，对于需要多跳推理（multi-hop reasoning）的复杂问题，简单的一次性检索可能无法提供足够的信息。 作为RAG的另一条技术路径，长上下文窗口模型通过底层架构优化，直接扩展了LLM能够处理的上下文长度。技术进展： 从早期Transformer架构Token数与计算量呈二次方增长（O(N2)），到通过FlashAttention等技术实现计算量与上下文长度呈线性增长（O(N)），长上下文模型已从最初的几千个Token发展到几十万乃至上百万的Token级别。例如，谷歌的Gemini 1.5 Pro模型正式发布了200万tokens的上下文窗口 ，微软的LongRoPE技术也实现了超过200万tokens的上下文扩展 。性能瓶颈： 尽管取得了显著进展，但长上下文模型依然面临巨大挑战。首先是计算量与显存消耗巨大，这使得训练和推理成本极高。其次，存在“长文本遗忘”效应，即模型在处理超长文本时，对文本中间部分的注意力会显著下降，导致关键信息被忽略。应用场景： 这类模型特别适用于需要处理单一、超长文档的任务，如长篇法律合同分析、技术文档问答、或代码库的全面分析。 RAG和长上下文模型并非竞争关系，而是高度互补的。RAG解决了知识的实时性和可更新性，但可能缺乏对全局信息的深度理解。长上下文窗口则提供了对“工作记忆”的深度理解，但其知识更新成本高昂。 一个高级的智能体架构，应该能够根据任务需求，动态地决定是进行外部检索（RAG），还是在内部上下文中进行推理，甚至是将两者结合起来。这种混合策略是当前最前沿的研究方向，它揭示了LLM智能体架构从单一技术路径向多模态、混合架构演进的必然趋势。 上下文状态管理远不止于提示词技巧，它需要对后端架构进行根本性的重新设计 。传统的无状态API调用模式已无法满足LLM智能体对“记忆”的需求。 为了实现上下文的持久化，需要设计专门的记忆存储方案。这可以基于键值对（Key-Value Store）来存储用户ID与对话历史；基于对话槽（Slot-filling）来识别和存储特定信息（如航班号、预定时间）；或基于用户偏好（User Profile）来持久化用户的习惯和兴趣。 这些机制共同构成了一个结构化的记忆层，使得智能体能够在不同时间、不同回合的交互中，始终引用和利用过去的经验。 向量数据库： 擅长对非结构化数据（如文档、图像）进行高维向量化存储与相似性检索，实现快速、灵活的知识检索。知识图谱： 提供结构化的、语义丰富的知识表示，擅长处理实体与关系，支持复杂的逻辑推理与多跳查询。协同： 在一个先进的智能体系统中，向量数据库可以用于快速检索与用户问题语义相似的文档片段，而知识图谱则可以为LLM提供结构化的、可推理的背景知识。例如，在回答一个关于法律条款的问题时，向量数据库可以快速找到相关的法条文本，而知识图谱则可以提供该法条与相关案例、判决结果之间的复杂关系。 这表明，一个成功的LLM智能体系统需要一个强大的后端来管理其“记忆”（持久化）和“知识”（知识图谱），并与LLM进行高效协同。上下文工程不仅是Prompt层面的技巧，更是系统架构层面的创新，它将LLM从一个孤立的模型调用提升为一个完整的、有状态的系统。 本部分将结合实际应用案例，展示上下文工程如何在不同领域实现从理论到实践的跨越，以展示其在落地方法中的具体应用 。 在法律、医疗、金融等高度依赖专业知识的垂直领域，上下文的质量直接决定了智能体的专业性与可靠性。技术方案： 基于RAG框架构建专业知识库。该方案能够确保智能体的输出不仅通用，而且具有事实依据和领域深度。落地方法：数据清洗与切块： 对海量的专业文档（如法律条文、医疗指南、金融财报）进行系统性清洗、分段，并为每个片段添加元数据（如章节、作者、日期）。这一步骤至关重要，因为高质量的切块是有效检索的前提。向量化与检索策略优化： 选取合适的Embedding模型将文档片段转化为高维向量。同时，设计混合检索策略，例如，结合关键词检索（用于精确匹配）与向量检索（用于语义匹配），以提高召回率和准确性。在推理阶段，智能体首先识别用户查询意图，然后根据意图决定是进行一次性检索还是多次迭代检索，并将检索结果作为上下文注入LLM。 这一案例表明，在垂直领域，RAG的成功不仅依赖于LLM自身的强大，更依赖于前期高质量的知识库构建和后期的检索策略优化。这揭示了“数据工程”在“上下文工程”中的核心地位。 任务执行型智能体，如预定航班、处理订单等，面临的核心挑战是“目标一致性”。即使提供的链接无法访问，我们也能从其意图中推断出，这类应用需要智能体“记住”它的长期目标。技术方案： 融合对话历史、用户偏好和任务状态的动态上下文管理。落地方法：状态机设计： 将复杂任务分解为一系列可管理的状态，并在上下文中显式地标注当前所处的状态。例如，一个航班预定智能体可以有“确认出发地”、“确认目的地”、“确认日期”、“确认人数”等状态。上下文槽填充与跨回合记忆： 识别并存储对话中的关键信息（如“北京”作为出发地、“上海”作为目的地），并将其作为固定槽位（slot）持久化。在多轮对话中，智能体可以根据槽位填充情况，在上下文中引用这些信息，而无需用户重复提供。当一个槽位被成功填充后，该信息可以被转移到长期记忆中，以供未来对话参考。 这一案例说明，任务执行型智能体要求上下文不仅包含信息，还要包含“意图”和“任务进度”等元数据。这正是从一个简单的“对话机器人”向一个具备长期目标感的“任务执行器”转变的关键。 在代码生成领域，上下文工程的重要性尤为突出。单纯的代码文本上下文不足以让LLM进行复杂的推理。技术方案： 整合代码库、项目结构、开发者习惯与错误日志的上下文。落地方法：混合检索： 结合向量搜索（基于语义相似度找到类似的代码片段）与关键词搜索（精确查找函数名、变量名）。抽象语法树（AST）分析： 这是代码上下文工程中的一个高级技术。在将代码片段作为文本输入LLM的同时，将代码的抽象语法树（AST）也作为结构化的上下文注入。AST提供了代码的逻辑和结构信息，而不是仅仅是Token序列。这使得LLM能够跳出Token序列的束缚，进行更深层次的逻辑推理，例如理解变量的作用域、函数调用关系等。 这一案例表明，未来的上下文工程将不仅仅是关于“信息”，更是关于“知识结构”的编码与传递。通过将代码的逻辑结构（AST）作为上下文的一部分注入，可以让智能体进行更深层次的逻辑推理，从而显著提升代码生成和修复的质量。 本文对LLM智能体上下文工程进行了全面、系统的分析。我们得出核心结论是，上下文工程并非仅仅是提示词工程的延伸，而是一种将LLM从无状态函数调用转变为有记忆、有目标的状态机的系统性工程学。 其核心挑战在于容量限制、动态更新与多模态融合，而当前的技术方案，如RAG、长上下文模型、上下文压缩以及知识图谱，正在系统性地应对这些挑战。成功的上下文工程实践，在垂直助手、任务执行器和代码生成等领域已经展现出巨大潜力，但其成功也高度依赖于高质量的数据工程和系统架构设计。 从更深层次看，上下文工程是对人类认知过程的工程化模拟，它为通向通用人工智能提供了关键路径。然而，伴随而来的，是数据偏见、隐私泄露和可解释性缺失等一系列严峻的伦理与安全挑战。对技术开发者： 建议将目光从单一的LLM API调用，转向设计分层的、混合的上下文管理架构。这意味着需要将记忆层（如向量数据库）、知识表示层（如知识图谱）与LLM调用层进行深度整合。同时，应高度重视数据工程，因为上下文的质量直接决定了智能体的性能上限。未来的开发工作，将是关于如何高效编码和传递知识结构，而不仅仅是信息本身。对产品经理： 建议从传统的“功能”导向转向“智能体”导向。产品设计不应只关注单次交互的体验，而应聚焦于如何通过上下文的积累，为用户提供长期、连贯且个性化的价值。应当将上下文视为核心资产，并思考如何通过产品设计，鼓励用户与智能体建立长期、有价值的交互关系。 总而言之，上下文工程远不止是一种优化技巧，它代表了构建下一代 AI 智能应用的核心范式转变。从静态的提示词到动态的、精心 orchestrated 的上下文系统，这一演进要求开发者像建筑师一样思考，而不仅仅是对话者。未来，随着模型能力的持续增强，如何更高效、更智能地构建和管理上下文，将成为决定 AI 应用价值上限的关键。掌握上下文工程，便是掌握了开启 AI 真正潜力的钥匙。
