Context Engineering 综述《Context Engineering 综述》围绕大模型 Agent 的上

1、上下文工程是什么

随着 Claude 、Cursor 、Manus等Agent产品的出现，标志着Agent 时代正式到来。其基于自主规划、工具调用、反思优化、长期记忆等环节，形成 "规划→执行→反思→优化" 的闭环 (Agent Loop)处理流程，让 LLM 从提示词工程 (Prompt Engineering) 阶段的静态指令进化到 "自主任务执行" 阶段。

从本质上讲，上下文（Context）是提供给 LLM 用于完成下一步推理或生成任务的全部信息集合，按照信息的来源及类型可以大致分为三类。

将上下文划分为三个核心类别：

指导性上下文（Guiding Context） ，这类上下文的核心功能是指导模型该做什么以及如何做，主要为模型行为设定框架，目标和规则。Prompt Engineering 一般旨在优化指导性上下文。它包括：System Prompt ；Task Description；Few-shot Examples；Output Schema（前面三个很简单，Output Schema 一般是强制要求模型以特定格式（如 JSON、XML）输出的结构定义）
信息性上下文（Informational Context） ，这类上下文的核心功能是告诉模型需要知道什么知识，为模型提供解决问题所必备的事实，数据与知识。它包括：RAG （外部知识库）；Memory（Short-term Memory：当前对话历史，Long-term Memory：跨会话存储的一些重要信息和偏好）；State / Scratchpad（状态维护和草稿纸，例如 Claude Code 在开始计划先的临时 TODO 以及 Thinking 模型下的思考“草稿本”）
行动性上下文（Actionable Context） ，这类上下文的核心功能是告诉模型能做什么以及做了之后的结果，为模型提供与外部世界交互的能力。它包括：Tool Definition；Tool Calls & Results / Tool Traces（调用了哪些工具以及工具返回的结果，即工具调用的历史追踪）

所以，上下文工程 既不是“高级的 提示工程 ”也不是“复杂的 RAG ”，它是设计和构建Agent动态系统的学科，目标是在正确时间以正确格式为 LLM 提供完成任务所需的全部信息和工具，以确保任务能够被可靠、高效地完成.

2、上下文工程为何重要

随着RAG、Memory以及MCP技术的不断涌现，Agent 需要处理的上下文越来越多，例如典型的 Manus 任务会调用 50 次工具，这些工具描述、调用结果以及大模型返回结果都会不断累积在 LLM 的上下文窗口中。虽然随着前沿大模型的不断发展，上下文窗口已经扩展到高达100W的Token，但是许多相关的研究表明，更长的上下文并不一定带来更好的性能，除了成本指数级的增长， LLM 的性能也会下降（耗时、准确性） 。

1.1、上下文污染（Context Poisoning）

上下文污染是指幻觉或其他错误信息进入上下文后，会影响大模型正确决策。

DeepMind 团队在 Gemini 2.5 技术报告中指出了“上下文污染”问题，在玩宝可梦游戏时，Gemini 智能体偶尔会出现幻觉，从而污染了其上下文，进而导致模型可能会执着于实现不可能或无关的目标。

在《精灵宝可梦红/蓝》中，玩家需要从自动售货机购买饮料（清水、汽水或柠檬水），然后交给一位口渴的守卫，守卫才会放行。但在《精灵宝可梦火红/叶绿》（游戏的重制版）中，玩家则需要给守卫一种特殊的茶，而这种茶在原版游戏中并不存在。Gemini 2.5 Pro 多次误以为必须找到茶才能继续游戏，结果花费了大量时间寻找茶或给守卫茶。

1.2、上下文干扰（Context Distraction ）

上下文干扰是指上下文长度达到一定程度，导致模型过度关注上下文，而忽略了训练期间学到的内容。

DeepMind 团队发现【17】，利用冗长的上下文信息来指导宝可梦的决策，会导致更差的结果，当上下文信息量显著超过 10 万个Token时，智能体倾向于重复其庞大历史记录中的行为，而不是合成新的策略。

Databrick 的一项报告指出【7】，大多数模型的准确性在达到一定上下文规模后就会下降。例如：Llama-3.1-405b 的性能在 16k 个Token后开始下降，GPT-4-turbo 的性能在 64k Token后开始下降，只有少数模型能够在所有数据集上保持稳定的模型性能。

