13.3 Context Engineering 概览:从提示词工程到上下文工程

Context Engineering 概览:从提示词工程到上下文工程

序言

如果说 2023 年是“提示词工程”(Prompt Engineering)的年代,那么 2024-2025 年的焦点已经逐步转向“上下文工程”(Context Engineering)。这个范式转变反映了一个深刻的认知:与其优化如何表达指令,不如优化向模型提供什么信息、以什么方式提供。本章深入探讨这一转变的原因、实践和方法论。

💡 深入学习:想深入了解上下文工程的战略和高级技巧?请参阅《大模型上下文工程权威指南》。想了解 MCP 作为上下文来源的更多细节?请参阅本书第 4 章《MCP 模型上下文协议》。

第一节 核心概念:为什么上下文工程正在取代提示词工程

13.3.1 问题的演进

提示词工程时代(2022-2023)的瓶颈

在提示词工程的黄金时代,我们关注的是如何写得更好的指令:

  • 更清晰的表述

  • 更多的示例(Few-shot learning)

  • 更明确的格式要求

  • 更长的思维链(Chain-of-Thought)

虽然这些技术确实有效,但存在几个本质的限制:

  1. 边际收益递减:经过一定的优化后,提示词改进带来的性能提升开始平缓

  2. 模型能力瓶颈:再好的提示词也无法让模型完成它能力范围之外的任务

  3. 输出质量的天花板:模型的最终表现由其训练数据和能力所决定,而不仅由提示词

新的认知

随着 Claude 3.5 系列模型的推出和用户规模的扩大,我们发现了一个更深层的真相:

问题不在于如何问,而在于给模型什么信息。

当我们为 Claude 提供充分的、相关的、高质量的上下文信息时,即使使用相对简洁的指令,模型也能表现出色。相反,再精妙的提示词也无法弥补上下文信息的缺失。

13.3.2 上下文工程的定义

上下文工程(Context Engineering)是指系统地设计、选择、组织和呈现给 LLM 的输入信息(上下文),以优化模型的输出质量、准确性、可靠性和效率的实践和方法论。

核心特点

  1. 以信息为中心:关注提供给模型的信息的质量、相关性和组织

  2. 动态和自适应:上下文不是静态的,而是根据任务动态选择和调整的

  3. 多维度优化:优化维度包括信息的准确性、完整性、相关性、结构清晰度、时间鲜度等

  4. 系统化方法:采用明确的策略和流程来进行上下文设计

13.3.3 两种范式的对比

维度
提示词工程
上下文工程

优化焦点

指令的表述

提供的信息

关键资源

优化的语言和模板

高质量的上下文数据

主要工作

写、修改提示词

数据收集、整理、选择

衡量指标

提示词的清晰度、详细度

上下文的相关性、覆盖率

扩展性

有限的(人工调整)

可扩展的(自动化选择)

成本驱动因素

迭代调整的时间

上下文处理的 token 数

典型工具

文本编辑器、提示库

向量数据库、检索系统

13.3.4 为什么现在转向上下文工程

技术进步的驱动

  1. 模型能力的成熟:Claude 等现代 LLM 已经足够强大,不需要复杂的提示技巧就能理解简单指令

  2. 上下文窗口的扩大:从 4K 到 200K 甚至 1M token,提供丰富上下文成为可能

  3. 检索技术的进步:向量搜索和 RAG 使得从大型数据库中智能提取相关信息成为可能

  4. 缓存和成本优化:提示缓存等技术使得包含大量上下文变得经济可行

实际应用的反馈

通过分析数百万个 Claude 的实际使用案例,我们发现:

  • 包含充分背景信息的请求,即使提示词简洁,也往往得到高质量的输出

  • 提示词优化的改进通常只能带来 5-10% 的性能提升

  • 上下文优化(选择更相关的信息)往往能带来 30-50% 的性能提升

  • 对于知识密集型任务,充分的上下文甚至可以弥补模型知识的时效性限制

13.3.4.1 补充:Context Rot 与 Attention Budget 的科学基础

虽然 LLM 的处理速度和数据管理能力不断提升,但有一个根本的技术限制困扰着所有模型:Context Rot(上下文衰减)现象。

Context Rot 的机制

