上下文工程：当 AI 的"眼前"装不下那么多信息时

> 来源 commit: 9621a05 | easy-learn-ai 项目每日更新

---

一、一个托盘的故事

想象你走进一家繁忙的餐厅，服务员手里端着一个托盘。这个托盘不大，最多放四五个盘子。现在，厨房同时要出十道菜的料，但托盘只能装得下其中一部分。服务员得做决定：哪些菜先端？哪些可以等下一趟？哪几盘可以叠在一起省点空间？

AI 干活的时候，面前也有这样一个"托盘"。

每次你跟 AI 说话，它能"看到"的不只是你刚发的这句话。它还会看到你们之前的聊天记录、你上传的资料文件、系统里预设的规矩和背景知识——这一整包，就是它这次干活的"眼前信息"。

问题是，这个"眼前"的容量是有限的。就像那个托盘装不下十道菜一样，AI 的"眼前"也装不下太多东西。塞少了，它没料，只能瞎编；塞多了，它抓不住重点，开始走神，甚至把重要的信息给挤掉了。

这门精心安排"眼前信息"的手艺，就叫上下文工程（Context Engineering）。

---

二、为什么"眼前"会装不下？

要理解上下文工程，先得明白 AI 的"眼前"到底是什么。

你可以把 AI 想象成一个正在考试的学生。考场上，他面前有一张桌子，只能摊开有限的参考资料。这张桌子的大小，在专业术语里叫"上下文窗口"（Context Window）——也就是 AI 一次能处理的文字量上限。

早期的 AI，这张桌子很小，可能只能放几页纸。现在的 AI，桌子变大了，能放下一整本书，但终究不是无限的。而且，桌子越大，AI 找东西的时候越费劲——就像在一间巨大的图书馆里找一本书，图书馆越大，你花的时间越多。

更麻烦的是，这个"桌子"上的东西不只是你给的。它包括：

• 你的问题 —— 这是主角
• 相关资料 —— 你上传的文档、搜索到的网页
• 聊天记录 —— 之前你们聊过的所有内容
• 系统预设 —— 告诉 AI 该怎么回答的隐藏指令

---

三、塞少了 vs 塞多了：两种窘境

上下文工程要解决的，本质上是两个极端之间的平衡问题。

塞少了：AI 开始" hallucination "

如果你给 AI 的上下文太少，它会进入一种"没料硬编"的状态。这在专业上叫"幻觉"（Hallucination）——AI 开始自信满满地胡说八道。

想象你问一个从没去过北京的人："三里屯最好吃的火锅店是哪一家？"他如果没资料，又不好意思说不知道，就很可能编一个听起来像那么回事的答案："好像是叫'老北京涮肉坊'吧，听说挺有名的。"——实际上这家店可能根本不存在。

AI 也一样。当它的"眼前"缺乏必要的背景信息时，它会用训练时学到的"一般性知识"来填补空白。问题是，这些一般性知识往往不够精确，甚至已经过时了。

塞多了：AI 抓不住重点

另一个极端是塞得太多。你把一整本手册、几十页聊天记录、十几个参考文档全扔进去，AI 的"眼前"堆满了东西，反而不知道看哪。

这就像让一个人同时读十份文件，然后立刻回答一个具体问题。他的注意力会被分散，可能漏掉关键细节，或者把不同文件里的信息混在一起搞混了。

研究表明，当上下文过长时，AI 对信息的使用效率会显著下降——它更倾向于关注上下文开头和结尾的内容，中间部分容易被"忽略"。这被称为"中间遗忘"现象。

---

四、四类基本动作：写、挑、压、分

那么，怎么解决这个问题？业界总结出了四类基本策略，就像那个餐厅服务员的四种手法：

1. 写出去（Write）—— 先把东西存外面

有些东西现在用不上，但后面可能需要。与其占用宝贵的"托盘"空间，不如先写到一个"便签"上，需要的时候再拿回来。

AI 也能这么做。它可以把中间算出的结论、搜索到的临时结果写到一个外部存储里（比如一个文件或数据库），等后面需要时再读取。这样，它的"眼前"始终只保留当前最相关的信息。