1.3、上下文混淆（Context Confusion）

下文混淆是指上下文中存在与目标无关的冗余信息，导致模型出现幻觉进而生成低质量的响应。

伯克利函数调用排行榜的结果显示，当一次提供太多的工具描述时， **模型的性能都会下降。一些测试场景中提供的所有函数都无关紧要，预期模型的输出结果为不调用任何函数，但所有模型都会出现调用无关工具的情况。且模型参数越少问题越严重

论文【19】指出使用量化（压缩）的 Llama 3.1 8b 模型执行包含全部 46 种工具的查询时，即使上下文完全在 16k 的上下文窗口内，查询仍然失败。但当他们只给模型 19 种工具时，查询却成功了。

1.4、上下文冲突（Context Clash）

上下文冲突是指上下文中存在互相矛盾的信息时，比如上下文存在过去错误的答案，会导致模型困惑，进而给出错误的答案。

微软团队发现，如果将左侧提示中的所有信息拆分后在多轮聊天中依次给出，会导致模型结果急剧恶化，平均下降了 39%。该团队测试了一系列模型——OpenAI 备受赞誉的 o3 模型得分从 98.1 降至 64.1。

原因就在于上下文冲突，分片提示时上下文中包含了模型在掌握所有信息之前尝试回答的早期结果。这些错误答案会保留在上下文中，并在模型生成最终答案时对其产生影响

3、上下文工程行业实践

自2025年6月份 Context Engineering 这一概念正式被提出以来，上下文工程领域催生出大量专业化但相对分散的研究方向，截止目前还有没一个相对系统化的结论。

3.1、Context Engineering in Manus

3.1.1、核心主张

1、KV-cache命中率是生产阶段AI代理最重要的单一指标：得益于kv-cache技术的普及，具有相同前缀的上下文可以利用KV缓存，可以大大减少首个token的生成时间(TTFT)和推理成本。

2、可恢复的上下文压缩策略: 任何不可逆的压缩都带有风险，应保留详尽的原始上下文避免信息损失，例如，保留URL，移除网页内容；保留文档路径，省略文档内容。

3.1.2、核心举措：

(1)、上下文围绕 KV 缓存命中进行组织

