收藏必看！上下文工程：大模型应用进阶指南，小白到专家必学

关注

原创最新推荐文章于 2026-04-19 00:09:24 发布 949 阅读 AI 写同款· GEO 优化 ›

问题解答：如何不通过修改底层数据库表的方式，给数据库对应的数据结构，增添新的字段？现在需要将这张表里的内容读取到 ABAP 内表里，并且针对每个行项目，增加一个新的列字段，我随便举个例子，这个列字段名称叫 LENGTH，值为 OBJ_NAME 字段的长度，使用。最笨的办法就是下面这样定义一个新的类型，这个类型的每个字段名称，都来自数据库表 TADIR 的同名字段，在末尾再增添自定义字段 length.其实我们是做 ALV 输出，只需要 ABAP 内表变量的类型，包含 TADIR 数据库表的全部字段，再加上新的 LENGTH 字段即可。这相当于多了一个中间层，没办法直接被 ALV 处理。阅读详情

上下文是 AI 智能体的关键但有限资源。本文将探讨如何有效筛选和管理驱动 AI 智能体运行的上下文。

在应用 AI 领域，提示词工程多年来一直是关注焦点，如今一个新术语逐渐崭露头角：上下文工程。使用大语言模型（LLM）构建应用，已不再是单纯寻找合适的提示词短语，而是要解决更宏观的问题：“什么样的上下文配置最有可能让模型产生我们期望的行为？”

上下文指的是从大型语言模型中采样时包含的一系列 tokens。当前的工程核心问题是，在大语言模型的固有约束下优化这些 tokens 的效用，以稳定实现预期结果。要灵活运用大语言模型，往往需要从 “上下文视角” 思考，也就是说，要考虑大模型在任何给定时刻能获取的整体状态，以及该状态可能触发的潜在行为。

本文将探索这一新兴的上下文工程领域，并提供一套更完善的思维框架，帮助构建可调控、高效能的 AI 智能体。

一、上下文工程与提示词工程的区别

在 Anthropic 公司看来，上下文工程是提示词工程的自然演进。提示词工程指的是通过编写和组织语言模型指令来获取最佳结果的方法（相关概述和实用策略可参考这里：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview）。而上下文工程则是在语言模型推理过程中，筛选和维护最优 tokens（信息）的一系列策略，其中包括提示词之外所有可能纳入上下文的其他信息。

在语言模型应用的早期阶段，提示词设计是 AI 工程工作的核心，除日常聊天交互外，大多数使用场景都需要针对一次性分类或文本生成任务优化提示词。顾名思义，提示词工程的核心是如何编写有效的提示词，尤其是系统提示词。但随着我们逐渐构建功能更强大、能进行多轮推理且支持长期任务的 AI 智能体，就需要专门的策略来管理整个上下文状态，包括系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等。

循环运行的 AI 智能体会不断生成可能与下一轮推理相关的数据，这些信息必须经过周期性提炼。上下文工程就是在不断扩充的潜在信息池中，筛选出可纳入有限上下文窗口的内容，是一门兼具艺术与科学性的技术。

在这里插入图片描述

与编写提示词这种一次性任务不同，上下文工程是迭代式的，每次决定向大模型传递什么信息时，筛选过程都会发生。

二、为什么上下文工程对构建高效 AI 智能体至关重要

尽管语言模型速度快、能处理海量数据，但我们发现它们和人类一样，在特定情况下会注意力不集中或产生困惑。“大海捞针” 式的基准测试研究揭示了 “上下文衰减” 现象：随着上下文窗口中的 tokens 数量增加，模型从上下文中准确召回信息的能力会下降。

虽然不同模型的衰减程度有所差异，但这是所有语言模型的共性特征。因此，上下文必须被视为一种边际收益递减的有限资源。就像人类的工作记忆容量有限一样，语言模型在解析大量上下文时也有 “注意力预算”，每新增一个 token 都会消耗一部分预算，这就要求我们必须精心筛选提供给模型的 tokens。

