很多团队在拿到大上下文模型后,会产生一种危险的错觉:只要窗口够大,把历史、日志、diff、工具结果和规则全塞进去,总会更稳。真实情况往往相反。上下文越满,模型越难分辨什么是指令、什么是证据、什么是噪音,系统最后得到的不是更强理解,而是更高成本和更低聚焦。
Context budget 真正要解决的,不是“能否装下全部信息”,而是“有限 token 里,谁该占优先席位”。因为对 agent 来说,系统提示、风险约束、关键证据、当前任务状态、工具结果和历史对话的价值并不相同。
建议先结合 AI agent 成本控制与预算治理、AI agent Context Compaction、Reset 与 Memory Write、AI agent 工具结果标准化 和 AI agent Plan Drift 检测与再规划触发 一起看。
预算不是越大越稳,而是越清楚越稳
更实用的做法,不是让每类信息都去争抢 token,而是先划预算 envelope:
| 上下文槽位 | 典型内容 | 优先级 |
|---|---|---|
| 指令槽 | system prompt、policy、硬性约束 | 最高 |
| 任务槽 | 当前目标、任务状态、未完成项 | 高 |
| 证据槽 | 已验证事实、引用、关键工具结果 | 高 |
| 历史槽 | 最近几轮对话、重要分歧 | 中 |
| 噪音槽 | 大段日志、重复失败、冗长草稿 | 最低 |
这张表的价值是:一旦超预算,系统知道先砍谁,而不是把所有内容平均压缩。
不同任务,预算分法应该不同
一份预算如果能覆盖所有任务,通常等于它对任何任务都不够好。至少可以按任务类型做三档:
| 任务类型 | 优先保留 | 可压缩部分 |
|---|---|---|
| 结构化提取 | schema、字段定义、最近工具结果 | 历史对话 |
| 多步规划 | 当前计划、失败原因、下一步依赖 | 旧草稿细节 |
| 高风险写入 | policy、审批状态、证据来源 | 长篇解释文本 |
这意味着 context budget 本身就是路由决策的一部分,而不只是一个底层参数。
失败案例:把完整 diff 和原始日志都塞进去,模型反而忽略了 stop condition
某个代码 agent 为了“让模型看到更多”,把全量 diff、失败测试日志和 20 轮对话都塞进同一次推理。结果模型确实看到了更多信息,但它忽略了 system prompt 里最关键的一条:不要继续修改未授权目录。
复盘发现问题不是 prompt 写得不清,而是重要指令在极度拥挤的上下文里被稀释了。系统没有给指令槽和风险槽保留最小预算,导致“最重要的信息”在总量上被次要信息淹没。
修复思路很直接:
- 给 system 与 policy 预留不可侵占预算
- 工具结果只保留摘要和关键字段,不放全量原文
- diff 先做 relevance slicing,只带与当前任务相关的部分
工具结果最好先标准化,再决定要不要进上下文
很多预算浪费不发生在对话历史,而发生在工具结果。因为原始 API 返回往往很长,但对当前决策真正有用的只是一小部分。
更稳的流程通常是:
- 工具先输出标准化结果
- 系统抽取 decision fields
- 只有关键字段进入 context
例如:
{
"tool": "searchPolicyDocs",
"summary": "命中 3 条策略,当前租户不允许自动外发邮件",
"confidence": 0.94,
"evidenceRefs": ["doc://policy-7", "doc://policy-11"],
"nextActionHint": "require_human_review"
}
相比把整页命中文档原文塞进去,这种结构更适合进入高价值上下文槽。
预算分配要和 drift 检测联动
一个常见误区是:budget 只在请求开始前算一次。现实里,任务会在执行过程中变形,特别是遇到反复失败、工具抖动或目标变化时,系统需要动态重分配预算。
例如:
- 如果任务已经进入重试阶段,应降低历史槽预算,抬高错误证据槽
- 如果任务触发 replan,应提高任务槽和当前约束槽预算
- 如果用户插入了新的硬性限制,应立刻让约束槽覆盖旧摘要
这也是为什么 context budget 最终应该被看成控制面的一部分,而不是一个固定常量。
Context Budget Checklist
- 是否为指令、任务、证据、历史设定了明确预算槽位
- system prompt 和 policy 是否拥有不可侵占预算
- 不同任务类型是否使用不同的 budget profile
- 工具结果是否先标准化,再决定进入上下文的字段
- 超预算时是否先丢弃噪音,而不是均匀压缩全部内容
- drift 或重试阶段是否会动态重分配 budget
- 是否监控 accepted run quality 与 token cost,而不是只看上下文总长度
最后真正要做的事
上下文预算分配的核心,不是证明模型能吃下多少 token,而是替系统回答一个更现实的问题:在有限注意力里,什么信息必须优先存在。只要这个问题没被明确回答,长上下文能力就很容易从优势变成噪音放大器。
延伸阅读:


