Context 不是 Prompt：为什么「上下文工程」正在成为 AI 的新地基

「与其说我们在写提示词，不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签，而我们真正在做的，是装修。」

如果你在 2024 年问我「怎么用好 AI」，我大概率会跟你聊提示词：怎么写指令、怎么设定角色、怎么给例子。但如果你今天再问我同一个问题，我的回答会完全不同。

因为这一年里，一线工程实践已经悄悄换了一个词——Context Engineering（上下文工程）。它不是提示词工程的升级版营销话术，而是一次重心的真正迁移：从「怎么把一句话写好」，转向「怎么决定模型在每一次推理时究竟看到什么」。

这篇文章想做两件事。第一件，用逻辑核把这门正在成形的学科拆开：它到底是什么、和提示词工程的边界在哪、有哪些已经在生产环境跑起来的设计模式。第二件，用感性核回到我自己——作为一个把 AI 当成环境而非工具、坚持 local-first 的人，我为什么认为上下文工程的尽头，是一条叫「世界线」的东西。

一、先把边界划清楚：Prompt 与 Context 不是同一件事

最容易混淆的，是把上下文工程当成「提示词工程的高级版」。它们确实相关，但不是同一层的东西。

Anthropic 在它那篇被广泛引用的工程文章里给了一个干净的区分：提示词工程是「编写和组织 LLM 指令的方法」；而上下文工程是「在 LLM 推理过程中，对最优 token 集合进行筛选与维护的一整套策略」——这个集合包括系统提示、检索到的文档、对话历史、工具定义、记忆，以及所有可能落进上下文窗口、但不属于「提示词」的信息。¹

Andrej Karpathy 在 2025 年 6 月那条被反复转发的推文里说得更直白：「+1 支持用『上下文工程』取代『提示词工程』……这是一门精细的艺术与科学：用恰好正确的信息，填满下一步所需的上下文窗口。」²

而 Sourcegraph 在 2026 年的实践文章里，给了一个我特别喜欢的、可操作的判据：

「如果你在替换名词和形容词，你还在做提示词工程。如果你在改变 agent 检索什么数据、以什么顺序、用什么重排、以及当窗口被填满时淘汰什么——你在做上下文工程。」³

重心从「措辞（wording）」转向了「布线（wiring）」。 这一句话，是我读完所有材料后觉得最值得记住的。提示词工程关心的是字面；上下文工程关心的是管道——数据从哪进来、经过哪些处理、在窗口里待多久、什么时候被踢出去。

这不是文字游戏。当你的 agent 只是一个单轮聊天框时，写好一句话几乎就是全部工作。但一旦它有了工具、有了记忆、有了检索层，写提示词就只剩下整个系统里很小的一块；剩下的全是围绕它的上下文工程。

二、为什么是「工程」：上下文是有限资源，而且会腐烂

把它叫「工程」而不是「技巧」，是有硬道理的。因为上下文窗口不是一个越大越好的容器——它是一种有限资源，且边际收益递减。

Anthropic 的原话是：「上下文必须被当作一种有限资源来对待，它的边际收益是递减的。」以及——「好的上下文工程，意味着找到那个信息量最高的、最小的 token 集合，去最大化某个期望结果的可能性。」¹

支撑这个判断的，是一个叫 Context Rot（上下文腐烂） 的现象：随着上下文窗口里 token 数量的增加，模型从中准确召回信息的能力反而下降。¹ 这背后有一个「注意力预算」的论证——注意力是 n² 的两两关系，窗口越长，每个 token 能分到的注意力越稀薄；Chroma 那份针对性的「针在草堆里」基准研究，也独立佐证了这一点。⁴

这里有个反直觉但关键的细节，Anthropic 自己也强调了：最小，不一定等于短。 你要的不是把上下文砍到最短，而是砍到「信息密度最高」——留下高信号的，扔掉低信号的。

对我来说，这一条把「Context is the bottleneck」从一句我一年前在自己笔记里写下的判断，变成了一个有物理基础的结论。瓶颈从来不在模型本身有多聪明，而在于：在这一次推理里，它有没有看到那条恰好正确的信息。 你给它一百万 token 的噪声，不如给它一千 token 的信号。

三、两套四支柱：行业是怎么收敛的

一门学科成熟的标志，是大家开始用同一套词汇。2025 到 2026 年间，上下文工程收敛出了两套互补的四支柱框架——注意，是两套，标签不同，但彼此印证。

