考察点
这道题出自 2026 年 Agent 岗位高频面经（牛客、卡码笔记的 Agent 专题都收录），一面二面都常见。面试官想确认你不是只会调 API 拼 prompt，而是理解"模型输出质量的上限由输入信息质量决定"这个工程现实。追问一般往两个方向走：你项目里具体怎么组装上下文的，以及上下文出问题时怎么定位和优化。
参考答案
定义：从写 Prompt 到管上下文
上下文工程（Context Engineering）指的是：在模型每次推理之前，把本次决策所需的信息——系统指令、工具定义、检索到的知识、长期记忆、对话历史、结构化状态——动态地筛选、排序、裁剪、组装进上下文窗口的整个工程过程。
Prompt 工程关注的是单条指令怎么写：角色设定、few-shot、思维链引导。上下文工程关注的是信息流：信息从哪来、进不进窗口、进多少、什么顺序、什么时候该清出去。前者是写作问题，后者是架构问题。2025 年以后模型能力趋同，同样是 GPT/Claude 级别的底座，两个团队做出的 Agent 效果差距，大部分就出在上下文供给的质量上。
上下文的五个来源
工程上我把上下文拆成五个来源，分别管理：
| 来源 | 内容 | 管理要点 |
|---|---|---|
| 系统指令 | 角色、规则、输出格式 | 稳定，少改，放最前 |
| 工具定义 | Function/Skill 的 schema | 几十个工具时 schema 本身就吃掉上万 token，要渐进加载 |
| 检索知识 | RAG 召回的文档片段 | top-k 和重排序控制，别整篇塞 |
| 记忆 | 用户画像、历史偏好、会话摘要 | 写入和召回都要策略，见记忆系统题 |
| 对话历史 | 本会话的消息流 | 超阈值要摘要压缩 |
为什么它是稀缺资源
三个硬约束决定了上下文必须精打细算。第一，窗口有限，200k token 看着大，一个带几十个工具的 Agent 跑二十轮工具调用就能塞满。第二，注意力会稀释，研究表明长上下文中间位置的信息召回率明显下降（lost in the middle 现象），塞得越多，每条信息被真正用到的概率越低。第三，成本线性增长，每轮推理都要为全量上下文付费，冗余上下文直接烧钱包。
所以上下文工程的核心动作是三个字：筛、排、裁。筛——不是相关的信息不进窗口；排——关键信息放开头结尾；裁——历史信息超阈值就摘要、落盘、只留引用。
工程落地
我自己的落地框架是：组装层写一个 context builder，每轮推理前按预算分配额度（比如系统 5%、工具 15%、检索 20%、记忆 10%、历史 40%、输出预留 10%）；每个来源有独立的裁剪器；再加一层观测，记录每轮各类上下文占了多少 token、最终回答引用了哪些片段，效果不好时能回溯是哪类信息没喂对。
可能的追问
- 上下文是不是越多越好？——不是。无关信息会稀释注意力、抬高成本、增加幻觉概率，相关性永远优先于完整性。
- 上下文出错了怎么定位？——把每轮发给模型的完整 payload 落日志，badcase 复盘时直接看当时模型"看到了什么"，九成问题能定位到某个来源没喂对。
- 和 RAG 什么关系？——RAG 是上下文工程里检索知识这一个来源的实现技术，上下文工程是更大的盘子。