필사 모드: 上下文工程取代了提示词工程吗 — 哪些被测量过，哪些没有

• 引言 — 先说结论
• 这个术语是什么时候、从谁那里来的
• 一个表明这是两件事的测量
• 上下文窗口和有效上下文是两个不同的数字
• 那么 2026 年的模型解决这个问题了吗
• Lost in the middle 到底有多糟
• 那把上下文按逻辑整理好不就行了吗 — 测量结果反着来的地方
• 「注意力预算」是被测量过的概念吗
• Compaction 真的损失很小吗
• 那么该做什么 — 决策规则
• 什么时候上下文工程不是答案
• 结语
• 参考资料

引言 — 先说结论

「上下文工程取代了提示词工程」这种说法，最近经常见到。结论先行：不是替代，而是包含。而且这不是我的意见，而是传播这个术语的人亲手写下的句子。Karpathy 在定义上下文工程时，把它的组成部分列为「任务描述与说明、few-shot 示例、RAG、工具、状态与历史、compacting」 — few-shot 示例和任务描述，本身就是提示词工程。Anthropic 更是直接写道，「把上下文工程看作提示词工程的自然演进(natural progression)」。没有任何一手来源说过「已死」。那句话是从新闻标题里诞生的。

但如果在这里停下，就只对了一半。包含关系只是术语上的梳理，真正的问题是「那么到底有没有新东西要学」。这个问题可以用测量来回答 — 而答案是「有」。Chroma 在 2025 年 7 月做的实验最干净利落。同样的问题、同样的任务、同样的措辞原封不动，只改变了周围上下文的量(只装相关内容的约 300 token vs 连无关内容也一并塞进去的约 113k token)。18 个模型全部性能下降。提示词的措辞一个字都没改，数字却动了 — 那这就是一条提示词工程无从下手的轴。这就是这个术语挣来的价值。

这篇文章的目的，是拨开炒作，把被测量过的东西和未经测量就被反复重复的东西分开。上下文窗口本身的使用策略，已经在1M 上下文窗口时代的 LLM 使用策略一文里谈过；智能体记忆设计的实务模式，已经在上下文工程 — 为 AI 智能体设计记忆的方法一文里谈过。这里要做的，是审计(audit)那些文章当作前提铺在底下的证据本身。

这个术语是什么时候、从谁那里来的

按时间顺序整理如下。

• 2025 年 6 月 12 日 — Cognition 的 Walden Yan 发布「Don't Build Multi-Agents」。文中把上下文工程定位为提示词工程的「下一阶段」，定义是「在动态系统中自动地做这件事」。并且断言，这是构建智能体的工程师的「头号工作」。
• 2025 年 6 月 19 日 — Shopify CEO Tobi Lütke 在 X 上写道，「比起提示词工程，我更喜欢上下文工程这个术语」。他的定义是「提供全部所需上下文、让任务变得有望被 LLM 解决的技艺」。
• 2025 年 6 月 25 日 — Karpathy 放大了它。就是上面引用的那句话。
• 2025 年 6 月 27 日 — Simon Willison 引用这两条推文，写道「这个术语看来会留下来」。他的观察很有意思 — 提示词工程被大众误解为「把往聊天机器人里打字这件事叫得很气派的说法」，而上下文工程，大众按字面推出的意思会更接近本来想表达的意思。也就是说，这次术语更替的动机里，相当一部分不是技术，而是语感。
• 2025 年 7 月 17 日 — 整整一年前的今天，一篇通读了 1400 多篇论文的综述(arXiv 2507.13334)上线，这个术语获得了学术上的外形。
• 2025 年 9 月 29 日 — Anthropic 在工程博客发布「Effective context engineering for AI agents」。这是厂商正式采纳这个术语的时间点。

这里有值得留意的地方。Cognition 的文章比那些推文早了一周，而且三个来源(Cognition、Karpathy、Anthropic)各自独立给出了同一结构的定义 — 把提示词工程作为子集包含进来的上位概念。谁都没有说是替代。

一个表明这是两件事的测量

术语谱系到此为止，去看证据。有一个实验，把「上下文工程是一件不同的工作」不是用主张、而是用测量展示了出来：Chroma 的技术报告「Context Rot: How Increasing Input Tokens Impacts LLM Performance」(Hong、Troynikov、Huber，2025 年 7 月 14 日)。

