什么是上下文工程？
2025 年 6 月，Anthropic 发了一篇文章叫《Effective Context Engineering for AI Agents》。同一个月，Andrej Karpathy 在推上说了一句话：“Prompt Engineering is dead, long live Context Engineering.”
这句话在国内被翻译成了各种版本，“Prompt 工程已死”、“别再卷 prompt 了”、“未来属于上下文工程”。
但 Anthropic 原文的说法要冷静得多——prompt 仍然是 context 工程的子集，两者之间没有谁会替代谁。上下文工程不是推翻 prompt engineering，是在它的基础上把视野放大：从prompt engineering关心的"怎么跟模型说一句话"，切换到关心"模型在整个任务周期里看到了什么、什么时候看到、看到多少"。
理解这个切换的关键，得先搞清楚一个问题：上下文窗口越来越大，为什么还需要"工程化"上下文？
- Context Rot：大窗口不等于不用管
到 2026 年，模型的上下文窗口已经大得离谱了。Claude 支持 200K，Gemini 2.5 Pro 标称 1M tokens。1M tokens 什么概念？把一整本《三体》塞进去还有富余。
多数人的直觉是：窗口大了，就把所有东西无脑丢进去，反正装得下。
Chroma 团队在 2025 年做了一个叫《Context Rot》的实验，把这种直觉证伪了。他们在传统 NIAH（大海捞针）测试的基础上多加了几个变量，测试目标不再是简单的"能不能在干草堆里找到针"，而是考察语义理解层面的捞针能力——问的不是"那句话原文是什么"，是"那句话意味着什么"。
实验结论很清晰：
上下文越长，模型完成同样任务的质量一定下降。 这个下降不是缓慢线性的，过了一个拐点后加速恶化。
干扰很致命，但方式和你直觉想的不一样。 当"针"在语义上和周围的"干草"很接近的时候——比如一篇关于写作建议的文章里夹着"最佳写作建议是每周写作"，周围十篇也都是写作建议——模型反而不容易找对。当"针"和干草的主题格格不入时——量子物理文章里突然夹一句写作建议——模型更容易抓住。
这说明一个问题：上下文窗口是一个有边际递减效应的有限资源。最大窗口 ≠ 最佳注意力窗口。
Gemini 2.5 Pro 标称 1M tokens，实测到 4 万 tokens 左右就开始推理变慢，响应质量下降。这个现象有个名字——Context Rot，上下文腐烂。
类比很好理解：人看一篇一万字的长文，和看十篇一千字的短文提取关键信息，后者准确率更高——即使一万字完全在人的阅读理解范围之内。注意力是稀缺资源，对人类和对模型都一样。
- 上下文工程的四件事
Anthropic 把上下文工程的策略归结为四类，但拆开看每类都不抽象，都能对应到具体的工具和代码。
2.1 选择（Selection）
不是所有背景信息都有用。上下文工程要做的第一件事，是根据当前任务意图，从海量数据中挑出最相关的那一部分。
举个例子：你让 AI Coding Agent 改一个 bug。它不应该拿到整个代码仓库的所有文件——只应该拿到相关文件、相关依赖链上的类定义、以及最近的 git diff。多给一条无关的代码文件，注意力就多稀释一层。
元数据在这里很值钱。文件名暗示用途，文件大小暗示复杂度，创建时间暗示相关性。把这些信息一起喂给上下文的筛选逻辑，比纯内容匹配准得多。
2.2 检索（Retrieval）
这一步超越了基础的向量搜索。单纯做 RAG 的 embedding 检索，召回量和准确率之间有一个很难跨越的 trade-off——召回多了噪音多，召回少了漏关键信息。
生产环境通常加两层：混合检索和重排序。
混合检索把关键词匹配和语义向量组合在一起，互补各自的盲区。关键词能抓到精确命中的技术术语（比如 “KeyError”、“OOM”），语义向量能抓到意思相近但不严格匹配的概念。
重排序的逻辑是先粗召回 100 条，再用一个轻量级的交叉编码器模型对这 100 条打分，选出最相关的 5 条。这个阶段的计算成本比直接在高维向量空间里做精确匹配低一个量级。
2.3 压缩（Compaction）
Claude Code 里有一个动作叫 /compact。触发时机是上下文快接近 Claude 的 200K 窗口上限了。触发后，模型会回看整段对话历史，做一次有损压缩：
- 保留的：整体计划决策、架构选择、未解决的错误、关键实现细节
- 扔掉的：冗余的工具调用输出、过细的中间步骤、重复确认
压缩完重新开一个干净的上下文窗口，把压缩后的总结作为新窗口的起点放进去。这相当于给 Agent 做了一次"垃圾回收"。
把历史的 150K tokens 压成 5K 的总结，一定会丢信息。工程上的挑战是控制"丢什么"——通过调整压缩 prompt 来控制保真度。先用"最大召回率"的目标写出第一版压缩提示词，再迭代着去掉总结中的冗余，在准确率和压缩比之间取平衡。
2.4 持久化（Persistence）
压缩解决的是"这一轮对话的上下文超限了怎么办"。持久化解决的是"跨对话、跨任务、跨时间的记忆存哪"。
最常见的落地形态是结构化笔记。Manus 的 todo.md、Claude Code 的 CLAUDE.md、MemU 等记忆框架，都属于这一类。Agent 定期把重要记忆——中间结论、待办事项、用户偏好、关键决策——写到外部文件里，后续推理时按需拉回来。
这种方式的成本极低，一个文件占几百 tokens。但它解决了一个关键问题：Agent 在长任务里不会"失忆"。
我在测试 Browser-use Agent 玩 2048 时做过实验。让 Agent 每步操作后往一个笔记文件里写心得——“固定一个角落放最大数”、“尽量往同一个方向合并”——下一轮开始前先看这个笔记。分数从 2000 左右跳到了 4000+。上下文没有变，但信息被组织过的形态进了窗口，效果就不同。
- 即时上下文：让 Agent 自己去拿
传统的 RAG 是在推理开始之前做一次批量检索，把检索结果塞进上下文，然后让模型基于这个静态上下文开始推理。
但人在回忆信息时也不是一次回想全部，然后开始想问题。人是先回想"这件事记在哪"，再去翻备忘录、找日历、打开对应的文件看细节。这是一个多步探索的过程。
即时上下文（Just-in-Time Context）就是让 Agent 模拟这个过程。Cursor 的做法是一个很直观的例子：Agent 拿到用户需求后，先读 readme.md 理解项目结构，再去 /components 目录找组件代码，最后到 /resources 目录找对应的图片。每一步的检索结果影响下一步去哪找。
这里面有一个容易被忽略的价值：即使检索到的文件名、大小、时间本身不是最终答案，这些元信息也帮助 Agent 在后续推理中判断什么信息重要、什么可以忽略。
什么时候用即时上下文，什么时候用预检索直接塞？一个实用的判断标准：交互成本高且上下文窗口吃紧的任务用即时上下文（AI Coding、Deep Research）；简单问答且对延迟敏感的任务用预检索。
- 多 Agent 作为上下文策略
多 Agent 架构的讨论主要集中在"任务分解"和"专业分工"这两个维度。但从上下文工程的角度看，它解决的是另一个问题：单个 Agent 的上下文窗口承受不了复杂任务的全部记忆需求。
一个 Deep Research 任务跑 30 分钟以上，产生的 context 轻松超 200K tokens。如果这些 context 全压在单个模型的一次推理窗口内，context rot 效应会把推理质量拉到很低。
多 Agent 的解法是把任务和记忆一起拆分。研究 Agent 只看自己检索到的论文和提取的摘要，写作 Agent 只看研究 Agent 产出的结构化结论，不对原始论文做二次阅读。每个 Agent 的上下文窗口只装自己那摊事，主 Agent 在高维度协调计划，不看执行细节。
Manus 的 Wide-Research 功能就是这个思路的落地：多个子 Agent 并行做研究，各自的上下文窗口独立管理，最后汇总时只传结论不传过程。
- 和 Prompt Engineering 的边界在哪
这两个概念的关系经常被简单对立为"新替代旧"。更准确的关系是：
Prompt Engineering 管的是指令层——怎么跟模型说清楚"要做什么"。
Context Engineering 管的是数据层——模型推理时"能看到什么信息"、信息以什么密度、什么顺序、在什么时机进入窗口。
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | 指令格式、语气、Few-shot | 背景数据、检索精度、信息密度 |
| 主要挑战 | 模型对措辞敏感 | Token 窗口限制、检索噪音 |
| 代表技术 | CoT、Few-shot、结构化 Prompt | RAG、重排序、压缩、持久化 |
| 产出 | 一段文本指令 | 一套动态筛选和注入系统 |
系统提示词是这两层交汇的地方。system prompt 本身靠 prompt engineering 写，但它也是 Agent 的初始上下文，决定了 Agent 在整个生命周期里怎么处理后续注入的 context。
- 三条起点建议
上下文工程的完整理论体系很大，但起步不需要全做。
先把系统提示词写好。 用最聪明的模型写出一版最小化 prompt——只定义"有什么、做什么"，不先定义"怎么做"。测试，发现问题，迭代加必要的指令。Anthropic 的建议是：少用 Few-shot，尤其不要在推理模型里堆示例。示例加多了，输出形式会僵化。
把上下文当有限资源管。 每往窗口里加一条信息，问问自己这条信息对当前推理有没有直接价值。并不是"塞得下"就该塞。
给 Agent 配一个外部记忆机制。 不管是一个 todo.md 还是 CLAUDE.md，让 Agent 有一个地方记录它推理过程中的关键决策和发现。这一步的工程成本很低，但能解决"长任务跑到后期 Agent 忘了前期做过什么决定"这类问题。
- 收尾
上下文工程 2025 年下半年开始成为一个独立的概念，根子上是 Agent 变复杂了。单轮对话的场景里，prompt engineering 把指令写好就能拿到不错的结果。但 Agent 的多轮推理、工具调用、跨任务记忆，把上下文的复杂度推到了需要工程化设计的程度。
它把视角从"我怎么跟模型说"拉到了"模型在这个任务全程看到什么"。
Anthropic 原文里的最后一句话概括得很准：
Context engineering is the practice of finding the context configuration most likely to produce the results you want.
翻译过来：上下文工程，归根到底是一件事——为每次推理，找到那组最小但最有用的信息。
这个逻辑不新鲜，决策论、信息论里都有类似的框架。新鲜的是，当模型的推理能力和窗口大小发生了量级跃迁之后，信息的筛选和编排本身变成了核心竞争力。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
0
0- 0
已为社区贡献219条内容
所有评论(0)