【必学收藏】大模型上下文工程完全指南：从提示工程到智能体构建

本文介绍了"上下文工程"这一新兴技术，它被视为提示工程的演进。文章探讨了上下文工程与提示工程的区别，强调了上下文工程对构建高性能智能体的重要性，详细分析了高效上下文的构成要素，并介绍了上下文检索、压缩、结构化记录和多智能体架构等长周期任务的处理技术。核心观点是：在LLM开发中，应找到最小规模的高价值令牌集，以最大程度提高实现预期结果的可能性。

小涂Ss

904人浏览 · 2025-11-09 07:30:00

小涂Ss · 2025-11-09 07:30:00 发布

前言

在应用AI领域，“提示工程”（Prompt Engineering）多年来一直是关注焦点，如今一个新术语逐渐凸显：上下文工程（Context Engineering）。基于语言模型进行开发，正从“为提示找到合适的词句”，转向更宏观的问题——“何种上下文配置最有可能让模型产生预期行为？”

上下文指的是从大型语言模型（LLM）中进行采样时所包含的令牌（token）集合。当前的工程问题是，在LLM固有的约束条件下优化这些令牌的效用，以持续实现预期结果。要高效驾驭LLM，往往需要从“上下文视角”思考——换句话说：要考虑LLM在任意时刻可获取的整体状态，以及该状态可能产生的潜在行为。

在本文中，将探讨新兴的上下文工程技术，并提供一个经过优化的思维模型，用于构建可引导、高效能的智能体。

一、上下文工程vs提示工程

我们将上下文工程视为提示工程的自然演进，提示工程指的是为实现最优结果而编写和组织LLM指令的方法。上下文工程则指在LLM推理过程中，筛选和维护最优令牌（信息）集的一系列策略，其中包括除提示之外可能纳入上下文的所有其他信息。

在基于LLM进行工程开发的早期阶段，提示词编写是AI工程工作的核心环节——因为除日常对话交互外，大多数用例都需要针对“单轮分类”或“文本生成”任务优化提示。顾名思义，提示工程的核心关注点是“如何编写高效提示”，尤其是系统提示。然而，随着我们开始开发“能力更强、可支持多轮推理、且能应对更长时间跨度”的智能体，我们需要一套策略来管理整个上下文状态（包括系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）。

在循环中运行的智能体会生成越来越多与“下一轮推理”相关的数据，而这些信息必须经过周期性优化。上下文工程正是一门“从不断演变的海量潜在信息中，筛选出可纳入有限上下文窗口的内容”的技术与科学。

与“编写提示”这种离散任务不同，上下文工程具有迭代性——每次决定向模型传递哪些内容时，都需要进行筛选

二、为何上下文工程对构建高性能智能体至关重要

尽管LLM速度快、能处理的数据量越来越大，但我们发现，LLM与人类类似，在特定情况下会出现注意力分散或理解混淆的问题。针对“大海捞针”式基准测试的研究揭示了“上下文衰减（context rot）”的概念：随着上下文窗口中令牌数量的增加，模型从该上下文中准确召回信息的能力会下降。

尽管不同模型的性能衰减程度存在差异，但所有模型都会出现这一特征。因此，上下文必须被视为一种“边际收益递减”的有限资源。与人类有限的工作记忆容量类似，LLM在解析大量上下文时，也会消耗“注意力预算（attention budget）”。每引入一个新令牌，都会在一定程度上消耗该预算——这使得“精心筛选LLM可获取的令牌”变得愈发重要。

这种注意力稀缺性源于LLM的架构约束。LLM基于Transformer架构构建，该架构允许每个令牌关注整个上下文中的所有其他令牌，由此产生的成对关系数量为 n²（n为令牌数量）。

随着上下文长度增加，模型捕捉这些成对关系的能力会逐渐减弱，从而在“上下文规模”与“注意力集中度”之间形成天然矛盾。此外，模型的注意力模式是从训练数据分布中学习而来的，而在训练数据中，短序列通常比长序列更常见。这意味着模型对“全上下文依赖关系”的处理经验更少，专门用于此类处理的参数也更少。