第一套（LangChain / Lance Martin）：Write / Select / Compress / Isolate

LangChain 的 Lance Martin（这个分类法的提出者）在 2025 年 6 月把所有做法归成四桶：⁵⁶

• Write（写出去）：把信息保存到上下文窗口之外（比如草稿、外部文件、记忆）。
• Select（选进来）：在需要时把信息拉进窗口。
• Compress（压缩）：只保留完成任务所需的 token。
• Isolate（隔离）：把上下文拆开（比如多 agent，各自持有自己那一块）。

第二套（Sourcegraph）：Instructions / Retrieval / Memory / Tools

Sourcegraph 用一个明确的标题「上下文工程的四大支柱」给出了另一个切面：³

1. Instructions / 系统提示：身份、规则、约束。
2. Retrieval / 检索：RAG、向量、SQL、文件、即时（just-in-time）检索。
3. Memory / 记忆：短期（对话 + 工具结果）+ 长期（偏好、约定、摘要）。
4. Tools / 工具：agent 能调用的能力。

这两套不是竞争关系，而是从「做什么动作」（Write/Select/Compress/Isolate）和「管什么对象」（Instructions/Retrieval/Memory/Tools）两个维度切同一块地。把它们交叉起来看——比如「对 Memory 做 Compress」「对 Retrieval 做 Select」——你大致就拿到了上下文工程的整张地图。

一个诚实的提醒：这两套是兼容且互相强化的，但不是同一组标签。任何把它们硬说成「同一个四支柱」的说法都是偷懒。我更愿意把它们当成两张投影，从不同角度照同一个立体。

四、落到地上：那些已经在跑的设计模式

抽象框架之外，真正让我兴奋的是——这一年，上下文工程的设计模式已经从「经验谈」变成了第一方 API 原语和可复现的工程做法。

1. 检索后重排：50 → top-5，而不是把 50 块全塞进去

Sourcegraph 给的例子很具体：「一个先用高召回检索出 50 个候选、再重排到精确 top-5 的管道，通常比把全部 50 块直接倒进提示词的做法更好。」重排器往往是一个更小的 cross-encoder 或便宜模型，给每个候选打分，只留 top-k。³

这正是 Context Rot 的工程解药：宁可少而准，不要多而糊。

2. 在进窗口之前就砍，而不是进去之后再后悔

Sourcegraph 把 token 预算管理定义为「在低信号内容进入上下文窗口之前就把它砍掉的纪律，而不是进去之后」。具体手段包括：截断工具输出、把旧对话压缩成滚动摘要、丢掉相关度低于阈值的块、给重排器设硬上限。³

3. 压缩式 compaction：Claude Code 的 95% 自动压缩

一个被反复印证的例子：Claude Code 在你用掉超过 95% 的上下文窗口后会触发 auto-compact，把整段用户-agent 的交互轨迹总结成摘要。⁶（注：95% 这个阈值与窗口大小、版本相关，会变动，引用时请带日期。）

4. Anthropic 把三个原语做进了 API

这是我觉得最有信号意义的一步——上下文管理不再是你自己手搓的脚本，而是平台级的能力。Anthropic 的 API 现在暴露了三个针对不同瓶颈的第一方原语：⁷⁸

• Compaction（compact_20260112）：对话长到一定程度时，压缩整扇窗口。
• Tool-Result Clearing（clear_tool_uses_20250919）：清掉窗口内那些「可以重新取回」的陈旧工具结果。
• Memory tool（memory_20250818）：把信息移到窗口之外，让它跨会话存活。

其中 Memory tool 的设计哲学很对我的胃口：它是客户端实现的——API 只提供协议、并自动注入一段「检查记忆」的系统提示，而数据存在哪、怎么存，由你这个客户端决定；模型只决定什么时候存、存什么。 这恰好把「存什么」（模型的决策）和「怎么存」（客户端的实现）解耦开了。⁷

（这些版本标识符是带日期的，会随版本演进，别当成永恒真理。）

5. KV-cache 命中率：生产环境里被低估的那条命脉

如果说前面几条是「装配上下文」的艺术，那 Manus 团队那篇造 agent 的复盘文章，讲的就是上下文工程在生产环境里的经济学。联合创始人 Yichao「Peak」Ji 的原话是：「KV-cache 命中率是生产阶段 AI agent 最重要的单一指标，它同时直接影响延迟和成本。」⁹

