上下文工程发展史：从资料输入到AI信息环境管理

引子：同一个问题，三个时代

假设你要让 AI 分析一份 200 页的上市企业财报，提取出值得关注的财务风险。

2022 年，你会把关键段落一个字一个字地复制粘贴进 ChatGPT 的输入框。如果财报有 200 页，你的做法是：先让 AI 看前 20 页，分析完，再喂 20 页，再分析……最后把几轮分析结果拼在一起。那时最大的瓶颈不是 AI 理解不了，而是你根本塞不进去。

2023 年，你有了更好的办法。你把 PDF 切片，存进向量数据库，写好检索逻辑。用户问一个问题，系统自动从向量库捞出最相关的几个文本块，拼进 prompt，发给 GPT-4。这时候你终于不用手工复制了，但整个流程是一个补丁摞着另一个补丁的产物——LangChain 套 Chroma，Chroma 套 OpenAI API，每个环节都可能出错，但至少能跑了。

2025 年，你对 AI 说一句话："分析这份财报，找出财务风险点，给出投资建议。" 系统自动启动了多条并行路径：一条去检索行业研报、一条去对比历史财报数据、一条去查最新的监管文件。检索结果经过语义去重和压缩、分派给不同 Agent 并行处理、每个 Agent 的输出再汇总到主 Agent 做综合判断。最后你拿到一份结构化的风险报告——这些背后，是一整套上下文流水线在工作。

同一个任务，三年的做法完全不同。变化的核心不是"AI 变聪明了"——GPT-4 在 2023 年就有了。真正改变的是你如何让 AI 看到它该看的东西。

这就是上下文工程（Context Engineering）的故事。

整篇文章中反复出现的"财报分析"场景，是贯穿三部曲的 running example——你在第一篇中看到了"怎么说"对它的影响，在这一篇中看到"让 AI 看什么"如何改变它，在第三篇中将看到 Harness 工程怎样为同样的任务铺上最后一道安全网。

一、2020-2022：被遗忘的序章

RAG：第一个把"查资料"和"写答案"串起来的人

2020 年 5 月 22 日，Facebook AI Research 的 Patrick Lewis 等人向 arXiv 提交了一篇论文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。

这篇论文提出的方案后来被称为 RAG（检索增强生成），结构听起来很直白：用一个 BART-large 模型（4 亿参数）做生成器，用 Dense Passage Retrieval（DPR）做检索器，从 Wikipedia 的约 2100 万文本块中检索相关信息。论文设计了两种模式：RAG-Sequence（同一篇文档生成全部输出）和 RAG-Token（每个 token 可以引用不同的文档）。

但真正的创新不在结构，而在于端到端联合训练——检索器和生成器一起训练，不需要人工标注"这段文本该从哪篇文档里找"。这意味着模型第一次学会了"遇到不懂的就先去查"——不是事后打补丁，而是训练时就把它作为核心能力。

注意一个时间：2020 年 5 月。当时 GPT-3 还没发布（GPT-3 论文是 2020 年 5 月底），ChatGPT 更是两年半以后的事。RAG 的思想诞生得极早，比后来几乎所有上下文工程实践都早——它像一个孤独的先行者，在还在讨论"few-shot prompting"的时代就提出了"让模型先查资料再回答"的范式。

GPT-3 和上下文学习的意外发现

2020 年 5 月底，OpenAI 发表了 GPT-3 论文 Language Models are Few-Shot Learners。1750 亿参数，生成能力让人惊叹。但当时有一个被很多人忽略的事实：它的上下文窗口只有 2048 token。

2048 token 是什么概念？约等于 1500 个英文单词、1000 个汉字。你连一个完整的 Wikipedia 条目都塞不进去。

但 GPT-3 带来了一个比参数规模更重要的发现：in-context learning（上下文学习）。你不需要微调模型，只需要在 prompt 里给几个例子，模型就能当场学会一个新任务。

这个发现暗示了一件大事：模型能从上下文中学习——前提是你有地方放这些上下文。而这个"前提"在接下来的三年里一直是最大的瓶颈。

