什么是上下文工程？它和提示词工程是什么关系？
谁在问：头部 AI 公司 / 大厂二面；概念辨析题，常作为 Agent 深聊的入口
口语化问法
- 2026 年大家都在说上下文工程，它和提示词工程有什么区别？是换了个说法吗？
- 你在项目里具体做过哪些上下文工程的事？
- Agent 上下文该放什么、该扔什么，你是怎么决定的？
考察意图
这是一道辨析题，但辨析本身不是目的。面试官在看：
- 你是把它当成营销包装还是当成约束变化——后者才说明你理解了为什么会改名；
- 你能不能给出具体操作，而不是复述定义；
- 这道题通常是 Agent 深聊的入口——答得好，后面直接进压缩、记忆、子代理；答成一段定义，面试官就换话题了。
参考答案
60 分答案（及格线）
提示词工程关注的是怎么写好一次请求的措辞——角色、指令、示例、输出格式。上下文工程关注的是模型每次推理时看到的全部内容：系统提示词、工具定义、检索结果、对话历史、外部记忆、加载进来的技能文档等等。
前者是一句话怎么写，后者是产出这句话及其周边一切的整条流水线。Agent 场景下上下文是动态组装且会累积的，所以重心从「写得好」变成了「放什么、扔什么」。
90 分答案（有生产经验的回答）
在上面基础上加三层：
第一，改名不是包装，是约束变了。 单轮聊天时，措辞确实是瓶颈；到了 Agent 时代，每一轮的上下文是动态拼装的，工具结果、模型自己的推理、用户消息一起累积，瓶颈变成了「这一轮到底该放什么、该扔什么」。官方的定义也是这个口径：为模型推理策展并维护一组最优 token，包括提示词之外所有可能落进上下文的信息。
第二，核心心智模型是「上下文是注意力预算」。 它有限、且边际递减——token 越多，模型从中准确召回信息的能力越低，所有模型都有这个特性，只是衰减快慢不同。所以这是一个策展问题，不是堆砌问题。「反正窗口大，先全塞进去」在 2026 年已经是一个可测量的反模式，不再是风格偏好。
第三，落地就是四个基本操作：写出去（把状态存到外部记忆或笔记里，不占窗口）、挑进来（检索或选择，只放这一轮需要的）、压缩（历史过长时做摘要式压缩）、隔离（子代理各用各的窗口，互不污染）。
我在项目里最典型的三件事：把系统提示词从长清单改成渐进披露——常用的留在主上下文，冷门流程拆成按需加载的文档；把老工具结果定期清理出去，因为它们进上下文之后就是永久居民，成本按剩余轮次复利；以及把关键约束从对话历史里提出来，放进每轮重新注入的结构化状态块——历史会被压缩、会被稀释，结构化状态不会。
至于两者的关系：不是取代，是包含。 提示词工程是上下文工程里「怎么写」这一块；上下文工程还管放什么、什么时候放、什么时候扔、以及怎么不把 prompt 缓存击穿。
追问链
举个例子说明「措辞对了但上下文错了」
期望三种「提示词写得再好也救不回来」：检索没召回那份文档，信息压根不在窗口里；第 3 轮说过的关键约束到第 30 轮已被压缩掉；工具结果堆了几万 token，把要紧那段挤进注意力洼地信号举得出具体场景 → 真在 Agent 上踩过；只抽象说「上下文不完整」→ 复述定义四个基本操作分别在解决什么？
期望写出去管「不该占窗口的状态」、挑进来管「只放这一轮需要的」、压缩扛「历史必然增长」、隔离防「子任务互相污染」；加分在指出四者代价不同，按代价从低到高上：先选择与清理 → 再压缩 → 最后才隔离信号给得出上手顺序、点名子代理隔离最贵 → 做过取舍；四个并列背出来 → 看过文章上下文是不是越长越好？
期望不是，贵、慢、笨三条。第三条是 context rot：召回准确率随长度下降，这是研究结论不是直觉。所以要把上下文当有限预算显式建模：固定开销 / 检索预算 / 历史预算 / 输出预留信号把「笨」单列成一条 → 读过一手材料；只说「太长太贵」→ 还停在成本视角上下文工程和 RAG 是一回事吗？
期望不是。RAG 只是「挑进来」这一个操作的一种实现，解决外部知识注入；上下文工程还管历史怎么压、状态放哪、工具结果何时清、系统提示词该多长、缓存前缀怎么保持稳定。反证：RAG 做得再好、从不清理工具结果的 Agent，第 30 轮照样变笨信号说清「RAG 是其中一个操作的实现」→ 层次分明；当成「RAG 的新叫法」→ 概念没分层Agent 跑到第 30 轮变笨：重复问已问过的、忘掉早期约束，怎么诊断治理？
期望先诊断别先加功能：按来源拆占比（系统提示词 / 工具定义 / 工具结果 / 历史 / 检索），大头通常是工具结果不是历史。两个症状两个病因：忘约束 = 约束活在会被稀释的历史里，提进每轮重注入的结构化状态块；重复问 = 缺可写可查的外部记忆。治理按代价：清工具结果 → 少次大压（频繁小压反复击穿 prompt 缓存）→ 子代理隔离排最后 → 重跑轨迹评测验证信号拆成两个病因、点出「约束不能活在对话历史里」→ 到位；答「换大窗口」或「上多 Agent」→ 前者不治衰减，后者把最贵手段当第一步
评分要点
- 能说清两者是包含关系，不是取代关系
- 解释改名的原因是约束变了，而非概念包装
- 说得出「上下文是注意力预算」这个心智模型
- 能列出四个基本操作并说明各自解决什么
- 知道四个操作代价不同，有上手顺序
- 能给出自己项目里的具体做法（渐进披露 / 清理 / 结构化状态）
- 知道 RAG 只是其中一个操作的实现
- 诊断时先拆上下文构成，再对症下药