上下文工程是什么？提示词工程的升级版
上下文工程（context engineering）是提示词工程在 2025 年升级出来的说法。一句话讲清：不再只打磨"这个问题怎么问"，而是去设计模型回答时看到的一切——指令、检索来的资料、工具返回的结果、对话历史、之前会话留下的笔记。这个词在 2025 年年中火起来，到现在，Anthropic、LangChain 这些一线厂商的官方文档都在正经使用它。你只要做过超出"玩具聊天框"的 LLM 应用，这就是决定你的东西能不能用的那门手艺。
名字是新的，问题不新。下面我把这个术语的来历、什么算上下文、为什么模型窗口越大这事儿反而越重要、以及实操层面到底怎么做，按顺序讲一遍。
上下文工程是什么，这个词从哪来
先把时间线捋清楚，因为它能告诉你当时大家在烦什么。
2025 年 6 月，Shopify 的 CEO Tobi Lütke 在一份后来公开的内部备忘录里用了这个说法，定义是"为任务提供全部所需上下文、让它对 LLM 来说可合理解决的艺术"。几天后，Andrej Karpathy 转发放大：他更喜欢上下文工程这个词，定义是"用恰好正确的信息填满上下文窗口、支撑下一步的精细艺术与科学"。注意 Karpathy 列的动作清单：少样本示例、RAG、工具、状态、历史、压缩。全是从业者干了好几年、却一直没有合适名字的事。
2022 年造出"提示词工程"这个词的 Simon Willison，点破了老词为什么失效：它的实际含义已经滑向"往聊天框里打字"这种自命不凡的说法。新词描述的才是真实的工作内容。到 2025 年 9 月，Anthropic 发布工程指南，明确说上下文工程是提示词工程的自然演进。词汇的换代至此完成。
还有一个我常用的解释，来自一个综述了 1400 篇论文的 GitHub 仓库：提示词工程管的是"你说什么"，上下文工程管的是"模型看到的其余一切"。给听过提示词的人解释这个概念，这句最快。
什么算上下文：七类东西抢一个窗口
直接上清单。任意时刻，上下文就是窗口里的一切，大致七类：
- 系统提示词（稳定的指令）
- 你当前这条消息
- 短期状态（进行中的任务、到目前为止的对话）
- 长期记忆（从之前会话带过来的内容）
- 检索来的知识（RAG 的那个 R，查询时现拉进来的文档）
- 工具定义和工具返回结果
- 要求的输出格式
七类东西挤同一个固定容量。这是多数人漏掉的部分：窗口是一份共享预算（容量机制本身，我们讲上下文窗口那篇有完整拆解），每多加一类，剩下各类分到的注意力就被稀释一分。上下文工程，本质上就是管这份预算。
为什么偏偏现在冒出来：窗口越大，越要少放
这是整个概念里最反直觉的一环，也是这个行业需要新词的真实原因。
照直觉想，模型都能吃一百万 token 了，还挑什么，全塞进去不就完了。研究结论正好相反。一篇标题就叫 Context Rot（上下文腐烂）的论文测了输入 token 变多会发生什么：召回和推理双双下滑。背后有机制：注意力是一份预算，每加一个 token，其他所有 token 分到的注意力就薄一分；而注意力建模的是 token 两两之间的关系，长度翻倍，关系数按平方涨。东西越多，每件东西被看得越模糊。
你可能会说，那些长上下文模型不是把大海捞针测试考满分了吗？考了，而这恰恰是陷阱。那个测试把一个事实藏在长文档里，提问的措辞和事实本身几乎一样，本质是词面匹配，接近字符串查找，不需要推理。研究者把"针"改写一下，让答案需要关联一句间接表述才能得出，或者加进几条看起来相关但不是答案的干扰项，成绩就随长度断崖式下跌。真实任务——"给你一堆代码，找出为什么跑挂"——恰恰是模糊加干扰的那种，不是字符串匹配那种。
有一个数字我建议你记住：在一组对照测试里，对着约 12 万 token 的完整对话历史回答，效果不如对着一份只有 300 token、只保留相关信息的精简版。token 少了四百倍，答案反而更好。过了一个点之后，筛选不是锦上添花，是全部。上下文工程的一半功夫，就是在决定不放什么。
上下文工程和提示词工程的关系
这是大家搜得最多的问法，值得认真回答。诚实的说法，也是 LangChain 联合创始人的立场：提示词工程没有死，它变成了子集。他有句话很准：智能体的失败，多数时候不是模型失败，是上下文失败。你的 AI智能体干了蠢事，模型拿到的输入往往"配得上"这个蠢答案——一堆臃肿的历史、检索错的文档、三个职责重叠的工具。
| 提示词工程 | 上下文工程 | |
|---|---|---|
| 打磨对象 | 一条指令的措辞 | 进入窗口的一切 |
| 形态 | 静态模板 | 按任务动态组装的系统 |
| 核心问题 | 怎么问 | 放什么、不放什么、用什么格式 |
| 典型动作 | 改措辞、加少样本示例 | 接 RAG、裁历史、设计工具、记笔记 |
举个例子最直观。你对模型说"我想退货"。只有这一句话时，它机械回答"请在 7 天内提交申请"。现在把上下文配上：客户是谁、订单详情、商城退货规则、前面对话里承诺过什么。同一个模型，同一个问题，回答变成"您买的耳机还在退货期内，退货申请已提交"。差别从来不在问题怎么问。想看更完整的路线版图（微调、纯提示各在什么位置），可以读我们那篇微调 vs RAG vs 提示词。
实操原则：放什么，不放什么
Anthropic 的工程指南是我读过最实用的一份，它的总纲压缩得极漂亮：追求最小的高信号 token 集。每一次交互，你都在问：这条信息配得上它占的预算吗。
几条值得直接抄的原则：
按需取用。 不预加载模型"可能要用"的一切，在需要的那一刻精确取。指南自己举的例子是 Claude Code：读文件只读开头几行或结尾几行，用 glob 看目录结构、grep 定位模式，而不是把整个代码库塞进上下文。信息按需到达，而且到达时已经收窄过。
系统提示词写在合适的高度。 太泛（"做个有用的助手"）模型没有方向；穷举每种情况怎么处理，规则之间会打架。甜点位是往上一层：写稳定的行为原则，不写逐案规则。
把工具设计给一个会犯迷糊的人用。 工具输出保持紧凑、工具职责别重叠、名字体现意图。指南说得很直白：人类工程师都分不清该用哪个工具时，就别指望智能体分得清。我恰好调试过这种故障：两个几乎一样的内部工具，agent 老选错那个，所有人都在怪模型。
还有一条是 demo 和产品的分水岭："AI 帮我约会议"的 demo，一个系统提示词就能跑。能用的版本，喂进去的是可用时段、时区、会议室容量、公司预订规则、上周会议的纪要。从 demo 到产品，模型没变聪明，它的上下文变了。这也解释了为什么上下文工程和 AI 智能体是一起长大的——智能体是上下文压力最大的场景：跑得久、工具多、状态一攒几个小时。
长任务的三个技术
任务跑得够久之后，上下文问题就从"放什么"变成"攒了一堆怎么办"。Anthropic 指南给了三个技术，各自对准一种失败：
压缩（compaction）。 历史太长时主动摘要清场。不显然的部分是留什么：最近的文件、架构决策、没解决的 bug 留下，已经处理完的工具输出清掉。压缩是分诊，不是无脑截断。
结构化笔记（structured note-taking）。 让智能体把要记住的东西写下来——一个 NOTES.md 文件、一个步数计数器（那个让 Claude 玩宝可梦的著名设置，就是用千步计数器当记忆）——而不是指望它一直活在大模型上下文的窗口里。笔记活得下来，窗口内容活不下来。
子智能体架构（sub-agent）。 开自己窗口的分身。一个子智能体可能烧掉几万 token 干一场脏活，然后只交回一两千 token 的结论摘要。脏的部分永远碰不到主上下文。
指南的收尾建议我很喜欢，就因为它朴素：先做最简单的能用的。多数任务用不上三件套。RAG 本身，你细想的话就是上下文工程最流行的动作——在刚好相关的时刻把检索到的知识拉进来。从这里起步，哪里真坏了再上机械。
快答
上下文工程和提示词工程的区别是什么？ 打磨对象不同：提示词工程打磨一条指令的措辞，上下文工程设计进入模型窗口的全部信息（检索、工具、记忆、历史都在内）。后者是前者的超集。
提示词工程死了吗？ 没有，降级成了子集。措辞依然重要，只是不再占全部工作量。
普通人需要懂上下文工程吗？ 你其实已经在轻量地做了：传文件、贴对的那段代码、发现对话糊涂了就新开一个聊天。你只是没叫它这个名字。
RAG 算上下文工程吗？ 算，而且是最高频的一招：让模型在对的时刻看到紧凑形态的检索结果。
这个领域如果你只带走一个想法：对面的模型是固定的，但它看到什么，是你设计的。把 LLM 用得好的团队，靠的不是什么魔法提示词，而是把上下文当工程系统对待——可度量、有预算、下得去刀。