上下文工程 Context Engineering

030 秒速览

一句话:上下文工程 = 在 Agent 运行的每一步,决定"把哪些信息、以什么结构、在什么时候"放进模型的上下文窗口。

大语言模型的上下文窗口,就像电脑的内存(RAM):容量有限,而且塞得越满、越乱,处理质量反而越差。Agent 要跑几十上百轮、不断吞入工具返回的结果,很容易把这块"内存"塞爆或塞脏。上下文工程就是那套"内存管理"手艺——把信息写出去存好、需要时选回来、太长了压缩、不相干的隔开。

1为什么需要它:痛点先行

先设身处地想一个场景:你让一个 Agent 帮你做调研。它调用搜索工具、读网页、调数据库、再搜、再读……跑了几十轮。每一次工具返回的内容都会被追加进上下文里。跑到后面,上下文窗口里堆满了几十次工具调用的原始输出——又长又杂。

结果就出问题了。Drew Breunig 和 LangChain 团队总结了长上下文常见的三类恶果:要么直接超出上下文窗口塞不下;要么 token 暴涨、成本和延迟飙升;要么——最隐蔽的——模型性能反而下降,该记住的没记住,被无关内容带偏了。(来源:LangChain、dbreunig)

换句话说:当模型能力已经足够强,制约 Agent 表现的瓶颈,常常不在模型本身,而在"我们喂给它的上下文对不对"。这就是上下文工程作为一门独立学科出现的根本原因。

2它到底是什么

"上下文"不止是你写的那段提示词。LangChain 把它归纳为一把"伞",覆盖三类信息:

3上下文为何会崩:四种失败模式

要理解四大策略在"治什么病",得先认识"病症"。Drew Breunig 总结了长上下文出问题的四种典型方式,已被 LangChain、Anthropic 等广泛引用。(来源:dbreunig、LangChain)

4四大策略:写 / 选 / 压 / 隔

LangChain 团队(Lance Martin)把业界常见做法归纳成四个桶——写(Write)、选(Select)、压(Compress)、隔(Isolate)。这套分类现在几乎是讨论上下文工程的通用语言。下面逐个用大白话讲透。(来源:LangChain、Atlan)

① 写 Write — 把信息存到窗口外面

"写"就是把有用的信息保存到上下文窗口之外,需要时再拿。就像人做复杂任务时会在草稿纸上记笔记。两种典型:

• 草稿本 Scratchpad(单次任务内): Agent 把中间信息写到一个文件或运行时状态对象里。Anthropic 的多 Agent 研究系统就是例子——主研究员一开始就把计划"写进 Memory",因为一旦上下文超过 20 万 token 会被截断,必须先把计划保住。(来源:Anthropic,经 LangChain 引用)
• 长期记忆 Memory(跨多次会话): 像 ChatGPT、Cursor、Windsurf 都能自动生成跨会话的长期记忆。学术上,Reflexion 提出每轮后"反思"并复用自生成的记忆。

② 选 Select — 需要时把对的信息拉进来

"选"就是在每一步,只把当下相关的信息拉进上下文窗口。存了不等于会用,关键是"选得准"。它作用在几类对象上:

• 记忆的选取: 挑相关的 few-shot 示例(情景记忆)、指令(程序性记忆)或事实(语义记忆)。很多代码 Agent 用固定文件常驻上下文,比如 Claude Code 的 CLAUDE.md、Cursor/Windsurf 的 rules 文件。
• 工具的选取: 工具太多会让模型"挑花眼"(描述重叠导致选错)。对工具描述做 RAG、只拉最相关的几个工具,有论文显示能把工具选择准确率提升约 3 倍。
• 知识的选取(RAG): 代码 Agent 是大规模 RAG 的最佳实战场——Windsurf 指出,代码库一大,单纯 embedding 检索就不可靠,得组合 grep/文件搜索、知识图谱检索,再加一步重排序(re-ranking)。

③ 压 Compress — 只留完成任务必需的 token

"压"就是把上下文缩短,只保留任务真正需要的那部分 token。两种手法:

• 摘要 Summarization: 用 LLM 把长轨迹提炼成短摘要。用过 Claude Code 就见过——超过窗口 95% 时它会自动 "auto-compact",把整段交互历史压缩。也可在特定位置压,比如对 token 很重的搜索工具输出做后处理,或在"Agent 与 Agent 交接"时压缩以减少交接 token(Cognition 甚至专门微调了一个模型来做这步)。
• 修剪 Trimming: 不用模型,直接按规则"剪枝"——比如删掉过老的消息。Drew Breunig 还提到 Provence,一个为问答训练的上下文剪枝器。

④ 隔 Isolate — 把不相干的上下文分开放

"隔"就是把上下文拆开,不让互不相关的部分互相干扰。三种做法:

• 多 Agent: 最流行的隔离方式——把上下文拆给多个子 Agent,每个有自己的工具、指令和独立的上下文窗口,各管一块窄任务。
• 用环境/沙箱隔离: HuggingFace 的 deep researcher 用 CodeAgent——模型输出的是代码,在沙箱里运行,只把需要的返回值传回给 LLM。特别适合把"token 很重的对象"(图片、音频)留在环境里,用变量引用,不塞进上下文。
• 用状态对象隔离: 给 Agent 设计一个带 schema 的运行时 state,把工具结果写进某些字段,先不暴露给 LLM,等真正需要时再取。

5怎么落地(以 LangGraph 为例)

策略讲完,落到工程上怎么做?LangChain 把 LangGraph 设计成对这四招都友好。注意:下面是官方博客给出的落地思路,不是可直接复制运行的完整代码,具体 API 请以 LangGraph 最新文档 为准(该框架迭代很快)。(来源:LangChain)

一个"写→选"的最小心智模型,伪代码示意(思路来自官方描述,非官方原样代码):

// 一个 LangGraph 节点里的思路
node("research", (state) => {
  // 选:只取这一步需要的字段,而不是把整个 state 丢给模型
  const ctx = pick(state, ["plan", "recent_findings"]);
  const out = llm(ctx, tools);
  // 写:把重要中间结果写回 state 的独立字段(隔离),不立刻塞进 messages
  return { scratchpad: out.notes, messages: out.answer };
});

6真实场景与案例

生产侧的落地样本也在增多:例如 Lyft 用 LangGraph + LangSmith 搭了自助式客服 AI Agent 平台(2026-05 案例),背后同样离不开对上下文与轨迹的追踪与评测。(来源:LangChain 案例)

7和 Prompt 工程、RAG 的关系

很多人会问:这跟提示词工程、跟 RAG 有啥不一样?一句话:上下文工程是更大的伞,Prompt 工程和 RAG 都是它的子集或组成部分。

8常见坑与限制

9学习资源

• LangChain《Context Engineering》(核心必读): langchain.com/blog/context-engineering-for-agents — 四大策略 + LangGraph 落地,本文主干来源。
• Drew Breunig《How Long Contexts Fail》/《How to Fix Your Context》: 失败四模式 / 修复方法。
• Anthropic 多 Agent 研究系统工程博客: anthropic.com/engineering/built-multi-agent-research-system — 写/隔离策略的一手案例。
• Simon Willison《How to Fix Your Context》: simonwillison.net。
• 综述/指南(社区): ivern.ai 2026 完整指南、Atlan 四策略、Firecrawl:上下文工程 vs 提示词工程。
• 学术: Context Engineering: From Prompts to Corporate Multi-Agent Architecture、Establishing Best Practices for Building Rigorous Agentic Benchmarks。

来源清单

1. LangChain,《Context Engineering》(核心来源,已 fetch 全文),2025-07-02 发布 — https://www.langchain.com/blog/context-engineering-for-agents
2. Drew Breunig,《How Long Contexts Fail》,2025-06-22 — https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
3. Drew Breunig,《How to Fix Your Context》,2025-06-26 — https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html
4. Anthropic Engineering,多 Agent 研究系统 — https://www.anthropic.com/engineering/built-multi-agent-research-system
5. Atlan,《Write, Select, Compress, Isolate》 — https://atlan.com/know/four-context-engineering-strategies/
6. ivern.ai,《AI Agent Context Engineering: Complete Guide (2026)》 — https://ivern.ai/blog/ai-agent-context-engineering-complete-guide-2026
7. arXiv 2603.09619,《Context Engineering: From Prompts to Corporate Multi-Agent Architecture》 — https://arxiv.org/abs/2603.09619
8. arXiv 2507.02825,《Establishing Best Practices for Building Rigorous Agentic Benchmarks》 — https://arxiv.org/pdf/2507.02825
9. Firecrawl,《Context Engineering vs Prompt Engineering》 — https://www.firecrawl.dev/blog/context-engineering
10. Simon Willison,《How to Fix Your Context》,2025-06-29 — https://simonwillison.net/2025/Jun/29/how-to-fix-your-context/
11. LangChain 案例,Lyft 自助客服 AI Agent 平台,2026-05 — https://www.langchain.com/blog/lyft-built-a-self-serve-ai-agent-platform-for-customer-support-with-langgraph-and-langsmith