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

比 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 的上下文设计假设你在做一个客服机器人看看上下文工程怎么落地上下文部分怎么处理系统提示角色、规则固定内容走缓存工具定义查订单、退款等固定内容走缓存用户历史订单只检索当前问题相关的 1-2 条不全塞知识库文档向量检索 重排只留Top 3对话历史超过 N 轮就摘要压缩早期内容当前问题放在最后最显眼的位置这样设计出来的 Agent又快、又省、又准。这就是上下文工程的价值。六、上下文工程 vs Prompt 工程维度Prompt 工程上下文工程关注点一句提示词怎么写整个上下文窗口怎么管范围局部指令本身全局所有输入信息典型场景单轮问答、写作Agent、RAG、长对话核心挑战表达清晰取舍与组织关系上下文工程的一部分Prompt 工程的上位概念结论Prompt 工程没有过时它是上下文工程的一个子集。但当你做的东西越复杂、越接近真实生产上下文工程的权重就越高。七、总结关于上下文工程记住这几点核心命题管理好模型在某一刻能看到的「全部信息」而不只是写好一句提示词关键认知信息不是越多越好——警惕「上下文腐烂」和「中间遗忘」六大策略精准检索、压缩、裁剪遗忘、结构化、隔离、缓存一句话把恰好够用、且最相关的信息放进模型有限的注意力里当大模型的能力越来越强、上下文窗口越来越大时很多人以为「窗口够大就能无脑全塞」。事实恰恰相反——窗口越大会管理上下文的人和不会管的人差距越大。上下文工程正在成为 AI 应用开发者最值钱的核心技能之一。相关阅读可结合我之前的《Prompt 工程》《RAG 知识库实战》《Prompt Caching 降本》《Token 是什么》几篇一起看它们都是上下文工程的具体组成部分。