上下文工程 (Context Engineering)

显示全部楼层

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0px 0.2em;color: rgb(255, 255, 255);background: rgb(15, 76, 129);">引言

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">著名AI专家 Andrej Karpathy 曾将大型语言模型（LLM）比作一种新型操作系统，其中LLM是CPU，而其上下文窗口（Context Window）则是RAM。正如操作系统需要精心管理内存（RAM）一样，我们在构建智能体时也必须高效地管理模型的“工作记忆”——上下文窗口。当智能体执行长时程、多步骤任务时，不断累积的指令、工具调用反馈和知识会迅速填满上下文窗口，导致成本飙升、延迟增加，甚至引发上下文中毒（Context Poisoning）、上下文分心（Context Distraction）等性能退化问题。“上下文工程”（Context Engineering）正是解决这一挑战的艺术与科学，它专注于在智能体运行的每一步，都为其上下文窗口精确填充“恰到好处”的信息。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0px 0.2em;color: rgb(255, 255, 255);background: rgb(15, 76, 129);">一、什么是上下文工程(Context Engineering)

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">DeepMind的工程师Philipp Schmid对上下文工程的理解如下：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">如图所示，他将系统提示词（System Prompt）、指令(Instruction)、长期记忆(LongTerm Memory)、可用工具（Tools）、用户提示词(User Prompt)以及召回信息(Retrieved Infomation)、历史对话等短时记忆（History）甚至是结构化的输出(Structured Output)统称为上下文。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">Chroma的首席执行官Hammad Bashir在他的一次演讲中，将上下文的定义总结为下图：

虽然和Philipp Schmid的图不完全一样，但是都大体的含义是一样的，即：上下文不止包括用户输入的单、多轮对话prompt与回答，也包括能够调用的工具、能够合作的智能体等“工具”，同时还包括“长期/短期记忆”、“环境状态”等抽象的概念。

二、上下文工程的三大发展阶段

1.提示工程（Prompt Engineering）随着聊天机器人的兴起，提示工程成为引导 LLM 行为的首要手段。
2.检索增强生成（RAG）为了让 LLM 连接外部数据源，RAG 作为第二阶段应运而生。
3.智能体与工具调用（Agent + Tool Calls）LLM 工具调用能力提升后，智能体（Agent）通过 LLM 与工具的反复交互，推动了上下文工程进入第三阶段。

三、上下文工程需要解决的问题

AI智能体的核心工作模式是在LLM调用和工具调用之间进行循环，利用工具的反馈来决定下一步行动。这个过程必定会产生大量的上下文信息。

随着任务的进行，来自工具调用的上下文会不断累积，这种会直接导致多种严重问题：

•超出上下文窗口限制：当Token数量超过模型上限时，程序会崩溃或丢失重要信息。
•成本与延迟激增：更多的Token意味着更高的API调用成本和更长的响应时间。
•性能下降：过长或混乱的上下文会严重影响模型的推理能力，具体表现为：

•上下文中毒 (Context Poisoning)：一个错误的幻觉信息进入上下文，并污染后续的推理过程。
•上下文分心 (Context Distraction)：海量信息淹没了模型的训练知识，使其偏离核心任务。
•上下文混淆 (Context Confusion)：无关的上下文信息对模型的响应产生了负面影响。
•上下文冲突 (Context Clash)：上下文中存在相互矛盾的信息，导致模型决策混乱。

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

针对目前的上下文问题，业界涌现出四大策略：写入（Write）、选择（Select）、压缩（Compress）和隔离（Isolate）。

策略一：写入上下文 (Write Context)

“写入”是指将信息保存到上下文窗口之外的存储中，以便将来使用。

便笺 (Scratchpads)

便笺是一种在单次任务会话中供智能体使用的“临时记事本”。它允许智能体在执行任务时记录中间思考、计划或重要发现，而无需将这些信息始终保留在上下文窗口中。

记忆 (Memories)