核心设计是这样的。用一个叫 LongMemEval 的对话式 QA 基准测试，但把同一个问题用两种方式抛出。

Focused 条件:  问题 + 仅含回答所需的相关部分          -> 平均约 300 token
Full 条件:     问题 + 相关部分 + 全部无关内容          -> 平均约 113k token

问题相同。任务相同。提示词措辞相同。
变了的是: 相关信息的周围铺着什么、铺了多少。

结果，按 Chroma 的原话，是「在所有模型上，focused 提示词都比 full 提示词有显著更高的性能」。评估对象是包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3 在内的 18 个模型。

这为什么是决定性的 — 因为这个实验把提示词工程的变量全部固定住了。措辞、示例、指令都原封不动。提示词工程能碰的旋钮一个都没动，数字却动了。所以「上下文工程是提示词工程的重新包装」这个主张，被这一个实验就证伪了。反过来，「提示词工程已死」也不成立 — focused 条件下性能很好，说明提示词仍然在起作用。这两条轴是正交的。

也有要诚实附上的条件。作者们在 LongMemEval_s 里选用了 knowledge update、temporal reasoning、multi-session 这几个类别，滤掉了 38 个含糊或无法回答的提示词，留下 306 个。打分是 LLM 评判(LLM-as-judge)，作者们说明已将这一评判对人工判断做过校准(对约 600 条 LongMemEval 输出做了人工标注)。Chroma 是向量数据库公司，对「用检索缩减上下文」这个结论有利害关系，这一点也要计入。不过代码库是公开的，可以复现。

上下文窗口和有效上下文是两个不同的数字

写着「1M 上下文」的那个数字，是输入不被拒收的上限，不是性能得以维持的上限。正面测量这一点的是 RULER(Hsieh 等，arXiv 2404.06654，COLM 2024)。

RULER 的方法论很明晰。测 13 个任务的平均分，把 Llama2-7B 在 4K 处得到的 85.6% 当作基准线，将能守住这条线的最大长度定义为「有效长度(effective length)」。基准线的选取本身是任意的，但重要的是论文言明了这份任意并把它固定了下来。17 个模型结果的一部分如下。

论文的句子是这样的 — 「几乎所有模型都在到达其标称上下文长度之前跌破基准线」。LWM 标称 1M，却连在 4K 处都赢不了 Llama2-7B。也就是说，标称长度预测不了有效长度，甚至连排序都不保持 — 标称 1M 的 GradientAI/Llama3(有效 16K)比标称 128K 的 GPT-4(有效 64K)低了一大截。

这里必须附上的条件：这些是 2024 年的模型。所以「现在还是这样吗」是理所当然的问题，答案在下一节。

那么 2026 年的模型解决这个问题了吗

没有。最近一次测量它的是 ATLAS(arXiv 2605.28079，2026 年 5 月 27 日提交)。它在 8K 到 1M 的固定网格上，用 6,438 个实例评估了 26 个模型。

在 ATLAS 以作者自测报告的结果里，直接扎进实务的有两条。

第一，排名随长度翻转。作者们分别汇总了到 128K 为止和到 1M 为止的分数：7 个模型的排名移动了两位以上，个别排名差距最大拉开到 12 位。报告出的第一名也不一致 — 128K 处 Gemini-3.1-Pro-Preview 领先，1M 处 Claude-Opus-4.6 领先。这意味着，你看着 128K 基准测试挑出的模型，没有任何保证在 1M 处也是最优。

第二，检索做得好，不等于使用做得好。用摘要的表述是「强检索性能可能不会迁移到下游使用(downstream use)」，基础操作层与应用工作负载层只共享模型间方差的 61%。在这里不能把算术反过来说「那么其余的就会错」 — 这个数字说的是，两层的模型间性能变动有相当一部分指向不同的方向，因此不能拿一个 NIAH 式检索分数去替代应用性能的排名。作者们的结论是「不要只报一个头条分数，要按能力、按长度报告」。

ATLAS 还是未经同行评审的预印本，数字是作者自测。不过它公开了方法论(固定网格、基于 AUC 的分数、不确定性传播)，把下层组件做成了可审计的 — 它属于主动提高了自身可验证性的那一类。

从这里引出真正的元观点。同一现象在四个世代上得到复现。