ReAct：第一个推理-行动循环

2022 年，一篇论文为后来所有 Agent 框架打下了理论基础：ReAct: Synergizing Reasoning and Acting in Language Models。

它的核心设计是一个三段式循环：

Thought（思考）→ Action（行动）→ Observation（观察）→ 回到 Thought

模型先推理当前情况（"我需要查这份财报的负债率"），再执行一个动作（调用搜索引擎/数据库），然后观察返回结果，再决定下一步行动。

这个范式今天看起来似乎理所当然——所有 Agent 框架都这么做——但在 2022 年，它第一次把"思考"和"做事"合到了一起。此前的 prompt 工程只关注"怎么说"，ReAct 说的是"怎么说 + 怎么做"。

你去看今天 Claude Code 中的任务规划、LangGraph 中的 Agent 状态机、CrewAI 中的角色分工——它们的底层逻辑都来自 ReAct 的这个三段式循环。

这段时间的瓶颈：窗口太小

可以总结 2020-2022 年这段时间的核心矛盾：

这个时期就像一个婴儿在长牙——能力已经有了，工具还没跟上。变革在 2023 年到来。

二、2023：补丁之年——RAG 与框架大爆发

如果用一个词概括 2023 年，就是"打补丁"。窗口不够用？加检索。检索不准确？上向量库。编排太复杂？套框架。补丁摞补丁，没人看全景——但所有人都知道，旧世界已经不够用了。

LangChain：第一个把一切串起来的框架

LangChain 的故事从 2022 年 10 月的一场内部黑客松开始。Harrison Chase 在 Robust Intelligence 的活动中写出了第一个原型。当时的目标很简单：把 "prompt + LLM" 这个模式工程化。

但它真正的爆发在 2023 年。LangChain 是第一个提出系统化方案的框架：prompt ==> tools ==> memory 三者应该被串在一起，而不是让开发者每次都手工拼接。它的核心抽象很朴素：

• Prompt：模板化，注入变量
• Chains：把多个 prompt 调用串起来
• Agents：模型决定调用哪个 tool，然后观察结果，再决定下一步（ReAct 的实现）
• Memory：把对话历史持久化，让模型"记住"之前发生了什么
• Retrievers：从向量库或其他数据源检索相关文档

这些概念今天看起来平平无奇，但在 2023 年初，每个开发者都在手工写这些逻辑——而且是每个项目写一遍。LangChain 的意义不在于每个组件多精妙，而在于它第一次定义了"上下文流水线"这个概念本身。

LlamaIndex：绕开窗口限制的"树形索引"

比 LangChain 晚一个月，2022 年 11 月 5 日，Jerry Liu 把第一版代码推到了 GitHub，项目名叫 GPT Tree Index。

它的初始方案很特别——不是向量嵌入，而是树形索引：自底向上把文档分组，每个父节点用 GPT 摘要子节点内容；查询时自顶向下遍历树结构。目的只有一个：绕开 GPT-3 那可怜的 4096 token 窗口。

这是上下文工程历史上一个重要时刻：有人不再抱怨窗口太小，而是想办法在窗口限制下结构化信息。这是从"塞进去"到"管理好"的心态转变。

2023 年是 LlamaIndex 的起飞年：1 月登上 GitHub Trending，4 月公司注册，6 月获 Greylock 领投的 850 万美元种子轮，到 12 月一周年时拥有 450+ 贡献者和近 90 万月下载。

向量数据库井喷："语义搜索"成为标配

2023 年，Pinecone、Wea viate、Milvus、Chroma 等向量数据库集中爆发。与 2020-2022 年不同，2023 年的向量数据库不再是一个学术概念，而是变成了 RAG 流水线的标准化组件。

"语义搜索"取代了关键词搜索——这意味着检索不再依赖精确的词语匹配，"高负债风险"能匹配到"资产负债率偏高"、"杠杆水平令人担忧"等表述。对于财报分析这类自然语言密集的任务，这是一个跳跃式的提升。

