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

Context Engineering是最近AI领域的一个新的概念 但Context是什么 Context Engineering又是什么 它解决了什么问题 怎么解决这些问题的 很多人都不是特别清楚 别担心 这个视频会一一给你解答 单纯从外部来看 大模型就像一个函数 你给它输入 它就会给你输出 不过大模型的输入是有大小限制的 这个限制叫做上下文窗口

对应的英文为Context Window 这里面的Context指的就是模型输入 比如用户问题 背景信息 相关资料 可用工具列表 工具执行结果 和历史对话等等 模型把这些输入作为上下文 并基于这些内容来生成答案 而Context Window呢 则是指模型的输入中 最多能包含多少个token token可以理解为文本被拆分成的最小单位

可能是一个字 一个词 或者是一个标点符号 一个token大概相当于0.75个单词 或者是1.5个汉字 比如说 Gemini 2.5 Pro的Context Window是100万 意思是它最多能处理100万个token的输入 一旦超过这个限制 前面的内容会被丢弃 只保留最后的100万个token 100万个token呢 其实是一个相当大的容量了 接近7本书的长度了

也就是说 像Gemini 2.5 Pro这样的模型 可以一次性地读完7本书 这个容量已经是非常惊人了 甚至让人觉得 既然Context Window这么大 那我们是不是就可以把所有资料都丢进去 让模型自己去理解 举个具体点的例子 假设你想做一个智能客服 你希望这个智能客服可以回答用户提出的各种 关于你们公司产品的问题 这个智能客服的核心就是一个大模型 大模型虽然很强

但是直接问它的话 它只能回答不知道 毕竟它又没有你们公司产品的信息 不过你一想 没关系 我们不是有产品使用手册吗 直接丢给大模型好了 让大模型根据手册回答问题 不管产品手册有几十页 还是几百页 甚至几千页 我们都直接扔给模型好了 不用管产品手册里面哪些内容与用户问题相关 哪些内容与用户问题无关

反正Context Window这么大 全部丢给模型就行了 肯定是没问题的 答案肯定能出来 这对不对呢 不对 事实并没有那么简单 在实际使用中 我们依然会遇到很多限制 想要让模型稳定 高效 准确地输出内容 我们必须考虑三个非常现实的问题 第一 大多数模型的Context Window 其实非常有限 Gemini 2.5 Pro的100万Context Window

算是很大的了 大部分的模型 其实都没有这么大的Context Window 让我们看一下主流模型的Context Window大小 Gemini 2.5 Pro我们之前聊过了 是100万 而最近出的GPT-5的Context Window 是40万 DeepSeek V3是12.8万 Claude 4的Context Window是20万 这些还算是一些相当不错的模型了 很多时候为了节省成本

我们可能还会使用一些小模型 它们的Context Window可能就只有几万 连一个产品使用手册也装不下 这个就是第一个问题了 我们再回来看其他的 第二点 输入太杂乱会影响模型理解 即使你所使用的模型有着很大的Context Window 即使给模型的输入量 没有超过Context Window的上限 你也最好不要把所有相关资料不加筛选

全部都扔给模型 因为如果你不加筛选的话 给模型的输入内容可能就会杂乱 冗余 矛盾 模型这个时候可能就会混淆重点 输出含糊其辞的回答 与其把所有信息都塞进去 不如经过精心的设计和组织 确保模型看到的是准确 有结构 重点突出的内容 第三 输入越多 成本越高

大语言模型的调用成本基本上都是按照token来计费的 token的数量越多 消耗就会越大 如果我们不加控制地塞入大量上下文内容 即使效果还行 也可能会带来不必要的开销 尤其是在产品化和大规模使用时 优化输入就是优化成本 所以我们看到 直接把所有资料都发给大模型的方案是行不通的 这里存在很多的问题 那我们该如何解决它们呢

这就引出Context Engineering了 Context Engineering翻译成中文就是上下文工程 从字面上来看 Context Engineering似乎就是针对Context所做的一些技术 回想下Context的含义 Context代表给模型的输入 那Context Engineering的含义就是对模型输入做优化了 对 就是这个意思 简单来说 Context Engineering关注的不是怎么训练模型

而是怎么精心设计给模型的输入内容 让模型在有限的Context Window里面 尽可能理解得更准 答得更好 花得更少 它的核心思想是 不改变模型结构 只改变模型看到什么 其实吧 Context这个概念一直都存在 但是Context Engineering这个词 却是最近一段时间才火起来的 这主要是因为以下两点原因 第一 现在的模型已经足够强大了