研究表明,随着上下文窗口中 token 数量的增加,模型准确回忆该上下文中信息的能力会逐步下降。这并非简单的线性衰减,而是一个复杂的现象:

  • Needle-in-a-Haystack 问题:当在大量信息(干草堆)中寻找关键信息(针)时,即使具有大上下文窗口的模型也会表现出信息检索准确度的下降

  • 位置偏差:信息的位置(相对于上下文起点或终点)会影响模型对其的关注度

  • 交叉模式衰减:超大上下文中,模型难以有效捕捉不同位置 token 之间的关系

Attention Budget(注意力预算)

就像人类拥有有限的工作记忆容量一样,LLM 拥有有限的"注意力预算"。这种注意力稀缺性源于 LLM 的架构基础——Transformer 模型。

关键事实:

  • 平方级复杂度:Transformer 的自注意力机制为 n 个 token 创建 n² 个成对的注意力关系

  • 参数训练分布:LLM 的参数是根据训练数据(通常以较短序列为主)进行优化的,对超长序列的处理能力有限

  • 边际收益递减:每增加一个新 token,注意力预算的消耗呈非线性增长

对实践的启示

既然上下文是有限的、珍贵的资源,好的上下文工程的核心原则就是:

找到最小的高信号 token 集合,以最大化所需结果的可能性。

这意味着:

  • 不是所有信息都应该加入上下文

  • 上下文的质量(相关性、清晰度)比数量(token 总数)更重要

  • 需要动态、迭代地精选上下文,而不是一劳永逸地准备


融入自 Anthropic 的《Effective context engineering for AI agents》中关于 Context Rot 和 Attention Budget 的科学分析

第二节 上下文工程的四大策略

上下文工程通过四个主要维度来优化模型的表现:

13.3.5 策略一:写入 - 制造高质量的上下文

写入指的是为你的特定需求创建、编写或生成上下文内容。

应用场景

  • 为 Claude 编写详细的背景说明、指导原则或参考资料

  • 创建系统提示词(System Prompt)来定义 Claude 的角色和约束

  • 编写示例和参考案例供 Claude 学习

最佳实践

示例:金融顾问系统提示词

写入的成本

编写高质量的背景信息和系统提示词需要投入:

  • 专业知识(了解领域的关键概念)

  • 清晰的表达能力

  • 对目标任务的深刻理解

但这个投入是一次性的,之后可以重复使用,所以 ROI 通常很高。

13.3.6 策略二:选择 - 检索相关的上下文

选择指的是从大量可用信息中智能地选择与当前任务最相关的内容。

核心问题

在信息爆炸的时代,问题不是信息的缺乏,而是过多。Claude 需要的是相关的、高质量的上下文,而不是所有可用的上下文。

实现方法

方法 1:向量搜索和语义相似度

方法 2:结构化元数据选择

选择的最佳实践

  1. 考虑时间鲜度:优先选择最新的信息

  2. 关注权威性:选择来自可信源的信息

  3. 平衡覆盖面和深度:包括概览性和详细的内容

  4. 避免冗余:不要包含高度重叠的内容

13.3.7 策略三:压缩 - 去除冗余,保留精华

压缩指的是减少上下文的大小,同时保持其信息价值。

压缩技术

技术 1:抽象式总结

技术 2:结构化提取

技术 3:去重和去冗余

压缩的成本-收益分析

压缩方法
压缩率
信息丧失
适用场景

摘要

50-80%

5-10%

长文档、新闻文章

结构化提取

40-70%

15-25%

数据密集文档

去重

10-30%

0%

多源信息

关键词提取

20-40%

30-40%

快速索引

13.3.8 策略四:隔离 - 分离不同类型的上下文

隔离指的是明确分离不同来源、不同类型的上下文,以避免混淆和冲突。

隔离的意义

在复杂的应用中,上下文通常来自多个源:

  • 用户提供的信息

  • 检索到的背景知识

  • 系统定义的规则

  • 历史对话记录

  • 外部数据集

如果这些混在一起,Claude 可能会混淆哪些是事实、哪些是假设、哪些是用户的意见。

隔离的实现

隔离的最佳实践

  1. 使用 XML 标签分隔<background>, <user_input>, <constraints>

  2. 明确标注来源:标记每个信息的来源和可信度

  3. 区分事实和观点:明确哪些是验证的事实,哪些是假设或观点

  4. 版本控制:标记上下文的版本和更新时间

