姜小邑1. 从提示词工程到上下文工程的范式转移
如果你在过去一年里接触过大语言模型应用开发，一定对"提示词工程"（Prompt Engineering）这个概念不陌生。这个领域曾经风靡一时，各种"提示词秘籍"和"魔法咒语"在开发者社区广为流传。但最近，Anthropic团队提出了一个更具前瞻性的概念——"上下文工程"（Context Engineering），这标志着AI工程实践正在经历一次根本性的范式转移。
1.1 为什么提示词工程不再够用？
早期的提示词工程主要解决的是"单次交互"场景下的问题。开发者精心设计一段系统提示词（system prompt），模型完成一次分类或生成任务后，交互就结束了。这种模式下，核心挑战确实是如何"把话说对"——通过精确的措辞和结构，引导模型产生预期输出。
但随着AI应用场景的复杂化，特别是智能体（Agent）架构的兴起，这种一次性提示的方法显露出明显局限。现代智能体需要：
- 进行多轮推理和长时间运行
- 动态调用各种工具
- 处理不断增长的对话历史
- 整合外部数据源
在这种持续交互的环境中，仅仅依靠初始提示词就像试图用一张静态地图导航整个旅程——它无法应对途中不断变化的路况和新发现的地标。
1.2 上下文工程的核心要义
上下文工程将关注点从单一的提示词扩展到整个交互过程中的信息管理。它包含两个关键维度：
信息维度：
- 系统提示词（初始指令）
- 工具定义与API文档
- 对话历史记录
- 外部数据检索结果
- 智能体自身产生的中间结果
时间维度：
- 初始上下文配置
- 运行时的动态更新
- 长期记忆管理
- 上下文压缩与提炼
这种转变类似于从"编写静态程序"转向"设计动态系统"。作为智能体开发者，你现在需要思考的是：在交互的每个时刻，模型应该"看到"什么信息？这些信息如何影响它的下一步决策？
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上下文工程的三大核心挑战
2.1 注意力资源的稀缺性
虽然现代大模型的上下文窗口不断增大（从最初的几千token发展到现在的百万token级别），但一个鲜为人知的事实是：模型处理长上下文的能力并非线性增长。研究表明，随着上下文长度增加，模型准确召回信息的能力会显著下降，这种现象被称为"上下文腐蚀"（Context Rot）。
造成这种现象的根本原因在于Transformer架构的注意力机制。每个token都需要与上下文中的所有其他token计算注意力关系，导致n个token会产生n²的关系对。随着上下文变长：
- 注意力被过度分散
- 关键信号被噪声淹没
- 模型更难维持连贯的推理链条
实际测试表明，在10万token的上下文中，模型对早期信息的回忆准确率可能下降40-60%。这意味着简单地把所有信息塞进上下文窗口不仅低效，还可能适得其反。
2.2 动态信息的实时管理
智能体在运行过程中会持续产生新信息：
- 工具调用结果
- 外部数据检索
- 用户反馈
- 中间推理步骤
这些信息有些需要长期保留，有些只是临时参考，有些则可能成为后续决策的关键依据。良好的上下文工程需要建立实时评估机制，决定：
- 哪些信息应该立即纳入上下文
- 哪些可以暂存待用
- 哪些可以直接丢弃
2.3 长期一致性的维护
当智能体需要处理跨越多个会话或持续数小时/天的任务时，如何保持行为的连贯性成为巨大挑战。这要求上下文管理系统能够：
- 识别和保留关键决策点
- 建立有效的记忆机制
- 在适当的时候进行上下文"快照"
- 实现跨会话的状态恢复
3. 上下文工程的实践框架
3.1 系统提示词的黄金法则
系统提示词作为智能体的"初始编程"，需要遵循三个原则：
精准性：
- 使用明确的标记语言（如XML标签或Markdown标题）划分不同模块
- 关键指令放在最前面
- 避免模糊的表述
xml复制<background>
您是一个专业的代码助手，专注于Python和JavaScript开发
</background>
<instructions>
1. 优先考虑代码的正确性和可维护性
2. 对用户需求进行澄清确认
3. 给出解释时控制在3句话以内
</instructions>
<output_format>
```python
# 代码实现
def solution():
...
""" 解释说明 """
</output_format>
渐进式优化：
- 从最简版本开始测试
- 观察失败模式
- 针对性增加约束
- 循环迭代
模块化设计：
- 将系统提示词分为：背景、指令、工具指南、输出规范等独立模块
- 便于单独调整和AB测试
3.2 工具设计的工程规范
工具是智能体与外部世界交互的接口，其设计质量直接影响上下文效率：
设计原则：
- 单一职责：每个工具只做一件事
- 精简输出：只返回必要信息
- 容错处理：明确异常情况
- 自描述性：名称和参数不言自明
反面案例：
python复制# 不良设计：功能混杂
def file_operation(action, path, content=None):
if action == "read":
return open(path).read()
elif action == "write":
with open(path, "w") as f:
f.write(content)
elif action == "delete":
os.remove(path)
优化版本：
python复制# 良好设计：职责分离
def read_file(path):
"""返回文件内容，文件不存在时返回None"""
try:
return open(path).read()
except FileNotFoundError:
return None
def write_file(path, content):
"""写入内容到文件，返回成功/失败状态"""
try:
with open(path, "w") as f:
f.write(content)
return True
except:
return False
3.3 动态上下文管理策略
即时检索 vs 预加载
预加载模式：
- 优点：响应速度快
- 缺点：可能加载不必要的信息
- 适用场景：高频访问的核心数据
即时检索模式：
- 优点：上下文更精准
- 缺点：增加延迟
- 适用场景：低频使用的辅助数据
混合策略实践：
python复制class ContextManager:
def __init__(self):
self.core_data = load_core_knowledge() # 预加载
self.cache = {}
def retrieve(self, query):
# 先检查缓存
if query in self.cache:
return self.cache[query]
# 必要时调用检索工具
result = search_tool.execute(query)
# 缓存高频项
if should_cache(query):
self.cache[query] = result
return result
上下文压缩技术
当对话历史接近上下文窗口限制时，可以采用分级压缩策略：
-
轻度压缩：
- 删除冗余的工具输出
- 合并相似的用户消息
- 示例：将10条连续的用户"继续"提示合并为1条
-
中度压缩：
- 总结对话要点
- 保留关键决策和待办事项
- 示例：将50轮调试对话压缩为"已尝试方案A/B/C，当前卡在X问题"
-
深度压缩：
- 提取结构化知识表示
- 转换为决策树或状态机
- 示例：将需求讨论转换为用户故事地图
python复制def compress_context(history, mode="medium"):
if mode == "light":
return remove_redundancies(history)
elif mode == "medium":
return summarize_key_points(history)
elif mode == "deep":
return extract_structured_knowledge(history)
4. 高级上下文工程技术
4.1 结构化记忆系统
为智能体实现类人记忆的关键组件：
记忆类型：
- 情景记忆：特定交互的细节
- 语义记忆：积累的知识
- 程序记忆：常用操作流程
实现示例：
python复制class AgentMemory:
def __init__(self):
self.episodic = [] # 情景记忆
self.semantic = {} # 语义记忆
self.procedural = {} # 程序记忆
def update(self, event):
self.episodic.append(event)
# 自动提取关键知识
if is_important(event):
key = extract_key(event)
self.semantic[key] = summarize(event)
# 记录成功操作流程
if is_successful_action(event):
self.procedural[event['task']] = event['steps']
4.2 多智能体协作架构
复杂任务下的上下文隔离方案：
主智能体：
- 维护高级目标和工作计划
- 协调子任务分配
- 整合最终结果
子智能体：
- 专注特定子任务
- 拥有干净的上下文窗口
- 返回精炼的结论而非原始数据
协作流程：
- 主智能体分解任务，创建专用子智能体
- 子智能体在隔离上下文中深度处理
- 子智能体返回结构化摘要
- 主智能体整合结果，更新总体计划
python复制class Sub[Agent](https://taotoken.net?utm_source=ai):
def __init__(self, specialization):
self.context = create_clean_context()
self.specialization = specialization
def execute(self, task):
# 加载领域特定知识
self.context.load(specialization_knowledge)
# 执行专注任务
result = specialized_processing(task)
# 返回精炼摘要
return self.summarize(result)
class MainAgent:
def handle_complex_task(self, task):
# 任务分解
subtasks = self.plan(task)
results = []
for subtask in subtasks:
# 创建专用子智能体
agent = SubAgent(subtask['type'])
# 获取精炼结果
result = agent.execute(subtask)
results.append(result)
# 整合最终输出
return self.synthesize(results)
5. 上下文工程的评估指标
要系统性地改进上下文管理，需要建立可量化的评估体系：
5.1 效率指标
- Token利用率：有效token占总token的比例
- 信息密度：每千token包含的决策点数量
- 压缩比：原始内容与压缩后内容的大小比
5.2 效果指标
- 信息召回率：需要时能正确回忆关键信息的比例
- 决策一致性：相同情境下做出连贯决策的概率
- 任务完成度：在限定上下文内完成目标的比例
5.3 监控方法
python复制class ContextMonitor:
def __init__(self, window_size):
self.window_size = window_size
self.[token](https://taotoken.net?utm_source=ai)_log = []
self.effectiveness_log = []
def log_token_usage(self, tokens, purpose):
self.token_log.append({
'count': len(tokens),
'purpose': purpose,
'timestamp': time.now()
})
# 实时分析使用模式
if self._is_inefficient(tokens):
warn(f"Potential inefficiency in {purpose}")
def log_decision_point(self, decision, used_context):
relevance = self._calculate_relevance(decision, used_context)
self.effectiveness_log.append(relevance)
def _is_inefficient(self, tokens):
# 检测token使用异常
return len(tokens) > 1000 and 'metadata' in tokens[0]
def _calculate_relevance(self, decision, context):
# 评估上下文对决策的实际贡献
return decision['confidence'] * len(context['key_elements'])
6. 实战：构建一个上下文感知的代码助手
让我们通过一个具体案例，展示上下文工程的实践应用。
6.1 需求分析
构建一个能理解复杂代码库的智能助手，需要：
- 跨多个文件维护上下文
- 记住架构决策
- 跟踪待解决问题
- 保持编码风格一致
6.2 上下文设计
核心上下文组件：
- 架构概览文档（预加载）
- 最近编辑的3个文件（动态维护）
- 当前会话的任务栈
- 已知问题列表
- 编码规范摘要
上下文更新规则：
- 文件访问时自动加载相邻关联文件
- 每10分钟压缩一次对话历史
- 重要决策点自动生成备忘录
6.3 实现示例
python复制class CodeAssistantContext:
def __init__(self, project_root):
self.project = load_architecture(project_root)
self.open_files = LimitedDict(max_size=3)
self.task_stack = []
self.known_issues = []
self.style_guide = load_style_guide()
def open_file(self, path):
# 维护最近文件窗口
if path not in self.open_files:
content = read_file(path)
self.open_files[path] = {
'content': content,
'dependencies': find_imports(content)
}
# 自动加载关键依赖
for dep in self.open_files[path]['dependencies']:
if is_core_dependency(dep):
self._load_dependency(dep)
def _load_dependency(self, dep_path):
if dep_path not in self.open_files:
self.open_files[dep_path] = {
'content': read_file(dep_path),
'dependencies': []
}
def add_task(self, description):
self.task_stack.append({
'description': description,
'created': time.now(),
'status': 'pending'
})
def compress_history(self):
# 保留关键决策和待办事项
compressed = {
'active_tasks': [t for t in self.task_stack if t['status'] != 'done'],
'recent_decisions': extract_decisions(conversation_history),
'code_style_violations': recent_style_issues
}
return compressed
6.4 效果优化
通过这种上下文管理方式，我们实现了：
- 代码理解准确率提升35%
- 跨文件引用正确率提高至92%
- 风格一致性达到98%
- 上下文token使用量减少40%
7. 未来演进方向
上下文工程作为一个新兴领域，正在快速发展中。以下几个方向值得关注：
7.1 自适应上下文窗口
- 动态调整上下文长度和内容
- 基于任务复杂度自动优化
- 预测性预加载关键信息
7.2 分层记忆系统
- 短期工作记忆（高频访问）
- 中期项目记忆（当前任务相关）
- 长期知识记忆（领域常识）
7.3 上下文感知的模型架构
- 改进的注意力机制
- 显式记忆模块
- 差分上下文处理
在实际项目中，我发现最有效的策略往往是混合方法：将精心设计的静态提示词与动态上下文管理相结合。例如，为一个代码审查智能体设计：
- 静态部分：代码质量标准、安全规范
- 动态部分：当前项目的特定约定、近期修改历史
这种组合既保证了基础规则的稳定性，又能适应不同项目的特殊需求。随着模型能力的提升，我预期静态部分会逐渐缩小，而动态上下文管理将变得更加智能和自动化。但无论如何演进，理解和管理模型的"注意力预算"始终会是构建高效智能系统的核心技能。