Re:source

Context Engineering Survey

Context Engineering 相关技术和实践的全面调研和分析

背景

最近 Shopify CEO Tobi Lutke 的一条推文引发了社区的广泛讨论：

tobi lutke on Twitter / X

其中 Context Engineering 正是本文的主角，Andrej Karpathy 也下场回复支持 Context Engineering 这一术语

Andrej Karpathy on Twitter / X

我在一个月前也写了一篇笔记 Context Engineering instead of Prompt Engineering，最近又有一系列 Context Engineering 相关的文章，我们一起来看一下有没有什么认知上的迭代。

什么是 Context Engineering？

到底什么是 Context Engineering，它和 Prompt Engineering 到底有什么区别和联系？

LangChain 将其定义为”构建动态系统为 LLM 提供合适的信息与工具，使得 LLM 能够完成任务”，DAIR.AI Academy 也有类似的定义”为 LLM 设计优化指令和相关上下文以有效执行任务的过程。”

某种意义上 Prompt Engineering 算是 Context Engineering 的一个子集。Prompt Engineering 更多的专注于巧妙的措辞来引导模型给出更好的答案，比如常用的 prompt 技巧：few-shot、CoT 等等，更像是”如何提问”、“提问的艺术”。而随着应用越来越复杂，Agent 的兴起，需要使用 Agent 动态地获取和组织信息，向 AI 提供完整、正确、结构化的上下文也变得更加重要。

Context Engineering vs Prompt Engineering

优秀的上下文包括了：

  • 给模型的提示与指令：设定角色与场景，说明我们希望它执行什么类型的任务
  • 从知识库检索到的信息：通过 RAG、API 调用、MCP 等工具检索到的相关信息
  • 短期记忆：正在进行中的对话，包括过去的状态、工具调用和结果
  • 长期记忆：来自相关但独立的历史对话、事件、用户偏好等
  • 结构化输出

为什么 Context Engineering 很重要？

当 LLM 无法很好得解决问题时，从第一性原理思考，通常有两种原因：

  • 模型能力不足
  • 模型没有被给予适当的上下文导致无法有好的输出

而大多数情况是第二个原因导致的。我们常常说要把 LLM 当成一个实习生来协助我们的工作与生活，试想一下你是一个刚入职的实习生，你的 mentor 给你安排了一个活，但是没有把背景给你交代明白，你把这个活干好的几率有多少呢？

前段时间，Cognition 和 Anthropic 各自发布了两篇关于是否构建 Multi Agent 的文章，看似双方持有对立观点，但其中都说明了 Context Engineering 的重要性：

Cognition:

Context Engineering is effectively the #1 job of engineers building AI agents.

Anthropic:

Agents often engage in conversations spanning hundreds of turns, requiring careful context management strategies.

我在使用 Agent 产品的时候，很喜欢看对话的过程，这是我们调试 Agent 的唯一信息，当结果不尽人意时，我会代入自己，此时我就是 Agent，我是否掌握了足够的上下文来回答问题？缺了什么信息是提问者没有给的？缺了什么工具导致我没法自动获取所需的信息？以此来优化 prompt、tools 和 Agent 流程，来补齐上下文。

Context Engineering 会遇到哪些问题？

当我们知道了应该给大模型提供足够多的上下文时，我们是不是可以一股脑的将所有内容都通过 prompt 交给大模型呢？答案肯定是否定的。在早期模型上下文相对比较小时，RAG 非常的火，它能够在知识库中筛选一层与用户输入最相关的信息作为上下文，这是 Context Engineering 非常关键的手段之一。

现在很多模型已经支持了长上下文窗口（OpenAI GPT-4.1，Gemini 2.5 Pro 都支持了 100W token），很多人觉得 RAG 是不是就可以不需要了，就可以将所有信息都放入提示词中？

现实往往不是如此，当输入过长的上下文时反而会让模型的性能更差，过度加载上下文会导致上下文污染、分散注意力、混淆或相互冲突。

Introducing Fiction.LiveBench: The First Real-World Long Context Benchmark for Writers 是一个专门评测大模型长下文理解能力的 benchmark，使用虚构小说作为测试语料，要求模型能够维持对复杂叙事的连贯理解，跟踪人物、事件和情节在长文本中的发展，准确回答需要理解整个上下文的详细问题。从数据中可以看到，绝大多数模型在随着输入 token 的增加，长下文理解能力都会有所降低。

Fiction.LiveBench Results

在 NoLiMa：Long Context Evaluation Beyond Literal Matching 这篇论文中提出的 NoLiMa Benchmark 也揭示了相同的现象。

NoLiMa Benchmark Results

Drew Breunig 在 How Long Contexts Fail 这篇文章中提到了更长的上下文可能导致性能问题的几种情况：

上下文污染（Context Poisoning）

Context Poisoning 这个词出现在 Gemini 2.5 的技术报告中， 他们讲述了使用基于 Gemini 2.5 Pro 的 Agent 玩宝可梦游戏的一些发现，其中就涉及到上下文污染。

由于模型的训练数据来源于互联网，当然也就包括了大量游戏攻略数据，这导致 Gemini 在玩宝可梦时，用到了其他版本宝可梦中才有的信息，导致被误导。这个”幻觉”一旦被加入到上下文中造成了污染，模型就会变得”执着于达成这个不可能或者毫无关系的目标”，并且需要很长的时间来摆脱这个影响。

An especially egregious form of this issue can take place with “context poisoning” - where many parts of the context (goals, summary) are “poisoned” with misinformation about the game state, which can often take a very long time to undo. As a result, the model can become fixated on achieving impossible or irrelevant goals.