这种注意力稀缺性源于语言模型的架构约束。语言模型基于 Transformer 架构，该架构允许每个 token 关注整个上下文中的所有其他 token，这会产生 n 个 tokens 对应 n² 个成对关系的情况。

随着上下文长度增加，模型捕捉这些成对关系的能力会被稀释，导致上下文规模与注意力集中度之间存在天然矛盾。此外，模型的注意力模式是从训练数据分布中习得的，而训练数据中短序列通常比长序列更常见，这意味着模型对长序列的上下文依赖关系缺乏足够经验，也缺少专门的参数支持。

位置编码插值等技术能让模型通过适配原始训练的较小上下文来处理更长序列，但会在 token 位置理解上出现一定衰减。这些因素导致模型性能呈梯度下降而非断崖式下跌：在长上下文场景下，模型仍具备较强能力，但信息检索精度和长程推理能力会比短上下文场景有所下降。

这些现实情况意味着，要构建高效 AI 智能体，必须重视上下文工程。

三、高效上下文的核心构成

既然语言模型的注意力预算有限，优秀的上下文工程就要找到最小规模的高价值 tokens，以最大程度确保预期结果。这一原则说起来容易做起来难，下面我们将结合上下文的不同组成部分，说明该原则的实际应用。

3.1 系统提示词

系统提示词应极其清晰，使用简洁直接的语言，且表述粒度要恰到好处（即 “Goldilocks 区间”），避免两种常见误区：一种是在提示词中硬编码复杂、脆弱的逻辑以强求特定智能体行为，这种方式会导致系统脆弱性增加，长期维护复杂度上升；另一种是提供模糊的高层指导，既没有给模型明确的输出信号，又错误地假设模型与人类拥有共同上下文。最优的表述粒度应实现平衡：足够具体以有效引导行为，同时足够灵活以赋予模型强大的启发式决策能力。

在这里插入图片描述

我们建议将提示词分成不同模块（例如：<background_information>（背景信息）、<instructions>（指令）、## Tool guidance（工具使用指南）、## Output description（输出说明）等），并使用 XML 标签或 Markdown 标题来区分这些模块，不过随着模型能力的提升，提示词的具体格式重要性正在降低。

无论采用何种结构，系统提示词都应追求 “用最少的信息完整勾勒预期行为”（注：“最少” 不等于 “最短”，仍需提供足够信息确保智能体遵循预期行为）。建议先使用最先进的模型测试极简提示词的表现，再根据初始测试中发现的问题，添加明确的指令和示例来优化性能。

3.2 工具

工具能让 AI 智能体与环境交互，并在工作过程中获取新的额外上下文。由于工具定义了智能体与信息 / 行动空间的交互规则，因此工具设计必须注重效率：一方面要返回 tokens 高效的信息，另一方面要鼓励智能体采取高效行为。

在《为 AI 智能体编写工具：借助 AI 智能体自身》一文中（链接为：https://www.anthropic.com/engineering/writing-tools-for-agents），我们讨论过如何构建易于语言模型理解且功能重叠最少的工具。就像设计精良的代码库一样，工具应具备独立性、抗错误能力，且用途明确。输入参数也应描述清晰、无歧义，并充分发挥模型的固有优势。

最常见的误区之一是工具集臃肿，功能覆盖过广，或导致智能体在选择工具时陷入歧义。如果人类工程师都无法明确判断特定场景下该使用哪种工具，就不能指望 AI 智能体做得更好。后文将提到，为智能体筛选 “最小可行工具集”，还能在长期交互中更可靠地维护和精简上下文。

3.3 示例（小样本提示）

提供示例（即小样本提示）是众所周知的最佳实践，我们仍强烈推荐使用。但有些团队会在提示词中堆砌大量边缘案例，试图罗列模型在特定任务中应遵循的所有规则，这种做法并不可取。相反，我们建议筛选一组多样化、具有代表性的示例，有效展现 AI 智能体的预期行为。对语言模型而言，示例可谓 “一图胜千言”。