13.3.8.1 补充:系统提示词的 Altitude 校准

系统提示词的设计涉及一个关键平衡问题:在两个常见失败模式之间找到"金发姑娘区"(Goldilocks zone)。

两个极端的陷阱

  1. 过度硬编码 (Overly Hardcoded)

    • 工程师在提示词中编写复杂的 if-else 逻辑和具体指令

    • 问题:变得脆弱、难以维护,随时间推移复杂性急剧增加

    • 例:逐条列出 50 项"禁止做"的指令,最后发现每条都需要异常处理

  2. 过度宽泛 (Overly Vague)

    • 提示词太过笼统,没有给予具体的行为信号

    • 假设 Claude 能理解未明确说明的隐含上下文

    • 问题:模型缺乏清晰的约束,往往偏离预期方向

正确的 Altitude(高度)

最优的系统提示词应该:

  • 足够具体:清晰地指导行为和输出格式,提供足够的约束

  • 足够灵活:给予模型解释空间和创意发展空间,而不是命令式的每步指令

  • 提供启发式而非规则:使用"倾向于..."和"优先考虑..."而不是"永远不能..."

  • 自解释:好的启发式提示自然会导出正确行为,而无需详细列举所有情况

Altitude 校准技巧

  1. 从最小化开始:先用最简洁的提示测试最能干的模型

  2. 基于失败模式迭代:遇到问题时添加明确指导(而不是预先填满提示词)

  3. 使用多阶段示例:提供少量示例来演示期望的思维过程,而不是罗列规则

  4. 优先使用正向指导:说"在 X 情况下做 Y"比"永远不要做 Z"更有效

  5. 定期审查和精简:随着经验积累,移除已成为模型直觉的冗余指导

实践例子

不好的写法:

好的写法:


融入自 Anthropic 的《Effective context engineering for AI agents》中关于系统提示词设计的altitude校准原则

第三节 Claude 中的上下文工程实践

13.3.9 系统提示词的精心设计

系统提示词是上下文工程中最强大的工具。与普通的用户消息不同,系统提示词定义了模型的基本行为和约束。

系统提示词的三层结构

13.3.10 使用 XML 结构化上下文

XML 标签提供了清晰的结构化方式来组织复杂的上下文。

13.3.11 RAG 与上下文工程的结合

RAG 是上下文工程中最实用的技术之一。

RAG 的基本流程

13.3.11.1 补充:混合检索策略与工具Token效率

在构建实际的上下文工程系统时,选择何种检索策略是一个关键权衡问题。

三种主要检索方式对比

  1. Agentic Search(智能检索)

    • 使用 bash 命令(grep、find、tail 等)让 Agent 主动探索文件系统

    • 优点:准确性高、透明度好、能捕捉文件命名和结构信息、避免索引过期

    • 缺点:速度较慢(需要多次文件 I/O)、需要对目录结构有良好设计

  2. 语义搜索(Semantic Search)

    • 基于向量化嵌入的相似度匹配

    • 优点:速度快、可以找到语义相关但措辞不同的内容

    • 缺点:准确性有时不如字面搜索、需要维护向量索引、嵌入模型选择很关键

  3. 混合策略(Hybrid Approach) - 推荐用于生产系统

    • 预先加载高优先级的关键信息(如 CLAUDE.md、系统配置)

    • 用 Agentic Search 处理大型文件和动态内容

    • 用语义搜索加速特定类型的信息查找

    • 允许 Agent 在发现新内容时灵活切换策略

工具设计的Token效率

工具的设计对整体 token 成本有重大影响:

  • 返回的信息应精准:工具不应返回整个对象,而是返回经过精心选择的相关信息

  • 避免重复:设计工具时考虑 Agent 可能多次调用同一工具,防止返回冗余数据

  • 嵌套和关联:相关的工具调用应该能在一个调用中完成,而不是分开的多个调用

例如,在电子邮件应用中:

  • 不好:list_all_emails() 返回所有邮件(可能数千条),Agent 需要逐条读取

  • 好:search_emails(query, limit=10) 直接返回相关摘录,或 get_email_summary(email_id) 返回关键信息