保持提示前缀稳定
上下文只追加： 谨慎改写并确保序列化的确定性，许多编程语言和库在序列化JSON对象时不保证键顺序的稳定性，这可能会悄无声息地破坏缓存。
在需要时明确标记缓存 断点：某些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。
遮蔽而非移除工具描述： 除非绝对必要，避免在迭代过程中动态添加或移除工具。工具定义在序列化后位于上下文的前部，任何更改都会使后续所有动作和观察的KV 缓存失效。当先前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。
- 基于上下文感知的状态机管理工具可用性。不移除工具，而是在解码过程中掩蔽token的logits，以基于当前上下文阻止（或强制）选择某些动作。
- 响应预填充：允许在不修改工具定义的情况下约束动作空间，
  - <|im_start|>assistant
  - <|im_start|>assistant<tool_call>
  - <|im_start|>assistant<tool_call>{"name": "browser_

(2)、上下文精简与卸载

Manus 使用文件系统作为上下文系统，提供文件系统管理指令工具集，让模型具备自主访问、检索上下文的能力。

必要时进行总结：利用大模型对整个上下文轨迹进行摘要总结。
卸载过时内容：用引用（例如文件路径）替换较旧的工具结果，以便填充上下文，确保需要时可恢复。

(3)、语境隔离

使用子代理执行离散任务：将任务分配给具有各自上下文窗口的子代理，从而隔离上下文。（按任务分工而非角色分工）。
有意识地共享上下文：对于简单任务，仅传递指令；对于子代理需要更多上下文的复杂任务，则传递完整上下文（例如，轨迹和共享文件系统）。

(4)、其他措施

通过重复操控注意力： 在处理复杂任务时，Manus会创建一个todo.md文件，并在任务进行过程中逐步更新它。通过重复强调任务的目标，避免模型"迷失在中间"的问题，并减少了目标不一致。
保留错误的内容： 擦除失败会移除证据，导致模型重复失败的动作，改善代理行为最有效的方法之一是将错误的尝试保留在上下文中。
增加样本多样性： 在涉及重复决策或行动的任务（例如：使用Manus帮助审查20份简历时），模型将倾向于模仿上下文中的行为模式，可能会导致偏离、过度泛化，甚至产生幻觉。

3.1.3、局限与挑战

基于文件系统的上下文，在多Agent场景下，尤其是分布式的多Agent场景下的上下文共享存在挑战。
如何解决语义相关性上下文召回问题
过分强调上下文追加，如何在无关上下文导致的幻觉与提高缓存命中之间找到平衡。

3.2、Windsurf

Windsurf 是一款AI编程工具，通过深度集成 AI 技术提升开发者的编码效率。采用 AI Flow 范式，支持多步骤、多工具协同，自动维护上下文状态。

3.2.1、核心主张

从引擎设计的角度切入，先根据精心设计的语义边界，把代码拆分成独立的代码块，并为这些代码块生成向量嵌入（embedding），然后利用语义相似性向量搜索来完成检索。同时结合传统的 grep 搜索，构建知识图谱，最后将所有检索结果统一排序和整合，形成了一个典型的复杂、多步骤 RAG 流程。

3.2.2、核心举措

Windsurf 推出Fast Context子智能体专门用于代码上下文检索。该智能体基于SWE-grep模型使用一组受限且跨平台兼容的工具（grep、read、glob），以确保在不同操作系统与开发环境中的一致性能。

Windsurf 认为上下文检索非常适合由自定义子代理来完成 [8]。

它为主 智能体 节省了上下文预算（和智能）。既节省了智能体资源，又避免无关信息污染智能体的上下文，使主智能体保持专注。
检索是一项用途广泛、功能强大的能力。上下文检索子代理是智能模型和快速模型之间完美的“交接点”。
检索是一项可验证的任务。 为此，我们可以定义一个客观的真实数据集，从而计算出一个清晰确定的奖励，用于强化学习。

3.2.3、局限与挑战

1、针对代码这一特定场景，对上下文知识（代码）的拆分、组织和检索进行了比较重的设计，相对定制化，并不适用纯文本的上下文知识。

2、基于SWE-grep模型训练开发的上下文检索智能体，难以应对语义相关性的检索场景。

3.3、ACE(Agentic Context Engineering)

3.3.1、核心主张：

1、 更长的上下文 ≠ 更高的服务成本。 得益于kv-cache技术的普及，具有相同前缀的上下文可以利用KV缓存大大减少了首个token的生成时间(TTFT)和推理成本，例如使用GPT-5时，缓存的输入token成本为0.125美元/百万token，而未缓存的成本为1.25美元/百万token——相差10倍。

2、上下文不应是简短的摘要，而应成为信息丰富、全面、动态演化的「作战手册（playbooks）」。

传统上下文自适应方案（例如GEPA)，存在两大局限：

「简约偏置」（brevity bias）：过分追求简洁、普适的压缩指令，虽能在部分指标上奏效，却常无法捕捉智能体或知识密集型应用所需的细节策略。
「上下文塌缩」（context collapse）：依赖 LLM 对整体提示进行重写的方式，往往会随着时间推移退化为更短、更模糊的摘要，从而造成性能骤降。

3.3.2、核心措施：

(1)、外部记忆

基于动态速查表（Dynamic Cheatsheet）构建了一个外部记忆，用于积累推理过程中过去成功和失败的策略和经验教训。

(2)、结构化的分工：

执行流程分为三个角色：

生成器，负责生成推理轨迹；
反思器，负责从成功和失败中提炼具体见解；
整合器，负责将这些见解整合到结构化的情境更新中。

这模拟了人类的学习方式——实验、反思和整合——同时避免了将所有职责都交给单个模型所带来的瓶颈。

(3)、增量更新机制：

将上下文表示为一系列结构化的、条目式知识，而不是单一文本提示，类似于 LLM 记忆框架。