总而言之，针对上下文的各个组成部分（系统提示词、工具、示例、消息历史等），我们的核心建议是：用心筛选，确保上下文既信息量充足，又简洁精炼。接下来，我们将深入探讨如何在运行时动态检索上下文。

四、上下文检索与智能检索

在《构建高效 AI 智能体》一文中（链接为：https://www.anthropic.com/engineering/building-effective-agents），我们强调了基于语言模型的工作流与 AI 智能体的区别。自那以后，我们倾向于用一个简单的定义来描述智能体：能自主循环使用工具的语言模型。

通过与客户合作，我们发现行业正逐渐聚焦于这一简单范式。随着底层模型能力的提升，智能体的自主化水平也在升级：更智能的模型能独立应对复杂的问题场景，并从错误中恢复。

如今，工程师设计智能体上下文的思路也在发生转变。目前，许多原生 AI 应用会采用某种基于嵌入的推理前检索方式，为智能体提供重要的推理上下文。而随着行业向更智能的智能体模式转型，越来越多团队开始用 “即时上下文” 策略来增强这些检索系统。

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

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

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

当然，这种方式也存在权衡：运行时探索比检索预计算数据更慢。此外，还需要精心设计工程实现，确保语言模型拥有合适的工具和启发式策略，以有效导航信息环境。如果缺乏适当指导，智能体可能会因误用工具、陷入死胡同或未能识别关键信息而浪费上下文资源。

在某些场景下，最高效的智能体可能会采用混合策略：预先检索部分数据以保证速度，同时根据需要自主进行进一步探索。自主化程度的 “最佳边界” 取决于具体任务。Claude Code 就是采用这种混合模型的智能体：CLAUDE.md 文件会预先直接纳入上下文，而 glob 和 grep 等基础工具则允许它导航环境并即时检索文件，有效规避了索引过时和语法树复杂的问题。

混合策略可能更适合内容动态性较低的场景，例如：法律或金融工作。随着模型能力的提升，智能体设计将逐渐倾向于让智能模型自主发挥作用，减少人为干预。考虑到行业的快速发展，“用最简单的方法实现目标” 可能仍是基于 Claude 构建智能体的最佳建议。

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

长期任务要求智能体在一系列行动中保持连贯性、上下文一致性和目标导向性，而这些行动的 token 数量可能会超出语言模型的上下文窗口限制。对于持续数十分钟到数小时的任务（例如：大型代码库迁移或全面研究项目），智能体需要专门的技术来突破上下文窗口大小的限制。

等待更大容量的上下文窗口似乎是显而易见的解决方案，但在可预见的未来，无论上下文窗口多大，都可能面临上下文冗余和信息相关性的问题，至少在需要智能体发挥最佳性能的场景中是如此。为了让智能体能有效处理长期任务，我们开发了几种直接应对上下文冗余约束的技术：压缩、结构化笔记和多智能体架构。

5.1 压缩

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

例如，在 Claude Code 中，我们通过将消息历史传递给模型，让模型总结并压缩最关键的细节，保留架构决策、未解决的漏洞和实现细节，同时丢弃冗余的工具输出或消息。之后，智能体可以基于这个压缩后的上下文，再加上最近访问过的 5 个文件继续工作。这样用户就能获得连贯的体验，而无需担心上下文窗口限制。

压缩的关键在于判断 “保留什么” 和 “丢弃什么”：过度压缩可能会丢失那些当下不显眼但后续至关重要的上下文。对于实施压缩系统的工程师，我们建议在复杂的智能体运行轨迹上仔细调整提示词：首先最大化召回率，确保压缩提示词能捕捉轨迹中的所有相关信息，然后逐步提升精度，剔除多余内容。

