200K context 怎么花？我把一次请求拆成 6 个预算桶

一个 187K token 的惨痛教训

去年九月接了一个保险行业的 AI 客服项目。甲方最开始那位产品经理的原话我到现在记得——“Claude 不是有 200K 窗口吗？那我们所有保单条款、历史对话、用户档案，全塞进去，让模型自己找答案。”

我当时就懵了一下，但没反驳。毕竟客户是上帝嘛，先跑一版看看。

跑了一周测试集，F1 从基线的 0.76 掉到了 0.68。客户那边还没发作，我自己先慌了。一次请求平均 187K token，input 就要烧掉 0.56 美刀，返回质量还不如当初拿 20K context 做的 demo。

后来翻 Anthropic 发的一些工程 blog，加上我自己跑了十几组对比，才把问题理清楚：200K 是能用的上限，不是该用的配额。就像你信用卡额度 50 万，不代表你每个月该刷 50 万。

我现在固定用的 6 桶预算模型

后来我们团队内部定了个分配规则，做 RAG 或者 agent 的时候就照这个走。数字是针对 Sonnet 4.5 调出来的，Opus 可以宽一点，Haiku 要再紧一点。

桶 1：系统指令（~2K）

就是你那段「你是一个 XX 助手，请用 YY 风格回答」。很多人写到一两千字还收不住。说白了系统指令不是写小说，够用就行。2K 基本能覆盖角色、风格、硬约束三件事。超了基本就是废话太多，或者该用 CLAUDE.md 沉淀的东西塞到这里了（顺手推荐看 CLAUDE.md 项目配置）。

桶 2：工具定义（~3K）

如果你用 function calling 或者 MCP，工具的 JSON Schema 会占一块。别看着不多，一个复杂 agent 挂 15 个工具，光定义就能飙到 8K。我现在的原则是：一次对话用不到的工具就不要挂进来，动态加载。关于 MCP 和传统 function calling 的取舍可以看 MCP vs Function Calling。

桶 3：长期记忆/知识库精华（~10K）

这块是 RAG 系统里最容易被忽视的。不是当次检索的文档，而是”这个用户是老客户、VIP 等级、历史投诉 2 次”这种持久化状态。塞太多就变成背景噪音，模型 attention 会被稀释。

桶 4：当前检索结果（~30K）

也就是 retrieval 阶段捞回来的 top-k 文档。30K 听起来挺多，其实也就 6-8 段长文档。超过这个数你就要考虑 rerank 了——这事儿我专门写过 RAG 里的 rerank。

桶 5：对话历史（~20K）

多轮对话的累积。到一定长度必须压缩，后面会详细说。

桶 6：当前用户输入（~5K）

用户这一轮说的话。留点余量给他贴个长邮件或者代码片段。

加起来 70K 左右，离 200K 还差得远。但这是健康水位，不是上限。

每桶超支的典型症状

这是我们踩坑总结的对照表，现在贴在 Confluence 上，新人上手前先看。

系统指令超过 4K：模型开始”遗忘”开头指令，尤其到长对话后期。这其实就是经典的 “lost in the middle”。

工具定义超过 5K：模型会乱挑工具。我见过一个 case，13 个工具里有 2 个功能相近，定义又长，模型 30% 的 case 选错了那个。砍掉重复的瞬间就好。

长期记忆超过 15K：无关信息污染。比如你塞了用户三年前的一次购买记录，模型突然就基于那个老信息做推理。不该知道的别给它知道。

检索结果超过 50K：进入 lost-in-the-middle 重灾区。Anthropic 自己的论文也印证了，position 10-20 的文档 recall 会掉 18-22%。

对话历史超过 30K：模型开始”忘掉”最早的约定。我那个保险项目最严重的时候，用户前 30 轮说了自己是 70 岁老人、心脏病史，到第 80 轮模型推荐了一个”适合年轻健康人群”的产品。

当前输入超过 10K：通常是用户贴了整份文档。这种 case 应该拆成一次 ingestion + 一次 query，而不是直接塞。

那个保险项目后来怎么救回来的

原始版本 187K，F1 0.68。我们做了四件事：

第一，检索从 top-20 砍到 top-5，配合 Haiku 4.5 做 rerank。这一步把桶 4 从 78K 压到 22K。

第二，对话历史做分级压缩——最近 5 轮原文保留，再之前的滚动摘要，十轮之前只保留 entity。桶 5 从 52K 压到 14K。

第三，系统指令砍掉一堆”请注意””务必””切记”这种废话，结构化成 XML 标签（为什么 XML 比 Markdown 好）。桶 1 从 6K 压到 1.8K。

第四，长期记忆只保留当前会话可能用到的那部分——不是把用户所有档案塞进去，而是提前按 intent 做一次筛选。桶 3 从 31K 压到 7K。

最终一次请求 44.8K token，F1 0.84。成本从 0.56 刀降到 0.11 刀。客户那位产品经理到项目收尾还问我：”你们是不是换了更贵的模型？怎么感觉变聪明了。”

Lost in the middle 的几个缓解技巧

这个效应没法完全消除，只能减弱。我现在常用的几招：

重要信息放头尾。 系统指令放头，当前 query 放尾，这两个位置 attention 最强。中间塞检索结果。关于系统指令到底放哪里，这篇写得比较清楚。

用 XML 标签锚定关键段。 模型对 <critical> <user_profile> 这种标签极其敏感，相当于给它划了重点。

证据按相关度降序，但最相关的放最后。 这是反直觉的。因为 recency 效应比 primacy 还强。我们 AB 过，相关度最高的放最后比放最前 F1 高 3-4 个点。

别让模型自己找针。 在 prompt 里直接说”答案在 Document 3 的第二段”，比让它自己扫描 20 段文档准确率高很多。当然这要求你 retrieval 环节已经定位精确。

给还在”塞满”的朋友一句话

200K context 是营销数字，不是工程配额。

真正决定效果的是你怎么编排这 200K，不是你塞了多少。我现在看到团队说”我们要用满 context”就觉得这个项目八成要返工。就像做菜，盘子大不代表菜要装满，留白也是风味的一部分。

预算思维只是第一步。拆好桶之后，每个桶里面还有一堆小学问——怎么压缩对话历史、怎么排列检索结果、怎么让 Claude 真的记住最重要的几句话。后面几篇会一个一个拆。