上下文窗口是公地，而每个团队都在过度放牧

打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。

加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。

上下文窗口是一片公地。它是一种共享的、有限的、可枯竭的资源，许多独立的团队都在从中支取。而且就像所有公地一样，它没有分配者（allocator）。每个团队都做出了局部合理但在集体层面具有毁灭性的决定。这不是一个提示词工程（prompt-engineering）问题。这是一个治理问题，它需要治理工具，而不是更聪明的提示词。

公地没有分配者

“公地悲剧”不是一个关于坏人的故事，而是一个关于好人和结构缺失的故事。一片共享牧场能供养的牲畜数量是固定的。每增加一头牲畜，牧民都能获得全部收益，而过度放牧的成本却由所有人分担。因此，每个理性的牧民都会不断增加牲畜，直到牧场崩溃。没有人想要崩溃，也没有人贪婪，只是这种结构缺乏一种机制，无法将分担的成本反馈到个人的决策定价中。

智能体的上下文窗口具有完全相同的特征。窗口是有限的——即使是百万级 token 的模型也是如此，因为 上下文腐败（context rot）意味着有效容量远小于名义容量。从中支取的团队是相互独立的：检索团队、工具团队、安全团队、负责产品界面的团队、负责基础提示词的平台团队。每个团队都能从自己添加的内容中获得全部收益——评测分数提高了，功能正常运行了。而成本则是分散的：响应变慢一点、支出增加一点、召回率降低一点，这些成本平摊在每个团队的功能中，在任何单一团队的仪表盘上都是不可见的。

系统中没有分配者。没有任何组件会说“检索团队分到 8,000 个 token，工具团队分到 12,000 个，剩下的留给对话”。因此，窗口被填满的过程就像牧场变荒的过程一样：一步步合理的决定累积而成。

每一项增加都是局部合理的

危险之处在于，你无法通过要求人们保持自律来阻止这种情况。他们已经很自律了。让我们梳理一下实际的决策过程。

工具团队集成了一个新的 MCP 服务器。它暴露了 40 个工具。如果算上 schema 和字段描述，每个工具定义需要消耗 550 到 1,400 个 token。这可能会耗费 50,000 多个 token。但团队并不是粗心大意——这些工具确实有用，而且 MCP 客户端的默认行为就是预先加载所有定义。团队没有选择冗余，它选择的是一套可用的集成，而冗余只是默认设置。

检索团队在提示词中添加了三个少样本示例，因为基准测试提高了 4 分。三个示例大约 1,200 个 token。这完全是合理的——他们有评测指标的增量来证明这一点。

安全团队在生产环境出现险些酿成事故的情况后添加了一个段落。没人会反对这个安全段落。

产品团队添加了一个术语表，以便智能体不再混淆两个内部术语。这也很合理。

孤立来看，这些决定每一个都是正确的。每个团队都衡量了收益，并支付了可见的成本（几千个 token），而它们假设的预算实际上是免费的。缺陷不在于任何单个决策，而在于局部最优决策的总和导致了全局最差的结果，而且没有一个团队能站在全局视角看到这个总和。检索团队并不知道工具团队在上一个冲刺（sprint）中刚刚增加了 50,000 个 token。整合这些成本的系统并不存在。

而且成本是非线性的。超过某个阈值后——Chroma 的研究发现，随着输入长度的每一次增加，性能都会出现退化，且这种影响在远未达到 50,000 个 token 时就已经显现——增加上下文会让智能体变得更糟，而不仅仅是变慢。模型的注意力预算是有限的。长上下文中段信息的召回率比两端信息低 15-40%。因此，第 50 个工具定义不仅会消耗 token，还会将用户的实际问题推向模型关注度较低的区域。公地的退化不是渐进的。它会先退化，然后崩溃。

你无法治理无法归因的事物

第一步不是削减任何东西，而是让隐性成本可见，并归因到产生该成本的团队。

目前，大多数团队无法回答一个基本问题：你的功能为上下文窗口（context window）增加了多少 token？他们知道自己的评估（eval）分数，却不知道自己的足迹（footprint）。这种不对称正是问题的核心——收益是按团队衡量的，而成本却是共担的。通过仪表化（instrumentation）可以解决这个问题。

构建一个上下文清单（context manifest）。每一块常驻上下文（standing context）——基础提示词（base prompt）、每个工具组、每组检索示例、每个指令段落——在每次构建时都会计算其所有者和 token 数量。输出是一个简单的表格：章节、所属团队、token 数量、常驻预算百分比。当工具团队添加一个 MCP 服务器时，清单会显示工具定义从 18,000 个 token 激增到 68,000 个 token，并指明是哪个细分项发生了变动。

这将对话从“智能体（agent）感觉很慢”转变为“工具定义占用了窗口的 34%，且本月增长了 50,000 个 token，由集成团队负责”。这才是人们可以采取行动的表述。这等同于云成本归因：在账单按团队拆解之前，没有人会优化支出。在上下文窗口进行同样的拆解之前，关于臃肿的每一次讨论都只是在讨论一个无人负责的数字。

