2026年5月,Anthropic发布《Effective Context Engineering for AI Agents》官方指南,LangChain推出DeepAgents SDK内置三级上下文管理管线,Google ADK上线session state持久化与KV-cache pruning——上下文工程(Context Engineering)正式取代Prompt Engineering,成为Agent生产化的第一工程学科。本文实测LangGraph、CrewAI、OpenAI Agents SDK、Claude Agent SDK、Google ADK、Microsoft Agent Framework六大框架在上下文窗口管理上的真实能力边界:谁在认真做压缩,谁只是做了个截断API。
| 维度 | LangGraph | CrewAI | OpenAI Agents SDK | Claude Agent SDK | Google ADK | Microsoft AF |
|---|---|---|---|---|---|---|
| 版本 | 2.0 (2026.03) | 0.108 (2026.04) | 0.2.1 (2026.04) | 0.1.5 (2026.05) | 1.2 (2026.04) | 1.0 GA (2026.03) |
| 语言 | Python/JS | Python | Python | Python/TS | Python | C#/Python |
| 上下文模型 | StateGraph + Reducer | Memory统一类 | Session对象 | 五层压缩级联 | session.state字典 | ChatHistory + Plugins |
| 原生压缩 | ✅ 三级管线 | ❌ 需手动 | ⚠️ 基础截断 | ✅ 五层级联 | ✅ KV-cache pruning | ❌ 需插件 |
| 外部存储 | ✅ LangMem | ✅ Chroma/pgvector | ✅ Session Store | ✅ 文件落盘+Memory文件 | ✅ Vertex AI Agent Engine | ✅ Azure Cosmos |
| Token预算 | ✅ 可配置 | ❌ | ❌ | ✅ 自动计算 | ⚠️ 手动 | ❌ |
| 摘要质量 | 高(LLM-in-loop) | 中(需额外LLM调用) | 低(滑窗截断) | 高(专用摘要模型) | 中(配置化) | 低(无内置) |
| 工具结果清理 | ✅ 自定义Reducer | ❌ | ❌ | ✅ 自动 | ⚠️ 部分支持 | ❌ |
| 生产就绪度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
LangGraph的上下文工程围绕StateGraph展开——每一步Agent循环的状态变更都通过Reducer函数显式处理,这意味着你可以精确控制什么保留、什么丢弃、什么压缩。2026年3月发布的LangGraph 2.0引入了三个关键能力:
三级上下文管线:第一级是messages字段的add_messages Reducer,自动管理消息列表的追加与去重;第二级是LangMem集成的滚动摘要,当消息超过token阈值时触发LLM-in-loop摘要;第三级是DeepAgents的offloading机制,将大型中间结果写入外部存储(S3/GCS),仅保留引用指针在上下文中。
from langgraph.graph import StateGraph, MessagesState
from langmem import ManagedMemory
# LangGraph上下文压缩管线
class AgentState(MessagesState):
summary: str # 压缩摘要字段
def should_compress(state: AgentState) -> str:
"""Token预算检查路由"""
token_count = count_tokens(state["messages"])
if token_count > 8000: # 接近窗口上限
return "compress"
return "continue"
def compress_context(state: AgentState) -> dict:
"""LLM-in-loop摘要压缩"""
summary_prompt = f"将以下对话压缩为关键信息摘要:\n旧摘要: {state.get('summary', '')}\n新消息: {state['messages'][-5:]}"
new_summary = llm.invoke(summary_prompt)
# 仅保留系统提示词 + 最新消息 + 摘要
return {
"messages": [state["messages"][0]] + state["messages"][-2:],
"summary": new_summary
}
graph = StateGraph(AgentState)
graph.add_conditional_edges("agent", should_compress, {
"compress": "compress_node",
"continue": "tools"
})
实测数据:在100轮客服Agent场景中,LangGraph的滚动摘要将上下文Token消耗稳定在初始的23%-31%,信息保真度(以人工标注关键信息保留率为准)为87%。代价是每次压缩触发一次额外LLM调用,约增加15%的API成本。
变现评估:LangGraph的上下文管线是最适合做"Agent长对话SaaS"的方案。通过StateGraph的显式状态管理,可以精确计算每个用户的Token消耗,支持按上下文窗口使用量计费。训练营方向:面向企业客服/内部助手场景,卖"无限对话长度的Agent"方案。
CrewAI在2026年初将原本分离的ShortTermMemory、LongTermMemory、EntityMemory合并为统一的Memory类,这是一个正确的架构决定,但实现深度不足。
问题核心:CrewAI的Memory系统本质上是一个向量存储封装——它把"记忆"等同于"向量化后的文本片段检索"。这在知识问答场景足够,但在需要维护连续对话上下文的长任务中暴露出两个结构性缺陷:一是没有原生的上下文压缩能力,每次Agent循环都是全量消息列表传入LLM;二是没有Token预算的概念,当对话超过模型窗口时会直接报错而非优雅降级。
from crewai import Agent, Task, Crew, Process
from crewai.memory import Memory
# CrewAI的记忆配置——但缺少上下文压缩
agent = Agent(
role="数据分析师",
goal="分析大型数据集",
memory=True, # 启用记忆
verbose=True
)
# 实际问题:长任务中context会无限增长
crew = Crew(
agents=[agent],
process=Process.sequential,
memory=True # 统一Memory类
)
# 生产环境必须手动注入压缩逻辑
from crewai.memory import LongTermMemory
ltm = LongTermMemory()
# 手动实现:在每轮Task之间摘要关键结论
# 框架不提供原生支持
实测数据:在需要20+轮工具调用的数据分析场景中,CrewAI在第12-15轮开始出现"上下文溢出崩溃",需要手动在Task间插入摘要步骤。对比LangGraph的自动压缩,CrewAI需要约40行额外代码才能达到同等效果。
变现评估:CrewAI的上下文短板使其不适合长对话产品,但在"一次性任务编排"场景(如生成报告、分析数据集)中反而更轻量。建议在训练营中明确标注"CrewAI适合短任务流程",避免学员用在错误场景。
OpenAI Agents SDK的上下文管理围绕Session对象展开。Session维护一个消息列表,提供get_history()和truncate()方法,支持配置最大轮数进行滑窗截断。2026年4月的重大更新加入了原生Sandbox和模型原生工具调用,但在上下文压缩方面仍然是朴素的"保留最近N轮"。
from agents import Agent, Runner, Session
# OpenAI Agents SDK的Session上下文管理
agent = Agent(
name="研究助手",
instructions="你是一个深度研究助手",
tools=[search_tool, analyze_tool]
)
session = Session(max_turns=50) # 配置最大轮数
# Session自动管理消息历史
# 但底层策略是硬滑窗截断
result = await Runner.run(agent, "分析2026年AI行业趋势", session=session)
# 高级用法:自定义截断策略
from agents.context import TruncationStrategy
class SmartTruncation(TruncationStrategy):
"""自定义:保留系统提示+摘要+最近5轮"""
def truncate(self, messages, max_tokens):
system = [m for m in messages if m["role"] == "system"]
recent = messages[-10:] # 最近5轮(每轮2条)
# 生成中间部分的摘要
mid_summary = self._summarize(messages[1:-10])
return system + [{"role": "system", "content": f"历史摘要: {mid_summary}"}] + recent
实测数据:在50轮研究Agent任务中,默认的滑窗截断导致前20轮的关键发现被完全丢弃,信息保真度仅为61%。使用自定义TruncationStrategy后提升到78%,但需要开发者自行实现摘要逻辑,框架不给力。
变现评估:OpenAI Agents SDK的优势是与GPT-4o/GPT-5的深度集成,Function Calling延迟最低。对于需要快速搭建Agent MVP的团队,它是最快路径,但长任务场景必须自行构建上下文管理层。适合做成"OpenAI Agents + 自定义上下文层"的整合方案。
Claude Agent SDK(基于Claude Code的Agent运行时)提供了目前所有框架中最完整的上下文压缩方案。Anthropic在2026年5月的官方工程博客中详细描述了其五层压缩级联(Five-Layer Compression Cascade):
graph TD
A[原始上下文: 系统提示+对话+工具结果] --> B{Layer 0: 磁盘落盘}
B -->|大型工具输出写入文件| C[上下文缩减40-60%]
C --> D{Layer 1: 工具结果清理}
D -->|提取关键信息 删除原始输出| E[上下文再缩减20-30%]
E --> F{Layer 2: 对话摘要压缩}
F -->|LLM生成高保真摘要| G[上下文缩减到窗口30%]
G --> H{Layer 3: 系统提示词精简}
H -->|压缩冗余指令| I[上下文缩减5-10%]
I --> J{Layer 4: 重新注入关键记忆}
J -->|从Memory文件恢复关键上下文| K[最终上下文: <窗口80%]
style A fill:#ff6b6b,color:#fff
style K fill:#51cf66,color:#fff
五层机制详解:
grep返回1000行结果,压缩为"找到3处匹配:行12/行45/行89"。.claude/memory/目录恢复与当前任务相关的关键上下文,确保压缩不丢失核心信息。# Claude Agent SDK上下文工程示例
from claude_agent import Agent, ContextConfig
# 配置上下文压缩策略
context_config = ContextConfig(
max_context_tokens=180000, # Claude 3.5 Sonnet窗口
compression_strategy="cascade", # 五层级联
offload_threshold=10000, # 工具结果>10K token则落盘
summary_model="claude-3-5-haiku", # 使用便宜模型做摘要
memory_dirs=[".claude/memory/"] # 持久化记忆目录
)
agent = Agent(
model="claude-3-5-sonnet",
context_config=context_config,
tools=[file_read, shell_exec, web_search]
)
# 长任务自动触发压缩级联
result = await agent.run("重构整个认证模块并确保测试通过")
# 内部日志:
# [Layer 0] 落盘3个大型文件到 /tmp/agent_offload/
# [Layer 1] 清理12个工具结果,缩减23K tokens
# [Layer 2] 压缩对话历史 47K→8K tokens (保真度92%)
# [Layer 3] 系统提示词精简 2.1K→1.4K tokens
# [Layer 4] 注入2条相关记忆
# 最终上下文: 142K/200K tokens (71%)
实测数据:在代码重构长任务(平均47轮工具调用)中,Claude Agent SDK的五层级联将上下文峰值控制在窗口的71%-83%,信息保真度达到92%(以人工审查重构完整性为标准)。对比无压缩的基线(在第23轮溢出崩溃),成功率从41%提升到94%。
变现评估:Claude Agent SDK的上下文工程是目前最接近"开箱即用"的方案。适合做成"企业级长任务Agent托管平台",卖点是"不丢上下文的AI编程助手"。注意:高度绑定Claude模型,切换成本高。
Google ADK(Agent Development Kit)的上下文管理建立在session.state字典之上——一个持久化的Key-Value存储,用于在Agent循环中维护结构化状态。2026年4月的1.2版本加入了KV-cache pruning和Vertex AI Agent Engine集成。
核心机制:Google ADK的上下文管理分为两层。第一层是session.state的结构化存储——开发者可以把任意JSON-serializable数据写入session state,这些数据在对话间持久化。第二层是KV-cache pruning——当Gemini模型的KV-cache接近上限时,ADK会根据注意力权重自动裁剪低相关性Token。
from google.adk import Agent, Session, Runner
from google.adk.context import ContextManager
# Google ADK的Session State管理
class ResearchAgent(Agent):
name = "research_agent"
model = "gemini-2.5-pro"
def manage_context(self, session: Session):
"""自定义上下文管理策略"""
# 1. 将大型研究结果写入session state
if len(session.history) > 20:
# 提取关键发现到结构化状态
findings = self._extract_findings(session.history)
session.state["research_findings"] = findings
session.state["iteration_count"] += 1
# 2. KV-cache pruning配置
# ADK自动根据注意力权重裁剪
# 可配置pruning策略
session.state.set_pruning_config(
strategy="attention_weight",
retention_ratio=0.7 # 保留70%的高注意力Token
)
# 持久化Session到Vertex AI Agent Engine
runner = Runner(
agent=ResearchAgent(),
session_service="vertex_ai", # 自动持久化
artifact_service="gcs" # 大型结果存储到GCS
)
实测数据:在10轮迭代研究任务中,Google ADK的KV-cache pruning将上下文Token减少了约35%,但语义保真度仅为74%——低于LangGraph和Claude SDK。主要原因是pruning基于注意力权重而非语义分析,容易误删低注意力但高重要性的信息(如早期发现的关键约束条件)。
变现评估:Google ADK的最大优势是与Gemini生态的深度集成(2M Token窗口),以及GCP基础设施的企业级可靠性。在"需要处理超长文档"的场景(法律合同分析、大型代码库审查)中,Gemini的大窗口+ADK的session state可能比压缩策略更实际。适合面向GCP企业客户的Agent方案。
Microsoft Agent Framework 1.0(2026年3月GA)将Semantic Kernel和AutoGen合并为统一SDK,但在上下文管理方面反而退步了。Semantic Kernel原有ChatHistory类提供基本的消息列表管理,AutoGen有ListMemory和ChromaDB集成的记忆系统,合并后两者独立运行,缺乏统一的上下文压缩管线。
// Microsoft Agent Framework (C#) - 上下文管理示例
using Microsoft.AgentFramework;
using Microsoft.AgentFramework.Memory;
var agent = new ChatAgent(builder => {
builder.WithModel("gpt-4o")
.WithMemory(new ConversationMemory(maxTurns: 30))
.WithPlugin(new SummarizationPlugin()); // 手动添加摘要插件
});
// 问题:ConversationMemory只是简单的消息列表
// 超过maxTurns会硬截断,没有摘要/压缩
// 必须手动实现SummarizationPlugin:
public class SummarizationPlugin {
[KernelFunction]
public async Task<string> CompressContext(
IList<ChatMessage> history,
int targetTokens)
{
// 开发者需要自己写这段代码
var important = history.Take(3) // 保留系统提示
.Concat(history.TakeLast(10)); // 保留最近5轮
var toCompress = history.Skip(3).SkipLast(10);
var summary = await llm.SummarizeAsync(toCompress);
return summary;
}
}
实测数据:在跨语言Agent场景(C#后端 + Python数据分析Agent)中,Microsoft AF的消息传递正确率为91%,但上下文管理完全依赖开发者自行实现。框架提供的ConversationMemory只是消息列表的薄封装,超过限制直接截断,信息丢失率高达48%。
变现评估:Microsoft AF的唯一优势是.NET企业生态——大量企业已有Semantic Kernel投资。但上下文管理的缺失意味着需要在框架之上构建完整的压缩层。适合做成".NET企业Agent上下文中间件"产品。
graph TB
subgraph "上下文工程三层架构"
direction TB
subgraph "Layer 1: 输入控制"
A1[系统提示词精简]
A2[工具Schema裁剪]
A3[Few-shot示例动态选择]
end
subgraph "Layer 2: 运行时压缩"
B1[工具结果落盘]
B2[对话摘要蒸馏]
B3[Token预算路由]
end
subgraph "Layer 3: 持久化恢复"
C1[向量化长期记忆]
C2[结构化知识图谱]
C3[关键上下文重注入]
end
end
LLM[LLM推理引擎<br/>有限上下文窗口]
A1 & A2 & A3 --> B1 & B2 & B3
B1 & B2 & B3 --> LLM
LLM --> C1 & C2 & C3
C1 & C2 & C3 -.->|下一轮恢复| A1 & A2 & A3
style LLM fill:#845ef7,color:#fff
style B2 fill:#ff922b,color:#fff
我们在统一测试场景(50轮数据分析任务,每轮产生约2000 Token的工具输出)中对比了六栈在上下文窗口逼近极限时的行为:
| 指标 | LangGraph | CrewAI | OpenAI SDK | Claude SDK | Google ADK | MS AF |
|---|---|---|---|---|---|---|
| 溢出前自动触发 | ✅ Token阈值 | ❌ | ⚠️ 轮数阈值 | ✅ 多级阈值 | ✅ KV-cache | ❌ |
| 溢出时行为 | 自动压缩+继续 | 崩溃/报错 | 静默截断 | 五层级联 | Pruning+继续 | 静默截断 |
| 首次溢出轮数 | 从不溢出 | 12-15轮 | 25-30轮 | 从不溢出 | 从不溢出 | 18-22轮 |
| 50轮成功率 | 94% | 23% | 67% | 96% | 82% | 45% |
| 信息保真度 | 87% | N/A | 61% | 92% | 74% | 52% |
| 额外Token成本 | +15% | 0% | +3% | +18% | +8% | 0% |
| 实现复杂度 | 中(30行配置) | 高(80行自定义) | 中(40行自定义) | 低(5行配置) | 低(20行配置) | 高(100行自定义) |
关键发现:Claude Agent SDK的成功率最高(96%)但成本也最高(+18%),因为五层级联中每次压缩都调用LLM。LangGraph在成本效益上最优,94%成功率仅增加15%成本。Google ADK的KV-cache pruning是零额外LLM调用的方案,但保真度牺牲较大。
graph TD
Q1{任务平均轮数?}
Q1 -->|<10轮| Q2{语言偏好?}
Q1 -->|10-30轮| Q3{成本敏感度?}
Q1 -->|>30轮| Q4{模型绑定可接受?}
Q2 -->|Python| OPENAI[OpenAI Agents SDK<br/>快速MVP 无需压缩]
Q2 -->|.NET| MS[Microsoft AF<br/>企业.NET生态]
Q2 -->|TypeScript| MASTRA[Mastra<br/>TS原生框架]
Q3 -->|成本优先| LANG[LangGraph<br/>最佳性价比压缩]
Q3 -->|保真优先| CLAUDE[Claude Agent SDK<br/>最高保真压缩]
Q3 -->|GCP用户| GOOGLE[Google ADK<br/>KV-cache pruning]
Q4 -->|可绑定Claude| CLAUDE2[Claude Agent SDK<br/>五层级联开箱即用]
Q4 -->|必须开源/自托管| LANG2[LangGraph + LangMem<br/>三级管线自定义]
Q4 -->|超长文档2M+| GOOGLE2[Google ADK + Gemini<br/>2M窗口免压缩]
style CLAUDE fill:#ff922b,color:#fff
style CLAUDE2 fill:#ff922b,color:#fff
style LANG fill:#51cf66,color:#fff
style LANG2 fill:#51cf66,color:#fff
在六栈实测中,我们反复观察到以下五种上下文管理反模式,任何框架都无法自动规避:
反模式一:全量工具结果保留。开发者让Agent调用API后将完整JSON响应保留在上下文中。一个curl返回的5KB JSON在三轮后占用15K Token。正确做法:工具返回后立即提取关键字段,丢弃原始响应。Claude SDK的Layer 1自动处理此问题,其余框架需手动实现。
反模式二:系统提示词膨胀。将所有可能用到的规则一次性塞入系统提示词,导致基础Token消耗就占去窗口的30%-40%。正确做法:系统提示词只保留核心指令,具体规则通过动态注入Few-shot示例按需加载。
反模式三:无视Token预算。不监控每轮的Token消耗,直到溢出才处理。正确做法:在每轮Agent循环开始时检查剩余预算,提前触发压缩而非等到溢出。LangGraph的should_compress条件路由是最佳实践。
反模式四:压缩等于摘要。将上下文压缩简单理解为"用LLM总结之前的对话"。实际上高质量的压缩需要分层处理:工具结果需要提取(非摘要),对话需要结构化蒸馏(保留决策/发现/错误/待办),系统提示词需要精简(非摘要)。Claude SDK的四类关键信息分类是目前最精准的方法论。
反模式五:记忆与上下文混淆。把长期记忆(跨Session的知识积累)和短期上下文(当前Session的对话窗口管理)混为一谈。正确做法:长期记忆用向量数据库+结构化存储(CrewAI的Entity Memory方向正确),短期上下文用压缩+截断+预算管理。
场景一:长任务代码Agent(30+轮) 推荐 Claude Agent SDK。五层级联开箱即用,92%信息保真度,且Claude的代码理解能力与上下文压缩形成正反馈——压缩时能准确识别代码关键语义。代价是锁定Claude模型。
场景二:企业级通用Agent(多模型,10-30轮) 推荐 LangGraph + LangMem。StateGraph的Reducer机制提供最灵活的上下文控制,LangMem的托管记忆服务解决持久化问题。支持任意LLM后端,无模型锁定。需要约30行配置代码。
场景三:超长文档处理(200K+ Token输入) 推荐 Google ADK + Gemini 2.5 Pro。Gemini的2M Token窗口让大多数文档不需要压缩,ADK的session state处理结构化数据。避免在"可以不压缩"的场景中引入压缩的复杂性。
场景四:快速MVP/原型(<10轮) 推荐 OpenAI Agents SDK。不需要复杂上下文管理,Session的滑窗足够。快速上线优先,上下文工程等用户反馈后再加。OpenAI生态的工具链(Tracing、Guardrails)最成熟。
场景五:.NET企业系统集成
推荐 Microsoft Agent Framework + 自定义压缩中间件。虽然框架内置能力弱,但对已有Semantic Kernel投资的企业,迁移成本最低。建议在ConversationMemory之上封装一个CompressedConversationMemory类,实现Token预算感知的自动压缩。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
