上下文：AI理解世界的窗口
第 1 章：上下文：AI理解世界的窗口
1.1 什么是上下文——从人类工作记忆说起
想象这样一个场景：你在一个嘈杂的咖啡馆里和朋友聊天。当朋友说"就像上次我们去的那家店"时，你立刻知道他在说哪一天、哪家店、发生了什么事。但如果换一个完全不了解这段经历的人听到这句话，他只会觉得莫名其妙——因为他没有你们共同的经历作为背景。
这个"共同经历"就是上下文。它不是当前这句话本身，而是理解这句话所必需的背景信息。
人类的认知系统天生擅长管理和利用上下文。心理学家Miller在1956年提出的"魔法数字7"理论告诉我们，人类的工作记忆大约能同时处理7±2个信息块。但更重要的是，我们并不是孤立地处理每个信息块，而是将新信息与已有背景结合，形成连贯的理解。当你阅读一本小说时，即使某个句子单独看有好几种理解方式，你也能凭借前文上下文自然地选择正确的那种解释。
这种能力看似平常，实则极其复杂。当你听到"她把球扔了出去"时，你知道"她"指的是谁，"球"是什么类型的球，"扔出去"是往哪个方向。这些信息几乎全部来自上下文——来自前文的描述、你对这个世界的认知、以及此刻的对话情境。
大语言模型的工作方式与人类惊人地相似。GPT、Claude、Gemini这些模型在处理输入时，并不是在真空中理解每个词语，而是将输入文本与一段"工作记忆"结合——这段工作记忆就是上下文（Context）。模型会根据上下文来决定如何回应、回应什么、回应得是否准确。
举一个具体的例子。当你向ChatGPT提问"如何修复这个问题"时，模型并不是在真空中回答这个问题。它会参考：
- 你之前的所有对话历史
- 你粘贴进来的代码或文档
- 你描述的具体情境
- 某些情况下，你所在的专业领域背景
这些信息组合在一起，就构成了回答问题所需的上下文。没有足够的上下文，模型就像一个被蒙住眼睛的专家——有知识，但不知道该用哪部分知识。
上下文的本质是什么？ 它是模型处理当前任务时依赖的相关信息。这个定义看似简单，却包含了三个关键维度：
第一，相关性。上下文不是越多越好，模型需要的是与当前任务相关的信息。一段关于烹饪的对话历史，对于解决编程bug毫无帮助，反而可能造成干扰。
第二，可访问性。上下文必须是模型能够"看到"的信息。这里就引出了一个关键概念——上下文窗口（Context Window），它指的是模型在一次处理中能够纳入的最大文本量。超出这个窗口的信息，模型就"看不见"了。
第三，动态性。上下文不是固定不变的。每一次新的输入都可能改变上下文——旧的背景信息可能被新的信息补充、修正，甚至完全替换。
理解了这三个维度，你就理解了为什么上下文工程如此重要——它本质上是一门关于如何管理"模型能看见什么"的技术。而"模型能看见什么"，直接决定了"模型能做什么"。
1.2 上下文窗口：技术的边界与突破
让我们把时间拨回到2019年。那时候的大语言模型上下文窗口普遍很小——BERT的上下文是512个tokens，GPT-2是1024个tokens。所谓tokens，你可以简单理解为文字被切分后的最小单元，大约相当于0.75个英文单词或1-2个中文字符。
这意味着什么？当时最先进的模型，一次对话最多只能"看见"大约一千个词的文本。这相当于一本短篇小说的长度。对于简单的问答任务这足够了，但想让它分析一份完整的商业报告？不可能。想让它记住一整天的对话历史？做不到。想让它处理一段长篇代码？超出限制。
这种限制有一个形象的比喻：想象你是一个记忆力极其有限的人，每次只能记住一页纸的内容，然后这一页纸就会消失，你要重新开始。在这种条件下，你能做的事情非常有限——你可以回答简单问题，但无法进行复杂的推理和多步骤的分析。
上下文窗口的发展史，就是一部不断突破这个"记忆极限"的历史。
2020年，OpenAI发布GPT-3，将上下文窗口提升到2048个tokens（约1500个英文单词）。这让模型能够处理更长的文档，生成更连贯的对话。但2048仍然是个相对较小的数字——一封长邮件就可能占去一半。
2021年到2022年间，模型上下文窗口开始快速扩张。Anthropic的Claude 1达到了9000 tokens，OpenAI的GPT-4达到了32,000 tokens（约25,000个英文单词或3万多个中文字符）。这个量级已经相当于一本书的一章或者一份中等长度的研究报告。
2023年，竞争进一步白热化。Claude 2将窗口扩展到100,000 tokens，能够一次处理整本书籍。Google的Gemini 1.5 Pro达到了100万个tokens的惊人规模，相当于可以同时阅读十几本书籍的核心内容。
让我们用具体数字来感受这个演进：
| 模型 | 发布时间 | 上下文窗口 | 相当于 | |------|----------|------------|---------| | GPT-2 | 2019 | 1,024 tokens | 一篇短文 | | GPT-3 | 2020 | 2,048 tokens | 一页报纸 | | GPT-4 | 2023 | 32,000 tokens | 一章书 | | Claude 2 | 2023 | 100,000 tokens | 一本书 | | Gemini 1.5 | 2024 | 1,000,000 tokens | 一个小型图书馆 |
这个表格里的数字变化，反映的不仅是技术进步，更是能力边界的根本性改变。当你只能处理一本书的一章时，你能做摘要、写评论；当你能够处理整本书时，你可以做跨章节的对比分析、主题归纳；当你能够处理一个图书馆时，你可以做某个领域知识的综合判断和复杂推理。
但上下文窗口的扩大并非没有代价。有三个核心挑战随之而来：
计算成本问题。 模型的计算复杂度通常与上下文长度的平方成正比。处理100,000个tokens的计算量，大约是处理10,000个tokens的100倍。这意味着更大的上下文窗口意味着更高的延迟和成本。
注意力分散问题。 当上下文变得很长时，模型需要在更多信息中"寻找"与当前任务相关的部分。这就像在一本厚书中找一个特定的引用——信息越多，找到真正有用的部分越困难。研究表明，当上下文长度超过一定阈值后，模型对上下文中部信息的召回能力会显著下降。
质量衰减问题。 不仅仅是"找不到"，有时候模型会"找错"。长上下文容易被无关信息稀释，导致模型在回答关于"长上下文开头部分"或"中间部分"的问题时，准确率明显低于关于"结尾部分"的问题——因为结尾离模型"更近"，受到更多"关注"。
这三个问题催生了上下文工程作为一个独立领域的必要性。上下文工程要解决的不仅是"能不能处理"的问题，更是"处理得好不好"的根本挑战。
一个100万token的上下文窗口是强大的，但如果你不知道如何在这样的窗口中组织信息、强调关键内容、过滤干扰噪音，那么这个窗口可能反而成为负担——模型会在无关信息中迷失，消耗大量计算资源却得出次优答案。
上下文窗口的扩大是必要条件，而非充分条件。真正的工程挑战在于：如何在这个更大的舞台上，精准地"编排"模型的视野，让它看到该看的，忽略该忽略的，理解该理解的。
1.3 上下文如何塑造AI能力
上下文对AI能力的影响是全方位的。让我通过几个关键场景来揭示这种影响的机制和深度。
推理能力的上下文依赖
大模型的一个核心能力是链式推理（Chain-of-Thought Reasoning）——将复杂问题分解为多个步骤，逐步推导出答案。但这个能力高度依赖上下文。
考虑一道数学题："小明有5个苹果，他吃掉了一些，现在还剩2个。他又买了3个，现在他有多少个苹果？"这个问题的解答需要三个步骤的推理，但每一步都依赖前一步的结论。如果上下文窗口在推导过程中丢失了之前的信息，模型就会"失忆"，无法完成连贯的推理。
更复杂的推理场景会涉及更长的上下文依赖链。比如在编程问题中，理解一个函数的功能可能需要查看它的调用者、调用者的调用者、以及相关的全局状态。如果上下文窗口太小，或者信息组织不当，模型就无法建立这种跨距离的关联，导致"管中窥豹"的局部理解。
研究表明，当问题的推理链超过模型上下文窗口的某个比例时，模型性能会急剧下降。这不是模型"笨"，而是它"看不见"完整的推理路径。就像一个人试图根据半张地图规划路线，无论他多聪明，都无法到达目的地。
问答系统的上下文敏感性
简单的问答系统看起来不依赖上下文——用户问"法国的首都是什么"，模型直接回答"巴黎"。但真实的问答场景要复杂得多。
同样是"这个项目的进度如何"这个问题，如果缺少上下文，模型只能给出通用性的回答："项目进度取决于具体阶段，通常包括计划、执行、监控等环节。"这种回答虽然"正确"，但毫无价值。真正有价值的回答需要上下文：项目名称是什么？当前处于哪个阶段？遇到了哪些问题？需要什么样的资源？
一个高质量的问答系统，其核心能力不是"知道答案"，而是"知道在什么上下文中寻找答案"。模型需要理解用户的问题是在什么情境下提出的，需要什么样的背景信息来缩小答案范围，以及如何将背景信息与问题结合形成精确回答。
在实践中，问答系统的质量瓶颈往往不在于模型本身的知识储备，而在于上下文构建能力。给模型提供错误或不完整的上下文，就像让一个专家在错误的档案室中查找资料——他知道怎么找，但被误导了方向。
对话系统的上下文维护
多轮对话是上下文价值的集中体现。在单轮对话中，上下文主要是用户当前的问题；在多轮对话中，上下文还包括之前的交互历史。
考虑这个对话片段：
- 用户：我想学习Python编程
- 助手：太好了！Python是一门适合初学者的编程语言。你有编程基础吗？
- 用户：我是大学生物专业的
- 助手：了解了。生物专业经常需要处理实验数据和做可视化分析，这些场景Python都很擅长。你更感兴趣的是数据分析还是生物信息学方向？
- 用户：数据分析
在这个对话中，每一轮的回答都基于之前的上下文：第一轮回答基于"用户想学Python"这个初始信息；第二轮回答结合了"用户是生物专业"这个新信息；第三轮回答综合了所有前面的信息并做出了更具体的推荐。
如果没有上下文维护，这个对话会变成：
- 用户：我想学习Python编程
- 助手：Python是一门适合初学者的编程语言...
- 用户：我是大学生物专业的
- 助手：作为大学生物专业的学生，你有很好的发展前景...
- 用户：数据分析
- 助手：数据分析是很有前景的领域...
每一轮都像是在和"失忆"的模型对话，用户体验大打折扣。更严重的是，在需要跨轮次推理的场景中——比如"根据我们刚才讨论的生物专业背景，你应该推荐什么学习路径"——没有上下文维护能力的模型将完全无法应对。
上下文在复杂任务中的综合作用
让我们把视角拉高，看看上下文在复杂任务中的综合作用。以一份软件代码审查任务为例：
模型需要处理的上下文包括：代码仓库的结构和架构设计文档、待审查代码的具体内容、相关的测试用例和运行日志、项目的代码规范和风格指南、历史上的类似问题和修复方案、审查者的专业背景和关注点...
这些信息源中，每一项都可能包含数百甚至数千个tokens。要在这样的信息海洋中做出高质量的代码审查，模型需要：
1. 理解整体架构和设计意图 2. 理解待审查代码的功能和逻辑 3. 将代码与规范进行对比 4. 识别潜在的bug、性能问题、安全风险 5. 考虑与整个系统的交互影响 6. 给出具体、可操作的改进建议
任何一个环节的上下文缺失都会导致审查质量的下降。没有架构文档，模型可能不理解代码的设计意图；没有风格指南，模型无法判断是否符合项目规范；没有历史问题记录，模型可能重复指出已经被讨论过的问题。
这个例子告诉我们，上下文不仅仅是"背景信息"，它是AI能力得以发挥的基础设施。当基础设施薄弱时，即使是最先进的模型也只能发挥有限的能力。
1.4 上下文工程：让AI"看见"正确的事
从上面的分析中，我们可以清晰地看到一个模式：模型的最终表现，很大程度上取决于我们给它提供了什么样的上下文。就像一个才华横溢的演员，如果拿到的是混乱的剧本，也无法奉献精彩的表演。
这就催生了一个新兴的工程领域——上下文工程（Context Engineering）。
上下文工程不是简单地"塞入更多信息"。它的核心问题有三个：
信息筛选：什么信息是真正相关的？什么信息可能干扰判断？如何在有限的上下文空间中保留最有价值的内容？
结构组织：信息应该如何排列？重要信息应该放在什么位置？不同来源的信息如何整合？
动态管理：随着对话的进行，上下文如何更新？何时需要"遗忘"旧信息？何时需要"强化"关键信息？
这三个问题没有标准答案，需要根据具体任务、具体模型、甚至具体的提问方式来灵活处理。但通过系统的研究和实践，社区已经形成了一些重要的原则和模式。
原则一：上下文的相关性比完整性更重要
初学者常犯的错误是试图在上下文中包含"所有可能有用的信息"。他们会粘贴大量的文档、代码、日志，期望模型能够从中找到有用的部分。但这种做法往往适得其反。
原因在于，虽然模型的上下文窗口很大，但它的"有效注意力"是有限的。当上下文中有太多无关信息时，有用的信息反而可能被稀释。此外，模型在处理长上下文时需要消耗更多计算资源，如果资源被无关信息占用，真正重要的信息反而得不到充分处理。
一个更好的策略是精挑细选。只包含与当前任务直接相关的信息，用简洁明确的语言描述背景，删除任何可能被解释为干扰的内容。如果不确定某段信息是否相关，宁可暂时排除，在需要时再补充。
原则二：信息的位置影响模型的关注度
模型对上下文中不同位置的信息，关注程度是不均匀的。一般而言，开头和结尾的信息更容易被记住和关注，而中间的信息相对容易被忽略。这被称为"位置偏差"。
这个发现对上下文工程有重要启示：最重要的信息应该放在上下文的开头或结尾；次要的信息可以放在中间；如果有多个同等重要的信息点，可以考虑用某种结构让它们都"靠近"边界。
在实践中，这意味着当你有一段很长的参考文档时，把最核心的结论或要点放在开头可能比放在结尾更有效；当你需要模型记住多个关键点时，将它们分散在开头、中间、结尾可能比集中在一起更容易被全面覆盖。
原则三：明确的结构优于隐含的上下文
当你向模型提供上下文时，不要假设它能够自动理解你组织信息的逻辑。如果你希望模型理解A、B、C三段文本的关系，明确说明它们之间的关系："A是B的前提条件，C是A和B的应用场景"。
这种明确的结构说明有几个好处：减少模型推断的认知负担；避免模型做出错误的关联；让模型能够更精准地定位和利用特定信息。
原则四：上下文需要随任务演化
上下文不是一次性设置好就固定不变的。在复杂任务中，随着探索的深入，需要不断调整上下文：添加新发现的重要信息、删除已过时的背景、重新组织信息结构以适应新的任务方向。
这种动态管理要求我们对任务有清晰的理解，知道什么时候上下文需要更新，以及如何更新。一个好的上下文工程实践者，会在任务进行过程中持续监控上下文的有效性，并在必要时做出调整。
这些原则构成了上下文工程的基础。但真正的挑战在于应用的灵活性——同一个任务，不同的人可能会设计出完全不同的上下文方案，每个方案都有其合理性。上下文工程既是一门技术，也是一门艺术，需要经验、直觉和持续的迭代优化。
接下来的章节中，我们将深入探讨上下文工程的各种技术手段、设计模式，以及在不同场景下的最佳实践。届时你会看到，如何将"给AI一个剧本"这件事，从凭感觉行事提升到系统化、工程化的层面。
1.5 本章小结
让我们回顾这一章的核心洞察。
上下文是AI理解世界的窗口。 就像人类依赖工作记忆来理解当前情境一样，大语言模型依赖上下文来处理和回应输入。上下文是模型处理当前任务时依赖的相关信息——不是越多越好，而是越精准越好。
上下文窗口定义了模型的"视野边界"。 从2019年的1024 tokens到2024年的100万 tokens，上下文窗口的扩张从根本上改变了AI的能力边界。但更大的窗口不等于更强的能力——注意力分散、质量衰减、计算成本等问题随之而来。真正的工程挑战在于：如何在这个更大的舞台上精准地编排模型的视野。
上下文直接影响推理、问答、对话等核心能力。 推理需要完整的上下文链，问答需要相关的背景信息，对话需要跨轮次的记忆维护。在复杂任务中，上下文的质量直接决定了输出的质量。
上下文工程是让AI"看见"正确事物的技术。 它包括信息筛选、结构组织、动态管理三个核心问题。基本原则是：相关性优先于完整性；位置影响关注度；明确的结构优于隐含的上下文；上下文需要随任务演化。
写到这里，一个比喻已经呼之欲出：大模型就像一位才华横溢的演员，而上下文就是它的剧本。一出好戏需要好剧本，一个好演员拿到烂剧本也难以发挥；反之，给定一个精心编排的剧本，即使普通的演员也能奉献精彩的表演。
上下文工程的核心任务，就是为AI编写最好的"剧本"——让它能够看到该看的、理解该理解的、发挥出它应有的能力。
在接下来的章节中，我们将从"剧本"的各个要素开始，系统地学习如何构建高质量的上下文。从最基础的提示词设计，到复杂的多模态信息整合；从静态的上下文构建，到动态的上下文管理；从单个模型的使用，到多智能体系统的协作。每一章都将深化我们对"如何让AI正确理解这个世界"的理解。
准备好了吗？让我们继续这场关于上下文的探索之旅。