但这里埋了一个伏笔：有了语义搜索，大家就开始疯狂往上下文里塞检索结果——"多塞一点总没错"。这个习惯在 2023 年末开始显露出问题，并在 2024 年集中爆发。

窗口军备竞赛拉开帷幕

2023 年也是上下文窗口军备竞赛真正开打的一年：

Claude 的 100K token 是第一个"认真对待大窗口"的决策。100K 约等于 7.5 万词——你可以把整本《哈利·波特与魔法石》塞进去。这在几个月前还是不可想象的。到 11 月，200K 出现了。

但有趣的是，这个窗口在 2023 年并没有多少人真正能用满——不是因为技术不行，而是因为管理大窗口的工具完全没跟上。你有了一个超大背包，但你不知道怎么整理放进来的东西。

OpenAI Function Calling：上下文不光是用来读的

2023 年 6 月，OpenAI 发布了 function calling。模型第一次能结构化地声明"我要调用什么工具、传什么参数"。

这件事在上下文工程上的意义被低估了。在此之前，上下文是单向的：你给模型信息，模型生成输出。Function calling 把上下文变成了双向的——模型不只从上下文中读取信息，还能通过上下文驱动外部动作：查数据库、调 API、写文件。

如果说 ReAct 定义了"思考-行动"的抽象范式，那 function calling 就是这个范式的第一个工程化实现。上下文从此不再是一个静态的"资料夹"，而是一个动态的"操作台"。

"Lost in the Middle"：一盆冷水

就在所有人都为大窗口欢呼时，2023 年 7 月，一篇论文给整个行业浇了盆冷水。

Stanford 的 Nelson F. Liu 等人发表 Lost in the Middle: How Language Models Use Long Contexts，揭示了一个让人不安的发现：模型的注意力曲线是 U 形的。它对最开头的信息（primacy bias，首因效应）和最结尾的信息（recency bias，近因效应）记得最牢，而中间部分的信息被系统性忽略——就像人看书，开头和结尾记得清楚，中间几章模模糊糊。

几个触目惊心的数据：

• GPT-3.5-Turbo 在信息位于上下文中间时，表现比不用任何文档还要差
• 把检索文档数量从 20 个增加到更多（后续工程实践验证了类似的规律），性能提升微乎其微——边际回报急剧递减

这意味着什么？你花大价钱检索了大量文档、塞满了上下文窗口，结果模型真正有效利用的只有开头和结尾的一小部分，中间的大量信息不仅浪费了成本，还可能干扰了模型的判断。更多不等于更好——位置比数量重要。

这篇论文是上下文工程从"堆砌"走向"管理"的转折点。它用数据证明了一件事：光有窗口不够，你需要信息编排。

2023 年的本质

站在 2023 年底回头看，这一年的所有创新——LangChain、LlamaIndex、向量数据库、function calling——都在回答同一个问题："怎么把更多东西塞进上下文，并让它正常工作"。但每个人都在自己的领地上打补丁，没有人看全景。

这套"补丁体系"勉强撑到了年底，但在 2024 年，新的 wa ve 让所有补丁都崩了——不是因为补丁不够多，而是因为上下文窗口突然大到不需要补丁了。

三、2024：膨胀之年——军备竞赛与框架井喷

如果 2023 年是"想塞但塞不进去"，2024 年是"塞得进去了，但里面一团糟"。

Gemini 和百万 token 时代

2024 年 2 月，Google 发布 Gemini 1.5 Pro，上下文窗口直接跳到 100 万 token（约 70 万词、1 小时视频、11 小时音频）。6 月，再翻倍到 200 万 token，并对所有开发者开放。

100 万 token 什么概念？你可以把整本《三体》三部曲几乎全部塞进去。而且不光是文本——Gemini 1.5 Pro 还能把视频和音频直接作为上下文的一部分。

这让 2023 年的窗口军备竞赛看起来像小孩子过家家。几个月前还在为 100K 欢呼，现在 200 万开放给所有人。

