Context Engineering：概念与技术实现深度解析

目录

• Context Engineering
  • 保存Context
  • 选择context
  • 压缩Context
  • 隔离Context
• 总结

大模型的输入就像一个函数的入参，大小是有限制的，这个限制叫做上下文窗口，英文叫做Context Window

Context Window： 模型的输入中最多能包含的Token的数量

token 可以理解为文本被拆分成的最小单位，可能是一个字，一个词或者一个标点符号，一个token大概相当于0.75个单词或者1.5个汉字

Gemini 2.5 pro 的 context window 为 100W token 相当于7本书的长度，也就是说像Gemini 2.5 pro 这样的模型一次性可以读取7本书的长度了

思考：

在LLM 不知道产品手册的基础上，问它一些产品相关的信息，它肯定不知道的：

那就会想了不管产品手册多么大，直接丢给大模型就好了，返正上下文窗口那么大， 其实能解决问题，但这这样不对，事实没有这么简单。

三大问题：

1. 大多数大模型 的Content Window 非常有限

2.输入太杂乱会影响模型理解

即使你使用的模型有着非常大的上下文窗口，即使我们给模型的输入量没有超过上下文窗口上限，你最好也不要把所有资料不加筛选的塞给大模型，因为如果你不加筛选的输入，模型的输出结果可能就会非常杂乱，冗余，矛盾。模型这个时候可能就会混淆重点，含糊其辞的回答。与其把所有内容塞进去，不如经过精心设计和组织，确保模型看到的是准确的，有结构，重点突出的内容

3. 输入越多，成本越高

在产品化和大规模使用时，优化输入就是优化成本

那么如何解决以上问题？ 那就引出了Context Engineering

Context Engineering

Context Engineering 翻译成中文就是上下文工程

让模型在有限的context window 中尽可能的回答的更准，回答的更好，花的更少

核心思想：不改变模型结构。只改变模型能"看到" 什么

Context Enginerring 流行的原因：

• 模型已经足够强大

• Agent 的兴起

Agent 运行时间长了，这些工具的执行结果就会占用整个Context Window ，从而影响到模型后续的回答效果，这也就是为什么Agent火了之后，Context Engineeing 的话题也随之火了起来。
因为Context 的管理效果会执行影响到模型的执行结果。

接下来我们来看它的具体实现方法，总的来说 Context Enginerring 并不是某一项单一的技术，而是由多种方法组成的方法体系

借鉴LainChain的设计架构，把 Context Enginerring 这们技术体系划分为4类：

保存Context

概念：保存context 就是 把contex 筛选/总结 找个地方保存起来，比如说硬盘/内存之类的地方，在模型需要的时候再发给模型

选择context

概念：就是从海量的信息种选择出一部分与用户问题最为相关的内容，并且把他们放进模型的context中，一个好的选择策略是整个系统高效准确运行的保障

• 静态选择：就是把永远重要必须要遵守的信息再每一次请求时都全部放到Context 里面，它就像是给AI焊在脑子中的系统指令或者是核心原则，
  比如Cursor 的rules文件，claude code 的Claude.md文件 这些文件指定了当前项目的一些信息，编码时需要遵守的一些规范等等，这些信息至关重要，无论用户问什么，这些信息都必须在场。以确保AI的行为符合预期

• 动态选择： 选择与用户问题最相关的内容放入Context中 ，它不是把所有的内容都塞进去，而是像一个图书管理员，为你精准的找到你需要的那几页
  

动态选择有不同的实现方式，其中最为有名的便是RAG

压缩Context

Agent 运行时会在context 里面积累大量历史消息。 一般来说，这些历史消息中，最占用空间的是模型的出书文本和工具的执行结果。如果不做处理的话，这些消息便会迅速占满Context的全部空间，从而影响模型后续的回答效果，
一个最常见的处理方法就是压缩历史消息。

举个例子：以Claude Code 为例 ，当Context Window 超过 95% 的时候，会运行auto-compact 的程序，对以往的context 做一个压缩，其实也就是总结以下之前的内容然后把原来的内容扔掉，在总结之后context windows的使用量就会降下来，
用户甚至还可以在Claude.md 中指定压缩方案。

隔离Context

概念：不同模块的Context 是互相隔离的，互补干扰，这通常发生在Muti-Agent系统里面

• Leade Agent 会先发起一个负责搜索PDF的SubAgent，拿到Subagnet的搜索结果之后再去执行一个负责搜索网络的Subagent，拿到网络的搜索结果，让后再去执行一个负责搜索图片的Subagent，在拿到所有的Subagnet的搜索结果后，Lead Agent就会产出一份最终的报告给用户看，整个流程随之结束 。这些Subagent 有着独立的工具，独立的运行历史，独立的记忆体系，也就是说这几个Subagent的Context的互相隔离的互补影响。这就是隔离Context的一个非常典型的例子，不同的系统拥有不同的Context 职责清晰彼此之间互不干扰 。Anthaopic构建的Muti-Agent 研究大概就是这个样子了。

总结