MCP

「与其说我们在写提示词，不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签，而我们真正在做的，是装修。」 如果你在 2024 年问我「怎么用好 AI」，我大概率会跟你聊提示词：怎么写指令、怎么设定角色、怎么给例子。但如果你今天再问我同一个问题，我的回答会完全不同。 因为这一年里，一线工程实践已经悄悄换了一个词——Context Engineering（上下文工程）。它不是提示词工程的升级版营销话术，而是一次重心的真正迁移：从「怎么把一句话写好」，转向「怎么决定模型在每一次推理时究竟看到什么」。 这篇文章想做两件事。第一件，用逻辑核把这门正在成形的学科拆开：它到底是什么、和提示词工程的边界在哪、有哪些已经在生产环境跑起来的设计模式。第二件，用感性核回到我自己——作为一个把 AI 当成环境而非工具、坚持 local-first 的人，我为什么认为上下文工程的尽头，是一条叫「世界线」的东西。 一、先把边界划清楚：Prompt 与 Context 不是同一件事 最容易混淆的，是把上下文工程当成「提示词工程的高级版」。它们确实相关，但不是同一层的东西。 Anthropic 在它那篇被广泛引用的工程文章里给了一个干净的区分：提示词工程是「编写和组织 LLM 指令的方法」；而上下文工程是「在 LLM 推理过程中，对最优 token 集合进行筛选与维护的一整套策略」——这个集合包括系统提示、检索到的文档、对话历史、工具定义、记忆，以及所有可能落进上下文窗口、但不属于「提示词」的信息。1 Andrej Karpathy 在 2025 年 6 月那条被反复转发的推文里说得更直白：「+1 支持用『上下文工程』取代『提示词工程』……这是一门精细的艺术与科学：用恰好正确的信息，填满下一步所需的上下文窗口。」2 而 Sourcegraph 在 2026 年的实践文章里，给了一个我特别喜欢的、可操作的判据： 「如果你在替换名词和形容词，你还在做提示词工程。如果你在改变 agent 检索什么数据、以什么顺序、用什么重排、以及当窗口被填满时淘汰什么——你在做上下文工程。」3 重心从「措辞（wording）」转向了「布线（wiring）」。 这一句话，是我读完所有材料后觉得最值得记住的。提示词工程关心的是字面；上下文工程关心的是管道——数据从哪进来、经过哪些处理、在窗口里待多久、什么时候被踢出去。 这不是文字游戏。当你的 agent 只是一个单轮聊天框时，写好一句话几乎就是全部工作。但一旦它有了工具、有了记忆、有了检索层，写提示词就只剩下整个系统里很小的一块；剩下的全是围绕它的上下文工程。 二、为什么是「工程」：上下文是有限资源，而且会腐烂 把它叫「工程」而不是「技巧」，是有硬道理的。因为上下文窗口不是一个越大越好的容器——它是一种有限资源，且边际收益递减。 Anthropic 的原话是：「上下文必须被当作一种有限资源来对待，它的边际收益是递减的。」以及——「好的上下文工程，意味着找到那个信息量最高的、最小的 token 集合，去最大化某个期望结果的可能性。」1 支撑这个判断的，是一个叫 Context Rot（上下文腐烂） 的现象：随着上下文窗口里 token 数量的增加，模型从中准确召回信息的能力反而下降。1 这背后有一个「注意力预算」的论证——注意力是 n² 的两两关系，窗口越长，每个 token 能分到的注意力越稀薄；Chroma 那份针对性的「针在草堆里」基准研究，也独立佐证了这一点。4 这里有个反直觉但关键的细节，Anthropic 自己也强调了：最小，不一定等于短。 你要的不是把上下文砍到最短，而是砍到「信息密度最高」——留下高信号的，扔掉低信号的。 对我来说，这一条把「Context is the bottleneck」从一句我一年前在自己笔记里写下的判断，变成了一个有物理基础的结论。瓶颈从来不在模型本身有多聪明，而在于：在这一次推理里，它有没有看到那条恰好正确的信息。 你给它一百万 token 的噪声，不如给它一千 token 的信号。 ...