什么是 上下文预算（Context Budget）？
上下文预算（Context Budget）是一项应用层策略，用于在序列化指令、工具、用户输入、历史、证据、工具结果与生成预留之间分配模型请求的有限 Token 容量。
工作原理
上下文预算是位于模型端点容量限制之下的应用分配策略。Context Window 说明端点最多能接受什么，预算则说明当前工作负载允许花费多少，并为生成保留多少空间。可移植的规划约束是：序列化输入、生成预留、供应商或运行时余量与安全边际之和，不得超过适用的模型和端点限制。有些 API 公布输入输出共享上限，有些分别限制输入、输出、推理或特定功能，因此不存在适用于所有供应商的单一减法公式。
预算对象应是组装后的完整请求，而不只是用户可见文本。常见 Bucket 包括 System 与 Developer Policy、Tool Schema、当前输入、对话历史、检索证据、Memory、示例、成组的 Tool Call 与 Result、多模态表示及输出格式 Schema。每个 Bucket 都应声明 Hard Cap、Soft Target、Protection Class 与 Overflow Action。固定百分比只能作为待验证假设：文档问答可能把多数输入留给证据，Agent 则可能需要更多 Tool 与状态容量。只有显式策略仍能保护必需下限和总上限时，才允许借用未使用配额。
必须在最终 Chat Template 或供应商序列化之后，使用目标模型的 Tokenizer 或 Token Count Endpoint 计数。Role Wrapper、JSON Schema、Tool Description、图像、PDF、音频和供应商附加格式都会让原始文本估算失真。计数接口本身也可能只提供估算，因此要保留经过测量的余量，并用响应 Usage 对账计划值。预算策略应绑定 Model、Endpoint、Tokenizer、Serializer、Prompt、Tool Catalog、Retrieval 与 Output Schema Revision；任一身份变化都要重新计算。
溢出行为属于契约。受保护的 System 与安全策略、授权范围、当前任务、必需输出 Schema、Source ID、未决冲突及原子的 Tool Call/Result Group 不能被静默切断。弹性 History 可以采用 Sliding Window 或已验证 Checkpoint；检索证据可以先授权，再 Rerank、Deduplicate、缩小范围或拆分；Tool Result 可以字段投影、分页，或保存后注入受限引用。必需内容仍无法放入时，应显式失败、要求用户缩小任务、路由到兼容端点或拆分工作，不能依赖未声明的截断。
单次调用的 Context Budget 不等于 Agent Run Budget、账单上限、Rate Limit 或权限系统。多步 Agent 还需分别限制 Model Call、Tool Call、Wall Time、Retry、Byte 及整次运行的总 Token。每个 Tool Result 都可能成为下一次请求的输入，因此纳入上下文前要校验类型与大小，并保持 Call/Result 原子性。数据必须先完成授权与分类，再参与预算；为适配容量而删除内容不会让未授权数据变安全，超大不可信结果还可能形成成本或可用性攻击。
Prompt Caching 可以减少重复 Prefill 计算或费用，但 Cached Token 仍占用逻辑上下文，不会扩大预算。Context Compression 可以缩小某个 Bucket，却会引入 Loss Budget 与 Provenance 义务。应记录每个 Bucket 的计划和实际 Token、溢出原因与动作、被省略或转换的 Source ID、生成用量、供应商报告的 Reasoning 或 Cached Token、Finish Reason、延迟、成本和任务结果，同时避免记录 Secret 或隐藏推理文本。
预算策略必须随完整 Release 一起评测。在相同 Model、Data 与 Output Contract 下，将多个预算方案与未预算或更大上下文对照组比较。测量 Task Success、Critical-evidence 与 Policy-constraint Recall、Citation Support、Incomplete-output 与 Overflow Rate、各 Bucket 的 p50/p95/p99 Utilization、TTFT、端到端延迟及每个成功任务成本。测试多语言、代码、大型 Schema、多模态输入、长会话、超大 Tool Result、冲突证据、Prompt Injection、供应商 Revision 变化，以及不存在安全分配方案的样本。
主要特点
- 应用策略而非模型容量：Context Window 是上限，预算定义当前工作负载在其下方的具体分配
- 完整请求计量：序列化指令、Tool、历史、证据、媒体、生成、运行时余量与安全边际均显式记录
- 分桶契约：每类内容都有 Cap、Target、Protection Class、Priority 与确定性 Overflow Action
- 绑定 Revision：Model、Endpoint、Tokenizer、Serializer、Prompt、Tool Catalog、Retrieval 与 Schema 都会影响计数
- 安全溢出语义：保留受保护内容，否则缩小、拆分、改路由、复核或拒绝请求
- 按结果验收：Token 利用率与节省量必须和质量、证据保留、延迟、成本及滥用测试一起评估
常见用途
- 组装带已授权证据、引用元数据与受保护生成预留的 RAG 请求
- 用原始近期轮次、已验证 Checkpoint 与可检索来源历史限制长对话
- 只加载当前任务相关的 Tool Schema，并对超大 Tool Result 执行字段投影或分页
- 按模型专属计数为多语言、代码、表格或多模态请求选择路由
- 在单独受限的多步 Agent 执行中约束每次模型调用的容量
示例
Loading code...常见问题
上下文预算与上下文窗口有什么区别？
Context Window 是模型与端点的容量上限；Context Budget 是应用在该上限之下，为指令、Tool、当前输入、历史、证据、结果与生成预留制定的分配策略。请求即使装得下，也可能因成本过高、延迟过长、噪声过多或风险不符合当前工作负载而违反预算。
应用应如何计算上下文预算？
先读取确切模型与端点限制，为生成容量和经过测量的安全余量预留空间，再用目标 Tokenizer 或供应商接口计算完整序列化输入。必须包含 Role Wrapper、Tool 与输出 Schema、历史、检索证据、Tool Result 和多模态表示，并用实际 Usage 对账估算值、版本化预算策略。
Cached Token 仍会占用上下文预算吗？
会。Prompt 或 Context Caching 可以减少重复 Prefill 计算或费用，但缓存前缀仍是逻辑输入并占用 Context Window。缓存不会产生额外容量、授权过期内容，也不能替代输出预留和有效上下文评测。
请求超过上下文预算时应该怎么办？
按超限 Bucket 的声明动作处理：减少 Tool Schema、缩小并重排证据、压缩历史、投影或分页 Tool Result、拆分任务，或路由到兼容端点。不能静默删除受保护策略、授权、当前任务、必需 Schema、Source Identity，也不能只保留 Tool Call/Result Group 的一半。
所有 LLM 应用都应使用相同预算比例吗？
不应。分配取决于任务、模型、语言、Tool Catalog、检索分布、输出契约、风险、延迟目标与成本目标。百分比只能作为候选，应在代表性和对抗性评测中比较多个方案，并选择能够通过质量、安全与运营门禁的最小预算。