元数据：包括唯一标识符和计数器，用于跟踪提示被标记为有用或有害的次数；
结构化内容：用于总结可重用策略、领域概念或常见故障模式等小单元。在解决新问题时，生成器会突出显示哪些提示有用或具有误导性，并提供反馈以指导反射器提出修正更新。这种方式既避免了整体重写的高计算成本与延迟。
三个关键特性：（1）局部化，只更新相关条目；（2）细粒度检索，生成器专注于最相关的知识；（3）增量适应，允许在推理过程中进行高效的合并、修剪和去重。

(4)、增长和总结机制：

在稳定的上下文扩展和冗余控制之间取得平衡。

带有新标识符的知识条目会被追加，存量标识符的知识条目会直接更新（例如，元数据的递增计数器）。
去重会通过语义嵌入比较知识条目来去除冗余。支持主动执行（每次增量更新后）或延迟执行（仅在超出上下文窗口时执行）两种策略。

3.3.3、局限与挑战：

它依赖于一个相当强大的反思器：如果反思器无法从生成的轨迹或结果中提取准确的见解，构建的上下文可能会包含噪声甚至有害。
信息是否有益并非单一评价标准，其往往与当前任务相关，同一条上下文对于不同任务其是否有益的结果可能是相反的。是否使用 Q-C-quality 的三元组标记。

3.4、ReasoningBank（Google）

25年9月份Google 提出了一种用于智能体系统的新型记忆框架（ReasoningBank），用于解决大模型只能孤立地处理每个任务，无法从累积的交互历史中学习经验，而出现重复过去错误的情况。

3.4.1、核心主张

智能体必须从过往成功和失败的经验中提炼出可泛化的推理策略，才能不断进化，并指导其后续的行为。

3.4.2、核心举措

（1）、ReasoningBank 将过去经验中的有用策略和推理提炼成结构化的记忆项（每个记忆项包含标题、描述和内容）并存储起来以供将来重用

（2）、将ReasoningBank 与TTS 结合，提出MaTTS（Memory-aware Test-Time Scaling），提供并行扩展和顺序扩展两种模式。

Parallel Scaling：通过对比多条推理轨迹，促进多样化的探索，识别一致的推理模式，总结成记忆项。

Sequential Scaling：利于自我完善原则，将单条推理轨迹的中间结果也总结成记忆项。

（3）、采用 LLM 作为标注器（LLM-as-a-judge），根据查询和轨迹将结果标记为成功或失败，而无需人工标注。基于这些信号，我们应用不同的提取策略：成功的经验提供已验证的策略，而失败的经验则提供反事实信号和陷阱。

3.4.3、局限与挑战

MaTTS 虽然通过扩展多条推理轨迹对比的方式提高了模型性能，如何在性能和成本之间取得均衡？

4、Agent评估体系

上下文工程的评估目前暂未出现一个完备的评价体系及标准。我们姑且从端到端和组件维度的评价方法进行梳理。同时下面提到的评估方案，主要侧重于评估Agent的性能，推理成本、推理步数以及性能维度的评级指标需要自己开发。

4.1、端到端的评估

4.1.1、GAIA

GIAI: huggingface.co/datasets/ga…

GAIA 是一个用于评估AI助手在真实世界任务上的表现的基准，这些核心能力包括推理、多模态理解、网页浏览和熟练的工具使用。

此论文介绍了GAIA ” GAIA: A Benchmark for General AI Assistants ” 。

该基准包含466个精心策划的问题，这些问题对人类来说在概念上简单，但对当前的AI系统来说却极具挑战性。

为了说明差距：

人类：约92%的成功率
带有插件的GPT-4：约15%
深度研究（OpenAI）：在验证集上的得分为67.36%

GAIA任务被组织为三个递增复杂度的等级，每个等级测试特定技能：

一级：需要少于5个步骤和最少的工具使用。
二级：涉及更复杂的推理和多个工具之间的协调以及5-10个步骤。
三级：需要长期规划和各种工具的高级集成。

评测提交DEMO:huggingface.co/spaces/Zero…

4.1.2、AppWorld

github.com/stonybrookn…

项目分为两个主要部分：AppWorld Engine 和 AppWorld Benchmark。

AppWorld Engine

AppWorld Engine 是一个高质量的执行环境，包含了大约9个日常应用程序，并且通过457个API进行控制。其设计和实现遵循了软件工程的最佳实践，例如REST API设计原则和严格的单元测试。这个引擎的关键特点包括：

