上下文工程：取代提示工程的新技能

提示词工程只是一条好的指令。上下文工程则是控制模型在推理时看到的一切：哪些文件、哪些历史记录、哪些工具结果。本文将解释它的含义、它拆解成的四种操作，以及为什么 FDE 和应用 AI 面试现在会考察这项技能。

作者：ARJUN MEHTA · FDEINTERVIEWS 编辑部 · 更新于 2026 年 7 月 25 日 · 阅读时长 5 分钟

实践练习：RAG 与 Agent 设计问题 · LLM 与 GenAI 问题 · FDE 必知问题 · 核心概念详解

上下文工程是指控制模型在推理时看到的一切的实践：指令、检索到的文档、之前的对话、工具结果，以及你要求它填写的输出模式（schema）。你输入的提示词只是其中一小部分，其余一切都由你的系统组装而成。提示词工程是写一条好的指令然后祈祷。上下文工程则是设计模型推理所依据的整个工作集，正是这一转变将可靠的 AI 产品与昂贵的自动补全区分开来。对于前沿部署工程师和应用 AI 工程师来说，它已经悄然成为核心技能，也是面试官在 RAG 和 Agent 轮次中考察的内容，更是 AI 前沿部署工程师角色与经典角色区别之一。本文将介绍它是什么、它拆解成的四种操作，以及如何在循环中展示它。

从提示词到上下文再到循环

短短几年间经历了三次转变，而大多数人只注意到了第一次。

Andrej Karpathy 给出了那个广为流传的框架。在他 2025 年的 Software 1.0 / 2.0 / 3.0 演讲中，他将这种新模式描述为通过上下文而非显式代码或训练好的权重来对模型进行编程。他将这门学科定义为“用恰到好处的信息填充上下文窗口，以完成下一步”。这句话就是全部工作所在。你不再编写确定性的指令，而是在策划一个智能解释器在行动之前所看到的内容。

每一层都建立在前一层之上。一个构建良好的循环中，一个仅仅合格的提示词通常能存活下来。而一个完美的提示词叠加在杂乱的上下文之上仍然会失败。杠杆点已经转移——这是关于下一个小时应该花在哪里的判断，而不是让你停止关注提示词的许可。

循环工程才是 FDE 真正的工作场景：不是在客户现场敲提示词，而是搭建一个系统，让它组装正确的上下文、执行操作、检查自己的工作，然后再运行一遍。MLOps 和 Agent 设计的问题始终围绕这一点展开。

四种操作

一个被广泛使用的分类法将上下文工程拆分为四种动作。你将来调试的几乎所有上下文问题，都是其中某一种的失败。

• 写入（Write）。将状态持久化到窗口之外，让模型可以读回这些状态，而不是把所有东西都放在内存里。比如项目规范文件、记录哪些方法有效哪些无效的运行日志、步骤之间的草稿笔记。
• 选择（Select）。只检索与下一步相关的内容。不是全部，也不是随机片段：而是那几份正确的文档。检索质量、分块和重排序的价值正体现在这里。
• 压缩（Compress）。当历史记录过长时，对陈旧的部分进行摘要，同时保持最新工具结果的完整保真度。在窗口填满之前回收 token。
• 隔离（Isolate）。给子任务一个干净的独立上下文，只让结构化的结果回流。这正是子 Agent 存在的原因：主 Agent 保持专注，而子 Agent 在单独的窗口中处理一个混乱的子任务。

这些操作所防止的失败在实践中有个说法：窗口不会缩小，而是变得杂乱。无关的 token 不断堆积，信噪比下降，模型在同一个任务上开始做出更差的决策。同一个模型面对同一个问题，能否通过可能仅仅取决于它回答时窗口里还放着什么。这就是这项技能存在的全部理由，也是嵌入与检索基础背后的直觉。

它在面试中如何体现

面试官很少直接说“上下文工程”。他们通过症状来考察它。

• “你的 RAG 助手有时会根据用户不应看到的文档来回答。请带我走一遍这个问题。”这是一个选择（Select）问题：检索范围和权限。
• “这个 Agent 能正常工作三轮，然后开始混乱并重复自己。”这是压缩（Compress）和隔离（Isolate）问题：一段未被管理的历史不断增长，直到关键指令被淹没。
• “客户的知识库远大于上下文窗口。你如何把它装进去？”这是整个学科的综合考验。

优秀的回答会点出对应的操作和失败模式，然后做出判断。糟糕的回答则倾向于“增加更多上下文”或“换更大的模型”，而这恰恰是上下文工程要纠正的本能。如果你想多加练习，RAG 与 Agent 设计题集和 ML 系统设计问题会直接训练这种推理，必知题集则涵盖了最常出现的失败模式。

构建循环，并且不要省略校验器

上下文工程的价值，在于把它封装进一个无需人工干预即可持续运行的循环中。在 Claude Code（由 Anthropic 的 Boris Cherny 构建）这类智能体编程工具中，其基本组件正好对应四种操作：每次会话智能体都会读取的项目文件（Write）、相关文件的检索（Select）、历史压缩（Compress），以及拥有独立上下文窗口的子智能体（Isolate）。一个可运行的循环由以下几个部分组成：

A working loop
  State file   persistent conventions + a log the loop reads each run   (Write)
  Retrieval    load only the files relevant to this step                (Select)
  Sub-agents   split the maker from the checker; each gets a clean window (Isolate)
  Cadence      run on a schedule or an event, not by hand
  Verifier     tests / schema / eval that MUST pass, or the run is rejected

团队最容易低估的部分是验证器。一个只生成而从不检查自身工作的循环，只会更快地产出错误结果。这道门槛——必须全绿通过的测试套件、输出必须满足的 Schema、必须达到阈值的评测——才是把“模型反复自我认同”变成可以放手让它持续运行的自动化的关键。在客户部署中，这道门槛决定了你交付的是一个可以上线的产品，还是一个需要人盯着的东西。这也是评测在这些循环中不断被提及的真正原因。

它解决不了什么

三点坦诚的提醒，因为这项技能常被过度吹捧。

更多上下文并不总是更好的上下文。超过某个限度后，额外的 token 只是噪音，一份精炼的、包含正确约定的文件胜过一大堆冗长的堆砌。即使在完美的上下文中，模型仍然会产生幻觉：好的上下文能减少错误，但不能免除对验证器的需求。而且这确实是一项大多数团队尚未掌握的新技能——这正是为什么值得在面试之前而非面试期间去构建它的原因。

提示词工程为行业带来了第一波价值。上下文工程则是其余价值所在之处。对于前沿部署或应用 AI 岗位来说，这不是一个值得观望的趋势，它就是这份工作本身。从 RAG 和 Agent 问题入手，对任何不确定的概念保持概念库随时可查，如果你还在梳理这个岗位本身，技能拆解部分能帮你把这些内容放到整体背景中理解。

把它转化为 Offer。练习与之对应的真实面试题和概念：

常见问题

上下文工程是指决定模型在推理时能看到的一切内容的实践：指令、检索到的文档、之前的对话轮次、工具输出，以及你要求它填写的 Schema。提示词只是其中一个组成部分。上下文是模型进行推理的完整工作集，能否掌控它，正是可靠 AI 系统与昂贵的自动补全之间的分水岭。

提示工程优化的是你手工编写的一条指令。上下文工程优化的是模型接收到的全部输入，其中大部分是由你的系统组装而非人工输入的：检索结果、对话状态、工具响应和格式。一条完美的提示，如果叠加在杂乱、不相关的上下文之上，依然会失败。杠杆已经从句子转移到了窗口。

是的，越来越多的情况是这样，即使他们不这么称呼它。当面试官问你会如何阻止 RAG 系统引用错误的文档、如何避免 Agent 淹没在自己的历史记录中，或者如何将大型知识库塞进有限的窗口时，他们考察的就是上下文工程。它出现在 RAG、Agent 和系统设计环节中，而不是作为一个有明确名称的主题。

一个广泛使用的分类法将其分为四种操作。写入（Write）：将状态持久化到窗口之外，以便模型稍后可以读回。选择（Select）：只检索与下一步相关的内容，而不是所有内容。压缩（Compress）：总结陈旧的历史记录以回收 token。隔离（Isolate）：给子任务分配各自干净的上下文，避免一个 Agent 污染另一个。大多数上下文问题都是这四种操作中某一种的失败。

不是，而且假设上下文越多越好是一个常见的错误。超过某个程度后，额外的 token 会增加噪音，淹没信号，并且当相关事实被埋在长窗口中间时，模型的表现会下降。一个由少数几份正确文档组成的紧凑、精心筛选的上下文，胜过五十份文档的大杂烩。目标是正确的信息，而不是最多的信息。

讨论 (5)

让我终于恍然大悟的框架是：模型是 CPU，上下文窗口是 RAM。你的工作不再是“写一条聪明的指令”，而是“决定每一步之前往 RAM 里加载什么”。一旦你这样看问题，检索质量、历史压缩和工具输出格式化就都是同一个问题了。

这个类比在设计环节也很有分量。如果你能像系统工程师谈论内存预算那样谈论 token 预算——决定淘汰什么、保持什么热点、把什么换出到磁盘——你听起来就像一个真正运行过这些系统的人，而不是只读过相关资料的人。

读者提问：在面试中，他们期望你真正构建过多少这类东西，还是只需要能够推理？我用过检索，但从未手动调优过 Agent 的上下文窗口。

主要是推理能力，至少在 staff 级别以下是如此。你不需要上线过自定义的压缩策略，但你应该能说出你会压缩什么、什么时候压缩，以及如果做错了会出什么问题。说出失败模式（一个 Agent 每一轮都重新读取自己的全部历史，直到耗尽预算），你就展现出了他们筛选的判断力。

团队低估的部分是验证器。一个只生成、从不检查自身工作的循环，只会更快地产出错误结果。在客户部署中，这道关卡（测试、schema 校验、必须通过的评测）决定了你得到的是可以放手运行的自动化，还是需要时刻盯着的演示。