融入自 Anthropic 的《Effective context engineering for AI agents》中关于混合检索策略的最佳实践

13.3.12 MCP 与上下文工程的集成

模型上下文协议(MCP)与上下文工程是天然的配合。MCP 提供了一种标准化的方式来为 Claude 提供动态的、实时的上下文。

第四节 实际案例分析

案例 1:技术文档的实时答疑系统

场景

一个公司需要为产品的技术文档构建一个自动化答疑系统,用户可以提问关于产品的技术细节。

上下文工程方案

  1. 写入:创建系统提示词,定义回答者的角色

  2. 选择:使用 RAG 从文档库中检索相关内容

  3. 压缩:如果检索到的文档太长,进行摘要压缩

  4. 隔离:明确区分官方文档、已知问题、用户问题

案例 2:代码审查系统

场景

一个开发团队需要一个 AI 辅助的代码审查系统,能够检查代码的质量、安全性和最佳实践。

上下文工程方案

  1. 写入:编写详细的代码审查标准和检查项清单

  2. 选择:选择相关的历史代码审查记录作为参考

  3. 压缩:对相关代码进行摘要(展示关键部分)

  4. 隔离:分离安全问题、性能问题、风格问题

第四节:RAG 与 MCP 的上下文管理实践

13.3.13 RAG 的上下文工程

RAG 是上下文工程的核心应用场景之一。通过检索相关文档来动态构建上下文,可以在不扩大模型本身的情况下显著提升知识覆盖范围。

完整的 RAG 实现示例

成本优化:使用提示缓存

13.3.14 MCP 作为上下文工程的桥梁

MCP(Model Context Protocol)提供了一种标准化的方式来动态地获取和管理上下文。MCP 可以连接到各种数据源(数据库、APIs、文件系统等),为 Claude 提供实时的、结构化的上下文。

MCP 在上下文工程中的角色

实现示例:使用 MCP 获取实时上下文

13.3.15 大规模上下文的成本优化

对于处理大量上下文的应用,成本优化至关重要。

策略 1:分层上下文

策略 2:使用 Batch API 降低成本

对于不需要实时响应的任务,使用 Batch API 可以降低 50% 的成本:

第五节 实践案例:MCP 驱动的动态上下文工程

13.3.16 场景:实时 GitHub 知识库与 AI 助手集成

背景:使用 MCP 连接 GitHub 知识库,动态获取最新文档和代码作为上下文。

13.3.17 MCP 上下文工程的优势

动态性

  • 上下文始终是最新的(从实时源获取)

  • 能够在对话过程中调整上下文

相关性

  • 基于查询的智能选择(分析器确定需要什么)

  • 避免不相关的信息堵塞

可扩展性

  • 易于添加新的 MCP 源(数据库、API、文件系统)

  • 支持复杂的跨源查询

成本效益

  • 只获取必需的信息

  • 减少冗余和低质量的上下文

13.3.18 与传统 RAG 的对比

特性
传统 RAG
MCP 驱动

数据来源

静态知识库

动态,多个 MCP 源

更新频率

定期重新索引

实时

上下文选择

向量相似度

智能分析 + 向量搜索

集成成本

需要 embedding 模型

标准 MCP 协议

适用场景

静态文档

快速变化的数据

第六节 总结与最佳实践

13.3.19 上下文工程的黄金法则

  1. 相关性优先:不是信息越多越好,而是信息越相关越好

  2. 一致性维护:确保不同部分的上下文在逻辑上一致

  3. 清晰结构化:使用明确的标签和分隔符组织上下文

  4. 定期更新:保持上下文的时效性和准确性

  5. 可测量优化:建立指标来衡量上下文质量的改进

13.3.20 迁移检查清单

从提示词工程迁移到上下文工程:

13.3.21 工具和资源

推荐工具

  • 向量数据库:Pinecone、Weaviate、Milvus

  • 文档处理:LangChain、LlamaIndex

  • MCP 平台:Anthropic 官方 MCP 服务器

深入学习


上下文工程代表了与 LLM 交互的一个范式转变。通过关注提供什么信息、而非如何指示,我们能够更有效地利用 Claude 的能力,构建更强大、更可靠的 AI 应用。

最后更新于