04 Context Engineering(上下文)：给 AI 装一个“信息管家”

你有没有这种经历：跟 AI 聊到第二十轮，它突然开始无视你一开始定的规矩——“数据库表结构不能动”，它好像完全忘了。你回去翻聊天记录，那句话明明还在。问题不在模型记性差，在于它的“工作台”太乱了。

上下文工程（Context Engineering）管的，就是这张工作台。

光写好提示词，不够了

提示词工程大家已经比较熟了。它关心的是“这句话怎么写，模型才听得懂”。你把角色、任务、约束、格式交代清楚，模型就能给出像样的回答。对于单次问答，这套方法够用。

但 Agent 不一样。Agent 是多轮推理、会调工具、要读历史、还要检索外部知识的系统。它每一步看到的东西，远不止你最后打的那句话。系统提示词、工具定义、上一步的返回结果、对话历史、长期记忆、RAG 检索到的段落——这些东西共同挤在一个有限的上下文窗口里。

你没法靠一句精心打磨的提示词，管理这么一屋子信息。

比喻：提示词工程是给员工写一张便签，上下文工程是给他搭一套工作体系

你让一个新员工去办一件事，写张便签告诉他“去三楼找王经理签字”，这叫提示词工程。但如果你要他独立运作一个项目，光有便签不够。你得给他公司背景资料、历史项目档案、团队协作流程、哪些事能自己定、哪些事得请示。上下文工程就是搭这套体系。

百度百科把上下文工程称为提示词工程的“自然演进”，这个说法挺准确。它不是取代，是把视野从“一句话”拉到了“整个信息环境”。

上下文窗口不是硬盘，是白板

很多人对上下文窗口有个误解，觉得它像一个仓库，东西塞进去就在那儿了，用的时候去拿就行。

不是这样。

上下文窗口更像会议室里的一块白板。模型每次推理，都是对着这块白板“看一遍”再开口。白板上的东西越多，它越难一眼找到重点。你写了三页板书，关键的决策记录夹在中间，它可能扫过去根本没注意到。

比喻：上下文窗口是白板，不是档案柜

档案柜里的文件放进去就在那儿，需要的时候翻出来看。白板不一样，你每次看它，只能看到当前写着什么。写满了就得擦掉一些再写。擦错东西，或者写得太密找不到重点，都是问题。

这就引出一个很现实的现象：上下文腐烂（Context Rot） 。随着对话变长，模型的推理准确率会下降。不是因为它“忘了”，而是因为注意力被摊薄了。更早的、已经不相关的内容还在白板上，干扰当前判断。有研究显示，纯对话场景下准确率会从高位掉到 57%，如果混入矛盾信息，直接崩到 21%。

这就像后厨台面：台面越大，主厨反而越难找到他要的那瓶调料。

上下文工程到底在管什么

说得直白一点，上下文工程在做四件事：写、选、压、隔。

写，是把该交代的东西写清楚。系统提示词、工具描述、任务背景，这些是 Agent 每次启动都要看到的基础信息。写得含糊，后面全歪。

选，是在每一步推理前，从一堆可用信息里挑出当前真正需要的。不是把所有资料一股脑倒进去，而是判断“这一步需要什么”。一个查天气的请求，不需要把用户的订单历史也塞进来。

压，是信息太多了要压缩。长对话的历史、冗长的工具返回结果，不可能原封不动全留着。得摘要、提炼、丢弃。就像整理行李箱，先把衣服卷紧，减少单件体积。

隔，是把不同来源的信息分开。系统指令和用户输入之间要有边界，工具返回的内容不能跟系统规则混在一起。Agent 场景下，工具返回的文本也可能夹带恶意指令，隔离是安全的第一道线。

比喻：上下文工程是Agent的“信息管家”和“内存管理器”

管家做的事，不是替老板做决策，而是确保老板在需要的时候，手边有正确的文件，没有多余的杂物。信息太少，模型抓瞎；信息太多，模型犯糊涂。管家的本事在于“恰到好处”。

和提示词工程不是一桌菜

很多人会问：上下文工程是不是就是升级版的提示词工程？学了新的，旧的就不用了？

不是。它们是不同层面的事。

提示词工程优化的是一次“提问”的措辞。上下文工程管理的是整个“信息环境”：数据从哪来、怎么组织、什么能进窗口、什么必须拦在外面。Teradata 有一句话总结得很到位：提示词工程决定模型“该怎么回答”，上下文工程决定模型“能知道什么、能用什么、能做什么”。

打个比方。你是一位导演，提示词工程是你写的那句“Action”怎么喊。上下文工程是你在开拍之前，把场景搭好、灯光调好、演员的台词和走位定好、道具摆放到位。“Action”喊得再好，场景不对，拍出来也不对。

Gartner 也把上下文工程定位得更偏“企业架构”层面，而提示词工程更偏“交互优化”。一个管系统，一个管沟通。

几个实战策略

滑动窗口是最基础的做法：保留最新的，丢掉最早的。简单直接，但粗暴丢弃可能让早期的重要约束消失。适合短周期任务，长任务不行。

摘要压缩是在丢之前先提炼。把一段历史对话压缩成几句关键结论，保留信号，节省空间。OpenAI 的实践里把这一步叫做“compaction”：把长跑对话里后续还用得上的状态带过去，同时把体积降下来。

分层组织是把信息按优先级摆。系统提示词放开头，当前任务和关键约束放结尾。斯坦福的研究提过一个现象：模型对上下文中间位置的信息利用效果更差，开头和结尾更容易被注意到。所以重要的东西不要埋在中间。

子 Agent 分流是让不同的 Agent 各管一摊，每个只拿自己需要的那部分上下文。一个主 Agent 负责拆任务和汇总，子 Agent 分别去查资料、写代码、做审查。每个子 Agent 看到的上下文是干净的、聚焦的，不会被其他任务的信息污染。

比喻：子 Agent 像公司里的不同部门

老板不需要把公司所有文件都塞给一个人。财务部看财务的，法务部看法务的，市场部看市场的。每个部门拿自己该看的资料，干自己该干的事，最后把结论汇总到老板那儿。主 Agent 就是那个做汇总的人。

说到底

上下文工程的核心问题，就一句话：怎么在正确的时间，用正确的格式，把正确的信息放进模型的视野里。

信息太少或格式不对，模型没有足够的依据；信息太多或无关，模型又会被带偏。这中间的分寸感，就是工程要做的事。

Karpathy 说这件事“既是精深的科学，也是巧妙的艺术”。科学在于它有可复用的策略和方法，艺术在于每一步的取舍都需要结合具体任务来判断。

提示词工程教你怎么说话。上下文工程教你怎么让模型在开口之前，就已经站在对的地方、看着对的东西。这两件事，一件都不能少。