<!-- title: 窗满即废：六栈上下文工程深拆 -->

# 窗满即废：六栈上下文工程深拆

## 概述

2026 年，AI Agent 领域最锋利的分水岭不再是 Agent Loop、工具调用或多智能体拓扑——这些都被上一轮框架趋同战磨平了。真正的战场已经转移到一个被长期低估的维度：**上下文工程（Context Engineering）**。Karpathy 把它定义为"用恰好够用的信息填满上下文窗口的那门精细手艺"；Anthropic 把上下文拆成静态、动态、工具三类；LangChain 的《State of Agent Engineering》报告显示，**超过 60% 的生产级 Agent 故障可追溯到上下文问题**，而企业侧的数据是 65% 的 Agent 失败死于"上下文漂移"。

本文以**上下文工程的四原语——压缩（Summarize）、卸载（Offload）、隔离（Isolate）、缓存（Cache）**为标尺，横向拆解六栈框架：LangGraph、CrewAI、Microsoft Agent Framework（AutoGen 继任者）、OpenAI Agents SDK、Claude Agent SDK（Anthropic 派）、Letta（虚拟上下文派）。核心结论先行：**把上下文当成一等公民、暴露为可编程原语的栈（LangGraph、Claude SDK、Letta）正在赢；把上下文塞进黑盒"记忆"或薄薄一层 handoff 的栈（CrewAI、OpenAI SDK）正在漏成本。** 多智能体的代价比单 Agent 高达 15 倍 token，谁不会工程化窗口，谁就替对手烧钱。

## 六栈上下文工程能力横评

| 框架 | 版本/状态 | 上下文定位 | 压缩(Summarize) | 卸载(Offload) | 隔离(Isolate) | 缓存(Cache) | 上手难度 |
|------|-----------|------------|-----------------|---------------|---------------|-------------|----------|
| LangGraph | 1.0 GA | 状态图的状态字段 | Checkpoint+压缩节点原生 | Subgraph/节点即子Agent | 独立 thread 状态天然隔离 | 与模型层 prompt cache 叠加 | 中高 |
| CrewAI | v1.15+ | 黑盒"记忆"模块 | 任务后写 embedding | 无原生子Agent卸载 | 共享 crew 上下文，易串味 | 弱（黑盒难控） | 低 |
| Microsoft Agent Framework | 1.0 GA（取代 AutoGen+SK） | 历史消息流 | 内置历史压缩/裁剪 | AssistantAgent 隔离 | 会话级隔离 | 依赖底层 client | 中 |
| OpenAI Agents SDK | 稳定 | handoff 为切换原语 | 薄，靠开发者自行截断 | handoff 转移控制权 | handoff 边界即隔离边界 | Responses API 自动缓存 | 低 |
| Claude Agent SDK | 活跃 | 一等公民原语最全 | auto-compaction 自动压缩 | subagent 工具+文件系统 | 子进程独立上下文 | prompt cache 命中率最高 | 中 |
| Letta | 开源 Agent Server | 虚拟上下文（无限窗口） | 分层记忆自动晋升/降级 | memory block 独立读写 | block 间硬隔离 | memory block 跨轮缓存 | 中高 |

## 深度分析

### 一、LangGraph：把上下文降维成"状态字段"，工程化程度最高

LangGraph 在 2026 年初与 LangChain 一起冲过 1.0 GA 门槛，其上下文哲学非常工程派：**上下文不是文本，而是状态图里的一个可读写字段（`State`）**。每个节点函数接收 `state`、返回增量更新，框架用 reducer 合并。这意味着压缩、卸载、隔离不再是魔法，而是你能 `print(state)` 出来看、能用条件边触发的普通代码。

```python
from typing_extensions import TypedDict
from langgraph.graph import StateGraph

class AgentState(TypedDict):
    messages: list          # 完整历史
    summary: str            # 压缩后的滚动摘要
    artifacts: dict         # 卸载出去的中间产物

def maybe_compress(state: AgentState) -> AgentState:
    # 消息超过阈值，触发摘要节点（Offload + Summarize）
    if len(state["messages"]) > 40:
        return {"summary": summarize(state["messages"]), "messages": state["messages"][-6:]}
    return {}
```