2023  Lost in the Middle    GPT-3.5-Turbo, Claude-1.3 世代
2024  RULER                 GPT-4, Llama3.1, Qwen2 世代
2025  NoLiMa / Context Rot  GPT-4o, GPT-4.1, Claude 4, Gemini 2.5 世代
2026  ATLAS                 Gemini-3.1-Pro, Claude-Opus-4.6 世代

如果只是某一代的缺陷，等下一代模型把它修好就行。连续四代都如此，那它就不是等待的对象，而是设计的对象。这是上下文工程不止于流行语的唯一且充分的理由。

Lost in the middle 到底有多糟

这是被引用最多、也最常被抹平细节的论文。「Lost in the Middle: How Language Models Use Long Contexts」(Liu 等，arXiv 2307.03172，TACL 刊载)的实际主张是这样的。

把装着正确答案的文档放在上下文的开头或结尾，性能最高；放在中间，性能大幅下降。开头侧的偏置叫 primacy bias，结尾侧的叫 recency bias，两者合在一起画出一条 U 形曲线。

效应量很重要，论文明确写出的数字是这些：GPT-3.5-Turbo 的多文档 QA 性能可能下降 20% 以上，最坏情况下，20 个、30 个文档设定下的性能比一份文档也不给的时候(closed-book，56.1%)还要低。作为参照，只给那一份正确答案文档的 oracle 设定是 88.3%。

这句话的分量很容易被放过，请再读一遍。明明把装着正确答案的文档放进了上下文，位置不好时，还不如不放。「先全塞进去，让模型自己去找」为什么危险 — 这是最紧凑的反例。

论文同时报告了一个引用得更少、却更扎心的结果 — 扩展上下文模型与原始模型显示相同性能的情况很常见，作者们就此写道，「扩展上下文模型并不必然更善于使用输入上下文」。加大上下文窗口和用好上下文，是两件不同的事。

条件：这些是 2023 年的模型(GPT-3.5-Turbo、Claude-1.3)。所以不能把这些数字原样搬到 2026 年的模型上。但现象本身被复现了 — NoLiMa(Modarressi 等，arXiv 2502.05167)去掉了 needle 和问题之间的词汇重叠，让字面匹配无从下手，然后重新评估了 13 个标称 128K 以上的模型：在 32K 处，11 个模型跌到短上下文(不足 1K)基准线的 50% 以下。连位居前列的 GPT-4o 都从 99.3% 掉到 69.7%。作者们补充说，加上 CoT 提示或推理能力也挡不住这个下降 — 意思是，用提示词修不好。

那把上下文按逻辑整理好不就行了吗 — 测量结果反着来的地方

在这里，一条通念被打破。Chroma 比较了 haystack(无关的填充文本)结构的两种条件 — 保持原样、带逻辑连贯性的一组随笔 vs 把句子随机打乱、消除了局部连贯性的版本。按常识，整理得好的那边应该更好。

结果相反。在全部 18 个模型上，打乱过的 haystack 性能更高。Chroma 的解读是 — needle 插进一篇连贯的随笔时，按说它打断了逻辑流、应该更显眼，但实际反着运作。

这个结果要小心对待。这是关于周围填充文本的结构的实验，不是「把你的上下文洗牌」的处方。Chroma 自己也在局限一节里划了线 — 说他们解释不了为什么。但方向是清楚的。「把上下文整理得让人读着舒服，模型也会读得好」不是一个被验证过的命题。直觉被测量掀翻的点已经出现了一个，那么其余的直觉，在被测量之前也只是直觉。

「注意力预算」是被测量过的概念吗

从这里开始，也许是这篇文章里最值得引用的部分。上面那些现象后面通常跟着解释，而解释的地位与测量值不同。

Anthropic 的文章这样提出机制 — Transformer 中每个 token 都对其他所有 token 做注意力，n 个 token 就产生 n² 个成对关系，长度增加时，捕捉这些关系的能力会「被摊薄」；而且模型是在短序列更常见的训练分布里学到注意力模式的，对长程依赖的经验更少。「注意力预算(attention budget)」这个表述就出自这里 — 一个「每个新 token 都会消耗一点这份预算」的比喻。