可控性：提供一个稳定且可重现的执行环境，让代理能够在没有现实后果的情况下操作这些应用程序（例如，避免垃圾邮件或者无谓的金钱损失）。
真实感：通过模拟与~100个虚构用户的数字生活和日常活动中的数据，建立了一个现实的数据环境。
API设计：提供近1500个参数的457个API，实现了对日常任务的复杂交互，如电子邮件发送、钱款转移、购物等。

AppWorld Benchmark

AppWorld Benchmark 提供了一套复杂的任务，目标是多样且具有挑战性的日常场景。这些任务的特点包括：

复杂性：每个任务涉及多个应用，并使用多个API，通常需要大约50行代码（最多可达134行），代理需要根据环境的反馈进行迭代改写代码。
评估套件：使用状态基础的单元测试进行评估，确保代理在完成任务时不会引发意想不到的变化（即“附带损害”）。
多样性：提供750个任务，通过对不同应用之间的交互进行细致设计，确保每个任务都具备不同的干扰因素和障碍。

4.1.3、AgentBoard

github.com/hkust-nlp/A…

主要用于通用Agent的模型评估，也支持自定义Agent的评估实现。榜单侧重模型维度评估的：hkust-nlp.github.io/agentboard/…

AgentBoard 是一款专为多轮交互、多任务环境设计的评估平台，旨在通过细粒度的能力拆解、轨迹回放和可视化分析，帮助开发者深入理解和优化 AI Agent 的行为表现。它旨在解决传统评估指标（如成功率）无法反映 Agent 内部决策过程、探索策略和计划执行一致性的问题。它通过过程能力拆解、多轮交互轨迹追踪和部分可观测环境模拟，实现对 Agent 全流程的细粒度评估。

AgentBoard 提供了多维度、细粒度的评测指标，主要包括以下几类：

Success Rate（任务成功率）：衡量 Agent 在规定最大交互步数内“完全达到”环境目标的比例
Progress Rate（进度率）：衡量 Agent 在多步任务中已完成子目标的比例，反映累进式推进能力
Grounding Accuracy（落地准确率）：衡量 Agent 在每步操作（如点击、API 调用）中生成“合法、可执行”动作的比例，用于评估动作的有效性及环境交互质量
难度分层分析
- Easy/Hard Breakdown：分别统计“易”“难”子集上的 Success Rate 与 Progress Rate，帮助识别在不同难度样本上的性能差异
长程交互趋势
- Long-Range Interaction Curve：展示随着交互步数增加，Progress Rate 的变化趋势，用于评估 Agent 在“长对话”“长任务”中的持续推进能力

4.1.4、WebArena

github.com/web-arena-x…

默认支持两种基准Agent 测试，自定义Agent 评估需要自己开发适配。

WebArena 考设计了四种常见场景，包括在线购物（Amazon、eBay），讨论论坛（Reddit、StackExchange），协作开发（GitLab），商业内容管理（CMS），并且纳入一些常用工具，比如计算器、地图、便签本，还有如维基百科这类常用知识库和文档。

同步提供了一个测试数据集，包含 812 个基于网络的测试任务

每个任务都是 high-level 自然语言表达的，模拟人正常的使用方式。
评估任务执行的准确性。

设计了两种基准LLM-prompt web代理，其中输入观察和预测动作都是文本形式：

(1) 直接代理 (Direct Agent)：代理接受观察作为输入，并直接预测下一个动作
(2) 推理代理 (Reasoning Agent)：代理首先以文本形式执行一系列推理步骤，然后发出下一个动作

4.1.5、TheAgentCompany

TheAgnetCompany: github.com/TheAgentCom…

WebArena 的升级版。

评估指标优化：

综合评分系统
- 结果导向型评价（主要）
- 子检查点检查（次要）
多种评价方法：
- 确定性评估者
- 基于LLM的评估者
可扩展基准测试框架
- 几分钟内即可添加新的任务/评估人员/子检查点

4.2、组件评估

4.2.1、工具评估

BFCL:gorilla.cs.berkeley.edu/blogs/13_bf…