一个简单有效的冗余内容处理方式是清除工具调用和结果，如果某个工具调用已深入消息历史，智能体为何还需要查看原始结果？工具结果清除是最安全、影响最小的压缩形式之一，最近已作为功能在 Claude 开发者平台推出。

5.2 结构化笔记（智能记忆）

结构化笔记（又称智能记忆）是指智能体定期将笔记存储到上下文窗口之外的记忆空间，之后可将这些笔记重新拉回上下文窗口。

这种策略能以最小开销实现持久化记忆。就像 Claude Code 创建待办清单，或自定义智能体维护 NOTES.md 文件一样，这种简单模式能让智能体跟踪复杂任务的进度，保留那些在数十次工具调用后可能丢失的关键上下文和依赖关系。

Claude 玩《精灵宝可梦》的案例，展示了记忆在非编码领域对智能体能力的提升：该智能体在数千步游戏过程中保持精确记录，比如 “在 1 号道路训练精灵宝可梦的 1234 步中，皮卡丘已升级 8 级，目标是 10 级”。无需任何关于记忆结构的提示，它就能绘制已探索区域的地图、记住已解锁的关键成就，并记录战斗策略，帮助自己学习哪种攻击对不同对手最有效。

在上下文重置后，智能体会读取自己的笔记，继续数小时的训练或迷宫探索。这种跨总结步骤的连贯性，让长期策略得以实现，而这仅靠语言模型的上下文窗口是无法完成的。

在 Sonnet 4.5 版本发布时，我们在 Claude 开发者平台推出了公测版记忆工具，通过基于文件的系统，让智能体能更轻松地存储和查询上下文窗口之外的信息。这使得智能体能逐步构建知识库、跨会话维护项目状态，并参考过往工作成果，而无需将所有信息都保存在上下文之中。

5.3 子智能体架构

子智能体架构是突破上下文限制的另一种方式。它不依赖单个智能体维护整个项目的状态，而是让专门的子智能体处理特定任务，每个子智能体都拥有独立的干净上下文窗口。主智能体负责用高层计划协调工作，子智能体则执行深度技术工作或使用工具查找相关信息。每个子智能体可能会进行大量探索（使用数万个甚至更多 tokens），但最终只返回浓缩精炼的总结结果（通常为 1000-2000 个 tokens）。

这种方式实现了清晰的职责分离，详细的检索上下文被隔离在子智能体内部，主智能体则专注于综合和分析结果。我们在《多智能体研究系统的构建方法》一文中（链接为：https://www.anthropic.com/engineering/multi-agent-research-system）讨论过这种模式，它在复杂研究任务上的表现明显优于单智能体系统。

选择哪种技术取决于任务特征：

压缩技术适合需要大量来回交互、需保持对话连贯性的任务；
笔记技术适合具有明确里程碑的迭代式开发任务；
多智能体架构适合需要并行探索、能从多维度分析中获益的复杂研究和分析任务。

即使模型不断升级，在长期交互中保持连贯性仍是构建更高效智能体的核心挑战。

六、总结

上下文工程标志着我们使用语言模型的方式发生了根本性转变。随着模型能力的提升，核心挑战已不再是编写完美的提示词，而是在每一步都精心筛选纳入模型有限注意力预算的信息。无论是为长期任务实施压缩技术、设计 token 高效的工具，还是让智能体能即时探索环境，核心原则始终不变：找到最小规模的高价值 tokens，以最大程度确保预期结果。

我们介绍的这些技术将随着模型的进步不断演进。目前已能看到，更智能的模型需要的指令性工程更少，允许智能体拥有更高的自主性。但即使能力不断提升，将上下文视为珍贵的有限资源，仍是构建可靠、高效 AI 智能体的核心前提。

今天就开始在 Claude 开发者平台尝试上下文工程吧，你还可以通过我们的记忆和上下文管理指南，获取更多实用技巧和最佳实践。