也要进行长期追踪。单一的快照只能告诉你现状；趋势线则能告诉你“过度消耗（grazing）”的速度。你真正想在仪表板上看到的数字是：按团队划分的每周常驻上下文 token 数。

实行有配额的预算，而非放任自流

归因能告诉你谁在消耗，而配额则决定了每个团队允许消耗多少。

一旦有了清单，下一步就是将隐含的放任自流转变为明确的分配。确定常驻上下文（即用户第一条消息之前的所有内容）允许消耗的成本。一个有用的默认设置是：常驻上下文应至少留出 70-80% 的“有效”窗口，用于对话、运行时检索和智能体自身的工作 token。注意是“有效（effective）”窗口，而非标称（nominal）窗口。如果上下文腐败（context rot）导致 200,000 个标称 token 的表现仅相当于 80,000 个有用 token，那么你的常驻预算应该是 80,000 的一小部分，而不是 200,000。

然后将常驻预算拆分为配额。平台团队获得 N 个 token 用于基础提示词。工具团队获得工具定义的配额。检索团队获得常驻示例的配额。配额在 CI 中强制执行：如果构建导致某个章节超过其细分项，则构建失败，就像测试未通过会导致构建失败一样。

配额并不是说“不”，而是说“权衡”。如果工具团队需要 60,000 个 token 而其配额只有 40,000 个，它有三个诚实的选择：删掉低价值工具；转向不预先加载所有工具的模型——工具搜索方法允许智能体按需发现工具，而不是携带所有定义；而代码执行模式将工具界面呈现为智能体调用的 API，而不是它必须保留在上下文中的模式（schemas）。或者，向分配负责人申请更大的配额，这意味着其他团队的配额会缩减。

最后一个选项正是重点所在。配额迫使权衡变得公开透明，并为其指定负责人。没有配额，权衡仍然会发生——只是它在无声无息中发生，分散在每个用户下降的体验中，且无人决策。

上下文审计：每一句指令都必须重新证明其价值

配额可以阻止窗口无限制增长。但它们无法收回已有的空间，也无法发现那些曾经合理但现在已过时的上下文缓慢腐烂的问题。为此，你需要定期审计。

原则是：常驻上下文不是一个只能追加的账本，而是一个你需要定期清算的投资组合。每一句指令、每一个示例、每一个工具定义都应该按计划（每季度一次比较合理）重新证明其存在的必要性。

真正的审计会对每个区块提出具体问题。为什么要添加这个——是否有相关的评估（eval）、事件或工单？十八个月前在一次事件中添加的术语表段落：如果没有它，模型是否仍然会困惑，还是模型升级已使其变得多余？那三个少样本（few-shot）示例：它们是否仍在提升基准测试表现，还是更新的模型已经内化了这种模式？这 40 个工具中的每一个：上一次在生产环境中被调用是什么时候？一个在 90 天内从未被调用的工具不是一种能力，而是对每一次请求征收的 1,000 个 token 的“税”，它降低了所有其他工具的召回率（recall）。

审计的默认选项应该是移除。任何没有当前、可证明的正当理由的内容都应移除，如果移除造成了损害，评估套件会捕捉到。这反转了通常的偏见。如今，增加上下文只需要一个小理由（“它提升了四个百分点”），而移除它则需要大费周章（“证明移除不会导致任何问题”）。审计翻转了这一点：保留上下文需要理由，而移除是默认操作。将其作为回归测试运行——在每次移除后重新运行完整评估，你通常会发现智能体表现不变或略有提升，因为你也移除了模型本需分散注意力去处理的噪声。

将审计与一条简单的文化规则结合：任何增加常驻上下文的拉取请求（pull request）都必须链接证明其合理性的评估或事件，说明清单中的 token 成本，并指明所消耗的配额。上下文变成了一种经过审查的资源，而不是免费资源。

把它当作它本该是的共享资源来对待

解决公地悲剧的方法绝不是“要求人们更加小心”。而是建立结构：让共享成本在每个具体决策中变得可见，为资源指定分配者，并为每一次提取定价。组织层面的上下文工程（Context Engineering）正是如此。

按顺序分三步走。归因（Attribution）—— 一份上下文清单，按所属团队细分窗口占用情况并进行长期追踪，使账单条目化。配额（Quotas）—— 针对 有效 窗口制定的明确常设上下文预算，拆分为各团队的专项条目并在 CI 中强制执行，从而让增长变成一种权衡，而非无声的税收。审计（Audits）—— 每季度的清理，每一项条款都必须重新证明其存在的合理性，且默认操作是移除，从而回收那些不再产生价值的上下文。

添加上下文的团队并不是问题所在；他们正在出色地完成工作。缺失的一环是分配者。建立起这套机制，上下文窗口就不再是每个团队竞相过度放牧直到崩溃的牧场，而是变成它本该有的样子：一个有预算、有所有者的资源，而用户的实际问题才是其中最重要的内容。