伯克利函数调用评测（Berkeley Function Calling Leaderboard, BFCL）提供 2000 个测试用例，通过分步评估与端到端评估，在复杂度逐渐提升的场景中衡量调用准确性、通过率与胜率。T-Eval 包含 553 个工具使用案例，用于测试多轮交互与嵌套工具调用能力。StableToolBench 等先进基准测试专注于解决 API 不稳定性问题，NesTools 用于评估嵌套工具场景，而 ToolHop 则通过 995 个查询与 3912 个工具，评估多跳工具使用能力。

华为方舟与清华最近的研究：ToolACE

ToolACE 利用一种自进化合成方式，构建了一个包含 26,507 个 API 的工具池。在复杂度评估器的指导下，多个代理通过交互生成对话。为了确保数据的准确性，实现了一个结合基于规则和基于模型的双层验证系统。基于合成数据训练的80亿参数小模型在BFCL上也能达到与 GPT-4 模型相媲美的性能。

数据集：huggingface.co/datasets/Te…

论文：arxiv.org/abs/2409.00…

4.2.2、RAG评估

RAGAs：github.com/explodinggr…

RAGAs (Retrieval-Augmented Generation Assessment) 它是一个RAG评估框架，它可以帮助我们来快速评估RAG系统的性能，为了评估 RAG 系统，RAGAs 需要以下信息:

question：用户输入的问题。
answer：从 RAG 系统生成的答案(由LLM给出)。
contexts：根据用户的问题从外部知识源检索的上下文即与问题相关的文档。
ground_truths：人类提供的基于问题的真实(正确)答案。这是唯一的需要人类提供的信息。

数据集名称	特点
Amnesty QA (V2)	包含完整的问题、上下文和标准答案，全面测试 RAG 系统能力
WikiEval	评估生成答案与维基百科内容一致性，强调事实性
Natural Questions (NQ)	真实用户搜索查询，多样化答案类型
HotpotQA	多跳推理，需跨文档整合信息

4.2.3、Mem评估

LongMemEval:github.com/xiaowu0162/…

设计了一个属性控制的流程，为每个问题编译出连贯、可扩展且带有时间戳的聊天记录。LongMemEval 要求聊天系统解析在线动态交互以进行记忆，并在所有交互会话结束后回答问题。包含 500 道高质量题目，旨在测试五项核心长期记忆能力：

Information Extraction 信息提取
Multi-Session Reasoning 多会话推理
Knowledge Updates 知识更新
Temporal Reasoning 时间推理
Abstention 信息丢弃

5、上下文工程如何实现

核心组件：

提示流 ( Prompt Flow) ：动态演进的指令集合，包括系统约束和任务指导
工具集 (Tools) ：模型可调用的外部能力 (API、代码解释器等)
资源库 (Resources) ：结构化知识和数据，包括外部检索内容（外部知识以及历史经验的沉淀）
记忆管理 (Memory) ：短期缓存和长期知识库，支持信息的持久化与检索

对上下文进行智能的、动态的写入（Write）、选取（Select）、压缩（Compress）和隔离（Isolate）

5.1、写入

会话内写入 (Session-level Write): Agent 将中间思考、计划或临时数据写入一个会话内的草稿纸 (Scratchpads)。这是一种轻量级的、非持久化的写入，用于管理当前任务的复杂性。
持久化写入 (Persistent Write): 系统将具有长期价值的信息（如用户偏好总结、关键事实）写入外部的记忆 (Memory) 系统，如向量数据库或知识图谱。这实现了跨会话的知识积累。例如，ChatGPT 和 Cursor 等应用通过这种方式，让 Agent 在与用户的持续交互中“学习”和“成长”，用户在解决某些问题时无需手动引入上下文。

5.2、选取

上下文工程的中的选取包括三类：

确定性选取 (Deterministic Select): 指根据预设规则加载上下文。例如，编码 Agent （Claude Code）在启动时，固定加载项目根目录下的 CLAUDE.md 文件，这是一种简单高效的先验知识注入。
模型驱动选取 (Model-driven Select): 当可用信息源过多时（如海量工具或文档），可以利用模型自身的能力进行筛选。
检索式选取 (Retrieval-based Select): 这是最主流的方式，其核心范式是通过相似度检索，从记忆、草稿纸或外部知识库中选取信息。因此，选取操作的成败，在很大程度上依赖于底层检索系统的质量。