
上下文精炼听起来很抽象,但一旦真正理解,你会发现它贯穿于每一次AI交互之中。对于构建AI智能体和工作流的开发者而言,理解上下文精炼是区分"偏离任务的智能体"与"保持专注的智能体"的关键所在。
定义
上下文精炼是指AI模型根据交互过程中累积的上下文——而非仅最近一条输入——调整其理解、输出或行为的过程。
更准确地说:它是对话早期的上下文影响后续回复的机制,以及如何有意识地设计智能体以利用(或重置)这种累积上下文。
为什么它比提示词工程更重要
提示词工程关注的是如何构造正确的输入以获得正确的输出。而上下文精炼关注的是管理影响模型在多轮交互中行为的整体信息状态。
实践中的区别:
| 提示词工程 | 上下文精炼 |
|---|---|
| "如何措辞这个提示词?" | "此时模型拥有什么上下文?" |
| 单轮优化 | 多轮状态管理 |
| 词语选择与结构 | 信息架构 |
| 单次请求质量 | 系统级行为质量 |
两者都很重要。但随着AI系统变得越来越具有智能体属性——在多个步骤中做出决策——上下文精炼变得愈发关键。
上下文如何影响AI行为
大语言模型在会话之间没有记忆,但在上下文窗口内,所有内容都会累积并影响模型行为:
- 近因效应: 最近的信息权重高于旧上下文
- 矛盾冲突: 后续上下文可以覆盖早期指令(有利有弊)
- 角色持久性: 在上下文早期建立的角色定义会持续存在
- 错误传播: 多步骤任务中早期的错误如不纠正会不断累积
这正是为什么一个从清晰上下文出发的精心设计的智能体,与一个累积了杂乱、矛盾上下文的智能体表现迥异——即便它们使用的是同一个模型。
开发者的上下文精炼技术
1. 上下文播种
在主任务开始前建立正确的上下文:
# 在主任务提示词之前建立:
context = """
Project: E-commerce platform in TypeScript/Next.js
Patterns: Functional programming, immutable state
Constraints: No class components, use zustand for state
Error handling: Use Result types from src/types/result.ts
Testing: Jest with React Testing Library
"""
response = client.messages.create(
messages=[
{"role": "user", "content": context + "\n\n" + main_task}
]
)
2. 渐进式上下文加载
与其一开始就加载所有上下文(这会填满上下文窗口并降低推理质量),不如在需要时渐进式地加载上下文:
class ContextManager:
def __init__(self, model):
self.model = model
self.context_items = []
def add_context(self, item: str, priority: int = 5):
self.context_items.append({"content": item, "priority": priority})
def get_active_context(self, max_tokens: int = 4000) -> str:
# 按优先级排序,优先包含高优先级项目
sorted_items = sorted(self.context_items, key=lambda x: -x['priority'])
active = []
total = 0
for item in sorted_items:
item_tokens = len(item['content']) // 4 # 概算
if total + item_tokens > max_tokens:
break
active.append(item['content'])
total += item_tokens
return "\n\n".join(active)
3. 上下文检查点
在长时间的智能体工作流中,定期汇总并重置上下文以防止漂移:
async def run_agent_with_checkpoints(task: str, steps: list):
context_summary = ""
for i, step in enumerate(steps):
# 执行当前步骤
result = await agent.run(
task=step,
context=context_summary
)
# 每3步创建一个上下文检查点
if i % 3 == 2:
context_summary = await agent.run(
task="Summarize the key facts, decisions made, and current state in 200 words",
context=result
)
return result
4. 上下文隔离
当需要模型在不受先前上下文影响的情况下进行推理时:
# 启动全新上下文进行独立推理
isolated_response = client.messages.create(
system="You are a code reviewer with no prior context about this project.",
messages=[
{"role": "user", "content": f"Review this function:\n\n{code}"}
]
)
多智能体系统中的上下文精炼
当多个智能体协同工作时,上下文管理成为一个协调问题:
智能体A(研究员)
↓ 传递:结构化JSON格式的研究结果
智能体B(撰写者)
↓ 传递:草稿 + "已做决策"摘要
智能体C(审阅者)
↓ 传递:审阅备注 + "接受/拒绝"决定
智能体D(发布者)
每次交接都是一个机会:传递正确的上下文(让智能体B能够在智能体A工作的基础上继续),或传递过多(导致智能体B重复工作),或传递过少(导致智能体B丢失重要决策)。
最佳实践: 流水线中的每个智能体应接收:
- 其具体任务
- 导致此阶段的决策(而非完整的讨论过程)
- 适用于其工作的约束条件
- 清晰的输出格式要求
AnyCap工作流中的上下文精炼
AnyCap的技能系统在设计时充分考虑了上下文精炼。每个技能接收:
- 结构化的任务简报
- 相关的工作区上下文(来自智能体的当前状态)
- 特定能力的参数
这意味着你可以串联AnyCap的各项能力,而无需每个能力重新理解完整的项目上下文:
# 智能体一次性建立上下文
anycap skill run anycap-deepresearch \
-m "Research competitive landscape for AI video generation APIs"
# 后续能力基于结构化输出工作,而非原始上下文
anycap image generate \
--prompt "Comparison diagram: Kling vs Seedance vs Veo3 feature matrix, clean table style" \
--model nano-banana-2
# 每个能力获得恰当的上下文,不多也不少
核心要点
- 上下文精炼是对累积上下文的管理——而非单个提示词的质量
- 上下文在长会话中会漂移——使用检查点和
/compact来管理它 - 渐进式加载优于预先倾倒所有上下文——在需要时添加上下文
- 多智能体系统需要明确的上下文交接协议——不要假设上下文会自动流转
- 隔离是一种技术——有时需要全新的上下文来获得更好的推理效果
→ 上下文工程指南 → AnyCap能力概览