**优点**：上下文完全可观测、可回放（Checkpoint）；subgraph 天然实现上下文隔离，父图只接收子图的返回值而非其全部历史；与 Anthropic/OpenAI 的 prompt cache 叠加后，长跑 Agent 的边际成本最低。**缺点**：心智负担重，"写状态图"比"写 prompt"门槛高，原型阶段略重。**变现/训练营评估**：极适合做"生产级 Agent 工程"训练营——可观测、可断点续传、可压测，是唯一能把上下文当成代码评审对象讲清楚的栈。

### 二、CrewAI：黑盒"记忆"是甜蜜陷阱，上下文不可见即不可控

CrewAI 的卖点是"角色扮演的多智能体小队"，开箱即用、上手最快。但它的上下文处理恰恰是最被诟病的一环：上下文被封装进一个叫 `Memory` 的黑盒模块。默认情况下，每完成一个 task，CrewAI 就用 OpenAI 的 `text-embedding-3-large` 把结果写进向量库，下一轮再"召回"塞回上下文——**但召回什么、塞多少、何时塞，开发者基本看不见**。

```python
from crewai import Agent, Crew, Process
agent = Agent(role="研究员", backstory="...", llm="gpt-4o")
crew = Crew(agents=[agent], tasks=[...], memory=True)  # memory=True 开启黑盒
```

**优点**：零配置，原型阶段省心；适合 demo 和"看起来很智能"的场景。**缺点**：上下文漂移失控——一条被错误召回的旧记忆会把整个 crew 带偏，而你很难定位是哪一条；crew 内部共享上下文导致"角色串味"（A agent 看到了 B agent 的私密推理）；token 消耗不可预测，15× 的多智能体税在这里体现得最狠。**变现评估**：适合做"48 小时搭一个多智能体 demo"的低端训练营，不适合讲生产工程——因为讲不出上下文是怎么流动的。

### 三、Microsoft Agent Framework：AutoGen 的"收编"，靠历史压缩续命

2026 年微软做了一个战略级动作：把 AutoGen 和 Semantic Kernel 收编进统一的 **Microsoft Agent Framework 1.0**，原生支持 Responses API、MCP、托管 Agent。它的上下文工程落在"历史消息流"这一层——内置了历史压缩与裁剪策略，AssistantAgent 之间通过会话级隔离避免互相污染。

```python
from agent_framework import AssistantAgent
# 历史超过窗口时，框架自动触发 summarize，保留近 N 轮
agent = AssistantAgent(name="analyst", 
    instructions="...", 
    # 框架托管消息历史与压缩策略
)
```

**优点**：企业级底子最厚，多语言（C#/Python）、与 Azure 生态深度绑定；AutoGen 时代积累的群聊（GroupChat）编排能力保留了下来。**缺点**：上下文策略偏"消息层裁剪"而非"语义层卸载"，对长任务的结构化产物管理弱；AutoGen→MAF 的迁移让老用户有迁移税。**变现评估**：面向 .NET / Azure 企业客户的最佳标的，"微软全家桶里做 Agent"是清晰的差异化卖点。

### 四、OpenAI Agents SDK：handoff 是上下文切换原语，但薄得像纸

OpenAI Agents SDK 走极简路线，它对上下文工程的回答就一个词：**handoff**。一个 Agent 把控制权 handoff 给另一个 Agent 时，前者把"必要的上下文"（通常就是一个简短交接说明）传给后者，而不是把整段历史搬过去。这本质上是一种**以组织结构换上下文隔离**的思路——不同专家只看到自己该看的。

```python
from agents import Agent, Runner
triager = Agent(name="分诊", handoffs=[billing, support])
billing  = Agent(name="计费专家", tools=[lookup_invoice])
# handoff 时只传递交接上下文，而非 triager 的全部历史
```