有道理，方向大概也对。也要指出 Anthropic 做了恰当的对冲 — 他们写的是「不是硬性的悬崖，而是性能的坡度」，并明确说模型在长上下文下依然能干。但诚实地说，这是解释，不是测量。那篇文章里没有把 n² 项作为原因分离出来的实验(ablation)。「注意力预算」是把我们观察到的东西编进一个故事时用的比喻，不是能从仪表上读出来的量。

而且有一处是决定性的。实际测量了这个现象的一方 — Chroma — 在局限一节里这样写：本报告不解释性能下降的机制，对它为什么发生没有确定答案；要查明这一点需要机制可解释性(mechanistic interpretability)研究，超出了本报告的范围。

整理如下。

被测量的     : 输入变长时，性能非均匀地下降         (Chroma, NoLiMa, RULER, ATLAS)
被解释的     : n^2 注意力、训练分布、"注意力预算"    (厂商博客，无 ablation)
测量方的立场 : "为什么会这样，我们也不知道"          (Chroma 局限一节，明示)

现象是坚实的，机制是未解的。这个区分在实务上也重要 — 因为一旦把机制故事当成事实，就会想从它演绎出处方(「既然是 n²，减少 token 就会按平方变好吧」)。支撑这种演绎的测量并不存在。

Compaction 真的损失很小吗

上下文要溢出窗口时的标准处方是 compaction — 把对话做成摘要，用这份摘要开一个新窗口。Anthropic 的文章连 Claude Code 是怎么做的都讲了：把消息历史交给模型去摘要，保留架构决策、未解决的 bug、实现细节，丢弃重复的工具输出，再把最近访问过的 5 个文件一并传过去。

然后这样写道 — compaction 以「高保真度」压缩上下文窗口的内容，让智能体能以「最小的性能下降」继续。

支撑这句话的测量数据并未公开。保真度是多少、性能下降几个百分点、在哪个评估集上测的 — 都没有。同一篇文章也诚实承认 compaction 的风险(「过于激进的 compaction 可能失去那些事后才显出重要性的微妙上下文」)。但告诉你这个权衡位于何处的数字，没有。

Cognition 也一样。Walden Yan 建议放一个把历史压缩成关键信息的专用模型，写道「很难做对」，并披露 Cognition 实际微调了一个小模型。同样没有数字。他还坦率补充 — 即便如此，最终仍会撞上极限。

那么公开的数字有哪些。Anthropic 在 2025 年 9 月 29 日发布上下文管理功能时给出的，是唯一接近的数值。

这些数字是厂商自测，评估集没有公开。任务数量、基准线构成、方差 — 都没有写。原理上无法复现。

更重要的是，这不是 compaction 的数字。上下文编辑是把老旧的工具调用和结果从窗口里删掉，compaction 是把对话做成摘要。机制不同。可实务讨论里这两者经常被搅在一起，我见过「提升 39%」被当作 compaction 的证据来引用。不是的。

所以准确的句子是这个：整个行业都说 compaction 是必需的，但测过 compaction 摘要保真度的公开数字不存在。这不是指责，是一张地图 — 知道这里是空白再进场，你就会在自己的评估集上亲自测压缩前后，而不是借别人的数字。那是唯一诚实的路径。

那么该做什么 — 决策规则

我不打算用「视情况而定」收尾。从上面的证据里，可以直接推出一个顺序。

第 1 步：先测 focused/full 差距。把 Chroma 的实验设计原样复制即可。选出你的 30~50 个评估问题，分别跑 (a) 只放人工手选相关信息的版本和 (b) 实际流水线塞进去的完整上下文版本。这两个数字之差，就是上下文工程在你的系统里能挣回来的上限。

第 2 步：差距小就停。focused 和 full 差不多，说明模型把你的上下文用得不错。这种情况下，compaction、记忆层、图谱都不需要。回到提示词和任务设计。对大多数团队来说，在这一步停下就是正确答案。

第 3 步：差距大，先从检索下手。最大的杠杆永远是「无关的东西一开始就别放进来」。lost-in-the-middle 也好，context rot 也好，对没放进去的 token 不起作用。

第 4 步：用你自己的任务测有效上下文。厂商的标称长度是输入上限，不是性能上限。把 RULER 做的事做成缩小版 — 固定任务，只拉长度，画出曲线。正如 ATLAS 的结论，需要的不是单一分数，而是曲线。

第 5 步：compaction 放最后，而且一定测过再上。用同一个评估集跑压缩前后，亲自确认丢了多少。公开的参考数值不存在，所以这不是可选项，是必做项。