2. 挑着放（Select）—— 用到哪条才放哪条

不是把所有资料都塞进去，而是根据当前问题，只挑选最相关的部分放入上下文。

这就像医生看病。病人的完整病历可能有几百页，但医生问诊的时候，只会调出跟当前症状相关的检查报告和用药记录，而不会把几十年的全部病历都摊在桌上。

在实际应用中，这通常通过"检索增强生成"（RAG）来实现：先根据用户问题搜索最相关的文档片段，只把这些片段放进上下文，而不是把整个文档库都塞进去。

3. 压一压（Compress）—— 把长的变短的

聊天记录越积越长，快占满窗口了。这时候可以把旧的对话总结成几句摘要，省出空间给新的内容。

想象你在开一个很长的会议。每过一个小时，秘书就把之前的讨论整理成一段"截至目前我们达成了什么共识"的摘要。后面的人只需要看这个摘要，不需要翻前面几十页的逐字记录。

AI 也可以做类似的事：定期把累积的上下文压缩成摘要，用更短的文本保留核心信息。

4. 分开放（Isolate）—— 各管各的，互不干扰

一个托盘塞不下所有菜，那就多找几个服务员，每人端一个托盘，各管几道菜。

在 AI 的世界里，这就是"多智能体"（Multi-Agent）架构：把复杂任务拆成几个子任务，让不同的 AI 各自处理自己那一摊，各有各的上下文窗口，互不干扰。最后再把结果汇总起来。

---

五、上下文工程的"甜蜜点"

好的上下文工程，既不是越少越好，也不是越多越好。它追求的是一个"甜蜜点"（Sweet Spot）——信息量刚好足够 AI 做出准确判断，又不至于让它 overwhelmed。

找到这个甜蜜点，需要考虑几个因素：

信息的时效性 —— 最近发生的事比远古的事更重要。把最新的信息放在上下文的末尾（因为 AI 对结尾更敏感），旧的信息压缩或移除。

信息的相关性 —— 跟当前问题直接相关的放进来，边缘相关的放外面备查，无关的坚决剔除。

信息的密度 —— 同样的意思，用更简洁的方式表达。去掉废话、重复和装饰，只保留核心事实。

结构化呈现 —— 把信息整理成清晰的格式（列表、表格、分层结构），比大段文字更容易让 AI 理解和使用。

---

六、为什么上下文工程突然火了？

上下文工程这个概念最近一两年才被频繁提及，不是因为以前不需要，而是因为两个变化：

第一，AI 的能力变强了。 早期的 AI 连基本的对话都磕磕绊绊，没人指望它能处理复杂的上下文。现在的 AI 聪明多了，能做的事情多了，人们开始意识到：限制 AI 发挥的往往不是它"脑子"不够好，而是"眼前"的信息没给对。

第二，应用场景变复杂了。 从简单的问答聊天，发展到需要查资料、调工具、多轮推理、长期记忆的复杂工作流。这些场景对上下文管理提出了更高的要求。

有句话说得好："Prompt Engineering 是怎么跟 AI 说话，Context Engineering 是给 AI 看什么。" 前者是话术，后者是策展。两者结合起来，才能真正释放 AI 的潜力。

---

七、小结

上下文工程的本质，是一门"信息策展"的手艺。它回答的核心问题是：在 AI 有限的"眼前"里，应该放什么、不放什么、怎么放。

就像那个餐厅服务员的托盘——好的服务员不会让托盘空着（客人会饿），也不会让它堆到溢出来（会打翻）。他会精心安排每趟端什么、先端什么、后补什么，确保每一道菜都在最合适的时候出现在客人面前。

AI 时代，我们每个人都可以成为这样的"信息策展人"。

---

*本文基于 easy-learn-ai 项目 9621a05 commit 中新增的"上下文工程"模块内容整理撰写。*

#easy-learn-ai #每日更新 #上下文工程 #ContextEngineering #记忆 #小凯