AI agent 上下文预算分配:系统提示、证据、历史和工具结果该给谁多少 token

HTMLPAGE 团队
17 分钟阅读

上下文变长时,问题不是能不能塞下,而是谁该优先留下。本文讲清 context budget、evidence priority、history slicing 和 token envelope,帮助 AI agent 在长任务里保持判断质量。

#AI agent #Context Budget #Token Allocation #工程实践

很多团队在拿到大上下文模型后,会产生一种危险的错觉:只要窗口够大,把历史、日志、diff、工具结果和规则全塞进去,总会更稳。真实情况往往相反。上下文越满,模型越难分辨什么是指令、什么是证据、什么是噪音,系统最后得到的不是更强理解,而是更高成本和更低聚焦。

Context budget 真正要解决的,不是“能否装下全部信息”,而是“有限 token 里,谁该占优先席位”。因为对 agent 来说,系统提示、风险约束、关键证据、当前任务状态、工具结果和历史对话的价值并不相同。

建议先结合 AI agent 成本控制与预算治理AI agent Context Compaction、Reset 与 Memory WriteAI 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 返回往往很长,但对当前决策真正有用的只是一小部分。

更稳的流程通常是:

  1. 工具先输出标准化结果
  2. 系统抽取 decision fields
  3. 只有关键字段进入 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,而是替系统回答一个更现实的问题:在有限注意力里,什么信息必须优先存在。只要这个问题没被明确回答,长上下文能力就很容易从优势变成噪音放大器。

延伸阅读: