上下文工程（Context Engineering）

本文整理自 LangChain 博客《Context Engineering for Agents》」更自然 blog.langchain.com/context-eng…

随着大语言模型（LLM）在智能体（Agent）系统中的广泛应用，如何有效管理有限的上下文窗口（Context Window）成为关键挑战。

1. 为什么需要上下文工程？

大语言模型的上下文窗口类似于计算机的 RAM——它是模型的“工作记忆”，但容量有限。当智能体执行长期任务时，会不断累积以下类型的上下文：
● 指令（Instructions）：提示词、记忆、少样本示例、工具描述等
● 知识（Knowledge）：事实、用户偏好、历史信息等
● 工具反馈（Tools）：API 调用结果、代码执行输出等

长期执行的任务和工具调用反馈的积累意味着智能体通常会使用大量令牌。这可能引发多种问题：可能超过上下文窗口大小、导致成本或延迟急剧上升，或降低智能体性能。

随着交互轮次增加，上下文迅速膨胀，可能引发以下问题：

问题类型	描述
上下文中毒（Context Poisoning）	幻觉内容被写入上下文，污染后续推理
上下文干扰（Context Distraction）	过多无关信息压倒模型对核心任务的关注
上下文混淆（Context Confusion）	冗余或矛盾信息导致输出不一致
上下文冲突（Context Clash）	上下文中存在相互矛盾的事实或指令

上下文工程已成为构建可靠、高效智能体的首要任务.

2. 上下文工程的四大核心策略

为应对上述挑战，业界普遍采用以下四类策略：

写入上下文（Write）
选择上下文（Select）
压缩上下文（Compress）
隔离上下文（Isolate）

2.1 写入上下文（Write）

将重要信息保存到上下文窗口之外，供后续使用。

Scratchpad（草稿板） ：在单次会话中临时存储计划、中间结论等。例如 Anthropic 的多智能体研究系统中，主研究员会将研究计划写入 Memory，防止因上下文截断而丢失。实现方式：通过工具调用写入文件，或存入运行时状态对象（State）。

长期记忆（Memories） ：跨会话持久化信息。

应用实例：ChatGPT、Cursor、Windsurf 均支持自动生成用户专属长期记忆。

2.2 选择上下文（Select）

动态检索最相关的信息注入当前上下文。

从 Scratchpad 选择：若以 State 存储，开发者可控制每步暴露哪些字段；若以工具实现，则通过读取工具调用获取。
记忆检索：
- 程序性记忆（Procedural）：如 CLAUDE.md、规则文件，用于指导行为。
- 情景性记忆（Episodic）：少样本示例。
- 语义性记忆（Semantic）：事实知识，通常通过向量嵌入或知识图谱进行检索。
工具选择：对大量工具使用 RAG 技术，仅检索与当前任务最相关的工具描述，可提升工具选择准确率。
知识检索（RAG） ：尤其在代码智能体中，需结合 AST 解析、文件搜索、知识图谱与重排序等多种技术，而非仅依赖向量搜索。

2.3. 压缩上下文（Compress）

保留完成任务所需的最少 token。

上下文摘要（Summarization） ：

在接近上下文上限时，对整个对话轨迹进行递归或分层摘要。
可在特定节点（如耗 token 的搜索工具后）插入摘要步骤。
复杂场景下甚至需微调专用摘要模型。

上下文修剪（Trimming/Pruning） ：

基于启发式规则（如删除最早消息）。
或使用训练好的上下文剪枝器。

2.4. 隔离上下文（Isolate）

将上下文拆分，避免相互干扰。

3. LangGraph：上下文工程的实践框架

LangGraph 作为底层智能体编排框架，原生支持上述所有策略：

上下文工程已从“技巧”演变为智能体开发的核心工程学科。面对有限的上下文窗口与复杂的任务需求，开发者必须像操作系统管理内存一样，精心调度每一条信息的“生命周期”——何时写入、如何选择、是否压缩、怎样隔离。

上下文工程不是 “越多信息越好”，也不是 “越少信息越省”，而是在每个任务步骤中，让 Agent 获得 “刚刚好” 的信息。

《上下文工程（Context Engineering）》是转载文章，点击查看原文。