**优点**：模型与 SDK 同源，Responses API 的自动缓存让 prompt cache 命中率天然高；心智模型极简，10 分钟出第一个 Agent。**缺点**：上下文工程几乎全靠开发者自觉——你想截断历史？自己写；想压缩？自己写；SDK 不提供 subagent 工具这种"框架级卸载"。**变现评估**：适合"OpenAI only"客户的快速交付，但一旦需要复杂长任务、需要精细窗口管理，就会撞墙，必须上 LangGraph 或 Letta 补位。

### 五、Claude Agent SDK：上下文原语最全，子进程隔离是真功夫

Anthropic 凭自家 claude-code 的实战经验，把上下文工程的四原语几乎全做成了框架级原语，Claude Agent SDK 是 2026 年上下文工程"原语完整度"的标杆。三个杀手锏：**subagent 工具**（把一个嘈杂的子任务，比如文件搜索、代码审查，整体卸载给子进程，子进程跑完只返回结论，污染不回流主上下文）、**文件系统即记忆**（把中间产物落盘，需要时再读，上下文窗口里只留指针）、**auto-compaction**（窗口接近满时自动压缩历史）。

```typescript
// 主 Agent 把"搜索整个仓库找用到 X 的地方"整体卸载给 subagent
// subagent 读了几十个文件，但只返回 5 行结论给主 Agent
const result = await task("找出所有调用 paymentService 的位置", { description: "..." });
// 主上下文只增加 5 行，而非 50 个文件的内容
```

**优点**：四原语齐备且开箱即用；prompt cache 设计精良，长会话成本可控；上下文漂移风险最低。**缺点**：绑定 Anthropic 模型生态；文件系统记忆要求你有持久化运行环境（不适合纯 serverless 无状态部署）。**变现评估**：做"严肃长任务 Agent"（代码库改造、长文档研究）的首选，训练营卖点可以是"上下文不漂移的 Agent"。

### 六、Letta：把上下文当数据库管，"虚拟无限窗口"的异类

Letta（前 MemGPT 团队）走了一条最激进的路线：**操作系统级上下文管理**。它把上下文窗口抽象成一个有"主存（上下文窗口）"和"外存（向量库）"的虚拟内存系统，memory block 自动在两者间晋升/降级——常用块进窗口，冷块落外存。开发者读写的是 block，框架替你管分页。

```python
# Letta 的上下文是命名 block，框架自动做"内存分页"
agent = client.create_agent(
    name="long_runner",
    memory_blocks=[
        {"label": "human", "value": "用户偏好..."},   # 始终在窗口
        {"label": "persona", "value": "..."},
    ],
    # 框架自动管理：窗口满时把低优先级 block 换出到外存
)
```

**优点**：唯一能撑住"超长任务"（数小时、数百轮）而不漂移的开源栈；上下文是显式 block，可观测、可外部编辑；block 跨轮缓存，长跑成本摊薄。**缺点**：心智模型最重，要学"内存管理"；上手门槛高；社区规模小于 LangGraph。**变现评估**：垂直场景杀手——客服长会话、个人助理、需要"记住一切"的场景，是少数能讲"上下文永不满"故事的栈。

### 七、四原语横评：谁的四件套最齐，谁就能上生产

把六栈压到四原语上看，差距一目了然。**压缩**：Claude SDK（auto-compaction 自动）、MAF（历史裁剪）、Letta（block 降级）三栈原生；LangGraph 需手写节点；CrewAI/OpenAI SDK 基本没有。**卸载**：Claude SDK（subagent 工具）和 LangGraph（subgraph）最强，把噪音整体搬出主窗口；Letta 用外存 block 实现；其余靠开发者硬扛。**隔离**：LangGraph（thread 状态）和 Claude SDK（子进程）最干净，handoff 派（OpenAI SDK）次之，CrewAI 的共享 crew 上下文最易串味。**缓存**：Claude SDK 和 OpenAI SDK 因模型同源占优；Letta 的 block 缓存独树一帜；LangGraph 靠与底层模型 cache 叠加。

**一句话判词**：**四原语齐备 = 能上生产；只齐一两件 = 只能做原型。** 这是 2026 年选型最硬的过滤条件，比比 Star 数、比比 demo 效果都可靠。

