一句话说清
上下文预算分配（Context Budgeting）指的是：在模型AI 词典：上下文窗口">上下文窗口（context window）大小固定的前提下，决定把多少 token 分给系统提示、历史对话、检索结果、工具输出，以及给模型自己写回答预留多少空间。
为什么这是个问题
上下文窗口是一次调用里模型能"看见"的全部文字。它不记忆，每一轮都要把当前需要的内容重新打包塞进去。窗口就像一只固定尺寸的行李箱：洗漱包（系统提示）不能不带，换洗衣服（历史对话）越多越安心，当地地图（检索结果）看着有用，再加上路上买的纪念品（工具输出）——塞到最后拉链拉不上，只能往外掏东西。掏错了，回答质量就崩。
怎么分
比较实用的思路不是"平均分"，而是排优先级，并给每一类定一个上限：
- 系统提示/指令：定角色、规则、输出格式。优先级最高，但也要精简，别把规范和示例都堆进去。
- 历史对话：维持连贯性。常见做法是"最近几轮原文 + 更早内容滚动摘要"，而不是全量保留。
- 检索结果：补充事实依据。先按相关性筛选和重排，再决定放几段，而不是检索到多少塞多少。
- 工具输出：接口返回、文件内容、执行日志。通常先截断或结构化，只留模型真正要用的字段。
- 输出预留：必须留够，否则模型还没写完就被截断。
| 内容块 | 作用 | 超预算时的常见处理 |
|---|---|---|
| 系统提示 | 定角色、规则、格式 | 保留，精简措辞 |
| 历史对话 | 维持连贯性 | 滚动摘要，只留最近几轮 |
| 检索结果 | 补充事实 | 减少条数、重排、只留相关段落 |
| 工具输出 | 外部数据、执行结果 | 截断、结构化、先摘要 |
| 输出预留 | 模型要写的回答 | 必须留，别把窗口塞满 |
还有一条经验：关键信息放在开头或结尾更稳妥，埋在一大段中间容易被忽略——这一点在实践中普遍能观察到。
和相邻概念的区别
上下文窗口是"容量"，是模型给的硬约束；上下文工程（Context Engineering）是更大的范畴，包含怎么选、怎么写、怎么放；提示压缩（Prompt Compression）只是其中一种省空间的手段；而 RAG 决定"取什么进来"，预算分配决定"进来多少、放在哪"。前者是选材，后者是配比。
对实际工作的意义
对从业者来说，上下文组装应该当成一个可观测、可配置的模块：记录每一块实际占了多少 token，设置优先级和降级策略，出问题时才能定位是检索噪声、历史膨胀，还是工具输出把窗口吃掉了。
对普通使用者来说，它解释了几件常见困惑：为什么聊久了会"忘事"，因为早期对话被摘要或挤出去了；为什么重要的事再说一遍确实有效；为什么把一堆资料全贴进去，回答反而更差——不是模型不行，是预算被无关内容占满了。
各家模型的窗口大小和计费方式不同，具体以官方页面为准。