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)
虽然这些技术确实有效,但存在几个本质的限制:
边际收益递减:经过一定的优化后,提示词改进带来的性能提升开始平缓
模型能力瓶颈:再好的提示词也无法让模型完成它能力范围之外的任务
输出质量的天花板:模型的最终表现由其训练数据和能力所决定,而不仅由提示词
新的认知
随着 Claude 3.5 系列模型的推出和用户规模的扩大,我们发现了一个更深层的真相:
问题不在于如何问,而在于给模型什么信息。
当我们为 Claude 提供充分的、相关的、高质量的上下文信息时,即使使用相对简洁的指令,模型也能表现出色。相反,再精妙的提示词也无法弥补上下文信息的缺失。
13.3.2 上下文工程的定义
上下文工程(Context Engineering)是指系统地设计、选择、组织和呈现给 LLM 的输入信息(上下文),以优化模型的输出质量、准确性、可靠性和效率的实践和方法论。
核心特点:
以信息为中心:关注提供给模型的信息的质量、相关性和组织
动态和自适应:上下文不是静态的,而是根据任务动态选择和调整的
多维度优化:优化维度包括信息的准确性、完整性、相关性、结构清晰度、时间鲜度等
系统化方法:采用明确的策略和流程来进行上下文设计
13.3.3 两种范式的对比
优化焦点
指令的表述
提供的信息
关键资源
优化的语言和模板
高质量的上下文数据
主要工作
写、修改提示词
数据收集、整理、选择
衡量指标
提示词的清晰度、详细度
上下文的相关性、覆盖率
扩展性
有限的(人工调整)
可扩展的(自动化选择)
成本驱动因素
迭代调整的时间
上下文处理的 token 数
典型工具
文本编辑器、提示库
向量数据库、检索系统
13.3.4 为什么现在转向上下文工程
技术进步的驱动
模型能力的成熟:Claude 等现代 LLM 已经足够强大,不需要复杂的提示技巧就能理解简单指令
上下文窗口的扩大:从 4K 到 200K 甚至 1M token,提供丰富上下文成为可能
检索技术的进步:向量搜索和 RAG 使得从大型数据库中智能提取相关信息成为可能
缓存和成本优化:提示缓存等技术使得包含大量上下文变得经济可行
实际应用的反馈
通过分析数百万个 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:结构化元数据选择
选择的最佳实践
考虑时间鲜度:优先选择最新的信息
关注权威性:选择来自可信源的信息
平衡覆盖面和深度:包括概览性和详细的内容
避免冗余:不要包含高度重叠的内容
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 可能会混淆哪些是事实、哪些是假设、哪些是用户的意见。
隔离的实现
隔离的最佳实践
使用 XML 标签分隔:
<background>,<user_input>,<constraints>等明确标注来源:标记每个信息的来源和可信度
区分事实和观点:明确哪些是验证的事实,哪些是假设或观点
版本控制:标记上下文的版本和更新时间
13.3.8.1 补充:系统提示词的 Altitude 校准
系统提示词的设计涉及一个关键平衡问题:在两个常见失败模式之间找到"金发姑娘区"(Goldilocks zone)。
两个极端的陷阱
过度硬编码 (Overly Hardcoded)
工程师在提示词中编写复杂的 if-else 逻辑和具体指令
问题:变得脆弱、难以维护,随时间推移复杂性急剧增加
例:逐条列出 50 项"禁止做"的指令,最后发现每条都需要异常处理
过度宽泛 (Overly Vague)
提示词太过笼统,没有给予具体的行为信号
假设 Claude 能理解未明确说明的隐含上下文
问题:模型缺乏清晰的约束,往往偏离预期方向
正确的 Altitude(高度)
最优的系统提示词应该:
足够具体:清晰地指导行为和输出格式,提供足够的约束
足够灵活:给予模型解释空间和创意发展空间,而不是命令式的每步指令
提供启发式而非规则:使用"倾向于..."和"优先考虑..."而不是"永远不能..."
自解释:好的启发式提示自然会导出正确行为,而无需详细列举所有情况
Altitude 校准技巧
从最小化开始:先用最简洁的提示测试最能干的模型
基于失败模式迭代:遇到问题时添加明确指导(而不是预先填满提示词)
使用多阶段示例:提供少量示例来演示期望的思维过程,而不是罗列规则
优先使用正向指导:说"在 X 情况下做 Y"比"永远不要做 Z"更有效
定期审查和精简:随着经验积累,移除已成为模型直觉的冗余指导
实践例子
不好的写法:
好的写法:
融入自 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效率
在构建实际的上下文工程系统时,选择何种检索策略是一个关键权衡问题。
三种主要检索方式对比
Agentic Search(智能检索)
使用 bash 命令(grep、find、tail 等)让 Agent 主动探索文件系统
优点:准确性高、透明度好、能捕捉文件命名和结构信息、避免索引过期
缺点:速度较慢(需要多次文件 I/O)、需要对目录结构有良好设计
语义搜索(Semantic Search)
基于向量化嵌入的相似度匹配
优点:速度快、可以找到语义相关但措辞不同的内容
缺点:准确性有时不如字面搜索、需要维护向量索引、嵌入模型选择很关键
混合策略(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:技术文档的实时答疑系统
场景
一个公司需要为产品的技术文档构建一个自动化答疑系统,用户可以提问关于产品的技术细节。
上下文工程方案
写入:创建系统提示词,定义回答者的角色
选择:使用 RAG 从文档库中检索相关内容
压缩:如果检索到的文档太长,进行摘要压缩
隔离:明确区分官方文档、已知问题、用户问题
案例 2:代码审查系统
场景
一个开发团队需要一个 AI 辅助的代码审查系统,能够检查代码的质量、安全性和最佳实践。
上下文工程方案
写入:编写详细的代码审查标准和检查项清单
选择:选择相关的历史代码审查记录作为参考
压缩:对相关代码进行摘要(展示关键部分)
隔离:分离安全问题、性能问题、风格问题
第四节: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 的对比
数据来源
静态知识库
动态,多个 MCP 源
更新频率
定期重新索引
实时
上下文选择
向量相似度
智能分析 + 向量搜索
集成成本
需要 embedding 模型
标准 MCP 协议
适用场景
静态文档
快速变化的数据
第六节 总结与最佳实践
13.3.19 上下文工程的黄金法则
相关性优先:不是信息越多越好,而是信息越相关越好
一致性维护:确保不同部分的上下文在逻辑上一致
清晰结构化:使用明确的标签和分隔符组织上下文
定期更新:保持上下文的时效性和准确性
可测量优化:建立指标来衡量上下文质量的改进
13.3.20 迁移检查清单
从提示词工程迁移到上下文工程:
13.3.21 工具和资源
推荐工具:
向量数据库:Pinecone、Weaviate、Milvus
文档处理:LangChain、LlamaIndex
MCP 平台:Anthropic 官方 MCP 服务器
深入学习:
关于上下文工程的研究论文
上下文工程代表了与 LLM 交互的一个范式转变。通过关注提供什么信息、而非如何指示,我们能够更有效地利用 Claude 的能力,构建更强大、更可靠的 AI 应用。
最后更新于