## 上下文工程四原语工作流

```mermaid
flowchart TD
    U[用户输入/任务] --> M[主 Agent 上下文窗口<br/>有限预算]
    M -->|窗口接近上限| S[压缩 Summarize<br/>Claude auto-compaction / Letta 降级 / LangGraph 摘要节点]
    M -->|噪音子任务| O[卸载 Offload<br/>Claude subagent 工具 / LangGraph subgraph<br/>只回传结论，不回传过程]
    M -->|多专家并行| I[隔离 Isolate<br/>独立 thread / 子进程 / handoff 边界]
    O --> R[结论回填主窗口<br/>仅指针/摘要]
    S --> R
    I --> R
    R --> M
    M -->|稳定前缀| C[缓存 Cache<br/>prompt cache / Responses 自动缓存<br/>block 跨轮缓存]
    C -->|命中| M
    style M fill:#ffe4b5,stroke:#333,stroke-width:2px
    style O fill:#cfe,stroke:#333
    style S fill:#fcd,stroke:#333
```

图中四条回流路径就是上下文工程的生命线：**任意一条断掉，窗口就会被噪音填满，Agent 表现断崖式下跌——这就是"窗满即废"**。LangGraph 和 Claude SDK 四条线全通；CrewAI 只有缓存一条勉强能控；OpenAI SDK 靠隔离（handoff）撑场面。选框架，本质是选这四条线的连通度。

## 推荐方案

**场景一：严肃长任务（代码库改造、深度研究、长会话助理）**
→ 首选 **Claude Agent SDK**（原语最全、漂移最低），次选 **Letta**（需要无限记忆的开源栈）。这条线上"上下文漂移"是头号杀手，必须选四原语齐备的栈。

**场景二：复杂工作流、需要可观测与断点续传的生产系统**
→ 首选 **LangGraph 1.0**。上下文是状态字段、可 Checkpoint、可回放，是唯一能做"上下文代码评审"的栈。变现上最适合做生产级 Agent 工程训练营。

**场景三：.NET / Azure 企业客户**
→ **Microsoft Agent Framework 1.0**。AutoGen+SK 收编后是企业全家桶里最顺的选型，历史压缩够用，迁移税一次性付清。

**场景四：48 小时 demo / 低端训练营 / OpenAI only 客户**
→ **OpenAI Agents SDK** 或 **CrewAI**。但要清醒：它们是原型利器、生产短板，一旦任务变长、上下文变脏，必须叠加 LangGraph/Claude SDK 补窗口管理。

**给所有团队的硬建议**：无论选哪栈，把"上下文预算"写进需求文档——规定每轮主窗口 token 上限、规定哪些子任务必须卸载、规定压缩触发阈值。**在 2026 年，不会工程化窗口的 Agent，就是替对手烧钱的自主体。**

## 参考来源

1. [Effective context engineering for AI agents — Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — 把上下文拆成静态/动态/工具三类的权威定义，本文四原语中"卸载/隔离"的理论源头。
2. [Context Engineering for Agents — LangChain](https://www.langchain.com/blog/context-engineering-for-agents) — Karpathy 定义"用恰好够用的信息填满窗口"的出处，及 LangGraph 1.0 与上下文工程的结合。
3. [Context Engineering for AI Agents: Offload, Summarize, Isolate, and Cache — langcopilot](https://langcopilot.com/posts/2026-03-23-context-engineering-ai-agents-offload-summarize-isolate-cache) — 压缩/卸载/隔离/缓存四原语的系统化梳理，本文横评标尺的直接来源。
4. [Microsoft Agent Framework 2026: AutoGen Successor Explained](https://baeseokjae.github.io/posts/microsoft-agent-framework-2026/) — AutoGen+Semantic Kernel 收编进 MAF 1.0、原生 Responses API 与 MCP 的细节。
5. [Agent Context Window Engineering 2026 — agentmarketcap](https://agentmarketcap.ai/blog/2026/04/09/agent-context-window-engineering-2026) — Letta 虚拟上下文管理、block 分页机制的实测，及长跑 Agent 成本对比。

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)