在某些情况下，“上下文污染”是尤其严重的一种问题表现，当上下文被游戏状态的错误信息污染时，往往需要很长的时间才能撤销。导致模型执着于达成不可能达成或者毫无关系的目标。

关于 Gemini Agent 玩宝可梦的更多细节，可以阅读技术报告，也可以查看 An Agentic Case Study: Playing Pokémon with Gemini 这篇文章。

上下文注意力分散（Context Distraction）

注意力分散指的是，当上下文变得越来越长时，模型会过度关注上下文，却忽略了其在训练时期学到的知识。同样是在Gemini 2.5 技术报告中的宝可梦例子，揭露了这一问题：

While Gemini 2.5 Pro supports 1M+ token context, making effective use of it for agents presents a new research frontier. In this agentic setup, it was observed that as the context grew significantly beyond 100k tokens, the agent showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans. This phenomenon, albeit anecdotal, highlights an important distinction between long-context for retrieval and long-context for multi-step, generative reasoning.

尽管 Gemini 2.5 Pro 支持了 100 万 tokens 长度的上下文，但如何有效地将其用于代理是一个前沿研究方向。在我们的代理设置中，观察到当上下文显著超过 10 万 tokens 时，代理表现出倾向于重复其历史中的行为，而不是综合新的计划。这一现象虽然是经验性的，但突出了长上下文检索和长上下文多步生成推理之间的区别。

上下文混淆（Context Confusion）

当上下文中混入了无关或多余的信息时，会导致模型生成低质量内容。

Berkeley Function-Calling Leaderboard 是一个关于模型 Function Call 的基准评测，用来评估模型有效使用工具调用的能力。该排行榜显示每个模型在提供多个工具时性能都会下降。

在 Less is More: Optimizing Function Calling for LLM Execution on Edge Devices 这篇论文中，在 Llama 3.1 8b 模型上测试了当提供了 46 个工具时，模型无法正确选择工具，当缩减到 19 个工具的时候，反而成功了。

Function Calling Results

上下文冲突（Context Clash）

这是另一种 Context Confusion 的场景，上面提到的 Context Confusion 还只是无关的信息，而这里的 Context Clash 则是存在相互矛盾的信息。

微软和 Salesforce 最近的一篇论文 LLMs Get Lost in Multi-Turn Conversation 发现 LLM 经常在早期阶段做出假设，并过早地尝试生成最终解决方案，并过分依赖这些解决方案，导致 LLM 在多轮对话过程中走错、迷失方向且无法恢复。

综上，更大的上下文会产生新的失败情况。上下文污染会随时间积累错误；上下文分散会导致过度依赖上下文并重复过去的动作，而非向前推进；上下文混淆会导致不相关的工具或文档使用；上下文冲突会产生内部矛盾从而破坏推理过程。

如何解决上述问题？

Drew Breunig 在下一篇文章 How to Fix Your Context 中就给出来缓解和避免这些失败的一些方法。

RAG

正如上文所说，我们不能因为模型支持了越来越长的上下文窗口就选择把所有信息都放入上下文中，RAG依然是能够有选择地添加相关信息来帮助 LLM 生成更好回复的方法。

RAG 相关的具体介绍这里就不赘述了，这里有一篇关于 RAG 相关技术的综述文章，感兴趣的可以查看：Retrieval-Augmented Generation for Large Language Models: A Survey

工具装备（Tool Loadout）

loadout 这个词来源于游戏领域，比如在 Moba 游戏中，游戏本身会提供大量的装备选择，但是玩家在每场对局中只能选择部分装备，需要根据对手以及场内局势选择。

在 LLM 中，我们可能确实需要提供更多的工具，但是全部给 LLM 装备会导致性能更差。我们可以使用 RAG 或者 LLM 来针对特定需求选择部分工具。Less is More 团队就是使用了 LLM 驱动的工具推荐器动态选择工具的方式，该 LLM 被提示推理”它需要哪些数量和类型的工具来回答用户的问题”，然后通过语义搜索来确定最终的工具组合，他们在 Berkeley Function-Calling Leaderboard 上使 Llama 3.1 8b 的性能提高了 44%。

上下文隔离

上下文隔离是通过多个相互不共享上下文的不同会话，实现这一点的方法之一就是将任务拆分为更小的、独立的任务，每个任务有其专属上下文。

Anthropic 的 How we build our multi-agent research system 就是一个很好的例子：

The essence of search is compression: distilling insights from a vast corpus. Subagents facilitate compression by operating in parallel with their own context windows, explring different aspects of the question simultaneously before condensing the most imporant tokens for the lead research agent. Each subagent also provides separation of concerns - distinct tools, prompts, and exploration trajectories - which reduces path dependency and enables thorough, independent investigations.

搜索的本质是压缩：从浩瀚语料库中提炼洞见。子智能体通过并行操作，各自拥有独立的上下文窗口，同时探索问题的不同方面，并最终为主研究智能体浓缩最重要的 token。每个子智能体还提供了关注点分离——不同的工具、提示和探索轨迹——这降低了路径依赖性，并使得调查更加全面和独立。

在给定一个问题时，可以识别出几个子问题或探索领域，并使用多个智能体分别进行处理。这不仅加快了信息收集和提炼速度，还可以防止上下文积累过多或不相关的信息，从而提升质量。

上下文剪枝与总结

上下文剪枝就是将不相关或不必要的信息从上下文中移除，而上下文总结则是将累积的上下文压缩成简明摘要。

Context Compaction

在 Claude Code 的使用中你会发现，当上下文即将耗尽时，会触发 compact 来对当前会话进行总结。

Reference