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.5 策略一:写入(Writing)- 制造高质量的上下文

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

应用场景

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

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

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

最佳实践

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

写入的成本

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

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

  • 清晰的表达能力

  • 对目标任务的深刻理解

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

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

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

核心问题

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

实现方法

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

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

选择的最佳实践

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

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

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

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

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

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

压缩技术

技术 1:抽象式总结

技术 2:结构化提取

技术 3:去重和去冗余

压缩的成本-收益分析

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

摘要

50-80%

5-10%

长文档、新闻文章

结构化提取

40-70%

15-25%

数据密集文档

去重

10-30%

0%

多源信息

关键词提取

20-40%

30-40%

快速索引

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

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

隔离的意义

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

  • 用户提供的信息

  • 检索到的背景知识

  • 系统定义的规则

  • 历史对话记录

  • 外部数据集

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

隔离的实现

隔离的最佳实践

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

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

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

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

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

13.3.9 系统提示词的精心设计

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

系统提示词的三层结构

13.3.10 使用 XML 结构化上下文

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

13.3.11 RAG(检索增强生成)与上下文工程的结合

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

RAG 的基本流程

13.3.12 MCP 与上下文工程的集成

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

第四节 实际案例分析

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

场景

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

上下文工程方案

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

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

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

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

案例 2:代码审查系统

场景

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

上下文工程方案

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

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

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

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

{code_to_review}

第四节(扩展):实践应用 - 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 服务器

深入学习

  • Anthropic 官方文档:https://docs.anthropic.com

  • MCP 规范:https://modelcontextprotocol.io

  • 关于上下文工程的研究论文


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

最后更新于