什么时候上下文工程不是答案

缺了这一节的文章，请不要相信。

• 上下文本来就短的时候。这些论文的效应量大多出现在 32K 以上。数千 token 的一次性分类、抽取、摘要，context rot 不是你的问题。提示词工程才是对的工具。
• 没有评估集的时候。没有测量的上下文工程只是品味。上面 5 步全部以「测」开头，不是偶然。第一件工作是建评估集，不是改上下文结构。
• 还没选定模型的时候。正如 ATLAS 的排名翻转所示，最优模型随长度区间而变。比起把上下文流水线做精，在你的长度区间里选一个更好的模型，可能收效更大。
• 问题其实在生成侧的时候。通读 1400 多篇论文的综述(arXiv 2507.13334)点出的不对称正是这个 — 模型在理解复杂上下文上很出色，但在生成同样精巧的长文上有明显局限。如果问题出在输出，那把输入策展得再精心也解不开。
• 多轮本身就是原因的时候。「LLMs Get Lost In Multi-Turn Conversation」(Laban 等，arXiv 2505.06120)用超过 20 万次模拟对话报告：在 6 个生成任务上，多轮性能比单轮平均低 39%(这个 39% 和上文 Anthropic 的 39% 毫无关系，是各自独立的数字)。作者们的分解很有意思 — 下降的大部分不是能力损失，而是不稳定性的增加。模型在开头几轮就妄下推断、急着奔向最终答案，然后对它过度依赖。一句话概括，「走错了路就回不来」。这可能是一个要靠重新开始对话、而不是把上下文填得更好来解决的问题。

结语

术语问题的答案很平淡。上下文工程没有取代提示词工程 — 是包含。造出它的人就是这么写的，「已死」这句话在任何一手来源里都不存在。

有意思的答案在其后。明明是包含关系，它配得上一个新名字吗 — 配。根据恰好只有一条，而这一条就足够：把提示词的所有变量固定住，只改周围上下文，性能也会动(Chroma 的 focused vs full)。这条轴在提示词工程的词汇表里不存在，所以需要一个名字。

而实际立在这个名字底下的证据，比想象的少。坚实的是现象 — 长度一拉长，性能非均匀地下降；标称长度不是有效长度；中间会消失；而这一切从 2023 年到 2026 年、跨四个世代得到复现。相反，机制(「注意力预算」)是比喻，处方的效应量(尤其是 compaction)大多没有公开数字。

这张地图给实务者的指引很简单。相信现象并把它反映进设计；不要从机制故事里演绎处方；不要借别人的处方数字来用。哪怕只测一个 focused/full 差距，30 分钟内就能分清这场讨论对你的系统有没有效。对大多数团队来说，正确答案是「这不是我们的问题」，而确认这一点的成本，比新建一条上下文流水线便宜得多。

参考资料

• Context Rot: How Increasing Input Tokens Impacts LLM Performance (Hong、Troynikov、Huber — Chroma 技术报告，2025-07-14)
• chroma-core/context-rot — 用于复现的代码库
• RULER: What's the Real Context Size of Your Long-Context Language Models? (Hsieh 等，arXiv 2404.06654，COLM 2024)
• Lost in the Middle: How Language Models Use Long Contexts (Liu 等，arXiv 2307.03172，TACL)
• NoLiMa: Long-Context Evaluation Beyond Literal Matching (Modarressi 等，arXiv 2502.05167)
• ATLAS: All-round Testing of Long-context Abilities across Scales (arXiv 2605.28079，2026-05-27)
• LLMs Get Lost In Multi-Turn Conversation (Laban 等，arXiv 2505.06120)
• A Survey of Context Engineering for Large Language Models (arXiv 2507.13334)
• Effective context engineering for AI agents (Anthropic 工程博客，2025-09-29)
• Managing context on the Claude Developer Platform (Anthropic，2025-09-29)
• Don't Build Multi-Agents (Walden Yan — Cognition，2025-06-12)
• Context engineering (Simon Willison，2025-06-27 — 引用 Lütke 与 Karpathy 的推文)
• 1M 上下文窗口时代的 LLM 使用策略(相关文章)
• 上下文工程 — 为 AI 智能体设计记忆的方法(相关文章)
• Context Window 100 万 token 时代：RAG 会消失吗?(相关文章)