跟一两年前的模型相比 现在的模型强大的不止一点半点 对于现在的模型来说 你只要给到它足够精细的要求 给出它足够完整的相关资料 模型就可以给出非常准确有用的回答 在大部分情况下 如果模型的回答不能够让你满意 这并不是因为模型不够强 而是因为你没有给到模型足够清晰和足够完整的信息

而这点也正是Context Engineering要解决的问题 第二 Agent的兴起 Agent是一种把大模型和工具结合起来 让模型能够独立感知环境 影响环境 从而解决用户问题的一项技术 我之前做过Agent的相关科普视频 不了解Agent的同学可以看一下 Agent的运行涉及到模型对工具的使用 所以可用工具信息 工具执行结果等等一系列的内容

都会放到模型输入里面 使用多少次工具就会有多少个工具执行结果 Agent运行时间长了 这些工具执行结果就会占满整个Context Window 从而影响到模型后续的回答效果 这也就是为什么Agent兴起了之后 Context Engineering的话题也就随之火了起来 因为Context的管理效果会直接影响到Agent的执行结果 在了解了Context Engineering兴起的原因之后 接下来我们来看它的具体实现方法

总的来说 Context Engineering并不是某项单一的技术 而是由多种技术组成的方法体系 这里我借鉴了LangChain的设计框架 把Context Engineering这门技术体系划分为四类 分别是保存Context 选择Context 压缩Context和隔离Context 下面我们来一一说明 首先是保存Context 保存Context就是说 我们把Context做个筛选

总结并且找个地方保存起来 比如说是内存硬盘之类的地方 在模型需要的时候再发给模型 这里一个比较典型的例子就是ChatGPT的记忆功能 比如我可能就在某次聊天的过程中告诉他 我的名字是马克 我有一个频道叫做马克的技术工作坊 在这个频道里面我分享过关于Agent RAG MCP A2A等相关的内容

注意到这个Updated saved memory了吗 这就代表ChatGPT把这段内容存入到它的记忆库里面去了 我们可以打开记忆库来证实这一点 这个就是ChatGPT的记忆库了 可以看到它刚才保存好的记忆就放在它的记忆库中 这个保存的动作是Context Engineering的第一步 它解决了信息持久化的问题 但光存下来还不够 ChatGPT的记忆库是可以存放很多条记录的

那在未来的对话中 ChatGPT是如何从这个庞大的记忆库里面 精准地找到它所需要的信息呢 这就引出了我们下一个 也就是最核心的技术 选择Context 所谓选择Context 就是从海量的信息中选择出一部分与用户问题最为相关的内容 并且把它们放在模型的Context里面 一个好的选择策略是整个系统高效准确运行的保障 我个人把选择策略分为两大类

静态选择和动态选择 我们先看最简单的静态选择 静态选择就是把一些永远重要 必须要遵守的信息 在每一次请求时都全部放到Context里面 它就像是给AI焊在脑子里的系统指令 或者是核心原则 比如Cursor的rules文件 Claude Code的CLAUDE.md文件

Claude Code的CLAUDE.md文件 这些文件指定了当前项目的一些信息 编码时需要遵守的一些规范等等 这些信息至关重要 无论用户问什么 这些信息都必须在场 以确保AI的行为符合预期 因此对于这类短小但至关重要的信息 最有效的策略就是全都要 只要确保它们加起来 不会撑爆Context Window就行 说完了静态选择

接下来我们看一下更强大 也更为常见的动态选择 动态选择是指选择与用户问题 最为相关的内容 并且把它放入到Context中 它不是把所有的东西都塞进去 而是像一个聪明的图书管理员 为你精准地找到需要的那几页 比如ChatGPT从记忆库中 挑选与用户问题最为相关的记忆 这就是一种动态选择 再比如我们从包含数十个

甚至数百个工具中挑选 与用户问题最为相关的三个工具 扔到模型的Context中 这也是一种动态选择 动态选择有很多种实现方式 其中最为有名的便是RAG 我之前讲过RAG的实现原理 不清楚的小伙伴可自行看下 讲完了选择Context 下面我们再聊下压缩Context Agent运行过程中会在Context里 积累大量的历史消息 一般来说 这些历史消息中最占空间的

