上下文预算 — 设计在于去掉什么，而不是放进什么

• 窗口还有富余，准确率却在下降
• 上下文工程是提示词工程的延伸
• 工具的 schema 也在花预算
• 从提示词堆积到 playbook
• 丢弃策略与压缩：丢什么，何时丢
• 委派子智能体：买来干净的窗口，用 token 付账
• 亲手练习
• 参考资料

窗口还有富余，准确率却在下降

智能体会话一变长，怪事就来了。上下文窗口还没碰到上限，它却忘了开头给的指示，重读已经确认过的文件，写出与先前定好的规则相矛盾的代码。这段描写是构造出来的情境，不是某次具体测量，但方向与公开的观察一致。Anthropic 关于上下文工程的文章把 token 越堆越多、检索准确率越掉越低的现象称为上下文腐蚀（context rot），并把原因指向注意力按 token 两两配对分摊的结构，以及以短序列为主的训练分布。

结论很简单。上下文窗口不是拿来填满的仓库，而是需要分配的注意力预算。既然是预算，就得有支出科目，也得有削减标准。

上下文工程是提示词工程的延伸

同一篇文章这样梳理两者的关系：如果说提示词工程是把指令写好，上下文工程就是在每次推理时为窗口筛选并维护最优的 token 集合。不只是系统提示词，工具定义、外部资料、消息历史统统在范围之内。区别在于，它不是一次写好就完事的文档工作，而是每一轮都要重复的编辑决定。

从框架的视角看，这个定义之所以重要，理由很清楚：上下文策略是框架六个旋钮之一，是以代码形式部署的决定。"每一轮放什么进去、拿什么出来"的答案，应该以函数的形式存在于仓库的某个地方。

工具的 schema 也在花预算

最容易被忘掉的支出科目是工具 schema。暴露给模型的每一个工具，都以名字、描述、参数 schema 的形式在每一轮占据窗口的一角。暴露 21 个工具，模型还什么都没调用，预算就已经少了一块。而且工具越多选择越晃，schema 的成本不只是 token 的问题。这个权衡在第 3 篇工具表面设计里单独展开。

反方向的省钱手段是按需加载（just-in-time retrieval）。不把整份资料预先装进窗口，只留下文件路径、查询、链接这类轻量引用，需要的那一刻再用工具去取。这和人不背下整份文档、只记住它在哪里是同一个结构，也是 Anthropic 那篇文章推荐的基本策略之一。

从提示词堆积到 playbook

最常见的上下文策略是没有策略。新学到的规则不断追加到系统提示词末尾，文档只增不减。一个月后，互相矛盾的指示并存，没人知道哪条还有效。在这种状态下删除是不可能的——因为没有删除的依据。

Lilian Weng 的框架文章介绍的智能体上下文工程方法，用结构解决了这个问题：把上下文当作不断进化的 playbook，把生成条目、反思条目、筛选条目的角色分开。一个条目大致长这样。

- id: pb-041
  rule: 'integration 测试用 -j1 跑。并行会撞端口。'
  scope: 'repo:payments-api / task:test'
  added: '2026-07-18'
  last_used: '2026-08-07' # 久未使用的条目进入筛选候选
  helped: 23 # 这个条目实际帮上忙的次数

重点不在格式，而在元数据。一旦记录了每个条目何时加入、适用于什么场景、最近是否帮上过忙，删除就变得可能。上下文管理难的那一半不是放进去，而是拿出来；要能拿出来，每个条目上就得挂着依据。

丢弃策略与压缩：丢什么，何时丢

预算一旦溢出，总得有东西出去。出去的是什么，由策略决定。先推走最旧内容的策略实现起来零成本，但最先丢掉的是开头的核心规则。先砍最大块的策略省 token，却完全不懂重要性。只有像 playbook 那样先撤下适用性最低条目的策略，才把"对当前任务不那么必要"当作标准。无论选哪种，丢弃策略都必须是框架的显式决定。交给默认值，等于选了先推走最旧内容的那种。

摘要——也就是压缩（compaction）——是丢弃的补充。在接近上限时把此前的进展压缩成摘要，再从摘要重新出发。Anthropic 的文章列出了此时应当保留的东西：架构决定、未解决的 bug、实现细节。反过来说，不明确保留内容的压缩，恰恰会以丢掉这三样的方式失败。配套的技法是结构化笔记：把进展写到窗口之外的文件里，需要时再读回来，即使摘要失败也留有恢复点。

委派子智能体：买来干净的窗口，用 token 付账

上下文预算的最后一招是把窗口拆开。把需要大范围探索的子任务交给子智能体，它就在自己干净的窗口里干活，只把压缩后的摘要交回主队。主队的预算只需要为结论付钱。

但这不是免费的。Anthropic 的多智能体系统文章以他们自己的系统为例报告：智能体大约用掉普通聊天 4 倍的 token，多智能体架构大约 15 倍。只有当任务价值盖过这笔成本，委派才划算；而且委派时要写明目标、输出格式、工具指引和任务边界，否则就会出现重复探索和失控搜索——这也是同一篇文章的教训。子智能体不是上下文问题的逃生门，而是把预算按更大颗粒度重新分配的一个旋钮。

亲手练习

框架工程 RPG 的第 4 层"上下文预算"就是本文的练习。把提示词堆积、裁剪、playbook、精选四种策略换着插进同一个场景，你能直接看到丢弃策略如何改变结果。工具 schema 吃预算这件事，也能在游戏内的数值里得到确认。

• 上一篇：什么是框架工程
• 下一篇：工具表面设计 — 一行 schema 就能移动成功率

参考资料

• Effective context engineering for AI agents — Anthropic, 2025-09-29 —— 上下文腐蚀与注意力预算、压缩、结构化笔记、按需加载、子智能体架构都在这篇文章里。
• Harness engineering for self-improvement — Lilian Weng, 2026-07-04 —— 把上下文当 playbook 的智能体上下文工程方法在这篇文章中有介绍。
• How we built our multi-agent research system — Anthropic, 2025-06-13 —— 4 倍与 15 倍 token 数字的出处，以及委派时要写明任务边界的教训。
• 开头的会话描写与正文中的 playbook 条目示例是为说明而构造的。