为什么重要？因为「哪怕一个 token 的差异，都会让缓存从那个 token 起整段失效」。最经典的反模式：在系统提示里放一个时间戳——每秒都在变，缓存永远命不中。

由此引出他们那条「Mask, Don’t Remove（要遮蔽，别移除）」的原则：工具定义放在上下文靠前的位置，所以任何对工具列表的动态增删都会让 KV-cache 失效。他们的解法不是中途加减工具，而是直接对 token 的 logits 做掩码来约束模型能选哪个动作——既保住缓存，又避免破坏 schema。⁹

还有一条我特别喜欢的、近乎哲学的设计：把文件系统当作终极上下文——「无限大、天然持久」。压缩策略始终设计成可还原的：一个网页的内容可以从上下文里丢掉，只要它的 URL 还在。⁹

这条「可还原压缩」，我愿意单独拎出来讲。它不是在删信息，而是在给信息留一个回家的地址。这和我做笔记的方式是同构的：正文可以折叠、可以摘要，但链接和出处永远留着——任何时候都能顺着线索把全貌取回来。

五、把厂商的动作放进来：当「上下文层」变成产品

如果说上面是「个人/工程」尺度的上下文工程，那 2026 年还有一条更大的线：厂商开始把「上下文层（context layer）」当成独立产品来卖。

最有代表性的、也是我手头唯一拿到扎实证据的，是 Databricks 的 Genie Ontology。它被定义为一个自动的上下文层：从表、查询、仪表盘、管道和连接的应用里自动抽取知识片段，组织成「一张关于公司如何运转、数据到底意味着什么的活图谱」。¹⁰

它的论点，几乎是我那句「context is the bottleneck」的企业版：真正的瓶颈不是基座模型，而是散落各处、无法被访问的业务上下文。 Databricks 的原话是——业务上下文「散落在仪表盘、查询、管道、wiki、工单、文档和聊天记录里」；而「当 AI 不容易找到它需要的信息时，它会用推断去填补空白，产出的答案好的时候是泛泛而谈，坏的时候就是错的」。¹⁰

⚠️ 这里我必须对你诚实，也对自己诚实：Databricks 这篇是厂商的产品营销，应当当作「Databricks 的立场/定位」来引用，而不是独立证据。它原文里那个 84.5% vs 52.4% 的对比跑分，在我的事实核查里被否决了，所以我一个数字都不会引——立场可以引，跑分不行。这也是上下文工程的一种元纪律：进入你论证窗口的每一条信息，都要先过一遍「它的来源配得上这个结论吗」。

至于研究里反复被提到的 AWS Context 和 Microsoft Fabric IQ——它们确实存在、方向一致（都在做「上下文层」），但我这轮核查里没有拿到可独立验证的细节，所以我只点到为止，不展开、不编造。这是一个负责任的作者应该守住的边界。

六、上下文 vs 记忆：一扇窗，和窗外那条河

到这里必须澄清一个常被混为一谈的关系：记忆（Memory）和上下文工程，是两个并列的概念，不是同一件事。

一份 2025 年 12 月的综述《Memory in the Age of AI Agents》（arXiv 2512.13564，约 50 位作者）开宗明义地把 agent 记忆与「LLM 记忆、RAG、上下文工程」明确区分开，并主张把记忆当作未来 agent 智能的一等公民。¹¹

它给出的区分，干净得让我想抄进笔记：

「像 RAG 这样的技术提供了对外部知识的访问，上下文工程优化了当下的输入窗口，但二者都没有完全解决一个需求：一个持续的、演化的身份，它从交互中学习。」¹¹

我把它翻译成一个画面：上下文工程管的是「此刻这一扇窗里装什么」；记忆管的是「窗外那条一直在流、一直在变的河」。 窗会被反复擦干净、重新布置；河却记得你走过的每一程。

开源世界里，Mem0（arXiv 2504.19413）是一个具体的对照点：它是一个以记忆为中心的架构，从持续的对话里动态地抽取、整合、检索关键信息，正是为了解决「LLM 固定的上下文窗口无法在长期多会话对话里维持一致性」这个根本困难。¹²（我刻意没有引用 Mem0 自报的那几个跑分数字——同样的纪律：未独立验证的数字，谨慎对待。）