“位置编码插值”（position encoding interpolation）等技术可通过将长序列适配到“原训练的较小上下文窗口”中，让模型能够处理更长序列，但会导致令牌位置理解能力有所下降。这些因素使得模型性能呈现“梯度衰减”而非“断崖式下降”：在长上下文场景下，模型仍具备较强能力，但与处理短上下文相比，其信息检索精度和长程推理能力可能会有所降低。

这些现实情况表明，要构建高性能智能体，精心设计的上下文工程至关重要。

三、高效上下文的构成要素

鉴于LLM的注意力预算有限，优秀的上下文工程意味着“找到最小规模的高价值令牌集，以最大程度提高实现预期结果的可能性”。实践这一理念难度不小，但在下文，将结合上下文的不同组成部分，说明这一核心原则在实际应用中的具体含义。

1. 系统提示

系统提示应极其清晰，使用简洁、直接的语言，并以“适合智能体的粒度”呈现信息。这里的“合适粒度”是介于两种常见失效模式之间的“黄金平衡点”：

（1）一种极端情况是，工程师在提示中硬编码复杂、脆弱的逻辑，以获取精确的智能体行为。这种方法会导致系统脆弱性增加，且长期维护复杂度上升。

（2）另一种极端情况是，工程师提供的指导过于模糊、宏观，无法为LLM提供关于“预期输出”的具体信号，或错误地假设存在“共享上下文”。

最优粒度需实现平衡：既要足够具体以有效引导行为，又要具备足够灵活性，为模型提供可靠的启发式规则以指导行为。

我们建议将提示组织为不同部分（如<background_information>、、##工具指南、##输出说明等），并使用XML标签或Markdown标题来区分这些部分——不过，随着模型能力的提升，提示的具体格式重要性可能会逐渐降低。

无论采用何种方式构建系统提示，核心目标都是“用最少的信息完整界定预期行为”（注：“最少”并不等同于“简短”；为确保智能体遵循预期行为，仍需提前向其提供足够信息）。最佳实践是：先使用最先进的模型测试“最小化提示”在目标任务上的表现，然后根据初始测试中发现的失效模式，添加清晰的指令和示例以提升性能。

2. 工具

工具使智能体能够与环境交互，并在工作过程中引入新的、额外的上下文。由于工具定义了“智能体与其信息/行动空间”之间的通信，因此工具设计必须注重效率——既要返回“令牌效率高”的信息，又要能引导智能体产生高效行为。

与设计精良的代码库中的函数类似，工具应具备“功能独立、抗错误能力强、用途明确”的特点。输入参数也应具有描述性、无歧义性，并能充分发挥模型的固有优势。

通常观察到的最常见失效模式之一，是“工具集臃肿”——工具涵盖的功能过多，或导致智能体在“选择使用哪种工具”时面临模糊的决策点。如果人类工程师无法明确判断“在特定场景下应使用哪种工具”，就不能期望AI智能体做得更好。正如我们将在下文讨论的，为智能体筛选“最小可行工具集”，还有助于在长时间交互中更可靠地维护和精简上下文。

3. 示例

提供示例（即“少样本提示”）是公认的最佳实践，仍强烈推荐这一方法。然而，许多团队会将大量边缘案例塞进提示中，试图让LLM理解任务相关的所有规则——不建议这样做。相反，建议筛选一组“多样化的标准示例”，以有效体现智能体的预期行为。对LLM而言，“示例”堪比“抵得上千言万语的图像”。

综上，针对上下文的不同组成部分（系统提示、工具、示例、消息历史等），我们的总体建议是：深思熟虑，确保上下文“信息丰富且精简”。接下来，我们将深入探讨如何在运行时动态检索上下文。

四、上下文检索与智能体式搜索

