编程 Agent 的上下文预算：如何保留关键证据而不淹没模型

上下文窗口变长后，很多团队的第一反应是把更多代码、日志和历史对话塞给 Agent。结果常常相反：关键约束被无关细节稀释，模型在旧信息和新代码之间做出错误关联，成本与延迟同步上升。上下文预算不是为了节省几个 token，而是为了让每一段输入都能说明“为什么必须在这次决策中出现”。

可以把任务上下文分成四层：不可省略的系统约束，例如安全策略和工作目录；当前任务事实，例如需求、验收条件和风险等级；代码证据，例如目标模块、调用方和测试；以及可选背景，例如历史讨论和相似 PR。前两层必须精确，第三层按依赖图选择，第四层只在它改变决策时加入。

预算要按证据类别分配

不要只设置一个总 token 上限。为不同类别预留额度，例如 15% 给任务和政策、45% 给当前代码和测试、20% 给接口和依赖、20% 给历史和检索结果。额度不是固定配方，但能阻止长日志或聊天记录吞掉所有代码上下文。每次选择时记录文件、片段范围、摘要版本和加入理由。

一个上下文包可以显式表达优先级：

{
  "task": {"priority": "required", "hash": "..."},
  "policy": {"priority": "required", "version": "repo-policy-v3"},
  "files": [
    {"path": "src/auth.ts", "reason": "authorization boundary", "priority": "high"},
    {"path": "tests/auth.test.ts", "reason": "acceptance evidence", "priority": "high"}
  ],
  "history": [{"id": "pr-812", "priority": "optional"}]
}

当预算不够时，应先去掉低优先级背景，而不是压缩安全规则或测试断言。压缩后的内容保留原始文件和行号引用，避免摘要成为无法追溯的二手事实。

摘要不是永久记忆

代码变更后，旧摘要可能比没有摘要更危险。为摘要绑定源文件哈希、生成时间和适用范围；任一关键源文件改变时，相关摘要自动失效。对于长期任务，保存的是决策摘要和证据引用，而不是不断追加的对话全文。这样恢复任务时可以按需重取最新代码，而不会继承数小时前已经失效的结论。

还要区分“模型曾经说过”与“仓库当前事实”。提示中可以保留历史假设，但必须标记为待验证，并要求 Agent 在执行前用文件或命令确认。特别是构建命令、依赖版本和权限规则，不能由旧对话直接决定。

用反事实测试检查上下文质量

评估上下文选择时，不只看最终答案是否看起来合理。构造几个反事实：移除关键权限文件后，Agent 是否仍错误地建议写操作；加入无关大日志后，它是否忽略测试失败；替换一个过期摘要后，它是否主动重新读取源文件。通过这些测试，可以发现选择器到底在保留信号，还是仅仅裁剪文本。

生产中监控每类上下文的 token、命中率、因缺少证据导致的返工率和缓存失效次数。若一个历史摘要从未改变决策，就应降低优先级；若某个测试文件反复在错误修复中缺失，就应把它加入任务模板。上下文工程应像依赖管理一样持续调整，而不是一次提示词优化。

为预算耗尽设计安全回退

当上下文已接近上限，Agent 不应继续压缩关键文件直到语义丢失。更安全的选择是停止在一个明确检查点，输出已确认事实、尚未读取的依赖和下一轮所需的最小证据。调度器可以启动新的子任务或请求用户缩小范围，但不能把不完整上下文伪装成完整结论。

回退策略还应限制摘要级联：摘要的摘要很容易失去异常处理、否定条件和版本约束。超过一层压缩时，要求重新读取原始高风险文件，并在输出中标出未验证区域。通过记录预算耗尽次数和最终返工率，团队能判断问题是模型窗口不足、任务过大，还是仓库地图选择错误。

延伸阅读

• 上下文工程
• AI 代码库上手
• 提示词版本控制