与此同时，Claude 3 系列（Sonnet/Opus/Haiku）在 2024 年 3 月发布，窗口稳定在 200K。Meta 的 Llama 3.1 在 7 月发布，窗口达到 128K。窗口军备竞赛的硝烟在 2024 年下半年渐渐散去——2M token 对大多数实际场景已经够用了。问题不再是"塞不进去"，而是"塞进去了然后呢"。

Agent 框架的爆炸

2024 年是 Agent 框架的"春秋战国"——LangGraph、CrewAI、AutoGen 等集中涌现，Anthropic 也发表了《Building Effective AI Agents》系统阐述长程 Agent 的设计原则。框架之间的底层逻辑惊人地一致：基本都是 ReAct 循环的某种变体 + 工具调用 + 状态管理。

但框架的繁荣带来了一个意想不到的副作用。当 Agent 真正跑起来执行多步任务时，上下文窗口在飞速膨胀。一个典型的多步 Agent 执行过程：

步骤 1：用户输入（500 token）
步骤 2：模型思考 + 工具调用 + 工具返回（3,000 token）
步骤 3：模型思考 + 工具调用 + 工具返回（4,000 token）
步骤 4：模型思考 + 工具调用 + 工具返回（5,000 token）
...
步骤 20：模型思考 + 最终输出（2,000 token）

每一步的工具返回结果（检索到的文档、数据库查询结果、API 响应）都堆在上下文里。20 步下来，上下文接近 10 万 token——而大部分内容可能是冗余甚至无关的。

三个新问题：膨胀、污染、腐化

在窗口不再是瓶颈之后，三个新问题浮现出来，它们构成了上下文工程的核心挑战：

上下文膨胀（Context Bloat）：Agent 执行几十步后，对话历史加上工具返回结果，总 token 数冲到几十万。你为每一次 API 调用付了钱，但其中相当大一部分是历史包袱。

上下文污染（Context Pollution）：无关信息混进上下文。Agent 在搜索过程中打开了 10 个网页，只有 2 个有答案，但其他 8 个的内容也留在了上下文里。这些噪音稀释了关键信号——模型在噪音中寻找答案，准确率和决策质量必然下降。

上下文腐化（Context Rot）：在极长的上下文中，信息会前后矛盾或逻辑断裂。前文说"公司负债率 60%"，后面某个工具返回的报告说"负债率 45%"——是时点不同、口径不同、还是某一份数据错了？模型没有能力判断，只能"平均"出一个可能不准确的结果。

这三个问题有一个共同根源：你给了模型太多信息，但没有任何机制帮模型分辨主次。当窗口很小的时候，你被迫筛选——所以问题不存在。当窗口大到什么都能塞进去后，筛选能力就成了瓶颈。

MCP 协议：标准化"工具怎么接入上下文"

2024 年 11 月 25 日，Anthropic 发布了 MCP（Model Context Protocol）。这是一个基于 JSON-RPC 2.0 的开放协议，目的是解决一个很具体的痛点：M 个 AI 应用要对接 N 个数据源和工具，每个组合都要写一套集成代码。

灵感来自 LSP（Language Server Protocol）。LSP 的解法是：每个语言实现一个 LSP 服务器，每个编辑器实现一个 LSP 客户端，M*N 的复杂度变成了 M+N——少了 M×N 那个乘法项。MCP 把同样的逻辑搬到了 AI 上下文管理上：每个工具和数据源实现一个 MCP 服务器，每个 AI 应用实现一个 MCP 客户端。

这件事在上下文工程历史上的意义是：工具接入第一次有了标准。在此之前，你在 Claude Desktop 里对接 GitHub 是一套代码，在 Cursor 里对接 GitHub 是另一套——同样的工具，重复造轮子。MCP 让上下文工程从"作坊"走向"工厂"。

MCP 的发展也很快：2025 年 3 月 26 日的更新引入了 OAuth 2.1 认证和 Streamable HTTP 传输，从"技术预览"走到了"生产可用"。

Prompt Caching：经济学开始介入

2024 年 8 月，Anthropic 推出 Prompt Caching。原理很简单：对频繁重用的上下文部分做缓存，避免每次调用都重新计算注意力。这意味着如果你有一个很长的 system prompt 或者一个重复使用的文档集合，你只需要为它付一次（完整费用），后续调用显著降低延迟和成本。

Google 在 2024 年末也推出了类似功能。

这看似只是一个定价策略的变化，但实际上它释放了一个信号：上下文已经从"一次性消耗品"变成了"可复用的资产"。当上下文可以被缓存、被管理、被复用，它就不再是一个简单的 prompt 前缀——它是一个需要被"工程化"的对象。

2024 年的本质

窗口军备竞赛在 2024 年告一段落。2M token 的通用窗口已经足以覆盖绝大部分应用场景。但行业突然发现：容器变大了，但你没有学会整理。2024 年的核心矛盾是——基础设施跑在了方法论前面：框架、协议、缓存这些"硬基建"已经就位，但怎么用好它们的"软知识"还散落在个体经验中。

膨胀、污染、腐化——这些词在 2024 年被反复讨论，因为它们精确地描述了当时的窘境。所有人都感受到了痛，但还没有一套系统的方法论来化解。当时的方法论散落在各种会议 talk、技术博客、开源项目的最佳实践中——它们是隐性知识，存在于人的经验里，但没有被命名、被记录、被系统化。

命名发生在 2025 年。

四、2025：正名之年——方法论收敛与框架命名

2025 年是上下文工程"定名"的年份。一套在 2020-2024 年逐渐形成的隐性知识，在这一年被明确命名、结构化，变成了可教授、可复用的工程方法论。

一个词诞生了

2025 年 6 月 19 日，Shopify CEO Tobi Lütke 在 X 上发了一条帖子：

几天之内，AI 圈炸了锅。Andrej Karpathy 回应："+1"——然后补充了一句在后来被反复引用的定义：

这段话精准地打中了所有人的痛点。它不是学术定义，不是营销话术——它是一个做了很多年 AI 产品的人对自己日常工作的直觉性描述。

紧接着，2025 年 6 月 23 日，LangChain 的 Harrison Chase 发表了长文 The Rise of Context Engineering。一个做出了 LangChain（上下文工程基础设施的先行者）的框架作者，用一整篇文章来确认"是的，这就是我们在做的事，它终于有了名字。"

7 月，Hugging Face 的 Philipp Schmid 发表了详细的参考文章。第一篇学术综述 arXiv:2507.13334 也在这时候出现。

事情有了自己的名字之后，行业的反应速度超过了所有人的预期。到 2026 年，Gartner 将 Context Engineering 收入其 Hype Cycle，Manning 出版社正在撰写相关专著（作者 Boni García）。

Anthropic 的四操作框架

2025 年 9 月，Anthropic 发布了 Effective Context Engineering for AI Agents，提出了一个四操作框架，成为上下文工程的标准操作模型：

这个框架的优雅之处在于：它不是说"你应该用什么库"或"你应该调什么参数"，它说的是"你应该对上下文做什么"。它是一套操作语义，不是一个实现指南。

回到财报分析的例子：

• Write：先把关键财务指标摘出来写到一个 scratchpad 里，不要在每次 AI 调用时重复塞入完整的财务报表
• Select：从行业研报库中只检索与当前分析维度相关的段落，而不是把所有研报全文喂进去
• Compress：对检索到的多份研报做语义去重和摘要，避免"三份报告说同一件事但措辞不同"浪费大量 token
• Isolate：让一个 Agent 专注分析负债率、另一个 Agent 专注分析现金流、主 Agent 只读它们的结论——每个子 Agent 拥有独立、干净的上下文

这四个操作不是凭空造出来的。它们是 2020-2024 年所有打补丁经验的浓缩——是对那五年中每个人无意中就在做的事的显性化。

LangChain 1.0 Middleware：从参数堆砌到管道抽象

2025 年 9 月，LangChain 发布了 1.0 alpha 版本（10 月正式 GA），引入 Middleware 架构。它的核心设计是一个请求管道：

before_model → modify_model_request → [模型调用] → after_model

这意味着上下文的处理不再是"在每个 Chain 里手工调参数"，而是一个标准的中间件管道：

• before_model：在模型调用前准备和优化上下文（选择、压缩）
• modify_model_request：动态修改发送给模型的请求（注入 system prompt、调整参数）
• after_model：在模型返回后处理输出（写入持久化存储、触发下一步操作）

学术界入局：从工业实践到学术框架

2025 年 10 月，"Context Engineering 2.0"综述论文发表（arXiv:2510.26493），标志着学术界正式入局。在此之前，上下文工程的讨论几乎完全在工业界和开源社区中进行。学术界的进入意味着两件事：第一，这套方法论已经被认为足够重要，值得独立的学术研究；第二，方法论从"实践驱动"开始转向"理论化梳理"——这不是取代工业实践，而是为它提供更坚实的理论基础。

2025 年的本质

一句话概括：方法论从隐性知识变成了显性框架。上下文工程不再是"高手经验"——那些靠手感、靠多年实践才能养成的上下文直觉，正在被转化为可教授、可复用的工程操作。你可以在一周内学会 2023 年的开发者花了两年才摸索出来的上下文管理技巧——因为现在有了名字、有了框架、有了这套 Write/Select/Compress/Isolate 的操作语言。

五、结语：下一步是什么？

Harness Engineering：让模型不犯错，而不只是让模型更好

2025 年末到 2026 年初，一个新概念开始浮现：Harness Engineering。

Mitchell Hashimoto（Terraform 的创始人）给出了一个操作性定义："每次发现 Agent 犯了一个错误，就花时间工程化一个方案，让它永远不再犯同样的错误。"

上下文工程回答的是"模型应该看到什么"。Harness Engineering 回答的是"系统应该阻止什么、度量什么、修复什么"——它是上下文工程的下一层。

用比喻来说：

• 上下文工程是给飞行员正确的地图和仪表盘——帮助模型做对
• Harness Engineering是给飞机装自动防撞系统——防止模型做错

2026 年 2 月，LangChain 在 Terminal Bench 2.0 上做了第一次大规模验证：不改模型权重，只改 Harness，分数从 52.8% 跃升到 66.5%，全球排名从第 30 名升至第 5 名。它证明了：环境的质量，在某种情况下，和模型的能力一样重要。

回到开头

还记得 2022 年那个做财报分析的你吗？把文本一段段复制进输入框，AI 每分析完一段你记一段笔记，最后手工拼成报告。

到了 2025 年，你只需要说一句"分析这份财报，找出风险点"，剩下的由上下文工程系统自动完成：多条并行检索路径、语义去重和压缩、多 Agent 分工处理、结果汇总和结构化输出。

你仍然在做同一个任务。变了的不是在对话框里打字的那几秒钟——变了的是一整条看不见的上下文流水线。

三部曲的中点

这篇文章是"AI 交互工程三部曲"的第二篇。这个系列的核心问题是：人怎么和 AI 合作？

《提示词工程简史》（第一篇）回答了"怎么说"——从"Let's think step by step"到结构化 prompt 模板，人类逐渐学会了用更精确的语言引导 AI。

本文（第二篇）回答了"让 AI 看什么"——那些上下文管理技巧不是凭空设计出来的，它们背后是一段从"塞不进去"到"塞进去了但一团糟"再到"有名字、有框架、有方法论"的演变史。

第三篇将回答"系统应该阻止什么"——《Harness 工程简史》。

Prompt 工程回答了"怎么说"，上下文工程回答了"让 AI 看到什么"，Harness 工程回答了"怎么防止做错"——三者合在一起，才构成完整的 AI 交互工程。

《提示词工程简史》 —— Prompt 工程回答了"怎么说"
《上下文工程简史》（本文） —— 上下文工程回答了"让 AI 看什么"
《Harness 工程简史》—— Harness 工程回答了"怎么防止做错"