通过与客户合作，发现行业正逐渐向这一简洁范式靠拢。随着底层模型能力的提升，智能体的自主性也会相应增强：更智能的模型能让智能体自主应对复杂的问题场景，并从错误中恢复。

如今，工程师对“智能体上下文设计”的思考方式也在发生转变。目前，许多原生AI应用会采用“基于嵌入的推理前检索”方式，筛选出重要上下文供智能体进行推理。随着行业向更具“智能体属性”的方案转型，发现越来越多团队会通过“即时（just in time）上下文策略”来增强这些检索系统。

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

除存储效率外，这些引用的元数据（无论是否明确提供）还能为“高效优化行为”提供机制。例如，对于在文件系统中运行的智能体，tests文件夹下名为test_utils.py的文件与src/core_logic.py中同名文件的用途显然不同。文件夹层级、命名规则、时间戳等信息都能提供重要信号，帮助人类和智能体理解“如何、何时利用信息”。

让智能体自主导航和检索数据，还能实现“渐进式信息披露”——即允许智能体通过探索逐步发现相关上下文。每次交互产生的上下文都会为下一次决策提供依据：文件大小暗示复杂度、命名规则提示用途、时间戳可作为相关性的参考指标。智能体可逐层构建理解，仅在工作记忆中保留必要信息，并通过记录策略实现额外的信息持久化。这种“自主管理的上下文窗口”能让智能体专注于相关信息子集，而非淹没在“全面但可能无关”的信息中。

当然，这种方案也存在权衡：运行时探索比检索预计算数据更慢。此外，要确保LLM拥有“有效导航信息场景”所需的合适工具和启发式规则，需要经过针对性的精心设计。若缺乏恰当指导，智能体可能会因“误用工具、陷入无效路径、无法识别关键信息”而浪费上下文资源。

在某些场景下，最高效的智能体可能会采用混合策略：提前检索部分数据以保证速度，并自主决定是否进行进一步探索。“自主性的合理程度”取决于具体任务。Claude Code便是采用混合模式的智能体：它会将CLAUDE.md文件直接提前加载到上下文中，同时通过glob、grep等基础命令让智能体能够导航环境并“即时”检索文件，从而有效规避“索引过时”和“语法树复杂”等问题。

混合策略可能更适用于内容动态性较低的场景（如法律或金融工作）。随着模型能力的提升，智能体设计将逐渐倾向于“让智能模型自主高效行动”，减少人工筛选环节。鉴于该领域的快速发展，“采用最简单可行的方案”可能仍是为Claude构建智能体的最佳建议。

五、长周期任务的上下文工程

长周期任务要求智能体在“令牌数量超过LLM上下文窗口”的行动序列中，保持连贯性、上下文一致性和目标导向行为。对于“大型代码库迁移”“全面研究项目”等需要持续数十分钟至数小时的任务，智能体需要专门的技术来突破上下文窗口大小的限制。

“等待更大的上下文窗口”看似是显而易见的解决方案，但在可预见的未来，无论窗口规模如何，“上下文冗余”和“信息相关性”问题都将存在——至少在需要智能体发挥最佳性能的场景中是如此。为使智能体能在长时间跨度内高效工作，我们开发了几种可直接应对“上下文冗余”约束的技术：压缩（compaction）、结构化记录（structured note-taking）和多智能体架构（multi-agent architectures）。

1. 压缩

压缩指的是：当对话接近上下文窗口上限时，对对话内容进行总结，然后用该总结重新初始化一个新的上下文窗口。在上下文工程中，压缩通常是提升长期连贯性的首要手段。其核心是“高保真提炼上下文窗口内容”，使智能体能够继续工作且性能损失最小。

以Claude Code为例，实现方式是：将消息历史传递给模型，由模型总结并压缩关键细节。模型会保留架构决策、未解决的漏洞、实现细节，同时丢弃冗余的工具输出或消息。随后，智能体可基于“压缩后的上下文 + 最近访问过的5个文件”继续工作。用户无需担心上下文窗口限制，即可获得连贯的体验。