便是模型的输出文本 和工具的执行结果 如果不做处理的话 这些历史消息便会迅速挤满 Context的全部空间 从而影响模型的后续回答效果 一个常见的处理方法 就是压缩历史消息 举个具体的例子 大家都知道Claude Code 它是一个用于写代码的Agent 在它运行的过程中 它可能会读取很多的代码内容 同时也会写入很多代码内容 然后Claude可能还会输出一些思考和结论

它们都会存放在Context中 如果Claude Code不对这些内容 做一些处理的话 那么它的Context Window 很快就会被各种代码信息所挤爆 还好Claude Code 早就意识到了这个问题 它也确实有一些处理措施 当Context Window的使用量超过95%的时候 Claude Code便会运行一种叫做 auto-compact的程序 对以往的Context做个压缩

其实也就是总结下之前的内容 然后把原来的内容扔掉 在总结后 Context Window的使用量就会降下来 用户甚至还可以在Claude.md里面

用户甚至还可以在Claude.md里面 指定压缩方案 比如我们看下Claude Code的官方文档 它这里举的例子就是让Claude Code 压缩时重点保留测试输出 和代码改动方面的内容 那说完了压缩Context 我们下面就来看看最后一个策略 隔离Context 隔离Context的意思就是说 不同模块之间的Context 是互相隔离的 互不干扰 这通常发生在Multi-Agent系统里面

我们可以用Anthropic的这篇文章来举例 它讲述了Anthropic是怎么构建 它们的Multi-Agent研究系统的 文章内容我们就不细看了 我来给大家画个图 讲一下它的大致架构 在文章中Anthropic提到 系统内部有一个Lead Agent 他负责做任务下发和归纳总结 你可以把它想象为整个系统的总指挥官 用户的请求会先打到这个Lead Agent里面 在接受到用户请求之后

Lead Agent便会把用户的问题 下发到其他的Agent系统里 Anthropic称这些Agent为subagent 比如Lead Agent会先发起一个负责搜索PDF的subagent 拿到PDF的搜索结果 再去执行一个负责搜索网络的subagent 拿到网络的搜索结果 然后再去执行一个负责搜索图片的subagent 在拿到所有subagent结果后

Lead Agent就会产出一份最终的报告给用户看 整个流程也就随之结束了 这些subagent系统有着自己独立的工具 独立的运行历史独立的记忆体系 也就是说这几个subagent的Context 是互相隔离的互不影响 这个就是隔离Context的一个非常典型的例子 不同的系统拥有不同的Context 职责清晰彼此之间互不干扰

Anthropic构建的Multi-Agent研究系统 大致就是这个样子的了 除此之外 Claude Code里面也有一个subagent的概念 跟我们之前讲的Multi-Agent研究系统里面的subagent有点像 但并不完全一样 在Claude Code中 每个subagent也都有着自己独立的Context 互相隔离 感兴趣的同学可以自己用下试试 鉴于时间的关系 我这里就不赘述了 Context Engineering大致就介绍到这里了

稍微回顾下我们今天学习到的一些知识 Context代表模型的输入 Context Window 它代表模型输入的容量上限 一般以token的数量为单位来表示 比如Gemini 2.5 Pro的Context Window就是100万个token Context Engineering 它指的是如何精心设计给模型的输入内容 让模型在有限的Context Window里面

尽可能理解得更准 答得更好 花得更少 Context Engineering的四大实现角度 分别是保存Context 选择Context 压缩Context 和隔离Context 最后值得一提的是 Context Engineering并不是某个特定而具体的技术 而是某一类技术的统称 它所包含的技术可以说是五花八门 我们这里也仅仅是管中窥豹 举了几个相关的例子

如果有观众想详细了解Context Engineering的话 我建议看看以下几篇文章 第一篇LangChain的Context Engineering 这篇文章系统地讲述了Context Engineering的概念和方法 通读一遍可以学到很多东西 我这个视频也借鉴了这篇文章中的不少内容 第二篇Cognition的Dont Build Multi Agents 这个标题 乍一看好像在反驳我前面讲到的Multi-Agent系统 其实不然

如果你仔细看一下这篇文章的话 你就会发现 它其实并没有反驳Multi-Agent系统 它只是认为多个Agent并行执行的方法是行不通的 如果一定要做Multi-Agent系统的话 那各个Agent的运行也必须要串联进行 并且要做好Context Engineering 确保给模型的输入简洁明了 所以看完这篇文章之后 你可以同时学到Agent的构建策略

与Context Engineering两方面的内容 今天的视频就到此结束了 别忘了点赞关注 我们下次再见 拜拜 ```