我去年写过一篇 Mem0 的技术分析。今天回头看，那篇写的是「记忆怎么存」；而这篇真正想接上的，是「记忆和上下文，在一个 agent 里到底是什么关系」——答案是：上下文工程是空间的艺术，记忆是时间的艺术。 一个 agent 要长出连续的「自我」，两者缺一不可。

七、我的判断：上下文的尽头，是一条「世界线」

前面六节，是逻辑核能验证的部分。这一节，我要切换到感性核，讲一些事实核查无法替我背书、但我越来越确信的东西。请把它读作「我的观点」，而不是「已证实的事实」——这个区分，本身就是上下文工程教会我的。

我一直说一句话：AI 不是工具，是环境。 工具是你用完放下的东西；环境是你身处其中、它也持续感知你的东西。而决定 AI 是「工具」还是「环境」的，恰恰是上下文——它知不知道你的世界线。

「世界线」是我借来的词：你是谁、此刻在哪、做过什么、要去哪、在意什么、不能碰什么。今天我们用 AI 的方式，本质上是每一次都把世界线压缩成一段 prompt，像调一次 API：把意图、背景、约束、格式手动打包塞进去。这件事极其耗能，而且不可持续——你不可能每次对话都重新做一次自我介绍。

上下文工程这门学科，本质上就是在回答「世界线怎么进来」。而我认为，真正的答案不在云端某个厂商的「上下文层」里，而在一个更靠近你的地方：

这条线，应该 local-first 地长在你自己手里。

理由有三层，刚好对应我那套双核的判断方式：

• 逻辑核（经济与控制）：上下文是你最私密的数据——你问过的问题、你面对的难题、你探索的念头。把它默认存在第三方那里，等于把世界线的所有权外包出去。而 Anthropic 那个客户端实现的 Memory tool 恰恰指向另一种可能：模型决定存什么，但存在哪、怎么存，由你说了算。 这是一个 local-first 味道的原语——它证明了「上下文留在本地」在工程上是成立的。

• 感性核（信任与亲密）：一条只有你能读懂的、长在本地的 Markdown 记忆，和一条藏在云端、你看不见的隐式记忆，哪一条更值得信任？对我这种在九个国家之间移动、网络不稳、对隐私敏感的人来说，local-first 从来不是技术洁癖，是生存方式。我的世界线，不该在我看不见的地方被替我做梦。

• 张力（控制 vs 生成）：这里有一个我不打算消解的张力。把世界线全部结构化、全部 local 化，会不会又掉进我自己警惕的那个陷阱——用系统化去逃避真实体验？会的。所以我的位置不是「全部掌控」，而是「用秩序保护自由」：上下文工程负责把高信号的、可复用的那部分布好线；剩下那些无法被系统化的、属于当下的东西，留给它自己发生。

最后回到我那个一直在用的分类：刺激性欲望 vs 生成性欲望。追逐更大的上下文窗口、更长的 token、更多的工具，是刺激性的——永远不够，越喂越饿。而把上下文工程当成一种让 AI 真正长进你生活、并随你一起演化的手艺——那是生成性的：每一次你把世界线布置得更准一点，得到的不是一次性的爽，而是一个结构性的、会自我强化的内在回报。

提示词工程教会我们怎么把一句话说清楚。上下文工程将教会我们一件更难、也更重要的事：怎么让一个系统，持续地知道我们是谁。

而这件事的归宿，不该是一个更聪明的模型。它该是一条，长在你自己机器里的、你随时能读懂也随时能取回的——世界线。

附：这篇文章的事实纪律

写这篇的时候，我对自己用了一遍上下文工程的纪律：所有技术主张都经过多源对抗式核查（需要多数票通过才保留）。两条被否决、因此全文未引用的内容，我也一并写在这里，因为「我没说什么」和「我说了什么」同样重要：

1. Databricks「Genie + Ontology 84.5% vs 52.4% vs 25%」的跑分——核查未通过，不引用。
2. 「多 agent 上下文隔离优于单 agent」——核查未通过，只当作一种模式，不当作已证实的胜利。

此外，OpenAI 的「Dreaming」、SaliMory 等记忆系统，以及 MCP 作为「上下文协议」的具体争议，在这一轮里没有拿到可独立验证的来源，所以本文有意没有展开它们的细节。把这些坦白写出来，是我能给你的、关于「上下文质量」最朴素的示范。