压缩的关键在于“选择保留与丢弃的内容”：过度压缩可能会导致“细微但关键的上下文”丢失，而这些上下文的重要性可能在后续才会显现。对于实施压缩系统的工程师，建议：在复杂的智能体轨迹（trace）上仔细优化压缩提示。首先最大化“召回率”，确保压缩提示能捕捉轨迹中的所有相关信息，然后通过迭代剔除多余内容来提升“精确率”。

“剔除多余内容”的一个简单切入点是“清除工具调用及结果”——如果某个工具调用已深入消息历史，智能体为何还需要查看原始结果？“工具结果清除”是最安全、影响最小的压缩方式之一。

2. 结构化记录

结构化记录（又称“智能体记忆”）是指：智能体定期将记录保存到“上下文窗口之外的内存”中，这些记录可在后续被重新加载到上下文窗口。

这种策略能以最小开销实现“持久化记忆”。例如，Claude Code创建待办事项列表、自定义智能体维护NOTES.md文件——这种简单模式能让智能体跟踪复杂任务的进度，保留“若仅依赖工具调用则会丢失的关键上下文和依赖关系”。

Claude玩《宝可梦》的案例表明，在非编码领域，记忆如何改变智能体的能力。该智能体在数千步游戏过程中能保持精确记录——例如跟踪目标：“在1号道路训练宝可梦的1234步中，皮卡丘已向10级的目标提升了8级”。无需任何关于“记忆结构”的提示，它就能绘制已探索区域的地图、记住已解锁的关键成就，并记录战斗策略（以了解哪些招式对不同对手最有效）。

在上下文重置后，智能体可读取自己的记录，继续进行数小时的训练或地牢探索。这种“跨总结步骤的连贯性”，使得“仅依靠LLM上下文窗口无法实现的长周期策略”成为可能。

“记忆工具”通过基于文件的系统，让智能体更容易在“上下文窗口之外”存储和查询信息，从而使智能体能够逐步构建知识库、跨会话维护项目状态，并参考历史工作内容——无需将所有信息都保存在上下文中。

3. 多智能体架构

多智能体架构是突破上下文限制的另一种方式。它不依赖单个智能体维护整个项目的状态，而是由“专门的子智能体”处理特定任务（每个子智能体都有独立的简洁上下文窗口）。主智能体通过高层计划进行协调，子智能体则负责开展深度技术工作或使用工具查找相关信息。每个子智能体可能会进行大量探索（消耗数万个令牌），但最终仅返回“压缩后的工作摘要”（通常为 1000-2000 个令牌）。

这种方式实现了清晰的“职责分离”——详细的搜索上下文被隔离在子智能体内部，主智能体则专注于综合和分析结果。
选择何种方案取决于任务特征，例如：

（1）压缩适用于“需要大量交互往返”的任务，可保持对话连贯性；

（2）结构化记录适用于“具有明确里程碑的迭代开发”任务；

（3）多智能体架构适用于“并行探索能带来优势”的复杂研究与分析任务。

即便模型持续升级，“在长时间交互中保持连贯性”仍是构建更高效智能体的核心挑战。

结论

上下文工程标志着“基于LLM进行开发”的根本性转变。随着模型能力的提升，挑战不再仅仅是“编写完美提示”，而是“在每一步都精心筛选可纳入模型有限注意力预算的信息”。无论是为长周期任务实施压缩、设计“令牌高效”的工具，还是让智能体“即时”探索环境，核心原则始终不变：找到最小规模的高价值令牌集，以最大程度提高实现预期结果的可能性。

本文介绍的技术将随着模型的升级而不断演进。更智能的模型对“指令细节”的要求更低，能让智能体拥有更高的自主性。但即便能力不断提升，“将上下文视为宝贵的有限资源”，仍是构建可靠、高效智能体的核心前提。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

在这里插入图片描述

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。
在这里插入图片描述
最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。