一句话回答
不是上下文越多越好，而是和当前任务越相关越好。好的上下文不是“信息最多”，而是“每一条信息都和当前任务有关”。
01 先看一张图：有效上下文和无效上下文
signal beats volume
无效上下文太多
50 轮历史聊天
完整产品手册
全部用户资料
历史工具结果
过期旧要求
无关系统说明
用户只是要优化一个产品标题，模型却背着一大堆和标题无关的资料工作。
精简后的上下文
只保留当前任务真正需要的信息，AI 更快、更省，也更容易抓住重点。
模型真正需要看的，不是“所有信息”，而是“完成当前任务需要的信息”。
02 什么叫无效上下文？
true is not always useful
50 轮历史聊天
很多内容已经被后续决定替代。
完整产品手册
用户只是在改一个标题。
全部用户资料
当前任务根本用不到这些字段。
历史工具结果
返回过的字段一直堆在上下文里。
过期旧要求
旧方案和当前方案互相打架。
无关系统说明
真实，但和这次任务没有关系。
真实信息，不等于有效信息。
03 无效上下文会带来什么问题？
cost, noise, focus
增加 Token
模型要处理更多输入，成本通常更高。
增加干扰
旧要求和无关事实会影响判断。
重点被淹没
真正重要的几条信息反而不突出。
无效上下文不只烧钱，还可能让答案变差。
04 最常见的无效上下文从哪里来？
common waste sources
过长聊天记录
很多轮对话只需要保留结论。
已失效旧要求
旧颜色、旧流程、旧策略应及时删除。
工具结果累积
每次返回几十个字段，最后变成噪音。
整张数据库表
能查询筛选，就不要整表塞给模型。
RAG 召回过多
Top 50 不一定比 Top 5 更可靠。
System Prompt 过长
所有规则都往里塞，容易冲突也更贵。
动态变量过多
时间戳、随机 ID 可能破坏缓存复用。
全部文件
当前任务可能只需要其中几段。
05 过长聊天记录要变成状态摘要
summarize old turns
原始历史
第 1 轮：白色背景；第 2 轮：6 个板块；第 3 轮：导航调整。
压缩摘要
当前方案：白色轻量风格，首页保留 6 个核心板块，导航使用最新版。
废弃信息
蓝色方案、旧导航、已删除板块不再传给模型。
上下文不只要增加，还要会删除。
06 工具结果也应该提炼
tool output is not all context
订单工具返回
20 个字段。
物流工具返回
30 个字段。
客户工具返回
50 个字段。
最终保留
当前状态、预计送达时间、异常情况。
用户只问订单什么时候到，真正需要的可能只有物流状态、预计送达时间和异常情况。
07 数据库能先筛选，就不要让模型海里捞针
filter before prompt
错误方式
把 1000 条订单全部交给 AI，让模型自己找。
程序先查
数据库定位张先生最近一笔订单。
只返必要字段
订单金额、状态、时间、关键备注。
AI 负责表达
把筛选后的事实讲清楚。
能在程序层筛选，就不要让模型自己从海量数据里找。
08 RAG 不是检索越多越好
retrieve relevant, not maximum
不是找最多
资料越多，噪音也可能越多。
而是找最相关
围绕当前问题拿核心段落。
A100 保修问题
保修政策、售后说明、A100 手册相关段落就够了。
RAG 的核心不是找最多资料，而是找最相关资料。
09 System Prompt 也不要越写越长
separate stable and dynamic
固定核心规则
放在 System Prompt。
业务方法
沉淀成 Skill。
企业知识
放进知识库检索。
动态数据
通过工具按需获取。
成熟系统不是把什么都塞进 System Prompt，而是把规则、方法、知识和动态数据分开放。
10 把上下文分成三层
keep, maybe, delete
保留
必须知道
不提供就无法完成任务，例如当前问题、关键规则、必要事实。
按需加入
可能有帮助
相关案例、历史摘要、可选背景，只有需要时再放入。
删除
无关信息
旧项目记录、无关订单、已废弃规则，不进入当前上下文。
必须知道就保留，可能有帮助就按需加入，无关信息就删除。
11 一张图看懂上下文漏斗
context funnel
01
所有可用信息
历史对话、知识库、数据库、工具返回、用户资料。
02
相关性筛选
先问：这次任务真的需要吗？
03
当前任务相关内容
只留下会影响回答或执行的内容。
04
再压缩
旧对话变摘要，工具结果变关键字段。
05
必要上下文
交给 AI 的是最少的充分信息。
AI 不应该直接吃“全部信息”，而应该经过筛选和压缩。
12 长期项目最好维护当前状态摘要
project state beats raw history
项目目标
开发企业 AI 官网。
当前技术
WordPress。
当前设计
白色轻量化风格。
已完成
首页、产品页、文章页。
当前任务
优化移动端首页。
禁止修改
现有数据库结构。
结构化本身就是一种上下文压缩。
13 无效上下文还会影响缓存
stable input caches better
每次都塞随机信息
无关随机字段、精确时间戳、全部历史状态，会让请求不断变化。
固定内容保持稳定
把真正会变化的内容放到动态区，且只保留当前任务需要的部分。
减少无效上下文，不只是省 Token，也有利于缓存。
14 目标不是最少，而是最少的“充分上下文”
minimum sufficient context
太少
AI 不知道“刚才确定的方案”是什么，任务无法继续。
刚刚好
再少不够，再多浪费。
太多
旧规则、无关资料、全部字段一起进来，成本和干扰都增加。
15 一个实用的上下文优化清单
before every call
历史聊天都还需要吗？
摘要旧内容。
有没有已经废弃的规则？
删除。
工具结果是不是太完整？
只留关键字段。
RAG 拿了太多资料吗？
降低无关召回。
数据库能先筛选吗？
程序先处理。
System Prompt 是不是太长？
拆成 Skill / 知识库。
动态变量真的需要吗？
不需要就不传。
当前任务需要全部文件吗？
按需读取。
16 最后把成本链路串起来
clean context pipeline
所有信息
先别急着塞给模型。
筛选
判断相关性。
删除无关信息
清理噪音。
压缩历史
变成状态摘要。
RAG 只取相关资料
控制召回。
工具只返必要字段
减少输入。
最少充分上下文
再选合适模型。
生成结果
更快、更省、更聚焦。
本节练习
把一封客户跟进邮件的上下文压缩到刚刚好
不要把 50 轮历史、完整客户档案、所有订单和全部产品资料都塞给模型。先筛选出当前任务、客户需求、最近沟通、相关产品价格和写作要求。
旧信息
能总结就总结。
失效信息
及时删除。
资料很多
先检索再读取。
工具和数据库
只返回当前任务需要的字段。
本节小结
上下文就像办公桌。真正高效的工作方式，不是把所有资料都堆上来，而是这次要做什么，就只把这次真正需要的东西放到桌面。
- 真实信息不等于有效信息。
- 无效上下文不仅烧钱，还可能让答案变差。
- 旧信息能总结就总结，失效信息及时删除。
- 最理想的是最少的充分上下文：再少不够，再多浪费。
