企业官网建设流程全解析

比 Prompt 工程更重要的事：一文讲透「上下文工程」（Context Engineering）

一、从「写好提示词」到「管好上下文」

过去两年，大家谈 AI 应用，开口闭口都是「Prompt 工程」——怎么把提示词写得更好，让模型听话。

但当你真正开始做 Agent、做 RAG、做长对话应用时，会发现一个事实：

决定大模型表现的，往往不是你那句提示词写得多漂亮，而是你往它的「上下文窗口」里塞了什么。

模型在某一时刻能看到的全部信息——系统提示、历史对话、检索到的资料、工具返回的结果、用户的问题——这一整个「视野」，才是它做判断的依据。如何设计、组织、管理这块「视野」，就是上下文工程（Context Engineering）。

如果说 Prompt 工程是「怎么问一个好问题」，那上下文工程就是「怎么在模型有限的注意力里，放进恰好够用、且最相关的信息」。它是 Prompt 工程的上位概念。

二、为什么上下文工程更关键？

2.1 上下文窗口是有限且「昂贵」的

模型的上下文窗口（Context Window）就那么大，而且：

• 塞得越多，越花钱：输入 token 是要计费的
• 塞得越多，越慢：处理长上下文需要更多时间
• 塞得越多，未必越准：这是最反直觉、也最关键的一点

2.2 「上下文腐烂」：信息多 ≠ 效果好

很多人以为「把所有相关资料都丢给模型」就万事大吉。恰恰相反，业界有个词叫Context Rot（上下文腐烂）：

当上下文里塞了太多无关或冗余信息，模型反而会被干扰，抓不住重点，表现下降。

经典现象包括：

• 「中间遗忘」（Lost in the Middle）：模型对上下文开头和结尾的信息记得清楚，放在中间的关键信息容易被忽略
• 注意力被稀释：10 条资料里只有 1 条有用，模型可能被另外 9 条带偏
• 相互矛盾：塞进去的资料彼此打架，模型无所适从

所以上下文工程的核心目标不是「给得多」，而是「给得准」。

三、上下文里到底装了哪些东西？

理解上下文工程，先得知道一次请求的上下文由哪些部分组成：

┌─────────────────────────────────┐ │ System Prompt（系统提示/角色设定） │ ← 相对固定 ├─────────────────────────────────┤ │ 工具定义（可用的 Tools / Functions） │ ← Agent 场景 ├─────────────────────────────────┤ │ 检索资料（RAG 召回的文档片段） │ ← 动态变化 ├─────────────────────────────────┤ │ 历史对话（之前的多轮问答） │ ← 不断增长 ├─────────────────────────────────┤ │ 工具调用结果（上一步的返回） │ ← Agent 场景 ├─────────────────────────────────┤ │ 当前用户问题 │ ← 本次输入 └─────────────────────────────────┘ ↑ 这一整块加起来，不能超过上下文窗口

上下文工程，就是去决定每一部分放什么、放多少、怎么排序、什么时候清理。

四、上下文工程的 6 个核心策略

4.1 精准检索（Retrieve）——只给相关的

这是 RAG 的核心。与其把整篇文档丢进去，不如：

• 把文档切成合适大小的片段（chunking）
• 用向量检索找出真正相关的几段
• 通过重排序（Rerank）进一步筛掉噪音，只留 Top 3-5 条

宁可少而精，不要多而杂。

4.2 压缩（Compress）——把长的变短

当历史对话或资料太长时，不要硬塞，而是先压缩：

• 摘要：让模型先把长对话总结成几句话，再带入后续
• 提取关键信息：只保留结论、决策、关键事实，丢掉寒暄和过程

4.3 裁剪与遗忘（Trim / Forget）——主动清理

长对话场景下，要有「遗忘机制」：

• 超出窗口的早期对话，做摘要后丢弃原文
• 已经完成、不再相关的任务上下文，及时移除
• 工具返回的大段原始数据，用完就清

4.4 结构化（Structure）——把信息组织好

同样的信息，组织方式不同，效果天差地别：

• 用清晰的标题、分隔符、标签区分不同部分
• 关键信息放在开头或结尾（避开「中间遗忘」区）
• 用 XML 标签、Markdown 等结构让模型一眼看清层次

<背景资料> ...这里放检索到的文档... </背景资料> <用户问题> ...这里放当前问题... </用户问题>

4.5 隔离（Isolate）——拆分上下文

复杂任务别都挤在一个上下文里：

• 用多个子 Agent，每个只负责一块，各自维护自己的小上下文
• 把不同性质的信息分到不同阶段处理，而不是一锅炖

4.6 缓存（Cache）——复用不变的部分

系统提示、工具定义这些每次都一样的内容，可以用Prompt Caching缓存起来，既省钱又提速。（这一点我之前专门写过一篇，可以翻来看。）

五、一个实战例子：客服 Agent 的上下文设计

假设你在做一个客服机器人，看看上下文工程怎么落地：

这样设计出来的 Agent：又快、又省、又准。这就是上下文工程的价值。

六、上下文工程 vs Prompt 工程

结论：Prompt 工程没有过时，它是上下文工程的一个子集。但当你做的东西越复杂、越接近真实生产，上下文工程的权重就越高。

七、总结

关于上下文工程，记住这几点：

1. 核心命题：管理好模型在某一刻能看到的「全部信息」，而不只是写好一句提示词
2. 关键认知：信息不是越多越好——警惕「上下文腐烂」和「中间遗忘」
3. 六大策略：精准检索、压缩、裁剪遗忘、结构化、隔离、缓存
4. 一句话：把恰好够用、且最相关的信息，放进模型有限的注意力里

当大模型的能力越来越强、上下文窗口越来越大时，很多人以为「窗口够大就能无脑全塞」。事实恰恰相反——窗口越大，会管理上下文的人和不会管的人，差距越大。

上下文工程，正在成为 AI 应用开发者最值钱的核心技能之一。

相关阅读：可结合我之前的《Prompt 工程》《RAG 知识库实战》《Prompt Caching 降本》《Token 是什么》几篇一起看，它们都是上下文工程的具体组成部分。