与便笺的“会话内”特性不同，记忆旨在实现跨会话的长期信息持久化。这使得智能体能够从过去的交互中学习和成长。如今，像 ChatGPT、Cursor 等主流产品都已经内置了基于用户交互自动生成和管理长期记忆的机制。

策略二：选择上下文 (Select Context)

“选择”是指在需要时，从外部存储中精准地拉取相关信息并注入到当前上下文窗口中。

从便笺和记忆中选择

选择机制与写入机制相对应。如果便笺是工具，智能体可以通过调用读取工具来获取信息。如果记忆存储在数据库中，就需要一套高效的检索机制。记忆可以分为不同类型，以服务于不同目的：

•情景记忆 (Episodic Memories)：如Few-shot示例，用于展示期望的行为模式。
•程序记忆 (Procedural Memories)：如操作指令，用于引导智能体的行为。
•语义记忆 (Semantic Memories)：如事实知识，为任务提供相关背景。

选择的要点在于确保相关性。简单的实现是始终加载固定的规则文件，如Claude Code使用的CLAUDE.md。而更复杂的系统（如ChatGPT）则使用嵌入（Embeddings）或知识图谱（Knowledge Graphs）来索引海量记忆，并进行语义检索。

选择工具和知识 (RAG)

当智能体拥有大量工具时，它可能会因为工具描述重叠而感到困惑。对工具描述应用RAG（检索增强生成）是一种有效的解决方案，它能根据当前任务动态选择最相关的工具，有研究表明这能将工具选择的准确率提高3倍。对于知识的检索，RAG同样至关重要。

策略三：压缩上下文 (Compress Context)

“压缩”是指在保留任务所需核心信息的前提下，尽可能减少上下文中的Token数量。

上下文总结 (Context Summarization)

这种方法通常使用一个LLM来提炼和浓缩信息。例如，当Claude Code的上下文窗口使用率超过95%时，它会自动触发“auto-compact”功能，对整个用户-智能体交互轨迹进行总结。总结可以应用于不同层面：对整个对话历史进行递归或分层总结，或在特定节点对高Token消耗的工具输出（如网页搜索结果）进行后处理。

上下文裁剪 (Context Trimming)

与使用LLM进行智能总结不同，裁剪通常依赖硬编码的启发式规则来过滤或“修剪”上下文。最常见的方法是简单地移除消息列表中最旧的消息。更高级的方法，如Provence，是训练一个专门用于问答场景的上下文修剪器。

策略四：隔离上下文 (Isolate Context)

“隔离”是指将上下文分解到不同的单元中，以降低单个上下文窗口的复杂性并实现关注点分离。

多智能体架构 (Multi-agent)

将一个复杂任务分解给多个专职子智能体是隔离上下文最流行的方式。每个子智能体都有自己独立的上下文窗口、指令集和工具集，可以并行处理不同子任务。Anthropic的多智能体研究系统证明，这种架构的性能远超单个大型智能体，因为每个子智能体的上下文窗口都可以更专注于一个狭窄的子任务。当然，其挑战在于更高的Token总消耗量和复杂的任务规划与协调。

使用环境隔离上下文 (Environments)

另一种隔离方法是使用沙箱环境。例如，HuggingFace的CodeAgent并不直接调用工具API，而是生成可执行代码。这些代码在一个隔离的沙箱中运行，只有必要的返回值才会被传回给LLM。这种方式非常适合处理和隔离高Token消耗的对象（如图片、音频文件），只需在沙箱中将其赋值给一个变量，即可在后续步骤中复用，而无需将庞大的数据本身放入LLM的上下文中。

利用状态对象隔离 (State)

一个精心设计的运行时状态对象（State Object）本身就是一种强大的隔离机制。通过定义一个包含多个字段的模式（Schema），我们可以将提供给LLM的消息（如messages字段）与其他仅供程序逻辑使用的信息（如工具调用的原始JSON输出）分离开来。这样，LLM只看到它需要看到的信息，而其他上下文则被安全地隔离在状态对象的其他字段中。